Reverse DNS does not match SMTP Banner

[atomicguava]

I've just installed MagicSpam 1.04.61 on my CentOS 5 Plesk 9.3 server running QMail.

When I use http://www.mxtoolbox.com to check one of the domain names, I get:

Code: Select all

220 Spam Protection provided by MagicSpam www.magicspam.com ESMTP

Not an open relay.
0 seconds - Good on Connection time
0.468 seconds - Good on Transaction time
OK - 78.***.***.** resolves to
Warning - Reverse DNS does not match SMTP Banner

Normally, I would expect the reverse DNS to be in place. For example, on another RHEL 5 Plesk 9.3 running Postfix with MagicSpam 1.04.61 I get the following output from mxtoolbox:

Code: Select all

20 server1.***************.com ESMTP Postfix

Not an open relay.
0 seconds - Good on Connection time
0.530 seconds - Good on Transaction time
OK - 83.***.***.** resolves to server1.**************.com
OK - Reverse DNS matches SMTP Banner

Where am I going wrong? I've set the hostname property on both servers in Plesk's settings section.

[jovic]

This is a strange configuration change, that MagicSpam does on qmail systems. Simply delete (or better rename) the file "/var/qmail/control/smtpgreeting". Qmail will then use the contents of the file /var/qmail/control/me as smtp banner. Make sure, that it matches your rDNS record.

Regards

[atomicguava]

This didn't work, I'm afraid.

As soon as I deleted the file and restarted qmail it came back with the same content as before.

[magicspam]

Please provide the contents of the following files:
/var/qmail/control/smtpgreeting
/var/qmail/control/me

as well as the output of the following command:

ls -al /var/qmail/control/

[atomicguava]

Please provide the contents of the following files:
/var/qmail/control/smtpgreeting
/var/qmail/control/me

as well as the output of the following command:

ls -al /var/qmail/control/

/var/qmail/control/smtpgreeting
Spam Protection provided by MagicSpam http://www.magicspam.com

/var/qmail/control/me
server1.guavadesign.co.uk

[root@server1 ~]# ls -al /var/qmail/control/
total 96
drwxr-xr-x 2 root qmail 4096 May 18 00:27 .
drwxr-xr-x 11 root qmail 4096 May 4 04:58 ..
lrwxrwxrwx 1 root root 33 Feb 11 19:26 clientcert.pem -> /var/qmail/control/servercert.pem
-rw-r--r-- 1 root root 1 Mar 11 17:07 databytes
-rw-r--r-- 1 root root 34 May 4 04:47 defaultdelivery
-rw-r--r-- 1 root root 245 May 4 04:47 dhparam1024.pem
-rw-r--r-- 1 root root 156 May 4 04:47 dhparam512.pem
-rw-r--r-- 1 root root 58 May 10 09:24 locals
-rw-r--r-- 1 root root 26 May 10 09:24 me
-rw-r--r-- 1 root root 12288 May 18 00:28 .me.swp
-rw-r--r-- 1 root root 1719 May 15 00:07 rcpthosts
-rw-r--r-- 1 root root 1795 May 15 00:07 rejectnonexist
-rw------- 1 qmaild root 493 Feb 11 19:25 rsa512.pem
-rw-r--r-- 1 root root 2954 Feb 11 19:24 servercert.pem
-rw-r--r-- 1 root sw-cp-server 56 May 17 12:09 smtpgreeting
-rw-r--r-- 1 root sw-cp-server 49 May 17 12:09 smtpplugins
-rw-r--r-- 1 root root 2053 May 15 00:07 virtualdomains

[jovic]

Yes, it seems, that magicspam restore that smtpgreeting regularly. I prevented that by linking the file to /dev/null:

cd /var/qmail/control
rm -f smtpgreeting
ln -s /dev/null smtpgreeting
ls
lrwxrwxrwx 1 root root 9 11. Mai 15:37 smtpgreeting -> /dev/null

[magicspam]

Please refer to: viewtopic.php?f=15&t=671