ordbscan - scan sendmail logs for ORDB bounces

ORDB Background

The Open Relay Database is an increasingly-popular tool in the fight against spam, and it works by allowing system operators to reject traffic from insecure mail servers. These insecure servers are a scourge of the internet, and by rejecting their traffic it reduces spam and motivates the server operators to clean up their acts.

Our experience is that the vast majority of mail rejected by ORDB is actually spam, but occasionally we find "false positives": blocked mail from people we want to interact with. These folks are in fact running insecure mail servers, but here we can at least help them fix them.

ordbscan is a tool to process sendmail logfiles and report on all the mail bounced by ORDB, and a visual scan of the output usually shows the "obvious" candidates for further investigation.

Sendmail ORDB Configuration

This is not a tutorial on sendmail, but we can highlight the configuration we use to employ ORDB. We always use the normal sendmail ".mc" macros because doing the raw configuration files by hand is madness. Adding ORDB support to sendmail is straightforward: simply add these two lines to the dot-mc file:

FEATURE(`delay_checks')dnl
FEATURE(`dnsbl', `relays.ordb.org', `Rejected - see http://ordb.org/')dnl

NOTE: This is for my version of sendmail. You should check your sendmail documentation for the details on yours.

Rebuild the configuration and "kick" sendmail. Now, mail from insecure servers will be rejected and logged.

Note that the delay_checks feature is crucial to using ordbscan. Without it, sendmail will reject mail from open relays very early in the SMTP conversation, before the recipients are known. It's more efficient to reject the traffic early, but by delaying the checks until RCPT time (recipient processing), sendmail logs both sender and recipient. ordbscan relies on this behavior.

Running the program

ordbscan is run on the command line by providing the names of one or more sendmail logfiles. It scans them in turn, collecting the senders and recipients, and reports them grouped by recipient. This allows for parcelling out the listing by recipient asking "Do any of these senders ring any bells?".

# ordbscan /var/log/maillog
Processing /var/log/maillog

To: user1@customer.zz
   7878khb87bb7b8@msn.zz             Jun 25 08:40:01 R=195.207.155.237
   bizzey@gala.zz                    Jun 25 06:44:35 R=211.144.1.230
   bizzey@gala.zz                    Jun 25 06:20:05 R=211.144.1.230
   steve@unixwiz.net                 Jun 24 15:37:12 R=64.170.162.98   <-- false positive
   jose_kocstone586@Flashmail.zz     Jun 23 22:00:17 R=211.42.39.130

To: webmaster@customer.zz
   freehghletters@Flashmail.zz       Jun 24 18:21:23 R=216.153.210.20

Note: we use the non-domain .zz here so the spambots won't pick up valid email addresses. Each recipient is listed with all senders to that address, and the right columns contain the send date and the mail server used to relay the attempted messages.

Here we observe one "obvious" false positive.

Dealing with False Positives

If ordbscan reveals any senders that are "interesting", there are three possible actions to take:

Ignore it

Every message rejected by ORDB is bounced to the sender with a reason for the rejection. They are pointed to the ordb web site and can decide to fix things on their own. Not surprisingly, this is the default.

Whitelist the server

If the sender is unwilling or unable to secure their relay (though there are not really any good reasons not to), it's possible to put them on a local "whitelist" to allow them to mail, the blacklist notwithstanding.

This is typically done via the access database, though the details depend on the particular version of sendmail being used. Normally whitelisting is done via IP address, not domain, so an entry in the file might look like:

# S. Friedl (added 2002/06/25)
64.170.162.98           OK

Always include a note as to why the entry appears, and date it so you can clean out older entries periodically. Whitelisting is not really solving any problems, so it's best to do this as a last resort only.

Help the sender fix his server

This is the most helpful approach: if their mail server is listed by ORDB, they are open to relaying spam and contributing to the pollution found on the internet. Contacting the sender with links to resources on how to secure their servers would be doing a service to more than just the sender: the ORDB web site has plenty of links for this.

Note that if you send an email to the responsible party, you won't get a response until they get themselves off ORDB. You may need to temporarily whitelist them as shown in the previous section.

But you'll probably find that efforts to help get you completely ignored or treated as if you are the problem. You've been warned.

Download

This is a simple perl program and should run without change on most UNIX/Linux systems.

ordbscan.txt - perl source code

Navigate: More Tools