.HP 5
.na
.B send
-.RB [ \-alias
-.IR aliasfile ]
+.RI [ +folder ]
+.RI [ msgs ]
.RB [ \-verbose " | " \-noverbose ]
-.RB [ \-watch " | " \-nowatch ]
-.RB [ msg
-\&...]
-.RB [ \-version ]
+.RB [ \-Version ]
.RB [ \-help ]
.ad
.SH DESCRIPTION
.B Send
will cause each of the specified messages to be delivered
-to each of the destinations in the \*(lqTo:\*(rq, \*(lqCc:\*(rq,
-\*(lqBcc:\*(rq, \*(lqDcc:\*(rq, and \*(lqFcc:\*(rq fields of the message. If
+to each of the destinations in the `To:', `Cc:',
+`Bcc:', `Dcc:', and `Fcc:' fields of the message. If
.B send
is re\-distributing a message, as invoked from
.BR dist ,
then the
-corresponding \*(lqResent\-xxx\*(rq fields are examined instead.
+corresponding `Resent\-xxx' fields are examined instead.
.PP
.B send
uses the program
are actually performed by
.BR spost .
.PP
-The draft is scanned for attachment header fields.
+Unless a
+.I 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
.I Attachment-Header
profile entry.
-If such header fields are found, or the body contains non-ASCII characters,
-the message is converted to a MIME message.
-This conversion occurs before all other processing.
+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.)
.PP
-The first part of the MIME message is the draft body if the body is non-empty.
-The body of each attachment header field is interpreted as a file name,
-and each file named is included as a separate part in the MIME message.
.PP
-For file names with dot suffixes, the context is scanned for a
-.I show-suffix-
-entry for that suffix.
-The content-type for the part is taken from that context entry if a match is
-found.
-If no match is found or the file does not have a dot suffix, the content-type
-is text/plain if the file contains only ASCII characters or
-application/octet-stream otherwise.
+The MIME type of each file is determined by the MIME type query program,
+as defined by the
+.I Mime-Type-Query
+profile entry.
+Mmh distributes the program
+.BR print-mimetype ,
+in case no better alternative is available on the system.
.PP
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:
.PP
.nf
-Content-Type: text/plain; name="VERSION"; charset="us-ascii"
-Content-Description: VERSION
-Content-Disposition: attachment; filename="VERSION"
+Content-Type: text/plain; name="README"; charset="us-ascii"
+Content-Description: README
+Content-Disposition: attachment; filename="README"
.fi
.PP
+This conversion occurs before all other processing.
+.PP
+If, however, a
+.I 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
+.B mhbuild
+to create elaborate MIME structures, which reach way beyond the
+attachment system's capabilities.
If
-.B \-verbose
-is specified,
+.B mhbuild
+was invoked on the draft beforehand (e.g. at the Whatnow prompt),
+then
.B send
-will indicate the interactions
-occurring with the transport system, prior to actual delivery.
+will use this already MIMEified draft as is.
+.PP
+As a second conversion step,
+.B send
+searches for
+.I Sign
+and
+.I Enc
+header fields, and if found, invokes
+.B mhsign
+to sign and encrypt the message. Signing and encrypting is done
+independently of the MIME conversion.
+.PP
If
-.B \-watch
-is specified
+.B \-verbose
+is specified,
.B send
-will monitor the delivery of local
-and network mail. Hence, by specifying both switches, a large detail
-of information can be gathered about each step of the message's entry
-into the transport system.
+will request verbose information of the transport system.
.PP
.B Send
with no
-.I msg
-argument will send the current message in the draft folder.
+.I +folder
+and
+.I msgs
+arguments will send the current message in the draft folder.
.B Send
-always takes messages from the draft folder.
-(But, a
+sends messages from the draft folder, unless
.I +folder
-argument might be added in the future.)
+is given.
Consult the
.BR mh-draft (7)
man page for more information.
.PP
Once the transport system has successfully accepted custody of the
-message, the message will be renamed with a leading comma, which allows
-it to be retrieved until the next draft message is sent. If there are
-errors in the formatting of the message,
+message, the message will be moved into the trash folder.
+If there are errors in the formatting of the message,
.B send
will abort with a
(hopefully) helpful error message.
.PP
-If a \*(lqBcc:\*(rq field is encountered, its addresses will be used for
-delivery, and the \*(lqBcc:\*(rq field will be removed from the 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.
.PP
-If a \*(lqDcc:\*(rq field is encountered, its addresses will be used for
-delivery, and the \*(lqDcc:\*(rq field will be removed from the message. The
+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 \*(lqDcc:\*(rq field receive no
-explicit indication that they have received a \*(lqblind copy\*(rq.
+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 \*(lqBcc:\*(rq field
+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.
.PP
-Prior to sending the message, the fields \*(lqFrom:\ user@local\*(rq,
-and \*(lqDate:\ now\*(rq will be appended to the headers in the message.
+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
.B $SIGNATURE
is set, then its value
-is used as your personal name when constructing the \*(lqFrom:\*(rq
+is used as your personal name when constructing the `From:'
line of the message. If this environment variable is not set, then
.B send
-will consult the profile entry \*(lqSignature\*(rq for
+will consult the profile entry `Signature' for
this information.
.PP
If
.B send
is re\-distributing a message (when invoked by
.BR dist ),
-then \*(lqResent\-\*(rq will be prepended to each of these
-fields: \*(lqFrom:\*(rq, \*(lqDate:\*(rq, and \*(lqMessage\-ID:\*(rq.
-If the message already contains a \*(lqFrom:\*(rq field, then a
-\*(lqSender: user@local\*(rq field will be added as well. (An already
-existing \*(lqSender:\*(rq field is an error!)
+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!)
.PP
-If an \*(lqFcc:\ folder\*(rq is encountered, the message will be copied
+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 \*(lqFcc:\*(rq fields
+the appended fields and field reformatting. The `Fcc:' fields
will be removed from all outgoing copies of the message.
.PP
-The files specified by the profile entry \*(lqAliasfile:\*(rq and any
-additional alias files given by the
-.B \-alias
-.I aliasfile
-switch will be
-read (more than one file, each preceded by
-.BR \-alias ,
-can be named).
+The files specified by the profile entry `Aliasfile:' will be read.
See
.BR mh\-alias (5)
for more information.
^Draft\-Folder:~^To set the default draft\-folder
^Aliasfile:~^For a default alias file
^Signature:~^To determine the user's mail signature
-^Attachment\-Header:~^To set the name of the attachment header field
+^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
.fi
.SH "SEE ALSO"
-comp(1), dist(1), forw(1), repl(1), mh\-alias(5), spost(8)
+comp(1), dist(1), forw(1), repl(1), mh\-alias(5), mhbuild(1),
+mhsign(1), spost(8)
.SH DEFAULTS
.nf
-.RB ` msg "' defaults to the current message in the draft folder"
+.RB ` msgs "' defaults to the current message"
+.RB ` +folder "' defaults to the draft folder"
.RB ` \-noverbose '
-.RB ` \-nowatch '
.fi
.SH CONTEXT
None
.SH BUGS
-Under some configurations, it is not possible to monitor the mail delivery
-transaction;
-.B \-watch
-is a no-op on those systems.
+None
projects / mmh / blobdiff