Re: SPF and bouncing

alan <[email protected]> Fri, 04 May 2012 21:22:48 +0100
Newsgroups gmane.mail.spam.spf.discuss
Message-ID <[email protected]>
At 20:38 04/05/2012  Friday, Michael Deutschmann wrote:
>On Fri, 4 May 2012, Scott Kitterman wrote:
>> Spammers to have not adapted to SPF by moving to null mail from's.
>
>It's not an adaptation to SPF, and is indeed counterproductive for the
>spammer /at this time/.  It's an adaptation to sender address
>whitelisting combined with harsh standards to accept non-whitelisted
>mail, perhaps to the extreme of goldlisting.

it dosn't happen and is unlikely to


>Goldlisting has two chinks in the armor.  The first is that the spammer
>may guess an e-mail address that the victim corresponds with, and ride on
>that person's reputation.  The second is that the spammer uses <> and the
>sysadmin, refusing to be "RFC-Ignorant", lets it through on the off chance
>it might be a genuine bounce.

there are smarter ways to allow someone to goldlist and verify legitimate from bogus bounces
(verp such as batv is the simplest and common among any worried by this possibility)

>The first threat doesn't worry me, since we have SPF.  Sure, I have
>plenty of correspondents with weak/absent SPF policies, but should the
>spammer find one, I can apply concentrated pressure to that specific
>friend to have his ISP deploy -all.  Once that hole is plugged, the
>spammer has to start all over.
>
>But I don't see a good "next move" for the good guys if spammers use the
>second strategy, other than refusing all putative DSNs. 

they wont simply because
A that means they can only spam sender address' (currently they spam receiver address' mainly, receive only address' do and can legitimately block all mail from <> ie sales@ postmaster@ support@)
B at the time this happens (which it won't) it would simply cause people to mass move to verp/batv, thus never again using a receiver-address as a sender

> VERP (such as BATV) doesn't count since, unless a VERP-decoding SPF extension is
>adopted, your whitelisting only works if your correspondents don't VERP.

this has already been shown to be a spurious argument
whitelisting VERP senders is common and easy, or no 'goldlister' could ever subscribe to any mailinglist,
the tech and software to do this has already been trivially implemented widely
simply accept mail from *@whitelinsted-domain at rcpt (assuming spf pass /helo/ptr/dnsbl etc.)
then check for From: Sender: etc containing whitelisted-sender@whitelisted-domain at data (and if from non-whitelisted neighbour reject)

really simple (and thats just one way to do it)

spf is not a tool to solve issues that do not yet exist (especially when the proposed solution will do more damage than good)
if spammers start sending en-mass from <> (which usually guarantees the mua can immediately see its not a bounce and spamfolder them)
then another solution will be found, spf is a tool for sender validation, and expression of the senders policy of what should happen to invalidated mails, it has no place for specifying the senders wilingness or unwillingness to receive/refuse bounces, and shouldn't