Sunday, Nov 29, 2015 1:13 PM John Levine wrote:
It's not even privacy vs. ops support, it's privacy issues via some
hints of sender's location vs. privacy issues via the recipient
getting spammed, phished, and malware'd.
The only Received: header fields that you can trust are the ones that were
added by servers in your administrative domain.
Not at all. If you get mail from a provider you know to be
trustworthy, you can trust the headers they add. Given that mail is
dominated by large providers, and any individual mail system tends to
exchange mail with the same people over and over, you can cover a
great deal of your mail with a modest number of sort of special cases
for providers you know. For example, I live near Ithaca NY so I
exchange a lot of mail with Cornell, which is full of students who
never saw a malware-infested game they wouldn't install. So it's
useful to have scripts that can look at their headers so I can tell
them who needs to be thwacked today.
the Received: header field needs to contain is a token that can be used to
backtrace the message to its origin using the logs:
Um, we have some scaling issues here. Large providers send and
receive billions of messages a day so looking up stuff in the logs is
non-trivial. Also, when you're trying to shut down a phish campaign,
you want to do it ideally in minutes, at worst hours, not whenever
someone can get around to pulling some log info from a distant server.
There are a lot of people on ietf-smtp familiar with large mail
systems, so perhaps it would be more productive to ask questions about
how stuff actually works.
R's,
John
_______________________________________________
ietf-smtp mailing list
ietf-smtp(_at_)ietf(_dot_)org
https://www.ietf.org/mailman/listinfo/ietf-smtp