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

[Jim Fenton <[e-mail]>]

On 11/29/2015 09:12 AM, Chris Newman wrote:
> I oppose the current shutup charter text
> and draft-josefsson-email-received-privacy as both promote the
> elimination of mechanisms that protect users from fraud and abuse.

Agreed, and to be more specific:

The proposed charter speaks of Received header fields leaking address
information that can expose user location. Yes, they can. But, in
general, that information is essential to identifying spoofed header
fields: it's by tracing the chain of "from" addresses in Received header
fields that one can determine that someone is attempting to do something
fraudulent. Further, I don't have a lot of sympathy for organizations
that rely on the secrecy of their network topologies as an essential
security component. We're trying to increase the trust in email, not
reduce it.

There are users for whom their privacy is critically important, such as
press informants in totalitarian societies. There are many other ways to
determine their location (network monitoring coupled with a STARTTLS
downgrade attack, for one), and it would be harmful (potentially
life-threatening) if anyone thought that this would truly protect them.
They should be using something like SecureDrop and not using email at all.

draft-josefsson-email-received-privacy mentions the issue of senders'
locations appearing on mailing lists and in mailing list archives. I
have long felt that we are conflicted on whether the output of a mailing
list is a new message or the same as the one sent to the mailing list.
It usually has a different MAIL FROM address, and often has text added
to the message body, which I would think is enough of a change to make
it a new message. Yet the Message-ID and Received header fields are
preserved. I would think that an entire new message should be created,a
new Message-ID assigned, and DKIM signed by the mailing list's domain
(of course!). Only selected header fields would be transferred to the
new message. The original incoming header fields should be available
only to the list administrators, who deal with abuse issues.

What would the motivation be for anyone to implement any header privacy
improvements? There is far too much deployed infrastructure to get a
change to be made, absent a very strong business case. We could spend a
lot of time on this and not have it matter a bit.

I would support some work on the mailing list issue resulting in a set
of recommended practices, and possibly guidance on obscuring the source
IP address when an authenticated submission is made to an MSA. But
that's it.

-Jim