Thursday, February 28, 2008

How Do I Enable remote access to MySQL database server?

Step # 1: Login over ssh if server is outside your IDC

First, login over ssh to remote MySQL database server

Step # 2: Enable networking

Once connected you need edit the mysql configuration file my.cfg using text editor such as vi.

* If you are using Debian Linux file is located at /etc/mysql/my.cnf location
* If you are using Red Hat Linux/Fedora Linux file is located at /etc/my.cnf location
* If you are using FreeBSD you need to create a file /var/db/mysql/my.cnf

# vi /etc/my.cnf
Step # 3: Once file open, locate line that read as

[mysqld]
Make sure line skip-networking is commented (or remove line) and add following line
bind-address=YOUR-SERVER-IP

For example, if your MySQL server IP is 65.55.55.2 then entire block should be look like as follows:
[mysqld]
user = mysql
pid-file = /var/run/mysqld/mysqld.pid
socket = /var/run/mysqld/mysqld.sock
port = 3306
basedir = /usr
datadir = /var/lib/mysql
tmpdir = /tmp
language = /usr/share/mysql/English
bind-address = 65.55.55.2
# skip-networking
....
..
....Where,

* bind-address : IP address to bind to.
* skip-networking : Don’t listen for TCP/IP connections at all. All interaction with mysqld must be made via Unix sockets. This option is highly recommended for systems where only local requests are allowed. Since you need to allow remote connection this line should removed from file or put it in comment state.

Step# 4 Save and Close the file

Restart your mysql service to take change in effect:# /etc/init.d/mysql restart
Step # 5 Grant access to remote IP address

# mysql -u root -p mysqlGrant access to new database
If you want to add new database called foo for user bar and remote IP 202.54.10.20 then you need to type following commands at mysql> prompt:mysql> CREATE DATABASE foo;
mysql> GRANT ALL ON foo.* TO bar@'202.54.10.20' IDENTIFIED BY 'PASSWORD';
How Do I Grant access to existing database?

Let us assume that you are always making connection from remote IP called 202.54.10.20 for database called webdb for user webadmin, To grant access to this IP address type the following command At mysql> prompt for existing database:mysql> update db set Host='202.54.10.20' where Db='webdb';
mysql> update user set Host='202.54.10.20' where user='webadmin';
Step # 5: Logout of MySQL

Type exit command to logout mysql:mysql> exit
Step # 6: Test it
From remote system type command:

$ mysql -u webadmin –h 65.55.55.2 –p

Where,

* -u webadmin: webadmin is MySQL username
* -h IP or hostname: 65.55.55.2 is MySQL server IP address or hostname (FQDN)
* -p : Prompt for password

You can also use telnet to connect to port 3306 for testing purpose:
$ telnet 65.55.55.2 3306

SMTP and POP with SSL (ucspi-tls-qmail-howto)

Why You Want To Use UCSPI-TLS

UCSPI-TLS is a protocol for adding "delayed encryption" to Dan Bernstein's Unix Client/Server Program Interface protocol. "Delayed encryption" means a session starts off in plaintext, then a command is issued to turn on encryption, encryption is negotiated, and the session restart. This has become a very common way to handle encryption, because it simplifies client configuration and requires only one TCP port.

These are the goals of UCSPI-TLS:

Simple, UCSPI-compatible use.
Support for both traditional SSL and delayed encryption through STARTTLS or similar.
All SSL/TLS code in one place.
Minimal changes required for each server.
Support for "privilege separation", so that encryption can happen in a low-privilege subprocess.

In particular, I believe the privilege separation feature increases your system's security significantly. It creates a dedicated process to handle each encrypted connection, and this process can change its root directory and switch to a low-privilege user and group. Because of its complexity, OpenSSL has had its share of security bugs. Doing encryption in a low-privilege process ensures that the impact of any security bugs is minimized.

How to install UCSPI-TLS for netqmail-1.05

