>> By the nature of e-mail, the recipient of a message already knows who >> the sender sent it to, since he or she got it. The Received headers go >> into the message itself, not third party logs. > > Mail list archives and mail corpus leaks do expose that to more > than one recipient.
Indeed, but unless they remove the Received: headers (in which case this debate is irrelevant) they also expose the recipient and so forth.
To the extent that list archives have those headers, they disclose the address of the list and perhaps an internal address used to forward mail from the list to the archive. BFD, I'd think. The corpora I've seen have no Received headers and the addresses in From/To/CC redacted, too.
> But, if someone has decided to setup ESNI for an MTA (which will > need them to take action to do that), then I'd assume they have > a reason. At that point, exposing the ESNI value in the message > is what I'm arguing to not recommend.
Naah, it just means they upgraded to a new library version that supports it.
Here's a thought experiment: try and construct a plausible Received header that would tell you more about the recipient with SNI than without, keeping in mind that the IP address of the server is mandatory,
First, I don't think that's the case. But even if it is, how about a server servicing multiple domains, some sensitive and some not, and each domain set up with different MX records? I'll also note that servers often omit or obfuscate IP address information for security reasons, irrespective of what the standards say.
and the server name and recipient (the "for" clause) are usually included. I think you'll find it's quite hard unless you do things that MTAs don't normally do.
Actually I'm seeing fewer and fewer for clauses over time. But regardless, as I noted in my previous message, the security considerations of including SNI information aren't really separable from the security considerations of what to include in trace fields in general, and don't obviously align with whether or not ESNI is used. Ned _______________________________________________ Uta mailing list Uta@ietf.org https://www.ietf.org/mailman/listinfo/uta