Google Groups no longer supports new Usenet posts or subscriptions. Historical content remains viewable.
Dismiss

CNAME failed at ouutlook.com

27 views
Skip to first unread message

BAGI Ákos

unread,
Jul 21, 2015, 1:52:52 PM7/21/15
to
Hi List!

I have a production system and is running fine.

However there is one address managed by
<company>-com02c.mail.protection.outlook.com

Which throws since yesterday
deferral: CNAME_lookup_failed_temporarily (#4.4.3)

I checked the "host -T -t mx <domain>" and the answer is 82 bytes only.
Other addresses are working fine.

Any clues?

Thx in advance
Akos





--
Posted automagically by a mail2news gateway at muc.de e.V.
Please direct questions, flames, donations, etc. to news-...@muc.de

K. Peter

unread,
Jul 21, 2015, 2:20:12 PM7/21/15
to
On 2015-07-21 19:50, BAGI Ákos wrote:
> Hi List!
>
> I have a production system and is running fine.
>
> However there is one address managed by
> <company>-com02c.mail.protection.outlook.com
>
> Which throws since yesterday
> deferral: CNAME_lookup_failed_temporarily (#4.4.3)
>
> I checked the "host -T -t mx <domain>" and the answer is 82 bytes only.
> Other addresses are working fine.
>
> Any clues?
>
> Thx in advance
> Akos
This (outlook.com) is a Russian spam domain. They have a ttl of max 300
through a bogus ns.

Jonathan Knopp

unread,
Jul 21, 2015, 3:00:01 PM7/21/15
to
I ran into this error message a couple weeks ago too, and for me it was a result of name.com (big registrar) denying DNS ANY requests, which qmail uses to look for CNAMES on the From and Reply-To headers' domains. Unfortunately qmail handles a failed response on this request badly, given it isn't actually needed in the first place. You could try patching qmail to use CNAME instead of ANY for that request (though I don't know if the bind bug that prompted that change in the first place is still out in the wild), or use the patch that disables the canonical lookup altogether.

http://fanf.livejournal.com/122220.html discusses the issue and provides both possible fixes.

I haven't actually applied either yet, just created a static route temporarily for the one domain we were having issues with. But given that name.com is not a small registrar and they aren't likely to change their minds it is probably something that needs to be addressed in qmail distributions sooner than later.

BAGI Ákos

unread,
Jul 21, 2015, 4:20:16 PM7/21/15
to
Hi!

Thx I solved the proble with your help:
- smtproutes made the magic :)
- but temporarily only, because I think outlook.com will change the ip-s
and a fix
route won't work for a longer period.
- I would however avoid to patch qmail on a running system.

I really do not understand what is the reason of the error if the
response is 80 bytes
only and the dns.c patch is useful when the 512 bytes response limit is
crossed.

BR
Akos

2015.07.21. 20:57 keltezéssel, Jonathan Knopp írta:
> I ran into this error message a couple weeks ago too, and for me it was a result of name.com (big registrar) denying DNS ANY requests, which qmail uses to look for CNAMES on the From and Reply-To headers' domains. Unfortunately qmail handles a failed response on this request badly, given it isn't actually needed in the first place. You could try patching qmail to use CNAME instead of ANY for that request (though I don't know if the bind bug that prompted that change in the first place is still out in the wild), or use the patch that disables the canonical lookup altogether.
>
> http://fanf.livejournal.com/122220.html discusses the issue and provides both possible fixes.
>
> I haven't actually applied either yet, just created a static route temporarily for the one domain we were having issues with. But given that name.com is not a small registrar and they aren't likely to change their minds it is probably something that needs to be addressed in qmail distributions sooner than later.
>
> On 15-07-21 10:50 AM, BAGI Ákos wrote:

Ian Foutch

unread,
Jul 21, 2015, 4:50:31 PM7/21/15
to
If you want to avoid patching qmail and maintaining smtproutes you could add a local caching DNS server to handle the queries, see dnscache. Bind as well as many other options are available for this as well.

--Ian
________________________________________
From: BAGI Ákos [ab...@compuflex.hu]
Sent: Tuesday, July 21, 2015 3:12 PM
To: qm...@list.cr.yp.to
Subject: Re: CNAME failed at ouutlook.com

Hi!

Thx I solved the proble with your help:
- smtproutes made the magic :)
- but temporarily only, because I think outlook.com will change the ip-s
and a fix
route won't work for a longer period.
- I would however avoid to patch qmail on a running system.

I really do not understand what is the reason of the error if the
response is 80 bytes
only and the dns.c patch is useful when the 512 bytes response limit is
crossed.

BR
Akos

2015.07.21. 20:57 keltezéssel, Jonathan Knopp írta:
> I ran into this error message a couple weeks ago too, and for me it was a result of name.com (big registrar) denying DNS ANY requests, which qmail uses to look for CNAMES on the From and Reply-To headers' domains. Unfortunately qmail handles a failed response on this request badly, given it isn't actually needed in the first place. You could try patching qmail to use CNAME instead of ANY for that request (though I don't know if the bind bug that prompted that change in the first place is still out in the wild), or use the patch that disables the canonical lookup altogether.
>
> http://fanf.livejournal.com/122220.html discusses the issue and provides both possible fixes.
>
> I haven't actually applied either yet, just created a static route temporarily for the one domain we were having issues with. But given that name.com is not a small registrar and they aren't likely to change their minds it is probably something that needs to be addressed in qmail distributions sooner than later.
>
> On 15-07-21 10:50 AM, BAGI Ákos wrote:

Richard Archer

unread,
Jul 21, 2015, 5:02:50 PM7/21/15
to
On 22/07/15 4:57 AM, Jonathan Knopp wrote:
> I ran into this error message a couple weeks ago too, and for me it was a result of name.com (big registrar) denying DNS ANY requests, which qmail uses to look for CNAMES on the From and Reply-To headers' domains. Unfortunately qmail handles a failed response on this request badly, given it isn't actually needed in the first place. You could try patching qmail to use CNAME instead of ANY for that request (though I don't know if the bind bug that prompted that change in the first place is still out in the wild), or use the patch that disables the canonical lookup altogether.
>
> http://fanf.livejournal.com/122220.html discusses the issue and provides both possible fixes.
>
> I haven't actually applied either yet, just created a static route temporarily for the one domain we were having issues with. But given that name.com is not a small registrar and they aren't likely to change their minds it is probably something that needs to be addressed in qmail distributions sooner than later.

I installed this patch and it solved my problems.

Ref: http://fanf.livejournal.com/122220.html?thread=786796

I think only the second change is required, but my system has been
running fine for a year with this whole patch.

...Richard.


--- dns.c.bak 2006-11-10 22:08:51.000000000 +1100
+++ dns.c 2014-09-01 12:28:22.000000000 +1000
@@ -211,7 +211,7 @@
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;
--- qmail-remote.c.bak 2006-11-10 22:08:51.000000000 +1100
+++ qmail-remote.c 2014-09-01 12:31:27.000000000 +1000
@@ -719,7 +719,7 @@
while (*recips) {
if (!saa_readyplus(&reciplist,1)) temp_nomem();
reciplist.sa[reciplist.len] = sauninit;
- addrmangle(reciplist.sa + reciplist.len,*recips,&flagalias,!relayhost);
+ addrmangle(reciplist.sa + reciplist.len,*recips,&flagalias,0);
if (!flagalias) flagallaliases = 0;
++reciplist.len;
++recips;

Nick Leverton

unread,
Jul 21, 2015, 6:07:00 PM7/21/15
to
In article <55AE9636...@delegated.net>,
Jonathan Knopp <jkn...@delegated.net> wrote:
>I ran into this error message a couple weeks ago too, and for me it was a result of name.com (big registrar) denying DNS ANY requests, which qmail uses to look for CNAMES on the From
>and Reply-To headers' domains. Unfortunately qmail handles a failed response on this request badly, given it isn't actually needed in the first place. You could try patching qmail to
>use CNAME instead of ANY for that request (though I don't know if the bind bug that prompted that change in the first place is still out in the wild), or use the patch that disables
>the canonical lookup altogether.
>
>http://fanf.livejournal.com/122220.html discusses the issue and provides both possible fixes.

DJB actually recommends removal of the T_ANY CNAME check entirely.
It was only there for backwards compatibility with ancient mail systems.

Patch and history at
http://permalink.gmane.org/gmane.mail.qmail.general/57395

Nick
--
"The Internet, a sort of ersatz counterfeit of real life"
-- Janet Street-Porter, BBC2, 19th March 1996

Andy Bradford

unread,
Jul 21, 2015, 11:00:35 PM7/21/15
to
Thus said Jonathan Knopp on Tue, 21 Jul 2015 11:57:58 -0700:

> I ran into this error message a couple weeks ago too, and for me it
> was a result of name.com (big registrar) denying DNS ANY requests,
> which qmail uses to look for CNAMES on the From and Reply-To headers'
> domains.

qmail doesn't care about From and Reply-to headers.

That being said, the only patch that is really required for this
particular problem (if encountered) is:

http://marc.info/?l=qmail&m=134062672511072&w=2

Andy
--
TAI64 timestamp: 4000000055af05d6

Jonathan Knopp

unread,
Jul 21, 2015, 11:52:10 PM7/21/15
to
On 15-07-21 07:53 PM, Andy Bradford wrote:
> qmail doesn't care about From and Reply-to headers.

Sorry, quite right, I was getting mixed up with another deliverability issue I was dealing with at the same time. It is just the recipient at play.
0 new messages