Resolved Internal e-mail marked as spam despite successful SMTP auth (sent via webmail)

[Kristo]

Plesk is configured to use DNS Blackhole Lists. As a result even internal mails get marked as spam because some IPs from my internet provider are on that lists. As stated in this article the problem can be avoided if port 587 is used for SMTP. But how to avoid the problem when sending mails via webmail (horde in my case)?

 

[Émerson Felinto]

Have you tried adding your IPs to the whitelist?

Tools & Settings> Spam Filter Settings> White list

 

[Kristo]

This is not realy an option because a) I can´t whitelist all IPs of other users home internet connections and b) even if I would the IPs are changing from day to day

 

[MarkM]

Sending email from webmail uses the IP address of the server. You wouldn't have any issue regardless the status of the customer's IP. (assuming you keep the server IP clean)

 

[Kristo]

But spamassassin is taking the IP of the customer into account. Have a look at the first two lines. 3.6 points for the customer IP (I replaced the original IP with xxx.x.xx.xxx but it´s definitely the customers IP ... checked it twice)

3.6 RCVD_IN_PBL            RBL: Received via a relay in Spamhaus PBL
                           [xxx.x.xx.xxx listed in zen.spamhaus.org]
-0.0 SPF_PASS              SPF: sender matches SPF record
...
0.4 RDNS_DYNAMIC           Delivered to internal network by host with
                           dynamic-looking rDNS
3.2 HELO_DYNAMIC_IPADDR    Relay HELO'd using suspicious hostname (IP addr 1)
2.7 TO_NO_BRKTS_DYNIP      To: lacks brackets and dynamic rDNS

 

[MarkM]

Which webmail platform are you using? I know for sure Roundcube doesn't do this.....

 

[Kristo]

Horde 5.2.13

 

[MarkM]

That's your issue. Horde add's the sender's IP. You may be able to find some sort of patch for it...

 

[websavers]

That's your issue. Horde add's the sender's IP. You may be able to find some sort of patch for it...

This is an interesting point. And unfortunately there's a lot of confusing little details to this.

My issue may not be exactly the same, though the title of this thread indicates it is, I suspect the title may have been incorrectly worded. The title says "despite successful SMTP auth". This implies that authentication actually occurred between the webmail system and the mail server. That said, last I heard Plesk's default method of sending messages via its built-in webmail solutions is to simply send unauthenticated to localhost, where the webmail and mail system reside on the same server. If that's what the OP is doing, then Mark is correct because it's technically not authenticated SMTP (there is no header indicating successful authentication), and therefore the RCVD_IN_PBL report from Spamassassin *is* correct.

However, we don't use any of the webmail systems built in to Plesk, instead opting to use a centrally hosted instance of Rainloop. We've got the Rainloop plugin to add the X-Originating-IP header installed (though now it's disabled to avoid this problem). Our Rainloop instance *must* and does use SMTP authentication to send messages because it doesn't reside on the same server as our customers' mail services.

According to this discussion on the Spamassassin bugzilla, even though the X-Originating-IP header exists, it should be ignored in favour of the SMTP servers' "Received:" header which indicates that the mail user has authenticated successfully, thus ensuring that the IP of the actual SMTP/Mail server is checked against the PBL and *not* the IP found in the X-Originating-IP header.

However we're finding that this is not the case. Here are the only headers added by Postfix on the Plesk server that describe authentication. They're from a message where the RCVD_IN_PBL rule was triggered against the X-Originating-IP header IP:

Received: from webmailserver.com (webmailserver-hostname.com [webmailserver-ip])
by actual-plesk-mail-server.com (Postfix) with ESMTPSA id 9DXXX92564
for ju****ks@ita****et.ca; Thu, 24 Jan 2019 14:16:37 -0400 (AST)
Authentication-Results: actual-plesk-mail-server.com;

My questions:
- Is Postfix not correctly indicating authentication occurred in its headers? Or
- Is Spamassassin not correctly reading the headers to understand that authentication occurred?

From what I can see, where it says "with ESMTPSA" -- that's the indication that it's using authentication. According to this Wikipedia entry on SMTP Authentication, the A on the end indicates it's using authentication. Therefore, it looks to me like Spamassassin is not parsing the headers correctly and understanding that authentication occurred.

 

[websavers]

We've created a bug report about this on spamassassin's bug tracker, but it's not going to go anywhere because Plesk/CentOS doesn't use the latest release of Spamassassin to test it properly. Instead it uses 3.4.0 when the latest release is 3.4.2. A Spamassassin dev replied indicating that until it can be tested against 3.4.2, there's nothing they can do.

Since we can't resolve the source issue (likely with Spamassassin) we've disabled the x-originating-ip header in our webmail to work around this problem.

 

[vimobe]

Plesk is configured to use DNS Blackhole Lists. As a result even internal mails get marked as spam because some IPs from my internet provider are on that lists. As stated in this article the problem can be avoided if port 587 is used for SMTP. But how to avoid the problem when sending mails via webmail (horde in my case)?

Im my opinion. best is to use smtp relay service provider and have them authorize to send email on behalf the domain by verifying via cname and/ or txt record. ive tried 3 different smtp relay service in fact my mail server connected to smtp relay service and each domain verified by the smtp relay will full dkim and spf compliant. as result slim chance will go into junk mail.

give it a try