Saslpassauth, nosaslpassauth, sasltrustauth, nosasltrustauth Channel Options

AUTH parameter handling
The SMTP Service Extension for Authentication, specified in RFC 4954, defines an AUTH parameter for the MAIL FROM command. This parameter is normally used to pass information about the identity associated with the agent that submitted the message between SMTP servers. As required by the specification, the MTA always accepts and retains any value presented in an AUTH parameter.

If the  channel option is set on a destination channel, any AUTH parameter value associated with the message will be passed on to the next SMTP server, assuming that server supports the authentication extension. is the default.

New in Messaging Server 7.3-11.01,  if the   channel option is set on a source channel, any value presented in the AUTH parameter will be promoted to the authenticated originator address that&#x27;s used throughout the MTA. is the default. The  option should be used with great care because the AUTH parameter is not, in general, trustworthy and the authenticated originator address is used for a variety of authentication checks. So setting , if not done thoughtfully and carefully, may  negate the value of certain authentication checks and allow more  malicious spoofing of e-mail. Normally  would  only be appropriate on a channel that is dedicated to receiving  messages from a trustworthy (and itself careful and meticulous to  require authentication) source; note that such a source must not only  verify any authentication on the messages it accepts, but indeed  require authentication on any of its incoming messages that it  will relay to your host, or itself be part of a chain of such trusted  relaying. The situation to avoid is trusting MAIL FROM AUTH values relayed by a -- possibly reliable enough on what it happened to  authenticate itself---host that itself accepted for relaying a message  with an unreliable MAIL FROM AUTH parameter.

An example of appropriate  use would be where  there is a user-client-facing,  dedicated-to-accepting-message-submissions host that relays to your  host. Then on your host, on a channel dedicated to accepting only messages from that client-submission host, use of    could allow desirable passing along of  known-to-be-accurate AUTH parameters, without opening the security door  wide to passing along potentially inaccurate AUTH parameters.

See also the  mapping table and   mapping table,  both of which can affect the MAIL FROM AUTH parameter.

See also:
 * AUTH_ACCESS mapping table
 * AUTH_REWRITE mapping table
 * TLS and SASL channel options
 * Channel options