| SEND(1mh) | [mmh-0.4] | SEND(1mh) |
send - send a message
send [+folder] [msgs] [-verbose | -noverbose] [-Version] [-help]
Send will cause each of the specified messages to be delivered to each of the destinations in the `To:', `Cc:', `Bcc:', `Dcc:', and `Fcc:' fields of the message. If send is re-distributing a message, as invoked from dist, then the corresponding `Resent-xxx' fields are examined instead.
send uses the program spost to do the actual delivery of the messages. Most of the features attributed to send are actually performed by spost.
Unless a MIME-Version header is already present, the message is converted to a MIME message. In this process, the draft is scanned for attachment header fields. Their name defaults to ``Attach'', but may be changed by the value of the Attachment-Header profile entry. If such header fields are found, the body of each is interpreted as a file name (or a message specification), and each of these files or messages is included as a separate part in the MIME message. (The first part of the MIME message is the draft body.)
The MIME type of each file is determined by the MIME type query program, as defined by the Mime-Type-Query profile entry. Mmh distributes the program print-mimetype, in case no better alternative is available on the system.
The last component of the path name is taken as the name of the MIME parts. A message part header for an attachment might be:
Content-Type: text/plain; name="README"; charset="us-ascii" Content-Description: README Content-Disposition: attachment; filename="README"
This conversion occurs before all other processing.
If, however, a MIME-Version header field is already present in the draft, no such conversion will be done. This way, it is possible to access the full capabilities of mhbuild to create elaborate MIME structures, which reach way beyond the attachment system's capabilities. If mhbuild was invoked on the draft beforehand (e.g. at the Whatnow prompt), then send will use this already MIMEified draft as is.
As a second conversion step, send searches for Sign and Enc header fields, and if found, invokes mhsign to sign and encrypt the message. Signing and encrypting is done independently of the MIME conversion.
If -verbose is specified, send will request verbose information of the transport system.
Send with no +folder and msgs arguments will send the current message in the draft folder. Send sends messages from the draft folder, unless +folder is given. Consult the mh-draft(7) man page for more information.
Once the transport system has successfully accepted custody of the message, the message will be moved into the trash folder. If there are errors in the formatting of the message, send will abort with a (hopefully) helpful error message.
If a `Bcc:' field is encountered, its addresses will be used for delivery, and the `Bcc:' field will be removed from the message sent to sighted recipients. The blind recipients will receive an entirely new message with a minimal set of headers. Included in the body of the message will be a copy of the message sent to the sighted recipients.
If a `Dcc:' field is encountered, its addresses will be used for delivery, and the `Dcc:' field will be removed from the message. The blind recipients will receive the same message sent to the sighted recipients. *WARNING* Recipients listed in the `Dcc:' field receive no explicit indication that they have received a `blind copy'. This can cause blind recipients to inadvertently reply to all of the sighted recipients of the original message, revealing that they received a blind copy. On the other hand, since a normal reply to a message sent via a `Bcc:' field will generate a reply only to the sender of the original message, it takes extra effort in most mailers to reply to the included message, and so would usually only be done deliberately, rather than by accident.
Prior to sending the message, the fields `From: user@local', and `Date: now' will be appended to the headers in the message. If the environment variable $SIGNATURE is set, then its value is used as your personal name when constructing the `From:' line of the message. If this environment variable is not set, then send will consult the profile entry `Signature' for this information.
If send is re-distributing a message (when invoked by dist), then `Resent-' will be prepended to each of these fields: `From:', `Date:', and `Message-ID:'. If the message already contains a `From:' field, then a `Sender: user@local' field will be added as well. (An already existing `Sender:' field is an error!)
If an `Fcc: folder' is encountered, the message will be copied to the specified folder for the sender in the format in which it will appear to any non-Bcc receivers of the message. That is, it will have the appended fields and field reformatting. The `Fcc:' fields will be removed from all outgoing copies of the message.
The files specified by the profile entry `Aliasfile:' will be read. See mh-alias(5) for more information.
^$HOME/.mmh/profile~^The user profile ^+drafts~^The draft folder
^Path:~^To determine the user's mail storage ^Draft-Folder:~^To set the default draft-folder ^Aliasfile:~^For a default alias file ^Signature:~^To determine the user's mail signature ^Attachment-Header:~^The name of the attachment header field ^Sign-Header:~^The name of the sign request header field ^Enc-Header:~^The name of the encryption request header field ^Mime-Type-Query:~^Program to determine the MIME types of files
comp(1), dist(1), forw(1), repl(1), mh-alias(5), mhbuild(1), mhsign(1), spost(8)
`msgs' defaults to the current message `+folder' defaults to the draft folder `-noverbose'
None
None
| 2019-01-06 | MH.6.8 |