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 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?
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.
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.
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
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
| 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.
Also I have:
rbl_enable = 0 # master RBL switch. Disables all RBLs
rwl_enable = 0 # master RWL switch. Disables all RWLs
| 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
I have the same problem.
It's no rbl or rwl checking problem.
it isn't
this issue is it?