On Mon, Oct 28, 2024 at 11:07 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.
This one is a special case. If the IETF is good at anything, it is accomodating special cases.
I think the document could use a sentence here saying what it doesn't cover. SMTP is incredibly insecure, but that's the state of play.
thanks,
Rob
-- last-call mailing list -- last-call@xxxxxxxx To unsubscribe send an email to last-call-leave@xxxxxxxx
