SMTP slow to respond.... any ideas?

Started by atari, May 03, 2005, 10:43:17 AM

Previous topic - Next topic

atari


Sending mail va SMTP w/TLS was working fine until last night, now all of a sudden it takes about 3 minutes before it gets to the stage where it asks for the SMTP user password.

I've tried without TLS and it still has the same ~3min delay before sending. I've also tried stopping & restarting the services as well as rebooting the machine.

I've watched all the mail logs suggested on:
http://www.tnpi.biz/internet/mail/toaster/upgrade/watch-logs.shtml" target="_blank"> http://www.tnpi.biz/internet/mail/toaster/upgrade/watch-logs .shtml
and nothing happens (other than mail checks) until that ~3 mins has passed & the client finally connects to the SMTP.

I am not using any of the filtering.

To make this even more confusing for me, the server (on the same ip) responds instantly when checking mail.

I'm using thunderbird as a client & my ISP is Comcast.


Any ideas or suggestions as far as how to troubleshoot this?

atari


Hmm maybe it has something to do with the tarpit delay?

dm1# more tarpitcount
50
dm1# more tarpitdelay
5

It's not a 5 minute delay here though.... maybe 1-3.



Also I noticed a lot of strange IPs hitting my port 25:



# sockstat | grep ':25'
vpopmail tcpserve 18692    0 tcp4   11.22.33.44:25       81.193.3.154:2039    
vpopmail tcpserve 18691    0 tcp4   11.22.33.44:25       71.110.152.67:3220  
vpopmail tcpserve 18690    0 tcp4   11.22.33.44:25       213.231.80.148:1746  
vpopmail tcpserve 18689    0 tcp4   11.22.33.44:25       220.80.248.245:1439  
vpopmail tcpserve 18688    0 tcp4   11.22.33.44:25       200.180.178.194:1251
vpopmail tcpserve 18561    0 tcp4   11.22.33.44:25       220.73.109.17:4700  
vpopmail tcpserve 18560    0 tcp4   11.22.33.44:25       218.21.77.203:1108  
vpopmail tcpserve 18558    0 tcp4   11.22.33.44:25       218.51.128.112:1656  
vpopmail tcpserve  7983    3 tcp4   *:25                  *:*                  

# sockstat | grep ':25'
vpopmail tcpserve 18692    0 tcp4   11.22.33.44:25       81.193.3.154:2039    
vpopmail tcpserve 18691    0 tcp4   11.22.33.44:25       71.110.152.67:3220  
vpopmail tcpserve 18690    0 tcp4   11.22.33.44:25       213.231.80.148:1746  
vpopmail tcpserve 18689    0 tcp4   11.22.33.44:25       220.80.248.245:1439  
vpopmail tcpserve  7983    3 tcp4   *:25                  *:*

None of those are me, and this is a pretty private low-usage mailserver. I'm still watching the logs & nothing is popping up while those ips are connected/trying to connect.





atari


My main concern is that this was working properly before last night , nothing was changed in the configuration, and now it's not working....

I'm just concerned it could be a security/DoS issue with one of the components of the Mail Toaster.


atari

Maybe it has something to do with this:


from /var/qmail/supervise/smtp/run:

exec /usr/local/bin/softlimit -m 15360000 /usr/local/bin/tcpserver -S -H -R -c20 -x /usr/local/vpopmail/etc/tcp.smtp.cdb -u 89 -g 89 0 smtp rblsmtpd -c -a qmail.bondedsender.org qmail-smtpd /usr/local/vpopmail/bin/vchkpw /usr/bin/true 2>&1




dm1# ping qmail.bondedsender.org
PING qmail.bondedsender.org (130.94.6.10): 56 data bytes
(nothing)
^C
--- qmail.bondedsender.org ping statistics ---
20 packets transmitted, 0 packets received, 100% packet loss
dm1# traceroute qmail.bondedsender.org
traceroute to qmail.bondedsender.org (130.94.6.10), 64 hops max, 44 byte packets
(nothing)
^C


matt

3?  The default DNS timeout for rblsmtpd is 60 seconds, so you'd need three of your RBLs to be failing to have a 3 minute timeout. Perhaps you're having DNS lookup problems?

Oh, and just because you can't ping a RBL zone name doesn't mean it's not working. They work using UDP, not ICMP.

Matt

atari

matt wrote on Tue, 03 May 2005 21:29

3?  The default DNS timeout for rblsmtpd is 60 seconds, so you'd need three of your RBLs to be failing to have a 3 minute timeout. Perhaps you're having DNS lookup problems?

Oh, and just because you can't ping a RBL zone name doesn't mean it's not working. They work using UDP, not ICMP.

Matt


Ok... to ensure accuracy, I timed it a few times...

it responds exactly 1 minute 45 seconds later every time.

Nothing with the configuration has changed. It was working early yesterday evening. This is on a network that is pretty much private at the moment.

Also I am connecting to the IP of the SMTPd vs the fqdn right now... (although maybe there are other places for dns to fail).

fwiw, nslookup hangs on the mail/dns machine (tinydns & dnscache are installed), but dnsip resolves domains just fine.

by 'hangs' I mean... sits there and does nothing.

atari


Also I have:

rbl_enable                      = 0    # master RBL switch. Disables all RBLs

rwl_enable                      = 0   # master RWL switch. Disables all RWLs


LogicX

atari wrote on Tue, 03 May 2005 23:39


fwiw, nslookup hangs on the mail/dns machine (tinydns & dnscache are installed), but dnsip resolves domains just fine.

by 'hangs' I mean... sits there and does nothing.



I'd look into this --
nslookup uses TCP instead of UDP to do lookups AFAIK --
this means there may be a problem with axfrdns

I'd verify the following sorts of DNS records:

forward and reverse of the mail machine from: client, mail machine, third party DNS

forward and reverse of the client machine from: client, mail machine, third party DNS

forward and reverse DNS for any other upstream/downstream mail servers that may be involved, and/or any DNS based spam checking services
--- May this post be indexed by spiders, and archived for all to see as my internet epitaph.
http://fpux.com" target="_blank">http://fpux.com

tomek

I have the same problem.
It's no rbl or rwl checking problem.

LogicX

--- May this post be indexed by spiders, and archived for all to see as my internet epitaph.
http://fpux.com" target="_blank">http://fpux.com