After mu#23 - plesk sendmail[]: Trying to resolve the e-mail alias:

[Qball]

TITLE:

After mu#23 - plesk sendmail[]: Trying to resolve the e-mail alias:​

PRODUCT, VERSION, OPERATING SYSTEM, ARCHITECTURE:

Plesk Onyx 17.5.3 update #23, CentOS Linux 7.3.1611 (Core)‬, XEN VPS​

PROBLEM DESCRIPTION:

Getting the following type of error reported by cron:

plesk sendmail[14291]: Trying to resolve the e-mail alias: exampleuser
postalias: option requires an argument -- 'q'
postalias: fatal: usage: postalias [-Nfinoprsvw] [-c config_dir] [-d key] [-q key] [map_type:]file...

Also seeing the following in /var/log/messages:

Sep 26 12:45:38 vm crond: plesk sendmail[16306]: Trying to resolve the e-mail alias: exampleuser
Sep 26 12:45:38 vm crond: postalias: option requires an argument -- 'q'
Sep 26 12:45:38 vm crond: postalias: fatal: usage: postalias [-Nfinoprsvw] [-c config_dir] [-d key] [-q key] [map_type:]file...​

STEPS TO REPRODUCE:

[root@server ~]# echo "this is the body" | mail -s "this is the subject" "[email protected]"
[root@server ~]# plesk sendmail[17485]: Trying to resolve the e-mail alias: root
plesk sendmail[17485]: The e-mail alias was resolved to: [email protected]​

ACTUAL RESULT:

mail sent with no errors​

EXPECTED RESULT:

mail is sent by errors are produced to console / terminal​

ANY ADDITIONAL INFORMATION:

This only occurred after mu#23, and is now happening with all servers as they automatically install mu#23. Every cron run triggers an error​

YOUR EXPECTATIONS FROM PLESK SERVICE TEAM:

Help with sorting out​

 

[IgorG]

Thank you for report. Bug was confirmed and submitted as PPPM-7138
As a workaround – specify fully qualified mail names when sending mail via sendmail.

 

[H9k]

I can confirm this problem is also present on Ubuntu 16.04

 

[Linulex]

same on
centos 6.9
plesk 17.5.3 mu 23
selinulex = off
mta = qmail.

error:
plesk sendmail[22841]: Trying to resolve the e-mail alias: root
fork_execv: execv("/usr/sbin/postalias") failed: No such file or directory
fork_execv: execv("/usr/sbin/postalias") failed: No such file or directory

reproduce:
mail -s "`uname -n`" [email protected]

working workaround:
add
>/dev/null 2>&1

to the end

regards
Jan

 

[IgorG]

regards
Jan

Thank you! Forwarded to developers as the separate report.

 

[Ruben]

PHP mail() is also affected, causing most mail forms, PHP cronjobs etc to throw the same errors.
I wonder if there's an easy workaround for this as well?

 

[dahamsta]

Thank you for report. Bug was confirmed and submitted as PPPM-7138
As a workaround – specify fully qualified mail names when sending mail via sendmail.

Any workaround for cron? The cron jobs automatically run with the relevant user, it isn't possible to specify an address.

 

[Linulex]

Any workaround for cron?

add
>/dev/null 2>&1
to the end of the cron, all output will be send to /dev/null including errors

please check first of there is enough room in /dev/null

regards
Jan

 

[SacAutos]

I've got automated processes written in PHP that aren't sending any email messages at all at the moment. Which is a major component of the service I'm trying to provide. I hope that this gets resolved quickly. CentOS 6.9, MTA of Postfix using Plesk 17.5.3...

 

[G J Piper]

