Re: [Shutup] [ietf-smtp] Proposed Charter for the "SMTP Headers Unhealthy To User Privacy" WG (fwd)

[Ted Lemon <[e-mail]>]

Sunday, Nov 29, 2015 11:28 PM John Levine wrote:
> Yes.  See the message you just replied to.

The experience you related sounds like hobbyist activity, no offense.   I can't see how what you described could possibly scale to anything a large email provider would ever do, and indeed it's not something I would ever take the trouble to do, even though my domain has exactly two users.   If I get spam, I delete it.   I do not complain about it.  I do not attempt to understand where it originated.

>>Since the only header-field you can actually trust is the first one that your own MTA adds, ...
> 
> No, that's not correct.  See recent message.

I saw the recent message, and again, what you described is something that doesn't scale.   If that is your model for how header-field messages are used for validation, I think what I said is actually more generally accurate.   Do you seriously think that Google has special-case header parsing to deal with spam from Cornell students' infected computers?   No, they just use machine learning.

> SPF works just as well (actually, a _lot_ better) as a validation mechanism.
> 
> What?  Header chains say "this message came through this IP".  SPF
> says "I assert that these IPs are allowed to send mail for this
> domain."  They're completely unrelated.

SPF allows me to discard all messages that claim to be from domain X but come from IP addresses not listed for domain X, which means that I never have to write a Received: header for that message.   If there is no SPF for the domain that sent the message, I would like to just discard it as spam, but that's not safe to do because so many small sites don't implement SPF or get it wrong.   But in any case where there is no SPF record, the site is definitely not trustworthy: I cannot rely on the Received: header fields it included in the message.   And if the site _is_ trustworthy, then modulo a few small exceptions like Cornell, it's not originating anything that can be reasonably identified as spam, because if it could have been reasonably identified as spam, it would never have been forwarded.   So I can't see how the experiences you are describing would motivate the inclusion of something like an unobfuscated Received: header field across organizational boundaries if SMTP were being designed today.

> We don't use header chains for validation, we use it to figure out who
> to blame, who to alert, and who to block.

I don't know who "we" is here.   Is this really how Google, et al., operate?   It sounds like something people like you and me used to do ten years ago, that some of us old-timers are still doing (I only stopped using spamassassin recently, for example).   I would be okay with being proven wrong, but the fact that you are still doing this isn't persuasive to me.


--
Sent from Whiteout Mail - https://whiteout.io

My PGP key: https://keys.whiteout.io/[e-mail]