Just changed a "can" to a "could" since I don't know if most POP3 servers are
[mmh] / man / post.man
index c344043..23841f7 100644 (file)
@@ -24,6 +24,7 @@ post \- deliver a message
 \%[\-noverbose]
 \%[\-watch] \%[\-nowatch]
 \%[\-width\ columns]
 \%[\-noverbose]
 \%[\-watch] \%[\-nowatch]
 \%[\-width\ columns]
+\%[\-sasl] \%[\-saslmech\ mechanism] \%[\-user\ username]
 .br
 file
 \%[\-version]
 .br
 file
 \%[\-version]
@@ -75,13 +76,13 @@ delivery).
 
 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
 
 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,
 "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.
 
 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
 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
@@ -92,16 +93,18 @@ 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
 
 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.
 
 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),
 
 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),
@@ -112,7 +115,21 @@ 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.
 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
 
 .Fi
 ^%etcdir%/mts.conf~^nmh mts configuration file