README

# $Id: README,v 1.64 2009/06/29 10:20:00 manu Exp $
###########################################################################

		     ======================================
		       milter-greylist installation notes 
		       $Date: 2009/06/29 10:20:00 $
		     ======================================

		       Emmanuel Dreyfus <manu@netbsd.org>

Table of contents:  
==================

 1 Building and installing milter-greylist 
 2 Configuring Sendmail with milter-greylist
 3 Configuring Postfix with milter-greylist
 4 Configuring milter-greylist 
 5 Trying it out for a few users 
 6 Running it for the whole site 
 7 Lists and per-ACL settings
 8 Dealing with mail farms
 9 Working with multiple MXs
 10 Using DNSRBL
 11 Building with SPF
 12 Using DRAC
 13 Using URL checks
 14 Using LDAP natively
 15 Using TLS
 16 Custom logs
 17 Packaging
 18 Things to look at if things get wrong
 19 Known problems
 20 License

Run this command to regenerate a table of contents:
 sed '/^.====/{g;p;};h;d' README

 1 Building and installing milter-greylist 
 =========================================

This section deals with installing milter-greylist from sources. If you
want to generate a RPM, see section 16 of this document.

First, download the sources. You can get a tarball from
http://ftp.espci.fr/pub/milter-greylist

or you can check out bleeding edge source from milter-greylist CVS:
cvs -danoncvs@anoncvs.fr.netbsd.org:/milter-greylist co -P milter-greylist
Don't forget to set CVS_RSH=ssh if this is not your system default.

Build dependencies: 
- flex (AT&T lex cannot build milter-greylist sources)
- yacc or bison (some older yacc will fail, use bison instead)
- libmilter (comes with Sendmail, or with the sendmail-devel
  package on RedHat, Fedora and SuSE. Debian and Ubuntu have it
  in libmilter-dev)
- Any POSIX threads library (Provided by libc on some systems)

Optional dependencies: 
- libspf2, libspf_alt or libspf, for SPF support
- libcurl, for URL checks support
- libGeoIP, for GeoIP support
- libbind from BIND 9, for DNSRBL support, except if your system has a 
  thread-safe DNS resolver built-in.

Before building milter-greylist, it might be wise to view the
configuration options by running:
./configure -help

To build milter-greylist, just do the usual 
./configure && make && make install

If libpthread and libmilter are not automatically located, use
--with-libpthread and --with-libmilter flags to the configure
script.

If you intend to run milter-greylist under an unprivileged
UID, use the --with-user flag.

A Makefile is supplied in the distribution in case you run into real 
trouble with configure and are unable to get it generating a Makefile
suited to your system. Of course this Makefile is not likely to work 
on your system (it is configured for NetBSD-3.0) and it will probably
need manual tweaks.

On the make install step, the Makefile will install a default config
file in /etc/mail/greylist.conf, except if there is already such
a file. In that case the original file is preserved. Great care is taken
to maintain milter-greylist backward compatibility, so no config file 
change should be nescessary when upgrading: Just replacing the 
milter-greylist binary and restarting the milter should be enough.

Some startup scripts are available: rc-redhat.sh, rc-debian, rc-gentoo.sh,
rc-suse.sh for Linux, rc-bsd.sh for NetBSD and FreeBSD, and rc-solaris.sh
for Solaris. They are not installed by default; you have to install the 
startup script manually if you want to use one.


 2 Configuring Sendmail with milter-greylist
 ===========================================

You need a few options in sendmail.cf to use milter-greylist:

O InputMailFilters=greylist 
Xgreylist, S=local:/var/milter-greylist/milter-greylist.sock 
O Milter.macros.connect=j,{if_addr}
O Milter.macros.envfrom=i

