Git Product home page Git Product logo

gross's Introduction

gross - Greylisting of suspicious sources

INTRODUCTION

Gross is a greylisting server. The features that make gross
stand out from other greylisters are:

- it's blazingly fast
- it's 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 DNSBL's
- it can be replicated and run parallel on two servers

It supports Sun Java System Messaging Server and Postfix,
Exim and Sendmail.

AUTHORS

Gross is written by Eino Tuominen <[email protected]> and
Antti Siira <[email protected]>

MOTIVATION

We decided to write a greylister of our own because
traditional greylisting was not acceptable due to it's
impact on legitimate emails. Likewise, we have not used
DNSBLs to directly refuse mail because of the possible
false positives. One of the cornerstones of our spam
fighting policy is to minimize the possibility of false
positives.

Because greylisting is found to be a very effective way
to reduce spam, and most of spam is originated from
hosts on various DNSBLs, I suggested that greylisting just 
those servers found on DNSBLs would reduce the amount
of spam received. This software has been written to test
if that hypothesis was correct.

DESIGN AND OPERATION

Gross consists of grossd, the greylisting daemon, and
a client library for SJSMS. The server also implements 
Postfix's 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 filter. If a
match is found, server sends an OK message.

If the triplet has not been seen before, grossd then
queries configured DNSBL databases for the smtp-client-ip.
If a positive match is found, grossd sends client a 
GREY response. If DNSBL tests are negative, an OK response
is sent. Database is then updated; currently there are 
two updating styles: either to always update or to only
update if the result was GREY.

As mentioned above, the data store is implemented with
Bloom filters. 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 OK 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.[1]

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

DOCUMENTATION

See INSTALL for installation instructions and for more
information about configuration.

See doc/examples/grossd.conf for an example configuration
along with additional information about each feature.

There is a mailing list linked from the project's home page.
Please, don't hesitate to contact the authors directly 
if you have any questions!

PERFORMANCE AND STABILITY

Gross is currently doing greylisting for the mail gateways
of the University of Turku and the University of Wisconsin.

Gross has proven to be very stable on Solaris (9 and 10) 
on Sun Sparc.  It has also been run on a production Red Hat
server with minor stability issues.

When we enabled Gross on our servers, we saw a tremendous 
drop on our internet originated mail flow. Also,
the load on our spam filtering servers was cut in half!

DEVELOPMENT AND LICENSING

Gross is published on a BSD-like license.

See http://code.google.com/p/gross/ for more information.

If you have any suggestions regarding the software or wish
to take part on the development, feel free to contact the authors.
We'll be happy to hear if you dare to try out the software.

Should it be grey or gray?-)

  Eino Tuominen


[1] http://en.wikipedia.org/wiki/Bloom_filter

gross's People

Stargazers

 avatar  avatar  avatar  avatar  avatar

Watchers

 avatar  avatar

gross's Issues

A dry run option for testing needed

There should be an option for grossd that makes it always send STATUS_TRUST 
response. That way 
one could safely simulate grossd in a live environment.

Original issue reported on code.google.com by [email protected] on 10 Jan 2007 at 11:01

Python hooks for checks and check result evaluation

We could have Python hooks so that checks could be written in Python instead of 
C. Also, the check 
result evaluation could be handed over to a Python module. That way complicated 
policy 
requirements could be easily fulfilled.

Original issue reported on code.google.com by [email protected] on 13 Jan 2007 at 4:48

connections could come from different IP addresses

From wikipedia: http://en.wikipedia.org/wiki/Greylisting

"In practice, most greylisting systems do not require an exact match on the
IP address and the sender address. Because large senders often have a pool
of machines that can send (and resend) e-mail from, IP addresses that have
the most-significant 24 bits (/24) the same are treated the equivalent, or
in some cases SPF records are used to determine the sending pool.
Similarly, because many mailing lists use Variable envelope return path
(VERP), if an exact match on the sender address is required, each post from
the mailing list will be delayed. Instead, some greylisting systems try to
eliminate the variable parts of the VERP by using only the sender domain
and the beginning of the local-part of the sender address."

Perhaps there could be a configurable options to make gross treat pooled IP
addresses equivalent
e.g.
match_ipaddr=24

Original issue reported on code.google.com by [email protected] on 12 Jan 2007 at 4:11

sophos blocker compatibility

It would be interesting to configure gross to query the sophos puremessage
IP blocker in addition to (or instead of) the DNSBLs.  I think I have some
example code laying around somewhere.

Original issue reported on code.google.com by [email protected] on 5 Jan 2007 at 5:19

don't update database if multiple checks match

Here is an idea for new configurable option:

grey_update_max = int 

where the database will not update if more than grey_update_max checks match

this will give these senders a perpetual temp block, which is effectively
the same as a perm block, without too much of a code redesign.

it would require that check short-cutting would have to be disabled

Original issue reported on code.google.com by [email protected] on 24 Jan 2007 at 5:13

configurable greylisting time

Would it be possible to have an option to set the amount of time a triplet
will be greylisted?  Currently, it's effectively set to 0, since it will
accept the 2nd attempt immediately.  I've heard of other greylisting
implementations that will greylist for up to 24 hours (extreme setting IMO)
before letting the messages through.

Assuming you have Y buffers, and X is your 'greylisting_buffer_offset' (or
whatever) option.  Instead of doing a logical OR on 0 through Y-1 buffers,
only do the logical OR on X through Y-1 buffers.  0 through X-1 buffers are
never queried.

Original issue reported on code.google.com by [email protected] on 12 Jan 2007 at 4:23

