Centos – How to change sendmail fallback behavior if TLS handshake fails

centosemailsendmailsmtptls

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?

Best Answer

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.

Related Topic