Prev: Godaddy Mail Server/Telnet Session Not Working - Message Refused
Next: ldap_routing tempfail
From: Steve Hajducko on 23 Mar 2010 03:04
While I hate to bring up an old thread - the fact of the matter was
the analysis was not 'faulty'.

In an area that has DNS but does not have access to external lookups,
you run into interesting issues - the whole point being that in our
setup we want all mail to go to a smart relay, we have DNS, but only
for internal domains.

There was no 'magic' fix that 'suddenly' happened. The rewrite of the
sendmail.cf to include the [ ] around the smart relay *was* the real
fix and I want it displayed on here so that others with the same
problem may benefit from the troubleshooting I was required to do.

sendmail will do an MX lookup for the smart relay, even if you'd tried
to tell it to only send to the smart relay. It's in the documentation
that it does this and DNS debug logs show the queries.

It's rather simple to setup and I've repeated the error and had to
help others at work solve the issue. Because we moved from a system
of having no DNS, we also had other necessary items ( nocanonify and
others ) setup that are required in this sort of setup.

On Feb 10, 3:01 pm, bon...(a)host122.r-bonomi.com (Robert Bonomi) wrote:
> In article <5364aa8b-8863-41ca-8664-65a6c0f80...(a)a5g2000prg.googlegroups.com>,
> Steve Hajducko  <hajdu...(a)gmail.com> wrote:
>
>
>
>
>
> >I ran into an issue on an AIX system recently and while I have it
> >resolved, it's brought up some questions that I can't find answers to.
>
> >Our AIX system is in an internal network that forwards all mail to a
> >smart host that is allowed to relay out through the firewall.  We do
> >have DNS for the tier but the DNS is only specifically for that
> >network tier - it has no knowledge of outside addresses nor can it
> >retrieve them.
>
> >I tried simply setting the SMART_HOST to this system, but this
> >resulted in:
>
> >stat=Deferred: Name server: relay.example.com: host name lookup
> >failure
>
> >In the end, I found the reason was because I didn't have an MX record
> >specifically for my SMART_HOST - I had one for the domain the
> >SMART_HOST was in, but not for the smart host itself.
>
> >I had this:
>
> >example.com  IN MX 5 relay.example.com
>
> >So by adding another record:
>
> >relay.example.com  IN MX 5  relay.example.com
>
> >I fixed the problem.
>
> >The other solutions I found to this were:
>
> >1) Putting [ ] around the smart host ( ie - DS[relay.example.com] ) to
> >prevent MX lookups
> >2) Setting a FallbackMXHost
> >3) Using a mailertable entry
>
> >My question, at the end of this long charade - why does sendmail try
> >and do an MX lookup for the smart host?  Why doesn't it instead try to
> >do the MX lookup on the domain the smart host is in? ( ie - where it's
> >usually defined )
>
> >Is it going with the assumption that my smart host isn't directly
> >accessible and therefore wants to find an MX record to how to deliver
> >the mail to my smart host?  If so, then it's surprising that
> >FallbackMXHost doesn't follow the same guidelines.  sendmail will
> >*try* and find an MX for FallbackMXHost but if it doesn't, just
> >attempts to send the mail directly to the host - something I would
> >assume the normal smart host would do as well.
>
> Your entire analysis appears to be faulty.
>
> 'host name lookup failure' indicates that sendmail could not get DNS
> data when trying to resolve 'relay.example.com'.
>
> In the course of mucking around with the MX record, you apparently fixed
> the 'real' problem.
>
> I.e., in the _in-memory_ database that the DNS server answers queries from,
> there was no 'A' record, or no CNAME, or the CNAME pointed (possibly
> through other CNAMEs to a name that did not exist.
>
> One can 'think' the record is there -- you see it in the 'zone' file -- but
> it is not actually being handed out by the DNS Server.  This state of affairs
> can happen for any of several reasons -- the one of the most common reasons
> being that one forgot to update the 'serial number' in the zone file; next is
> a failure to tell the DNS server to 'reload the zone files'.  A third reason
> that can lead to this behavior is "improper caching" of 'negative answers'
> from the DNS server, either by a slave server, a DNS forwarding server, or
> a local resolver.
>
> This particular kind of a 'problem' is a bear to troubleshoot, because it tends
> to 'spontaneously' cure itself -- giving the impression that 'something else'
> (that was actually unrelated to the problem) getting changed _was_ the 'fix'.
> When the 'actual cure' was the result of the DNS server expiring its in-memory
> date, and actually reading the modified file.

 | 
Pages: 1
Prev: Godaddy Mail Server/Telnet Session Not Working - Message Refused
Next: ldap_routing tempfail