Re: STS causes mail to be deferred

Liste des GroupesRevenir à cm sendmail 
Sujet : Re: STS causes mail to be deferred
De : bjorn (at) *nospam* mork.no (Bjørn Mork)
Groupes : comp.mail.sendmail
Date : 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.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

Date Sujet#  Auteur
27 Dec 24 * STS causes mail to be deferred8Marco Moock
27 Dec 24 `* Re: STS causes mail to be deferred7Claus Aßmann
27 Dec 24  `* Re: STS causes mail to be deferred6Marco Moock
27 Dec 24   `* Re: STS causes mail to be deferred5Claus Aßmann
27 Dec 24    `* Re: STS causes mail to be deferred4Marco Moock
28 Dec 24     `* Re: STS causes mail to be deferred3Claus Aßmann
28 Dec 24      +- Re: STS causes mail to be deferred1Marco Moock
28 Dec 24      `- Re: STS causes mail to be deferred1Bjørn Mork

Haut de la page

Les messages affichés proviennent d'usenet.

NewsPortal