[Sussex] SPAM Filtering Revisited

[Steven Dobson]

Andy

On Sun, 2006-08-20 at 19:50 +0000, Andy Smith wrote: 
> I do not believe it is acceptable to use sender callback
> verification (i.e. actually making callouts to a remote mail server
> to see if mail for a given address would be accepted) as it puts an
> unfair load on innocent mailservers that happen to have been forged
> in to the mail.

Fair point.  I accept that Sender CBV does put a extra load on MXes, and
I hadn't concidered the load it would generate for a forged sender
address - I only concidered faked and ligitmate which I thought
acceptable.

> Sender CBV is much much better than accepting the mail and then
> bouncing a DSN back to the forged sender (in the above scenario I
> would then receive thousands of bounce messages for mail I never
> sent, which is far worse than just connections that check for
> deliverability without actually doing a delivery).  But I believe it
> to be far too abusive on inncoent uninvolved parties if everyone
> were to implement it.

Given that CBV is not as onerous as a DSN storm aren't you better off
accepting the CBV load?  CBV requires no human intervention.  Aren't
completely automatic the best way to stop spam?

But to make CBV more acceptable what is needed is some kind of centeral
database that will do the query for us.  Something like
rfc-ignorant.org.  I see it working like this:

  1). An MTA receives a SMTP connection which issues the command:
        MAIL FROM: fake-sender at example.com

  2). Before accepting the command it makes a DNS request of
       fake-sender.-at-.example.com.cbv.spam-beaters.org

  3). If the DNS response is blank then the incoming message cab be
       accepted (subject to other checks).  If the DNS response does
       contain an address (something in the loopback range like the
       other DNS blacklists) then the incoming message is rejected.

This way the CBV load on MTAs will be negliable, and I would have though
acceptable given that it will only be a few spam-beaters.org servers
that are making the CBV requests.

> Get rid of bounces and stop there.

But the SMTP protocol [RFC821] requires that a DSN be generated if an
e-mail can't be delivered.  Is there a proposal out to change the
standard?  I can't believe (given what you've posted on other threads)
that you're advicating a policy that is unlikly to be widely adopted
without such a change.

> When implementing anti-spam measures I urge people to consider what
> effect it would have on remote sites if everyone did it.  Lack of
> consideration for third parties leads to ideas like sender CBV and
> challenge-response.

Not an unreasonable request.  However, as you also pointed out in  the
other thread, mail forwarding creates a problem with checking e-mail
baded on origin.  To fight spam we need methods that work with the
current way e-mail is handled or, as spam gets worse, there is going to
come a time (if it hasn't already) where e-mail is unusable because of
the spam load.

Steve