On Sun, 31 Jul 2011 18:36:22 EDT, William Herrin said: > On Sun, Jul 31, 2011 at 2:32 PM, <valdis.kletni...@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.
pgprxWoqvJxDU.pgp
Description: PGP signature