Incorrect email headers for authenticated sessions (ESMTPA)

[nforde]

The problem : Spam Assassin is marking all internal emails (sent via authenticated SMTP sessions by our customers to another email address on our server) as spam.

This is because qmail isn't RFC 3848 compliant. It isn't marking the 'Recieved' header as ESMTPA instead of ESMTP.

Here is an example of how it SHOULD be shown (this is from http://www.fehcom.de/qmail/smtpauth.html) -

Received: from xdsl-81-173-228-159.netcologne.de (HELO mail.fehnet.de) ([email protected]@81.173.228.159)
by hamburg134 with ESMTPA; 23 Jan 2005 13:32:13 -0000

As a result, Spam Assassin can't tell it's an authenticated email, and it performs tests on the email that it shouldn't, so the email gets marked as spam (it is treated as an UN-authenticated email from a dynamic IP address).

Is anyone else having this problem? Does anyone know of a solution?

Why doesn't Parallels/Plesk provide a patched version of Qmail that is RFC 3848 compliant? If anyone from Parallels is reading this, here are the patches... http://www.fehcom.de/qmail/smtpauth.html#PATCHES

There is discussion of this issue at the following url. It shows that Postfix now has native support for RFC 3848, but doesn't mention Qmail - http://wiki.apache.org/spamassassin/DynablockIssues

 

[breun]

We're not seeing this problem. SpamAssassin isn't marking internal mail as spam for us.

 

[nforde]

What is stopping your dynablock (dynamic IP) rules from being triggered? (when you connect to the smtp server from a typical dynamic IP address).

Here are the typical headers for emails sent from our customers to other customers on the same server -
X-Spam-Level: ******
X-Spam-Status: No, score=6.5 required=7.0 tests=AWL,BAYES_00,DOS_OUTLOOK_TO_MX,
RCVD_IN_PBL,RCVD_IN_SORBS_DUL,RDNS_DYNAMIC autolearn=no version=3.2.5

ps. On this occassion it didn't get marked as spam, but it would have if the spam threshold was set below 6.5.

 

[breun]

Do you use submission (port 587) to connect to your SMTP server? That may make a difference, I'm not sure. You could always change the scores for the dynamic IP rules to your liking. Note that we're not using psa-spamassassin, but ART's qmail-scanner with his SpamAssassin package.

 

[nforde]

We use the standard smtp port (25). I don't think changing the port would make a difference to email headers, as it's still using the same qmail server.

Does anyone know when this will be implemented in Plesk?

Surely others are having the same problem?

 

[breun]

We use the standard smtp port (25). I don't think changing the port would make a difference to email headers, as it's still using the same qmail server.

It's the same software, but not the same configuration. See the /etc/xinetd.d/s*_psa files. They're not identical.

 

[nforde]

ESMTPA Qmail Plesk Issue

I've tested by sending via port 587 also.

It bypasses the 'stage 1' spam blocking (MAPS, set in Plesk), but the emails still then go via the 'stage 2' spam filter (Spam Assassin) which triggers the dynamic IP rules (and 'no reverse dns' rules etc.).

Back to the original question -
1) When is Plesk going to include an RFC 3848 compliant version of Qmail with Plesk so it shows ESMTPA for authenticated emails instead of always showing ESMTP? I have upgraded to Plesk 9.0.0 and it's STILL not been rectified.

Maybe in Plesk 9.0.1 it will FINALLY be sorted out!?!?

 

[breun]

You can switch from qmail to Postfix if you're running Plesk 9.0. Have you tried that?

 

[nforde]

No, I haven't tried it yet as I host around 300 domains and I'm concerned it could possibly break during the changeover, especially in relation to Spam Assassin or ClamAV.

Does Postfix put "ESMTPA" in the Received headers for authenticated sessions?