.\" include the -mh macro file
.so %etcdir%/tmac.h
.\"
-.TH POST %manext8% MH.6.8 [%nmhversion%]
+.TH POST %manext8% "%nmhdate%" MH.6.8 [%nmhversion%]
.SH NAME
post \- deliver a message
.SH SYNOPSIS
\%[\-noverbose]
\%[\-watch] \%[\-nowatch]
\%[\-width\ columns]
+\%[\-sasl] \%[\-saslmech\ mechanism] \%[\-user\ username]
.br
file
\%[\-version]
Under normal circumstances, \fIpost\fR constructs the "From:" 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
+passwd file, and the fully\-qualified name of the local machine (or the value of
"localname" in mts.conf, if set). An example is "From: Dan Harkless
<dan@machine.company.com>". There are four ways to override these values,
-however. Note that they apply equally to "Resent-From:" lines in messages sent
+however. Note that they apply equally to "Resent\-From:" lines in messages sent
with \fIdist\fR.
-The first way is GECOS-based username masquerading. If the "masquerade:" line
+The first way is GECOS\-based username masquerading. If the "masquerade:" line
in mts.conf contains "mmailid", 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
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. This
+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 mts.conf.
-The third way is controlled by the "plussed_user" value of "masquerade:" line of
-mts.conf. When that's turned on, setting the $USERPLUS environment variable
-will result in its value being tacked onto the user's login name, following
-a '+' sign. For instance, if I set $USERPLUS to "www", my "From:" line will
-contain "Dan Harkless <dan+www@machine.company.com>" (or "Dan.Harkless+www" if
-I'm using mmailid masquerading as well). Recent versions of sendmail
-automatically deliver all mail sent to \fIuser\fR+\fIstring\fR to \fIuser\fR.
+The third way is controlled by the "user_extension" value of "masquerade:" line
+of mts.conf. When that's turned on, setting the \fB$USERNAME_EXTENSION\fR
+environment variable will result in its value being appended the user's login
+name. For instance, if I set \fB$USERNAME_EXTENSION\fR to "+www", my "From:"
+line will contain "Dan Harkless <dan+www@machine.company.com>" (or
+"Dan.Harkless+www" if I'm using mmailid masquerading as well). Recent versions
+of sendmail automatically deliver all mail sent to \fIuser\fR+\fIstring\fR to
+\fIuser\fR. qmail has a similar feature which uses '\-' as the delimiter by
+default, but can use other characters as well.
The fourth method of address masquerading is to specify a "From:" line manually
in the message draft. It will be used as provided (after alias substitution),
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).
+sendmail's "X\-Authentication\-Warning:" header).
+
+If nmh has been compiled with SASL support, the `\-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 \*(lq.netrc\*(rq file can be used to store this password).
+`\-saslmech' switch can be used to select a particular SASL mechanism,
+and the the `\-user' switch can be used to select a authorization userid
+to provide to SASL other than the default.
+
+Currently SASL security layers are not supported for SMTP. 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 nmh's POP3 SASL support, where encryption is supported for both the
+authentication and the data stream.
.Fi
^%etcdir%/mts.conf~^nmh mts configuration file