spamdyke 2.6.3 Screenshot

spamdyke is a drop-in filter for qmail to provide connection-time blacklisting, graylisting, DNS RBL checking, improved logging, and more spamdyke project is a standalone program that does not use qmail source code or require patching/recompiling qmail.

For anyone who runs a mail server, spam is a problem. Its a huge problem and its only getting bigger. Unfortunately, qmail doesnt have many facilities for dealing with spam. qmail also doesnt do good logging. The qmail logs are probably useful to qmail developers but not to system administrators. Consider:

· Qmail doesnt log with a human-readable time format.
· Qmail logs dont track usable information (like senders and recipients).
· Qmail doesnt log to a single log file, making it very difficult to track an email from connection to delivery.
· Qmail logs roll over after a set size is reached (could be a few hours, could be a few minutes).

All of these things makes qmail very difficult to troubleshoot or monitor. spamdyke solves this. It monitors incoming traffic, acting as a middleman between qmail and the remote server. It catches the sender and recipient addresses as they go by and logs them to syslog. If it sees something it doesnt like (e.g. a blacklisted sender), it cuts the connection, closes qmail and fakes the rest of the SMTP transaction with the remote server. qmail thinks the remote server disconnected normally. The remote server thinks qmail is rejecting the message. Its the best of both worlds.

Some history: DJBs ucspi-tools package includes a handy little program called rblsmtpd for checking incoming SMTP connections against a DNSRBL. Initially, this seemed like a great thing (and it was) but it didnt go far enough. Lots of spam still came through. So after extending rblsmtpd to do more and more and more things, a limit was finally reached where it wouldnt go any further. Thus, spamdyke was born.

Here are some key features of "spamdyke":

· Reject the connection if the remote server has no reverse DNS entry.
· Reject the connection if the remote servers reverse DNS entry does not resolve.
· Reject the connection if the remote servers reverse DNS entry contains its IP address and a prohibited keyword (like "dynamic").
· Reject the connection if the remote servers reverse DNS entry contains its IP address and ends in a country code (whats the japanese word for "dynamic"?).
· Reject the connection if the remote servers IP address is listed in an IP blacklist.
· Reject the connection if the remote servers reverse DNS entry is listed in a domain name blacklist.
· Reject the connection if the remote servers IP address is listed in a given DNS realtime blacklist.
· Reject the connection if the remote server sends data before the SMTP greeting banner is displayed (earlytalkers).
· Reject the connection if the senders address is listed in a sender blacklist file.
· Limit recipients to a maximum number per connection. (Yes, this goes against RFC 821 but legitimate mail servers retry the rejected recipients, spammers dont.)
· Graylist incoming mail to specific domains (some domains can enjoy graylisting while others do not).
· Close the connection after a set idle time.
· Close the connection after a set maximum time.

Those filters end up rejecting more than 99.9% of the incoming connections to my mail server. As a result, I receive (on average) less than one spam message PER WEEK! (Down from a high of 70+ per day.) Regular correspondance with real people has not suffered.

Graylisting deserves special mention. As of 2007, its not widely used (and therefore still effective against spammers). Heres how it works:
An incoming connection is received and the sender and recipient are identified.

A log is consulted to see if the sender has sent email to the recipient before. If so, the message is accepted. If not, the message is rejected with a temporary rejection code and a log entry is made.
When the remote mail server retries the message (usually only a few minutes later), the previously-logged connection is noted and the message is accepted.

Simple, right? After the system is activated, regular correspondents first email is delayed a few minutes. After that, there are no delays. But the spam stops because most spammers dont retry their deliveries! Even when they do, they usually change their sender address to a new (fake) one, which gets graylisted.

Graylisting is amazing and makes a tremendous difference (for now). spamdyke will also:

· Bypass all filters if the remote servers IP address is listed in an IP whitelist file.
· Bypass all filters if the remote servers reverse DNS entry is listed in a domain name whitelist file.
· Log meaningful messages to the syslog (very unlike qmails logs).
· Log all SMTP traffic to aid diagnosing problems.

Whats New in This Release:

· This release fixes a serious bug that was causing lost mail when the remote server sent the message and disconnected in a burst without waiting for a response.
· Code has been added to translate bare line feeds into carriage return+line feeds.
· Support has been added for MUAs that send their username with their AUTH LOGIN command.