git.marmaro.de Git - mmh/blob - man/send.man1

   1 .\"
   2 .\" %nmhwarning%
   3 .\"
   4 .TH SEND %manext1% "%nmhdate%" MH.6.8 [%nmhversion%]
   5 .SH NAME
   6 send \- send a message
   7 .SH SYNOPSIS
   8 .HP 5
   9 .na
  10 .B send
  11 .RI [ +folder ]
  12 .RI [ msgs ]
  13 .RB [ \-verbose " | " \-noverbose ]
  14 .RB [ \-Version ]
  15 .RB [ \-help ]
  16 .ad
  17 .SH DESCRIPTION
  18 .B Send
  19 will cause each of the specified messages to be delivered
  20 to each of the destinations in the `To:', `Cc:',
  21 `Bcc:', `Dcc:', and `Fcc:' fields of the message.  If
  22 .B send
  23 is re\-distributing a message, as invoked from
  24 .BR dist ,
  25 then the
  26 corresponding `Resent\-xxx' fields are examined instead.
  27 .PP
  28 .B send
  29 uses the program
  30 .B spost
  31 to do the actual delivery of the messages.
  32 Most of the features attributed to
  33 .B send
  34 are actually performed by
  35 .BR spost .
  36 .PP
  37 Unless a
  38 .I MIME-Version
  39 header is already present, the message is converted to a MIME message.
  40 In this process, the draft is scanned for attachment header fields.
  41 Their name defaults to ``Attach'', but may be changed by the value of the
  42 .I Attachment-Header
  43 profile entry.
  44 If such header fields are found, the body of each is interpreted as a
  45 file name (or a message specification), and each of these files or
  46 messages is included as a separate part in the MIME message.
  47 (The first part of the MIME message is the draft body.)
  48 .PP
  49 .PP
  50 The MIME type of each file is determined by the MIME type query program,
  51 as defined by the
  52 .I Mime-Type-Query
  53 profile entry.
  54 Mmh distributes the program
  55 .BR print-mimetype ,
  56 in case no better alternative is available on the system.
  57 .PP
  58 The last component of the path name is taken as the name of the MIME parts.
  59 A message part header for an attachment might be:
  60 .PP
  61 .nf
  62 Content-Type: text/plain; name="README"; charset="us-ascii"
  63 Content-Description: README
  64 Content-Disposition: attachment; filename="README"
  65 .fi
  66 .PP
  67 This conversion occurs before all other processing.
  68 .PP
  69 If, however, a
  70 .I MIME-Version
  71 header field is already present in the draft, no such conversion
  72 will be done. This way, it is possible to access the full
  73 capabilities of
  74 .B mhbuild
  75 to create elaborate MIME structures, which reach way beyond the
  76 attachment system's capabilities.
  77 If
  78 .B mhbuild
  79 was invoked on the draft beforehand (e.g. at the Whatnow prompt),
  80 then
  81 .B send
  82 will use this already MIMEified draft as is.
  83 .PP
  84 As a second conversion step,
  85 .B send
  86 searches for
  87 .I Sign
  88 and
  89 .I Enc
  90 header fields, and if found, invokes
  91 .B mhsign
  92 to sign and encrypt the message. Signing and encrypting is done
  93 independently of the MIME conversion.
  94 .PP
  95 If
  96 .B \-verbose
  97 is specified,
  98 .B send
  99 will request verbose information of the transport system.
 100 .PP
 101 .B Send
 102 with no
 103 .I +folder
 104 and
 105 .I msgs
 106 arguments will send the current message in the draft folder.
 107 .B Send
 108 sends messages from the draft folder, unless
 109 .I +folder
 110 is given.
 111 Consult the
 112 .BR mh-draft (7)
 113 man page for more information.
 114 .PP
 115 Once the transport system has successfully accepted custody of the
 116 message, the message will be moved into the trash folder.
 117 If there are errors in the formatting of the message,
 118 .B send
 119 will abort with a
 120 (hopefully) helpful error message.
 121 .PP
 122 If a `Bcc:' field is encountered, its addresses will be used for
 123 delivery, and the `Bcc:' field will be removed from the message
 124 sent to sighted recipients.  The blind recipients will receive an entirely
 125 new message with a minimal set of headers.  Included in the body of the
 126 message will be a copy of the message sent to the sighted recipients.
 127 .PP
 128 If a `Dcc:' field is encountered, its addresses will be used for
 129 delivery, and the `Dcc:' field will be removed from the message.  The
 130 blind recipients will receive the same message sent to the sighted
 131 recipients. *WARNING* Recipients listed in the `Dcc:' field receive no
 132 explicit indication that they have received a `blind copy'.
 133 This can cause blind recipients to
 134 inadvertently reply to all of the sighted recipients of the
 135 original message, revealing that they received a blind copy.
 136 On the other hand, since a normal reply to a message sent
 137 via a `Bcc:' field
 138 will generate a reply only to the sender of the original message,
 139 it takes extra effort in most mailers to reply to the included
 140 message, and so would usually only be done deliberately, rather
 141 than by accident.
 142 .PP
 143 Prior to sending the message, the fields `From:\ user@local',
 144 and `Date:\ now' will be appended to the headers in the message.
 145 If the environment variable
 146 .B $SIGNATURE
 147 is set, then its value
 148 is used as your personal name when constructing the `From:'
 149 line of the message.  If this environment variable is not set, then
 150 .B send
 151 will consult the profile entry `Signature' for
 152 this information.
 153 .PP
 154 If
 155 .B send
 156 is re\-distributing a message (when invoked by
 157 .BR dist ),
 158 then `Resent\-' will be prepended to each of these
 159 fields: `From:', `Date:', and `Message\-ID:'.
 160 If the message already contains a `From:' field, then a
 161 `Sender: user@local' field will be added as well.  (An already
 162 existing `Sender:' field is an error!)
 163 .PP
 164 If an `Fcc:\ folder' is encountered, the message will be copied
 165 to the specified folder for the sender in the format in which it will
 166 appear to any non\-Bcc receivers of the message.  That is, it will have
 167 the appended fields and field reformatting.  The `Fcc:' fields
 168 will be removed from all outgoing copies of the message.
 169 .PP
 170 The files specified by the profile entry `Aliasfile:' will be read.
 171 See
 172 .BR mh\-alias (5)
 173 for more information.
 174
 175 .SH FILES
 176 .fc ^ ~
 177 .nf
 178 .ta \w'%etcdir%/ExtraBigFileName  'u
 179 ^$HOME/.mmh/profile~^The user profile
 180 ^+drafts~^The draft folder
 181 .fi
 182
 183 .SH "PROFILE COMPONENTS"
 184 .fc ^ ~
 185 .nf
 186 .ta 2.4i
 187 .ta \w'ExtraBigProfileName  'u
 188 ^Path:~^To determine the user's mail storage
 189 ^Draft\-Folder:~^To set the default draft\-folder
 190 ^Aliasfile:~^For a default alias file
 191 ^Signature:~^To determine the user's mail signature
 192 ^Attachment\-Header:~^The name of the attachment header field
 193 ^Sign\-Header:~^The name of the sign request header field
 194 ^Enc\-Header:~^The name of the encryption request header field
 195 ^Mime\-Type\-Query:~^Program to determine the MIME types of files
 196 .fi
 197
 198 .SH "SEE ALSO"
 199 comp(1), dist(1), forw(1), repl(1), mh\-alias(5), mhbuild(1),
 200 mhsign(1), spost(8)
 201
 202 .SH DEFAULTS
 203 .nf
 204 .RB ` msgs "' defaults to the current message"
 205 .RB ` +folder "' defaults to the draft folder"
 206 .RB ` \-noverbose '
 207 .fi
 208
 209 .SH CONTEXT
 210 None
 211
 212 .SH BUGS
 213 None