SYNOPSIS

milter-greylist [-A] [-a autowhite_delay] [-c] [-D] [-d dumpfile] [-f configfile] [-h] [-l] [-q] [-r] [-S] [-T] [-u username[:groupname]] [-v] [-w greylist_delay] [-L cidrmask] [-M prefixlen] [-P pidfile] -p socket

DESCRIPTION

milter-greylist is a mail filter for sendmail that implements grey listing, a spam filtering technique proposed by Evan Harris.

Grey listing works by assuming that contrarily to legitimate MTA, spam engines will not retry sending their junk mail on a temporary error. The filter will always temporarily reject mail on a first attempt, and 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. Odds are good that the spammer will send a mail to an honey pot address and get blacklisted in a distributed black list before the second attempt.

Of course, the filter can be configured to not apply grey listing to some hosts or networks. You can whitelist friendly SMTP servers, and you should whitelist your own network, otherwise your SMTP clients will have real trouble to send e-mail. Whitelisting localhost is also a must.

milter-greylist works with two files. greylist.conf is the configuration file. It holds the whitelist of addresses that will not suffer grey list filtering. It is read once upon milter-greylist startup, then it will be automatically reloaded whenever a new message gets in and if it had been modified. You should not send milter-greylist a kill -1 as it will just terminate it (libmilter works that way).

See greylist.conf(5) for documentation on the file's format.

The second file is greylist.db. milter-greylist will regularly dump its grey list database into this file, which is used on startup to restore the previous grey list state. If the file does not exist or is unreadable, milter-greylist will start with an empty grey list.

The default location for the grey list database and the socket for communicating with sendmail is /var/milter-greylist/. That directory must be owned and writeable by the user id under which milter-greylist runs.

The following options are available; if present, they override their equivalents specified in the configuration file:

-A

Normally, milter-greylist does not greylist senders that succeeded SMTP AUTH. This option disables that feature and causes authentication to be ignored. Equivalent to the noauth option in the configuration file.

-a autowhite_delay

Configure auto-whitelisting. After a tuple (sender IP, sender e-mail, recipient e-mail) has been accepted, other identical tuples will get accepted for autowhite_delay. The default is one day. Use zero to disable auto-whitelisting. A suffix can be added to specify seconds (s), minutes (m), hours (h), days (d) or weeks (w). Without any suffix, values are treated as seconds. Equivalent to the autowhite option in the configuration file.

-c

Only check the configuration file and exit. Return value is 0 if the configuration is valid, or an error code from <sysexit.h> otherwise.

-D

Do not fork; run in the foreground instead. Without this flag, milter-greylist will become a daemon. Equivalent to the nodetach option in the configuration file.

-d dumpfile

Location of the dump file. Default is /var/milter-greylist/greylist.db. Equivalent to the dumpfile option in the configuration file.

-f configfile

Location of the config file. Default is /etc/mail/greylist.conf.

-h

Show usage information.

-L cidrmask

Use cidrmask as a matching mask when checking IPv4 addresses entries in the greylist. This is aimed as a workaround to mail farms that re-emit messages from different IP addresses. With -L 24, the matching mask is 255.255.255.0, and all addresses within the same class C network are considered the same. Default is -L 32, which corresponds to all addresses considered different.

-M prefixlen

Use prefixlen as a matching mask when checking IPv6 addresses entries in the greylist. This is aimed as a workaround to mail farms that re-emit messages from different IP addresses. With -M 64, the matching mask is ffff:ffff:ffff:ffff::, and all addresses within the same subnet are considered the same. Default is -M 128, which corresponds to all IPv6 addresses considered different.

-l

Enable debug output in the access-list management code.

-P pidfile

write the daemon's PID to pidfile. Equivalent to the pidfile option in the configuration file.

-p socket

Use socket as the socket used by sendmail(8) to communicate with milter-greylist.

-q

Quiet mode. milter-greylist will not tell SMTP clients how much time they have to wait before the message will be accepted. Equivalent to the quiet option in the configuration file.

-r

Display milter-greylist version and build environment, then exit.

-S

If milter-greylist was built with SPF support, then SPF-compliant senders bypass greylisting. This flag causes messages to be greylisted regardless of whether they are SPF-compliant or not. Equivalent to the nospf option in the configuration file.

-T

Enable test mode. This alters the meaning of rcpt lines in greylist.conf, so that only messages sent to recipient addresses listed there are selected for greylisting. This option and the rcpt lines have been deprecated in favor of ACL, so do not use it.

-u username[:groupname]

Drop root privileges and switch to username (and optionally groupname) credentials. Make sure this user (and group) has write access to greylist.db. Equivalent to the user option in the configuration file.

-v

Enable debug output. milter-greylist will send messages (and debug output if it is given the -v flag) to syslogd(8) with facility LOG_MAIL. Equivalent to the verbose option in the configuration file.

-w greylist_delay

sets the minimum delay between the first attempt and the time the message can be accepted. Default is 30 minutes. A suffix can be added to specify seconds (s), minutes (m), hours (h), days (d) or weeks (w). Without any suffix, values are treated as seconds. Equivalent to the greylist option in the configuration file.

GREYLIST MX SYNC

milter-greylist is now able to sync the greylist between multiple MX. In order to enable this feature, you need to list the peer MXs in greylist.conf(5) like this:

  peer 192.0.2.17
  peer 192.0.2.18

When peers are configured, milter-greylist will listen on the port defined for the mxglsync service in /etc/services (defaults to 5252), and it will connect to peers at this port. Each time an entry is added or deleted on one MX, it will be propagated to the others.

The protocol is quite simple, just telnet to your MX at port 5252, and type help to see how it works. Note that connections will only be accepted from peer MXs, even localhost will be rejected (and don't ever add localhost as a peer for MX sync, as you will cause each entry in the greylist to be added twice).

If an MX is down, changes to the greylist will be queued until it gets back up again. The queue length is limited (default is 1024 entries), and if it overflows, newer entries will be discarded.

AUTHORS

Emmanuel Dreyfus <[email protected]>

milter-greylist received many contributions from (in alphabetical 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, Jean-Jacques Puig, 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, and Yaroslav Boychuk.

Thanks to Helmut Messerer and Thomas Pfau for their feedback on the first releases of this software.