[Greylist-users] idea: mis use temporary errors

Yaser Doleh yaser at doleh.com
Sun May 27 17:26:11 PDT 2007


The side effect of that is when somebody  sends a legit email message 
but mistypes the recipient address. That message will not bounce to the 
sender right away and the sender mail server will keep trying to send 
the message for few days.

Yaser

rbr wrote:
> 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:<Karen532 at ipconsult.nl>
>  Out: 550 <Karen532 at ipconsult.nl>: 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:<Karen532 at ipconsult.nl>
>  Out: 412 <Karen532 at ipconsult.nl>: 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
>
> -------------------------------------------------------
>
> _______________________________________________
> Greylist-users mailing list
> Greylist-users at lists.puremagic.com
> http://lists.puremagic.com/cgi-bin/mailman/listinfo/greylist-users
>   

-------------- next part --------------
A non-text attachment was scrubbed...
Name: smime.p7s
Type: application/x-pkcs7-signature
Size: 2657 bytes
Desc: S/MIME Cryptographic Signature
Url : http://lists.puremagic.com/pipermail/greylist-users/attachments/20070527/830d5240/attachment.bin 


More information about the Greylist-users mailing list