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).

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 adresses 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). Whithout 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.