> Sunday, Nov 29, 2015 1:13 PM John Levine wrote:
> > It's not even privacy vs. ops support, it's privacy issues via some
> > hints of sender's location vs. privacy issues via the recipient
> > getting spammed, phished, and malware'd.
> The only Received: header fields that you can trust are the ones that were
> added by servers in your administrative domain.
Nonsense. The most obvious counterexample is when you receive mail from a
trusted server in some other trusted domain.
In fact this is now the most common case: Mail is submitted to a large service
provider which if it exits the administrative domain at all goes directly to
your administrative domain. The Received: header fields from, say, aol.com is
entirely trustable, especially since you can check the DKIM signature.
A certain amount of heurisitics are involved, but these are well understood.
> Anything else, you have to trace back through the logs hop by hop to actually
> know that the mail transited those systems; otherwise, an attacker can fake up
> whatever Received: header fields they want in order to cast blame on whomever
> they want to harm.
No, they really can't. See above.
> That being the case, all the Received: header field needs to contain is a
> token that can be used to backtrace the message to its origin using the
> logs: anything else is superfluous.
Nope. For one thing, the use of a token would require some means
of accessing logs across administrative domains. That's not going to happen
for a whole bunch of reasons.
And the "from" clause d is far from the only thing of use in a Received: field.
In fact it's far from the only thing that has privacy implications. Just
as one example, "with" clauses can be used to indicate whether or
not SSL/TLS was used to secure the connection. An unbroken Received: chain
can provide assurance (or repudiation) of end-to-end transport protection.
Unfortunately, so far the "analysis" that's been done of the privacy
considerations of email trace information has been so shallow that stuff like
this has been missed.
> So postcarding all kinds of private
> information about the end user is not only not actually useful for the
> reason you suggest, it is actively harmful to the end user.
Nonsense again. In a world where almost email is spam or worse, any mechanism
that provides benefits in the fight against spam is beneficial to end users.
Ned
_______________________________________________
Shutup mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/shutup