UCSPI-TLS is currently implemented as patches to existing programs. To install it, first download the programs you want to use, apply the UCSPI-TLS patches, install the programs as you normally would, and finally make the appropriate changes to your configuration files.

Here are more details on doing this with netqmail version 1.05.

Become root, using su or sudo bash. Some of these steps require you to have superuser privileges, and its easier just to get them now than to switch back and forth throughout the process.
Do a base qmail install
Install qmail according to Life with qmail , and make sure everything works with a standard setup.
Install a patched ucspi-ssl+tls
Make sure you have a recent version of OpenSSL installed on your system, along with the files required for development with the library. If you don't already have it installed, this should be available from your OS install CDs, with a name like libssl-dev or openssl-devel. If all else fails, you can download OpenSSL and compile it yourself.
Download ucspi-ssl 0.70, and unpack it. It will create a directory host/superscript.com/net/ucspi-ssl-0.70; cd into this directory. Here's some commands to cut-n-paste:
```
wget http://www.superscript.com/ucspi-ssl/ucspi-ssl-0.70.tar.gz
gunzip -cd ucspi-ssl-0.70.tar.gz |tar xf -
cd host/superscript.com/net/ucspi-ssl-0.70
```

Download ucspi-tls patch to ucspi-ssl (you can also read the ucspitls for ucsp-ssl patch README), and apply the patch:

wget http://www.suspectclass.com/~sgifford/ucspi-tls/files/ucspi-ssl-0.70-ucspitls-0.1.patch
patch -p1 < ucspi-ssl-0.70-ucspitls-0.1.patch

If anything is already using an older copy of sslserver, shut it off now.
Compile and install the patched ucspi-ssl+tls, by running package/compile base then package/install base:
```
package/compile base
package/install base
```
You now have a patched copy of sslserver in /usr/local/bin/sslserver. Congratulations!
Patch qmail
The next step is to patch qmail to add TLS support to its SMTP and POP servers. If you followed Life with qmail religiously, your qmail source code will be in /usr/local/src/netqmail-1.05/netqmail-1.05. cd to that directory, or wherever you have the qmail source:
```
cd /usr/local/src/netqmail-1.05/netqmail-1.05
```

Now download the ucspi-tls patch to netqmail (and read the ucspitls patch for netqmail README), and apply the patch:

wget http://www.suspectclass.com/~sgifford/ucspi-tls/files/netqmail-1.05-ucspitls-0.3.patch
patch -p2 < netqmail-1.05-ucspitls-0.3.patch

