-
-Under normal circumstances, \fIpost\fR constructs the "From:" line of the
-message from the user's UNIX username, the full name from the GECOS field of the
-passwd file, and the fully-qualified name of the local machine (e.g. `From: "Dan
-Harkless" <dan@machine.company.com>'). However, there are three ways to
-override these values. Note that they apply equally to "Resent-From:" lines in
-messages sent with \fIdist\fR.
-
-The first way is GECOS-based username masquerading. If "mmailid" in the
-mts.conf file has been set to non-zero, this processing is activated. If a
-user's GECOS field in the passwd file is of the form "Full Name <fakename>" then
-"fakename" will be used in place of the real username. For instance, a GECOS
-field of "Dan Harkless <Dan.Harkless>" would result in `From: "Dan Harkless"
-<Dan.Harkless@machine.company.com>'. Naturally if you were doing something like
-this you'd want to set up an MTA alias (e.g. in /etc/aliases) from, for
-instance, "Dan.Harkless" to "dan".
-
-The second way to override default construction of "From:" is to set the
-\fB$SIGNATURE\fR environment variable. This variable overrides the full name
-from the GECOS field, even if GECOS-based masquerading is being done.
-
-The third way, which will override either of the previous two, is to specify a
-"From:" line manually in the message draft. It will be used as provided (after
-alias substitution), but to discourage email forgery, the user's real address
-will be used in the SMTP envelope "From:" and in the "Sender:" line. However,
-if the system administrator has allowed address masquerading by setting
-"mmailid" to non-zero in mts.conf, the SMTP envelope "From:" will use the
-address given in the draft "From:", and there will be no "Sender:" header. This
-is useful in pretending to send mail "directly" from a remote POP3 account, or
-when remote email robots give improper precedence to the envelope "From:". Note
-that your MTA may still reveal your real identity (e.g. sendmail's
-"X-Authentication-Warning:" header).
-
-.Fi
+.PP
+Under normal circumstances,
+.B post
+uses the \*(lqFrom:\*(rq line in the message draft as the identity of
+the the originating mailbox. A \*(lqFrom:\*(rq line is required in
+all message draft. By default the message composition utilities such
+as
+.BR comp ,
+.B repl
+and
+.B mhmail
+will automatically place a \*(lqFrom:\*(rq line in the message draft.
+There are two ways to override this behavior, however.
+Note that they apply equally to \*(lqResent\-From:\*(rq lines in messages sent
+with
+.BR dist .
+.PP
+The first way is to supply a \*(lqSender:\*(rq line. The value of this
+field will be used as the originating mailbox identity when submitting the
+message to the mail transport system. If multiple addresses are
+given in the \*(lqFrom:\*(rq line, a \*(lqSender:\*(rq line is
+.BR required .
+If an \*(lqEnvelope-From:\*(rq line is supplied when multiple addresses
+are given in the \*(lqFrom:\*(rq line, a \*(lqSender:\*(rq header will
+be generated using the value of the \*(lqEnvelope-From:\*(rq line,
+.B if
+the \*(lqEnvelope-From:\*(rq line is not blank.
+.PP
+The second way is to supply a \*(lqEnvelope-From:\*(rq line. The value
+of this field will be used as the originating mailbox identity when
+submitting the message to the mail transport system. This will override
+both the value of the \*(lqFrom:\*(rq line and a \*(lqSender:\*(rq line
+(if one is supplied). The \*(lqEnvelope-From:\*(rq line is allowed to
+have a blank value; if the value is blank, then the mail transport system
+will be instructed to not send any bounces in response to the message.
+Not all mail transport systems support this feature.
+.PP
+The mail transport system default is provided in
+.I %etcdir%/mts.conf
+but can be overriiden here with the
+.B \-mts
+switch.
+.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
+.B \-sasl
+and
+.B \-nosasl
+switches will enable and disable
+the use of SASL authentication with the SMTP MTA. Depending on the
+SASL mechanism used, this may require an additional password prompt from the
+user (but the
+.RI \*(lq \&.netrc \*(rq
+file can be used to store this password).
+.B \-saslmech
+switch can be used to select a particular SASL mechanism,
+and the the
+.B \-user
+switch can be used to select a authorization userid
+to provide to SASL other than the default.
+.PP
+If SASL authentication is successful,
+.BR nmh
+will attempt to negotiate a security layer for session encryption.
+Encrypted data is labelled with `(sasl-encrypted)' and `(sasl-decrypted)' when
+viewing the SMTP transaction with the
+.B \-snoop
+switch. The
+.B \-saslmaxssf
+switch can be used to select the maximum value of the Security Strength Factor.
+This is an integer value and the exact meaning of this value depends on the
+underlying SASL mechanism. A value of 0 disables encryption.
+.PP
+If
+.B nmh
+has been compiled with TLS support, the
+.B \-tls
+and
+.B \-notls
+switches will require and disable the negotiation of TLS support when
+connecting to the
+SMTP MTA. Encrypted data is labelled with `(tls-encrypted)' and
+`(tls-decrypted)' when viewing the SMTP transction with the
+.B \-snoop
+switch.
+.SH FILES
+.fc ^ ~
+.nf
+.ta \w'%etcdir%/ExtraBigFileName 'u