Requirements
Features
Weaknesses
Mailing list, wiki
To do list
Downloads
License
Contributors
Translations


Tired of sorting your spam?
Try out milter-greylist


News milter-greylist is not dead, it is just mature, and does not release often.

milter-greylist is a stand-alone milter written in C that implements the greylist filtering method, as proposed by Evan Harris.

Grey listing works by assuming that, unlike legitimate MTA, spam engines will not retry sending their junk mail on a temporary error. The filter will always reject mail temporarily on a first attempt, then accept it after some time has elapsed.

If spammers ever try to resend rejected messages, we can assume they will not stay idle between the two sends (if they do, the spam problem would just be solved). Odds are good that the spammer will send a mail to a honey pot address and get blacklisted in several real-time distributed black lists before the second attempt.


System requirements

You need a Sendmail or Postfix that supports the milter interface: at least Sendmail 8.11.x, (8.12.x or higher is recommended), or Postfix 2.3.

milter-greylist has been successfully built on NetBSD, Linux, FreeBSD, Darwin, Solaris, Tru64 UNIX and IRIX. You need libmilter installed on your system, and your system must support POSIX threads (GNU Pth is fine if your system does not have native threads).


milter-greylist features

Can be enabled on a per-recipient basis

Not everyone wants greylisting. It is extremely efficient against spam, but it introduces a delay in legitimate mail delivery. Users that currently receive no spam (because their address has not yet been harvested by spammers) will not want to trade the extra delay for nothing. In order to address that problem, milter-greylist can be enabled on a per-recipient basis.


Testing is easy

milter-greylist can also be enabled for no recipient except a small list of users. This makes testing easier: install milter-greylist and you can activate it only for an address crippled with junk mail.


Friendly networks white-listing

There are many networks around you that are known to be friendly, and for which you don't want to trade the delivery delay for a junk mail cleanup. milter-greylist can be configured to white-list IP net blocks, so that mail coming from them never goes through greylist filtering.

The "must-have" friendly network is 127.0.0.1/8. You will also white-list your LAN, so that MUA don't bug users with odd messages about e-mail that need to be resent later.


Information report and debugging

milter-greylist tries to report as much information to users as possible.

When a message is rejected, milter-greylist will tell the remote MTA how long there is to wait before the message can be accepted (this feature can be disabled if you prefer that information to remain secret).

Each message that went through the MTA has a X-Greylist header line, which reports what milter-greylist did: message accepted immediately because the sender IP is white-listed, or because the recipient is white-listed. And if the message has been delayed, milter-greylist will report how long it had to wait because of greylisting before being accepted.

The database of pending messages is a plain old text file. The date each message will be accepted is formatted as a human-readable string.


Multi-MX sync

When using multiple MX, the sequence of delivery attempts can become complicated, and if the sending MTA does not try all the MX servers, the delivery can be much longer. milter-greylist has a multi-MX sync feature, that enable the database to be shared by all the MX servers.


Auto-whitelisting

In order to minimize the impact of grey-listing, each time a message is accepted, the tuple (sender IP, sender e-mail, recipient-email) gets auto-whitelisted for a configurable time (default is one day). Newer messages matching the same tuple will pass through with no delay. This feature can be disabled.


Roaming users and SMTP AUTH support

You don't want to greylist your roaming users. Starting with version 1.1.1, milter-greylist supports SMTP AUTH, so that authenticated users can bypass the greylist.

Alternatively, if you don't use SMTP AUTH but the "POP before SMTP" paradigm, you can feed milter-greylist a dynamic whitelist of IP addresses generated on the fly as users connect to your POP service. Helmut Messerer wrote some documentation explaining how to do that with poprelay.


IPv6

Before version 1.5.4, milter-greylist did not fully support IPv6, but it was IPv6-aware. It was just letting messages from IPv6 addresses going in without greylisting them. This was okay since no spammer has switched to IPv6 yet.

Starting with version 1.5.4, thanks to the contribution of Hajimu Umemoto, IPv6 is fully supported.


Access-lists

Milter-greylist enables you to specify what messages should be whitelisted and what message should be greylisted using access-lists (ACL). You can specify complex conditions on sender IP, sender DNS address, sender e-mail address, and recipient e-mail address. Regular expressions are supported.


SPF records

Starting with version 1.1.3, milter-greylist is able to use libspf_alt to check SPF records. SPF records are DNS objects that tell the whole Internet which server(s) can legally send e-mail from a domain.

Using SPF records, milter-greylist will avoid greylisting any mail that comes from an SPF-compliant server. This feature is optionnal and requires libspf_alt

