qmail Combined Patch Set

I have found a particular collection of patches that I use, and which I install on all of the machines I build for my clients. This list was fairly static for about two years, but I have recently (early 2005) started adding new features to it, thanks to suggestions and feedback received on the qmailrocks mailing list.

This page used to contain what amounted to the complete history of the patch file, but it was not organized very well- it made it rather difficult to figure out which features were included in each version of the patch. I have re-organized the page, so that instead of being a history lesson, it has links to specific pages for each released version of the patch. The patch files themselves can be downloaded from the combined patch details page.

If you are currently running a "qmailrocks" install and want to upgrade to this patch, please make sure to read my page on the other issues you will run into when upgrading from qmailrocks to my combined patch before you start working on your system.

Mailing lists

I have a one-way mailing list where I announce new versions of the patch, and a two-way discussion list which focuses on the patch, but also includes other topics relating to qmail and/or this web site.

http://qmail.jms1.net/lists/ has more information about both lists.

I'm using Bruce Guenter's ezmlm-browse to provide a web interface to read and search the archives. As an added bonus, it provides RSS feeds for the lists it watches.

http://www.jms1.net/lists/ is the address to view the archives.

Details

This section of the page used to be a list of the versions with a brief description of what was added or removed with each one, and a link to a specific web page for each version. However, it was becoming a pain to maintain so many pages whenever a new version came out, so I wrote a single page which contains all of the information, and a Javascript menu to select which version's information you want to see.

This page contains complete details about which features were added or fixed with each version of the combined patch.

In addition to the "series" patches listed on the other page, there is a domainkeys add-on patch available for version 6b which adds support for domainkeys signing and checking. Because it requires downloading an external library to do the domainkeys work, I am not able to "roll it into" the combined patch as cleanly as I would like. However, if you can install the library, this patch (meant to be applied after applying the normal combined patch from the list above) will create a program called qmail-dk which does the actual domainkeys work.

Note that there is a minor issue with how the qmail-dk program handles the environment variables which control its operation. I am waiting to hear from Russell Nelson about how, or whether, he wants to handle the issue. For now there is a work-around, possible because of the AUTH_SET patch.

To-Do Lists

These are ideas which I definitely plan to add to a future release. They may not be added right away, but the items on this list WILL happen.

• Copy the validrcptto.cdb patch changes (allowing certain addresses to be rejected, and using the conf-break value instead of assuming "-" when searching for "-default" entries) into the stand-alone validrcptto.cdb patch.

