Plesk 10.4.4: External emails not receiving @ mailserver

[burnleyvic]

On all the three affected servers:

md5sum /usr/lib64/plesk-9.0/psa-pc-remote
c318fc5ec968e56e4aec9c618ff64029 /usr/lib64/plesk-9.0/psa-pc-remote

ls -l /usr/lib64/plesk-9.0/psa-pc-remote
-r-xr-s--- 1 postfix popuser 131601 Jan 19 10:08 /usr/lib64/plesk-9.0/psa-pc-remote
(dates are different across the servers, though)

cat /root/.autoinstaller/microupdates.xml
<?xml version="1.0" encoding="UTF-8" standalone="yes" ?>
<patches>
<product id="sitebuilder" version="4.5.0" installed-at="not-a-date-time">
<patch version="1" timestamp="" installed-at="not-a-date-time" />
</product>
<product id="plesk" version="10.4.4" installed-at="20120201T202324">
<patch version="15" timestamp="" installed-at="20120201T202944" />
</product>
</patches>

Load average: no idea, but the collected alerts and graphs didn't look different with/without psa-pc-remote

/usr/local/psa/var/log/maillog - now this is becoming interesting. I had a look at all "Message aborted" entries and it seems that each "Message aborted" log entry is:
- preceded by a Postfix message informing that the current SMTP connection was terminated during the initial SMTP conversation, before DATA. The reason for this is e.g.: " postfix/smtpd[15834]: NOQUEUE: reject: RCPT from unknown[xxx.xxx.xxx.xxx]: 550 5.1.1 <[email protected]>: Recipient address rejected: User unknown in virtual mailbox table"
- logged twice for the terminated SMTP connection.
So, in fact this "Message aborted" message might be perfectly legitimate.
However, the actual problem was that Plesk's milter psa-pc-remote was not sending the email to spamassassin for scanning, spamd was not logging anything and no specific headers were attached to the delivered email while psa-pc-remote milter was active.

 

[IgorG]

If I correctly understood you want that spamassassin works on before-queue stage. But during smtp session spamassassin is not working in Plesk. It is set in the before-local.

 

[burnleyvic]

No Igor, there's a bit of a misunderstanding. I can't ask for Spamassassin to work before the SMTP client sends CR-LF-dot-CR-LF, it'd be a nonsense, since it needs the entire message to do its scanning job What I described was a behaviour seen after upgrading to 10.4.4 when now Postfix gets antispam integration using a milter as opposed to the previous smtpd content filter. I might have been misled in my assumptions by:
- these "Message aborted" entries, which seem to be caused by Postfix closing the milter connection if the message is deemed as undeliverable before DATA
- the fact that, after the upgrade to psa-pc-remote, spamd stopped logging its activity even if the mails were flowing through. It started sending log messages as soon as I reconfigured Postfix to use spamass-milter.
I'll have to find a good time to run some tests on one of the affected machines to confirm whether, in my case, it was just a false alarm or a genuine Plesk milter issue.

 

[burnleyvic]

Igor, I'm back: I was clearly misled by these "Message aborted" log entries, spamd is actually scanning the emails for the users that have their spam filter activated in Plesk, so it's more of a non-issue in my case, sorry for the noise. Should have checked it more thoroughly before posting. It appears to work fine and we haven't had reports of undeliverables due to psa-pc-remote milter yet.
This being said, "Message aborted" entries should probably be reviewed for a future release, there's no point in logging the same message twice.

 

[IgorG]

burnleyvic,

Ok. In any case thank you for information and cooperation.

 

[MathijsT]

Still not working!!

I am on Panels Plesk 10.4.4 with MU#19 !!

