Sujet : Re: STS causes mail to be deferred
De : bjorn (at) *nospam* mork.no (Bjørn Mork)
Groupes : comp.mail.sendmailDate : 28. Dec 2024, 13:41:57
Autres entêtes
Organisation : m
Message-ID : <87bjwwx9m2.fsf@miraculix.mork.no>
References : 1 2 3 4 5
User-Agent : Gnus/5.13 (Gnus v5.13) Emacs/28.2 (gnu/linux)
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.2since 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/resourcesBjørn