Re: [BULK] Re: SORBS contact

[Valdis.Kletnieks () vt edu]

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.

Attachment: _bin
Description: