• If you are still using CentOS 7.9, it's time to convert to Alma 8 with the free centos2alma tool by Plesk or Plesk Migrator. Please let us know your experiences or concerns in this thread:
    CentOS2Alma discussion

qmail/relaylock doesn't work corectly when connected via localhost

D

datenimperator

Guest
Hi,

since I've upgraded my Virtuozzo/Ubuntu6.04 to Plesk 9 yesterday, the qmail relaylock binary doesn't work correctly when a SMTP connection comes in from localhost. This is actually a severe issue, because such connection arise i.e. from fetchmail collecting mails and delivering locally, or from services like mailman, which also sends via localhost.

To fight spam, I use spamdyke as a drop-in filter for qmail, and spamdyke rejects connects with no valid RDNS information. Unfortunately, this is now true for all local connections.

Code: 
root@xxx:~# telnet localhost 25
Trying 127.0.0.1...
Connected to localhostname.localdomain.
Escape character is '^]'.
220 xxx.host.de ESMTP
quit
221 xxx.host.de
Connection closed by foreign host.

In /var/log/mail.info, I see these lines:

Code: 
Dec 11 10:19:44 xxx relaylock: /var/qmail/bin/relaylock: Unable to get ip address, white list will not work
Dec 11 10:19:44 xxx relaylock: /var/qmail/bin/relaylock: mail from localhost:37257 (not defined)

Just switching of the RDNS requirement isn't a solution because it's a proven method to reduce spam. Besides, relaylock shouldn't have a problem regarding connections from localhost.

Where can I find the source code of relaylock to see why it fails? What else can I do to resolve this? Regards,

Christian
 
Have you looked in /etc/hosts to see if the loopback address is in there? Also check to see what dns servers you are using to resolve things since you had localhost come up as undefined I would tend to think it is a resolver issue.
 
247trader,

thanks for your reply, however, the files look good:

Code: 
root@srv1:~# cat /etc/hosts
127.0.0.1	localhost localhost.localdomain
92.51.129.12	srv1.software-consultant.net	srv1

Code: 
root@srv1:~# cat /etc/resolv.conf
nameserver 127.0.0.1
nameserver 80.237.128.144
nameserver 80.237.128.145

Code: 
root@srv1:~# hostname 
srv1.software-consultant.net

All configuration remained unchanged from 8.6 to 9.0, at least AFAIK: I did not change anything, did the Plesk installer?
 
247trader said:
THis might be a stupid question but have you checked to make sure your DNS server is running and can resolve names?
Click to expand...

Not a stupid question at all, but yes, DNS is ok:

Code: 
root@srv1:~# dig -x 127.0.0.1 +short
localhost.
root@srv1:~# dig -x 92.51.129.12 +short
srv1.software-consultant.net.

Would be interesting to check whether it made a difference if I used the relaylock binary of 8.6. Could somebdy send me a copy?
 
datenimperator said:
Not a stupid question at all, but yes, DNS is ok:

Code: 
root@srv1:~# dig -x 127.0.0.1 +short
localhost.
root@srv1:~# dig -x 92.51.129.12 +short
srv1.software-consultant.net.

Would be interesting to check whether it made a difference if I used the relaylock binary of 8.6. Could somebdy send me a copy?
Click to expand...

One more thing to check. Relaylock gets its information from the environment via TCPREMOTEIP. Are you starting qmail under inetd or via daemontools? If you are starting under inetd then you need to make sure tcp-env is run as part of the startup script otherwise it will never be able to see that variable.
 
247trader said:
One more thing to check. Relaylock gets its information from the environment via TCPREMOTEIP. Are you starting qmail under inetd or via daemontools? If you are starting under inetd then you need to make sure tcp-env is run as part of the startup script otherwise it will never be able to see that variable.
Click to expand...

qmail is run via xinetd. I've put in a debug wrapper that prints env to the console to see what variables are available:

Code: 
SHELL=/bin/bash
TERM=xterm-color
TCPLOCALHOST=localhost
USER=root
REMOTE_HOST=127.0.0.1
PATH=/usr/local/sbin:/usr/local/bin:/usr/sbin:/usr/bin:/sbin:/bin:/usr/bin/X11:/usr/games
MAIL=/var/mail/root
_=/usr/bin/env
PWD=/
PROTO=TCP
SMTPAUTH=1
TCPREMOTEIP=localhost
LANG=POSIX
TCPLOCALPORT=25
TCPLOCALIP=127.0.0.1
HOME=/root
SHLVL=4
TCPREMOTEPORT=58854
LOGNAME=root
LC_CTYPE=
LESSOPEN=| /usr/bin/lesspipe %s
LESSCLOSE=/usr/bin/lesspipe %s %s

(I removed all variables belonging to my SSH session)

Interesting, there's "localhost" in TCPREMOTEIP where I'd expect 127.0.0.1 to be.
 
datenimperator said:
qmail is run via xinetd. I've put in a debug wrapper that prints env to the console to see what variables are available:

Code: 
SHELL=/bin/bash
TERM=xterm-color
TCPLOCALHOST=localhost
USER=root
REMOTE_HOST=127.0.0.1
PATH=/usr/local/sbin:/usr/local/bin:/usr/sbin:/usr/bin:/sbin:/bin:/usr/bin/X11:/usr/games
MAIL=/var/mail/root
_=/usr/bin/env
PWD=/
PROTO=TCP
SMTPAUTH=1
TCPREMOTEIP=localhost
LANG=POSIX
TCPLOCALPORT=25
TCPLOCALIP=127.0.0.1
HOME=/root
SHLVL=4
TCPREMOTEPORT=58854
LOGNAME=root
LC_CTYPE=
LESSOPEN=| /usr/bin/lesspipe %s
LESSCLOSE=/usr/bin/lesspipe %s %s

(I removed all variables belonging to my SSH session)

Interesting, there's "localhost" in TCPREMOTEIP where I'd expect 127.0.0.1 to be.
Click to expand...

What does your startup look like in /etc/xinet.d/smtp_psa?
 
247trader said:
What does your startup look like in /etc/xinet.d/smtp_psa?
Click to expand...

Code: 
root@srv1:~# cat /etc/xinetd.d/smtp_psa
service smtp
{
	socket_type     = stream
	protocol        = tcp
	wait            = no
	disable		= no
	user            = root
	instances       = UNLIMITED
	env             = SMTPAUTH=1
	server          = /var/qmail/bin/tcp-env
	server_args     = -Rt0  /var/qmail/bin/relaylock /usr/local/bin/spamdyke -f /etc/spamdyke4.conf /var/qmail/bin/qmail-smtpd /var/qmail/bin/smtp_auth /var/qmail/bin/true /var/qmail/bin/cmd5checkpw /var/qmail/bin/true
}
 
datenimperator said:
Code: 
root@srv1:~# cat /etc/xinetd.d/smtp_psa
service smtp
{
	socket_type     = stream
	protocol        = tcp
	wait            = no
	disable		= no
	user            = root
	instances       = UNLIMITED
	env             = SMTPAUTH=1
	server          = /var/qmail/bin/tcp-env
	server_args     = -Rt0  /var/qmail/bin/relaylock /usr/local/bin/spamdyke -f /etc/spamdyke4.conf /var/qmail/bin/qmail-smtpd /var/qmail/bin/smtp_auth /var/qmail/bin/true /var/qmail/bin/cmd5checkpw /var/qmail/bin/true
}
Click to expand...

Everything looks okay. Have you killed all services realted to qmail_smtpd and restarted them? This is an environmental issue.

Have you rebooted the system at all?
 
247trader said:
Everything looks okay. Have you killed all services realted to qmail_smtpd and restarted them? This is an environmental issue. Have you rebooted the system at all?
Click to expand...

Yes, I've restarted the server after the upgrade of plesk:

Code: 
root@srv1:~# uptime
 10:13:05 up 5 days, 11:54,  1 user,  load average: 0.05, 0.04, 0.00

I will restart the machine once again and see if it changes anything, bt I'm not too confident that it will.

Edit: As I suspected, behavior remained unchanged after the restart. When I execute "telnet localhost 25", the log reads:

Code: 
Dec 16 10:18:34 srv1 relaylock: /var/qmail/bin/relaylock: Unable to get ip address, white list will not work
Dec 16 10:18:34 srv1 relaylock: /var/qmail/bin/relaylock: mail from localhost:59219 (not defined)
 
datenimperator said:
Yes, I've restarted the server after the upgrade of plesk:

Code: 
root@srv1:~# uptime
 10:13:05 up 5 days, 11:54,  1 user,  load average: 0.05, 0.04, 0.00

I will restart the machine once again and see if it changes anything, bt I'm not too confident that it will.

Edit: As I suspected, behavior remained unchanged after the restart. When I execute "telnet localhost 25", the log reads:

Code: 
Dec 16 10:18:34 srv1 relaylock: /var/qmail/bin/relaylock: Unable to get ip address, white list will not work
Dec 16 10:18:34 srv1 relaylock: /var/qmail/bin/relaylock: mail from localhost:59219 (not defined)
Click to expand...

Do an nslookup for localhost and see what you get.
 
247trader said:
Do an nslookup for localhost and see what you get.
Click to expand...

Strange:

Code: 
root@srv1:~# nslookup localhost
Server:		80.237.128.144
Address:	80.237.128.144#53

Non-authoritative answer:
Name:	localhost
Address: 127.0.0.1

root@srv1:~# nslookup localhost
Server:		127.0.0.1
Address:	127.0.0.1#53

** server can't find localhost: NXDOMAIN
 
datenimperator said:
Strange:

Code: 
root@srv1:~# nslookup localhost
Server:		80.237.128.144
Address:	80.237.128.144#53

Non-authoritative answer:
Name:	localhost
Address: 127.0.0.1

root@srv1:~# nslookup localhost
Server:		127.0.0.1
Address:	127.0.0.1#53

** server can't find localhost: NXDOMAIN
Click to expand...

Two things to check. /etc/named.conf and make sure that there is an entry for 0.0.127.IN-ADDR.ARPA. If there is then that is fine and you need to run /var/named/run-root/var/make-localhost and the restart named.

Let me know how that works.
 
247trader said:
Two things to check. /etc/named.conf and make sure that there is an entry for 0.0.127.IN-ADDR.ARPA. If there is then that is fine and you need to run /var/named/run-root/var/make-localhost and the restart named. Let me know how that works.
Click to expand...

Did it, but didn't solve the issue. The file localhost.rev looks unchanged. (Certainly the script re-created it, but with the same content as before). /etc/named.conf is ok.

