Re: [Shutup] [ietf-smtp] Proposed Charter for the "SMTP Headers Unhealthy To User Privacy" WG (fwd)

[Ned Freed <[e-mail]>]

> 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