Hello,
Another site can't send mail to my site because the connection times
out. I believe the connection may be timing out because of his DNS. I'd
like to air my reasoning out here so that a) people who understand tcpserver
better can verify what I believe the man page is telling me, and b) people
who understand DNS better can verify what I'm seeing in DNS.
The really short version is:
1) I don't think logical.logical-approach.com (207.168.117.16) has reverse
DNS mappings. Am I wrong?
2) If it doesn't, could that trigger a 10 minute delay before tcpserver goes
ahead with the connection?
The long version is:
My machine is hunin.scansoft.com (4.17.150.117), running qmail-1.0.3 and
ucspi-tcp-0.84. The remote site has various machines which are
demonstrating this problem, notably carrera.nine-eleven.com but, in this
test, logical.logical-approach.com (207.168.117.16).
The symptom is that SMTP connections from there hang for 10 minutes
before the "220 hunin.scansoft.com ESMTP" message is sent. Their sendmail
config has a 5-minute connection timeout (I don't know if that's greet or in
general), so they give up before they get through.
I'm logging tcpserver with -v to get more info. Here is the command
line, pulled out of 'ps', for a connection attempt in progress (wrapped by
me):
qmaild 6428 0.0 0.3 844 424 ? S 16:07 0:00 \
tcpserver -v -c100 -x/etc/tcp.smtp.cdb -u 501 -g 500 \
0 smtp /var/qmail/bin/qmail-smtpd
Here are the 3 lines concerning this connection that tcpserver logs
(also wrapped by me):
May 6 16:07:34 hunin tcpserver: 926021254.455163 tcpserver: \
pid 6428 from 207.168.117.16
May 6 16:17:01 hunin tcpserver: 926021821.613477 tcpserver: \
ok 6428 hunin.scansoft.com:4.17.150.117:25 :207.168.117.16::52739
May 6 16:17:01 hunin tcpserver: 926021821.613671 tcpserver: \
end 6428 status 256
Note that it took 9-1/2 minutes for tcpserver to continue, and when it
did so, it had not figured out the name for this host.
Now, my understanding of the default tcpserver behavior is:
-P (not paranoid, so no hangups there)
-h (look up remote host name and set TCPREMOTEHOST)
-r (Attempt to obtain TCPREMOTEINFO from the remote host) (ident?!?)
-t... (give up on TCPREMOTEINFO after 26 seconds by default)
So, it'll try 'ident' for 26 seconds, then give up. But it will also
try to do a reverse DNS lookup on the remote host. It isn't being paranoid,
so it won't refuse it on the basis of that info, but the reverse DNS lookup
doesn't have a specific timeout.
So, next I ran nslookup to figure out if this place has reverse info.
My understanding (NOTE, here's where I'm shaky!) is that the following
commands (ptr, then any) should show me if there are any reverse records
(log prefixed with "% "):
% [gowen@hunin log]$ nslookup
% Default Server: vnsc-pri.sys.gtei.net
% Address: 4.2.2.1
%
% > set type=ptr
% > 16.117.168.207.in-addr.arpa
% Server: vnsc-pri.sys.gtei.net
% Address: 4.2.2.1
%
% *** vnsc-pri.sys.gtei.net can't find 16.117.168.207.in-addr.arpa:
% Non-existent host/domain
% > set type=any
% > 16.117.168.207.in-addr.arpa
% Server: vnsc-pri.sys.gtei.net
% Address: 4.2.2.1
%
% *** vnsc-pri.sys.gtei.net can't find 16.117.168.207.in-addr.arpa:
% Non-existent host/domain
And, just to check myself, let's do it for my host (hunin.scansoft.com):
% > 117.150.17.4.in-addr.arpa
% Server: vnsc-pri.sys.gtei.net
% Address: 4.2.2.1
%
% Non-authoritative answer:
% 117.150.17.4.in-addr.arpa name = hunin.scansoft.com
%
% Authoritative answers can be found from:
% 150.17.4.in-addr.arpa nameserver = knock.ser.bbnplanet.net
% 150.17.4.in-addr.arpa nameserver = nic3.barrnet.net
% 150.17.4.in-addr.arpa nameserver = nic.near.net
% knock.ser.bbnplanet.net internet address = 192.239.16.129
% nic3.barrnet.net internet address = 131.119.245.6
% nic.near.net internet address = 192.52.71.4
So, my theory:
1) They don't have reverse DNS on logical.logical-approach.com (they say
they do)
2) tcpserver takes 10 minutes before giving up on the reverse DNS lookup
3) so when it continues with the transaction, they've already hung up.
If this is all true:
1) Is there anything requiring reverse DNS for mail hosts (i.e., are they
broken?)
If I'm blowing smoke out my *ss:
1) Any other suggestions as to what I should look at?
Any help you can give is greatly appreciated.
--
gowen -- Greg Owen -- [EMAIL PROTECTED]
