my smtp server is very slow to accept connections today

[Don Russell]

On 4/6/2006 5:28 PM, Les Mikesell wrote:
> On Thu, 2006-04-06 at 18:43, Don Russell wrote:
> 
>> I've been using this address range for years, and never noticed any 
>> problems. Just recently I notice it takes a long time to get a response 
>> when connecting from 10.10.10.253 to 10.10.10.250 using ssh.
>>
>> Telnet 10.10.10.250 25 (smtp) from 10.10.10.253 takes a very long time 
>> (a minute or more sometimes) to get a response... My Thunderbird mail 
>> clients time out trying to send mail to 10.10.10.250 when last week they 
>> had no problems at all.
>>
>> I also tried telnet from "outside" and it takes a while for a response 
>> too... it used to be much quicker...
>>
>> If you're curious... try telnet drussell dnsalias com 25 (with dots in 
>> all the right places) and see how long it takes for you to get a response...
>>
>> Maybe you're right... maybe my ISP was providing the necessary lookups 
>> and now that's broken on their end...
> 
> I got a connection immediately - the response close to a minute
> later.  Do you perhaps have 2 nameservers listed in your
> resolv.conf with the 1 one not responding?

Yes... that's the symptom.. connects, then waits ...

login as: don
don at 10.10.10.250's password:
Last login: Thu Apr  6 14:59:28 2006 from 10.10.10.253
[don at boris ~]$ cat < /etc/resolv.conf
; generated by /sbin/dhclient-script
search san.rr.com
nameserver 66.75.164.90
nameserver 66.75.164.89
[don at boris ~]$


I just tried two digs which replied right away..
dig @66.75.164.89 ibm.com ---> replied in 27 mSec
dig @66.75.164.90 ibm.com ---> replied in 26 mSec

That tells me the two dns servers defined there are responsive...

and looking back through my Cisco router firewall logs, I see tons of 
udp 66.75.164.90 port 1078 denials... before and after my digs... :-(



>>> The other thing that happens during a connection is that
>>> sendmail will try an IDENT query on the socket to identify
>>> the user if the other end is unix-like.  Normally you get
>>> a quick ICMP response if nothing is listening on port 113
>>> at the other end, but if you have a firewall configured to
>>> silently drop packets you'll have to wait for the timeout,
>>> probably 30 seconds. 
>>>
>>>
>> And does the ssh server do that sort of thing too?
> 
> I don't think it tries IDENT, but it will do the reverse
> dns to log the hostname from the inbound connection.
> 

hmmm, with the same symptom... quick to connect, slow to reply...