X-Git-Url: http://git.marmaro.de/?a=blobdiff_plain;f=man%2Fpost.man;h=23841f788da969e71586f3c8b0f9d28a2e619ca4;hb=22a08fd1babf7a0a5602684ea0c6c2485e15f6d9;hp=397901a5f842de15c052375a1993b4cba3bdcefe;hpb=1691e80890e5d8ba258c51c214a3e91880e1db2b;p=mmh diff --git a/man/post.man b/man/post.man index 397901a..23841f7 100644 --- a/man/post.man +++ b/man/post.man @@ -24,6 +24,7 @@ post \- deliver a message \%[\-noverbose] \%[\-watch] \%[\-nowatch] \%[\-width\ columns] +\%[\-sasl] \%[\-saslmech\ mechanism] \%[\-user\ username] .br file \%[\-version] @@ -73,9 +74,62 @@ The `\-watch' switch indicates that the user would like to watch the transport system's handling of the message (e.g., local and \*(lqfast\*(rq delivery). -\fIPost\fR consults the environment variable \fB$SIGNATURE\fR to determine -the sender's personal name in constructing the \*(lqFrom:\*(rq line of -the message. +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 +"localname" in mts.conf, if set). An example is "From: Dan Harkless +". There are four ways to override these values, +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 +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 " then "fakename" +will be used in place of the real username. For instance, a GECOS field of "Dan +Harkless " would result in "From: Dan Harkless +". 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. This +processing is always active, and does not need to be enabled from mts.conf. + +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 " (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), +but normally, to discourage email forgery, the user's \fIreal\fR address will be +used in the SMTP envelope "From:" and in a "Sender:" header. However, if the +"masquerade:" line of mts.conf contains "draft_from", 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). + +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 @@ -87,7 +141,7 @@ the message. .Sa \fIStandard for the Format of ARPA Internet Text Messages\fR (RFC\-822), .br -mhmail(1), send(1), mh\-mail(5), mh\-alias(5) +mhmail(1), send(1), mh\-mail(5), mh\-alias(5), mh\-tailor(5) .De `\-alias %etcdir%/MailAliases' .Ds