• Qmail IPv6 support
  • tcpserver and rblsmtpd
  • sslserver
  • jgreylist
  • jms1 combined patch

ucspi-ssl

The ucspi-ssl package provides the sslserver program. sslserver accepts incoming SSL connections and passes them to another program such as qmail-smtpd. sslserver is almost identical to tcpserver except that it deals with encrypted SSL traffic rather than clear text.

I could not find an IPv6 patch for sslserver, however I was able to port the tcpserver patch to sslserver. You can easily apply my ucspi-ssl-0.70-ipv6.patch:

sslserver

To understand what the sslserver portion of the IPv6 patch does, you should be familiar with the sslserver man page and read about how tcpserver handles IPv6 on Fefe’s ucspi-tcp page. Essentially, if a client connects via IPv4, sslserver exhibits it’s normal behavior. If a client connects with IPv6, the PROTO environment variable will be set to “SSL6” instead of “SSL“.

The patch also supports using IPv6 addresses in your tcprules files. A new rule may look like this:

After applying this patch, you may notice that your logs are filled with addresses similar to: ::ffff:192.168.1.1. This is because internally sslserver treats every IP as an IPv6 address. IPv4 addresses are represented using their IPv4 mapped address.

Summary

If you have any comments, corrections, or questions, please feel free to leave a comment below. Remember Gentoo users can apply all of my qmail patches automatically by using the ebuilds in my gentoo-overlay.

Once you’ve patched sslserver, you should move on to patching jgreylist for IPv6.

• Qmail IPv6 support
  • tcpserver and rblsmtpd
  • sslserver
  • jgreylist
  • jms1 combined patch

ucspi-tcp

The ucspi-tcp package provides the tcpserver and rblsmtpd programs. tcpserver accepts incoming TCP connections and passes them to another program such as qmail-smtpd. rblsmtpd blocks connections from RBL listed IPs.

Thanks to Fefe, a patch has been around for a while that adds IPv6 support to tcpserver. Fefe’s patch does not touch rblsmtpd, however.

I’ve modified Fefe’s patch to patch rblsmtpd as well. You can easily apply my ucspi-tcp-0.88-ipv6.patch:

tcpserver

To understand what the tcpserver portion of the IPv6 patch does, you should read Fefe’s ucspi-tcp page. Essentially, if a client connects via IPv4, tcpserver exhibits it’s normal behavior. If a client connects with IPv6, the PROTO environment variable will be set to “TCP6“.

The patch also supports using IPv6 addresses in your tcprules files. A new rule may look like this:

After applying this patch, you may notice that your logs are filled with addresses similar to: ::ffff:192.168.1.1. This is because internally tcpserver treats every IP as an IPv6 address. IPv4 addresses are represented using their IPv4 mapped address.

rblsmtpd

When patching rblsmtpd for IPv6 support, I had to decide how to lookup IPv6 addresses. As far as I know, there aren’t any IPv6 blacklists yet. There isn’t a spec on how these addresses should be queried. My patch will use a new namespace, ipv6, when querying RBLs as described here. This means if you connect via 2001:470:1f0f:350::1, a TXT DNS lookup will be made to:

If anyone knows of a working RBL that differs, please let me know.

Summary

If you have any comments, corrections, or questions, please feel free to leave a comment below. Remember Gentoo users can apply all of my qmail patches automatically by using the ebuilds in my gentoo-overlay.

Once you’ve patched tcpserver, you should move on to patching ucspi-ssl (sslserver) for IPv6.

I’m not trying to defend IPv6. I realize there are many people with strong feelings towards the subject, including qmail’s author. Switching to IPv6 is a monumental task. It may never happen, but something needs to – we can’t keep NATing forever.

Many software projects have already added support for IPv6. My Gentoo box has been on an IPv6 network, via Hurricane Electric’s free tunnel broker service for a while now. Mac OS X has support for IPv6, as do the latest versions of Windows. Even Windows XP can support IPv6 if enabled. Postfix, Exim, and Sendmail all support IPv6.

In this series of posts, I will outline the steps I took to add IPv6 support to qmail. I use John Simpson’s combined patch for qmail as well as many other tools and methodologies described on his site, however many of the patches and instructions in these posts will work for other versions of qmail as well.

Components

John Simpson has an excellent illustration of a typical qmail system, Anatomy of a typical qmail system [PDF], on his website. The following articles describe the steps I took to enable IPv6 for each of the necessary components:

• tcpserver and rblsmtpd
• sslserver
• jgreylist
• jms1 combined patch

For Gentoo users, the patches described in each of the above posts can be installed automatically using the ebuilds in my gentoo-overlay. For others, I’ve listed all the IPv6 patches on my qmail patches page.

Testing

