idea: mis use temporary errors
rbr <[email protected]> Sun, 27 May 2007 22:54:29 +0200
| Newsgroups | gmane.mail.spam.greylist.user |
|---|---|
| Message-ID | <[email protected]> |
Following an idea. We have tried it for a while, and it works, but it is a 'solution' that is open for debate. As you all know: [1] smtp knows temporary 4xx errors and permanent 5xx errors. [2] spammers worst enemy is time or delay, because with increasing time the chance of being blacklisted on Spamcop, Sorbs, etc is also increased. The second fact is one of the reasons why greylisting does work against spammers. The idea I would like to drop is a combination of [1] and [2]. Quite often we get mail like this: In: EHLO vsmtp105.tin.it Out: 250-ipconsult.nl In: RCPT TO:<[email protected]> Out: 550 <[email protected]>: Recipient address rejected: User unknown in local recipient table For reasons unknown to us, all kind of email addresses are 'tried'. Luckely they have not found any working email address yet. The trace as copied-and-paste above, is not coming from the usual dsl/cable/ppp-hacked-windows-PC, but from decent mailservers. Every detail like hostname, mx-record, etc, is correct. So, apparently there are a lot of decent mailservers that are available for spammers, for testing the existence of email addresses at our domains. A small extra piece of info: we do run a perl-script that checks the mail-logfile. Based on the mail-logfile, this perl-script does add IP-addresses to the blacklist of the firewall. Handling abuse at a firewall level is less expensive in terms of cpu then handling the abuse at mail-level. And it gives us the oppertunity to do a 'drop' at iptable level, which does result in timeouts for the offending mailhost. Something that result in timeouts for a offending mailhost is always good [2]. The idea is as follows: we have changed permanent 5xx error to a self-defined 4xx temporary error. This is, off course, a violation of the RFCs. But the result is kind of funny. Those temporary errors codes are pickup up by the perl script, and the offending mailhost is placed in the blacklist at TCP/IP level, with a drop rule. Because the offending mailhost did receive a 4xx error, he keeps on trying for a couple of hours up to 2 days. Those retries do not bother us, because it is handled quite effeciently by ip-tables. The result is: In: EHLO vsmtp105.tin.it Out: 250-ipconsult.nl In: RCPT TO:<[email protected]> Out: 412 <[email protected]>: Recipient address rejected: User unknown in local recipient table ..... shorewall drop vsmtp105.tin.it Any comments on this? Mis-use of temporary 4xx errors in combination with a drop-rule in the firewall, with the objective that the offending mailhost is waisting time. RbR-IPConsult BV -------------------------------------------------------