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
