On Thu, 2010-04-22 at 12:09 -0400, W B Hacker wrote:
> I'd suggest not using that RBL as a 'hard reject', but rather to
> merely add
> 'demerits' as part of a point-score. IOW - if the connecting host is
> in the RBL
> BUT does 'everything else' - or at least the important stuff - as they
> should,
> I'd do no more than (maybe) flag the traffic as 'Suspect'.
>
> In practice, we don't need to do even that here, as a 'real'
> backscatter would
> probably be blocked by earlier rules, an 'accidental' backscatter
> rendered
> harmless, and the chronically-errant locally LBL'ed. Perhaps
> 'forever'.
>
> Which saves yet-another RBL lookup...
My use of backscatterer.org in this way was brought on by a number of
incidents a few years back for which it seems perfectly matched. There
didn't seem to be any better protection I could add.
What happened was a joe job to thousands of servers each receiving
hundreds of thousands of emails "from" a hosted domain's valid email
address, but "to" an invalid recipient. Each of these servers did not
check SPF or DK of the source domain and certainly didn't check for a
valid recipient, but instead accepted the email and subsequently bounced
it.
Each of these servers was otherwise set up perfectly:
- matching HELO, PTR and A records
- patient and if deferred would return in 10m-4h
Each of the bounce messages was unique, possibly in a foreign language
and able to easily pass Spam Assassin. There was simply no way to stop
this tide of bounces. The spam runs were timed to hit between 2am and
10am local time which meant I was usually asleep for it and since these
were mostly small business servers that didn't take much traffic, I did
not have any alarms or limits in place.
All up I had 7 sites attacked like this, each with its own
unique .com.au domain with at least SPF configured on it. After the
first one, I thought it might have been just unlucky, after the second I
was worried and by the third I had found backscatterer and included it
all the configurations. Almost every bouncing host was already included
which cut the hundreds of thousands of emails down to 50ish accepted.
This is always what I imagined the backscatterer list to be useful for
and it still continues to prevent this kind of attack. I occasionally
see a speculator attempt but nowhere near the scale of the initial
attacks since they are no longer successful here. Unfortunately, it's
very hard to tell the difference between a callout and a bounce at rcpt
time. Hmm.. perhaps I should do the same protection I do for greylisting
and move that check to DATA until the host proves itself stupid and only
capable of only handling RCPT rejects.
> YMMV, but I believe that it can be 'fixed' at your end more reliably
> than at
> their end, if only because the supply of external fools will always
> exceed that
> of local experts...
I do have to agree there but I have been saved so many times now by the
backscatterer list. I have localised a large number of tests but this is
one I can't see me being able to do because I just don't have the data
source they do.
If you have some insight on how to block a seemingly good looking back
scatterer, I would love to hear it.
--
The Exim manual -
http://docs.exim.org
