+.PP
+Under normal circumstances,
+.B post
+constructs the \*(lqFrom:\*(rq line of the
+message from the user's login name, the full name from the GECOS field of the
+passwd file, and the fully\-qualified name of the local machine (or the
+value of
+\*(lqlocalname\*(rq in
+.IR mts.conf ,
+if set). An example is \*(lqFrom: Dan Harkless
+<dan@machine.company.com>\*(rq. There are four ways to override these values,
+however. Note that they apply equally to \*(lqResent\-From:\*(rq lines in messages sent
+with
+.BR dist .
+.PP
+The first way is GECOS\-based username masquerading. If the \*(lqmasquerade:\*(rq line
+in
+.I mts.conf
+contains \*(lqmmailid\*(rq, this processing is activated. If a user's GECOS
+field in the passwd file is of the form \*(lqFull Name <fakename>\*(rq then \*(lqfakename\*(rq
+will be used in place of the real username. For instance, a GECOS field of \*(lqDan
+Harkless <Dan.Harkless>\*(rq would result in \*(lqFrom: Dan Harkless
+<Dan.Harkless@machine.company.com>\*(rq. 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, \*(lqDan.Harkless\*(rq to \*(lqdan\*(rq.
+.PP
+The second way to override default construction of \*(lqFrom:\*(rq is to set the
+.B $SIGNATURE
+environment variable. This variable overrides the full name
+from the GECOS field, even if GECOS\-based masquerading is being done. This
+processing is always active, and does not need to be enabled from
+.IR mts.conf .
+.PP
+The third way is controlled by the \*(lquser_extension\*(rq value of \*(lqmasquerade:\*(rq line
+of
+.IR mts.conf .
+When that's turned on, setting the
+.B $USERNAME_EXTENSION
+environment variable will result in its value being appended the user's login
+name. For instance, if I set
+.B $USERNAME_EXTENSION
+to \*(lq+www\*(rq, my \*(lqFrom:\*(rq
+line will contain \*(lqDan Harkless <dan+www@machine.company.com>\*(rq (or
+\*(lqDan.Harkless+www\*(rq if I'm using mmailid masquerading as well). Recent versions
+of
+.B sendmail
+automatically deliver all mail sent to
+.IR user + string
+to
+.IR user .
+.B qmail
+has a similar feature which uses '\-' as the delimiter by
+default, but can use other characters as well.
+.PP
+The fourth method of address masquerading is to specify a \*(lqFrom:\*(rq line manually
+in the message draft. It will be used as provided (after alias substitution),
+but normally, to discourage email forgery, the user's
+.B real
+address will be
+used in the SMTP envelope \*(lqFrom:\*(rq and in a \*(lqSender:\*(rq header. However, if the
+\*(lqmasquerade:\*(rq line of
+.I mts.conf
+contains \*(lqdraft_from\*(rq, the SMTP envelope \*(lqFrom:\*(rq
+will use the address given in the draft \*(lqFrom:\*(rq, and there will be no \*(lqSender:\*(rq
+header. This is useful in pretending to send mail \*(lqdirectly\*(rq from a remote POP3
+account, or when remote email robots give improper precedence to the envelope
+\*(lqFrom:\*(rq. Note that your MTA may still reveal your real identity (e.g.
+.BR sendmail 's
+\*(lqX\-Authentication\-Warning:\*(rq header).
+.PP
+If
+.B nmh
+has been compiled with SASL support, the
+.B \-sasl
+switch will enable
+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
+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.