If there is a domain for which the root response does NOT fit into the 512 bytes, qmail does not change properly to a TCP lookup, and will continue infinitely trying to fetch the DNS, while giving the message "CNAME lookup failed temporarily (#4.4.3)". If the message continues for too long, qmail will discard the mail as undeliverable. We used to include the patch for this many years ago, and we need to bring it back so that mail isn't lost.
This patch seems to work for me http://www.ckdhr.com/ckd/qmail-103.patch It only affects dns.c
(In reply to comment #1) > This patch seems to work for me > http://www.ckdhr.com/ckd/qmail-103.patch > > It only affects dns.c How to patch netqmail-1.06 correctly if QMAIL_PATCH_DIR variable in make.conf is not supported anymore?
Just add a epatchrow into de ebuild in an overlay that points to the patch.
I think we should add this back to the main ebuilds. The Yahoo DNS responses are now triggering this, so anybody trying to mail Yahoo addresses is going to run into this. @400000004d347fdf2beae5a4 starting delivery 126989: msg 344580 to remote (CENSORED)@yahoo.com @400000004d347fdf2beae98c status: local 0/20 remote 3/100 @400000004d347fdf2c153d7c delivery 126989: deferral: CNAME_lookup_failed_temporarily._(#4.4.3)/
This really does need to be added back ASAP. I have been suffering from this for quite some time, and should have spoken up much sooner. Several members of the local LUG mailing list I administrate have been probe removed because of CNAME lookup failures. Now its preventing me from communicating with ITT, who wanted me to be on a local advisory committee. I have seen a few patches floating around. I haven't gone about using them, since I would have to make an overlay and make it available to all servers, and deal with addition maintenance there, etc. I would really like to see the patch added to the ebuild in portage. If its problematic for others, which I can't see that being the case. Then maybe use flag the patch or something.
Went ahead and applied the patch mentioned in comment #1 and instantly resolves the issue. Didn't even having to restart qmail :)
(In reply to comment #4) > I think we should add this back to the main ebuilds. > > The Yahoo DNS responses are now triggering this, so anybody trying to mail > Yahoo addresses is going to run into this. Seconded. I changed VPS providers recently and rebuilt my system while doing so. Email to my wife (who uses Yahoo for her email) started failing. While researching the problem (and before checking here), I ran across this page: http://www.memoryhole.net/qmail/ It links to a couple of patches that appeared to be relevant to this bug: http://www.ckdhr.com/ckd/qmail-103.patch (large DNS response patch) http://homepages.tesco.net/~J.deBoynePollard/Softwares/qmail/any-to-cname.patch (replaces ANY requests with CNAME requests) With a patched ebuild that includes these, email to Yahoo is getting through again. My wife will no longer think I'm ignoring her. :-)
I have this problem too with several domains. Mentioned patch resolves the problem. I'm also think that it should be added ASAP into portage.
New URL for the any-to-cname patch, original went 404 http://www.memoryhole.net/qmail/any-to-cname.patch
today i struggled again over this. I found the following: http://comments.gmane.org/gmane.network.djbdns/14928 quite down is a post where someone says he had mailed dan bernstein on this. dan said, that dns.c should be patched to have dns_cname return always 0. this sounds at least reasonable to me, and maybe better than the cname patch at all. here the full mail ---------------------snip------------------- Hi Bhasker, Back in the 1990s there were many sites relying on the following feature of the SMTP infrastructure: If you set up www.your.site with a CNAME for your.site, mail to www.your.site will automatically be accepted by your.site's mailer. This feature was implemented by SMTP clients: the client would see the CNAME record for www.your.site and rewrite www.your.site as your.site in SMTP. This wasn't in the RFCs---I'm pretty sure that it started with Eric Allman misinterpreting a stupid side comment in the RFCs---but new clients such as qmail had to do the same thing for interoperability. Implementors discussing this in the late 1990s agreed that it would be good to drop this feature, eliminating all special knowledge of CNAMEs from clients and telling servers to take care of themselves. I hate to break the mail system, so I advocated a two-step transition with a gap in time between (1) warning clients to stop relying on the feature and (2) turning the feature off. Other people---including the RFC 2821 author---advocated simply turning the feature off, mail delivery be damned. I don't know who was the first to actually turn the feature off. I'm sure that there aren't any sites relying on the feature now. It's safe to simply skip the CNAME lookup: i.e., have dns_cname simply return 0. ---Dan ---------------------snip-------------------
Created attachment 337356 [details, diff] patch to dns.c to always return 0 from dns_cname This patch causes dns_cname() to always return 0, per advice from qmail author. I suggest adding a use flag to netqmail ebuild (named 'nolookup'), which will apply this patch when present.
Created attachment 337358 [details] update patch
Created attachment 337460 [details] ebuild with nocname useflag to apply patch to reutn 0 from dns_cname() this is an update to the ebuild, adding nocname useflag, in order to apply the patch that just returns 0 from dns_cname() rather than failing to send email due to a dns response greater than 512 bytes. If no useflag, the patch is not applied.
Created attachment 337462 [details, diff] patch to dns.c to always return 0 from dns_cname rename patch to match other patches in the files directory. patch does the same as before: always return zero from dns_cname().
I had a hell of a time getting email sent to various people at comcast.net. I applied these patches and no longer see: CNAME lookup failed temporarily. (#4.4.3) I hope this can be added to main-stream portage. This has hobbled Qmail for too long.
This is a pretty distressing bug for me because it happens any time mail is sent to a postini mail server (or google mail with postini active). My current workaround is not sustainable any longer (adding the highest priority MX server for the problem domain to /var/qmail/control/smtproutes). Is this patch in an overlay anywhere? Because other, seeing as this simple patch isn't going anywhere, I guess I'm left with the choice of building by hand or moving to postfix.
You could do what I did for now, which is make my own overlay. /etc/make.conf has PORTDIR_OVERLAY="/usr/local/overlays" mkdir -p /usr/local/overlays/mail-mta/netqmail rsync -a /usr/portage/mail-mta/netqmail/ /usr/local/overlays/mail-mta/netqmail Added my patch to the files subdirectory. Changed the ebuild to use the patch and named it netqmail-1.06-r1.ebuild, so it is ahead of current portage. ebuild netqmail-1.06-r1.ebuild digest emerge mail-mta/netqmail. But the bug should be addressed by the package maintainer. I voted for the bug.
I recently figured out that it is this bug that manifests when sending mail to @lists.gentoo.org. I assume that the DNSSEC stuff made the ANY response reasonably longer. However, until I figured out that it is not a general DNS problem on my side but a problem inside qmail itself, I already found Christopher Davis' patch and applied it to my netqmail install. The CKD-Patch applies cleanly to the netqmail-1.06 code base (and at least the ssl patch still applies cleanly afterwards). I personally feel like dealing with longer DNS responses is preferrable to just disabling cname lookup at all. cf. my thread on gentoo-users: http://www.gossamer-threads.com/lists/gentoo/user/269744
InCVS.
