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.
