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 -- ## List details at http://lists.exim.org/mailman/listinfo/exim-users ## Exim details at http://www.exim.org/ ## Please use the Wiki with this list - http://wiki.exim.org/
