send \- send a message
.SH SYNOPSIS
.HP 5
+.na
.B send
.RB [ \-alias
.IR aliasfile ]
.IR seconds ]
.RB [ \-verbose " | " \-noverbose ]
.RB [ \-watch " | " \-nowatch ]
+.RB [ \-server
+.IR servername ]
+.RB [ \-port
+.IR port-name/number ]
.RB [ \-sasl ]
.RB [ \-saslmech
.IR mechanism ]
\&...]
.RB [ \-version ]
.RB [ \-help ]
+.RB [ \-attach
+.IR header-field-name ]
+.RB [ \-attachformat
+.IR 0 " | " 1 " | " 2 ]
+.ad
.SH DESCRIPTION
.B Send
will cause each of the specified files to be delivered
to each of the destinations in the \*(lqTo:\*(rq, \*(lqcc:\*(rq,
-\*(lqBcc:\*(rq, and \*(lqFcc:\*(rq fields of the message. If
+\*(lqBcc:\*(rq, \*(lqDcc:\*(rq, and \*(lqFcc:\*(rq fields of the message. If
.B send
is re\-distributing a message, as invoked from
.BR dist ,
.B send
are actually performed by
.BR post .
+
+.PP
+If a
+.I header-field-name
+is supplied using the
+.B -attach
+option, the draft is scanned for a header whose field name matches the
+supplied
+.IR header-field-name .
+The draft is converted to a MIME message if one or more matches are found.
+This conversion occurs before all other processing.
+.PP
+The first part of the MIME message is the draft body if that body contains
+any non-blank characters.
+The body of each header field whose name matches the
+.I header-field-name
+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 mhshow-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
+if it contains characters outside of the ASCII range.
+.PP
+Each part contains a name attribute that is the last component of the path name.
+A
+.I x-unix-mode
+attribute containing the file mode accompanies each part.
+Finally, a description attribute is generated by running the
+.I file
+command on the file.
+.PP
+The
+.B -attachformat
+option specifies the MIME header field formats: a value of
+.B 0,
+the default,
+includes the
+.I x-unix-mode
+attribute as noted above. A value of
+.B 1
+suppresses both that and the \*(lqContent-Description\*(rq header, and
+adds a \*(lqContent-Disposition\*(rq header. A value of
+.B 2
+adds the file
+.I modification-date
+parameter to the \*(lqContent-Disposition\*(rq header. You can
+specify one value in your profile, and override it for individual
+messages at the
+.I whatnow
+prompt.
+.PP
+Here are example message part headers for each of the
+.B -attachformat
+values:
+.PP
+.nf
+-attachformat 0:
+Content-Type: text/plain; name="VERSION"; x-unix-mode="0644";
+ charset="us-ascii"
+Content-Description: ASCII text
+
+-attachformat 1:
+Content-Type: text/plain; charset="us-ascii"
+Content-Disposition: attachment; filename="VERSION"
+
+-attachformat 2:
+Content-Type: text/plain; charset="us-ascii"
+Content-Disposition: attachment; filename="VERSION"; modification-date="Mon, 19 Dec 2005 22:39:51 -0600"
+.fi
.PP
If
.B \-push
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
+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.
+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
+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
If
.B \-filter
.I filterfile
.B send
as to how long it should make header lines containing addresses.
.PP
+If nmh is using the SMTP MTA, the
+.B \-server
+and the
+.B \-port
+switches can be used to override the default mail server (defined by the
+.RI servers
+entry in
+.I %etcdir%/mts.conf
+).
+.PP
If
.B nmh
has been compiled with SASL support, the
switch can be used to select a authorization userid
to provide to SASL other than the default.
.PP
-Currently SASL security layers are not supported for SMTP.
-.BR nmh 's
-SMTP SASL code
-will always negotiate an unencrypted connection. This means that while the SMTP
-authentication can be encrypted, the subsequent data stream can not. This is in
-contrast to
-.BR nmh 's
-POP3 SASL support, where encryption is supported for both the
-authentication and the data stream.
+If SASL authentication is successful,
+.BR nmh
+will attempt to negotiate a security layer for session encryption.
+Encrypted data is labelled with `(encrypted)' and `(decrypted)' when
+viewing the SMTP transaction with the
+.B \-snoop
+switch.
.PP
The files specified by the profile entry \*(lqAliasfile:\*(rq and any
additional alias files given by the
.SH FILES
.fc ^ ~
.nf
-.ta \w'/usr/local/nmh/etc/ExtraBigFileName 'u
+.ta \w'%etcdir%/ExtraBigFileName 'u
^$HOME/\&.mh\(ruprofile~^The user profile
.fi
.RB ` \-noverbose '
.RB ` \-nowatch '
.RB ` "\-width\ 72" '
+.RB ` "\-attachformat\ 0" '
.fi
.SH CONTEXT