Re: [exim] Sender verification

"Alan J. Flavell" wrote:
> 1. Do we have a compelling business case to want to hear from them?
> Then don't do callouts on that domain.
>
> 2. We conclude that they don't participate properly in email, so we
> don't want to hear from them. Implement the <> callout, and let them
> block their own mail until they learn better. (As you see, this
> repairs itself automatically as soon as they start accepting bounces,
> without any extra work on our part).

Ah, you folk in acedemia might not then have encountered the argument
from a paying customer "I don't care if the admin of the site hosting
my prospective customer is a fool, your decision to not accept their
mail on the basis of the failed callout is costing me potential
business".

> It stops quite a number of spams for us, from offering MTAs for which
> we'd have no other reason to refuse the item *without* the overhead
> of spamassassin rating - which means it's a net benefit to us.

I wasn't clear. It did stop several spams from making it to our
SpamAssassin cluster, but the overall daily increase n scanning
load was less than 5% of one hours load.

Your SpamAssassin overhead is nobody elses concern but your own.
Don't steal resources from others to make your life easier. If you
do, you really are not much better than the spammers that have the
same practice.

> I'm keenly aware that when the presented envelope-sender is a fake, it
> means we're using a (small amount per transaction of) some innocent
> third-party's resources in order to keep the spam out. That isn't
> nice, really (as Suresh emphasised on this list in the past); but, as
> I say, it seems to me that if it's done selectively, it's not too
> harmful overall. And in many cases the faked sender is fixed, so,
> after being tried and repudiated once, the answer gets cached, and
> repeat offerings of spam are refused "for free", without bothering the
> innocent third party.

And that is a nice intellectualisation. One domain on one of our
servers was the target of a joe-job recently. Using the bounce
recipients and the originating server as the key to obtain a sample
for uncached callouts, the callout load would have only been halved
by caching (there were about .5M unique local parts - randomly
generated and continuously morphing). That's not a significant
reduction. I should point out that the callouts alone from this
run made mail unusable for the innocents on this system for
unacceptably long. This was not because the callout processing is
computationally intenisve, but because they are connection intensive.

What I don't get is why you (and many others) think it's OK to:
1. Steal resources.
2. Participate in a DDoS attack (of innocents to boot).

By all means use sender callouts on your smart host to verify your
senders angainst your MX.

Ian

--
Ian Freislich