Domain of sender address does not resolve ?
in [Sendmail]
|
Prev: starttls errors
Next: 554 5.7.1 Command rejected
From: proftpd on 20 Sep 2007 19:03 Hello, I am using sendmail as a gateway for spam/virus filtering for several domains. This has been working great until about a week ago when I noticed the outgoing queue (mail to the domains witch I filter for) started to grow. I am seeing allot of errors regarding "Domain of sender address user(a)cox.net does not resolve" Where the domain in question really is cox.net the username will vary. This is the only domain that for some reason sendmail can't seem to resolve. Here is a sample: Sep 20 15:40:00 nospam1 sendmail[15290]: l8H0itPK031395: to=<user(a)alexabercrombie.com>, delay=3+21:54:59, xdelay=00:00:00, mailer=smtp, pri=35137092, relay=[64.18.194.87], dsn=4.0.0, stat=Deferred: 451 4.1.8 Domain of sender address user(a)cox.net does not resolve I am running named on the same machine as a local caching name server for faster response times. Here is the output from "dig cox.net" ; <<>> DiG 9.2.4 <<>> cox.net ;; global options: printcmd ;; Got answer: ;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 13980 ;; flags: qr rd ra; QUERY: 1, ANSWER: 1, AUTHORITY: 3, ADDITIONAL: 0 ;; QUESTION SECTION: ;cox.net. IN A ;; ANSWER SECTION: cox.net. 84290 IN A 68.1.17.9 ;; AUTHORITY SECTION: cox.net. 84290 IN NS ns.west.cox.net. cox.net. 84290 IN NS ns.cox.net. cox.net. 84290 IN NS ns.east.cox.net. ;; Query time: 13 msec ;; SERVER: 127.0.0.1#53(127.0.0.1) ;; WHEN: Thu Sep 20 15:44:31 2007 ;; MSG SIZE rcvd: 102 Here is the reverse from "dig -x 68.1.17.9" ; <<>> DiG 9.2.4 <<>> -x 68.1.17.9 ;; global options: printcmd ;; Got answer: ;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 3599 ;; flags: qr rd ra; QUERY: 1, ANSWER: 1, AUTHORITY: 3, ADDITIONAL: 0 ;; QUESTION SECTION: ;9.17.1.68.in-addr.arpa. IN PTR ;; ANSWER SECTION: 9.17.1.68.in-addr.arpa. 86378 IN PTR www.cox.net. ;; AUTHORITY SECTION: 17.1.68.in-addr.arpa. 86378 IN NS ns.east.cox.net. 17.1.68.in-addr.arpa. 86378 IN NS ns.west.cox.net. 17.1.68.in-addr.arpa. 86378 IN NS ns.cox.net. ;; Query time: 0 msec ;; SERVER: 127.0.0.1#53(127.0.0.1) ;; WHEN: Thu Sep 20 15:45:58 2007 ;; MSG SIZE rcvd: 126 As far as I can see sendmail _should_ be able to resolve the domain. Here are the steps I have taken in order to allow these messages to pass onto the customers. I have added the following to my /etc/mail/access file, then rebuilt the db. From:cox.net OK cox.net OK Result =NG I have added cox.net to my /etc/hosts file then restarted sendmail. Result =NG I have added the following to my /etc/mail/sendmail.mc file and rebuilt the .cf file and restarted sendmail. define(`confBIND_OPTS',`WorkAroundBrokenAAAA') FEATURE(accept_unresolvable_domains) LOCAL_CONFIG O Timeout.hoststatus=10m O HostStatusDirectory=.hoststat C{ResOk}TEMP Result =NG I am at a loss. So far nothing I have tried has worked. Also I think it is important to note that some mail from "cox.net" will pass along just fine to the customer. So its not all mail, but at least some of it that is getting stuck. I am running CentOS 4.5 2.6.9-55.0.2.ELsmp Sendmail 8.13.1 BIND 9.2.4 Any ides, thoughts, suggestions ? Thanks, James
From: Bill Cole on 21 Sep 2007 08:07 In article <1190329385.146805.233620(a)e34g2000pro.googlegroups.com>, proftpd(a)gmail.com wrote: > Hello, > > I am using sendmail as a gateway for spam/virus filtering for several > domains. This has been working great until about a week ago when I > noticed the outgoing queue (mail to the domains witch I filter for) > started to grow. I am seeing allot of errors regarding "Domain of > sender address user(a)cox.net does not resolve" > > Where the domain in question really is cox.net the username will vary. > This is the only domain that for some reason sendmail can't seem to > resolve. > > Here is a sample: > Sep 20 15:40:00 nospam1 sendmail[15290]: l8H0itPK031395: > to=<user(a)alexabercrombie.com>, delay=3+21:54:59, xdelay=00:00:00, > mailer=smtp, pri=35137092, relay=[64.18.194.87], dsn=4.0.0, > stat=Deferred: 451 4.1.8 Domain of sender address user(a)cox.net does > not resolve Note that this is the MTA at 64.18.194.87 having a domain resolution problem, and it is telling the sendmail instance generating that log line that it cannot resolve cox.net in some probably transient way, i.e. a DNS query timeout, not an explicit NXDOMAIN response. It isn't exactly clear whether resolution on 64.18.194.87 is what you're trying to diagnose here... > I am running named on the same machine as a local caching name server > for faster response times. Here is the output from "dig cox.net" > > ; <<>> DiG 9.2.4 <<>> cox.net > ;; global options: printcmd > ;; Got answer: > ;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 13980 > ;; flags: qr rd ra; QUERY: 1, ANSWER: 1, AUTHORITY: 3, ADDITIONAL: 0 > > ;; QUESTION SECTION: > ;cox.net. IN A > > ;; ANSWER SECTION: > cox.net. 84290 IN A 68.1.17.9 > > ;; AUTHORITY SECTION: > cox.net. 84290 IN NS ns.west.cox.net. > cox.net. 84290 IN NS ns.cox.net. > cox.net. 84290 IN NS ns.east.cox.net. > > ;; Query time: 13 msec > ;; SERVER: 127.0.0.1#53(127.0.0.1) > ;; WHEN: Thu Sep 20 15:44:31 2007 > ;; MSG SIZE rcvd: 102 That's less important than the MX record for cox.net, but that also has valid resolution with suitably long TTL's. DNS should not be breaking. [...] > As far as I can see sendmail _should_ be able to resolve the domain. Yes, but if you are not looking at how the receiving MTA on 64.18.194.87 is doing resolution, you aren't looking at the right place. This is not clear to me... > Here are the steps I have taken in order to allow these messages to > pass onto the customers. > > I have added the following to my /etc/mail/access file, then rebuilt > the db. > From:cox.net OK > cox.net OK > > Result =NG > > I have added cox.net to my /etc/hosts file then restarted sendmail. > > Result =NG > > I have added the following to my /etc/mail/sendmail.mc file and > rebuilt the .cf file and restarted sendmail. > > define(`confBIND_OPTS',`WorkAroundBrokenAAAA') > FEATURE(accept_unresolvable_domains) > LOCAL_CONFIG > O Timeout.hoststatus=10m > O HostStatusDirectory=.hoststat > C{ResOk}TEMP > > Result =NG If you are doing this to the sendmail that generated the cited log line, you are hitting the wrong sendmail over the head with a bat it does not deserve, and probably doing so to its detriment. accept_unresolvable_domains is evil. > I am at a loss. So far nothing I have tried has worked. Also I think > it is important to note that some mail from "cox.net" will pass along > just fine to the customer. So its not all mail, but at least some of > it that is getting stuck. I am running > > CentOS 4.5 2.6.9-55.0.2.ELsmp > Sendmail 8.13.1 You should upgrade that. I'm not convinced that the security issue it has is deadly, and the bug fixes are not universally expressed, but it is a bit old. 64.18.194.87 is running 8.12.10, or at least its banner says that. This implies some serious administrative laxness there.... > BIND 9.2.4 Upgrade that. Really. > Any ides, thoughts, suggestions ? Wild ideas: does 64.18.194.87 have TCP port 53 firewalled in any way? Does it have a well-performing resolver? It is conceivable that the DNS response is taking just about as long as the resolver timeout on that machine. -- Now where did I hide that website...
From: Michael Heiming on 21 Sep 2007 09:13 In comp.mail.sendmail Bill Cole <bill(a)scconsult.com>: > In article <1190329385.146805.233620(a)e34g2000pro.googlegroups.com>, > proftpd(a)gmail.com wrote: [..] >> I am at a loss. So far nothing I have tried has worked. Also I think >> it is important to note that some mail from "cox.net" will pass along >> just fine to the customer. So its not all mail, but at least some of >> it that is getting stuck. I am running >> >> CentOS 4.5 2.6.9-55.0.2.ELsmp >> Sendmail 8.13.1 > You should upgrade that. I'm not convinced that the security issue it > has is deadly, and the bug fixes are not universally expressed, but it > is a bit old. Doesn't look that bad, the kernel is a halfway recent RHEL 4 update kernel. I'd check using 'yum update' for more recent patches, though he should be fine with a recent RHEL sendmail rpm update. CentOS is iirc a RHEL clone. -- Michael Heiming (X-PGP-Sig > GPG-Key ID: EDD27B94) mail: echo zvpunry(a)urvzvat.qr | perl -pe 'y/a-z/n-za-m/' #bofh excuse 122: because Bill Gates is a Jehovah's witness and so nothing can work on St. Swithin's day.
From: Bill Cole on 21 Sep 2007 09:37 In article <2kscs4-fmc.ln1(a)news.heiming.de>, Michael Heiming <michael+USENET(a)www.heiming.de> wrote: > In comp.mail.sendmail Bill Cole <bill(a)scconsult.com>: > > In article <1190329385.146805.233620(a)e34g2000pro.googlegroups.com>, > > proftpd(a)gmail.com wrote: > [..] > > >> I am at a loss. So far nothing I have tried has worked. Also I think > >> it is important to note that some mail from "cox.net" will pass along > >> just fine to the customer. So its not all mail, but at least some of > >> it that is getting stuck. I am running > >> > >> CentOS 4.5 2.6.9-55.0.2.ELsmp > >> Sendmail 8.13.1 > > > You should upgrade that. I'm not convinced that the security issue it > > has is deadly, and the bug fixes are not universally expressed, but it > > is a bit old. > > Doesn't look that bad, the kernel is a halfway recent RHEL 4 > update kernel. I'd check using 'yum update' for more recent > patches, though he should be fine with a recent RHEL sendmail rpm > update. CentOS is iirc a RHEL clone. I was speaking of Sendmail. 8.13.1 has a number of bugs including a single-message denial of service attack, and it is not a good idea to leave that sort of problem in place after its presence has been announced in a public forum. -- Now where did I hide that website...
From: Carl Byington on 22 Sep 2007 01:05
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 On Fri, 21 Sep 2007 09:37:50 -0400, Bill Cole wrote: > In article <2kscs4-fmc.ln1(a)news.heiming.de>, > Michael Heiming <michael+USENET(a)www.heiming.de> wrote: >> Doesn't look that bad, the kernel is a halfway recent RHEL 4 update >> kernel. I'd check using 'yum update' for more recent patches, though he >> should be fine with a recent RHEL sendmail rpm update. CentOS is iirc a >> RHEL clone. > I was speaking of Sendmail. 8.13.1 has a number of bugs including a > single-message denial of service attack, and it is not a good idea to > leave that sort of problem in place after its presence has been announced > in a public forum. RH/Centos end up back-porting the recent security fixes into the older versions of sendmail (and everything else, bind, apache, etc), without changing the version number. That particular 8.13.1 won't have that vulnerability if it came from sendmail-8.13.1-3.RHEL4.5.i386.rpm or the more recent sendmail-8.13.1-3.2.el4.i386.rpm. -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.2.6 (GNU/Linux) iD8DBQFG9KJsL6j7milTFsERAqFiAJ0bf2updyNfR1CqP2YjNRqUg35yogCeI0WU S7vhLS3CVU7mVVR5EfFpMts= =x1FC -----END PGP SIGNATURE----- |