Forwarded to devs SPF_FAIL for internally forwarded emails

[RPD]

Username:

TITLE

SPF_FAIL for internally forwarded emails

PRODUCT, VERSION, OPERATING SYSTEM, ARCHITECTURE

Plesk Obsidian 18.0.46 Update #1
CentOS Linux 7.9.2009
x86-64

PROBLEM DESCRIPTION

When we switch on mail forwarding for an email address in Plesk and forward to another address on the same server, we always get an SPF_FAIL in SpamAssassin. Plesk correctly rewrites the envelope sender for forwarded emails (SRS) and the domain of the rewritten sender is correctly authorised to send email via that same server (SPF). So this shouldn't happen. Emails forwarded to addresses on an external server don't exhibit that problem.

So we think this is a problem related to the way Plesk forwards emails to internal addresses. SPF should work correctly even for internally forwarded emails. The bug leads to false SPF_FAILs which subsequently increase the probability of false positives for spam detection.

STEPS TO REPRODUCE

Switch on mail forwarding for an arbitrary email address A on a Plesk server. Enter a destination email address B that is on the same server, but has a different domain. Make sure the domain of the destination address B has SPF enabled and the server is authorised to send email for that domain. Now send an email C from a different server to A. That email is then forwarded to B by Plesk.

ACTUAL RESULT

Plesk correctly rewrites the envelope sender of C to an address in the domain of A (SRS) and forwards that email to B. But unfortunately that email erroneously fails the SPF check (SpamAssassin X-Spam-Status includes SPF_FAIL in the mail headers), although the server is authorised to send emails for the domain of A (SPF).

EXPECTED RESULT

The mail which is finally delivered to the mailbox of B should pass the SPF check because the server is authorised to send mails for the domain of A (which is the envelope sender after SRS).

ANY ADDITIONAL INFORMATION

The bug leads to false SPF_FAILs for internally forwarded emails which subsequently increase the probability of false positives for spam detection. So this should definitely be fixed.

Mail server is Postfix with Dovecot.

YOUR EXPECTATIONS FROM PLESK SERVICE TEAM

Confirm bug

 

[RPD]

Small correction (changes in bold):

STEPS TO REPRODUCE

Switch on mail forwarding for an arbitrary email address A on a Plesk server. Enter a destination email address B that is on the same server, but has a different domain. Make sure the domain of the address A has SPF enabled and the server is authorised to send email for that domain. Now send an email C from a different server to A. That email is then forwarded to B by Plesk.

 

[BC108]

I see this, too. (Actually Google brought me here while searching for this issue.) The problem arises because SpamAssassin verifies the envelope-from (which has been rewritten) against the topmost "Received: from ..." header (which still indicates the host that delivered the original mail).

IMO Postfix should not rewrite the envelope-from for internal forwards, but only when forwarding to external domains via SMTP.

(Btw., this behavior also causes the HEADER_FROM_DIFFERENT_DOMAINS rule to fire, which adds another 0.25 points to the spam score.)

 

[RPD]

@BC108 Thank you for confirming the bug and the additional insights.

I agree, Postfix shouldn't rewrite the envelope-from for internal forwards, i.e. SRS should be disabled for these.

@plesk team: Could this be implemented?

As regards the HEADER_FROM_DIFFERENT_DOMAINS I think this is normal for SRS and can't be changed for external forwards. But if we disabled SRS for internal forwards as you suggested, HEADER_FROM_DIFFERENT_DOMAINS wouldn't be triggered, of course. So you're right.

I really hope this can be fixed soon, as it causes some problems for us.

 

[RPD]

No answer from the Plesk team and no other news so far? Why hasn't this confirmed report been forwarded to the dev team?

 

[Bitpalast]

No answer from the Plesk team and no other news so far? Why hasn't this confirmed report been forwarded to the dev team?

Please see the blue tag

It means that this has been forwarded to developers for further processing.

 

[RPD]

@Peter Debik:

Please see the blue tag

It means that this has been forwarded to developers for further processing.

Yes, but this wasn't the case when I wrote my message. The tag has been added only after I posted my preceeding message. But thank you for informing me about this change.

 

