Maysasl, maysaslclient, maysaslserver, mustsasl, mustsaslclient, mustsaslserver, nosasl, nosaslclient, nosaslserver, disconnectbadauthlimit Channel Options

SMTP authentication and SASL
As of Messaging Server 7.0-3.01,   and   take effect for the SMTP client direction, as well as the SMTP server direction.

The,  ,   ,  ,   ,  ,   ,  ,   , and    channel options are used to configure SASL use, specifically the use of the AUTH command, during the SMTP protocol by SMTP based channels such as TCP/IP channels. is the default, and means that SASL authentication will not be permitted nor attempted. It subsumes, which means that the SMTP server will not permit SASL authentication, and  , which means that the SMTP client will not attempt SASL authentication.

Specifying  will cause the SMTP server to permit clients to attempt to use SASL authentication. Specifying  will cause the SMTP server to insist that clients use SASL authentication: the SMTP server will not accept messages unless the remote client successfully authenticates. Unless authentication has been performed, the SMTP server will issue an error to any attempted EXPN: command of: 530 5.7.0 Authentication required prior to EXPAND while any attempted MAIL FROM: command will receive an error of: 520 5.7.0 Authentication required prior to MAIL/SAML/SEND/SOML Note that the authentication code performs various checks on the user account when attempting to authenticate, as when a client attempts to authenticate to the MTA&#x27;s SMTP server. This may result in authentication errors being returned to the SMTP server, which will in  turn issue an SMTP error back in response to the SMTP AUTH attempt. Some errors of note are discussed in Authentication errors and resultant SMTP errors.

New in Messaging Server 7.0 update 1 (Messaging Server 7.0-3.01) is support for limited SASL capabilities in the MTA&#x27;s SMTP client. Thus it is new in Messaging Server 7.0 update 1 that the (previously existing but not meaningful) keywords ,    have meaning, and the (previously existing  but now with enhanced meaning)  ,   , and   channel options truly affect  SMTP client operation. SASL authentication will be attempted by the SMTP/LMTP client if the ,   ,  , or    channel options are set---and must succeed in  order for message transmission if   or    is set. The PLAIN and EXTERNAL SASL mechanisms are currently supported. In legacy configuration, the  AUTH_PASSWORD and AUTH_USERNAME TCP/IP-channel-specific options  provide the credentials for the plain mechanism and  the   EXTERNAL_IDENTITY TCP/IP-channel-specific option provides the  identity string  for SASL EXTERNAL. (EXTERNAL_IDENTITY can be set to the empty string to enable SASL EXTERNAL without an identity string.)  In Unified Configuration, those TCP/IP-channel-specific options have been replaced by the  ,  , and   channel options.

Normal configuration includes setting  on the    channel and    on the    channel. As of Messaging Server 7.0u1,  is placed also on  the    channel definition. Additional discussion of normal configuration can also be found in Blocking SMTP relaying.

New in MS 6.2 is the  channel option, applicable to source channels. It takes a (required) integer argument, specifying an upper limit on the number of bad (failed) SMTP AUTH attempts that will be permitted during a single SMTP session (connection). The default is 3. (Note that this default of 3 complies with the recommendation in RFC 4954 that servers permit at least 3 authentication attempts prior to disconnecting due to failed attempts.) Once a client&#x27;s unsuccessful SMTP AUTH attempts reaches the specified number, the SMTP server will close the connection after rejecting the SMTP AUTH attempt, including in the SMTP AUTH rejection error the additional text: " ".

See also the   channel option, to cause source channel "switching" based upon successful client authentication. And see also the  and   channel options for control of the handling of any MAIL FROM AUTH parameter value. And see also the  channel option for some options on propagating SMTP AUTH information into message headers.

Note that client configuration may be required in order to get clients to make use of the MTA&#x27;s SMTP AUTH support (that is, to get clients to attempt to authenticate). For instance, in order for Messenger Express (Webmail) and Communications Express (UWC) to use SMTP AUTH (SASL), one must set the  and   MSHTTP options in Unified Configuration (or the   and      http parameters in legacy configuration)   to the user ID (and corresponding password) of a store administrator (a user who exists in the list in the   Message Store option in Unified Configuration, or in legacy configuration the   list---often  for instance, a user id of  ). (This will cause the mshttpd server to use the specified credentials to "vouch" for the identity of the sending user---who in turn has already had to login to mshttpd.)

Note that the   MTA option, if set to a value greater than , will restrict the user of plaintext passwords for authentication unless a security layer (SSL or TLS) is activated; see  TLS and SASL channel options and  Password and TLS MTA options for further discussion of SSL/TLS configuration for the MTA.

See also:
 * saslpassauth Option
 * sasltrustauth Option
 * saslswitchchannel Option
 * smtpauthuser Option
 * smtpauthpassword Option
 * plaintextmincipher Option
 * admins Store Option
 * Typical TCPIP channels and servers
 * Blocking SMTP relaying
 * authrewrite Option
 * Authentication errors and resultant SMTP errors
 * AUTH_PASSWORD and AUTH_USERNAME and EXTERNAL_IDENTITY
 * authpassword Option
 * authusername Option
 * externalidentity Option
 * SMTP and LMTP protocol channel options
 * Password and TLS MTA options
 * TLS and SASL channel options
 * Channel options