• We value your experience with Plesk during 2024
    Plesk strives to perform even better in 2025. To help us improve further, please answer a few questions about your experience with Plesk Obsidian 2024.
    Please take this short survey:

    https://pt-research.typeform.com/to/AmZvSXkx
  • The Horde webmail has been deprecated. Its complete removal is scheduled for April 2025. For details and recommended actions, see the Feature and Deprecation Plan.
  • We’re working on enhancing the Monitoring feature in Plesk, and we could really use your expertise! If you’re open to sharing your experiences with server and website monitoring or providing feedback, we’d love to have a one-hour online meeting with you.

Forwarded to devs Saving the Mail Server Settings page resets smtpd_recipient_restrictions

danami

Silver Pleskian
Username:

TITLE

Saving the Mail Server Settings page resets smtpd_recipient_restrictions

PRODUCT, VERSION, OPERATING SYSTEM, ARCHITECTURE

Product version: Plesk Obsidian 18.0.45.2
OS version: AlmaLinux 8.6 x86_64
Build date: 2022/07/22 09:00
Revision: eb4e2a3b37f5171bb9212b7a720f51b9edddefaf

PROBLEM DESCRIPTION

Postfix allows admins to set spam fighting restrictions in /etc/postfix/main.cf so that Spam can be blocked at the smtp level before it goes to SpamAssassin or Amavis. Extensions like Plesk Email Security try to set these options.

The problem is that Plesk erases those extra restrictions when the Mail Server Settings page is saved.

For example:

Enabling "Postfix - Strict Rules" in Plesk email security sets an extra restriction in smtpd_recipient_restrictions like:
Code:
smtpd_recipient_restrictions = permit_mynetworks,permit_sasl_authenticated,reject_unauth_destination,reject_invalid_helo_hostname

Then when the Mail Server Page is saved these settings are erased and reset to:
Code:
smtpd_recipient_restrictions = permit_mynetworks, reject_unauth_destination

The result is that the admin thinks that "Postfix - Strict Rules" are set when some of them are erased.

You should also note that it resets these differently between rpm and debian versions (which is likely another bug).

On AlmaLinux 8 it gets reset to:

Code:
smtpd_recipient_restrictions = permit_mynetworks, reject_unauth_destination

On Debian/Ubuntu it gets reset to:

Code:
smtpd_recipient_restrictions = permit_mynetworks, permit_sasl_authenticated, reject_unauth_destination

STEPS TO REPRODUCE

1. Add any extra restrictions like "reject_non_fqdn_recipient, reject_unknown_recipient_domain" to smtpd_recipient_restrictions manually or by enabling "Postfix - Strict Rules" using the Plesk Email Security extension.

2. Go to Tools and Settings -> Mail Server Settings and save the page.

ACTUAL RESULT

smtpd_recipient_restrictions will be reset again to :

Code:
smtpd_recipient_restrictions = permit_mynetworks, reject_unauth_destination

with the new restrictions removed.

EXPECTED RESULT

Plesk should should only reset smtpd_recipient_restrictions if it detects that reject_unauth_destination is missing (which would result in an open relay).

This would fix Plesk Email Security and improve spam fighting options being set.

ANY ADDITIONAL INFORMATION

(DID NOT ANSWER QUESTION)

YOUR EXPECTATIONS FROM PLESK SERVICE TEAM

Confirm bug
 
The bug is confirmed for Plesk Email security extension: EXTPLESK-3846. The extension should keep strict rules enabled.

The manual customization of the main.cf is yet to be implemented. Feature request already exists: Allow customization of /etc/postfix/main.cf

As a possible workaround, to keep manual changes in main.cf, it is possible to create a script that will track changes in main.cf and update required parameters automatically. Postfix should be reloaded to apply changes. For file changes fswatch utility can be used:
How To Monitor File Changes Using fswatch In Linux - OSTechNix
 
Thanks @IgorG. This really is needed as in our testing we can reject the bulk of spam using postfix's built in spam settings. All the developers would need to do is add a simple check to smtpd_recipient_restrictions to see if it was missing 'reject_unauth_destination then reset it:

PHP:
if (strpos($smtpd_recipient_restrictions, 'reject_unauth_destination') === FALSE)
{
   // lets reset smtpd_recipient_restrictions as it could be an open relay
}

That would allow additions to be applied and still maintain sanity checks. Hopefully this gets added soon!
 
Back
Top