From 7bc9c63c9da678a7e6fceb095d56c634afd22c56 Mon Sep 17 00:00:00 2001 From: V3n3RiX Date: Sun, 15 Dec 2019 18:09:03 +0000 Subject: gentoo resync : 15.12.2019 --- .../files/netqmail-1.06-any-to-cname.patch | 74 ++++++++++++++++++++++ 1 file changed, 74 insertions(+) create mode 100644 mail-mta/netqmail/files/netqmail-1.06-any-to-cname.patch (limited to 'mail-mta/netqmail/files') diff --git a/mail-mta/netqmail/files/netqmail-1.06-any-to-cname.patch b/mail-mta/netqmail/files/netqmail-1.06-any-to-cname.patch new file mode 100644 index 000000000000..9c9d53963510 --- /dev/null +++ b/mail-mta/netqmail/files/netqmail-1.06-any-to-cname.patch @@ -0,0 +1,74 @@ +From b05ec6cbdacdf40d6c75326394461e22b7f8ab20 Mon Sep 17 00:00:00 2001 +From: Jonathan de Boyne Pollard +Date: Fri, 12 Jul 2019 23:34:52 -0600 +Subject: [PATCH] Apply Jonathan de Boyne Pollard's any-to-cname 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. +--- + dns.c | 2 +- + 1 file changed, 1 insertion(+), 1 deletion(-) + +diff --git a/dns.c b/dns.c +index 44db25b..77e4ff7 100644 +--- a/dns.c ++++ b/dns.c +@@ -197,7 +197,7 @@ stralloc *sa; + if (!sa->len) return loop; + if (sa->s[sa->len - 1] == ']') return loop; + if (sa->s[sa->len - 1] == '.') { --sa->len; continue; } +- switch(resolve(sa,T_ANY)) ++ switch(resolve(sa,T_CNAME)) + { + case DNS_MEM: return DNS_MEM; + case DNS_SOFT: return DNS_SOFT; +-- +2.16.4 + -- cgit v1.2.3