Provided by: gross_1.0.2-4build1_amd64 bug


       grossd - Greylisting of Suspicious Sources - the Server


       grossd [-dCDhnrV] [-f config] [{-p|-P} pidfile]


       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.

   Theory of operation
       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.


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

       -f config
           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.

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

       -p pidfile
           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.


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


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

       Gross project site: <>

       Bloom filters: <>

       DNS queries are done asynchronously using c-ares library


       Eino Tuominen and Antti Siira

                                            2008-05-04                                  grossd(8)