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

[Ted Lemon <[e-mail]>]

Monday, Nov 30, 2015 12:50 PM Ned Freed wrote:
>> 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.

I think you misunderstood my question.   What I mean is, if the spam gets to you through aol with a dkim signature, what good does it do you to check the Received: headers?   I'm not disputing that spam comes through AOL!

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

Dave Crocker brought it up.   It's a concern: people do commit crimes (e.g., harassment) using email, and being able to get close to the source of the email can be helpful in those cases.

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

Sure, absolutely.   But whether we like it or not, absent the logs, we may simply not have the information because large mail providers are making the decisions without waiting for us.

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

I think this is certainly interesting from a research PoV, but has pretty much zero applicability to everyday users of email.   That said, I don't think anybody has proposed to remove indications of whether SSL is used from Received header fields, so perhaps this is a non-issue.

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

What I am not interested in is being told that I shouldn't be allowed to have an opinion about the privacy implications of Received: headers because I am more of a mail user than a mail operator.   I'm sorry that you find that position problematic, but I think that your response here is unfortunate.


--
Sent from Whiteout Mail - https://whiteout.io

My PGP key: https://keys.whiteout.io/[e-mail]