sendmail, 4th Edition

${auth_type}

---

Authentication mechanism used

V8.10 and above

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 .