On Tue, 29 Oct 2024, Brian E Carpenter wrote:
The Security Considerations start by saying "SMTP mail is inherently insecure" which is undoubtedly true, although "Transmission of mail via SMTP is inherently insecure" might be more precise.
The term "insecure" does not work well here. There is the privacy aspect, and then there is the modification aspect.
So I am a bit surprised that the next sentence doesn't require STARTTLS and cite RFC 3207 and RFC 7817. It seems to me that this would be a practical response to Donald's comments about transport authentication and surveillance, and I don't see why it should be kicked to the future Applicability Statement.
I agree. But that in itself does not make solve the "SMTP mail is inherently insecure" bit. Since it is hop by hop, every hop can still receive it (securely via STARTTLS) and modify the contents. In practise, the pipeline is a few hops trusted by the sender, followed by a direct delivery to the mx target with no intermediate/backup MX, followed by a few anti-spam hops trusted by the receiver. So the chance of email modification is low.
In particular, it deals with both threats against SMTP (a *transfer* protocol) - alteration to the content, and capture of the content. Just a couple of sentences could capture these threats and STARTTLS as the mitigation.
STARTTLS is not a full protection against content modification.
I agree with John Klensin that DMARC, DKIM and the like are out of scope for SMTP as such. They aren't part of simple mail *transfer* so they don't belong here.
In the real world, they are. As Aragorn would say, "You cannot simple mail transfer into Mordor without doing DKIM/SPF/DMARC". As an aside, I wonder how long until SMTP without STARTTLS can be turned off? I'm very tempted for my personal domain to do so already. Paul -- last-call mailing list -- last-call@xxxxxxxx To unsubscribe send an email to last-call-leave@xxxxxxxx
