SMTP Authentication

The macros ${auth_authen}, ${auth_author}, and ${auth_type} can be used in anti-relay rulesets to allow relaying for those users that authenticated themselves. A very simple example is:

SLocal_check_rcpt
R$*		$: $&{auth_type}
R$+		$# OK

which checks whether a user has successfully authenticated using any available mechanism. Depending on the setup of the CYRUS SASL library, more sophisticated rulesets might be required, e.g.,

SLocal_check_rcpt
R$*		$: $&{auth_type} $| $&{auth_authen}
RDIGEST-MD5 $| $+@$=w	$# OK

to allow relaying for users that authenticated using DIGEST-MD5 and have an identity in the local domains.

The ruleset trust_auth is used to determine whether a given AUTH= parameter (that is passed to this ruleset) should be trusted. This ruleset may make use of the other ${auth_*} macros. Only if the ruleset resolves to the error mailer, the AUTH= parameter is not trusted. A user supplied ruleset Local_trust_auth can be written to modify the default behavior, which only trust the AUTH= parameter if it is identical to the authenticated user.

  Per default, relaying is allowed for any user who authenticated via a "trusted" mechanism, i.e., one that is defined via TRUST_AUTH_MECH(`list of mechanisms') For example:

If the selected mechanism provides a security layer the number of bits used for the key of the symmetric cipher is stored in the macro ${auth_ssf}.

If sendmail acts as client, it needs some information how to authenticate against another MTA. This information can be provided by the ruleset authinfo or by the option DefaultAuthInfo. The authinfo ruleset looks up {server_name} using the tag AuthInfo: in the access map. If no entry is found, {server_addr} is looked up in the same way and finally just the tag AuthInfo: to provide default values.

Notice: the default configuration file causes the option DefaultAuthInfo to fail since the ruleset authinfo is in the .cf file. If you really want to use DefaultAuthInfo (it is deprecated) then you have to remove the ruleset.

The RHS for an AuthInfo: entry in the access map should consists of a list of tokens, each of which has the form: "TDstring" (including the quotes). T is a tag which describes the item, D is a delimiter, either ':' for simple text or '=' for a base64 encoded string. Valid values for the tag are:

U	user (authorization) id
I	authentication id
P	password
R	realm
M	list of mechanisms delimited by spaces

Example entries are:

User or authentication id must exist as well as the password. All other entries have default values. If one of user or authentication id is missing, the existing value is used for the missing item. If "R:" is not specified, realm defaults to $j. The list of mechanisms defaults to those specified by AuthMechanisms.

Since this map contains sensitive information, either the access map must be unreadable by everyone but root (or the trusted user) or FEATURE(`authinfo') must be used which provides a separate map. Notice: It is not checked whether the map is actually group/world-unreadable, this is left to the user.