Issue [PPP-27696] Postfix Local Delivery Issue

[Vitaliy_Chetverikov]

After upgrading Plesk from 11.5 to 12.0.18, I started experiencing system email delivery issues. Specifically, LogWatch stopped being able to send emails to root.

I can replicate the issue as follows:

echo -e "To: root\nFrom: test\nSubject: Test\n\nTest" | sendmail -t

This results in the following maillog messages:

Oct  6 13:25:35 shared1 plesk sendmail[29839]: Unable to get sender domain by sender mailname
Oct  6 13:25:35 shared1 plesk sendmail[29839]: handlers_stderr: SKIP
Oct  6 13:25:35 shared1 plesk sendmail[29839]: SKIP during call 'check-quota' handler
Oct  6 13:25:35 shared1 plesk sendmail[29839]: Unable to get sender domain by sender mailname
Oct  6 13:25:35 shared1 plesk sendmail[29839]: Incorrect recipient mailname : root

However, the following command succeeds and I receive the email just fine:

echo -e "To: root\nFrom: test\nSubject: Test\nTest" | sendmail -t

As you can see, the only difference between the two commands is that the body of the email starts with a new line. Space causes the same issue. So, it looks like the issue is triggered by a whitespace character at the beginning of email body.

This only happens with To addresses, which are local usernames and do not include FQDN. Complete email addresses work just fine. However, this issue prevents me form receiving local system emails, which are sent to root.

 

[DanCermak]

Hi,
I am observing exactly the same issue with Plesk 12.5 on CentOS 7 with postfix as the MTA.

Is there any fix for this?

Cheers,
Dan

 

[serverpoint]

Hi,

Can you please check if "non_smtpd_milters" is present in the Postfix configuration: /etc/postfix/main.cf:
If so please try to comment out non_smtpd_milters and restart postfix and try again.

Regards,

 

[DanCermak]

Hi,
that option is not present in the postfix configuration file.

Cheers,
Dan

 

[serverpoint]

Hi,

As a work around. I suggest you to switch the mail service to Qmail and try running.

/usr/local/psa/admin/sbin/mchk

 

[DanCermak]

Hi,
the email notification also contained the following link, which somehow does not seem to show up in the web version: http://www.ispcolohost.com/2013/11/07/removing-postfix-aliases-after-converting-from-qmail-plesk/
I already found that webpage previously, but that is a different problem. It is about external mail for any root@ address being delivered to root (nevertheless, I checked the aliases and no remnants from a switch from qmail are present). But my problem is about local mail for root not being properly delivered unless there is only one newline after the subject line (but there should be two, therefore every unix daemon fails to send mail to root; and even when that wonky formatting is used, the messages are not sent to the proper recipient from /etc/aliases but to root@maildomain).
About your suggestion to switching to qmail: that is not an option. Qmail has been unmaintained for close to 10 years now, using it in production and on the open internet is imho a bad idea.

Cheers,

 

[DanCermak]

So, after digging further, I have been able to partially solve the problem: apparently plesk set its own program postfix-sendmail-wrapper as the mta in the alternatives. You can find it via:
alternatives --display mta
My system has the options:
/usr/sbin/sendmail.postfix - priority 30
/usr/lib64/plesk-9.0/postfix-sendmail-wrapper - priority 90
which means that postfix-sendmail-wrapper was used. Once I set it to sendmail.postfix, I could send mails to root but unfortunately at least local delivery of emails is broken (from an email user to an email user, not to unix user accounts) due to wrong access rights to the executables. When the server is not in frequent use, I'll try to fix them.

Anyway, I guess the plesk supplied postfix-sendmail-wrapper is indeed doing some wonky stuff and rejecting valid mails. I will try to gain further insight what the problem is.

 

[DanCermak]

I have spent some time trying to debug postfix-sendmail-wrapper to gain further insight what is actually happening. And to be frankly honest, I believe this is actually a bug in this executable. Let me elaborate: I have run the two commands:
fail_cmd: echo -e "To: root\nFrom: test\nSubject: Test\n\nTest" | sendmail -t
and
success_cmd: echo -e "To: root\nFrom: test\nSubject: Test\nTest" | sendmail -t
with strace and monitored the output. Unsurprisingly both cases are fairly similar in the beginning and at some point the program executes the quota checker. The command with two \n (fail_cmd) produces this call:
[pid 16615] execve("/usr/local/psa/handlers/hooks/check-quota", ["/usr/local/psa/handlers/hooks/check-quota", "none", "[email protected]", "root"], [/* 8 vars */]) = 0
and success_cmd leads to:
[pid 16238] execve("/usr/local/psa/handlers/hooks/check-quota", ["/usr/local/psa/handlers/hooks/check-quota", "none", "[email protected]"], [/* 8 vars */]) = 0
Please note the missing third parameter to check-quota in the success case. This is not the cause for the failure of the first sendmail command, since that check-quota call actually exits successfully, whereas the second one (from the successful command!) produces an error, since the third parameter is missing. I guess this might be a bug.
The sendmail wrapper then clones & opens in both cases the sqlite3 database from /var/lib/plesk/mail/handlers/handlers.db . In the success case the process exits with 0 and in the unsuccessful with 31. Unfortunately that's all I can find out using strace without actually debugging & disassembling the binary.

Anyway, I believe that there is probably some bug in the parsing of the email headers that results in this behavior. I could actually very well imagine, that the successful invocation of sendmail is the buggy case, as the check-quota call is wrong (the recipient parameter is missing) and maybe it somehow succeeds.

Could a plesk employee please take a look at this? There is little I can do without the source of postfix-sendmail-wrapper.

 

[IgorG]

I confirm this bug. It is already submitted to developers as PPP-27696.
Thank you for report!

 

[DanCermak]

Thanks for the confirmation. Do you have an ETA for a fix?

 

[IgorG]

Do you have an ETA for a fix?

Sorry, no any ETA.

 

[UFHH01]

Hi DanCermak,

Thanks for the confirmation. Do you have an ETA for a fix?

For your information: The bug with the issue "PPP-27696" has now being fixed with the latest Plesk Onyx 17.5.3 Update 23. ( You might know, that we fix bugs first within the latest, currently stable versions, while other versions might follow )