Steve Atkins wrote:
Were you around for the fiasco that was SPF?
SPF FAIL works as designed, stopping forgeries of Return-Paths,
thanks for asking. Spammers understand how SPF works, now it
is merely a self-fulfilling prophecy.
our operational experience of throwing away perfectly good
mail, simply because it wasn't transmitted in a way that
followed the dogma of the message signers came from.
As soon as somebody throws mail away for whatever reason they
should be ready for some years in jail, unless it's their own
mail of course. SPF policies SHOULD be checked at the border
MTA during the SMTP session, and at that point in time the
only realistic behaviour of a server is to reject FAIL. Not
accept and throw away, that's madness, nobody would do this.
SPF policies (which are very much equivalent to SSP)
They are completely unrelated. SPF is an SMTP protocol, not
some mail-magic like DKIM or SenderID. SPF is about the HELO
and the envelope sender, not about obscure identities like a
PRA, or the utter dubious 2822-From SSP ideas discussed here.
that are published are almost "?all", which is pretty much
equivalent to "I sign some things" in SSP speak.
No, an SPF PASS is still better than nothing, a bounce or any
other kind of auto-reply covered by RFCs (i.e. going to the
envelope sender) won't hit innocent bystanders. SPF FAIL and
SPF PASS both have a clear meaning wrt SMTP.
People wouldn't tolerate mail being thrown away for no good
reason
That's why it's so important to reject mail a.s.a.p. Anything
else is unreliable.
nor were even the developers of SPF prepared to modify the
way in which they forwarded email around in order to work
around the flaws of SPF.
That's complete rubbish. The concept of a "reverse path" is
older than RFC 821, and SPF revived it after the situation
with the broken RFC 1123 5.3.6(a) got out of hand. The same
loophole that established open relays. "Just modify RCPT TO"
never worked, it was always wrong, from day one of RFC 1123.
There seems to be some belief that if SSP does exactly the
same thing as SPF then we'll pull the phishing-proof, spam-
resistant mail architecture out of the hat this time.
A lousy chance based on PRA (SenderID). Zero chance based on
2822-From, the concept makes no sense, it's incompatible with
tons of special cases with PRA != 2822-From.
Frank
_______________________________________________
NOTE WELL: This list operates according to
http://mipassoc.org/dkim/ietf-list-rules.html