Re: [exim] Sender callout verification with warning only

Phil (Medway Hosting) napisał(a):
> Do you realise that callouts are considered abusive in anti-spam circles and
> are often used in certain forms of ddos attacks ?
Using "collateral callout" for DDOS to attack host B seems kind of
pointless, because the attacker is sending spam to the host A that is
known to use callouts that will go out to B, which costs attacker at
least as much as attacking host B directly.

That's assuming host A is not using any caching and Exim does callout
result caching after all.

> Some major mail servers
> even BLOCK based on the number of callouts they receive from a given IP.
>
If so, that's a wrong policy, but that's not much of a problem anyway
with exim's callout cache. At least we have never had problem of this
kind on our "shared hosting" hosts.

> Something like 80% of emails are spam, so 80% of your callouts are being
> directed at totally innocent machines.
Which means that if everyone used callouts for every single e-mail, at
absolute worst each legitimate e-mail would get 4 halfves of SMTP
session initiations (hello, mail from: <>, rcpt to:
verified.address@domain) of "callout overhead" directed at someone
(possibly even at spammer or zombie). Frankly, that's ridiculously low
cost. A bored teenager watching one YouTube video on Sunday afternoon
probably wastes more bandwidth than callouts use up in the entire world
on that day.

If callouts cut only 20% of spam, and in my experience they allow
cutting much more, that is still much more of gain in terms of sheer
bandwidth used up by respective activities (callouts vs. increase in
volume of spam that callouts would have eliminated had you not used
them). What about user irritation with spam? What about bigger load on
the mail servers that have to scan mail for spamminess?

Just today on one of my hosts:

% grep "virtual_localdelivery" mainlog | wc -l
2947
(legitimate local mail in our config)

% grep "rejected RCPT" rejectlog | wc -l
6217

% grep "spamd: result: Y" /var/log/maillog | wc -l
923
(that's SpamAssassin evaluating mail as spam obviously)

We get pretty clean mail feed, and the above shows that at least in our
case callouts do wonders in cutting down the volume of spam. Bandwidth
use for callouts is minimal, while in terms of CPU time it's a gain,
too: SA itself is pretty heavy, if it had to scan all the mail that are
rejected thanks to callouts, it would cause high load on our hosts.

Frankly, if callouts for every single email cut down even 10% of spam,
such tradeoff would still have been way more than worth it.

Note: rejected RCPT today is a net _gain_, not loss! That means that
spammer has been prevented from sending mail _in someone's name_! I
don't know about you, but I would be more than happy to pay a cent more
each month for hosting account to get my e-mail address protected this
way. Complicated technological explanations about intricancies of e-mail
envelope tend not to be understood at all by customers and users who
aren't techies: from their POV e-mail sender address should be something
trustworthy (and insistence that realities tend to be kind of opposite
is often met with hostility directed at me, as if I were the guilty
party here).

There's even overlooked opportunity here: suppose callouts were part of
SMTP protocol and if callout failed, mail would be rejected, no
questions asked. Further in the process of evolution of e-mail this
would allow easy and possibly automated identification of legitimate
mailservers (we could think of software that would ask other mailservers
in cooperative network "has this host been sending legitimate mail to
you?") vs malicious hosts.

Yes, callouts do cause minimum costs, but they give a lot of gains, too
- it's a tradeoff.

Callouts can be considered abusive only if you ignore their context,
look only at their negative side effects and overlook at their positive
side effects.

> Challenge response methods should be
> considered in the same way.
>
That's fine with me, but only once you get rid of nearly all spam first.

--
Marcin Król