[IgorG]

From the developer:

I was unable to reproduce the issue - my email successfully passed SPF check, but meanwhile: Looks like 'envelope' header was added because "Fix incorrectly set sender for outgoing mail" is checked on in Tools&Settings -> Mail server settings -> Global settings. Or using CLI - "plesk bin --set-outgoing-messages-fix-sender true|false". This option described in our doc - mailserver: Mail Server Settings

 

[RPD]

From the developer:

I was unable to reproduce the issue - my email successfully passed SPF check, but meanwhile: Looks like 'envelope' header was added because "Fix incorrectly set sender for outgoing mail" is checked on in Tools&Settings -> Mail server settings -> Global settings. Or using CLI - "plesk bin --set-outgoing-messages-fix-sender true|false". This option described in our doc - mailserver: Mail Server Settings

That's unfortunate, because the problem is reproducible on all our Plesk servers (current version). The option "Fix incorrectly set sender for outgoing mail" is not enabled on any of our servers. So that can't be the reason for the problem. Also, Plesk doesn't add an "envelope" header, but rewrites the "envelope-from" (which is visible in the "Return-Path" header). That's the mechanism behind SRS (Sender Rewriting Scheme), which is needed to not break SPF (Sender Policy Framework) for forwarded emails to external domains. Unfortunately, this mechanism breaks SPF for internal forwards.

So, there are two alternative solutions to the problem:

1. SRS should not be performed for internal forwards (i.e. "envelope-from" for internal forwards should not be rewritten).
   This is the solution suggested by @BC108.
   
   
2. Plesk (or Postfix) should add an additional "Received: from" header for internal forwards with the same public IP address of the server which would be used to forward the email to an external server.

Both solutions should fix the problem.

 

[DaarGaJeDan]

Have the same issue: see

Issue - 421 EHLO MXIN201 Your HELO/EHLO example.com is not matching your DNS configuration s2.myserver.com

hi Guys, I have problems setting up the mail servers and the DNS settings. I try to mail to ziggo.nl but i keep getting the following error: 421 EHLO MXIN201 Your HELO/EHLO example.com is not matching your DNS configuration s2.myserver.com i should expect that example.com should be...

talk.plesk.com

 

[RPD]

@DaarGaJeDan No, your problem seems to be different from the problem described in this thread. The problem in this thread only occurs for internal forwards, not for regular emails to external email addresses.

 

[IgorG]

Developers cannot reproduce the issue according to the provided steps to reproduce. Even with "Fix incorrectly set sender for outgoing mail" disabled (as mentioned above).

Please either provide the complete steps to reproduce that is reproducible on a clean Plesk or file a ticket to the Plesk Support Team and supply access to a server with the problem.

 

[RPD]

@IgorG I can assure you that the problem is reproducible on a clean installation of Plesk. Unfortunately, we cannot give access to our servers to external service providers (company policy).

Did your developers pay attention to my small correction in post #2 (Forwarded to devs - SPF_FAIL for internally forwarded emails)?

 

[IgorG]

Did your developers pay attention to my small correction in post #2 (Forwarded to devs - SPF_FAIL for internally forwarded emails)?

Yes, all domains had SPF enabled (this is the default, anyway).

 

[RPD]

@IgorG When I said "SPF enabled", I meant the DNS setting (TXT SPF record). This is important, because otherwise the problem does not occur.

If your developers had that record for all domains, I'm not sure why they weren't able to reproduce the problem. BC108 (post #3) described the root cause of the problem quite well and that does definitely happen on all our Plesk servers.

 

[Kaspar]

I can confirm having this issue too and I am able to reproduce it on a fresh server as well.

For testing purposes I created a droplet with DigitalOcean running CentOS 7.9 and installed Plesk via command line. Which installed Plesk version 18.0.48.

These are the steps I took to reproduce the issue.

1) SpamAssassin wasn't installed by default, so trough the UI (Tools & Settings > Updates) I selected SpamAssassin to be installed (which is verion 3.4.0)
2) Created a subscription for domainA.com and added the email address [email protected]
3) Double checked if the option Switch on spam filtering for this email address for [email protected] was checked (it was)
4) Created a subscription for domainB.com and added the email address [email protected]
5) Enabled forwarding for [email protected] to [email protected].
6) Disabled the mailbox for [email protected] (to just have it as a forward address)
7) Double checked if the option Switch on spam filtering for this email address for [email protected] was checked (it was)
8) For both domains a TXT record for SPF was added with the value: v=spf1 +a +mx -all

