STS causes mail to be deferred

[Marco Moock]

Hello!

I am using 8.18.1-6~bpo12+1, openssl 3.0.15-1~deb12u1 and
postfix-mta-sts-resolver 1.1.2-1.1

I see that some mail is being deferred to MS and Gmail. If I disable
sts, the mail goes out.

Running /var/spool/mqueue/4BQ7S9xS386605 (sequence 2 of 2)
<itex-***@microsoft.com>... Connecting to
microsoft-com.mail.protection.outlook.com. via esmtp... 220
BL6PEPF0002256F.mail.protection.outlook.com Microsoft ESMTP MAIL
Service ready at Thu, 26 Dec 2024 20:37:06 +0000 [08DD2281F2EBE627]

EHLO srv1.dorfdsl.de

250-BL6PEPF0002256F.mail.protection.outlook.com Hello
[2a01:170:118f:3::22] 250-SIZE 157286400
250-PIPELINING
250-DSN
250-ENHANCEDSTATUSCODES
250-STARTTLS
250-8BITMIME
250-BINARYMIME
250-CHUNKING
250 SMTPUTF8

STARTTLS

220 2.0.0 SMTP server ready

QUIT

221 2.0.0 Service closing transmission channel
<itex-***@microsoft.com>... Deferred: 403 4.7.0 authentication failed
Closing connection to microsoft-com.mail.protection.outlook.com.

I would now like to diagnose that further and find out where the
problem is.

I assume the problem is related to the TLS validation. MS has an STS
policy and the check failed according to sendmail.

STARTTLS=client, relay=microsoft-com.mail.protection.outlook.com.,
version=TLSv1.3, verify=FAIL, cipher=TLS_AES_256_GCM_SHA384,
bits=256/256

openssl verify looks ok:

openssl s_client -connect microsoft-com.mail.protection.outlook.com:25
-starttls smtp | openssl x509 -in /dev/stdin -text

depth=2 C = US, O = DigiCert Inc, OU
= www.digicert.com, CN = DigiCert Global Root CA verify return:1
depth=1 C = US, O = DigiCert Inc, CN = DigiCert Cloud Services CA-1
verify return:1
depth=0 C = US, ST = Washington, L = Redmond, O = Microsoft
Corporation, CN = mail.protection.outlook.com verify return:1

[Other output omitted]

I now did further tests with MS:

Dec 27 17:19:09 srv1 sm-mta[405139]: tls_clt_features=sts=secure;servername=hostname, relay=microsoft-com.mail.protection.outlook.com [IPv6:2a01:111:f403:f804:0:0:0:0]
Dec 27 17:19:10 srv1 sm-mta[405139]: STARTTLS=client, relay=microsoft-com.mail.protection.outlook.com., version=TLSv1.3, verify=FAIL, cipher=TLS_AES_256_GCM_SHA384, bits=256/256
Dec 27 17:19:10 srv1 sm-mta[405139]: ruleset=tls_server, arg1=FAIL, relay=microsoft-com.mail.protection.outlook.com, reject=403 4.7.0 authentication failed
Dec 27 17:19:10 srv1 sm-mta[405139]: STARTTLS=read: error:0A000126:SSL routines::unexpected eof while reading:../ssl/record/rec_layer_s3.c:322:
Dec 27 17:19:10 srv1 sm-mta[405139]: STARTTLS: read error=generic SSL error (-1), errno=9, get_error=error:00000000:lib(0)::reason(0), retry=99, ssl_err=1
Dec 27 17:19:10 srv1 sm-mta[405139]: 4BRGJ8lb405137:
to=<***@microsoft.com>, delay=00:00:02, xdelay=00:00:01,
mailer=esmtp, pri=30354, relay=microsoft-com.mail...ction.outlook.com.
[IPv6:2a01:111:f403:f804:0:0:0:0], dsn=4.7.0, stat=Deferred: 403 4.7.0
authentication failed


Is that an issue with sendmail, openssl, the certificate or at MS?
I am aware of <vfr1qk$vd4$***@news.misty.com>, but according to Bjørn,
this may be a different issue.
I haven't applied the patch to my system yet.

[Claus Aßmann]

Post by Marco Moock
I see that some mail is being deferred to MS and Gmail. If I disable
sts, the mail goes out.

What is logged in that case?

[Marco Moock]

Post by Claus Aßmann

Post by Marco Moock
I see that some mail is being deferred to MS and Gmail. If I disable
sts, the mail goes out.

What is logged in that case?

E.g.

***@srv1:~# journalctl -S 2024-12-24 -t sm-mta -t sendmail |grep 389237
Dec 26 13:02:01 srv1 sm-mta[389237]: STARTTLS=client, relay=microsoft-com.mail.protection.outlook.com., version=TLSv1.3, verify=FAIL, cipher=TLS_AES_256_GCM_SHA384, bits=256/256
Dec 26 13:02:01 srv1 sm-mta[389237]: ruleset=tls_server, arg1=FAIL, relay=microsoft-com.mail.protection.outlook.com, reject=403 4.7.0 authentication failed
Dec 26 13:02:01 srv1 sm-mta[389237]: STARTTLS: read error=generic SSL error (-1), errno=9, get_error=error:0A000126:SSL routines::unexpected eof while reading, retry=99, ssl_err=1
Dec 26 13:02:01 srv1 sm-mta[389237]: 4BQ7S9xS386605: to=<itex-***@microsoft.com>, delay=04:33:50, xdelay=00:00:01, mailer=esmtp, pri=2551890, relay=microsoft-com.mail...ction.outlook.com. [IPv6:2a01:111:f403:f911:0:0:0:1], dsn=4.7.0, stat=Deferred: 403 4.7.0 authentication failed
***@srv1:~#

