grossd - Greylisting of Suspicious Sources - the Server

       Eino Tuominen and Antti Siira

                                                   2008-05-04                                          grossd(8)

grossd is a greylisting server, and more.  It's blazingly fast and amazingly resource efficient.  It can
       be configured to query DNSBL databases, and enforce greylisting only for hosts that are found on those
       databases.  It can block hosts that match multiple databases.  It can be replicated and run parallel on
       two servers.  It supports Sun Java System Messaging Server, Postfix and Exim.  Sendmail Milter
       implementation needs testing.

   Theoryofoperation
       Gross consists of grossd, the greylisting daemon, and a client library for SJSMS.  The server also
       implements Postfix content filtering protocol.

       Upon receiving a request from a client, grossd first validates it.  The request includes a triplet
       (`smtp-client-ip', `sender-address', `recipient-address').  A hash is then calculated and matched against
       the Bloom filters.  If a match is found, and test result does not exceed block_threshold value, grossd
       sends an OK (STATUS_TRUST) message.

       If the triplet is not in the Bloom filters (has not been seen recently,) grossd then runs configured
       checks against the client information.  Based on check results grossd returns the client a result.
       Possible results are STATUS_TRUST, STATUS_BLOCK and STATUS_GREY.  The final response is query protocol
       specific.

       The Bloom filters are updated according the update configuration option.  A Bloom filter is a very
       efficient way to store data.  It's a probabilistic data structure, which means that there is a
       possibility of error when querying the database.  False positives are possible, but false negatives are
       not.  This means that there is a possibility that grossd will falsely give an STATUS_TRUST response when
       a connection should be greylisted.  By sizing the bloom filters, you can control the error possibility to
       meet your needs.  The right bloom filter size depends on the number of entries in the database, that is,
       the retention time versus the number of handled connections.

grossd daemon exits 0 if success, and >0 if an error occurs.

/etc/grossd.conf

       grossd - Greylisting of Suspicious Sources - the Server

-C  Create  the  statefile  and  exit.   The  statefile  configuration  option  must  be specified in the
           configuration file.

       -D  Make debugging output more verbose.  It can be set twice for maximum verbosity.

       -d  Run grossd on foreground without daemonizing the process.  grossd will output to terminal instead  of
           using syslog.

       -fconfig
           Specifies the name of the configuration file.  The default is /etc/etc/grossd.conf-h  Output short usage information and exit.

       -n  Enable dry-run.

       -Ppidfile
           Bail out if the pidfile already exists.  Create pidfile after the check.

       -ppidfile
           Create the pidfile.  Overwrite if it already exists.

       -r  Disable replication.

       -V  Output version information and exit.

       Run  grossd  under some unprivileged user id.  If started as root grossd will setuid() itself to nobody's
       user id.  There are no known security flaws but you must not expose grossd to the Internet.  It could  be
       used for a DoS against a domain's DNS servers by an attacker as there is no authentication in grossd.

       Regarding the configuration both the daemon and MTA's, refer to grossd.conf(5)

       Gross project site: <http://code.google.com/p/gross/>

       Bloom filters: <http://en.wikipedia.org/wiki/Bloom_filter>

       DNS queries are done asynchronously using c-ares library <http://daniel.haxx.se/projects/c-ares/>.

grossd [-dCDhnrV] [-fconfig] [{-p|-P} pidfile]