If qmail is running, shut it down. On a Life with qmail setup, you do this by running:
```
/var/qmail/bin/qmailctl stop
```
Recompile and re-install qmail by running make setup check:
```
make setup check
```
You now have a copy of qmail-smtpd and qmail-popup with TLS support
Make your certificates
Next you'll need SSL certificates. These certificates contain the encryption keys used to communicate with your servers, and possibly a signature from a trusted authority confirming your server's identity. The first thing you'll need is a place to store them. Let's put them in /var/qmail/ssl:
```
mkdir /var/qmail/ssl
chown root /var/qmail/ssl
chmod 700 /var/qmail/ssl
cd /var/qmail/ssl
```
Create the SSL keys for your system. We'll store the certificate in a file named cert, and the key in key. If you already have certificates you'd like to use, separate out the certificate part (the key part will generally be labeled RSA PRIVATE KEY, and the cert part CERTIFICATE. You can just copy these sections from your certificate file, and paste them into the appropriate files.
You'll have to decide whether you want to use an unsigned certificate or a certificate signed by a Certificate Authority (CA). If you hire a CA to verify your identity and sign your certificate, clients are more likely to accept this certificate without prompting the user. If you use your own unsigned certificate, clients may have to confirm that they trust your certificate.
If you'd like to use a signed certificate, choose a CA, and follow their directions to obtain a signed certificate. Save the certificate in a file called cert, and the key in a file called key. If you just have one file containing both of these, see the beginning of this step for suggestions on how to split it up.
If you'd like to use an unsigned certificate, follow these steps:
1. Make sure openssl is installed on your system.
2. Set a umask that will keep your files protected, by running:
```
umask 077
```
3. Generate a certificate by running:
```
openssl req -new -x509 -keyout key.enc -out cert -days 360
```
  Answer the questions you're asked. Your password is temporary, so it doesn't matter what it is as long as you remember it for a few minutes; you can even write it down. Make sure you use the server's host name, as clients will be configured to connect to it, as the "Common Name" for the certificate. Note that this certificate will expire in 360 days, and you'll have to create a new one before then.
  You'll now have a file called key.enc containing your encrypted key, and a file called cert containing your certificate.
4. Remove the password from your certificate, so the server can start automatically. You can do this by running:
```
openssl rsa -in key.enc -out key
```
  Enter the password you chose above, and you'll have a file called key containing an unencrypted copy of your key.
Create a Diffie-Hellman parameter file. I usually create 1024-bit dhparam files, but I'll admit I don't know exactly what they do. I should probably find out and put it here. You can use the command
```
openssl dhparam -out dhparam 1024
```
to generate a 1024-bit Diffie-Hellman parameter file.
Add a user and group for SSL to drop privileges too; name them both ssl. How to do this depends on your OS and what tools it provides; you can find some examples in the qmail source directory in a file called INSTALL.ids. For example, on Linux you would run:
```
groupadd ssl
useradd -g ssl -d /var/qmail ssl
```
If you can't figure out any OS-specific commands, edit the /etc/group and /etc/passwd files directly, using the file format described in the system manpages for group(5) and passwd(5).

Create a file to set shell variables in /var/qmail/ssl/env. Put these lines in that file:

# Set these three
SSL_USER=ssl
SSL_GROUP=ssl
SSL_DIR=/var/qmail/ssl
# Enable UCSPI-TLS
UCSPITLS=1
# The rest are set based on the above three
SSL_CHROOT="$SSL_DIR"
CERTFILE="$SSL_DIR/cert"
KEYFILE="$SSL_DIR/key"
DHFILE="$SSL_DIR/dhparam"
SSL_UID=`id -u "$SSL_USER"`
if [ $? -ne 0 ]; then echo "No such user '$SSL_USER'" >&2; exit; fi
SSL_GID=`id -g "$SSL_GROUP"`
if [ $? -ne 0 ]; then echo "No such group '$SSL_GROUP'" >&2; exit; fi
# Export the variables used by other scripts
export SSL_CHROOT SSL_UID SSL_GID UCSPITLS CERTFILE KEYFILE DHFILE

Now set your umask back to something more usable, like 022:
```
umask 022
```
Set up qmail-smtpd
Edit the qmail-smtpd run file, in /var/qmail/supervise/qmail-smtpd/run. There are three changes required:
- The top of the file has several variable settings. Below these lines, include the SSL environment variable script we created above, using the shell's "dot" command, typed as a single period:
```
. /var/qmail/ssl/env
```
- On the line that contains softlimit, add 10MB (10,000,000) the number after the -m flag. This allows qmail-smtpd to use the extra memory required for SSL. For example, if it's currently 2000000, you would have for that line:
```
exec /usr/local/bin/softlimit -m 12000000 \
```
- On the line that contains tcpserver, change tcpserver to sslserver -e -n, leaving all of the other flags in place. The line will now look something like:
```
/usr/local/bin/sslserver -e -n -v -R -l "$LOCAL" -x /etc/tcp.smtp.cdb -c "$MAXSMTPD" \
```
Restart qmail to use the new configuration:
```
/var/qmail/bin/qmailctl restart
```

Now we'll try a few tests to make sure everything works. If any of these steps fails, double-check the steps above, look for errors in the error logs, and use your common sense to see what's going wrong. Look in the logs to see if there are any errors:

tail /var/log/qmail/smtpd/current

You should see something like this:

@40000000431fb29d10e09c2c sslserver: cafile 32655
@40000000431fb29d10e120fc sslserver: ccafile 32655
@40000000431fb29d10e14bf4 sslserver: cadir 32655 /usr/local/ssl/certs
@40000000431fb29d10e176ec sslserver: cert 32655 /var/qmail/ssl/cert
@40000000431fb29d10e1a9b4 sslserver: key 32655 /var/qmail/ssl/key
@40000000431fb29d10e1d4ac sslserver: param 32655 /var/qmail/ssl/dh 512
@40000000431fb29d10e226b4 sslserver: status: 0/20

Make sure the server is now offering TLS. To test this, you can connect to the server on port 25 and issue an "extended HELO" command (EHLO) and see what extensions the server offers. To do this, start at a shell and type in the lines marked below with *:
```
  * telnet localhost 25
   Trying 127.0.0.1...
   Connected to localhost.
   Escape character is '^]'.
   220 host.example.com ESMTP
 * EHLO there
   250-host.example.com
   250-PIPELINING
   250-8BITMIME
   250 STARTTLS
 * QUIT
   221 host.example.com
```
The line that says STARTTLS after you type EHLO means that the server has TLS configured.
Now test with a client to make sure things basically work. First start watching the logfile for errors:
```
tail --follow=name /var/qmail/supervise/qmail-smtpd/log/main/current
```
Unfortunately the client included with sslserver doesn't support TLS. If you have a copy of stunnel version 3 lying around, you can do something like this:
```
stunnel -r localhost:25 -f -c -n smtp -D debug -P none
```
Otherwise, just skip this test and try the test in the next step.
Finally, try turning on TLS in the mail clients you'll be using and sending a test message. Make sure there are no errors from the client or in the logs, and that the messages arrives successfully.
If this step works, you've set everything up correctly. Congratulations!
Set up qmail-pop3d
If you want to run a POP3 server, make sure you've set up qmail-pop3d as described in Life with qmail, then continue to follow these steps. If you're not running a POP3 server, you can skip this entire section.
Edit the qmail-pop3d run file, in /var/qmail/supervise/qmail-pop3d/run. There are three changes required:
- Near the top of the file, between the #!/bin/sh line and the line that begins with exec, include the SSL environment variable script we created above, using the shell's "dot" command, typed as a single period:
  . /var/qmail/ssl/env
- On the line that contains softlimit, add 10MB (10,000,000) the number after the -m flag. This allows qmail-smtpd to use the extra memory required for SSL. For example, if it's currently 2000000, you would have for that line:
  exec /usr/local/bin/softlimit -m 12000000 \
- On the line that contains tcpserver, change tcpserver to sslserver -e -n, leaving all of the other flags in place. The line will now look something like:
  /usr/local/bin/sslserver -e -n -v -R -H -l 0 0 110 /var/qmail/bin/qmail-popup \
Restart qmail to use the new configuration:
```
/var/qmail/bin/qmailctl restart
```
Now we'll try a few tests to make sure everything works. If any of these steps fails, double-check the steps above, look for errors in the error logs, and use your common sense to see what's going wrong. Look in the logs to see if there are any errors:
```
tail /var/log/qmail/pop3d/current
```
You should see something like this:
```
@40000000431fb29d10e09c2c sslserver: cafile 32655
@40000000431fb29d10e120fc sslserver: ccafile 32655
@40000000431fb29d10e14bf4 sslserver: cadir 32655 /usr/local/ssl/certs
@40000000431fb29d10e176ec sslserver: cert 32655 /var/qmail/ssl/cert
@40000000431fb29d10e1a9b4 sslserver: key 32655 /var/qmail/ssl/key
@40000000431fb29d10e1d4ac sslserver: param 32655 /var/qmail/ssl/dh 512
@40000000431fb29d10e226b4 sslserver: status: 0/20
```
Make sure the server is now offering TLS. To test this, you can connect to the server on port 110, then ask for a list of its capabilities. To do this, start at a shell, and type in the lines marked below with *:
```
  * telnet localhost 110
   Trying 127.0.0.1...
   Connected to localhost.
   Escape character is '^]'.
   +OK
 * CAPA
   +OK capability list follows
   STLS
   .
 * QUIT
   +OK
   Connection closed by foreign host.
```
The STLS line after you type CAPA indicates that the server supports TLS.
Now test with a client to make sure things basically work. First start watching the logfile for errors:
```
tail --follow=name /var/qmail/supervise/qmail-pop3d/log/main/current
```
Unfortunately the client included with sslserver doesn't support TLS. If you have a copy of stunnel version 3 lying around, you can do something like this:
```
stunnel -r localhost:110 -f -c -n pop3 -D debug -P none
```
Otherwise, just skip this test and try the test in the next step.
Finally, try turning on TLS in the mail clients you'll be using and receiving some test messages. Make sure there are no errors from the client or in the logs, and that the messages arrives successfully.
If this step works, you've set everything up correctly. Congratulations!

Optional Step: If desired, set up SSL servers

If you'd like to support SSL (not delayed encryption through TLS), you can still use the modified sslserver, and get the security advantages of chroot and privilege separation.

These steps will help you create an SSL service from a TLS service. The instructions are for qmail-smtpd; they will work for qmail-pop3d if you simply replace smtpd with pop3d everywhere.

Change directory to /var/qmail/supervise:
```
cd /var/qmail/supervise
```
Create a service directory and log directory:
```
mkdir -p qmail-smtpd-ssl/log
```
Copy the run file from the original service, and make it executable:
```
cp qmail-smtpd/run qmail-smtpd-ssl/
chmod 755 qmail-smtpd-ssl/run
```
Edit the run file (qmail-smtpd-ssl/run) in the following ways:
- On the line after . /var/qmail/ssl/env, add unset UCSPITLS
- On the line that contains sslserver line, remove the -n flag.
- On the next line, which will contain something like 0 smtp, change smtp to smtps; that tells sslserver to listen on the appropriate port for the SSL version of this service.

Set up a logging directory for this new service:

mkdir /var/log/qmail/smtpd-ssl
chown qmaill /var/log/qmail/smtpd-ssl

Set up the logging program for this new service, by creating a file in qmail-smtpd-ssl/log/run with these contents:
```
#!/bin/sh
exec /usr/local/bin/setuidgid qmaill /usr/local/bin/multilog t \
      /var/log/qmail/smtpd-ssl
```
Make sure the script is executable:
```
chmod 755 qmail-smtpd-ssl/log/run
```
Link the new service into the /service directory, to have it start automatically on boot:
```
ln -s /var/qmail/supervise/qmail-smtpd-ssl /service
```

Add the following to qmailctl's "start" section:

if svok /service/qmail-smtpd-ssl ; then
 svc -u /service/qmail-smtpd-ssl /service/qmail-smtpd-ssl/log
else
 echo qmail-smtpd-ssl supervise not running
fi

Add the following to qmailctl's "stop" section:

echo "  qmail-smtpd-ssl"
svc -d /service/qmail-smtpd-ssl /service/qmail-smtpd-ssl/log

Add the following to qmailctl's "stat" section:

svstat /service/qmail-smtpd-ssl
svstat /service/qmail-smtpd-ssl/log

Add the following to qmailctl's "pause" section:

echo "Pausing qmail-smtpd-ssl"
svc -p /service/qmail-smtpd-ssl

Add the following to qmailctl's "cont" section:

echo "Continuing qmail-smtpd-ssl"
svc -c /service/qmail-smtpd-ssl

Add the following to qmailctl's "restart" section:

echo "* Restarting qmail-smtpd-ssl."
svc -t /service/qmail-smtpd-ssl /service/qmail-smtpd-ssl/log

To test, use an SSL-enabled mail client, or use stunnel version 3:
```
stunnel -r localhost:smtps -f -c -D debug -P none
```

Optional Step: If desired, set up other servers

If you have any other TLS or SSL servers you'd like to set up, such as an IMAP server, you should be able to use the above steps as a template to get you started.

Required Step: Sleep better at night

Knowing your TLS- and SSL-protected mail server is secure.

Thanks

Rbldns How to

What is this document?

I wrote this HOWTO so that others can have one place to stop and see how to setup their own private RBL list. The information is out there, but scattered all over the place.

The color convention I use is to have the headlines in gray and the code / shell scripts in yellow

What is rbldns?

Rbldns is a suite of programs in conjunction with dnscache to provide RBL service. In a nutshell IPs put into the rbldns data file show up as 127.0.0.1 responses to a specially crafted DNS query.

The IP address go into the file in the normal readable way, ie 192.168.0.1, and you query for them by reversing the address, like 1.0.168.192.example.com

How do I use rbldns?

Normally you don't use it directly, you have a program query an RBL server and based on the result of the query it either runs or doesn't run the program following it.

For example with Qmail you'll change your qmail-smtpd/run file from
tcpserver 0 smtp /var/qmail/bin/qmail-smtpd
to
tcpserver 0 smtp /usr/local/bin/rblsmtpd -a whitelist.example.com -r blacklist.example.com -r relays.ordb.org /var/qmail/bin/qmail-smtpd

According to the rblsmtpd man page, the -r and -a switches mean:

Switch	If successful, do this
-r	Quit
-a	Don't do other lookups, and continue on

In this case the steps are:
1. Do a lookup against whitelist.example.com, if sucessful then skip the other lookups and go on to accepting the smtp request
2. Do a lookup against blacklist.example.com, if that's successful then quit out printing a "RBL denied" message to the client.
3. Same as #2 but against relays.ordb.org

How do I make my own RBL?

You should know how to setup Dnscache before trying to do this. The steps are pretty easy, but its helpful if you know your way around

Setting up the rbldns is pretty easy, just follow the directions on the RBLdns-conf page:

 rbldns-conf rbldns dnslog /etc/rbldns/black 127.0.0.2 rbl.example.com
rbldns-conf rbldns dnslog /etc/rbldns/white 127.0.0.3 whitelist.example.com

This says to setup a RBL on 127.0.0.2 that answers queries for *.rbl.example.com, and and RBL on 127.0.0.3 that answers for *.whitelist.example.com

Note: the 'rbl' and 'whitelist' names are arbitrary. RBLdns doesn't know if this is a 'good' or a 'bad' list of addresses -- it just knows that if someone asks for 1.0.168.192.bad.example.com on IP 127.0.0.2 it should answer with a 127.0.0.1 if it has it, or nothing if it doesn't.

Start these services up like all of DJB's other daemons:

 ln -s /etc/rbldns/black /service
ln -s /etc/rbldns/white /service

To see if they are running, do a

 lsof -n -i:53

And you should see listeners on 127.0.0.2 and 127.0.0.3

Why would I want to use a local RBL?

Why shouldn't you just relay on publically available RBLs? For a couple of reasons:
1. You know a couple of IPs are good and you don't want to waste bandwith by checking them against an RBL on the internet
2. Same thing for bad ones
3. You know your friend has a DSL line at home and an RBL blocks all home DSL users, you want to continue using the service but want to accept his mail.
4. You want to keep a 2nd source of information about who is sending mail to your server

So part of this is being a good netizen. If you know you're getting a lot of email from a handful of IPs, you should put those in your own whitelist so that you're not continously asking the public RBLs if they are okay

How to resolve *.(whitelist|rbl).example.com -- DNScache way

Now that we have the RBL service ready to go we have to be able to query it. Like we told dnscache to send all queries for *.example.com to the local tinydns IP address, we're going to do that for the RBL service.

This is the part that took me a while to think about: how do I serve both *.example.com and *.rbl.example.com? Well the same way you've already done it: through a dnscache setting.

Add two entries to your dnscache "forwarding" information:

 cd /service/dnscache/root/servers
echo 127.0.0.2 > rbl.example.com
echo 127.0.0.3 > whitelist.example.com
svc -h /service/dnscache

This tells dnscache that when it gets a query for *.whitelist.example.com to send it off to the server on 127.0.0.3, *.rbl.example.com queries should go to 127.0.0.2. If you're setup TinyDns this should be familiar

How to resolve *.(whitelist|rbl).example.com -- TinyDns way

This might be a little cleaner if you're already serving up *.example.com results. You put in your tinydns file pointers to the (rbl|whitelist) lists:

 cd /service/tinydns/root/
echo "&rbl.example.com:127.0.0.2:a" >> data
echo "&whitelist.example.com:127.0.0.3:a" >> data
make
svc -h /service/tinydns

So now when your tinydns server is queried for 1.0.168.192.rbl.example.com it will look at its file and say "That's handled by 127.0.0.2 and I'll ask it"

How do I add entries to my RBL?

Scenerio: a spammer is continously sending us email from 192.168.5.100 while our friend is sending from 192.168.6.56. We would like to avoid using public RBL servers for these two addresses.

Step 1: add the spammer to your spam list:

 cd /service/rbl/black/root
echo 192.168.5.100 >> data
make

Step 2: Add your friend to your good list:

 cd /service/rbl/white/root
echo 192.168.6.56 >> data
make

Now query to see if they are in there:

 dnsip 100.5.168.192.rbl.example.com
dnsip 100.5.168.192.whitelist.example.com
dnsip 56.6.168.192.rbl.example.com
dnsip 56.6.168.192.whitelist.example.com

Notice I queried both sets of databases to make sure we didn't screw up who is a spamer versus who is our friend.

If you don't get a 127.0.0.1 result from a query when you think you should, HUP the appropriate daemon:

 svc -h /service/rbl/black
svc -h /service/rbl/white

How do I now use an RBL service?

Now that you have the local RBLdns server(s) working through simple queries, modify your other scripts to use them. With qmail you do that like this:

exec /usr/local/bin/tcpserver -R -v -p \
  -x /var/qmail/control/tcp.smtp.cdb \
  -u $QMAILUID -g $QMAILGID \
  mail.example.com smtp \
  /usr/local/bin/rblsmtpd \
  -a whitelist.example.com \
  -r rbl.example.com \
  -r relays.ordb.org \
  -r bl.spamcop.net \
  /var/qmail/bin/qmail-smtpd 2>&1

This is what your implementation will probably look like: an initial test against your goodlist, if that passes the continue on to the qmail-smtpd part. If that fails, then test against your local bad list. If that is sucessful then quit out. If not, continue on to your 2nd and 3rd RBLs.

How do I test my RBL?

You test an RBL by sending it a query. If it is in the database then it should return with a 127.0.0.x (1 or 2) answer. If it isn't in there, then nothing comes back.

The trick is to remember to reverse your IP address, so that 192.168.0.1 becomes 1.0.168.192.myrbldomain.com

Here's a simple program to check names fed on stdin:

 #!/usr/bin/perl

use Net::DNS;
use strict;
my ($res, @rbls);

@rbls = qw (rbl.example.com whitelist.example.com);

$res  = Net::DNS::Resolver->new;
while (<>) {
 my ($rev, $ip);
 chomp;
 $ip = $_;
 $rev = (join ".", reverse (split /\./, $ip) );  # ie 4.3.2.1.
 foreach my $rbl (@rbls) {
  my $query = $res->search("$rev.$rbl");
  next unless ($query);
  my $hit;
  foreach my $rr ($query->answer) {
   next unless $rr->type eq "A";
   $hit = $rr->address;
   last;
  }
  next unless $hit;
  printf "%-20s %-20s $hit\n", $ip, $rbl;
 }
}

How do I contact you?

If you have any questions or comments, or just want to say thanks, drop me a line at anand.shah@coolaquarius.com

Anand Shah