I assume you made a typo, but for the sake of clarity: mta-sts needs a TXT
record at _mta-sts.<domain> and an http server serving the policy at
https://mta-sts.<domain>/.well-known/mta-sts.txt. It has nothing to do with
_smtp._tls.<domain>.
Groetjes,
Louis
Op zondag 17 november 2024 om 04:19, schreef Viktor Dukhovni via mailop
<mailop@mailop.org>:
> On Sun, Nov 17, 2024 at 01:30:24AM +0100, Olga Fischer via mailop wrote:
>
> > Some of our domains receive TLS reports for connections their mx's
> > didn't make on behalf of any user of such a domain.
>
> This makes no sense, because unlike DMARC reports which are sent by
> receiving (server) systems, TLS reports are sent by sending (client)
> systems to the domains whose MX hosts had trouble with TLS.
>
> So when you receive a TLS report, it is never about mail your MX hosts
> sent, rather it is about mail others tried to send to you.
>
> > Are such reports usually only sent for DMARC-aligned senders or even
> > for forged senders to the actual MX? As we get DMARC reports from the
> > same receivers, that show forged senders, I believe they are sent for
> > forged senders as well.
>
> TLS reports (RFC 8460) have nothing to do with DMARC. If you publish
> conformant _smtp._tls.<domain>. (MTA-STS) or _smtp._tls.<mxhost>. (DANE)
> DNS records, you may get reports from *senders* about their issues with
> establishing a (verified) TLS connection to your system.
>
> There is active work on TLSRPT support in Postfix, if this sees
> non-trivial adoption, the volume of reports go up a bit.
>
> --
> Viktor.
> _______________________________________________
> mailop mailing list
> mailop@mailop.org [mailop@mailop.org]
> https://list.mailop.org/listinfo/mailop
> [https://list.mailop.org/listinfo/mailop]
_______________________________________________
mailop mailing list
mailop@mailop.org
https://list.mailop.org/listinfo/mailop
