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.
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.
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.
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
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
DKSIGN contains the location of the
key to be used for signing a message, and
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
DKVERIFY variables are implemented in the code makes it
impossible to ever verify a message if the DKSIGN variable exists at
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.
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
/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
present? Many people would enable signing for trusted IP addresses by
: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.
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
instead, or if you have a script which needs it, modify that script to use
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
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.
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!