Code: 
root@srv1:/var/named/run-root/var# cat localhost.rev
;	From: @(#)localhost.rev	5.1 (Berkeley) 6/30/90
;	$Id: PROTO.localhost.rev,v 1.1.2.1 2001/06/06 11:41:00 kan Exp $
;
; This file is automatically edited by the `make-localhost' script in
; the /etc/namedb directory.
;

$TTL	86400

@	IN	SOA	. root..  (
				20081216	; Serial
				3600	; Refresh
				900	; Retry
				3600000	; Expire
				3600 )	; Minimum
	IN	NS	.
1	IN	PTR	localhost.
root@srv1:/var/named/run-root/var# /etc/init.d/bind9 restart
 * Stopping domain name service...
   ...done.
 * Starting domain name service...
   ...done.
root@srv1:/var/named/run-root/var# nslookup localhost
Server:		127.0.0.1
Address:	127.0.0.1#53

** server can't find localhost: NXDOMAIN
 
BTW: Why would relaylock need to resolve localhost at all to properly set TCPREMOTEIP?
 
datenimperator said:
Did it, but didn't solve the issue. The file localhost.rev looks unchanged. (Certainly the script re-created it, but with the same content as before). /etc/named.conf is ok.

Code: 
root@srv1:/var/named/run-root/var# cat localhost.rev
;	From: @(#)localhost.rev	5.1 (Berkeley) 6/30/90
;	$Id: PROTO.localhost.rev,v 1.1.2.1 2001/06/06 11:41:00 kan Exp $
;
; This file is automatically edited by the `make-localhost' script in
; the /etc/namedb directory.
;

$TTL	86400

@	IN	SOA	. root..  (
				20081216	; Serial
				3600	; Refresh
				900	; Retry
				3600000	; Expire
				3600 )	; Minimum
	IN	NS	.
1	IN	PTR	localhost.
root@srv1:/var/named/run-root/var# /etc/init.d/bind9 restart
 * Stopping domain name service...
   ...done.
 * Starting domain name service...
   ...done.
root@srv1:/var/named/run-root/var# nslookup localhost
Server:		127.0.0.1
Address:	127.0.0.1#53

** server can't find localhost: NXDOMAIN
Click to expand...

Let's try this; run nslookup on any name at all like a www.yahoo.com or something along those lines and see if it returns something. If it does not return anything then it is not listening on the loopback address which means there is an entry in /etc/named.conf that is telling what ip address to use. It is does then make sure that 0.0.127.IN-ADDR.ARPA in /etc/named.conf is not commented out.

Let me know how that fairs.
 
datenimperator said:
BTW: Why would relaylock need to resolve localhost at all to properly set TCPREMOTEIP?
Click to expand...

There are two things at work here, one relaylock will not set the proper environment variable to allow for services to work correctly unless it is able to see that information. And two, spamdyke will have its own issues when relaylock does not pass that information on so that it will bypass the filters in spamdyke.
 
247trader said:
Let's try this; run nslookup on any name at all like a www.yahoo.com or something along those lines and see if it returns something. If it does not return anything then it is not listening on the loopback address which means there is an entry in /etc/named.conf that is telling what ip address to use. It is does then make sure that 0.0.127.IN-ADDR.ARPA in /etc/named.conf is not commented out.

Let me know how that fairs.
Click to expand...

No prob.

Code: 
root@srv1:~# nslookup www.apple.com
Server:		127.0.0.1
Address:	127.0.0.1#53

Non-authoritative answer:
www.apple.com	canonical name = www.apple.com.akadns.net.
Name:	www.apple.com.akadns.net
Address: 17.112.152.32

nslookup works. When bind9 starts up, it prints this to syslog:

Code: 
Dec 16 12:27:45 srv1 named[7464]: starting BIND 9.3.2-P2.1 -t /var/named/run-root -c /etc/named.conf -u bind
Dec 16 12:27:45 srv1 named[7464]: found 1 CPU, using 1 worker thread
Dec 16 12:27:45 srv1 named[7464]: loading configuration from '/etc/named.conf'
Dec 16 12:27:45 srv1 named[7464]: no IPv6 interfaces found
Dec 16 12:27:45 srv1 named[7464]: listening on IPv4 interface lo, 127.0.0.1#53
Dec 16 12:27:45 srv1 named[7464]: listening on IPv4 interface venet0:0, 92.51.129.12#53
Dec 16 12:27:45 srv1 named[7464]: command channel listening on 127.0.0.1#953
Dec 16 12:27:45 srv1 named[7464]: dns_rdata_fromtext: localhost.rev:10: near 'root..': empty label
Dec 16 12:27:45 srv1 named[7464]: zone 0.0.127.IN-ADDR.ARPA/IN: loading master file localhost.rev: empty label
Dec 16 12:27:45 srv1 named[7464]: zone 129.51.92.in-addr.arpa/IN: loaded serial 1229171956
Dec 16 12:27:45 srv1 named[7464]: zone adcollect.com/IN: loaded serial 2008111008
Dec 16 12:27:45 srv1 named[7464]: zone compoll.com/IN: loaded serial 2008101601
Dec 16 12:27:45 srv1 named[7464]: zone familie-wiedemann.com/IN: loaded serial 2008110203
Dec 16 12:27:45 srv1 named[7464]: zone familiewiedemann.com/IN: loaded serial 2008110203
Dec 16 12:27:45 srv1 named[7464]: zone jobcollect.com/IN: loaded serial 2008110901
Dec 16 12:27:45 srv1 named[7464]: zone mariawiedemann.com/IN: loaded serial 2008110203
Dec 16 12:27:45 srv1 named[7464]: zone uliwiedemann.com/IN: loaded serial 2008110203
Dec 16 12:27:45 srv1 named[7464]: zone ulrichwiedemann.com/IN: loaded serial 2008110203
Dec 16 12:27:45 srv1 named[7464]: zone uwcon.com/IN: loaded serial 2008110901
Dec 16 12:27:45 srv1 named[7464]: zone webmail-done-right.com/IN: loaded serial 2008121102
Dec 16 12:27:45 srv1 named[7464]: zone local.b2-performance.de/IN: loaded serial 2008112501
Dec 16 12:27:45 srv1 named[7464]: zone compoll.de/IN: loaded serial 2008101601
Dec 16 12:27:45 srv1 named[7464]: zone effertz-koellen.de/IN: loaded serial 2008101601
Dec 16 12:27:45 srv1 named[7464]: zone familiewiedemann.de/IN: loaded serial 2008110203
Dec 16 12:27:45 srv1 named[7464]: zone guidokoellen.de/IN: loaded serial 2008101601
Dec 16 12:27:45 srv1 named[7464]: zone jobcollect.de/IN: loaded serial 2008110901
Dec 16 12:27:45 srv1 named[7464]: zone machts-euch-schoen.de/IN: loaded serial 2008101601
Dec 16 12:27:45 srv1 named[7464]: zone markus-brandenburger.de/IN: loaded serial 2008101601
Dec 16 12:27:45 srv1 named[7464]: zone nosunblogger.de/IN: loaded serial 2008101601
Dec 16 12:27:45 srv1 named[7464]: zone onlinetasche.de/IN: loaded serial 2008112003
Dec 16 12:27:45 srv1 named[7464]: zone opinioncounts.de/IN: loaded serial 2008101601
Dec 16 12:27:45 srv1 named[7464]: zone sauerlaender-in-koeln.de/IN: loaded serial 2008121002
Dec 16 12:27:45 srv1 named[7464]: zone uliwiedemann.de/IN: loaded serial 2008110203
Dec 16 12:27:45 srv1 named[7464]: zone uwcon.de/IN: loaded serial 2008110901
Dec 16 12:27:45 srv1 named[7464]: zone voidblog.de/IN: loaded serial 2008121301
Dec 16 12:27:45 srv1 named[7464]: zone wilde-welt.de/IN: loaded serial 2008121001
Dec 16 12:27:45 srv1 named[7464]: zone software-consultant.net/IN: loaded serial 2008121301
Dec 16 12:27:45 srv1 named[7464]: running
Dec 16 12:27:45 srv1 named[7464]: zone effertz-koellen.de/IN: sending notifies (serial 2008101601)
Dec 16 12:27:45 srv1 named[7464]: zone nosunblogger.de/IN: sending notifies (serial 2008101601)
Dec 16 12:27:45 srv1 named[7464]: zone ulrichwiedemann.com/IN: sending notifies (serial 2008110203)
Dec 16 12:27:45 srv1 named[7464]: zone adcollect.com/IN: sending notifies (serial 2008111008)
Dec 16 12:27:45 srv1 named[7464]: zone compoll.com/IN: sending notifies (serial 2008101601)
Dec 16 12:27:45 srv1 named[7464]: zone machts-euch-schoen.de/IN: sending notifies (serial 2008101601)
Dec 16 12:27:45 srv1 named[7464]: zone guidokoellen.de/IN: sending notifies (serial 2008101601)
Dec 16 12:27:45 srv1 named[7464]: zone familiewiedemann.de/IN: sending notifies (serial 2008110203)
Dec 16 12:27:45 srv1 named[7464]: zone jobcollect.com/IN: sending notifies (serial 2008110901)
Dec 16 12:27:45 srv1 named[7464]: zone local.b2-performance.de/IN: sending notifies (serial 2008112501)
Dec 16 12:27:45 srv1 named[7464]: zone opinioncounts.de/IN: sending notifies (serial 2008101601)
Dec 16 12:27:45 srv1 named[7464]: zone uliwiedemann.com/IN: sending notifies (serial 2008110203)
Dec 16 12:27:45 srv1 named[7464]: zone markus-brandenburger.de/IN: sending notifies (serial 2008101601)
Dec 16 12:27:45 srv1 named[7464]: zone compoll.de/IN: sending notifies (serial 2008101601)
Dec 16 12:27:45 srv1 named[7464]: zone uwcon.de/IN: sending notifies (serial 2008110901)
Dec 16 12:27:45 srv1 named[7464]: zone onlinetasche.de/IN: sending notifies (serial 2008112003)
Dec 16 12:27:45 srv1 named[7464]: zone jobcollect.de/IN: sending notifies (serial 2008110901)
Dec 16 12:27:45 srv1 named[7464]: zone webmail-done-right.com/IN: sending notifies (serial 2008121102)
Dec 16 12:27:45 srv1 named[7464]: zone software-consultant.net/IN: sending notifies (serial 2008121301)
Dec 16 12:27:45 srv1 named[7464]: zone familiewiedemann.com/IN: sending notifies (serial 2008110203)
Dec 16 12:27:45 srv1 named[7464]: zone familie-wiedemann.com/IN: sending notifies (serial 2008110203)
Dec 16 12:27:45 srv1 named[7464]: zone mariawiedemann.com/IN: sending notifies (serial 2008110203)
Dec 16 12:27:45 srv1 named[7464]: zone uwcon.com/IN: sending notifies (serial 2008110901)
Dec 16 12:27:45 srv1 named[7464]: zone sauerlaender-in-koeln.de/IN: sending notifies (serial 2008121002)
Dec 16 12:27:45 srv1 named[7464]: zone uliwiedemann.de/IN: sending notifies (serial 2008110203)
Dec 16 12:27:45 srv1 named[7464]: zone voidblog.de/IN: sending notifies (serial 2008121301)
Dec 16 12:27:45 srv1 named[7464]: zone wilde-welt.de/IN: sending notifies (serial 2008121001)
Dec 16 12:27:45 srv1 named[7464]: client 92.51.129.12#55143: received notify for zone 'ulrichwiedemann.com'
Dec 16 12:27:45 srv1 named[7464]: client 92.51.129.12#55143: received notify for zone 'familiewiedemann.de'
Dec 16 12:27:45 srv1 named[7464]: client 92.51.129.12#55143: received notify for zone 'familiewiedemann.com'
Dec 16 12:27:45 srv1 named[7464]: client 92.51.129.12#55143: received notify for zone 'uliwiedemann.com'
Dec 16 12:27:45 srv1 named[7464]: client 92.51.129.12#55143: received notify for zone 'mariawiedemann.com'
Dec 16 12:27:45 srv1 named[7464]: client 92.51.129.12#55143: received notify for zone 'familie-wiedemann.com'
Dec 16 12:27:45 srv1 named[7464]: client 92.51.129.12#55143: received notify for zone 'uliwiedemann.de'

I've completed the email address of root in localhost.rev to eliminate the warning regarding the empty label, but it doesn't help: nslookup'ing localhost still doesn't work.

About your comments: Sure, spamdyke needs valid rDNS information to do its work, no doubt about that. But why does relaylock need an DNS server to set the variable TCPREMOTEIP? The remote IP is visible from the incoming IP session, right? No need for DNS.

So I'd understand if TCPREMOTEIP contained 127.0.0.1 but TCPREMOTEHOST was empty (because, for some reason lookup of 127.0.0.1 didn't work), but the other way doesn't make sense to me.
 
