How to change sendmail fallback behavior if TLS handshake fails?

I have a CentOS 5.x server running sendmail that is failing to negotiate TLS with SOME various recipient servers. I'm looking into it.

In the meantime though, I've noticed that sendmail will NOT bother falling back to use standard unencrypted delivery methods if TLS handshake errors occur. Is this normal behavior?

I would expect this logic to be in place if (and only if) I explicitly required it for domains. For example if I added TLS_SRV options in /etc/mail/access. In this case, I don't. In essence, Sendmail is only running "opportunistic TLS".

All of the information I’ve come across thus far suggests that this issue is expected behavior and is hard-coded…

As per http://www.sendmail.org/m4/starttls.html#disable_starttls :

By default STARTTLS is used whenever possible. However, there are some broken MTAs that don't properly implement STARTTLS. To be able to send to (or receive from) those MTAs, the ruleset try_tls (srv_features) can be used that work together with the access map. Entries for the access map must be tagged with Try_TLS (Srv_Features) and refer to the hostname or IP address of the connecting system.

As per http://etutorials.org/Server+Administration/Sendmail/Part+II+Administration/Chapter+10.+Maintain+Security+with+sendmail/10.10+STARTTLS/:

If the access database is not used, the connection is allowed in all cases, both inbound and outbound, unless the value in ${verify} is SOFTWARE, in which instance the connection is not allowed.

Both of these blurbs suggest that the try_tls feature is the only option for skipping TLS when the other side claims to support it. I understand that this is an option but it's cumbersome because it means I'd need to manually make exceptions anytime an outbound domain has trouble.

Is there any other way to have sendmail fallback?

Solution 1:

According to this thread, the fallback feature tls_failures was implemented in this patch. Apparently this will use plain text automatically after a certain number of TLS handshake failures.

Note: this patch is integrated in 8.16 (at least available as snapshot)

As of this post, 8.16 is not yet released, so for now you will have to use /etc/mail/access or /etc/mail/access_db as Seth suggested, and be sure to rebuild the .db using makemap hash /etc/mail/access < /etc/mail/access

As for security risks of using tls_failures globally; considering that this is opportunistic TLS to begin with, I think that refraining from using this new option would only help in some really fringe cases where the recipient mailserver is temporarily reconfigured and later corrected.

Solution 2:

You can disable TLS for certain hosts. For example:

# Try_TLS:gmail.com                     NO

I also point you to http://www.sendmail.org/m4/starttls.html

By default STARTTLS is used whenever possible. However, there are some broken MTAs that don't properly implement STARTTLS. To be able to send to (or receive from) those MTAs, the ruleset try_tls (srv_features) can be used that work together with the access map. Entries for the access map must be tagged with Try_TLS (Srv_Features) and refer to the hostname or IP address of the connecting system. A default case can be specified by using just the tag. For example, the following entries in the access map:

Try_TLS:broken.server   NO
Srv_Features:my.domain  v
Srv_Features:       V

will turn off STARTTLS when sending to broken.server (or any host in that domain), and request a client certificate during the TLS handshake only for hosts in my.domain. The valid entries on the RHS for Srv_Features are listed in the "Sendmail Installation and Operations Guide".