I have a cron job that emails the results of a script to me each day that was affected by this. (I'd get a second email with the "Trying to resolve the e-mail" error message in it)

I resolved it by moving the MAILTO="" to the very top of the crontab (above my entries). Maybe that is just masking the symptom though.

 

[Matthl]

Similar or same issue here since update #23.
Logwatch is setup to mail me the results and since #23 a second mail states:

Cron test -x /usr/sbin/anacron || ( cd / && run-parts --report /etc/cron.daily )

/etc/cron.daily/00logwatch:
plesk sendmail[27186]: Trying to resolve the e-mail alias: root
plesk sendmail[27186]: The e-mail alias was resolved to: placeholder@adress.com

Running on Debian 8.9.

 

[Bitpalast]

Confirmed on our hosts, too. CentOS 7.1, 7.2 and 7.4.

 

[SacAutos]

Thank you for report. Bug was confirmed and submitted as PPPM-7138
As a workaround – specify fully qualified mail names when sending mail via sendmail.

This is still a big problem for us. Any guidance on a work-around for mail verb within PHP? The target of the email messages is already a fully qualified email address.

 

[UFHH01]

Pls. expect a bug - fix within the next upcoming Plesk updates.

Plesk updates/upgrades/patches are ( mostly ) scheduled to be published on mondays, while Plesk extensions updates/upgrades/patches are ( mostly ) scheduled to be published on thursdays. Only in case of security issues, updates/upgrades/patches could be published as some kind of "emergency" update/upgrade/patch immediately after a fix is available.

 

[SacAutos]

That's good news. Thank you. While some might feel this bug was an annoying inconvenience, it has been a real issue for us. The sooner it gets fixed the better.

 

[UFHH01]

Hi @ all,

as you can see at => Change Log for Plesk , the issue with the confirmed bug PPPM-7138 , has been fixed with the today updates/upgrade: Plesk Onyx 17.5.3 Update 24

Plesk used a Postfix-specific version of sendmail-wrapper, which resulted in cron tasks failing due to non-empty output of plesk sendmail command. (PPPM-7138, PPPM-7148)

Pls. inform us with an additional post, if you experience further issues/errors/problems as decribed by the thread starter.

 

[Ian Collier]

I have just updated to Plesk Onyx 17.5.3 Update 24 and I am still experiencing the same issue when I use a php script to send a number of emails (it appears any number above 50). I get an Internal 500 error in the web browser. This has only started to happen after installing Update 23. When this occurs, I get the following in the apache error log several times:

[Tue Oct 03 08:45:22.560472 2017] [fcgid:warn] [pid 16108] mod_fcgid: process 40931 graceful kill fail, sending SIGKILL
plesk sendmail[42060]: Trying to resolve the e-mail alias: <<name in here>>
postalias: option requires an argument -- 'q'

 

[Wiz]

Following on from my earlier post here Issue - After mu#23 - plesk sendmail[]: Trying to resolve the e-mail alias: and after mu#24, it still appears the sendmail-wrapper is attempting to resolve system users (process owners) that are piping mail into sendmail when it should only resolve system users and/or email aliases to whom the mail is being sent to unless the developers at Plesk were trying to tighten down the security around the wrapper. If that is the case, they then need to revisit their approach.

In my case, I was piping mail into sendmail from spamc as I was using additional content filters in postfix/master.cf which relied on piping mail traffic into sendmail ... A permanent fix for my particular setup was to use spamass-milter, specifically with '-u -x' flags before sendmail-wrapper which resolved the issue introduced with the new feature/capability in mu#23.

 

[Ian Collier]

I am still having issues with this.

My code has not changed. only plesk since Update 23. There have been no other changes and the production php scripts to send multiple emails has been running for several months without issue.

As you can see form the attached screenshot I have updated to 24. When I run my test script, or when the production scripts run, to send out more than around 50 emails we still experience the same issue. This has only started happening since Update 23.

Here is a sample of the log entry in the apache2 error log.

[Tue Oct 03 08:45:22.560472 2017] [fcgid:warn] [pid 16108] mod_fcgid: process 40931 graceful kill fail, sending SIGKILL
plesk sendmail[42060]: Trying to resolve the e-mail alias: <<name in here>>
postalias: option requires an argument -- 'q'

Plesk version:

Product version: Plesk Onyx 17.5.3 Update #24
Update date: 2017/10/03 08:16
Build date: 2017/03/17 16:00
OS version: Ubuntu 14.04
Revision: 55d1b49a272f44666e1920eca8b6e4da449a38cd
Architecture: 64-bit
Wrapper version: 1.2

 

[IgorG]

When I run my test script,

Well. Could you please provide us detailed step-by-step instruction how this issue may be reproduced by our developers on Plesk server with MU#24 installed?
Thanks.