Index of /eximrbl/eximrbl-20080304

EXIMRBL
=======

Update 20/02/2008
-----------------

This update makes eximrbl compile on modern Linux distros and removes
the older patches for PDNS which has since been updated fixing the
previous bugs with it's SQLITE implementation (Thank you PDNS).

Darron M Broad.

-------------------------------------------------------------------------------

1) What is this?

Eximrbl is an application that inspects a running EXIM 4 rejectlog
and using the information gathered there updates an RBL zone.

2) Why would I use this?

Updates in the RBL zone are published via DNS and can be inspected
by backup MX hosts to determine what the master host for a domain
is rejecting, this allows a sysadmin to propagate rejections automatically.

3) How does this work?

Network interaction
-------------------

\INCOMING EMAIL/-----------------------------------
   |                                              |
   |                                              |
/-------\   /------------\   /------------\   /-------\
| MTA   |   | RECURSIVE  |   | AUTH       |   | MTA   |
| MX 0  |<->| DNS SERVER |<->| RBL        |   | MX 1  |
|       |   |            |   | DNS SERVER |   |       |
| EXIM4 |   |            |   | (POWERDNS) |   | EXIM4 |
\-------/   \------------/   \------------/   \-------/
   |              |                |              |
   |              |________________|______________|
 /REJECTLOG\                       |
   |                               |
   |                               |
 /EXIMBRL\----------------------/SQLITE ZONE FILE\
    
    (The EXIM MTA/EXIMRBL/PDNS applications all run on the same device)

When an incoming host connects to either of the MTAs it's ip address
is checked via dns to determine if it is RBLd. Should it be RBLd the
connection is dropped (or processed in a way the sysadmin decides).

When a host is not in the RBL zone, the reply from the authoritative
DNS server has a TTL of 60 seconds, this informs the recursive server
to retry a similar lookup after that amount of time.

In the case where an SMTP transaction continues if it then follows that
the message is dropped then EXIM enters a rejectlog entry which the
eximbrl application inspects and that log entry will update the sqlite
zone file information for the RBL domain.

This update is automatically registered by powerdns, and the cycle will
repeat if the same host reconnects but this time the host DNS entry should
automatically RBL the connecting host.

Eg.

    2004-06-09 22:00:07 H=aboulogne-107-1-3-251.w80-11.abo.wanadoo.fr \
        (kewl.org) [80.11.200.251] F=<soporte@winzyrar.com.es> rejected RCPT \
        <anime-vip@kewl.org>: Sender verify failed
    
    2004-06-09 22:00:49 H=aboulogne-107-1-3-251.w80-11.abo.wanadoo.fr \
        [80.11.200.251] rejected connection in "connect" ACL: blacklisted at \
        rbl.kewl.org

The lifetime of an RBL entry is determined by the initial rejected
log entries. If a host has only one entry, then a minimal TTL is set. If
a host failed multiple times in that initial transaction, the TTL is
a multiplied by that number of entries.

Eg.

    host connects, delivers one failed RCPT, RBL updated with small TTL
    host connects, delivers 10 failed RCPT, RBL updated with 10X TTL

The above rules may be affected easily by applying the RBL check for
the MTA host in different places in the EXIM ACLs as this will cause
differing reject log entries.

Eg.
    
    acl_smtp_connect = connect_acl

    connect_acl:
      deny    message       = blacklisted at $dnslist_domain
              log_message   = blacklisted at $dnslist_domain
              dnslists      = rbl.kewl.org=127.0.0.2
      accept

    The above exim rules will work as described above, but if we move
    the RBL deny into acl_smtp_rcpt, then things will be different.

    In that instance, exim will log one line for all future RCPT
    failures, we can then match those in eximrbl and increase the
    TTL for that host.

The TTL of the host will also decrement in real time whilst eximrbl is running
until eventually it is below 60 seconds, and at that point it is removed
from the RBL zone.

4) Are there any drawbacks using this?

A drawback of using this method to drop connections are that should a
legitimate host connect and attempt to email a invalid recipient, yet
also wish to email a valid one, then it will be RBLd. It won't be able
to deliver a message to the valid recipient at a later time (at least
until it's RBL entry expires). In this scenario a sysadmin may only 
wish to log a warning in an X- header of an email rather than actually
drop connections, this means MX hosts would also be configured to pass
along messages.