fallback to unencrypted method if TLS fails, 403 4.7.0 TLS handshake failed

[marcus....@gmail.com]

Hi,

running sendmail 8.14.4 on Ubuntu 12.04.05 TLS (upgrades are up-to-date) I get a "403 4.7.0 TLS handshake failed" error for outgoing emails with a handful different servers from time to time:

-------
Jul 21 20:16:49 mail sm-mta[1918]: ruleset=tls_server, arg1=SOFTWARE,
relay=smtp.example.org, reject=403 4.7.0 TLS handshake failed.
Jul 21 20:16:49 mail sm-mta[1918]: t6KEqCVx008672:
to=<postm...@example.org>, delay=1+03:24:37, xdelay=00:00:03,
mailer=esmtp, pri=15132699, relay=smtp.example.org. [xx.xx.xx.xx],
dsn=4.0.0, stat=Deferred: 403 4.7.0 TLS handshake failed.
-------

As a workaround I set "Try_TLS:smtp.example.org NO" entries to /etc/mail/access, but I'm looking for a more general configuration to fallback to unencrypted sending if TLS fails with a receiving server. Any ideas?

Cheers
Marcus

[marcus....@gmail.com]

Sorry, didn't seen the post "dh key too small error" ... so the only workaround is to mark broken servers to access in set Try_TLS, right?

Cheers
Marcus

[Claus Aßmann]

Marcus wrote:
> Sorry, didn't seen the post "dh key too small error" ... so the only workaround is to mark
> broken servers to access in set Try_TLS, right?

I've posted a link to a feature (patch) in that thread, give it a try.
Here it is again:
http://www.sendmail.org/%7Eca/email/patches/tls_failures.p1

and the desciption:

tls_failures If enabled, the MTA will stop using STARTTLS on
outbound connections after a certain number of previous
failures with either PROTOCOL or SOFTWARE error. An
optional numeric value indicates the number of attempts
after which the MTA will give up trying STARTTLS:

FEATURE(`tls_failures', `8')

Once ${ntries} exceeds the value of 8, and if the
previous delivery ended up with a PROTOCOL or
SOFTWARE TLS errors, then the MTA will not use
STARTTLS. Default value for the parameter is 5.

Note: if you enforce TLS for the recipient or
destination then it is likely the message will
never be delivered as the TLS enforced criterias
are unlikely to be ever verified.


--
Note: please read the netiquette before posting. I will almost never
reply to top-postings which include a full copy of the previous
article(s) at the end because it's annoying, shows that the poster
is too lazy to trim his article, and it's wasting the time of all readers.

[Kees Theunissen]

Claus Aßmann wrote:
> Marcus wrote:
>> Sorry, didn't seen the post "dh key too small error" ... so the only workaround is to mark
>> broken servers to access in set Try_TLS, right?
>
> I've posted a link to a feature (patch) in that thread, give it a try.
> Here it is again:
> http://www.sendmail.org/%7Eca/email/patches/tls_failures.p1
>
> and the desciption:
>
> tls_failures If enabled, the MTA will stop using STARTTLS on
> outbound connections after a certain number of previous
> failures with either PROTOCOL or SOFTWARE error. An
> optional numeric value indicates the number of attempts
> after which the MTA will give up trying STARTTLS:
>
> FEATURE(`tls_failures', `8')
>
> Once ${ntries} exceeds the value of 8, and if the
> previous delivery ended up with a PROTOCOL or
> SOFTWARE TLS errors, then the MTA will not use
> STARTTLS. Default value for the parameter is 5.
>
> Note: if you enforce TLS for the recipient or
> destination then it is likely the message will
> never be delivered as the TLS enforced criterias
> are unlikely to be ever verified.

Thank you Claus for this patch.
I used your idea and code to implement this functionality on a
debian 8.2 (jessie) system with stock debian sendmail packages
(version 8.14.4-8) installed.

Putting the following code at the very end of sendmail.mc and
rebuilding sendmail.cf does the job.



divert(-1)
# Stop using STARTTLS on outbound connections after a certain number of
# previous failures with either PROTOCOL or SOFTWARE error.
# This code is based on a patch from Claus Assmann against
# sendmail-8.15.2 that implements a new feature "tls_failures".
# See: http://http://www.sendmail.org/~ca/email/patches/tls_failures.p1
#
# The following copyright notice applies to the borrowed idea and code:
#
# Copyright (c) 2015 Proofpoint, Inc. and its suppliers.
# All rights reserved.
#
# By using this file, you agree to the terms and conditions set
# forth in the LICENSE file which can be found at the top level of
# the sendmail distribution.
#
define(`_NEED_MACRO_MAP_', `1')dnl
define(`TLS_FAILURES_CNT',`3')dnl # Stop using STARTTLS after 3 failures
LOCAL_CONFIG
C{persistentMacros}{saved_verify}
LOCAL_TRY_TLS
R$* $: $&{saved_verify} $| $(arith l $@ eval(TLS_FAILURES_CNT - 1) $@ $&{ntries} $)
RSOFTWARE $| TRUE $#error $@ 5.7.1 $: "550 do not try TLS with " $&{server_name} " ["$&{server_addr}"] due to previous verify=SOFTWARE errors"
RPROTOCOL $| TRUE $#error $@ 5.7.1 $: "550 do not try TLS with " $&{server_name} " ["$&{server_addr}"] due to previous verify=PROTOCOL errors"
R$* $@ OK
LOCAL_TLS_SERVER
R$* $: $(macro {saved_verify} $@ $1 $) $1
R$* $@ OK



Regards,

Kees.

--
Kees Theunissen.

[Claus Aßmann]

Kees Theunissen wrote:

> I used your idea and code to implement this functionality on a

It was not my idea... (AFAICT it's from Christophe Wolfhugel).

What's "mine" can be found in the latest 8.16 snapshot.

To automatically handle TLS interoperability problems for outgoing
mail, sendmail can now immediately try a connection again
without STARTTLS after a TLS handshake failure.
This can be configured globally via the option
TLSFallbacktoClear or per session via the 'C' flag
of tls_clt_features.
This also adds the new value "CLEAR" for the macro
{verify}: STARTTLS has been disabled internally for
a clear text delivery attempt.


The cf hack has problems with multiple RCPTs for different
destinations in a single transaction.

BTW: It's much better to simply disable DH ciphers -- see the current
discussion about cracking some DH primes... -- that will avoid those
"dh key too small" interop problems too.