Re: SPF and bouncing

Michael Deutschmann <[email protected]> Fri, 4 May 2012 05:12:14 -0700 (PDT)
Newsgroups gmane.mail.spam.spf.discuss
Message-ID <%[email protected]>
On Fri, 20 Apr 2012, Scott Kitterman wrote:
> ...  I think everything's been said and people are repeating themselves.
> Please leave it.

Okay, I'll agree to disagree on the fine points of the Conspiracy
Against Bounces.  But on further reflection, that doesn't let SPF off
the hook.  Reform is needed no matter who was right, it's just different
reforms.


If I'm right, and the Conspiracy treats all bounces of
SPF-neutral-or-worse mail the same, then an alternative SPFv3 qualifier
that says "This is definitely not forged.  However, notwithstanding the
implication that a bounce of this message would never be backscatter, you
must still treat delivery as absolutely final, 'cause I'm doing leet hax
that count on the absence of bounces." would be useful.

If Alan is right, and the Conspiracy only applies to a subset of bounces
that are relatively easy to prevent and would be extremely common if not
so prevented (that is, spam filters and nonexistent addresses), then we
have a different problem, actually even more serious.

To avoid spammers using "MAIL FROM: <>" as a "skeleton key" that opens
all the mailboxes, a whitelisting site would have to use VERP such as
BATV.  But automatic whitelisting fails when other people VERP in the
same way.  We have a sustainability problem.

I'd fix that by coming up with a "standard SPF VERP", and then adding a
modifier to SPFv1 to indicate that it is in use.  Then without the
modifier, the existing precedent that SMTP local parts are opaque would
apply.  With the option, the recieving MTA would be encouraged to apply
a published algorithm to derive a whitelist key from the MAIL FROM it
sees.

(If BATV was adopted as the standard VERP, then the algorithm would be
"discard text from the left of the localpart up to and including the
second '=' character, keep the rest.".)

---- Michael Deutschmann <[email protected]>