1. Forum
  2. USENET
  3. comp.mail.sendmail

  • Any possible support for MTA-STS or TLSRPT in sendmail?

    From Dan Mahoney (Gushi)@danm@prime.gushi.org to comp.mail.sendmail on Mon Aug 24 09:33:53 2026
    From Newsgroup: comp.mail.sendmail

    Hey there folks,

    Postfix has (kind of, sort of, with a third party look up daemon) support
    for looking up MTA-STS. I'm not particularly interested in this -- I'll
    do TLS if a server offers it, I don't need an HTTPS page to tell me it's required.

    That said, it would be interesting to be able to report TLS or DANE
    failures (even if I'm not evaluating an MTA-STS policy, I can still
    generate reports based on DANE and Opportunistic TLS).

    Is there enough logging in sendmail at some level that could be sent off
    at some log-level to generate these reports, such that a clever syslog
    parser could just pull the data out there?

    -Dan
    --

    --------Dan Mahoney--------
    FB: fb.com/DanielMahoneyIV
    LI: linkedin.com/in/gushi
    Site: http://www.gushi.org
    ---------------------------

    --- Synchronet 3.22a-Linux NewsLink 1.2
  • From Claus =?iso-8859-1?Q?A=DFmann?=@INVALID_NO_CC_REMOVE_IF_YOU_DO_NOT_POST_ml+sendmail(-no-copies-please)@esmtp.org to comp.mail.sendmail on Mon Aug 24 07:15:37 2026
    From Newsgroup: comp.mail.sendmail

    Dan Mahoney (Gushi) wrote:

    Postfix has (kind of, sort of, with a third party look up daemon) support for looking up MTA-STS. I'm not particularly interested in this -- I'll

    Same for sendmail - see the docs.

    That said, it would be interesting to be able to report TLS or DANE
    failures (even if I'm not evaluating an MTA-STS policy, I can still
    generate reports based on DANE and Opportunistic TLS).

    Is there enough logging in sendmail at some level that could be sent off
    at some log-level to generate these reports, such that a clever syslog parser could just pull the data out there?

    sendmail shows whether TLS has been used for a session:
    sm-mta[63106]: STARTTLS=client, relay=...., version=TLSv1.3, verify=FAIL, cipher=TLS_AES_256_GCM_SHA384, bits=256/256
    sm-mta[63131]: STARTTLS=server, relay=...., version=TLSv1.3, verify=NO, cipher=TLS_AES_256_GCM_SHA384, bits=256/256

    The non-trivial bit for a parser is to associate those session log
    entries with the transactions.
    Unless the FFR for session/transaction ids is enabled,
    this can be done by looking for the pid:

    sm-mta[63106]: 67K7J9LF022027: to=<.....>, delay=4+03:20:05, xdelay=00:00:03, mailer=esmtp, relay=...., dsn=4.5.0, ...

    The simpler way is to look at the from= entry and check the value
    of proto=

    sm-mta[63131]: 67OAik2Z063131: from=<....>, size=38093, class=0, nrcpts=1, msgid=<....>, proto=ESMTPS, daemon=MTA, relay=...

    The trailing 'S' indicates the use of STARTTLS.
    --
    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.
    --- Synchronet 3.22a-Linux NewsLink 1.2