On Sun, 31 Jul 2011 18:36:22 EDT, William Herrin said:
On Sun, Jul 31, 2011 at 2:32 PM, <Valdis.Kletnieks@vt.edu> wrote:
That sort of shoots your "If Woody had gone straight to the SPF record, none of this would have happened" claim.
My WHAT claim?
What you said:
2. I assume the subscription request came from a web page because if it was from an email request you received then you ignored my SPF records when generating the confirmation request. That was OK in 2001 but in 2011 you ought not be doing that.
However, we've established that the if the email request was from the domain that actually *started* this thread, the SPF data would *not have mattered* - even if it *was* checked, the fact it contained a '?all' would *not* have stopped the subscription request from being passed on. And before you start saying "but then they've got their SPF misconfigured" - remember that in 2011, we *still* don't have enough sites with SPF configured *correctly* that we can start chopping out code on the basis of "this case can't possibly happen with proper SPF, and almost never happens in the production Internet". And as I pointed out, there are a *lot* of failure modes that make you wish you can ditch the bounce message that are *not addressed at all* by SPF. Bounces caused by forged messages are just *one* issue - and even that's one that SPF doesn't actually address.
I'll see your wild speculation and raise you mine. The Barracuda is designed to protect enterprises where the mail can only go out one path -- through it. It auto-whitelists folks its users sends mail to and allows bounce messages for those destinations based on pattern matching in the message content... before discarding other messages with a null return path.
Presumably you're referring to this press release: http://www.reuters.com/article/2008/08/21/idUS127450+21-Aug-2008+BW20080821 However, it has the same problem as any other auto-whitelist - it can only whitelist those things it knows about. The press release talks about NDRs - but is silent on DSNs, MSNs, and other RFC-blessed uses of a null return path. And even if it *does* DTRT for all current standards-path RFCs, that *still* doesn't change the fact that what it's basically doing is saying "We're unilaterally insisting that the 'SHOULD have a non-null' is actually a MUST, and enforcing it". They are of course welcome to do so, but they're not allowed to complain when elevating said SHOULD to a MUST causes some mail to be lost because the mail came from a site that's still following what the RFC actually says, not what Barracuda or the recipient site *wishes* it said. Let me repeat that: You're certainly allowed to be stricter than the standard. However, you're *not* allowed to complain when being stricter than the standard results in failures dealing with less-strict-but-still-standard inputs.