tcp-env Still Doing Reverse DNS Lookups with -Rt0

[stupidnic]

I have been having a problem with a particular client all day. It seems their ISP's name servers have stopped handing out responses for the IP address. So I went ahead and added the -Rt0 to the inetd.conf (this is a Debian server) and restarted inetd.conf.

This didn't fix the problem so I thought I had some sort of problem with the mail server itself. I went round and round and I have finally determined that even though tcp-env is passed the -Rt0 switch (I have also tried just -R) it still does the reverse DNS lookup.

Here is a stack trace of inetd spawning off tcp-env and its subsequent calls to the resolv.conf and DNS calls out to the DNS server.

[pid  2334] execve("/var/qmail/bin/tcp-env", ["tcp-env", "-Rt0", "/var/qmail/bin/relaylock", "/var/qmail/bin/qmail-smtpd", "/var/qmail/bin/smtp_auth", "/var/qmail/bin/true", "/var/qmail/bin/cmd5checkpw", "/var/qmail/bin/true"], [/* 16 vars */]) = 0

As you can see -Rt0 is being passed as an option to tcp-env.

Later in the same process we can see tcp-env parsing the resolv.conf:

[pid  2334] open("/etc/resolv.conf", O_RDONLY) = 3
[pid  2334] fstat64(3, {st_mode=S_IFREG|0644, st_size=69, ...}) = 0
[pid  2334] mmap2(NULL, 131072, PROT_READ|PROT_WRITE, MAP_PRIVATE|MAP_ANONYMOUS, -1, 0) = 0xb7d2a000
[pid  2334] read(3, "search domain.net\nnameserve"..., 131072) = 69
[pid  2334] read(3, "", 131072)         = 0
[pid  2334] close(3)                    = 0

and then making the call out to the remote DNS server:

[pid  2334] socket(PF_INET, SOCK_DGRAM, IPPROTO_IP) = 3
[pid  2334] connect(3, {sa_family=AF_INET, sin_port=htons(53), sin_addr=inet_addr("1.2.3.4")}, 28) = 0
[pid  2334] send(3, "\202\253\1\0\0\1\0\0\0\0\0\0\00237\00281\003210\003207"..., 44, 0) = 44
[pid  2334] gettimeofday({1188954458, 39940}, NULL) = 0
[pid  2334] poll([{fd=3, events=POLLIN, revents=POLLIN}], 1, 5000) = 1
[pid  2334] recvfrom(3, "\202\253\201\200\0\1\0\1\0\0\0\0\00237\00281\003210\003"..., 513, 0, {sa_family=AF_INET, sin_port=htons(53), sin_addr=inet_addr("1.2.3.4")}, [16]) = 82
[pid  2334] close(3)

This has been driving me crazy. I have even gone so far as to start picking through the tcp-env.c file in the qmail+plesk source code, but it looks correct (even if my C skills are a tad rusty).

I see the same thing on a CentOS 5 based Plesk install of 8.2... I am at a loss why it is doing this when it is specifically told not to.

 

[stupidnic]

I always hate replying to my own threads... but here I am doing it anyways...

Basically I misunderstood the purpose of the -R command line switches. Their purpose is not to skip reverse DNS lookups, but are instead supposed to skip Ident lookups (which is should do anyways).

So basically, if you are having trouble sending email to a qmail based server, then most likely there is something wrong with the servers responsible for handing out reverse DNS for the connecting IP address.

Our particular problem is causing a sort of deadlock in the qmail-smtpd process. The qmail-smtpd process eventually spawns the ESMTP response to the remote client, but far too late for the client and they just sit there waiting for each other.

 

[ramirors]

problem sending mail

I have problems with sending in outlook, i check ports, check isp, all....and still havin problems...in log a saw a lot of "xinetd[xxxx] warning: can't get client address: Connection " starting the same day of the fail...

i did telnet and OK...

Any clue?? (CentOS, plesk 8.2.1)...

Thanks

 

[hardbrasil]

i have the same problem. Some Portals block all emails from my qmail server.
At now whem i send an email this Portals (to test) they not come back anymore.

i dont konow what to do!

 

[Gustave Stresen-Reuter]

Hi,

I seem to be having the same problem, but when testing with command line networking tools, reverse DNS seems to be functioning properly (unless I'm misunderstanding what reverse DNS is or how to do it, which is very possible).

For example:

~# host 82.98.131.91
Name: hl75.dinaserver.com
Address: 82.98.131.91

----
~# nslookup 82.98.131.91
Server: 204.11.247.196
Address: 204.11.247.196#53

Non-authoritative answer:
91.131.98.82.in-addr.arpa name = hl75.dinaserver.com.

Authoritative answers can be found from:
131.98.82.in-addr.arpa nameserver = ns7.dinahosting.com.
131.98.82.in-addr.arpa nameserver = ns8.dinahosting.com.
ns7.dinahosting.com internet address = 82.98.128.130
ns8.dinahosting.com internet address = 82.98.128.194

----
~# dig -x 82.98.131.91

; <<>> DiG 9.4.3-P3 <<>> -x 82.98.131.91
;; global options: printcmd
;; Got answer:
;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 30150
;; flags: qr rd ra; QUERY: 1, ANSWER: 1, AUTHORITY: 0, ADDITIONAL: 0

;; QUESTION SECTION:
;91.131.98.82.in-addr.arpa. IN PTR

;; ANSWER SECTION:
91.131.98.82.in-addr.arpa. 139 IN PTR hl75.dinaserver.com.

;; Query time: 72 msec
;; SERVER: 80.58.0.33#53(80.58.0.33)
;; WHEN: Fri Jan 22 12:55:17 2010
;; MSG SIZE rcvd: 76

And yet I am unable to receive email from a domain hosted on this server. The connection times out after exactly 30 seconds and I'm not seeing much in my server logs, except the line:

Jan 22 05:55:43 myservername relaylock: /var/qmail/bin/relaylock: mail from 82.98.131.91:46454 (hl75.dinaserver.com)


Any ideas?

Ted Stresen-Reuter