portal Ola

Netscape Messaging Server 4's SMTP daemon provides an API for protocol-level plugins that can affect the behaviour of the server during SMTP conversation. The sample antirelay.c plugin provides basic anti-relay facilities and is a satisfactory means for blocking relaying. On his web page, Yusuf Kursat Tuncel has published a modified version of that plugin that adds support for checking connecting client IPs in RBLs (Realtime Blackhole Listings). RBLs provide an effective method for blocking unsolicited bulk mail messages (commonly referred to as SPAM).

However, I've had no luck trying to use Yusuf's modified antirelay plugin - the SMTP server would quit on startup when trying to load the compiled plugin. Rather than correcting the source code of the plugin, I've decided to cook a more versatile solution myself using Dan J. Bernstein's rblsmtpd wrapper, NetCat and Perl.

In order to get a decent RBL functionality with Netscape Messaging Server 4 you'll have to:

1. Install all required DJB's tools - daemontools and ucspi-tcp
2. Create a service directory for rblsmtpd (read docs for daemontools on how to do that). See my sample run script, tcp rules file and Makefile.
   As you can see from the run script, we use the following RBLs:
   • sbl.spamhaus.org
   • list.dsbl.org
   • relays.ordb.org
   • relays.monkeys.com
   • formmail.relays.monkeys.com
   • proxies.relays.monkeys.com
   • bl.spamcop.net
3. Change the configuration of the Netscape SMTP service to listen on a port different than 25. You'll have to change the following options in local.conf:
   • alarm.nsmsgmsgalarmnoticeport
   • service.http.nsmsgsmtpport
   • service.smtp.nsmsgport

   My example script (see next section) connects to port 2500 through the loopback interface.

4. Optionally create a Perl script that would add a "Received" header on behalf of rblsmtpd process (as it doesn't do that by itself and only forwards all SMTP data to the given program). See the sample script I've created. If you don't do that, the source of all the incoming messages will look as if they were coming from localhost! My script adds an additional "Received" header on behalf of the whole tcpserver/rblsmtpd/netcat/forward_to_mailserver package. This received header supplies information about connecting client's IP address.
5. Symlink the rblsmtpd's service directory in svscan's services directory so it gets started and will be maintained by svscan.

You should be now able to connect to your mailserver and negotiate with it using SMTP - in fact you're talking to NMS through rblsmtpd, my Perl script and Netcat.

Try to connect to the server with a source address of 127.0.0.2 (nc -s 127.0.0.2) - it's a special source address for testing RBL-enabled servers. Instead of your mail server's banner you should see rblsmtpd's banner, and you will be rejected after you supply "MAIL FROM:" and "RCPT TO:". This is what a known spammer's server would see.

RBL is an extremely effective method of blocking spam - after its introduction on our mail server the amount of spam was reduced by over an order of magnitude. Some individuals who received ~ 40 unsolicited messages a day now only receive ~ 1 a day.

Of course, this doesn't come without a price. Occasionally, a business partner's or potential customer's mail server gets listed on a RBL due to a misconfiguration of that server (usually an open relay, in some cases even used historically by the spammers to send spam through it, which fact is usually documented at Spamcop). We counter that by constantly monitoring rblsmtpd's logs with a script which extracts IPs, reverse resolves them to get domain names, highlights possible legitimate hosts (those in .pl domain) and sends the list of blocked servers to all co-admins who then

• Unblock that particular host by supplying an entry similar to this one in the rblsmtpd service's tcp file (every change in that file requires compilation to tcp.cdb, the sample Makefile lets you do this by simply calling make from rblsmtpd service's directory)
• Try to find the contact to the admin of involved server and notify him by e-mail (our company offers IT training and support, so this even comes out as a double gain - blocking spam and gaining new customers!)
• If the admins remain unresponsive (we usually give them ~ 1 month), forward the case to sales dept. so that they can try and contact the involved company and offer them help in configuring their servers properly - be it in form of training, consulting or outsourcing.