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
_______________________________________________ Shutup mailing list [email protected] https://www.ietf.org/mailman/listinfo/shutup