Starting with 1.1.10, libspf (James Couzens's version) is also supported. libpsf2 is supported starting with version 1.7.2.


milter-greylist bug^H^H^Hweaknesses

milter-greylist have been in production for months on various systems, including rather big mail servers. It seems to perform quite well. We know that it builds reasonably well on NetBSD, Linux, FreeBSD, Darwin, Solaris, Tru64 UNIX and IRIX, and that it works well on NetBSD, Linux, FreeBSD, and Solaris. Of course your experience may vary.

milter-greylist uses main memory to hold its database, which result in very fast operation. However, in case of a system crash, the database is lost. In order to avoid that, a database checkpoint is regularly dumped to a text file. This text file is read at milter-greylist restart, to resume operation at the last checkpoint.

Before version 1.3.3, the database is dumped on each change, which makes milter-greylist quite bad on high volume server. Starting with 1.3.3, you can tune the dump frequency in order to fit bigger mail setups.


Mailing list, Wiki, and more

The project mailing list is aimed at discussions related to milter-greylist: user support, feature requests, and technical design. Note that the mailing list web site defaults to french if your browser does not provide language preference. Set it up to request english if this is what you want

The mailing list has been previously hosted at Yahoo groups, but it is now unused.

There is also an outdated milter-greylist wiki, which has been the place to exchange tips and configuration samples.

And finally, we even gave a translation of this page in Belorussian (thank to Webhostingrating)


To do list

Here are the future directions for milter-greylist developement:

  • Add database back-ends. SQLite is a good candidate.
  • Support SenderID and DKIM

Downloads

milter-greylist stable release milter-greylist-4.6.4.tgz.
MD5 (milter-greylist-4.6.4.tgz) = def021c0ff43e4c3f1ae2f8bb997ceac
Check out latest code through CVS:
export CVS_RSH=ssh; cvs -danoncvs@anoncvs.fr.netbsd.org:/milter-greylist co -P milter-greylist

milter-greylist's README, milter-greylist(8), and greylist.conf(5) man pages (text document, Unix-like carriage returns).


License

This software is free software. It is available under a 3-clause BSD license, which is copied at the end of the README file.


Contributors

milter-greylist was initially written by Emmanuel Dreyfus. As its popularity increased, it received many contributions, from (in alphabetic order):

  • Adrian Dabrowski
  • Aida Shinra
  • Adam Katz
  • Alexander Lobodzinski
  • Alexandre Cherif
  • Alexey Popov
  • Andrew McGill
  • Attila Bruncsak
  • Benoit Branciard
  • Bernhard Schneider
  • Bob Smith
  • Constantine A. Murenin
  • Christian Pelissier
  • Cyril Guibourg
  • Dan Hollis
  • Denis Solovyov
  • Elrond
  • Enrico Scholz
  • Eugene Crosser
  • Fabien Tassin
  • Fredrik Pettai
  • Gary Aitken
  • Georg Horn
  • Gert Doering
  • Greg Troxel
  • Guido Kerkewitz
  • Hajimu Umemoto
  • Hideki ONO
  • Ivan F. Martinez
  • Jacques Beigbeder
  • Jean Benoit
  • Jeff Rife
  • Jim Klimov
  • Jobst Schmalenbach
  • Joe Pruett
  • Joel Bertrand
  • Johann E. Klasek
  • Johann Klasek
  • John Thiltges
  • John Wood
  • Jorgen Lundman
  • Klas Heggemann
  • Kouhei Sutou
  • Laurence Moindrot
  • Lev Walkin
  • Manuel Badzong
  • Martin Paul
  • Matt Kettler
  • Mattheu Herrb
  • Matthias Scheler
  • Matthieu Herrb
  • Michael Fromme
  • Moritz Both
  • Nerijus Baliunas
  • Ole Hansen
  • Pavel Cahyna
  • Pascal Lalonde
  • Per Holm
  • Petr Kristof
  • Piotr Wadas
  • R P Herrold
  • Ralf S. Engelschall
  • Ranko Zivojnovic
  • Remy Card
  • Rick Adams
  • Rogier Maas
  • Romain Kang
  • Rudy Eschauzier
  • Stephane Lentz
  • Thomas Scheunemann
  • Tim Mooney
  • Wolfgang Solfrank
  • Yaroslav Boychuk

If you have contributed something and you are not on the list above, don't hesitate to complain.



Translations

This page has been translated into

And now, something completely different

Some advertising: you are a french speaker, interested in UNIX system administration? Check out this book, available in any good bookstore. first edition


2021/08/25 Emmanuel Dreyfus

Valid HTML 4.01!