For a quick and dirty work around. If you have a non-qmail SMTP server that can send outbound email and will allow relaying from the server with the backlog, you can try adding an entry in smtproutes for the remote domain that is causing the CNAME error that will forward all mail for that domain to the other non-qmail SMTP server, then restart(?) qmail-send to "requeue" messages for the domain.
I have used something like this workflow in the past but I have relay access to both postfix and sendmail servers that make this an easy fix.
—Ian
From: "michael@hudsonstreet.us<mailto:michael@hudsonstreet.us>" <michael@hudsonstreet.us<mailto:michael@hudsonstreet.us>>
Date: Monday, August 31, 2015 at 4:26 PM
To: "msayah@controlcc.com<mailto:msayah@controlcc.com>" <msayah@controlcc.com<mailto:msayah@controlcc.com>>, qmail List <qmail@list.cr.yp.to<mailto:qmail@list.cr.yp.to>>
Subject: RE: CNAME LOOKUP
This is production server with a backloged queue. I can't start from scratch at this point
Sent from my Windows Phone
________________________________
From: msayah@controlcc.com<mailto:msayah@controlcc.com>
Sent: 8/31/2015 5:23 PM
To: michael@hudsonstreet.us<mailto:michael@hudsonstreet.us>
Cc: qmail@list.cr.yp.to<mailto:qmail@list.cr.yp.to>
Subject: Re: CNAME LOOKUP
Hi Mike,
I run a fairly plain qmail setup (not NetQmail) and have a script which
patches qmail starting from the DJB baseline qmail-1.03.tar.gz. After
tar extracting the contents of the original DJB qmail-1.03.tar.gz, the
errno patch is applied, then the any-to-cname patch, and then the DNS
oversize-dns-packets patch.
I believe the http URLs below still host these patches. if not I have
the patches (small text files).
#
# http://cr.yp.to/software/qmail-1.03.tar.gz
#
tar -xpf qmail-1.03.tar.gz || exit $status
sync
#
cd qmail-1.03 || exit $status
#
# http://www.thedjbway.org/patches/djb_errno_patches.tgz
#
patch < ../djb_errno_patches/qmail-1.03.errno.patch
if ( $status ) exit $status
sync
#
# Jonathan de Boyne Pollard
# http://www.memoryhole.net/qmail
patch < ../qmail-patches/qmail-1.03-any-to-cname.patch
if ( $status ) exit $status
#
# Christopher K. Davis patch
# http://qmail.org/top.html
patch < ../qmail-patches/qmail-1.03-oversize-dns-packets.patch
if ( $status ) exit $status
#
.
.
.
a few more patches
-----------------------------------------------------------------------
Some old original doc:
My mail is not being delivered. The log says "deferral: CNAME_lookup_failed_temporarily._(#4.4.3)/"
The "qmail.org" web site suggests that you may be able to get around
this problem somewhat by installing the "djbdns" package, and in
particular, "dnscache" from that package.
Installing "djbdns" is generally a good idea, but it does not
genuinely fix this problem.
The cause of this problem is as follows:
"qmail-remote" wants to perform "CNAME" lookups of the domain
names that mail is to be sent to. However, instead of doing a
"CNAME" DNS lookup directly, it performs an "ANY" DNS lookup
and scans the result for "CNAME" resource records. It does
this because of a bug in BIND version 4 that would be triggered
if it did "CNAME" lookups directly.
But "qmail" only employs a 512-byte buffer to receive the DNS
response. Unfortunately, an "ANY" lookup for several popular
domains (such as "aol.com.") now yields a response bigger than
512 bytes, and the DNS lookup fails because the response size
exceeds the size of the buffer that "qmail" has to hold it.
(An "ANY" response for "aol.com." was 543 bytes - and even that
was with the "glue" stripped - at the time of writing this
answer.)
Installing "dnscache" partially alleviates this problem because
"dnscache" provides smaller answers to "ANY" queries than other
proxy DNS server softwares, such as BIND, do. This happens to
defer the onset of this problem in most cases.
However, this is not a true solution. The problem can still occur
even if one employs "dnscache". The the maximum size that a DNS
response can be is 65536 bytes, and "qmail"'s DNS response buffer
should therefore be capable of holding responses up to this size.
The correct fix is to apply Christopher K. Davis' patch (hyperlink
given above) that increases "qmail"'s buffer to 65536 bytes.
Whilst you are about it, you also might consider applying the
patch (hyperlink given above) that makes "qmail" actually use
"CNAME" queries when it wants to look up "CNAME" resource
records.
-----------------------------------------------------------------------
-rw-r--r-- 1303 Jan 13 2003 qmail-1.03.errno.patch
-rw-r--r-- 403 Oct 30 2010 qmail-1.03-any-to-cname.patch
-rw-r--r-- 2104 Oct 26 2010 qmail-1.03-oversize-dns-packets.patch
-----------------------------------------------------------------------
This qmail running on all versions of Slackware Linux versions
from 10.1 to 14.1
Mike Sayah
msayah@controlcc.com<mailto:msayah@controlcc.com>
>Date: Mon, 31 Aug 2015 16:48:05 -0400
>Subject: Re: CNAME LOOKUP
>From: Michael DiMartino <michael@hudsonstreet.us<mailto:michael@hudsonstreet.us>>
>To: ed <ed-qmail@s5h.net<mailto:ed-qmail@s5h.net>>
>Cc: qmail List <qmail@list.cr.yp.to<mailto:qmail@list.cr.yp.to>>
>
>???Ed,
>Yes, I tested the MX lookup. That's why this is so ???puzzleiing to me.
>
>[root@smtp1 qmail]# host -t mx outlook.com
>outlook.com mail is handled by 10 mx4.hotmail.com.
>outlook.com mail is handled by 10 mx3.hotmail.com.
>outlook.com mail is handled by 10 mx2.hotmail.com.
>outlook.com mail is handled by 10 mx1.hotmail.com.
>[root@smtp1 qmail]#
>
>
>
>
>Mike Di Martino, CEO/Founder
>M: +1 631 988 6060
>F: +1 206 202 1807
>E: michael@hudsonstreet.us<mailto:michael@hudsonstreet.us>
>W: www.hudsonstreet.us
>
>
>
>On Mon, Aug 31, 2015 at 4:41 PM, ed <ed-qmail@s5h.net<mailto:ed-qmail@s5h.net>> wrote:
>
>> On Mon, Aug 31, 2015 at 04:36:25PM -0400, Michael DiMartino wrote:
>> > I have searched the forums and the web in general, but the replies deal
>> w/
>> > older versions of qmail specially pre NetQmail.
>> >
>> > My issue have over 100 emails sitting in the queue due to
>> >
>> > delivery 289: deferral: CNAME_lookup_failed_temporarily._(#4.4.3)/
>> >
>> > Most of these are known legitimate email addresses, like my @outlook.com
>> > address.
>> >
>> > How can this be resolved, my users are beginning to complain.
>>
>> Have you tested that DNS does work from your mail server?
>>
>> Something like:
>>
>> $ host -t mx outlook.com
>>
>> It should return the MX records (currently mx[1-4].hotmail.com).
>>
>> --
>> Best regards,
>> Ed http://www.s5h.net/
>>
>>