Fw: [ale] Sendmail latency

[Ryan Fish]

Not sure why this didn't go through the first time...

----- Original Message ----- 
From: "Ryan Fish" <FishR at bellsouth.net>
To: "Atlanta Linux Enthusiasts" <ale at ale.org>
Sent: Tuesday, January 25, 2005 12:33 AM
Subject: Re: [ale] Sendmail latency


> > --- Ryan Fish <FishR at bellsouth.net> wrote:
> > >
> > > - The actual IP for this app server is .221 so I have no idea why it
is
> > > coming back as .0
> >
> > This could be a red-flag.  I would check the dns servers listed in
> > /etc/resolv.conf to see if they return an incorrect IP address for that
> host.
> > Just as a check, verify that from each server you should get accurate
> > information for these four commands:
> >
> >    # host <server1>
> >    # host 192.168.3.221
> >    # host <server2>
> >    # host <IP_Addr_2nd_Machine>
>
 - The mail server is the only one experiencing the following issue with the
 'host' cmd:

 [root at mailserver mail]# host app01
 app01.clientdomain.com has address 192.168.3.0
 [root at mailserver mail]# host app02
 app02.clientdomain.com has address 192.168.3.0
 [root at mailserver mail]# host app101
 app101.clientdomain.com has address 192.168.3.220 (correct)
 [root at mailserver mail]# host app102
 app102.clientdomain.com has address 192.168.3.0
 [root at mailserver mail]# host mailserver
 mailserver.clientdomain has address XX.XXX.XXX.199 (the correct IP address)


>
> >
> > >
> > >
> > > Everything worked fine prior to rebooting the app servers around 5A on
> > > 14JAN.  Afterwards all of this started...
> > >
> > >
> > > I see very few errors in the maillog.  Here is a sample of some:
> > >
> > > Jan 24 23:24:33 mailserver sendmail[5617]: j0LHsHCx010652:
> > > to=<user at outsidedomain.com>, delay=3+10:30:11, xdelay=00:00:00,
> > > mailer=esmtp, pri=7327408, relay=mail.outsidedomain.com.
[38.113.1.50],
> > > dsn=4.3.0, stat=Deferred: 451-host lookup did not complete
> >
> > A log of these are indicative of a DNS problem.  A few here and there
are
> > pretty normal.
> >
> > >
> > > Jan 24 23:27:56 mcmail02 sendmail[5617]: j0LFWuTF026717:
> > > to=<user at otherdomain.com>, delay=3+12:54:55, xdelay=00:00:15,
> mailer=esmtp,
> > > pri=7502182, relay=otherdomain.com. [38.161.171.51], dsn=4.0.0,
> > > stat=Deferred: Connection refused by otherdomain.com
> > >
> >
> > A few of these during "rush hour" is all too common.  Repeated refusals
> need to
> > be investigated.  Just curious, are those valid domains or have you
> changed
> > them to otherdomain.com and outsidedomain.com?

 - I changed the domain names to protect the innocent...  The domains in
 question are valid though.

>
> >
> > >
> > > - I don't know how to obtain the 'stat' output of connections in
> > > /var/log/maillog...
> >
> > I was just referring to the "stat=Deferred" statements you showed above.
> >
> > On my systems, I see slow email delivery under 2 different situations.
> The
> > first being high load average, thus causing sendmail to throttle itself.
> > Secondly, when DNS has latency/resolution issues.  The trick to the
second
> is
> > to run a caching DNS server on the mailserver and have /etc/resolv.conf
> use
> > 127.0.0.1.  It is possible that your issues are related to DNS
resolution.
>

- How would I setup a caching name server on the mail server?  named is
 running on that box and named.conf contains info for each domain hosted by
 the client however there I can find no other DNS info (as far domains not
 hosted by the client) on this box but I have no idea where to look for
that.

> >
> > Btw, "Connection refused by otherserver.com" type messages can be a
result
> of
> > their mailserver not liking yours.  Make sure that your mailserver has a
> valid
> > PTR (reverse DNS) entry.  Also use a site like openrbl.org to verify the
> > 'cleanliness' of the IP address of your mailserver.
>
>
 - A valid PTR record is in place.  I verified this with 'dig -x' from a box
 outside of their network.

 - I haven't found any RBL issues with the mail server's IP either.