• Hi, Pleskians! We are running a UX testing of our upcoming product intended for server management and monitoring.
    We would like to invite you to have a call with us and have some fun checking our prototype. The agenda is pretty simple - we bring new design and some scenarios that you need to walk through and succeed. We will be watching and taking insights for further development of the design.
    If you would like to participate, please use this link to book a meeting. We will sent the link to the clickable prototype at the meeting.
  • (Plesk for Windows):
    MySQL Connector/ODBC 3.51, 5.1, and 5.3 are no longer shipped with Plesk because they have reached end of life. MariaDB Connector/ODBC 64-bit 3.2.4 is now used instead.
  • 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.

Resolved Plesk Postfix RPM overrites /etc/postfix/header_checks with every Postfix package update

danami

Silver Pleskian
Username:

TITLE


Plesk Postfix RPM overrites /etc/postfix/header_checks with every Postfix package update

PRODUCT, VERSION, OPERATING SYSTEM, ARCHITECTURE

Product version: Plesk Obsidian 18.0.65.2
OS version: AlmaLinux 8.10 x86_64
Build date: 2024/11/22 08:00
evision: 738ea4038904b53a068e522aa7c64390f4f29d5f

PROBLEM DESCRIPTION

The file /etc/postfix/header_checks is meant to be a config file but it gets overwritten with every time Plesk updates Postfix.

Documentation from the /etc/postfix/header_checks file:

Code:
#        header_checks - Postfix built-in content inspection
#
# SYNOPSIS
#        header_checks = pcre:/etc/postfix/header_checks
#        mime_header_checks = pcre:/etc/postfix/mime_header_checks
#        nested_header_checks = pcre:/etc/postfix/nested_header_checks
#        body_checks = pcre:/etc/postfix/body_checks
#
#        milter_header_checks = pcre:/etc/postfix/milter_header_checks
#
#        smtp_header_checks = pcre:/etc/postfix/smtp_header_checks
#        smtp_mime_header_checks = pcre:/etc/postfix/smtp_mime_header_checks
#        smtp_nested_header_checks = pcre:/etc/postfix/smtp_nested_header_checks
#        smtp_body_checks = pcre:/etc/postfix/smtp_body_checks

Normally the admin would run postconf -e "header_checks = pcre:/etc/postfix/header_checks" to add it to the config then add any required header checks to that file.

STEPS TO REPRODUCE


Run the Plesk installer. If the Postfix package gets updated then the /etc/postfix/header_checks gets reverted.

ACTUAL RESULT

Any changes to /etc/postfix/header_checks get overwritten because it gets reverted back to default.

EXPECTED RESULT

The Plesk Postfix package RPM spec file should mark /etc/postfix/header_checks with %config(noreplace) so it doesn't get overwritten if its been edited.

ANY ADDITIONAL INFORMATION

(DID NOT ANSWER QUESTION)

YOUR EXPECTATIONS FROM PLESK SERVICE TEAM

Confirm bug
 
Thank you for the report, @danami. I forwarded it to our engineers for further review and it was not classified as a Plesk bug. If the header_checks file is added as pcre, it should be complied before use as:

postmap /etc/postfix/header_checks

Then header_checks.db is not overwritten by updates.
 
@Sebahat.hadzhi That doesn't make any sense at all. If a user adds a check to /etc/postfix/header_checks then runs postmap to generate the header_checks.db then Plesk updates Postfix and reverts /etc/postfix/header_checks. Then what happens if you want to add another header_check later on? You have re-add everything again because the file was reverted?
 
Thank you for your update. I see your point, that will complicate things if you want to make further updates. I will double-check with our team and get back to you.
 
@Sebahat.hadzhi I checked the RPM spec file from the Postfix packages provided by AlmaLinux 9 (not Plesks packages) and they set the header_checks properly like they should be

From the AlmaLinux 9 Postfix RPM spec file:

Code:
%attr(0644, root, root) %config(noreplace) %{postfix_config_dir}/header_checks
 
Thank you for your follow-up. After further discussion, the case was indeed classified as a bug with ID PPPM-14712. I am sorry for the initial misunderstanding caused by our end and thank you for bringing the issue to our attention. Until a fix is introduced, the only alternative we can suggest is to manually restore the file after an upgrade.
 
Back
Top