datenimperator said:
No prob.

Code: 
root@srv1:~# nslookup www.apple.com
Server:		127.0.0.1
Address:	127.0.0.1#53

Non-authoritative answer:
www.apple.com	canonical name = www.apple.com.akadns.net.
Name:	www.apple.com.akadns.net
Address: 17.112.152.32




About your comments: Sure, spamdyke needs valid rDNS information to do its work, no doubt about that. But why does relaylock need an DNS server to set the variable TCPREMOTEIP? The remote IP is visible from the incoming IP session, right? No need for DNS.

Actually it has to do with tcp-env which as part of the libraies it calls looks to resolver for the lookup and then sets the parameters. So it is related in an indirect fashion.

So I'd understand if TCPREMOTEIP contained 127.0.0.1 but TCPREMOTEHOST was empty (because, for some reason lookup of 127.0.0.1 didn't work), but the other way doesn't make sense to me.
Click to expand...

Something is not right here and I can't put my finger on it. Since qmail is basically running as root under inetd it makes it a bit more complicated to find the issues. You know I really wish plesk would run qmail like Daniel Bernstein wanted it run; under daemontools.

Run ps -aex | grep qmail-smtpd and send me the output. Also see if you can run tcp-env from the command line.
 
You must log in or register to reply here.

Similar threads

H
Relay Problem!
Replies
0
Views
2K
[email protected]
H
B
spam from localhost
Replies
10
Views
12K
trialotto
T
R
SMTP server(qmail) won't start, no file /var/qmail/bin/relaylock
Replies
10
Views
7K
levelup3
L
Back
Top