[ale] Sendmail latency

[Ryan Fish]

> --- 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)

Where is the info 'host' returns obtained???

>
> >
> >
> > 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.