>> 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
_______________________________________________
ietf-smtp mailing list
ietf-smtp(_at_)ietf(_dot_)org
https://www.ietf.org/mailman/listinfo/ietf-smtp