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

[Ned Freed <[e-mail]>]

> Sunday, Nov 29, 2015 11:53 PM Ned Freed wrote:
> > 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.

> Why would you want to check the Recieved: header fields in this case?   Under
> what circumstances would checking the header fields in a message known to have
> been received from aol.com, with a valid DKIM signature, add value over the
> validation you're already stipulating has happened?

Because vast amounts of spam comes through MSPs like aol.com, all nicely DKIM
signed. And of course you can't block aol.com completely - although I admit
it's really tempting sometimes.

> >> 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.

> I think we may be talking about different things.   If you are trying to
> identify spam, you wouldn't need to do this for mail received through aol.com.  

Except that sometimes you do. See above.

> I'm talking about the case where someone is committing some kind of illegal
> behavior that triggers search warrants or other requests for records.  In this
> case, lawful requests can be satisfied by searching logs, and could not be
> satisfied by looking at the text of a message.   The data in such a message
> could not be considered trustworthy.

When did the needs of law enforcement become part of this?

Anyway, it is of course the case that logs are the best evidence. But logs
aren't always available, and if they are available they may not be accessible,
in which case you make do with what you have.

> > 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.

> Why would that be useful?

Oh, I don't know, perhaps to find out where gaps exists in privacy coverage
and patch them up? Service providers have proven to be fairly responsive
to customer requests for SSL/TLS 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.

> I don't think it's so much been missed as found to be of no obvious value.

> > 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.

> Yes, let us think of the children!

And with this I'm done. It is now quite apparent that not only do you have zero
clue about the operational realities of modern email systems, you aren't
interested in correcting your many misconceptions. Given that, there is
no point in continuing this discussion.

				Ned