Testing your IPv6 enabled qmail setup can be a little confusing. There aren’t that many IPv6 enabled mail servers out there. Even worse, most people don’t have IPv6 connections.

Hurricane Electric provides a free IPv6 tunnel broker service that will allocate a /64 block of addresses that you can use. I host my personal mail server on a Linode which, despite being an excellent VPS, doesn’t have native IPv6. To get around this I set up a tunnel broker and enabled AAAA entries in DNS.

To test my setup, I had to install two separate qmail installs on different servers. Email addresses on my bltweb.net domain are now IPv6 enabled. If you’d like to use them to test, feel free to shoot me an email. Perhaps one day I’ll set up some type of reflector to automatically test.

IPv6 email experience

I’ve been running IPv6 mail servers at home and work for a few months now. I haven’t been keeping detailed statistics, but for the most part the only connections I’ve seen over IPv6 thus far have been spam

Still, enabling IPv6 in qmail wasn’t as hard as I thought it was going to be, thanks to the pre-existing patches on the internet. Hopefully more and more companies will start to enable IPv6 on their networks, such as Netflix. While email may still be even further out it never hurts to be ready.

Hopefully these posts have helped you add IPv6 support to your qmail install. Feel free to leave comments or questions below and I’ll do my best to address them.

Though this ebuild makes installing qmail with John’s patch a little easier, it doesn’t make administering a qmail system child’s play. Before merging this ebuild, you should read through John’s website. You may also want to read about netqmail on Gentoo. While this ebuild has nothing to do with netqmail, it does borrow some the conventions presented in the Gentoo doc concerning starting, stopping and controlling qmail.

I didn’t include any of John’s run scripts or configuration files. Only the combined patch is applied to the base qmail image. I’ve also included some additional patches I’ve found useful. They are described in more detail on my qmail patches page. Most of my extra patches are controlled by use flags (dkim, ipv6) and not applied by default.

For the impatient, here is a direct link to the ebuild:
http://svn.bltweb.net/repos/public/gentoo_overlay/mail-mta/qmail-jms1/qmail-jms1-7.08-r1.ebuild

Install my portage overlay

The easiest way to use the qmail-jms1 ebuild is to use my Gentoo Portage Overlay. Please see the overlay page for instructions on how to set it up.

You will need the following ebuilds from my overlay:

• virtual/qmail
• mail-mta/qmail-jms1
• sys-apps/ucspi-tcp
• mail-filter/libdkim (only needed if using the dkim use flag)

Install Qmail

Once the overlay is set up, installing qmail-jms1 is easy.

Add the following to your /etc/portage/package.keywords file:

Now install qmail-jms1:

Configure Qmail

Yeah right… There is plenty of documentation elsewhere for this. Try John’s website.

Start Qmail

 
 
That’s all I have for now. Installing, configuring and administering qmail should not be taken lightly. This ebuild has made it easier for me to set up and maintain my servers, however you should only consider using it if you are already familiar with setting up a qmail server.

Feel free to leave any comments, suggestions or problems below!

Support for DomainKeys in qmail has existed for a while thanks to a patch by Russel Nelson. Kyle Wheeler created a set of wrapper scripts that can be used to provide support for DKIM and DomainKeys. Mihai Secasiu has some wrapper scripts similar to Kyle’s that provide support for DKIM via the libdkim library instead of Perl’s Mail::DKIM module.

The current methods take different approaches to implement DKIM and DomainKeys. The DomainKeys patch creates a single program, qmail-dk that is called before qmail-queue. This program signs or verifies all incoming messages (that may later become outbound) based on the existence of the DKSIGN and DKVERIFY variables. The DKIM wrapper scripts wrap qmail-remote to sign messages and wrap qmail-queue (or qmail-dk) to verify incoming messages. This can be easier understood by looking at the qmail big picture.

I tend to agree with separate programs for signing outbound messages and verifying inbound messages as this allows signing all outbound messages, even those (such as NDRs) that never pass through qmail-queue. I also prefer patching qmail as it tends to be a little easier and requires less configuration after qmail is installed.

In this post I will show you how to patch qmail to support DKIM as well as DomainKeys. My qmail DKIM/DomainKeys patch uses neither Russel Nelson’s DomainKeys patch nor Kyle Wheeler’s DKIM/DomainKey wrappers, but borrows ideas from both. My patch uses the libdomainkeys and libdkim libraries to do the actual signing and verifying. Rather than creating two new programs, I patch qmail-smtpd (for verifying) and qmail-remote (for signing) directly.

I’ll do my best to provide step by step instructions for patching and installing for you non-Gentoo users, but in my next post I’ll share my ebuild which does it all for you.

1. Install libdomainkeys

The libdomainkeys library is used to sign and verify DomainKeys signatures.

