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-rua@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-rua@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=<ungueltig@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$1@news.misty.com>, but according to Bjørn,
this may be a different issue.
I haven't applied the patch to my system yet.

--
kind regards
Marco

Send spam to 1735245840muell@stinkedores.dorfdsl.de

Marco Moock wrote:

> 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?

On 27.12.2024 13:29 Uhr Claus Aßmann wrote:

> Marco Moock wrote:
>
> > 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.

root@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-rua@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
root@srv1:~#

I can connect via openssl manually.

--
kind regards
Marco

Send spam to 1735302565muell@stinkedores.dorfdsl.de

Marco Moock wrote:
> On 27.12.2024 13:29 Uhr Claus Aßmann wrote:

> > Marco Moock wrote:

> > > If I disable
> > > sts, the mail goes out.

> > What is logged in that case?

> to=<itex-rua@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

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

--
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.

On 27.12.2024 15:12 Uhr Claus Aßmann wrote:

> Marco Moock wrote:
> > On 27.12.2024 13:29 Uhr Claus Aßmann wrote:
>
> > > Marco Moock wrote:
>
> > > > If I disable
> > > > sts, the mail goes out.
>
> > > What is logged in that case?
>
> > to=<itex-rua@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
>
> 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-rua@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-1735198089@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.

--
kind regards
Marco

Send spam to 1735308768muell@stinkedores.dorfdsl.de

Marco Moock wrote:

> 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
^^^^^^^^^^^

> to=<itex-rua@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

> 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?

On 28.12.2024 01:08 Uhr Claus Aßmann wrote:

> 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.

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

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

--
kind regards
Marco

Send spam to 1735344526muell@stinkedores.dorfdsl.de

Claus Aßmann
<INVALID_NO_CC_REMOVE_IF_YOU_DO_NOT_POST_ml+sendmail(-no-copies-please)@esmtp.org>
writes:

> 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