Tuesday, Dec 1, 2015 12:11 PM Steve Atkins wrote: > > 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!
> 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. Your entire argument relies on this point, so I will just respond to this one point; I don't disagree with what you say afterwards, but I think that you are wrong in suggesting that obfuscating the Received: header field for the email submission causes the problem you say it does. The claim you have made is that the person submitting the email is hiding their identity, but this is not the case. First, they have to prove their identity in order to submit the mail in the first place, most likely. Secondly, their IP address is visible to the submit server, and is likely logged. It is the submit server that, we are theorizing, should hide their identity. The entity responsible for providing support to _that person_ is the entity that operates the SMTP submit server. That entity knows the end user's identity, and knows what IP address they used to submit the email. So they are not prevented from providing the support that you rightly say they should provide. It is certainly true that if the submit server is not operated by a responsible entity, then we have a problem. The right fix for that problem is probably something similar to what John has said AOL did in a similar situation: start greylisting mail from that provider so that the high rate of spam chokes their queues, and they will start to be more proactive in addressing problems. There is no need to violate the privacy of legitimate end-users who are doing nothing wrong in order to address this problem. -- Sent from Whiteout Mail - https://whiteout.io My PGP key: https://keys.whiteout.io/[email protected]
pgpg6hcXeHxm9.pgp
Description: PGP signature
_______________________________________________ Shutup mailing list [email protected] https://www.ietf.org/mailman/listinfo/shutup