default time window needs to be greater than 4 hours

I was reading through http://en.wikipedia.org/wiki/Greylisting

"When a mail server is greylisted, the duration of time between the initial
delay and the re-transmission is variable. Some mail servers use a default
of 4 hours, though most will retry sooner."

we should configure the default number_buffers and rotate_interval to give
a total time of 4+ hours.

It would be worthwhile to survey other greylisting implementations to
figure out what they have found to be successful

Original issue reported on code.google.com by [email protected] on 12 Jan 2007 at 4:06

configurable logging

Feature request: allow for configurable logging location

(I know that this is already on the TODO list in the README.)

Original issue reported on code.google.com by [email protected] on 10 Jan 2007 at 2:35

Update queue synchronizing

Update queues should be synchronized. This is vital if the greylist_delay
is much longer than the default 10 seconds.

Original issue reported on code.google.com by [email protected] on 16 Jan 2007 at 8:01

logging on one line per request

I would prefer only one log line per request.  I know that this may
sacrifice readability, but it would make it easier to parse and give a
potentially smaller overall log size.

Original issue reported on code.google.com by [email protected] on 18 Jan 2007 at 10:42

check for regexp patterns in reverse dns

This is an RFE for the addition of a new check to perform a dns lookup on
the client_ip and obtain the reverse dns value and then match this value
against multiple regular expressions to determine if the message should be
greylisted.

The idea is that the reverse dns of the client_ip may indicate that the
sending host is not a normal mail server.  e.g. it contains 'dhcp' or 'pool'

It should be considered that this could be used as a blacklist of sorts,
and what will happen if an administrator adds an excessive number of
regular expressions.

Original issue reported on code.google.com by [email protected] on 10 Aug 2007 at 5:21

grossd crashes when starting

Grossd crashes:

Thu Jan 18 12:06:06 2007 #8: threadpool 'sjsms' starting
Thu Jan 18 12:06:06 2007 #5: initializing postfix thread pool
Thu Jan 18 12:06:06 2007 #5: doubling the space for message queues from 4 to 8
Thu Jan 18 12:06:06 2007 #9: threadpool 'postfix' starting
Thu Jan 18 12:06:06 2007 #8: threadpool 'sjsms' processing
Thu Jan 18 12:06:06 2007 #8: threadpool 'sjsms' starting another thread
Thu Jan 18 12:06:06 2007 #8: query from 127.0.0.1
Thu Jan 18 12:06:06 2007 #a: threadpool 'sjsms' starting
Assertion failed: brq, file bloom.c, line 350
Abort - core dumped 

Original issue reported on code.google.com by [email protected] on 18 Jan 2007 at 2:10

Make dnsbl checking run time configurable

Currently it is possible to compile gross with- and without dnsbl. It would
be useful to be able to use gross both with- AND without dnsbl, using the
same instance with only one configuration file.

E.g. compile always with support for dnsbl

Gross determines whether dnsbl's lookups must be done or not, based upon
the presence (or absence) of dnsbl statements in the configuration file. IF
no dnsbl entries in the configfile THEN do not query any dnsbl, ELSE do
query the defined dnsbl's.

Original issue reported on code.google.com by [email protected] on 2 Mar 2007 at 3:27

postfix protocol broken

When testing postfix protocol I discovered that there is no \r\n line 
terminators in the policy 
protocol. They must be changed to plain \n.

Original issue reported on code.google.com by [email protected] on 21 Dec 2006 at 2:30

autoconfigure fails to configure pthread library on Solaris 9

What steps will reproduce the problem?
1. compile
2. start grossd -d

What is the expected output? What do you see instead?
Grossd shutdown with exit code 2: pthread_create No such file or directory

Please use labels and text to provide additional information.


Original issue reported on code.google.com by [email protected] on 18 Dec 2006 at 9:14

Bug in the mapping file example

Having an empty secondary host in mappings entry will break grosscheck. It will 
treat client ip as a 
port number to connect to. Right way to disable failover queries is set the 
secondary server address 
to '0'. 

Original issue reported on code.google.com by [email protected] on 12 Jan 2007 at 8:07

Recommend Projects

  • React photo React

    A declarative, efficient, and flexible JavaScript library for building user interfaces.

  • Vue.js photo Vue.js

    ๐Ÿ–– Vue.js is a progressive, incrementally-adoptable JavaScript framework for building UI on the web.

  • Typescript photo Typescript

    TypeScript is a superset of JavaScript that compiles to clean JavaScript output.

  • TensorFlow photo TensorFlow

    An Open Source Machine Learning Framework for Everyone

  • Django photo Django

    The Web framework for perfectionists with deadlines.

  • D3 photo D3

    Bring data to life with SVG, Canvas and HTML. ๐Ÿ“Š๐Ÿ“ˆ๐ŸŽ‰

Recommend Topics

  • javascript

    JavaScript (JS) is a lightweight interpreted programming language with first-class functions.

  • web

    Some thing interesting about web. New door for the world.

  • server

    A server is a program made to process requests and deliver data to clients.

  • Machine learning

    Machine learning is a way of modeling and interpreting data that allows a piece of software to respond intelligently.

  • Game

    Some thing interesting about game, make everyone happy.

Recommend Org

  • Facebook photo Facebook

    We are working to build community through open source technology. NB: members must have two-factor auth.

  • Microsoft photo Microsoft

    Open source projects and samples from Microsoft.

  • Google photo Google

    Google โค๏ธ Open Source for everyone.

  • D3 photo D3

    Data-Driven Documents codes.