I can connect via openssl manually.

[Claus Aßmann]

Post by Marco Moock

Post by Claus Aßmann

Post by Marco Moock
If I disable
sts, the mail goes out.

What is logged in that case?

mailer=esmtp, pri=2551890, relay=microsoft-com.mail...ction.outlook.com.
[IPv6:2a01:111:f403:f911:0:0:0:1], dsn=4.7.0, stat=Deferred: 403 4.7.0
authentication failed

That doesn't look like "the mail goes out."

[Marco Moock]

Post by Claus Aßmann

Post by Marco Moock

Post by Claus Aßmann

Post by Marco Moock
If I disable
sts, the mail goes out.

What is logged in that case?

mailer=esmtp, pri=2551890,
relay=microsoft-com.mail...ction.outlook.com.
[IPv6:2a01:111:f403:f911:0:0:0:1], dsn=4.7.0, stat=Deferred: 403
4.7.0 authentication failed

That doesn't look like "the mail goes out."

Dec 26 21:39:18 srv1 sendmail[394144]: STARTTLS=client, relay=microsoft-com.mail.protection.outlook.com., version=TLSv1.3, verify=FAIL, cipher=TLS_AES_256_GCM_SHA384, bits=256/256
Dec 26 21:39:20 srv1 sendmail[394144]: 4BQ7S9xS386605: to=<itex-***@microsoft.com>, delay=13:11:09, xdelay=00:00:03, mailer=esmtp, pri=7501890, relay=microsoft-com.mail...ction.outlook.com. [IPv6:2a01:111:f403:f905:0:0:0:0], dsn=2.6.0, stat=Sent (<microsoft.com-***@dorfdsl.de> [InternalId=13683765809078, Hostname=DM6PR21MB1353.namprd21.prod.outlook.com] 11990 bytes in 0.043, 269.832 KB/sec Queued mail for delivery)

This happened after I disabled sts.

[Claus Aßmann]

Post by Marco Moock
Dec 26 21:39:18 srv1 sendmail[394144]: STARTTLS=client,
relay=microsoft-com.mail.protection.outlook.com., version=TLSv1.3,
verify=FAIL, cipher=TLS_AES_256_GCM_SHA384, bits=256/256

^^^^^^^^^^^

Post by Marco Moock
mailer=esmtp, pri=7501890, relay=microsoft-com.mail...ction.outlook.com.
[IPv6:2a01:111:f403:f905:0:0:0:0], dsn=2.6.0, stat=Sent
This happened after I disabled sts.

and if you enable STS mail cannot be sent because the server cert
cannot be verified.
sendmail works as it should.

Now you need to fix your CACert* settings -- check what openssl
uses in case it is able to verify the server.

BTW: doesn't M$ support DANE by now?

[Marco Moock]

Post by Claus Aßmann
Now you need to fix your CACert* settings -- check what openssl
uses in case it is able to verify the server.

That pointed to the letsencrypt stuff and didn't include any other CAs
I now changed CACertPath to /etc/ssl/certs and now verification works
as intended. I dunno why I set that to the /etc/letsencrypt/live
folder in the past.

I now get the SAN error which is already discussed in the other thread.

Post by Claus Aßmann
BTW: doesn't M$ support DANE by now?

They support to check it in exchange, but for microsoft.com, no DNS
record exists yet.

[Bjørn Mork]

Claus Aßmann

Post by Claus Aßmann
and if you enable STS mail cannot be sent because the server cert
cannot be verified.
sendmail works as it should.
Now you need to fix your CACert* settings -- check what openssl
uses in case it is able to verify the server.

Yuck. Made me re-read RFC8461 to see what it actually says about CAs.

"Not much" seems to be the answer...

Quoting the complete
https://datatracker.ietf.org/doc/html/rfc8461#section-4.2
since it is ubelievably brief:

The certificate presented by the receiving MTA MUST not be expired
and MUST chain to a root CA that is trusted by the Sending MTA. The
certificate MUST have a subject alternative name (SAN) [RFC5280] with
a DNS-ID [RFC6125] matching the hostname, per the rules given in
[RFC6125]. The MX's certificate MAY also be checked for revocation
via OCSP [RFC6960], CRLs [RFC6818], or some other mechanism.

I believe the expression "a root CA that is trusted by the Sending MTA"
is a bug in the spec. There is exactly no way for the receiving MTA to
know which CAs are trusted by the sending MTA. And this must also be
known in advance. For *any* sending MTA in the world. That is
obviously an impossible requirement.

Section 3.3 "HTTPS Policy Fetching" is slightly more specific wrt the
certificate for the https policy host:

It is expected that Sending MTAs use a set of trusted CAs
similar to those in widely deployed web browsers and operating
systems.

So we could assume that the Sending MTA will use the same list for both
https and smtp starttls validation. But I believe this requirement
should be way more explicit wrt the starttls CA list. And the way it is
specified makes it a moving target. This should have been made an IANA
registry. I guess that's out of the quetion for political/financial
reasons.

Better implement DANE if you can. Unfortunately there are still some
TLDs without DNSSEC support, and I happen to receive mail in one of
those (.im).

MTA-STS validating sending MTAs should keep their CA database in sync
with the "Server Authentication (SSL/TLS )Root Certificates" list on
https://www.ccadb.org/resources


Bjørn