• Document the AUTH_CDB patch (which was accidentally added in version 6c5, and which does work if you know what you're doing.) I also want to find a way to split this out as a stand-alone patch for djb's original code and for netqmail, however I can see a lot of conflicts with other AUTH patches... Maybe if I just tell people "this won't work if you already have some other AUTH patch in there"...

• Expand the AUTH_CDB patch to allow for per-user environment variables, similar to how tcpserver parses its access control entries. This would allow per-user DATABYTES limits, for example.

• Fix the CRAM code so that, as long as there is a command-line program available to validate passwords, "AUTH CRAM" will be allowed even if the connection is not secure. Thanks to Tyler Larson for pointing out that this was needed.

• Write something similar to the MFCHECK patch, but which checks the RCPT TO value instead. This would mean that if you are using a DNS poison server to make certain domain names "not exist", nobody would be able to send mail to those domains- the RCPT commands would be rejected during the SMTP conversation rather than the message being accepted and then bouncing after sitting in the queue for several days.

These are ideas which I hope to add to a future release, but are "on the back burner" for now.

• Update the domainkeys add-on patch. Add optional logging for domainkeys activity (i.e. whenever a message is signed, or whenever the signature on a message is checked and what the result of that check was.)

• Add support for using vpopmaild or courierauthd to verify AUTH commands. This is something which, to be honest, I have only an academic interest in (I want to see if I can get it working) but I will not be using it on my own server, since I have AUTH_CDB working fairly well.

• MAYBE fix the qmail-dk program. The program relies on two environment variables: DKSIGN contains the location of the key to be used for signing a message, and DKVERIFY contains a set of letters which tell whether each SPF return value should be treated as a hard error, a soft error, or ignored. While adding domainkeys support to my service-qmail-smtpd-run script, I discovered that the way the DKSIGN and DKVERIFY variables are implemented in the code makes it impossible to ever verify a message if the DKSIGN variable exists at all.

  I have developed a work-around which uses my AUTH_SET patch to let you set up an AUTH_SET_DKSIGN variable which will become a DKSIGN variable when a successful AUTH command is processed. This requires that any message which is intended to be signed, must be sent by a client which does a successful AUTH command before sending the message.

  If the DKSIGN variable is set (as it would be if you were storing your keys in a non-standard directory) the qmail-dk program will ALWAYS try to sign the message, regardless of whether it comes from a "trusted" IP address or not.

  My idea is to add an environment variable called DKKEYS, which would contain the location of the key file(s) used to sign the message, and could be set without forcing the code to always sign and never verify messages.

  The existing DKSIGN variable would still exist, as a flag to allow signing messages. If the variable is present in the environment, the message CAN be signed, if a suitable signing key can be found in the directory pointed to by DKKEYS (with the default /etc/domainkeys/%/default used if the DKKEYS variable is not found.)

  The idea is that if DKSIGN is not present, or if it is present but a suitable key cannot be found, then the message would be verified instead. If you store your keys in a non-standard location, you can set the DKKEYS variable globally in your SMTP service's "run" script without affecting the "sign or verify" decision.

  Why would you want to verify a message when DKSIGN is present? Many people would enable signing for trusted IP addresses by adding :allow,RELAYCLIENT="",DKSIGN="" to the appropriate lines in their tcpserver access control file. Coming from an ISP background, I can see cases where my clients would be using IP space which we gave them, and therefore would have RELAYCLIENT access and the DKSIGN variable set, but might be running their own mail server which is adding domainkeys signatures for their outbound messages which are "From" their own domain. It might be nice to be able to verify those signatures when they send messages to us.

  If your users use AUTH in order to send mail out, you can use AUTH_SET_DKSIGN="" to have this variable created when they successfully AUTH, enabling your users' outgoing mail to be signed on your server.

  There was a suggestion that RELAYCLIENT be used for this decision- but the meaning of RELAYCLIENT is not always the same as the meaning of my planned DKSIGN_OK variable- you may not always want all messages from RELAYCLIENT addresses to be signed, and you may also want to be able to sign messages from IP's which are not RELAYCLIENTs.

  Status: I'm waiting to hear back from Russell Nelson (the author of the qmail-dk program, and somebody who knows a lot more about qmail than I do) before I implement this- I figure if this kind of change is going to be made, it should come from him. If I were to make this change and then he later fixes the same problem but goes about it in a slightly different manner, there would be chaos in the qmail world- and even though I may be slanted in a discordian direction, this is one case where chaos should be avoided.

• I'm looking into using Bruce Guenter's syncdir library (the web page is not Bruce's page, it's another page which describes the problem and has a walk-through of how to use it with qmail.) I'm not sure yet if it's going to be part of an actual patch or not, since (1) it's only needed for systems like Linux, where calls to link() may not be fsync()'ed to the disk immediately, and (2) while it can be harmlessly added on BSD systems, one of the header files it uses is in a different location which means the source code for the syncdir library itself would have to be changed.

  Thanks to Carl de Kock for reminding me that this problem existed- I remember reading about it years ago, back when I was first starting to use qmail, and never did get around to implementing it.

• It's been suggested that I add the "verh" patch, which performs certain kinds of header substitutions when doing deliveries. These substitutions can be useful for ezmlm mailing lists. I understand what they're doing, but haven't had the time to fully explore why it needs to be done- since I've only heard about it, and the problem that it supposedly solves, one time... I figure if it were really a major problem, I would have heard something about it by now. I'm not saying it will never be added, just that it's not a high-priority item for me.

Not To-Do List

These are patches which people suggested, and I thought about, and I have decided not to add for one reason or another.

• It has been suggested that qmail-smtpd should explicitly add RELAYCLIENT="" to the environment when a client does a successful AUTH command.

  Status: not going to happen.

  If you need this functionality, use AUTH_RELAYCLIENT="" instead, or if you have a script which needs it, modify that script to use the SMTP_AUTH_USER variable instead, which is set in case of a successful AUTH command (and will contain the userid which was used in the AUTH command).

  Also, be aware that the RELAYCLIENT environment variable is used for more than just granting permission to relay. Read the man page for qmail-smtpd (i.e. run "man qmail-smtpd" on your system) for more details.

Notes

• The environment variables requried by the new patch are not normally present, and will need to be added- either to your "run" script(s) for your SMTP service(s), or as per-client-IP options in your tcprules file (which is /etc/tcp.smtp.cdb on many systems.) My qmail scripts page has a greatly expanded /service/qmail-smtpd/run script which can be used to run any kind of SMTP server, which has comments for the new variables.

• Most of the documentation which exists for the newer features that the patch adds to qmail-smtpd can be found in the service-qmail-smtpd-run script. I am working on fleshing out the documentation on this web site, but for now you should refer to the directions within the script itself.

• If you're going to use the validrcptto.cdb functionality, you will need to generate a cdb file whose keys are every valid email address on your system (the values, if any, are ignored.) The keys in this file MUST BE LOWERCASED. If you have any domains for which the RCPT TO check should not be done, or for which every email address should be considered valid (i.e. if you have a catch-all address specified) you should list this domain as "@domain.name" in the file.

  I have written the mkvalidrcptto script which can be used to generate the required cdb file. It scans your system and generates a list of valid email addresses. The output of this script can be used to generate a flat text file which is suitable for use with the original "validrcptto" patch (if you happen to have built that version yourself), or which can be piped through the cdbmake-12 program from djb's cdb package to produce the cdb file needed for my patch.

• For people like myself who write scripts involving the combined patch, I have two text files on the site which identify the current "stable" and "testing" versions of the patch. The files are combined-stable.txt and combined-testing.txt. I will be updating these files whenever I change what I consider to be the "stable" and "testing" versions.

A quick note to everybody who's been looking at, finding problem with, and suggesting new features for the code I've written here, especially everybody on the qmailrocks mailing list ... THANK YOU!

Copyright 1995-2024 John M. Simpson KG4ZOW (email) (PGP key)
Last updated 2008-08-08 03:43:32 +0000