Re: [ietf-smtp] [Shutup] Proposed Charter for the "SMTP Headers Unhealth

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/mellon(_at_)fugue(_dot_)com

pgpgxFVzeOejp.pgp
Description: PGP signature

_______________________________________________
ietf-smtp mailing list
ietf-smtp(_at_)ietf(_dot_)org
https://www.ietf.org/mailman/listinfo/ietf-smtp