To test this issue I've send and email message from an external email account (with a different domain) to [email protected]. Then I logged in to Roundcube to retrieve the email on [email protected]. The email was received and has the following headers.

Return-Path: <[email protected]>
X-Spam-Checker-Version: SpamAssassin 3.4.0 (2014-02-07) on
    busy-leakey.123-123-123-123.plesk.page
X-Spam-Level: ***
X-Spam-Status: No, score=3.4 required=5.0 tests=DKIM_SIGNED,DKIM_VALID,
    DNS_FROM_AHBL_RHSBL,HTML_MESSAGE,RCVD_IN_DNSWL_NONE,RCVD_IN_MSPIKE_H2,
    SPF_FAIL,T_HEADER_FROM_DIFFERENT_DOMAINS autolearn=no autolearn_force=no
    version=3.4.0
X-Original-To: [email protected]
Delivered-To: [email protected]
Received: by busy-leakey.123-123-123-123.plesk.page (Postfix, from userid 30)
    id 0FA81B55CF; Wed, 9 Nov 2022 17:54:35 +0000 (UTC)
X-Original-To: [email protected]
Delivered-To: [email protected]
Received: from mail-ed1-f53.google.com (mail-ed1-f53.google.com [209.85.208.53])
    by busy-leakey.123-123-123-123.plesk.page (Postfix) with ESMTPS id C847E1AE9
    for <[email protected]>; Wed, 9 Nov 2022 17:54:32 +0000 (UTC)
Authentication-Results: busy-leakey.123-123-123-123.plesk.page;
    dmarc=pass (p=NONE sp=NONE) smtp.from=external-domain.com header.from=external-domain.com;
    dkim=pass header.d=external-domain-com.20210112.gappssmtp.com;
    dmarc=pass (p=NONE sp=NONE) smtp.from=external-domain.com.com header.from=external-domain.com;
    dkim=pass header.d=external-domain-com.20210112.gappssmtp.com;
    spf=pass (sender IP is 209.85.208.53) [email protected] smtp.helo=mail-ed1-f53.google.com
Received-SPF: pass (busy-leakey.123-123-123-123.plesk.page: domain of external-domain.com designates 209.85.208.53 as permitted sender) client-ip=209.85.208.53; [email protected]; helo=mail-ed1-f53.google.com;

Notice the SPF_FAIL rule has been trigged by SpamAssassin.

Other information that might be useful.

• Only a IPv4 address was available, no IPv6 address was configured

 

[RPD]

@Kaspar Thank you for chiming in. Yes, that's exactly the problem we are observing. And it is of course reproducible.

 

[IgorG]

From developer:

Cannot reproduce in our test environment according to the provided STR. In all tests, SpamAssassin correctly results in SPF_PASS status.

So, please contact Plesk Support Team. Investigation directly on your server is required.

 

[RPD]

@IgorG As I already noted we cannot give access to our servers to external service providers (company policy). And I don't think this is necessary either, because Kaspar (see post #16) could reproduce it in a DigitalOcean droplet (fresh install). Follow his detailed steps and you will be able to reproduce this issue, too.

Thanks!

 

[Kaspar]

I escalated this to Plesk support. Got the following response.

The development team has found an inconsistency in SpamAssassin's behavior - since it's using a non-matching relay address (first external relay form Received) and sender domain address (from SRS-rewritten Return-Path), the SPF check fails as a result.

This inconsistency was confirmed as a bug PPPM-13801, which is scheduled to be fixed in future Plesk versions. Until the bug is fixed, the only workaround would be to manually tag the forwarded messages as "not spam" to train SpamAssassin, or to whitelist the sender's addresses on the recipient's side.