Tuesday, Dec 1, 2015 12:11 PM Steve Atkins wrote:
On Dec 1, 2015, at 8:54 AM, Ted Lemon <mellon(_at_)fugue(_dot_)com> 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/mellon(_at_)fugue(_dot_)com
pgpV18rYhB2IP.pgp
Description: PGP signature
_______________________________________________
ietf-smtp mailing list
ietf-smtp(_at_)ietf(_dot_)org
https://www.ietf.org/mailman/listinfo/ietf-smtp