2. Install libdkim

The libdkim library is used to sign and verify DKIM signatures. You’ll need g++ to compile this on your system. The library claims to be portable, but I needed to patch it to get it to compile on my Gentoo box. I’ve also included a (slightly modified) patch from Mihai Secasiu that makes working with libdkimtest much easier.

3. Patch and install qmail

I’m currently using John Simpson’s qmail Combined Patch Set for my qmail installation. The instructions below highlight how to apply my DKIM/DomainKeys patch on top of John’s combined patch. I’d highly recommend checking out John’s combined patch as it is about as close as you can get to an actively maintained qmail.

I’m not attempting to describe or document John’s patch in anyway in this post, as John runs an excellent site about qmail (qmail.jms1.net) that contains far more information than is contained here. Do not attempt to proceed without reading through John’s documentation as well as the rest of this post.

4. Configure DKIM/DomainKeys signing

Signing is done by qmail-remote and is controlled by the dksign control file. Signatures are created using a private key on your system, and verified by a public key stored in the DNS for the email domain.

Generate keys

Before you can sign an email, you must create at least one public/private key pair. You should create key pairs for every domain you wish to sign. To create keys for example.com:

It is very important that the default file be readable only by root and the group which qmailr (the qmail-remote user) belongs to. This is the private key used for signing messages and, if compromised, would allow others to sign messages as your domain.

Now add a TXT entry to the DNS for default._domainkey.example.com containing the quoted part in the /etc/domainkeys/example.com/default.pub. NOTE: You normally want to include the quotes!

Configure control files

Create a file /var/qmail/control/dksign containing one line:

The % will be replaced with the domain name in the From: header (or the Sender: header if it exists). If no file exists for the given domain, parent domains will be tried. For example if the message is from foo@bar.example.com, /etc/domainkeys/bar.example.com/default will be tested first. If the file does not exist, /etc/domainkeys/example.com/default will be tested. If no key can be found, the message will not be signed. If a key exists, but cannot be read or contains invalid data, the message will not be sent and will remain in the queue until the problem is fixed.

If you do not create the /var/qmail/control/dksign file, no messages will be signed.

Test outbound signing

Now that DKIM/DomainKeys signing is configured, you can test it by sending an email to sa-test (at) sendmail dot net. This reflector will reply (within seconds) to the envelope sender with a status of the DomainKeys and DKIM signatures.

If you experience problems, consult the qmail-remote man page or post a comment below and I’ll try to help.

5. Configure DKIM/DomainKeys verification

Verification is performed by qmail-smtpd and is controlled by the DKVERIFY environment variable. Messages are only verified if DKVERIFY is set and RELAYCLIENT is not set. You may control which IP addresses are verified using the tcpserver access file (sometimes stored in /etc/tcprules.d/tcp.qmail-smtp).

When verifying a message, the contents of DKVERIFY are checked against the status of the DomainKeys and DKIM results. Each test result is represented by a letter. DKVERIFY should contain a series of letters for DomainKeys results, a comma, and then a series of letters for the DKIM results. If the letter is uppercase, the message will be rejected (hard error). If the letter is lowercase, the message will be deferred (soft error). The DKVERIFY variable can be set but empty, in which case messages will be verified and an Authentication-Results: header will be added but all messages will be accepted regardless of status.

The letters for DomainKeys results are:

The letters for the DKIM results are:

I recommend a DKVERIFY value of DEGIJKfh,CGHIJMQRkl. This will only reject improperly formatted messages. Messages that don’t verify will still be allowed. I would advise against rejecting messages that don’t verify as there are still some problems with DomainKeys and DKIM (such as mailing lists). Rather than rejecting bad signatures, incorporate the Authentication-Results header into your broader spam prevention strategy.

The Authentication-Results header

All messages received by qmail-smtpd when DKVERIFY is set will add an Authentication-Results header to the incoming message. This header conforms to the IETF internet draft. Here’s an example from one of my emails:

Authentication-Results: bltweb.net; domainkeys=pass (ok); dkim=pass (ok)

6. Examples

Here are some examples to help you configure your box. Anything that normally should be private is made up.

Keys

For my bltweb.net domain name, here’s what my keys look like (these are not the actual keys installed on my system, those are private):

Signing Configuration

To sign emails for all domains for which I have a key in /etc/domainkeys, I set the control/dksign configuration file:

Verify Configuration

Here’s an example of my /etc/tcprules.d/tcp.qmail-smtp file. Make sure you regenerate the cdb file after editing your tcp.qmail-smtp file!

7. Finished

That’s it. You should now have a qmail installation capable of signing and verifying messages. More information is contained in the qmail-smtpd and qmail-remote man pages.

If you have any comments or find any bugs, please feel free to post a comment below.