Greylisting -- Was: Anti Spam

[Ted Mittelstaedt]

> -----Original Message-----
> From: owner-freebsd-questions at freebsd.org
> [mailto:owner-freebsd-questions at freebsd.org]On Behalf Of Christopher
> Hilton
> Sent: Wednesday, April 25, 2007 3:25 PM
> To: Grant Peel
> Cc: Eric Crist; freebsd-questions at freebsd.org
> Subject: Greylisting -- Was: Anti Spam
>
>
> Just my $0.02. Have you considered adding greylisting. I find the
> combination of greylisting and Spamassassin with the SA's bayes filter
> completely handles my spam problem. On my primary MX I use spamd on
> OpenBSD and on my secondary MX I use spamd on FreeBSD. As a very
> informal method of measurement my Inbox.spam folder, held an average of
> 400 messages per day in October before I started using spamd. It
> currently averages about 80 messages per day.
>
> If you don't know about greylisting it works as follows. A greylister
> monitors port 25 for inbound mail connections. When a server connects to
> this port to exchange mail the greylister predetermines the response
> based on whether or not this server has exchanged mail in the recent
> past. If it has it's allowed to exchange mail again and the server's
> timestamp is updated. If the server has not exchanged mail in the recent
> past the greylister responds: "45x - I'm too busy to talk to you right
> now. Please try to deliver this mail later". It then puts the server and
> information about the mail being delivered onto a list. If the same
> server tries the same message later it passes and the greylister
> promotes the server onto it's list of okay mail servers (mail servers
> that it has exchanged mail with in the recent past).
>
> Greylisting works because many, and I'd like to say most, spam programs
> never retry message delivery.

Actually, no.  Greylisting works because it delays the spam injector
long enough that the injector will get blacklisted by the time that the
greylist opens the door for the mail to come in.  Greylisting alone
by itself is getting less and less effective every day.  Spammers are now
starting to setup spam injectors to retry.  If you think about it, it is
very easy to program.  Simply create a list of victims, iterate through
the list once, deleting all the victims that accept, then wait several
hours and iterate through the list again.  It didn't take a rocket scientist
to figure that one out.

Since SA has a lot of the major blacklist servers as score-feeders, the
spam that gets past the greylist just gets tagged by SA.

> The best thing about greylisting is that
> combines well with filters like SA by reducing the amount of mail that
> they have to see. In my case something like 80% of the mail that
> Spamassassin used to process just never gets past the greylister today.
>
> The downsides to greylisting is that it delays the first message from a
> legitimate mailserver. In the most common case the incurred delay will
> be between 30 minutes and an hour. This assumes that then sending mail
> server retries queued mails every half hour or so. In an extreme case
> the delay may be longer. If the mail sender has a cluster for delivering
> outbound mails and that cluster features shared message storage and
> several processing units to handle the smtp transfer then the greylister
> will trap that message until the same server attempts redelivery. This
> is a problem with mail coming from very large internet companies like
> Google or AOL or very distributed corporations like General Electric,
> Unilever or United Technologies.
>

That is why the greylist milter (that you use for sendmail) has an exception
list.  There are not many large senders that do this and it is easy enough
to figure out who they are.

> Since you are in an ISP environment greylisting may not be something
> that you can do. I was extremely surprised when a client told me that
> the 1 hr delay in receiving mail from new and infrequent mail servers
> was too much to pay to stop the spam coming into his mailbox.

That should not be a problem.  The current greylist milter port allows
you to define clients email addresses like this as an exception that won't
get the benefits of the greylist, while allowing everyone else on the server
to
continue to enjoy it.

> I don't
> claim to know the political layer as much as I do the technical one.
>

There are legitimate technical reasons that someone may want their mail
to not be greylisted.  For example, my cell phone's e-mail address is
in our monitoring scripts to page me in the event of a server failure.
I would be pretty pissed off if Sprint suddenly started greylisting.  It
isn't just dumb-ass users making stupid political decisions to reject
it, although in your case it probably was.

Ted