Posted by Steve on Fri 24 Jun 2005 at 12:27
Greylisting is a relatively recent approach which is designed to cut down on the reciept of incoming SPAM messages. Rather than something running after the mail has been received it attempts to ensure you don't recieve mail from spammers in the first place by rejecting messages at SMTP time.
Like many anti-SPAM methods it is seen by many as a controversial approach because it can result in the loss of legitimate mail.
However in many cases the benefits outweigh the drawbacks, and whilst there exists the risk that mail will be dropped the sender of the mail will see an error message - so there's no risk that the mail will be dropped "silently" as with some other anti-SPAM solutions.
Greylisting is a simple means of attempting to combat incoming mail SPAM with multiple implementations for different mail servers:
Each of these packages work in the same way, the difference comes from the way they hook up to the mailserver itself. There are is non-mailserver specific software around, but these must be configured more.
What normally happens when mail is delivered to your mailserver is fairly simple:
An incoming connection is made from the machine that wants to send mail, (OK possibly that machine directly, or possibly another mail server en route), and the mail is immediately accepted by your mail server.
(There may well be more steps for your mailserver - for example you may filter virus mails at SMTP time.)
With the installation of greylisting things change:
When a new connection is made to your mailserver to deliver a mail the server will check that this is permitted:
- If the remote machine has previously attempted to deliver mail to the given address it is allowed, and everything works as it did before.
- If this is a message from a machine which has not previously connected the server will respond with a temporary error.
The intention is that incoming mail messages will initially be given an error code - and they will then queue the message.
After a while they will retry the original delivery. At this point the mailserver with greylisting upon it will realise that this client previously attempted to deliver the mail and allow it.
So what does this mean?
If this was a legitimate server which sent the message then a bounce will eventually be generated informing the sender that their mail was not delivered.
In practical terms this should all work out, so long as you are not averse to having your incoming mail subjected to delays due to the retry period.
Installing the software and configuring it is very straightfoward:
apt-get install greylistd
To configure the software there's a helpful tool installed, called greylistd-setup-exim4 whihc you use to update your exim4 configuration file(s) easily, although I'd suggest you backup your existing configuration first by running:
cp -R /etc/exim4 /etc/exim4.pre-greylist
Once you've got a good backup you can update your exim4 configuration by running the following command:
greylistd-setup-exim4 add
(If you don't wish to risk this you can see exactly what needs to be changed by reading the documentation in /usr/share/doc/greylistd.)
The greylist deamon can be adjusted via the file /etc/greylistd/config, this allows you to setup the length of time before a retry will be accepted. By default this is an hour, I've reduced my server to 30minutes.
You can also setup a list of hosts which will never be greylisted via the file /etc/greylistd/whitelist-hosts. This will augment the whitelists which are kept in /var/lib/greylistd/whitelist-hosts - which will be upgraded with the package, and shouldn't be editted by hand.
Once that's done you'll be working with greylisting. You can keep an eye upon the mail which is being temporarily rejected by looking at the logfile /var/log/exim4/rejectlog.
Mail which has been rejected will appear with an explaination. This is a sample entry:
2005-06-21 21:34:33 H=mail6.optimalorigin.com [65.196.164.6] F=<info-smlsm@netsingular.com> temporarily rejected RCPT <sexy@steve.org.uk>: greylisted.
As with all SPAM solutions this technique could become less effective over time, as spammers start using mailing software or zombie hosts which will retry deliveries.
However even if that occurs we've achieved something - reduced SPAM throughput from the senders. Maybe not much, but hopefully enough to reduce the total volume of mail sent in any given day..
This article can be found online at the Debian Administration website at the following bookmarkable URL:
This article is copyright 2005 Steve - please ask for permission to republish or translate.