1. Forum
  2. Usenet
  3. COMP.MAIL.SENDMAIL

  • STS causes mail to be deferred

    From Marco Moock@21:1/5 to All on Fri Dec 27 17:26:22 2024
    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) <[email protected]>... 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
    <[email protected]>... 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=<[email protected]>, 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$[email protected]>, 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 [email protected]

    --- SoupGate-Win32 v1.05
    * Origin: fsxNet Usenet Gateway (21:1/5)
  • From Claus =?iso-8859-1?Q?A=DFmann?= @21:1/5 to Marco Moock on Fri Dec 27 13:29:25 2024
    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?

    --- SoupGate-Win32 v1.05
    * Origin: fsxNet Usenet Gateway (21:1/5)
  • From Claus =?iso-8859-1?Q?A=DFmann?= @21:1/5 to Marco Moock on Fri Dec 27 15:12:48 2024
    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=<[email protected]>, 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.

    --- SoupGate-Win32 v1.05
    * Origin: fsxNet Usenet Gateway (21:1/5)
  • From Marco Moock@21:1/5 to All on Fri Dec 27 20:38:57 2024
    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=<[email protected]>, 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 [email protected]

    --- SoupGate-Win32 v1.05
    * Origin: fsxNet Usenet Gateway (21:1/5)
  • From Marco Moock@21:1/5 to All on Fri Dec 27 21:20:33 2024
    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=<[email protected]>, 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=<[email protected]>, 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 (<
    [email protected]> [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 [email protected]

    --- SoupGate-Win32 v1.05
    * Origin: fsxNet Usenet Gateway (21:1/5)
  • From Claus =?iso-8859-1?Q?A=DFmann?= @21:1/5 to Marco Moock on Sat Dec 28 01:08:46 2024
    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=<[email protected]>, 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?

    --- SoupGate-Win32 v1.05
    * Origin: fsxNet Usenet Gateway (21:1/5)
  • From Marco Moock@21:1/5 to All on Sat Dec 28 12:27:47 2024
    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 [email protected]

    --- SoupGate-Win32 v1.05
    * Origin: fsxNet Usenet Gateway (21:1/5)
  • From =?utf-8?Q?Bj=C3=B8rn_Mork?=@21:1/5 to All on Sat Dec 28 13:41:57 2024
    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

    --- SoupGate-Win32 v1.05
    * Origin: fsxNet Usenet Gateway (21:1/5)