[143165] in North American Network Operators' Group
Re: [BULK] Re: SORBS contact
daemon@ATHENA.MIT.EDU (Valdis.Kletnieks@vt.edu)
Sun Jul 31 19:55:17 2011
To: William Herrin <bill@herrin.us>
In-Reply-To: Your message of "Sun, 31 Jul 2011 18:36:22 EDT."
<CAP-guGVtc-9axEHrWm6uXuK_x4=A2yGJaMQ9eR=qd=dp+xR8bA@mail.gmail.com>
From: Valdis.Kletnieks@vt.edu
Date: Sun, 31 Jul 2011 19:53:58 -0400
Cc: nanog@nanog.org
Errors-To: nanog-bounces+nanog.discuss=bloom-picayune.mit.edu@nanog.org
--==_Exmh_1312156438_23760P
Content-Type: text/plain; charset=us-ascii
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.
--==_Exmh_1312156438_23760P
Content-Type: application/pgp-signature
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.11 (GNU/Linux)
Comment: Exmh version 2.5 07/13/2001
iD8DBQFONesWcC3lWbTT17ARAoN1AJ9tXKIjQiUhiO334IdYpPFvW27oIACgvTuN
NwLFteKg0cTOSe47MI3xB+E=
=bQZH
-----END PGP SIGNATURE-----
--==_Exmh_1312156438_23760P--