If you use SPF, DNSRBL or urlchecks, then milter-greylist can 
spend a lot of time waiting for DNS lookups to complete. This
may lead to sendmail reporting timeout errors. If you see such
messages, consider setting a timeout larger than the default (see 
Sendmail's milter documentation for more details on timeout settings):

Xgreylist, S=local:/var/milter-greylist/milter-greylist.sock, T=R:1m

Note that InputMailFilters and Milter.macros.* options are shared 
with other milters, and the other milters you have set up may 
require additionnal macros. Therefore you need to merge what
milter-greylist needs with what other milters need. If you just
copy the lines proposed in this file, this is likely to break 
other milters setup. In this section we simply list the macros 
milter-greylist require. Your default sendmail.cf is likely to already 
contain the proper Milter.macros.* setup.

If you want to bypass greylisting for users that succeeded SMTP AUTH, 
you also need {auth_authen} in Milter.macros.envfrom:
O Milter.macros.envfrom=i, {auth_authen}

If you want to bybass greylisting for users that use STARTTLS with 
a client certificate, you also need {verify} and {cert_subject}
in Milter.macros.helo: 
O Milter.macros.helo={verify},{cert_subject}

If you want to use Sendmail access DB as a whitelisting source, you
will need {greylist} too. milter-greylist will whitelist a message
when the {greylist} macro is defined and set as WHITE.
O Milter.macros.envrcpt={greylist}

When using access DB as a whitelisting source, you will also need some
rules for the ruleset "Local_check_rcpt" which assign a value to the
macro {greylist}.
Kstorage macro
SLocal_check_rcpt
R$+		$: $(storage {greylist} $) $&{client_addr}
R$+		$: $>A <$1> <?> <+Connect> <$1>
R<$+> <$*>	$: $(storage {greylist} $@ $1 $) $2

Alternatively, you can use the following m4 macro definitions 
if you build sendmail.cf with m4 (contributed by Hubert Ulliac).
Here again, confMILTER_MACROS_* are shared with other milters,
so you need to merge the definitions with what others milters 
require. Just copying the lines below is likely to cause other
milters to malfunction.

INPUT_MAIL_FILTER(`greylist',
`S=local:/var/milter-greylist/milter-greylist.sock')
define(`confMILTER_MACROS_CONNECT', `j, {if_addr}')
define(`confMILTER_MACROS_HELO', `{verify}, {cert_subject}')
define(`confMILTER_MACROS_ENVFROM', `i, {auth_authen}')
define(`confMILTER_MACROS_ENVRCPT', `{greylist}')

Ivan F. Martinez contributed the milter-greylist.m4 file that includes 
thoses definitions and will take care of adding the macros required by
milter-greylist instead of overwriting what has already been done. This 
should simplify an automatic generation of sendmail.cf.

To add the rules for defining the {greylist} macro via m4, add the following
lines to your m4 input file:

LOCAL_CONFIG
Kstorage macro
LOCAL_RULESETS
SLocal_check_rcpt
R$+		$: $(storage {greylist} $) $&{client_addr}
R$+		$: $>A <$1> <?> <+Connect> <$1>
R<$+> <$*>	$: $(storage {greylist} $@ $1 $) $2

Note that there must be tabs and no spaces before the "$:"!

 3 Configuring Postfix with milter-greylist
 ==========================================

As Postfix currently does not provide milter library, you need to have
sendmail sources or development package installed. See
http://www.postfix.org/MILTER_README.html#limitations

Use --enable-postfix flag when configuring milter-greylist, or you
can build an rpm like this:
rpmbuild --define "build_postfix 1" -tb milter-greylist-3.1.4.tgz

Add the following to postfix main.cf (customize for your needs):
milter_default_action = accept
milter_connect_macros = j
milter_protocol = 3
smtpd_milters = unix:/var/milter-greylist/milter-greylist.sock


 4 Configuring milter-greylist 
 =============================

Edit /etc/mail/greylist.conf, and add addr lines for at least
localhost and all your local network addresses. Here is an example:

acl whitelist addr 127.0.0.0/8
acl whitelist addr 192.0.2.0/24 
acl whitelist addr 10.0.0.0/8

Then consider adding addresses of all the friendly networks you get
mail from. By friendly networks, we mean networks with no spammers:
Universities are usually friendly, some companies are friendly,
some others are not, and dial-up and ADSL ISPs are definitively not
friendly at all.


 5 Trying it out for a few users 
 ===============================

Add some rcpt access-lists to /etc/mail/greylist.conf for the users 
that want to try milter-greylist filtering. Here is an example:

acl greylist rcpt John.Doe@example.net 
acl greylist rcpt webmaster@example.net 
acl greylist rcpt postmaster@example.net

Then finish your ACL with the default rule: here, anything that
is not for John.Doe@example.net, webmaster@example.net, or
postmaster@example.net will not get greylisted:

acl whitelist default

Now you can start milter-greylist:

milter-greylist -u smmsp -p /var/milter-greylist/milter-greylist.sock

If you have trouble with the socket file, check the permissions of
the directory where the socket is located. The default directory is
/var/milter-greylist and it should be chmod 0755 and owner smmsp, if 
you are running the milter as smmsp. If permissions are wrong, 
sendmail will complain to syslog, stating the directory is unsafe.

If sendmail complains it cannot connect to the milter because of a 
connection refused, that either means that the milter is not running, 
or that the socket location configured in sendmail.cf is not the same
as what was given to milter-greylist with the -p flag.

Sometimes, milter-greylist has trouble starting up because of a stale
socket file in /var/milter-greylist/milter-greylist.sock. Just removing
the socket and restarting milter-greylist should fix the problem.

You might want to add -v and -D to get more debugging output. The
-w flag is used to choose how long we will refuse a given message.
If you want to check that things work, try 10 seconds with -w10.

The -a option controls auto-whitelisting. Once a (sender IP, sender e-mail,
recipient e-mail) tuple has been accepted, it is marked autowhitelisted,
and similar tuples will be accepted with no retry for one day. Using -a0
disables this feature.


 6 Running it for the whole site 
 ===============================

Remove the "acl greylist rcpt ..." lines from /etc/mail/greylist.conf, 
and replace "acl whitelist default" by

acl greylist default

Now greylisting is enabled for every recipient. If some of your 
users don't want greylisting, add a "acl whitelist rcpt" line for them 
in /etc/mail/greylist.conf. Make sure you put it before 
"acl greylist default": ordering does matter, as the ACL rules are
evaluated on a first match wins basis.

If your mail server handles several domains and you want to enable
milter-greylist for a whole domain but not for everyone, this is 
possible, just use a regular expression:

acl greylist rcpt /.*@example\.net/
acl whitelist default


 7 Lists and per-ACL settings
 ============================

It is possible to have per-ACL greylisting and autowhitelisting
settings:

acl greylist rcpt /.*@example\.net/ delay 15m autowhite 3d
acl greylist default delay 30m autowhite 1d

Here, all messages to domain example.net will have a greylisting delay
of 15 minutes and will be autowhitelisted for 3 days, while messages
to other domains will be greylisted for 30 minutes and autowhitelisted
for one day.

milter-greylist is now also able to use lists, which is very useful for
factoring rules:

list "users" rcpt { user1@example.com user2@example.com user3@example.com }
acl greylist list "users"
acl whitelist default

Here message sent to members of the "users" list will be greylisted, while
other messages will not.

Theses two advanced features were added in release 2.1.7 and may not be
fully stable.


 8 Dealing with mail farms
 =========================

Some Internet service provider such as Hotmail feature mail farms,
where several different machines are able to resend an e-mail. The
message is likely to be resent from different IP addresses, and this
is likely to break with milter-greylist.

The -L option is an ad-hoc hack for this problem. It provides
milter-greylist a CIDR mask to use when comparing IPv4 addresses. 
With -L24, the match mask is 255.255.255.0, and any address in a 
class C network is considered the same.

There is also a real fix for the problem: SPF. SPF is a DNS based
mechanism that enables domains to publish the identity of machines
allowed to send mail on behalf of the domain. milter-greylist knows 
how to use SPF through libspf or libspf_alt. See section 8 of this
document: Building with SPF

Another workaround is simply to whitelist the netblocks allocated to 
mail farms. As any machine in theses IP address ranges are real SMTP 
servers that will always resend their messages, there is no point in 
greylisting them.


 9 Working with multiple MXs
 ===========================

When running several MXs, the client should try each server after
its message gets refused, thus causing greylist entries creation 
on each MX. Things should work, but with two minor problems:

* Some stupid clients don't try all the available MXs. In that 
  situation, it could take some time before the message gets in,
  as the client might try a different MX each time and wait for 
  several hours between the retries.

* After a messages is accepted, its entry is removed for one MX, 
  but not the others. Stale entries remain until being flushed
  because of a timeout. If a message with the same {IP, from, rcpt}
  gets in on an MX with a stale entry, it will be accepted 
  immediately, and the X-Greylist header will report it had been
  delayed for some time.

In order to address these issues, milter-greylist is now able to
sync the greylist among different MXs. This can be configured in
the greylist.conf file, by adding one line per peer MX,  
like this:
peer 192.0.2.17
peer 192.0.2.18

If you have firewalls between your MXs, you should enable TCP 
connections in both directions between random unprivileged 
source ports and destination port 5252.


 10 Using DNSRBL
 ===============

milter-greylist can use a DNSRBL to decide wether a host should be
greylisted or whitelisted. For instance, let us say that you want to
greylist any host appearing in the SORBS dynamic pool list (this include
DSL and cable pools). You would do this:

# if IP 192.0.2.18 is positive, then nslookup of 18.2.0.192.dnsbl.sorbs.net 
# returns 127.0.0.10
dnsrbl "SORBS DUN" dnsbl.sorbs.net 127.0.0.10
acl greylist dnsrbl "SORBS DUN"

You can combine it with variable greylisting delays so that dynamic hosts
get a greylisting delay of 12 hours while other hosts only get 15 minutes:

dnsrbl "SORBS DUN" dnsbl.sorbs.net 127.0.0.10
acl greylist dnsrbl "SORBS DUN" delay 12h
acl greylist default delay 15m

This feature was introduced in milter-greylist 2.1.7 and may not be
fully stable. You need the --enable-dnsrbl flag to configure to use 
it. You must link milter-greylist with a thread-safe resolver, else 
the milter will be unstable (see the explanation in the SPF section).

If your resolver is not thread safe, install BIND9, and use 
--with-libbind. If you know your resolver is thread-safe but 
configure tells otherwise (because you lack the res_ninit() function),
then use --with-thread-safe-resolver. 

If you install BIND9, make sure it includes libbind.a, since this is
what milter-greylist needs. libbind.a is not created in BIND9 default
build setup, so you might not have it in a precompiled package. If you 
cannot find a package that contains libbind.a, then you have to rebuild
BIND9 from sources, using the --enable-libbind 
flag to BIND9's configure.


 11 Building with SPF
 ====================

milter-greylist can use either libspf or libspf2 to perform SPF
checks. Use --with-libspf=DIR or --with-libspf2=DIR to enable this
feature. DIR must be the base directory where include and lib
directories containing the headers and library can be found.

If you want to link with an older version of libspf2, you will
need one of the following configure flags:
For older libspf_alt: --with-libspf_alt=DIR
For older libspf2 up to version 1.0: --with-libspf2_10=DIR
For newer libspf2: --with-libspf2=DIR

WARNING: milter-greylist is a multithreaded program. The external
functions it uses must be thread-safe. While libspf and libspf_alt
contain only thread-safe code, they use the DNS resolver. By default,
the DNS resolver from libc or libresolv is used. If this resolver
is not thread-safe, milter-greylist with SPF will quickly crash or
hang.

You need to make sure that libspf or libspf_alt are linked against
a thread-safe DNS resolver. For instance, NetBSD-1.6.2 libc-supplied
resolver is from BIND 4, and it is not thread safe. In order to get
a stable milter-greylist, you need to link with a BIND 8.2 or higher
resolver.

When building with libspf_alt-0.4, you might encounter problems if
libbind is only available as a static library. It seems to be the
default with BIND 8, which causes troubles. BIND 9 is fine.


 12 Using DRAC
 =============

milter-greylist can be built with DRAC (Dynamic Relay Authorization
Control) support, by giving the --enable-drac flag to configure.
Location of the DRAC DB file can be chosen at build time with
--with-dracdb=PATH, and at runtime with the drac db "PATH"
configuration file option.

If built-in, DRAC can be disabled by the nodrac configuration file
option.

More information on DRAC can be obtained at 
http://mail.cc.umanitoba.ca/drac/


 13 Using URL checks
 ===================

ACL can cause URL lookups:

urlcheck "mytest" "http://www.example.net/mgl.php?rcpt=%r+ip=%i" 10
acl greylist urlcheck "mytest"

For each ACL evaluation will spawn a request to
http://www.example.net/mgl.php?rcpt=%r+ip=%i, with
%r replaced by recipient e-mail
%i replaced by IP address
You can also substitute domain, sender address, and various other data,
including any sendmail macro. Check the greylist.conf(5) man page for
details. The trailing 10 is the maximum number of simultaneous
connections you want to have.

The mgl.php script is to answer if you get a match by sending back this:
milterGreylistStatus: Ok

Even better, you can send settings in the reply:
milterGreylistStatus: Ok
milterGreylistDelay: 1h

autowhite, code, ecode, flushaddr and msg can be overloaded. You can
even overload the ACL action (ie: turning a greylist ACL into a
blacklist action), see the man page for details.

Something to note: the reply format is LDIF-like. It was chosen so that
the URL could be a ldap:// query, though this has not been experimented 
yet. 


 14 Using LDAP natively
 ======================

It is possible to use URL checks against an LDAP URL, but that method
has some drawbacks:
- This uses CURL, which must be built with LDAP support
- There might be thread-safety problems. A workaround it to use the
  fork option of urlcheck statement, so that milter-greylist forks 
  a pool of instances to perform queries. This may not be very reliable
  on some setups.
- It is not possible to fallback to another server if the LDAP directory 
  goes down.

milter-greylist can also support LDAP natively, using OpenLDAP libraries,
if configure --with-openldap is used. 

Here is an example that pulls a per-user sender whitelist from the 
directory:

ldapconf "ldapi:// ldaps://ldap.example.net"
ldapcheck "mytest" "ldap://ldap.example.net/o=example?whitelist?sub?mail=%r"
acl whitelist ldapcheck "mytest" $whitelist "%f"
acl greylist default

The ldapconf statement is used to list LDAP servers. If one goes down, 
another will be contacted. For ldaps:// URLs, certificate information
is taken from system ldap.conf.

ldapcheck definition works like urlcheck with the getprop option (see 
the man page for details). Note that the scheme and host parts of the 
URL are just ignored: information from ldapconf is used instead.


 15 Using TLS
 ==============

Using the "tls" clause, an ACL could match any email that succeeded TLS
check in sendmail (STARTTLS giving "verify=OK"). This assumes you already
have TLS working in sendmail.

acl whitelist tls "DN1"
acl whitelist tls "DN2"

or

list "trusted" tls { "DN1" "DN2" }
acl whitelist list "trusted"

A DN has a special syntax.
If you used the 'update_tls' script provided with sendmail to generate
your certificates, your DN should look like this:

"/O=Sendmail/OU=Sendmail+20Client/CN=machine.example.net/emailAddress=admin@machine.example.net"

Note that it's the "client" certificate (of the remote server) that is used
as (the local) sendmail is acting as server during that transaction.

To find the DN of any certificate, you can use the openssl command:

$ openssl x509 -noout -issuer < some.crt | cut -d' ' -f2- | sed -e 's/ /+20/g'


 16 Custom logs
 ==============

It is possible to monitor milter-greylist activity with a custom log
format. You can choose where the output is sent (file or external
command), and the output format. If you have this in greylist.conf:
stat ">>/var/log/milter-greylist.log" "%T{%T}    %i:%f:%r:%S\n"

On each mail, this will give you a line like this in milter-greylist.log:
10:08:04    192.0.2.16:spammer@evil.com:postmaster@example.net:reject

Another example, to send the data to the local7 facility of syslog,
using the external command logger:
stat "|logger -p local7.info" "%i:%f:%r:%S\n" 

Substitutions are the same as in URL checks (%i becomes sender IP, %s
becomes sender e-mail, %r becomes recipient, and so on). A few nifty
additions:

%T{format} is substituted by strftime(3) time format. So %T{%F %T} gives
you a date/time in the following format: YYYY-MM-DD HH:MM:SS 
%S is substituted by the action milter-greylist chose: accept, tempfail
or reject
%A is substituted by the line number of the ACL that caused the decision


 17 Packaging
 ============

milter-greylist is available from NetBSD pkgsrc and FreeBSD ports.
A .spec file is included in the distribution to build an RPM for
RedHat Linux. This is achieved by running rpmbuild on milter-greylist
source tarball: rpmbuild -tb milter-greylist-3.1.4.tgz. You can define
build_user, build_postfix, build_dnsrbl, build_libbind - for example,
to build with DNSRBL support and choose smmsp as the user that will run
milter-greylist, use
rpmbuild --define "build_user smmsp" --define "build_dnsrbl 1" -tb milter-greylist-3.1.4.tgz


 18 Things to look at if things get wrong
 ========================================

First, read the milter-greylist(8) and greylist.conf(5) man page! :-)

Second, reread the installation notes at the beginning this file! ;-)

Each message will get an X-Greylist header indicating either how long the
message has been delayed, or that it has been passed through because of
whitelisting. It looks something like this:

For messages which were delayed because of greylisting:
  X-Greylist: Delayed for 00:53:21 by milter-greylist-M.m
      (mail.example.net [192.0.2.16]); Wed, 3 Mar 2004 17:01:06 -0000

For messages which were not delayed because of whitelisting (e.g. they
are whitelisted in the configuration file):
  X-Greylist: Sender IP whitelisted, not delayed by milter-greylist-M.m
      (mail.example.net [192.0.2.16]); Wed, 3 Mar 2004 17:01:06 -0000
  X-Greylist: Sender DNS name whitelisted, not delayed by milter-greylist-M.m
      (mail.example.net [192.0.2.16]); Wed, 3 Mar 2004 17:01:06 -0000

For messages which were not delayed because of auto-whitelisting from a
previously resent and accepted message:
  X-Greylist: IP, sender and recipient auto-whitelisted, not delayed by
      milter-greylist-M.m (mail.example.net [192.0.2.16]); Wed, 3 Mar 2004
      17:01:06 -0000

where M.m is the major and minor version number of milter-greylist.

The file /var/milter-greylist/greylist.db is a dump of the greylist.
It is done periodically and is used to restore state after
milter-greylist has been restarted. The file contains an entry per
line, with four columns:  IP address, sender e-mail address,
recipient e-mail address, and time when the message will be accepted
(in seconds since 00:00:00 01-01-1970).  Here is an example:

10.0.23.1  <evilspammer@example.com>  <pooruser@example.net>  1078344409

Additionally, you can find a human-readable time in the comment at the
end of each line.

At the end of the file, you will find entries with the keyword AUTO
at the end of the line. Theses are auto-whitelisted tuples. The date
tells you when the entry will expire.

Examining the tail of this file may reveal problems with domains which
use multiple MX servers or whose mail is actually served by another site.


 19 Known problems
 =================

If milter-greylist terminates during its operation, first check your
system limits with ulimit (sh/ksh/bash) or limit (csh/tcsh). As it stores 
its complete database in memory, milter-greylist can eat a large amount of 
memory on a busy mail server. Each incoming connection uses a socket, so
file descriptors can easily be exhausted too. Any resource shortage will
cause milter-greylist to quit. This is not specific to milter-greylist; 
all milters do that.

When SPF support is compiled in, if milter-greylist hangs and/or crashes
regularly, check that you linked your SPF library with a thread-safe
resolver. This can be done by running nm(1) on milter-greylist: if
nres_init is referenced, you are fine.  If res_init is referenced, you 
are probably at risk.

When DNSRBL support is compiled in, you also need to make sure that
milter-greylist itself is linked with a thread-safe resolver.

On Solaris 2.8, milter-greylist may grow out of memory rather quickly 
due to some bugs in the pthread nsl and socket libraries. It is strongly 
recommended that you install the latest revision of patch 108993 (sparc) 
or 108994 (x86). Solaris 9 and later do not seem to be affected.
Solaris patches are available from <http://sunsolve.sun.com/>

On Solaris, and on some IRIX releases, the file descriptor field 
of <stdio.h>'s FILE structure is a char, and thus no more than 255 
streams can be open at once. This will cause failures in milter-greylist 
when handling a large number of connections. If you are not sure whether 
your system is affected or not, check your system headers for the FILE 
definition. On Solaris, the problem only exists with the 32 bit ABI, 
so rebuilding milter-greylist with a 64 bit compiler will fix the problem.
An alternative is to use the --enable-stdio-hack option to configure

On IRIX, milter-greylist has to be compiled with the same ABI as
libmilter. If libmilter was built with the MIPSpro compiler,
milter-greylist should be too, because of binary incompatibility
between gcc and the MIPSpro compilers. This can be achieved by invoking
configure with the CC environment variable set to cc. This
incompatibility may be fixed in gcc 3.4.


 20 License
 ==========

This software is available under a 3 clauses BSD license:
  Copyright (c) 2004-2007 Emmanuel Dreyfus
  All rights reserved.

  Redistribution and use in source and binary forms, with or without
  modification, are permitted provided that the following conditions
  are met:
  1. Redistributions of source code must retain the above copyright
     notice, this list of conditions and the following disclaimer.
  2. Redistributions in binary form must reproduce the above copyright
     notice, this list of conditions and the following disclaimer in the
     documentation and/or other materials provided with the distribution.
  3. All advertising materials mentioning features or use of this software
     must display the following acknowledgement:
         This product includes software developed by Emmanuel Dreyfus

  THIS SOFTWARE IS PROVIDED ``AS IS'' AND ANY EXPRESS OR IMPLIED
  WARRANTIES, INCLUDING, BUT NOT LIMITED TO, THE IMPLIED WARRANTIES
  OF MERCHANTABILITY AND FITNESS FOR A PARTICULAR PURPOSE ARE
  DISCLAIMED. IN NO EVENT SHALL THE AUTHOR BE LIABLE FOR ANY DIRECT,
  INDIRECT, INCIDENTAL, SPECIAL, EXEMPLARY, OR CONSEQUENTIAL DAMAGES
  (INCLUDING, BUT NOT LIMITED TO, PROCUREMENT OF SUBSTITUTE GOODS OR
  SERVICES; LOSS OF USE, DATA, OR PROFITS; OR BUSINESS INTERRUPTION)
  HOWEVER CAUSED AND ON ANY THEORY OF LIABILITY, WHETHER IN CONTRACT,
  STRICT LIABILITY, OR TORT (INCLUDING NEGLIGENCE OR OTHERWISE)
  ARISING IN ANY WAY OUT OF THE USE OF THIS SOFTWARE, EVEN IF ADVISED
  OF THE POSSIBILITY OF SUCH DAMAGE.


If you run on a non-BSD system, two files with different licenses might
be required for building or installing.

install-sh has a MIT BSD-like license:
  Copyright 1991 by the Massachusetts Institute of Technology
 
  Permission to use, copy, modify, distribute, and sell this software and its
  documentation for any purpose is hereby granted without fee, provided that
  the above copyright notice appear in all copies and that both that
  copyright notice and this permission notice appear in supporting
  documentation, and that the name of M.I.T. not be used in advertising or
  publicity pertaining to distribution of the software without specific,
  written prior permission.  M.I.T. makes no representations about the
  suitability of this software for any purpose.  It is provided "as is"
  without express or implied warranty.


queue.h has a 4 clause BSD license:
  Copyright (c) 1991, 1993
 	The Regents of the University of California.  All rights reserved.
 
  Redistribution and use in source and binary forms, with or without
  modification, are permitted provided that the following conditions
  are met:
  1. Redistributions of source code must retain the above copyright
     notice, this list of conditions and the following disclaimer.
  2. Redistributions in binary form must reproduce the above copyright
     notice, this list of conditions and the following disclaimer in the
     documentation and/or other materials provided with the distribution.
  3. All advertising materials mentioning features or use of this software
     must display the following acknowledgement:
 	This product includes software developed by the University of
 	California, Berkeley and its contributors.
  4. Neither the name of the University nor the names of its contributors
     may be used to endorse or promote products derived from this software
     without specific prior written permission.
 
  THIS SOFTWARE IS PROVIDED BY THE REGENTS AND CONTRIBUTORS ``AS IS'' AND
  ANY EXPRESS OR IMPLIED WARRANTIES, INCLUDING, BUT NOT LIMITED TO, THE
  IMPLIED WARRANTIES OF MERCHANTABILITY AND FITNESS FOR A PARTICULAR PURPOSE
  ARE DISCLAIMED.  IN NO EVENT SHALL THE REGENTS OR CONTRIBUTORS BE LIABLE
  FOR ANY DIRECT, INDIRECT, INCIDENTAL, SPECIAL, EXEMPLARY, OR CONSEQUENTIAL
  DAMAGES (INCLUDING, BUT NOT LIMITED TO, PROCUREMENT OF SUBSTITUTE GOODS
  OR SERVICES; LOSS OF USE, DATA, OR PROFITS; OR BUSINESS INTERRUPTION)
  HOWEVER CAUSED AND ON ANY THEORY OF LIABILITY, WHETHER IN CONTRACT, STRICT
  LIABILITY, OR TORT (INCLUDING NEGLIGENCE OR OTHERWISE) ARISING IN ANY WAY
  OUT OF THE USE OF THIS SOFTWARE, EVEN IF ADVISED OF THE POSSIBILITY OF
  SUCH DAMAGE.


The configure script has the following license:
  Copyright 1992, 1993, 1994, 1995, 1996, 1998, 1999, 2000, 2001, 2002
  Free Software Foundation, Inc.
  This configure script is free software; the Free Software Foundation
  gives unlimited permission to copy, distribute and modify it.


If you use the 32 bit ABI on Solaris and have a large traffic, you will 
need the a workaround for stdio unability to use streams with associated
file dexriptor above 255. The files implementing the workaround are
fd_pool.c and fd_pool.h, and they have a 3 clause BSD license:
  Copyright (c) 2007 Johann Klasek
  All rights reserved.
 
  Redistribution and use in source and binary forms, with or without
  modification, are permitted provided that the following conditions
  are met:
  1. Redistributions of source code must retain the above copyright
     notice, this list of conditions and the following disclaimer.
  2. Redistributions in binary form must reproduce the above copyright
     notice, this list of conditions and the following disclaimer in the
     documentation and/or other materials provided with the distribution.
  3. All advertising materials mentioning features or use of this software
     must display the following acknowledgement:
         This product includes software developed by Johann Klasek
 
  THIS SOFTWARE IS PROVIDED ``AS IS'' AND ANY EXPRESS OR IMPLIED
  WARRANTIES, INCLUDING, BUT NOT LIMITED TO, THE IMPLIED WARRANTIES
  OF MERCHANTABILITY AND FITNESS FOR A PARTICULAR PURPOSE ARE
  DISCLAIMED. IN NO EVENT SHALL THE AUTHOR BE LIABLE FOR ANY DIRECT,
  INDIRECT, INCIDENTAL, SPECIAL, EXEMPLARY, OR CONSEQUENTIAL DAMAGES
  (INCLUDING, BUT NOT LIMITED TO, PROCUREMENT OF SUBSTITUTE GOODS OR
  SERVICES; LOSS OF USE, DATA, OR PROFITS; OR BUSINESS INTERRUPTION)
  HOWEVER CAUSED AND ON ANY THEORY OF LIABILITY, WHETHER IN CONTRACT,
  STRICT LIABILITY, OR TORT (INCLUDING NEGLIGENCE OR OTHERWISE)
  ARISING IN ANY WAY OUT OF THE USE OF THIS SOFTWARE, EVEN IF ADVISED
  OF THE POSSIBILITY OF SUCH DAMAGE.


SpamAssassin binding requires the spamd.c file, which has a 3-clauses
BSD licence:
  Copyright (c) 2008 Manuel Badzong, Emmanuel Dreyfus
  All rights reserved.
 
  Redistribution and use in source and binary forms, with or without
  modification, are permitted provided that the following conditions
  are met:
  1. Redistributions of source code must retain the above copyright
     notice, this list of conditions and the following disclaimer.
  2. Redistributions in binary form must reproduce the above copyright
     notice, this list of conditions and the following disclaimer in the
     documentation and/or other materials provided with the distribution.
  3. All advertising materials mentioning features or use of this software
     must display the following acknowledgement:
         This product includes software developed by Manuel Badzong
 
  THIS SOFTWARE IS PROVIDED ``AS IS'' AND ANY EXPRESS OR IMPLIED
  WARRANTIES, INCLUDING, BUT NOT LIMITED TO, THE IMPLIED WARRANTIES
  OF MERCHANTABILITY AND FITNESS FOR A PARTICULAR PURPOSE ARE
  DISCLAIMED. IN NO EVENT SHALL THE AUTHOR BE LIABLE FOR ANY DIRECT,
  INDIRECT, INCIDENTAL, SPECIAL, EXEMPLARY, OR CONSEQUENTIAL DAMAGES
  (INCLUDING, BUT NOT LIMITED TO, PROCUREMENT OF SUBSTITUTE GOODS OR
  SERVICES; LOSS OF USE, DATA, OR PROFITS; OR BUSINESS INTERRUPTION)
  HOWEVER CAUSED AND ON ANY THEORY OF LIABILITY, WHETHER IN CONTRACT,  
  STRICT LIABILITY, OR TORT (INCLUDING NEGLIGENCE OR OTHERWISE)
  ARISING IN ANY WAY OUT OF THE USE OF THIS SOFTWARE, EVEN IF ADVISED
  OF THE POSSIBILITY OF SUCH DAMAGE.