I cannot send/receive email with postfix. Tried installing qmail isntead - also did not work (qq read error #430). Back to postfix and disabled the lines in main.cf as mentioned earlier. This finally works!



But the real fix is NOT MU#5. I am on MU19 and it is still not fixed.

md5sum /usr/lib64/plesk-9.0/psa-pc-remote
6413a4910b6c68e52cc1dc6a44cc03d7 /usr/lib64/plesk-9.0/psa-pc-remote

ls -l /usr/lib64/plesk-9.0/psa-pc-remote
-r-xr-s--- 1 postfix popuser 78426 2012-04-02 21:34 /usr/lib64/plesk-9.0/psa-pc-remote

cat /root/.autoinstaller/microupdates.xml
<?xml version="1.0" encoding="UTF-8" standalone="yes" ?>
<patches>
<product id="plesk" version="10.4.4" installed-at="20120402T201209">
<patch version="19" timestamp="" installed-at="20120402T201447" />
</product>
</patches>

 

[oasisf]

not receiving external emails

I have the same issue.
I have adjusted the milter settings in my /etc/postfix/main.cnf file as stated earlier in the thread. However my main.cnf did not have the milter_protocol = 6 line so I didn't bother adding it. Still not getting incoming emails. Outgoing emails seem to work alright.

#smtpd_milters = inet:localhost:12768
#non_smtpd_milters = inet:localhost:12768

# md5sum /usr/lib64/plesk-9.0/psa-pc-remote
c318fc5ec968e56e4aec9c618ff64029 /usr/lib64/plesk-9.0/psa-pc-remote
# ls -l /usr/lib64/plesk-9.0/psa-pc-remote
-r-xr-s--- 1 postfix popuser 131601 Apr 11 03:36 /usr/lib64/plesk-9.0/psa-pc-remote
# cat /root/.autoinstaller/microupdates.xml
<?xml version="1.0" encoding="UTF-8" standalone="yes" ?>
<patches>
<product id="plesk" version="10.4.4" installed-at="20120403T143038">
<patch version="24" timestamp="" installed-at="20120403T143038" />
</product>
</patches>


CentOs 5
OS Linux 2.6.18-028stab095.1
Panel version 10.4.4 Update #24, last updated at April 3, 2012 02:30 PM

maillog

Apr 11 04:25:15 postfix/smtpd[9423]: connect from smtp163.iad.emailsrvr.com[207.97.245.163]
Apr 11 04:25:15 postfix/smtpd[9423]: CF89DD500D7: client=smtp163.iad.emailsrvr.com[207.97.245.163]
Apr 11 04:25:15 /usr/lib64/plesk-9.0/psa-pc-remote[7424]: mkstemp(/usr/local/psa/handlers/spool/mlfi.XTICPq) failed: Permission denied
Apr 11 04:25:15 /usr/lib64/plesk-9.0/psa-pc-remote[7424]: Message aborted.
Apr 11 04:25:15 postfix/smtpd[9423]: CF89DD500D7: milter-reject: DATA from smtp163.iad.emailsrvr.com[207.97.245.163]: 451 4.7.1 Service unavailable - try again later; from=<[email protected]> to=<[email protected]> proto=ESMTP helo=<smtp163.iad.emailsrvr.com>
Apr 11 04:25:15 postfix/smtpd[9423]: disconnect from smtp163.iad.emailsrvr.com[207.97.245.163]

 

[oasisf]

MathijsT, did you ever find a solution?

 

[Dalowe]

I found this after about pulling my hair out ;O verfied all permissions and ownership against working version with same MU 28 patch level.

Check permissions on /usr/local/psa/handlers directory

It was set to this: 770 on my installation after update.

drwxrwx--- 8 root root 4096 Jan 25 22:36 handlers

Changed it to this : 755 originally what it was before update

drwxr-xr-x 8 root root 4096 Jan 25 22:36 handlers

Mail started to come in no write error

psa-pc-remote[xxxxx]: mkstemp(/usr/local/psa/handlers/spool/xxx.XXXXXX) failed: Permission denied

 

[jpameli]

I found this after about pulling my hair out ;O verfied all permissions and ownership against working version with same MU 28 patch level.

Check permissions on /usr/local/psa/handlers directory

It was set to this: 770 on my installation after update.

drwxrwx--- 8 root root 4096 Jan 25 22:36 handlers

Changed it to this : 755 originally what it was before update

drwxr-xr-x 8 root root 4096 Jan 25 22:36 handlers

Mail started to come in no write error

psa-pc-remote[xxxxx]: mkstemp(/usr/local/psa/handlers/spool/xxx.XXXXXX) failed: Permission denied

YOU ARE THE BEST!
This also fixed my postfix..
I used the autoinstaller on a fresh CentOS5 system and needed to install PHP 5.3.
Afterwards I wanted to configure my mailboxes but also got 4.7.1 error message..

I only changed the rights to 755 of /usr/local/psa/handlers and boom everything worked (so far)

Thank you!

 

[SteveWroblewski]

Hi,

I received a new dedicated server with 10.2 installed and after upgrade to 10.4.4 could not receive mail - the same blocked milter lines were in my mail log.

After reading this thread I edited out the lines in main.cf as below:

#smtpd_milters = inet:localhost:12768
#non_smtpd_milters = inet:localhost:12768

and rebooted the server

All works fine after subsequent reboots and more domains added

My vital stats are:

OS Linux 2.6.32-220.17.1.el6.x86_64
Panel version 10.4.4 Update #35, last updated at June 8, 2012 03:33 PM

So, it looks like the bug is still there as at Update #35

Anyway, thanks for the great forum that helped me find and fix this quickly

Kind regards

Steve

 

[stefanos]

This struck me today. Commenting out the 3 lines in main.cf did the trick for me, but obviously is not an optimal solution

 

[euphbasio]

Any solution for this yet? I'm on 11.0.9 and this hit after installation of MU#6.

 

[euphbasio]

If anyone is having this issue (it just popped up for me on 3 machines after MU#6 on 11.0.9. It is caused by permission conflicts between the pc-remote user (default postfix) and read write permissions on mail handlers.

 

[stefanos]

If anyone is having this issue (it just popped up for me on 3 machines after MU#6 on 11.0.9. It is caused by permission conflicts between the pc-remote user (default postfix) and read write permissions on mail handlers.

Could you please more specific. What permissions exactly have to be changed to fix this?

 

[HanZim]

When will this issue be addressed? This thread is now more than 6 months old. Plenty of time to fix the core of the problem. I have set up a vanilla Ubuntu 12.04 LTS and used the one click installer to install Plesk 11. After the installation it was not possible to send any mails.

echo "test mail" | mail -s "test subject" [email protected]

As a workaround I have disabled the milter filter by modifying /etc/postfix/main.cf

#smtpd_milters = , inet:localhost:12768
#non_smtpd_milters = , inet:localhost:12768

Mail is now working but this is not a permanent solution.

 

[JustinCH]

Still seeing this issue.

I'm still seeing this issue, we use the band-aid and disable milter in main.cf but when ever a change is made on the server, those settings get over written. We are using the latest version of Plesk10.4.4




<?xml version="1.0" encoding="UTF-8" standalone="yes" ?>
<patches>
<product id="plesk" version="10.4.4" installed-at="20120724T135446">
<patch version="41" timestamp="" installed-at="20120816T032057" />
</product>
</patches>

 

[ArnonW]

Thanks very much burnleyvic. I was able to get this working using your instructions on a Fedora machine with Plesk 9.5.4.

A few notes:

- This installation of postfix appears to be running chroot'ed to /var/spool/postfix, resulting in the following entries in maillog:

postfix/smtpd: warning: connect to Milter service unix:/var/run/spamass-milter/postfix/sock: No such file or directory
postfix/smtpd: NOQUEUE: milter-reject: CONNECT from unknown: 451 4.7.1 Service unavailable - try again later; proto=SMTP

I fixed this using:

>mkdir -p /var/spool/postfix/var/run/spamass-milter/postfix
>chown sa-milt:sa-milt /var/spool/postfix/var/run/spamass-milter
>chown sa-miltostfix /var/spool/postfix/var/run/spamass-milter/postfix

Set in postconf:

smtpd_milters = unix:/var/run/spamass-milter/postfix/sock
non_smtpd_milters = unix:/var/spool/postfix/var/run/spamass-milter/postfix/sock

And in /etc/sysconfig/spamass-milter:

SOCKET="/var/spool/postfix/var/run/spamass-milter/postfix/sock"

- While the content-filtering spamd uses user-based preferences and bayes databases (in .spamassassin directories), spamass-milter operates before the user directory is determined, and is hence based on a central database. The maillog contained the following entries:

spamd: plugin: eval failed: bayes: (in learn) locker: safe_lock: cannot create tmp lockfile /var/qmail/mailnames///.spamassassin/bayes.lock for /var/qmail/mailnames///.spamassassin/bayes.lock: 2

I fixed this using:

>mkdir /var/qmail/mailnames/.spamassassin
>chown popuseropuser /var/qmail/mailnames/.spamassassin

The milter works great now.

 

[vmonroigv]

We are experiencing something similar. Some messages bounce to postmaster without being delivered. In mail.log, these entries are shown:

Oct 16 12:35:10 kitt /usr/lib/plesk-9.0/psa-pc-remote[1436]: Message aborted.

But no earlier problem is visible in log, like spam filtering could be. This happens to only one address from hundreds in our server. We tried deleting and rebuilding, with no luck.

Workaround has been disabling milter in main.cf.

 

[IgorG]

http://kb.parallels.com/114982