These are some minor softwares for use with Dan Bernstein's qmail.
This patch modifies the behaviour of qmail-smtpd so that it responds with a 500 error code to unrecognised SMTP commands instead of a 502 error code.
RFC 2821 section 4.2.4 says
502 SHOULD be used when the command is actually recognized by the SMTP server, but not implemented. If the command is not recognized, code 500 SHOULD be returned.
Stock qmail-smtpd does not have a "recognized, but not implemented" category of commands. A command is either recognised and implemented, or not implemented and not recognised. However, the patch allows for such commands to be added in the future (by the simple expedient of explicitly making err_unimpl() the implementation of the relevant command).
This is not a qmail-smtpd bug, for two reasons:
A violation of a "SHOULD" does not make an implementation non-conformant. However, one should have a good reason for violating a "SHOULD", and (given that it's no harder to return the recommended error code) qmail-smtpd has no such reason.
RFC 2821 is dated April 2001. qmail version 1.03 is dated June 1998.
This patch modifies the behaviour of qmail-smtpd so that if a GET, POST, or HEAD verb is used, it will respond with a 221 code and abort the session.
A common abuse is to send mail by having the back end of a proxy HTTP server connect to an SMTP Relay server, and perform an SMTP transaction under the mistaken belief that it is performing an HTTP transaction.
This patch is a simple way of avoiding SMTP Relay clients that are actually the back ends of proxy HTTP servers. It simply aborts the session when it encounters an HTTP verb.
The risk of using this patch is that one's SMTP Relay service will be incompatible with any future extension to the SMTP protocol that employs those verbs.
This patch modifies the behaviour of qmail-remote to remove the workaround that Dan Bernstein added on 1996-10-03 to work around a bug in BIND versions earlier than version 4.9.4.
Applying this patch incurs a risk, but yields a benefit. It is published in order to allow others to experiment with removing the workaround.
The risk is twofold:
qmail-remote will not be able to relay any mail if one's own proxy DNS server is such a version of BIND. This is trivially overcome by replacing such an old version of BIND either with a new version of BIND that doesn't have the problem or with some other proxy DNS server software entirely (such as dnscache).
qmail-remote will not be able to relay mail to domains whose content DNS servers use such versions of BIND, because the "CNAME" resource record lookup will fail. To gauge the level of this risk, notice that Dan's own 2002-12-17 survey of content DNS servers reports a mere 2% of the "*.com." content DNS servers as employing BIND version 4 (but doesn't report how many of that 2% employ BIND 4 versions earlier than 4.9.4).
The benefit of this patch is that it reduces DNS query traffic and proxy DNS server cache load.
Without it, qmail-remote issues "ANY" queries. Some proxy DNS server softwares (albeit not dnscache) pass such queries through directly to the back end, meaning that every query issued by qmail-remote will result in a back-end query to a content DNS server, no matter if the necessary information is already cached. Moreover: The results of such a query, which are often a large collection of resource record sets of various types, are cached in the proxy DNS server's cache, even though almost none of them will be used. A caching proxy DNS server dedicated to serving qmail will end up with all sorts of cruft in its cache that isn't actually relevant to mail transportation, taking up space that could be better put to use caching those resource record sets that are relevant.
With it, qmail-remote issues "CNAME" queries. All of the mainstream proxy DNS server softwares in popular use (apart from dnscache, because it has problems in this regard) don't pass such queries directly through, and will answer them from their caches without issuing a back-end query at all if the data are already there and still current. Moreover: A caching proxy DNS server dedicated to serving qmail will not have its cache cluttered with irrelevant data.