Saslpassauth, nosaslpassauth, sasltrustauth, nosasltrustauth Channel Options

From Messaging Server Technical Reference Wiki
Jump to: navigation, search


AUTH parameter handling (saslpassauth, nosaslpassauth, sasltrustauth, nosasltrustauth)

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 saslpassauth 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. nosaslpassauth is the default.

New in Messaging Server 7.3-11.01, if the sasltrustauth channel option is set on a source channel, any value presented in the AUTH parameter will be promoted to the authenticated originator address that's used throughout the MTA. nosasltrustauth is the default. The sasltrustauth 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 sasltrustauth, if not done thoughtfully and carefully, may negate the value of certain authentication checks and allow more malicious spoofing of e-mail. Normally sasltrustauth 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 sasltrustauth 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 sasltrustauth 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 AUTH_ACCESS mapping table and AUTH_REWRITE mapping table, both of which can affect the MAIL FROM AUTH parameter.


See also: