I think that the original wording, which is technology agnostic, is better. As you suggest, there are multiple ways to address the requirement and being overly specific will not age well.
Scott K On April 27, 2023 2:11:17 PM UTC, "Brotman, Alex" <Alex_Brotman=40comcast....@dmarc.ietf.org> wrote: >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
