On Mon, Oct 28, 2024 at 11:08 AM John R. Levine <johnl@xxxxxxxx> wrote: > > On Mon, 28 Oct 2024, Eric Rescorla wrote: > > As I said, I'd prefer the security considerations in this document to be > > complete but I could live with them being in a separate document provided > > there was a normative reference to said document. If you don't think that's > > a valid alternative, then I think the appropriate resolution is to properly > > update the security considerations in this document. > > Keeping in mind that this protocol is 40 years old, and most of the > security issues are addressed higher up the stack than the SMTP level, who > do you see as the targets or beneficiaries of that update? > > The only significant thing I can think of that happens at the SMTP level > is TLS security, so I suppose it could point to STARTTLS, which is > described in RFC 3207, and to encourage people to use TLS, mention MTA-STS > which is in RFCs 8460 and 8461, or TLSA, which is in RFCs 6698 and 7671. > Those are all optional extensions, not part of the protocol described > here. > > I could certainly see a separate document that gives an overview of the > state of mail security, but stuffing it into this revision of 5321 seems > like process for process' sake. It wouldn't cost much to shove in a bunch of citations to additional docs here to describe these things. Why is this a big edit? > > Regards, > John Levine, johnl@xxxxxxxxx, Primary Perpetrator of "The Internet for Dummies", > Please consider the environment before reading this e-mail. https://jl.ly > > -- > last-call mailing list -- last-call@xxxxxxxx > To unsubscribe send an email to last-call-leave@xxxxxxxx -- Astra mortemque praestare gradatim -- last-call mailing list -- last-call@xxxxxxxx To unsubscribe send an email to last-call-leave@xxxxxxxx