In summary: “Report senders SHOULD attempt delivery via SMTP using STARTTLS to all receivers. Transmitting these reports via a secured session is preferrable.”
I don’t think we should add this in, but receivers could deploy DANE/MTA-STS if they wanted to ensure senders who honor those will use TLS. -- Alex Brotman Sr. Engineer, Anti-Abuse & Messaging Policy Comcast From: dmarc <dmarc-boun...@ietf.org> On Behalf Of Hector Santos Sent: Wednesday, April 26, 2023 4:29 PM To: Scott Kitterman <skl...@kitterman.com> Cc: IETF DMARC WG <dmarc@ietf.org> Subject: Re: [dmarc-ietf] I-D Action: draft-ietf-dmarc-aggregate-reporting-10.txt On Apr 26, 2023, at 3:50 PM, Scott Kitterman <skl...@kitterman.com<mailto:skl...@kitterman.com>> wrote: I think it would be crazy in 2023 not to use STARTTLS is offered. +1 Personally I interpreted it more as employ a secure transport and think through if you really want to be sending the report if you can't. I think there's some room for interpretation and I think that's fine. I believe connectivity is independent of the application. All connections SHOULD assume the highest possible security available today. For unsolicited email, the presumption would be: Port 25 STARTTLS If I was start performing reports (and I think I will), that is how I would begin, naturally, with outbound SMTP clients with optional TLS if offered. Sorry if I was not focused with the main question, — HLS
_______________________________________________ dmarc mailing list dmarc@ietf.org https://www.ietf.org/mailman/listinfo/dmarc
