Apply Jonathan de Boyne Pollard's any-to-cname patch.

[alanpost]

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.

[DerDakon]

@jdebp

[DerDakon]

The patch is absolutely fine. I just add this to make sure the original author has a few days time to comment on this before it get's merged.

[alanpost]

@jdebp,

Pleasure to meet you. This patch is hands down the most frequent issue we help with in the #qmail IRC channel on Freenode. If a person wanders in with delivery problems on their system it's likely to be resolved by applying this patch.

The commit message is my good-faith effort to summarize your writing on the topic. I modified the author field in the commit to name you, as I have only curated your material.