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

  • Problem with FEATURE(`sts'): bogus "not listed in SANs" rejects

    From =?utf-8?Q?Bj=C3=B8rn_Mork?=@21:1/5 to All on Tue Oct 29 09:16:37 2024
    I have been testing out the MTA-STS support for a while, using the
    Debian sendmail package 8.17.1.9-2+deb12u2 with postfix-mta-sts-resolver
    to look up policies.

    This seemed to work pretty well, but yesterday I noticed a problem: Some
    emails were temporarily rejected with an unexpected "not listed in SANs" message. This was unexpexted because most of the affected emails were
    for MXes hosted by Microsoft and their "protection.outlook.com" service.

    Anonymzed example log lines:

    Oct 27 19:49:47 dilbert sm-mta[1589041]: 49N8ZWuJ1287620: ruleset=tls_rcpt, arg1=redacted@hotmail.com, relay=hotmail-com.olc.protection.outlook.com., reject=450 4.7.0 <redacted@hotmail.com>... hotmail-com.olc.protection.outlook.com not listed in SANs
    Oct 27 19:54:49 dilbert sm-mta[1589264]: 493ISGKc649896: ruleset=tls_rcpt, arg1=redacted.redacted@outlook.com, relay=outlook-com.olc.protection.outlook.com., reject=450 4.7.0 <redacted.redacted@outlook.com>... outlook-com.olc.protection.outlook.com not
    listed in SANs


    The smarthost handles only a very low volume, and most MXes don't have a MTA-STS policy obviously. But amond those few, there was also a similar
    reject for a non-Microsoft hosted MX:


    Oct 27 19:24:48 dilbert sm-mta[1587923]: 49JAD2Eb1019895: ruleset=tls_rcpt, arg1=redacted@01-mail.org, relay=mx.01-mail.net., reject=450 4.7.0 <redacted@01-mail.org>... mx.01-mail.net not listed in SANs


    There were also a few examples of MXes publishing a policy and still
    working fine. This included my own MX as well as Googles:

    alt1.gmail-smtp-in.l.google.com
    alt2.gmail-smtp-in.l.google.com
    alt3.gmail-smtp-in.l.google.com
    alt4.gmail-smtp-in.l.google.com
    gmail-smtp-in.l.google.com


    Looking at the certificates I see that the most obvious difference is
    the use of wildcard SANs. Both the certficate of my MX and Googles
    explicitly list all their names, using no wildcards at all:

    X509v3 Subject Alternative Name:
    DNS:canardo.dyn.mork.no, DNS:canardo.mork.no, DNS:imap.mork.no, DNS:mail.mork.no, DNS:smtp.mork.no


    X509v3 Subject Alternative Name:
    DNS:mx.google.com, DNS:smtp.google.com, DNS:aspmx.l.google.com, DNS:alt1.aspmx.l.google.com, DNS:alt2.aspmx.l.google.com, DNS:alt3.aspmx.l.google.com, DNS:alt4.aspmx.l.google.com, DNS:gmail-smtp-in.l.google.com, DNS:alt1.gmail-smtp-in.l.
    google.com, DNS:alt2.gmail-smtp-in.l.google.com, DNS:alt3.gmail-smtp-in.l.google.com, DNS:alt4.gmail-smtp-in.l.google.com, DNS:gmr-smtp-in.l.google.com, DNS:alt1.gmr-smtp-in.l.google.com, DNS:alt2.gmr-smtp-in.l.google.com, DNS:alt3.gmr-smtp-in.l.google.
    com, DNS:alt4.gmr-smtp-in.l.google.com, DNS:mx1.smtp.goog, DNS:mx2.smtp.goog, DNS:mx3.smtp.goog, DNS:mx4.smtp.goog, DNS:aspmx2.googlemail.com, DNS:aspmx3.googlemail.com, DNS:aspmx4.googlemail.com, DNS:aspmx5.googlemail.com, DNS:gmr-mx.google.com


    While both the failing MXes use certificates with multiple wildcard
    SANs:

    X509v3 Subject Alternative Name:
    DNS:mail.protection.outlook.com, DNS:*.mail.eo.outlook.com, DNS:*.mail.protection.outlook.com, DNS:mail.messaging.microsoft.com, DNS:outlook.com, DNS:*.olc.protection.outlook.com, DNS:*.pamx1.hotmail.com, DNS:*.mail.protection.outlook.de,
    DNS:*.mx.microsoft, DNS:*.k-v1.mx.microsoft, DNS:*.n-v1.mx.microsoft, DNS:*.q-v1.mx.microsoft, DNS:*.y-v1.mx.microsoft, DNS:*.d-v1.mx.microsoft, DNS:*.e-v1.mx.microsoft, DNS:*.a-v1.mx.microsoft, DNS:*.r-v1.mx.microsoft, DNS:*.w-v1.mx.microsoft, DNS:*.p-
    v1.mx.microsoft, DNS:*.x-v1.mx.microsoft, DNS:*.j-v1.mx.microsoft, DNS:*.s-v1.mx.microsoft, DNS:*.c-v1.mx.microsoft, DNS:*.b-v1.mx.microsoft, DNS:*.f-v1.mx.microsoft, DNS:*.i-v1.mx.microsoft, DNS:*.t-v1.mx.microsoft, DNS:*.m-v1.mx.microsoft, DNS:*.o-v1.
    mx.microsoft, DNS:*.g-v1.mx.microsoft, DNS:*.v-v1.mx.microsoft, DNS:*.h-v1.mx.microsoft, DNS:*.l-v1.mx.microsoft, DNS:*.u-v1.mx.microsoft

    X509v3 Subject Alternative Name:
    DNS:*.01-mail.com, DNS:*.01-mail.net, DNS:*.01-mail.org, DNS:01-mail.com, DNS:01-mail.net, DNS:01-mail.org


    It's dangerous to draw conclusions based on so few samples, but this is
    all I've got. Could there be a problem with FEATURE(`sts') related to
    wildcard SANs? Either wildcard SANs in general, or maybe just when
    there is more than one?

    I see that there is code in cf/m4/proto.m4 which is supposed to do
    wildcard matching, but I must admit that I am too clueless wrt m4 to
    understand if this should work with the certificate examples above:

    dnl check SAN for STS
    SSTS_SAN
    ifdef(`_STS_SAN', `dnl
    R$* $: $&{server_name}
    dnl exact match
    R$={cert_altnames} $@ ok
    # strip only one level (no recursion!)
    R$-.$+ $: $2
    dnl wildcard: *. or just .?
    R *.$={cert_altnames} $@ ok
    dnl R .$={cert_altnames} $@ ok
    dnl always temporary error? make it an option (of the feature)?
    R$* $#error $@ 4.7.0 $: 450 $&{server_name} not listed in SANs', `dnl')



    I have not yet verified this problem on 8.18, but AFAICS the code I am
    quoting above was introduced in 8.17.1 and has not been changed since.

    The getaltnames() function in sendmail/tls.c, populating the
    cert_altnames class has not been changed since it was introduced in
    8.16.0.48.

    Disabling the SAN test by doing

    FEATURE(`sts',,`NO_SAN_TST')

    is verified to "solve" the problem as expected. But obviously with the
    huge downside of not actually validating the MX name.



    Bjørn

    --- 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 Tue Oct 29 10:45:15 2024
    Noticed that getaltnames() can log the SANs as they are parsed, so I
    yanked up the log level and registered an outlook.com address to test
    against:

    2024-10-29T09:29:30.283537+00:00 dilbert sm-mta[1697002]: STARTTLS=client, init=1
    2024-10-29T09:29:30.283681+00:00 dilbert sm-mta[1697002]: engine=(null), path=(null), ispre=0, pre=0, initialized=0
    2024-10-29T09:29:30.356523+00:00 dilbert sm-mta[1697002]: tls_clt_features=sts=secure;servername=hostname, relay=outlook-com.olc.protection.outlook.com [52.101.40.30]
    2024-10-29T09:29:30.356694+00:00 dilbert sm-mta[1697002]: tls_clt_features=parsed, sts=secure, relay=outlook-com.olc.protection.outlook.com [52.101.40.30]
    2024-10-29T09:29:30.356941+00:00 dilbert sm-mta[1697002]: tls_clt_features=parsed, servername=hostname, relay=outlook-com.olc.protection.outlook.com [52.101.40.30]
    2024-10-29T09:29:30.510779+00:00 dilbert sm-mta[1697002]: STARTTLS=client, start=ok
    2024-10-29T09:29:30.511540+00:00 dilbert sm-mta[1697002]: STARTTLS=client, info: fds=9/4, err=2
    2024-10-29T09:29:30.668666+00:00 dilbert sm-mta[1697002]: STARTTLS=client, info: fds=9/4, err=2
    2024-10-29T09:29:30.836892+00:00 dilbert sm-mta[1697002]: STARTTLS: TLS cert verify: depth=0 /C=US/ST=Washington/L=Redmond/O=Microsoft Corporation/CN=mail.protection.outlook.com, state=1, reason=ok
    2024-10-29T09:29:30.841735+00:00 dilbert sm-mta[1697002]: STARTTLS=client, get_verify: 0 get_peer: 0x55e6b9c7f290
    2024-10-29T09:29:30.842307+00:00 dilbert sm-mta[1697002]: STARTTLS=client, relay=outlook-com.olc.protection.outlook.com., AltName=mail.protection.outlook.com
    2024-10-29T09:29:30.842615+00:00 dilbert sm-mta[1697002]: STARTTLS=client, relay=outlook-com.olc.protection.outlook.com., AltName=*.mail.eo.outlook.com
    2024-10-29T09:29:30.842825+00:00 dilbert sm-mta[1697002]: STARTTLS=client, relay=outlook-com.olc.protection.outlook.com., AltName=*.mail.protection.outlook.com
    2024-10-29T09:29:30.843017+00:00 dilbert sm-mta[1697002]: STARTTLS=client, relay=outlook-com.olc.protection.outlook.com., AltName=mail.messaging.microsoft.com
    2024-10-29T09:29:30.843226+00:00 dilbert sm-mta[1697002]: STARTTLS=client, relay=outlook-com.olc.protection.outlook.com., AltName=outlook.com
    2024-10-29T09:29:30.843430+00:00 dilbert sm-mta[1697002]: STARTTLS=client, relay=outlook-com.olc.protection.outlook.com., AltName=*.olc.protection.outlook.com
    2024-10-29T09:29:30.843659+00:00 dilbert sm-mta[1697002]: STARTTLS=client, relay=outlook-com.olc.protection.outlook.com., AltName=*.pamx1.hotmail.com
    2024-10-29T09:29:30.843864+00:00 dilbert sm-mta[1697002]: STARTTLS=client, relay=outlook-com.olc.protection.outlook.com., AltName=*.mail.protection.outlook.de
    2024-10-29T09:29:30.844063+00:00 dilbert sm-mta[1697002]: STARTTLS=client, relay=outlook-com.olc.protection.outlook.com., AltName=*.mx.microsoft
    2024-10-29T09:29:30.844125+00:00 dilbert sm-mta[1697002]: STARTTLS=client, relay=outlook-com.olc.protection.outlook.com., AltName=*.k-v1.mx.microsoft
    2024-10-29T09:29:30.844325+00:00 dilbert sm-mta[1697002]: STARTTLS=client, relay=outlook-com.olc.protection.outlook.com., AltName=*.n-v1.mx.microsoft
    2024-10-29T09:29:30.844424+00:00 dilbert sm-mta[1697002]: STARTTLS=client, relay=outlook-com.olc.protection.outlook.com., AltName=*.q-v1.mx.microsoft
    2024-10-29T09:29:30.844669+00:00 dilbert sm-mta[1697002]: STARTTLS=client, relay=outlook-com.olc.protection.outlook.com., AltName=*.y-v1.mx.microsoft
    2024-10-29T09:29:30.844778+00:00 dilbert sm-mta[1697002]: STARTTLS=client, relay=outlook-com.olc.protection.outlook.com., AltName=*.d-v1.mx.microsoft
    2024-10-29T09:29:30.844949+00:00 dilbert sm-mta[1697002]: STARTTLS=client, relay=outlook-com.olc.protection.outlook.com., AltName=*.e-v1.mx.microsoft
    2024-10-29T09:29:30.845107+00:00 dilbert sm-mta[1697002]: STARTTLS=client, relay=outlook-com.olc.protection.outlook.com., AltName=*.a-v1.mx.microsoft
    2024-10-29T09:29:30.845309+00:00 dilbert sm-mta[1697002]: STARTTLS=client, relay=outlook-com.olc.protection.outlook.com., AltName=*.r-v1.mx.microsoft
    2024-10-29T09:29:30.845370+00:00 dilbert sm-mta[1697002]: STARTTLS=client, relay=outlook-com.olc.protection.outlook.com., AltName=*.w-v1.mx.microsoft
    2024-10-29T09:29:30.845555+00:00 dilbert sm-mta[1697002]: STARTTLS=client, relay=outlook-com.olc.protection.outlook.com., AltName=*.p-v1.mx.microsoft
    2024-10-29T09:29:30.845606+00:00 dilbert sm-mta[1697002]: STARTTLS=client, relay=outlook-com.olc.protection.outlook.com., AltName=*.x-v1.mx.microsoft
    2024-10-29T09:29:30.845794+00:00 dilbert sm-mta[1697002]: STARTTLS=client, relay=outlook-com.olc.protection.outlook.com., AltName=*.j-v1.mx.microsoft
    2024-10-29T09:29:30.845849+00:00 dilbert sm-mta[1697002]: STARTTLS=client, relay=outlook-com.olc.protection.outlook.com., AltName=*.s-v1.mx.microsoft
    2024-10-29T09:29:30.846090+00:00 dilbert sm-mta[1697002]: STARTTLS=client, relay=outlook-com.olc.protection.outlook.com., AltName=*.c-v1.mx.microsoft
    2024-10-29T09:29:30.846178+00:00 dilbert sm-mta[1697002]: STARTTLS=client, relay=outlook-com.olc.protection.outlook.com., AltName=*.b-v1.mx.microsoft
    2024-10-29T09:29:30.846382+00:00 dilbert sm-mta[1697002]: STARTTLS=client, relay=outlook-com.olc.protection.outlook.com., AltName=*.f-v1.mx.microsoft
    2024-10-29T09:29:30.846576+00:00 dilbert sm-mta[1697002]: STARTTLS=client, relay=outlook-com.olc.protection.outlook.com., AltName=*.i-v1.mx.microsoft
    2024-10-29T09:29:30.846664+00:00 dilbert sm-mta[1697002]: STARTTLS=client, relay=outlook-com.olc.protection.outlook.com., AltName=*.t-v1.mx.microsoft
    2024-10-29T09:29:30.846758+00:00 dilbert sm-mta[1697002]: STARTTLS=client, relay=outlook-com.olc.protection.outlook.com., AltName=*.m-v1.mx.microsoft
    2024-10-29T09:29:30.846853+00:00 dilbert sm-mta[1697002]: STARTTLS=client, relay=outlook-com.olc.protection.outlook.com., AltName=*.o-v1.mx.microsoft
    2024-10-29T09:29:30.846913+00:00 dilbert sm-mta[1697002]: STARTTLS=client, relay=outlook-com.olc.protection.outlook.com., AltName=*.g-v1.mx.microsoft
    2024-10-29T09:29:30.846973+00:00 dilbert sm-mta[1697002]: STARTTLS=client, relay=outlook-com.olc.protection.outlook.com., AltName=*.v-v1.mx.microsoft
    2024-10-29T09:29:30.847045+00:00 dilbert sm-mta[1697002]: STARTTLS=client, relay=outlook-com.olc.protection.outlook.com., AltName=*.h-v1.mx.microsoft
    2024-10-29T09:29:30.847123+00:00 dilbert sm-mta[1697002]: STARTTLS=client, relay=outlook-com.olc.protection.outlook.com., AltName=*.l-v1.mx.microsoft
    2024-10-29T09:29:30.847223+00:00 dilbert sm-mta[1697002]: STARTTLS=client, relay=outlook-com.olc.protection.outlook.com., AltName=*.u-v1.mx.microsoft
    2024-10-29T09:29:30.847297+00:00 dilbert sm-mta[1697002]: STARTTLS=client, relay=outlook-com.olc.protection.outlook.com., version=TLSv1.3, verify=OK, cipher=TLS_AES_256_GCM_SHA384, bits=256/256
    2024-10-29T09:29:30.847368+00:00 dilbert sm-mta[1697002]: STARTTLS=client, cert-subject=/C=US/ST=Washington/L=Redmond/O=Microsoft+20Corporation/CN=mail.protection.outlook.com, cert-issuer=/C=US/O=DigiCert+20Inc/CN=DigiCert+20Cloud+20Services+20CA-1,
    verifymsg=ok
    2024-10-29T09:29:30.847428+00:00 dilbert sm-mta[1697002]: STARTTLS=read, info: fds=9/4, err=2
    2024-10-29T09:29:30.996568+00:00 dilbert sm-mta[1697002]: STARTTLS=read, info: fds=9/4, err=2
    2024-10-29T09:29:31.193337+00:00 dilbert sm-mta[1697002]: STARTTLS=read, info: fds=9/4, err=2
    2024-10-29T09:29:31.350226+00:00 dilbert sm-mta[1697002]: 49T9TSAv1697000: --- 450 4.7.0 <du1874@outlook.com>... outlook-com.olc.protection.outlook.com not listed in SANs (hold)
    2024-10-29T09:29:31.350353+00:00 dilbert sm-mta[1697002]: 49T9TSAv1697000: ruleset=tls_rcpt, arg1=du1874@outlook.com, relay=outlook-com.olc.protection.outlook.com., reject=450 4.7.0 <du1874@outlook.com>... outlook-com.olc.protection.outlook.com not
    listed in SANs
    2024-10-29T09:29:31.350462+00:00 dilbert sm-mta[1697002]: 49T9TSAv1697000: --- 050 <du1874@outlook.com>... Deferred
    2024-10-29T09:29:31.350545+00:00 dilbert sm-mta[1697002]: 49T9TSAv1697000: to=<du1874@outlook.com>, delay=00:00:02, xdelay=00:00:02, mailer=esmtp, pri=31187, relay=outlook-com.olc.protection.outlook.com. [52.101.40.30], dsn=4.2.0, stat=Deferred
    2024-10-29T09:29:31.350631+00:00 dilbert sm-mta[1697002]: STARTTLS=read, info: fds=9/4, err=2
    2024-10-29T09:29:31.508147+00:00 dilbert sm-mta[1697002]: NOQUEUE: --- 050 Closing connection to outlook-com.olc.protection.outlook.com.
    2024-10-29T09:29:31.508386+00:00 dilbert sm-mta[1697002]: STARTTLS=read, info: fds=9/4, err=2
    2024-10-29T09:29:31.662726+00:00 dilbert sm-mta[1697002]: STARTTLS=client, SSL_shutdown failed: -1


    The SAN parsing looks fine to me, so I believe this points to a bug in
    the m4 matching.

    For reference, this is a similar test log against google:

    2024-10-29T09:29:57.965992+00:00 dilbert sm-mta[1697008]: STARTTLS=client, init=1
    2024-10-29T09:29:57.966067+00:00 dilbert sm-mta[1697008]: engine=(null), path=(null), ispre=0, pre=0, initialized=0
    2024-10-29T09:29:57.970146+00:00 dilbert sm-mta[1697008]: tls_clt_features=sts=secure;servername=hostname, relay=gmail-smtp-in.l.google.com [IPv6:2a00:1450:4010:c05:0:0:0:1b]
    2024-10-29T09:29:57.970286+00:00 dilbert sm-mta[1697008]: tls_clt_features=parsed, sts=secure, relay=gmail-smtp-in.l.google.com [IPv6:2a00:1450:4010:c05:0:0:0:1b]
    2024-10-29T09:29:57.970406+00:00 dilbert sm-mta[1697008]: tls_clt_features=parsed, servername=hostname, relay=gmail-smtp-in.l.google.com [IPv6:2a00:1450:4010:c05:0:0:0:1b]
    2024-10-29T09:29:57.974133+00:00 dilbert sm-mta[1697008]: STARTTLS=client, start=ok
    2024-10-29T09:29:57.974858+00:00 dilbert sm-mta[1697008]: STARTTLS=client, info: fds=9/4, err=2
    2024-10-29T09:29:57.981578+00:00 dilbert sm-mta[1697008]: STARTTLS: TLS cert verify: depth=0 /CN=mx.google.com, state=1, reason=ok
    2024-10-29T09:29:57.982254+00:00 dilbert sm-mta[1697008]: STARTTLS=client, get_verify: 0 get_peer: 0x55e6b9c7d3d0
    2024-10-29T09:29:57.982433+00:00 dilbert sm-mta[1697008]: STARTTLS=client, relay=gmail-smtp-in.l.google.com., AltName=mx.google.com
    2024-10-29T09:29:57.982779+00:00 dilbert sm-mta[1697008]: STARTTLS=client, relay=gmail-smtp-in.l.google.com., AltName=smtp.google.com
    2024-10-29T09:29:57.983537+00:00 dilbert sm-mta[1697008]: STARTTLS=client, relay=gmail-smtp-in.l.google.com., AltName=aspmx.l.google.com
    2024-10-29T09:29:57.983614+00:00 dilbert sm-mta[1697008]: STARTTLS=client, relay=gmail-smtp-in.l.google.com., AltName=alt1.aspmx.l.google.com
    2024-10-29T09:29:57.983671+00:00 dilbert sm-mta[1697008]: STARTTLS=client, relay=gmail-smtp-in.l.google.com., AltName=alt2.aspmx.l.google.com
    2024-10-29T09:29:57.984115+00:00 dilbert sm-mta[1697008]: STARTTLS=client, relay=gmail-smtp-in.l.google.com., AltName=alt3.aspmx.l.google.com
    2024-10-29T09:29:57.984576+00:00 dilbert sm-mta[1697008]: STARTTLS=client, relay=gmail-smtp-in.l.google.com., AltName=alt4.aspmx.l.google.com
    2024-10-29T09:29:57.984677+00:00 dilbert sm-mta[1697008]: STARTTLS=client, relay=gmail-smtp-in.l.google.com., AltName=gmail-smtp-in.l.google.com
    2024-10-29T09:29:57.984879+00:00 dilbert sm-mta[1697008]: STARTTLS=client, relay=gmail-smtp-in.l.google.com., AltName=alt1.gmail-smtp-in.l.google.com
    2024-10-29T09:29:57.984970+00:00 dilbert sm-mta[1697008]: STARTTLS=client, relay=gmail-smtp-in.l.google.com., AltName=alt2.gmail-smtp-in.l.google.com
    2024-10-29T09:29:57.985155+00:00 dilbert sm-mta[1697008]: STARTTLS=client, relay=gmail-smtp-in.l.google.com., AltName=alt3.gmail-smtp-in.l.google.com
    2024-10-29T09:29:57.985310+00:00 dilbert sm-mta[1697008]: STARTTLS=client, relay=gmail-smtp-in.l.google.com., AltName=alt4.gmail-smtp-in.l.google.com
    2024-10-29T09:29:57.985400+00:00 dilbert sm-mta[1697008]: STARTTLS=client, relay=gmail-smtp-in.l.google.com., AltName=gmr-smtp-in.l.google.com
    2024-10-29T09:29:57.985608+00:00 dilbert sm-mta[1697008]: STARTTLS=client, relay=gmail-smtp-in.l.google.com., AltName=alt1.gmr-smtp-in.l.google.com
    2024-10-29T09:29:57.985780+00:00 dilbert sm-mta[1697008]: STARTTLS=client, relay=gmail-smtp-in.l.google.com., AltName=alt2.gmr-smtp-in.l.google.com
    2024-10-29T09:29:57.985842+00:00 dilbert sm-mta[1697008]: STARTTLS=client, relay=gmail-smtp-in.l.google.com., AltName=alt3.gmr-smtp-in.l.google.com
    2024-10-29T09:29:57.985890+00:00 dilbert sm-mta[1697008]: STARTTLS=client, relay=gmail-smtp-in.l.google.com., AltName=alt4.gmr-smtp-in.l.google.com
    2024-10-29T09:29:57.986130+00:00 dilbert sm-mta[1697008]: STARTTLS=client, relay=gmail-smtp-in.l.google.com., AltName=mx1.smtp.goog
    2024-10-29T09:29:57.986191+00:00 dilbert sm-mta[1697008]: STARTTLS=client, relay=gmail-smtp-in.l.google.com., AltName=mx2.smtp.goog
    2024-10-29T09:29:57.986379+00:00 dilbert sm-mta[1697008]: STARTTLS=client, relay=gmail-smtp-in.l.google.com., AltName=mx3.smtp.goog
    2024-10-29T09:29:57.986450+00:00 dilbert sm-mta[1697008]: STARTTLS=client, relay=gmail-smtp-in.l.google.com., AltName=mx4.smtp.goog
    2024-10-29T09:29:57.986644+00:00 dilbert sm-mta[1697008]: STARTTLS=client, relay=gmail-smtp-in.l.google.com., AltName=aspmx2.googlemail.com
    2024-10-29T09:29:57.986705+00:00 dilbert sm-mta[1697008]: STARTTLS=client, relay=gmail-smtp-in.l.google.com., AltName=aspmx3.googlemail.com
    2024-10-29T09:29:57.986917+00:00 dilbert sm-mta[1697008]: STARTTLS=client, relay=gmail-smtp-in.l.google.com., AltName=aspmx4.googlemail.com
    2024-10-29T09:29:57.986982+00:00 dilbert sm-mta[1697008]: STARTTLS=client, relay=gmail-smtp-in.l.google.com., AltName=aspmx5.googlemail.com
    2024-10-29T09:29:57.987174+00:00 dilbert sm-mta[1697008]: STARTTLS=client, relay=gmail-smtp-in.l.google.com., AltName=gmr-mx.google.com
    2024-10-29T09:29:57.987232+00:00 dilbert sm-mta[1697008]: STARTTLS=client, relay=gmail-smtp-in.l.google.com., version=TLSv1.3, verify=OK, cipher=TLS_AES_256_GCM_SHA384, bits=256/256
    2024-10-29T09:29:57.987423+00:00 dilbert sm-mta[1697008]: STARTTLS=client, cert-subject=/CN=mx.google.com, cert-issuer=/C=US/O=Google+20Trust+20Services/CN=WR2, verifymsg=ok
    2024-10-29T09:29:57.987482+00:00 dilbert sm-mta[1697008]: STARTTLS=read, info: fds=9/4, err=2
    2024-10-29T09:29:57.994383+00:00 dilbert sm-mta[1697008]: STARTTLS=read, info: fds=9/4, err=2
    2024-10-29T09:29:58.000405+00:00 dilbert sm-mta[1697008]: STARTTLS=read, info: fds=9/4, err=2
    2024-10-29T09:29:58.162462+00:00 dilbert sm-mta[1697008]: STARTTLS=read, info: fds=9/4, err=2
    2024-10-29T09:29:58.163402+00:00 dilbert sm-mta[1697008]: STARTTLS=read, info: fds=9/4, err=2
    2024-10-29T09:29:58.366636+00:00 dilbert sm-mta[1697008]: 49T9Tu0F1697006: --- 050 <du1874@gmail.com>... Sent (OK 1730194198 38308e7fff4ca-2fcb45e2a01si27180301fa.310 - gsmtp)
    2024-10-29T09:29:58.366769+00:00 dilbert sm-mta[1697008]: 49T9Tu0F1697006: to=<du1874@gmail.com>, delay=00:00:01, xdelay=00:00:01, mailer=esmtp, pri=31200, relay=gmail-smtp-in.l.google.com. [IPv6:2a00:1450:4010:c05:0:0:0:1b], dsn=2.0.0, stat=Sent (OK
    1730194198 38308e7fff4ca-2fcb45e2a01si27180301fa.310 - gsmtp) 2024-10-29T09:29:58.369046+00:00 dilbert sm-mta[1697008]: 49T9Tu0F1697006: done; delay=00:00:01, ntries=1
    2024-10-29T09:29:58.369260+00:00 dilbert sm-mta[1697008]: NOQUEUE: --- 050 Closing connection to gmail-smtp-in.l.google.com.
    2024-10-29T09:29:58.370012+00:00 dilbert sm-mta[1697008]: STARTTLS=read, info: fds=9/4, err=2
    2024-10-29T09:29:58.373981+00:00 dilbert sm-mta[1697008]: STARTTLS=client, SSL_shutdown failed: -1



    Bjørn

    --- 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 Tue Oct 29 12:11:35 2024
    OK, I will not claim to understand any of the sendmail cf language, but
    trying to reduce this problem to a test.cf file like this:

    C{cert_altnames}*.olc.protection.outlook.com D{server_name}outlook-com.olc.protection.outlook.com
    SSTS_SAN
    R$* $: $&{server_name}
    R$={cert_altnames} $@ ok
    # strip only one level (no recursion!)
    R$-.$+ $: $2
    R *.$={cert_altnames} $@ ok
    R$* $#error $@ 4.7.0 $: 450 $&{server_name} not listed in SANs

    and running that through sendmail -bt -Ctest.cf will reproduce the problem:

    STS_SAN foo
    STS_SAN input: foo
    STS_SAN returns: $# error $@ 4 . 7 . 0 $: 450 outlook-com . olc . protection . outlook . com not listed in SANs

    What I do not understand is why the rule doesn't simply rewrite "outlook-com.olc.protection.outlook.com" to
    "*.olc.protection.outlook.com" and then repeat the class lookup with
    that. Like this, which seems to work for me:

    SSTS_SANFIX
    R$* $: $&{server_name}
    R$={cert_altnames} $@ ok
    # strip only one level (no recursion!)
    R$-.$+ $: *.$2
    R$={cert_altnames} $@ ok
    R$* $#error $@ 4.7.0 $: 450 $&{server_name} not listed in SANs

    Running that I get:

    STS_SANFIX foo
    STS_SANFIX input: foo
    STS_SANFIX returns: ok
    ${server_name}
    outlook-com.olc.protection.outlook.com
    $={cert_altnames}
    *.olc.protection.outlook.com

    And it still seems to work as it should with non-matching names:

    .D{server_name}example.com
    STS_SANFIX foo
    STS_SANFIX input: foo
    STS_SANFIX returns: $# error $@ 4 . 7 . 0 $: 450 example . com not listed in SANs

    Exact matches also continue to work. Adding example.com to the class
    and run again:

    .C{cert_altnames}example.com
    $={cert_altnames}
    example.com
    *.olc.protection.outlook.com
    STS_SANFIX foo
    STS_SANFIX input: foo
    STS_SANFIX returns: ok


    So, what do you think? Is that the correct fix or am I missing
    something?



    Bjørn

    --- SoupGate-Win32 v1.05
    * Origin: fsxNet Usenet Gateway (21:1/5)
  • From HQuest@21:1/5 to All on Tue Oct 29 11:00:03 2024
    I can confirm the problem exists with messages sent to outlook.com email addresses. At first, I thought it would be a behavior change introduced
    by openssl 3.4.0 (this was the last update I applied to this system),
    however downgrading back to v3.3.2, and even going down to 3.0.15 gives
    the same output. Unless this is a side effect of any possible patches
    applied by upstream in their Sep 2024 releases.

    --- SoupGate-Win32 v1.05
    * Origin: fsxNet Usenet Gateway (21:1/5)
  • From =?utf-8?Q?Bj=C3=B8rn_Mork?=@21:1/5 to HQuest on Tue Oct 29 12:54:59 2024
    hquest@hquest.pro.br (HQuest) writes:

    I can confirm the problem exists with messages sent to outlook.com email addresses. At first, I thought it would be a behavior change introduced
    by openssl 3.4.0 (this was the last update I applied to this system),
    however downgrading back to v3.3.2, and even going down to 3.0.15 gives
    the same output. Unless this is a side effect of any possible patches
    applied by upstream in their Sep 2024 releases.

    Thanks for confirming that I'm not crazy :-)

    The patch below fixes the issue for me, but should probably go through
    someone who knows what they are doing.


    Bjørn
    ---
    From a43bb19d2f26267f7098a114edc2c191f45e4286 Mon Sep 17 00:00:00 2001
    From: =?UTF-8?q?Bj=C3=B8rn=20Mork?= <bjorn@mork.no>
    Date: Tue, 29 Oct 2024 12:17:04 +0100
    Subject: [PATCH] cf: fix wildcard handling in STS_SAN rule
    MIME-Version: 1.0
    Content-Type: text/plain; charset=UTF-8
    Content-Transfer-Encoding: 8bit

    MXes with wildcard certificates would be rejected with a bogus
    "not listed in SANs" error. Fix by rewriting the MX hostname
    to its wildcard alternative, and then reattempt the SAN class
    match.

    Link: https://www.novabbs.com/computers/article-flat.php?id=1120&group=comp.mail.sendmail
    Signed-off-by: Bjørn Mork <bjorn@mork.no>
    ---
    cf/m4/proto.m4 | 4 ++--
    1 file changed, 2 insertions(+), 2 deletions(-)

    diff --git a/cf/m4/proto.m4 b/cf/m4/proto.m4
    index ff7eb0bedc2a..d143b42fbae9 100644
    --- a/cf/m4/proto.m4
    +++ b/cf/m4/proto.m4
    @@ -2748,9 +2748,9 @@ R$* $: $&{server_name}
    dnl exact match
    R$={cert_altnames} $@ ok
    # strip only one level (no recursion!)
    -R$-.$+ $: $2
  • From Claus =?iso-8859-1?Q?A=DFmann?= @21:1/5 to All on Tue Oct 29 12:17:24 2024
    Unfortunately this has not yet been released:
    8.18.2/8.18.2 202x/xx/xx
    Fix matching of wildcard SANs in the experimental support
    for SMTP MTA Strict Transport Security (MTA-STS).
    Problem reported by Dilyan Palauzo.

    Here's the current version of the ruleset:

    dnl check SAN for STS
    SSTS_SAN
    ifdef(`_STS_SAN', `dnl
    R$* $: $&{server_name}
    # {server_name} does not have a trailing dot
    # R$+. $1
    dnl exact match
    R$={cert_altnames} $@ ok
    # strip one level up to first dot
    R$~. . $+ .$2
    dnl wildcard: *. not just .
    R.$+ $: *.$1
    R $={cert_altnames} $@ ok
    dnl always temporary error? make it an option (of the feature)?
    R$* $#error $@ 4.7.0 $: 450 $&{server_name} not listed in SANs', `dnl')



    --
    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 Tue Oct 29 20:36:23 2024
    On 29.10.2024 um 12:17 Uhr Claus Aßmann wrote:

    Unfortunately this has not yet been released:
    8.18.2/8.18.2 202x/xx/xx
    Fix matching of wildcard SANs in the experimental support
    for SMTP MTA Strict Transport Security (MTA-STS).
    Problem reported by Dilyan Palauzo.

    It is also not in
    ftp://ftp.sendmail.org/pub/sendmail/KNOWNBUGS

    --
    kind regards
    Marco

    Send spam to 1730200644muell@cartoonies.org

    --- 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 Wed Oct 30 01:30:08 2024
    Marco Moock wrote:
    On 29.10.2024 um 12:17 Uhr Claus Aßmann wrote:

    Unfortunately this has not yet been released:

    It is also not in
    ftp://ftp.sendmail.org/pub/sendmail/KNOWNBUGS

    Of course not. KNOWNBUGS is part of the most recent release.
    If the problem would have been detected during snapshot testing
    then we would have fixed it before release (instead of adding
    it to KNOWNBUGS).

    --
    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 HQuest@21:1/5 to All on Wed Oct 30 12:55:13 2024
    Claus preview of m4/proto.m4 changes does improve delivery of
    Outlook.com emails to a functional status. Looking forward to the final update/preview Sendmail code to test other fixes.

    --- SoupGate-Win32 v1.05
    * Origin: fsxNet Usenet Gateway (21:1/5)
  • From Claus =?iso-8859-1?Q?A=DFmann?= @21:1/5 to HQuest on Thu Oct 31 00:51:08 2024
    HQuest wrote:
    Claus preview of m4/proto.m4 changes does improve delivery of
    Outlook.com emails to a functional status. Looking forward to the final update/preview Sendmail code to test other fixes.

    There is only one other fix in the current code, hence we haven't
    released a new version (yet).

    Avoid adding a second To: header to DSNs, instead any
    additional addresses are appended to an existing
    To: header (this also applies to Cc: and Bcc:).

    --- 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 Mon Nov 11 17:09:13 2024
    Claus Aßmann <INVALID_NO_CC_REMOVE_IF_YOU_DO_NOT_POST_ml+sendmail(-no-copies-please)@esmtp.org>
    writes:

    There is only one other fix in the current code, hence we haven't
    released a new version (yet).

    If you're looking for another quick fix to justify a new version, then
    may I suggest making _FFR_TLS_USE_CERTIFICATE_CHAIN_FILE default?

    The Debian sendmail package is still built without this (I will open a
    bug now). Googling a bit I see that Redhat hit the problem a few years
    ago: https://bugzilla.redhat.com/show_bug.cgi?id=1565341

    There are probably many other distros, or end users building their own
    binary, doing the same because they are unaware of the setting.

    A binary built without that flag can only use server certificates
    directly signed by a CA known to the client. A well known workaround is
    to add intermediate CAs to the CACertFile. The simplest method is by
    using the server certificate chain for both ServerCertFile and
    CACertFile.

    A side effect of this workaround is that intermediate CAs are also
    trusted to sign client certificates. Which will cause policy conflicts.

    If the server certificate is signed by a public CA using an intermediate
    CA, which I will claim is an extremely common use case nowadays, then
    client certificates are useless unless _FFR_TLS_USE_CERTIFICATE_CHAIN_FILE
    is set.

    Yes, I know I still can configure client trust by DN using the access
    db. But AUTH EXTERNAL is not possible in a secure way AFAICS.

    Even worse, users may be tempted to ignore the security implications and
    trust client certificates even if they depend onq the CACertFile workaround.



    Bjørn

    --- SoupGate-Win32 v1.05
    * Origin: fsxNet Usenet Gateway (21:1/5)
  • From Marco Moock@21:1/5 to All on Fri Dec 27 11:53:15 2024
    On 29.10.2024 09:16 Uhr Bjørn Mork wrote:

    This seemed to work pretty well, but yesterday I noticed a problem:
    Some emails were temporarily rejected with an unexpected "not listed
    in SANs" message. This was unexpexted because most of the affected
    emails were for MXes hosted by Microsoft and their
    "protection.outlook.com" service.

    Which logging options do you use?
    I maybe have the same problem with gmail/MS and STS with their
    certificates, but the logging just says and verify=FAIL <itex-rua@microsoft.com>... Deferred: 403 4.7.0 authentication failed


    --
    kind regards
    Marco

    Send spam to 1730189797muell@stinkedores.dorfdsl.de

    --- SoupGate-Win32 v1.05
    * Origin: fsxNet Usenet Gateway (21:1/5)
  • From =?utf-8?Q?Bj=C3=B8rn_Mork?=@21:1/5 to Marco Moock on Fri Dec 27 13:35:29 2024
    Marco Moock <mm+usenet-es@dorfdsl.de> writes:
    On 29.10.2024 09:16 Uhr Bjørn Mork wrote:

    This seemed to work pretty well, but yesterday I noticed a problem:
    Some emails were temporarily rejected with an unexpected "not listed
    in SANs" message. This was unexpexted because most of the affected
    emails were for MXes hosted by Microsoft and their
    "protection.outlook.com" service.

    Which logging options do you use?
    I maybe have the same problem with gmail/MS and STS with their
    certificates, but the logging just says and verify=FAIL <itex-rua@microsoft.com>... Deferred: 403 4.7.0 authentication failed

    I'm usually running with

    define(`confLOG_LEVEL', `10')dnl # - attempting to get useful AUTH logging (default is 9)
    define(`confMILTER_LOG_LEVEL',`9')dnl # ...without creating unnecessary milter noise


    But I don't think your error is related to the SAN wildcard problem.
    Looks like you are trying to verify the peer certificate?


    Bjørn

    --- SoupGate-Win32 v1.05
    * Origin: fsxNet Usenet Gateway (21:1/5)
  • From Marco Moock@21:1/5 to All on Fri Dec 27 17:14:34 2024
    On 27.12.2024 13:35 Uhr Bjørn Mork wrote:

    But I don't think your error is related to the SAN wildcard problem.
    Looks like you are trying to verify the peer certificate?

    Yes, I will then open another thread here.

    --
    kind regards
    Marco

    Send spam to 1735302929muell@stinkedores.dorfdsl.de

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