my smtp server is very slow to accept connections today

[Damon Lambooy]

Check iptables, if turned on then stop it  and test if problem fixed 
then I would guess at "Ident port 113"  add it to iptables. then start  
iptables , check again.
There normally  is latency when port 113 is being blocked.

Paul Howarth wrote:
> Don Russell wrote:
>> On 4/4/2006 4:29 AM, Paul Howarth wrote:
>>> Don Russell wrote:
>>>> I'm using FC5 and have the "nightly yum update" turned on.
>>>> My FC5 box runs a mail server.
>>>> Yesterday, there were no problems.
>>>> Today, I can't send mail from PCs on the network... the Thunderbird 
>> client
>>>> says "Connected to 10...." and eventuaally times out.
>>>>> From external machines I can telnet to port 25 and it takes anywhere 
>> from
>>>> 40-80 seconds to get a reply from the server.
>>>> If I'm on the same machine as the server, the connection is immediate.
>> That tells me it is not smtp that's slow, but something relating to
>> external connections.
>>>> I have not changed any configurations... but with the nightly updates,
>> what could account for introducing such a delay?
>>>> I'm thinking somethin like it's trying to a reverse dns look up to
>> check
>>>> the address connecting, and that's taking a long time?
>>>> Any ideas/suggestions?
>>> Check that your nsswitch.conf has an appropriate hosts entry.
>>
>> hmmm, I don't know what's "appropriate". :-(
>> The nsswitch.conf file looks pretty generic... the "hosts" line says:
>> hosts: files dns
>
> That looks OK.
>
>> Guessing, I changed that to
>> hosts: files dns [NOTFOUND=return]
>>
>> then "service network restart"
>> but that had no effect...
>>
>> hmmm, do I need to have my PCs listed in /etc/hosts ?
>
> No. Sendmail needs to look up MX records, which it can't get from a 
> hosts file anyway.
>
>> If so, that means something changed because this was all working fine 
>> the
>> other day... could a "nightly yum" have wiped out my /etc/hosts file?
>
> Which new packages were installed on the night in question? (check 
> /var/log/yum.log)
>
>>> Check that /etc/resolv.conf points to nameservers that are working.
>>>
>>> Try using "dig" to check them out, e.g.
>>>
>>> $ dig @first.name.server -x 212.56.100.58
>>>
>>> See how long the lookups take.
>>
>>
>> I tried several times with the two dns addresses in /etc/resolv.conf and
>>   the longest query time was 180mSec, the shortest was 25mSec.
>>
>> However, I also tried dig @dns-server - x 10.10.10.13
>> (the 10. address is my PC that tries to connect to my mail server at
>> 10.10.10.250)
>>
>> That timed out after 15 seconds.... expected, but far short of the 
>> delay I
>> see when I "telnet 10.10.10.250 25" from 10.10.10.13
>
> Doesn't really sound like a DNS issue then.
>
> Paul.
>