Reading this thread, the obvious reason I feel as though there should be some language about (Opportunistic) STARTTLS is that I highly doubt any technically competent person would deploy a new system without supporting STARTTLS. If we're aligning these bis documents to more closely resemble modern deployments, I'm not sure why we would ignore this opportunity to provide good guidance (I'm not wading into SHOULD/MUST).
Personally, I'd love to see a reference to DANE and MTA-STS as sort of the "extra credit" model, but I also understand if it doesn’t happen.
Happy to help with language if others are interested.
--
Alex Brotman
Sr. Engineer, Anti-Abuse & Messaging Policy
Comcast
> -----Original Message-----
> From: Salz, Rich <rsalz=40akamai.com@xxxxxxxxxxxxxx>
> Sent: Thursday, October 31, 2024 2:28 PM
> To: Nick Hilliard <nick@xxxxxxxxxx>
> Cc: last-call@xxxxxxxx; emailcore@xxxxxxxx
> Subject: [Emailcore] Re: [Last-Call] Re: MUST be Parental
>
> > Note that SMTP, as defined here and elsewhere conducts all its traffic
> > in plaintext. Applications which use it that are concerned about the
> > traffic being intercepted or modified SHOULD consider using the
> > STARTTLS extension as described in {{something}}.
>
> > protocol support? operational support? pki / configuration management
> > support?
>
> All good questions, I was just trying to propose wording that gets us past the
> roadblock.
>
> --
> Emailcore mailing list -- emailcore@xxxxxxxx To unsubscribe send an email to
> emailcore-leave@xxxxxxxx
--
last-call mailing list -- last-call@xxxxxxxx
To unsubscribe send an email to last-call-leave@xxxxxxxx
