RE: [Exim] Sender Verify

Pàgina inicial
Delete this message
Reply to this message
Autor: Alan J. Flavell
Data:  
A: Exim-Users (E-mail)
Assumpte: RE: [Exim] Sender Verify
On Thu, 1 Jul 2004, David Brodbeck wrote:

> It's also a slightly controversial thing to do


Fair comment. Just for the record: we attempt callout verification on
a selective basis. Some details have been posted before, but I simply
wanted to make clear that we don't attempt it in every case; and
what's more, many of the mails where we -would have- attempted to
verify the sender address are already getting rejected earlier in the
ACL for other reasons. So we can't be accused of using a shotgun
approach.

> because it can consume
> resources on unrelated sites. If somebody spoofs a bunch of mail with
> example.com as the return address, suddenly example.com has to deal with
> responding to callouts for mail it never sent.


Correct, but we also play our own part by consuming our own resources
in rejecting bounces addressed to non-existent addresses in our own
domains. So I think there's an element of fairness.

By the way, we really have no idea (at the point in the RCPT ACL where
we issue the rejection) whether we are rejecting an actual bounce
(non-delivery report), or servicing a callout request from someone who
uses sender address verification. It's a pity we don't know this, if
only for statistical reasons.

> It's undeniably a very effective anti-spam technique, though.


But only as long as spammers are faking refutable sender addresses.
If we all started doing callout, they'd have to adopt some other
scheme, and then the technique would become useless.

So it's a defence mechanism that works well as long as only a minority
of sites are using it. Several other antispan defences are like that
too, which means one inevitably has misgivings about promoting their
use by others :-}

Furthermore: the response to callouts can be misused by spammers for
"laundering" their address lists. Which is why we try as many other
measures as possible for blocking abusive transactions before
resorting to this technique.

hope that helps