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? You asked if I wanted mailing list confirmation requests that arrive at my mail server to have a non-null return path. My answer was yes I do. And I still do. Even if it means I'm the one who gets stuck generating a deferred bounce because the final recipient downstream turned out to be non-deliverable.
And even at that point, that Barracuda is almost certainly *still* broken, because I'm pretty darned sure it doesn't include code that says "reject MAIL FROM:<> unless it's a specifically blessed MDN, DSN, bounce or other RFC-compliant format", it's just got a "reject <> yes/no" switch someplace.
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. If my speculation is right, the Barracuda is behaving reasonably and SORBS' use of the null return path ignores the SHOULD in an ill considered manner. If your speculation is right, the Barracuda's design bug is exacerbated by SORBS' ill considered use of the null return path. Either way, SORBS' ill considered use of the null return path for the confirmation messages (disregarding the SHOULD in RFC 5321) contributes to fully broken mail delivery behavior. That last sentence there, that's my claim. Regards, Bill Herrin -- William D. Herrin ................ herrin@dirtside.com bill@herrin.us 3005 Crane Dr. ...................... Web: <http://bill.herrin.us/> Falls Church, VA 22042-3004