Index: [Article Count Order] [Thread]

Date:  Wed, 20 Sep 2006 12:27:10 +0200
From:  Michael Stauber <bq (at mark) solarspeed.net>
Subject:  [coba-e:07110] Re: greylisting.org
To:  coba-e (at mark) bluequartz.org
Message-Id:  <200609201227.10858.bq (at mark) solarspeed.net>
In-Reply-To:  <00f901c6dc9d$f64d38f0$3701a8c0@lapxp>
References:  <00f901c6dc9d$f64d38f0$3701a8c0@lapxp>
X-Mail-Count: 07110

Hi Arthur,

> Does anyone use the greylist from http://greylisting.org/ ?
> It supposed to be a great future, but I find the technique a little
> doubtful.
>
> Would you share your experience ?

Yes, I've been using Greylisting for about two years on one of my mailservers 
and about 3 months ago also tested it on a BlueQuartz box (implemented 
through a Sendmail-Milter). I usually don't use it for business related email 
accounts, but some of my exposed email accounts (those that I need for online 
shopping, for website registrations or in WHOIS information).

Greylisting has ups and downs. Usually people are accustomed to the fact that 
an email "instantly" reaches its destination. With Greylisting that will not 
be the case, which is the whole purpose:

Greylisting delays inbound emails for a configureable amount of time. During 
that period the Greylist-using-MTA will flatly refuse to accept the email 
from the sender with "service temporarily unavailable". The sending MTA will 
simply queue the message and will repeatedly try to send it again. 

Eventually the Greylist-using-MTA will accept the email and it will reach its 
destination just fine.

Spammers are often using botnets or applications to send emails which don't 
incorporate all the MTA features like queuing mails. They just want to send 
the most amount of emails in the shortest possible time. So their SPAM-MTA's 
cut a lot of corners to achieve that purpose. Like not accepting bounces and 
returns, or not waiting excessive amounts of time for remote MTA's to accept 
connections.

This is where Greylisting kicks them square in the face. With Greylisting 
enabled you will receive a bit less SPAM, as those from SPAM-optimized MTA's 
and SPAM-sending applications will mostly be weeded out - at the level of 
your MTA and before any actual SPAM-filtering takes place. That can save you 
some CPU-cycles if you're using additional SPAM fighting mechanisms like 
SpamAssassin.

There are several Greylisting approaches imagineable. I use one that allows 
whitelisting and keeps a backlog of the message history. If I have already 
received mail *from* that email address in the past, then the delay will be 
shortened step by step for each email. After a configureable amount of time 
without activity from that address (a few days or weeks - for example) old 
email addresses are purged from the whitelist.

If I already emailed *to* that address in the recent past, then the mail will 
be allowed to bypass the Greylisting entirely - also for a configureable 
amount of time.

OTOH a fair chunk of SPAM (if not the majority of it) comes from regular MTAs 
on servers which either operate in countries with relaxed, unenforcible or 
non existant rules in regards to SPAM (USA, China, Taiwan, Indonesia for 
example). Or it comes from exploited/hacked servers with regular MTAs. 
Greylisting will be mostly useless against SPAM from those.

So Greylisting alone won't protect you from SPAM entirely. It may not even be 
able to catch more than 5-20% of your SPAMs. If used in conjunction with 
other SPAM-fighting mechanisms it may have its role, though. 

Of course the most obvious backdraw is that your inbound email traffic will be 
delayed, which can be unacceptable. Imagine that typical customer call where 
the customer says: "I just emailed you that info a couple of minutes ago! You 
*should* have it already!". Well, thanks to Greylisting that mail may not 
arrive for the next 15 minutes. That can be a bit embarassing to explain. :o/ 

-- 

With best regards,

Michael Stauber