> On Dec 1, 2015, at 8:54 AM, Ted Lemon <[email protected]> wrote: > > Tuesday, Dec 1, 2015 7:27 AM Arnt Gulbrandsen wrote: >>> Sure, but in this case wouldn't deferring to the end systems> argue in >>> favor of allowing end systems to make the decision as> to whether their >>> private information should be exposed? >> >> As I see it, that's not the question here. The question is: Should there be >> an RFC that can be used/misused to apply pressure regarding trace fields etc? > > Yes, I agree that this is what we are discussing. I think it's pretty clear > that for Received header fields that refer to the IP address of the end-user, > the answer is "yes, there should be such an RFC." I haven't heard anyone > seriously propose that this is not true, although I'd be interested to hear > such an argument!
Well, I'll be the first, then. When people routinely hide their identities - to the extent that a recipient cannot tell that two emails were sent by the same person - that eliminates many social and technical pressures on bad behaviour. But it *also* removes the ability for people to help them when their endpoints have been compromised. The biggest email-related risk to peoples privacy is malware that compromises their computers (followed by phishing, that compromises their online accounts). If someone is sending mail through a smarthost provider that a) hides the source of mail sent through them and b) has an abuse/security team that is anything less than top-tier then there is no way to identify that mail originated with them. When their machine is compromised, it can then send out malware and phishing itself, compromising others. And there's no way to contact the people responsible for the security of that machine - whether it be the end-user themself, the end-users employers IT department or the end-users residential ISP. The infection spreads faster, more people's privacy is violated. *Routinely* removing end-user identifiers harms privacy. Cheers, Steve _______________________________________________ Shutup mailing list [email protected] https://www.ietf.org/mailman/listinfo/shutup
