Fighting spam via greylisting

Felix M. Palmen zirias at despammed.com
Wed Apr 25 07:52:00 PDT 2007


* Ag. D. Hatzimanikas <a.hatzim at gmail.com> [20070425 12:04]:
> The logic behind greylisting is rejecting email with a temporary error 
> code -- which is defined in RFC 821 [1] and should be honored by the
> moderns MTA's-- so:
>    
>    - Any "well behaved" [2] MTA will try to resend the email, which is
>      exactly what we want.

And there's a key error in [2]. Consider [1], Appendix E, ``Theory of
Reply Codes'':

| 4yz   Transient Negative Completion reply
| 
| The command was not accepted and the requested action did
| not occur.  However, the error condition is temporary and
| the action may be requested again.  The sender should
| return to the beginning of the command sequence (if any).

So, the action /may/ be requested again, the sender /should/ return
[...]. To give up on any 4xx would indeed be "well behaved", too. 

>    - The spam software will see the error code (450) and quite possible
>      will not try to resend the email, considering as a dead connection. 

No, that's wrong. Spam software doesn't care about return codes at all,
that would only slow down the bulk mailer. The typical spam strategy
while processing the address list is "fire and forget".

As I mentioned earlier, I've seen a lot of spam mails hitting my host
twice lately. Well, that's exactly the one logical thing for spammers to
do: Still ignore all return codes, just let their spam-bots process the
address list twice. Indirectly, greylisting increases the spam problem
for everyone.

> Most anti-spam software make extra usage of the system resources, so by reducing 
> a good amount of spam with greylisting (hopefully), and freeing some system 
> resources, we can make a more extensive and careful filtering by the traditional 
> anti-spam software.

Reducing spam early is a good idea, but it should be done without
messing with the email standards. In fact, I can see from my logs that a
lot of spam is already rejected for protocol violation reasons.

> [1] http://www.faqs.org/rfcs/rfc821.html 
> [2] http://projects.puremagic.com/greylisting/whitepaper.html

Regards, Felix

-- 
Felix M. Palmen (Zirias)  \ -PGP- <fmp at palmen.homeip.net>  /"\  ASCII  Ribbon
web: http://zirias.ath.cx/ \ http://zirias.ath.cx/pub.txt  \ /     Campaign
my open source projects:    \ FP ED9B 62D0 BE39 32F9 2488   X  Against HTML In
http://zirias.ath.cx/?pg=pro \   5D0C 8177 9D80 5ECF F683  / \  Mail And News
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 307 bytes
Desc: Digital signature
URL: <http://lists.linuxfromscratch.org/pipermail/lfs-dev/attachments/20070425/233115b7/attachment.sig>


More information about the lfs-dev mailing list