On Tue, 2005-12-06 at 10:50, Rodrigo Barbosa wrote: > -----BEGIN PGP SIGNED MESSAGE----- > Hash: SHA1 > > On Tue, Dec 06, 2005 at 10:36:12AM -0500, Scot L. Harris wrote: > > > > That is why I like greylisting. Very little resources required and in > > my experience it blocks 98% or better of the spam I see. Prior to that > > there would be days when a spam storm would hit and backup email for > > several hours. Spamassassin did a good job of sorting it out but it > > took all of the systems resources to handle it. > > > > And with greylisting you are not dependent on someone else's RBL lists > > or connectivity to a system somewhere on the Internet. Once setup it > > has required little if any additional admin work to keep it running. It > > actually allowed me to pretty much get out of the business of fighting > > spam which had started to consume a large amount of my time. > > > > And with the combination of greylisting and spamassassin it is rare that > > any spam gets through to an end user. > > There are many definitions of graylisting. But since the "click here > to validate your e-mail" is the most common on the mind of the > people I have contact with, I'll assume that is the (main) one you > are reffering to. Please correct me if I'm wrong. > > When I send e-mail and I get back a message like that, 90% of > the time I'll simply ignore it. The other 10% is when there is > some money for me relatated to the e-mail I'm sending. > > A secondary problem is that practice will for users to click on > links on e-mails, which is not something I want my users doing without > thinking about. Good habits are to be cultivated, and bad habits > are to be avoided at all costs (says the guy who smokes 2 packs a > day :)). No no no! That is not the greylisting I am talking about. You implement greylisting on your MTA using something like milter-greylist. This uses standard RFC compliant behavior documented for MTAs to block most zombie systems which send spam from send to your MTA. The way it works is when a server connects to your system to deliver email your system sends a temporary failure notice. Prior to sending the temp fail it stores the IP address of the server, the sender, and the recipient of the message (a tuple). This tuple is stored and a timer is set. I used 2 minutes, the default is normally 30 minutes. I found 2 minutes worked just as well. That 2 minute timer is a delay imposed before your MTA will accept that message from the remote server. The remote server may retry very quickly or retry in 30 minutes. Eventually a proper MTA will retry the message. Once the delay period has expired your MTA will accept and deliver the message. The way this blocks 98% or more of the spam out there is zombie machines spewing spam do not abide by the standard MTA rules. They generally dump and run and do not retry messages. I was amazed at how effective this method is. You benefit by not having to read the body of the message or incur the overhead of processing those messages through spamassassin or other spam filter or additional network traffic by querying RBL lists. You can also put specific IPs or addresses in a whitelist so those will not have to go through the greylist process. The time an entry is auto whitelisted can be adjusted as well. I usually have this set to 48 hours. Any additional messages for that same tuple in that 48 hour period won't be delayed again. The combination of greylisting and spamassassin provide about as close to 100% spam elimination as any other method I have seen.