A server offers authentication by presenting the AUTH keyword to the connecting site, following that with the types of authentication mechanisms supported:

250-host.domain Hello some.domain, pleased to meet you
250-ENHANCEDSTATUSCODES
250-PIPELINING
250-8BITMIME
250-SIZE
250-DSN
250-ETRN
250-AUTH DIGEST-MD5 CRAM-MD5               note this line
250-DELIVERBY
250 HELP

If the connecting site wishes to authenticate itself, it replies with an AUTH command indicating the mechanism preferred:

AUTH CRAM-MD5                                                  client sends

Once it is selected, that mechanism is placed into this ${auth_type} macro. If no mechanism is selected (none is offered, or none is accepted), or if the act of authentication fails, ${auth_type} becomes undefined (NULL).

If the authentication is accepted, the Received: header is updated to reflect that:

HReceived: $?sfrom $s $.$?_($?s$|from $.$_)
        $.$?{auth_type}(authenticated$?{auth_ssf} bits=${auth_ssf}$.)
        $.by $j ($v/$Z)$?r with $r$. id $i$?{tls_version}
        (version=${tls_version} cipher=${cipher} bits=${cipher_bits} 
verify=${verify})$.$?u
        for $u; $|;
        $.$b

Here, if the connection were authenticated, the second line of the Received: header would look like this:

(authenticated bits=bits)
(authenticated)                    if no encryption negotiated

The ${auth_type} macro is useful for adding your own rules to policy rule sets, such as to the Local_trust_auth rule set. Note that a $& prefix is necessary when you reference this macro in rules (that is, use $&{auth_type}, not ${auth_type}).

${auth_type} is transient. If defined in the configuration file or in the command line, that definition can be ignored by sendmail.