[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

[BULK] Re: SORBS contact



On Sun, Jul 31, 2011 at 2:32 PM,  <Valdis.Kletnieks at 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 at dirtside.com? bill at herrin.us
3005 Crane Dr. ...................... Web: <http://bill.herrin.us/>
Falls Church, VA 22042-3004