• If you are still using CentOS 7.9, it's time to convert to Alma 8 with the free centos2alma tool by Plesk or Plesk Migrator. Please let us know your experiences or concerns in this thread:
    CentOS2Alma discussion

Email problems after 8.4.0 update

This is what i did. I upgraded to Plesk 8.4 (Fedora Core is the OS) and was getting the

"553 sorry, that domain isn't in my list of allowed rcpthosts (#5.7.1)" error in Outlook...Everyone was.

Everything was working fine up until the upgrade, so I knew there was an authentication issue somewhere.

I went to /etc/xinetd.d/smtp_psa and verified this:
"env = SMTPAUTH=1 SHORTNAMES=1"

I remembered that I created a smtp_psa_alt file for my alternate port. Inside that file, I looked for the following:
"env = SMTPAUTH=1 SHORTNAMES=1"
But it WAS NOT there. So I added it under "instances = UNLIMITED"

Restarted xinetd.d and I can send without the error. Nothing in Outlook or Plesk was changed except that file.

I assume that if you change the Relay options the ALT file will not update itself. This "env" must be new to this file??

Nonetheless, I hope this works for someone out there.

To update:
I found out later that clients somehow stopped getting mail as the email would bounce back the the sender would get a 553 error. I used this command and all is working now.

/usr/local/psa/admin/bin/mchk --with-spam

Hopefully all these problems will stop.
 
Let's get this problem fixed properly.

Excuse me. Please do not try to fix the issue by tools from previous Plesk versions - this is a risk.

I agree and stated that my fix was a "hack". But without any developers around, what else can we do? On Ubuntu 7.10, the upgrade to 8.4 left all my users unable to access their email via Pop and IMAP. Since this problem has been ongoing and I didn't have a clear solution I had to do something before my paying clients decided to go elsewhere.

For my server, it was clear that that my cdb file did not contain ANY password information. (I used the cdbdump tool to verify this). I tried all of the suggestions listed in this thread but none of them worked for me. So I decided to install the 8.3 version of mchk and when I ran it, it generated the poppasswd file with the password information.

Unfortunately, the cdb file still didnt have password information in it. I suspect the 8.4 version of authpsa was coded to use passwords stored in the cdb file rather than poppasswd. So I installed the 8.3 version of authpsa and my users could start accessing their mail again.

So, if I had to guess, I would imagine that one of the 8.4 deb files for Ubuntu 7.10 did not get built with the proper library. I cannot allow access to my system if someone from Plesk wants to debug, but I am more than willing to provide information and feedback.
 
8.4.0 update now available

I have been having the same problems with POP and Horde webmail access all last week. Today the update is once again available and this time the update worked. All email pop and webmail are now working.
 
I try all tips but mails not worked. not worked. not workd!!!!!!!!!!!!!
 
Yes!

This did the trick, I have an alternative port too, and in the smtp_psa file the "env =" wasn´t there.

Thanks man!

(Using Red Hat PSA 8.4)


This is what i did. I upgraded to Plesk 8.4 (Fedora Core is the OS) and was getting the

"553 sorry, that domain isn't in my list of allowed rcpthosts (#5.7.1)" error in Outlook...Everyone was.

Everything was working fine up until the upgrade, so I knew there was an authentication issue somewhere.

I went to /etc/xinetd.d/smtp_psa and verified this:
"env = SMTPAUTH=1 SHORTNAMES=1"

I remembered that I created a smtp_psa_alt file for my alternate port. Inside that file, I looked for the following:
"env = SMTPAUTH=1 SHORTNAMES=1"
But it WAS NOT there. So I added it under "instances = UNLIMITED"

Restarted xinetd.d and I can send without the error. Nothing in Outlook or Plesk was changed except that file.

I assume that if you change the Relay options the ALT file will not update itself. This "env" must be new to this file??

Nonetheless, I hope this works for someone out there.

To update:
I found out later that clients somehow stopped getting mail as the email would bounce back the the sender would get a 553 error. I used this command and all is working now.

/usr/local/psa/admin/bin/mchk --with-spam

Hopefully all these problems will stop.
 
Where do we get the packages to re-install

Sirs,

There are several problems and solutions mixed in this thread.
Let's try to summarize them to a sequence of steps and hope that it will be helpful for the majority.

1) reinstall psa-qmail and courier-imap (psa-courier-imap) packages. I mean exactly packages from Plesk 8.4.0 distribution. Do not try to use packages from previous Plesk versions.

2) run /usr/local/psa/admin/sbin/mail_auth_dump utility

3) If you use authorization as a relay option:
In CP go to Server->Mail page. set "relaying" = closed. Click "OK" button. After that go to the page again, set desired authorization options and click OK button.

4) If you use "short names", check that there is a "SHORTNAMES=1" line in your /etc/courier-imap/imapd, imapd-ssl, pop3d, pop3d-ssl files. If it's missing, add it to the end of each file and restart courier-imap service.

5) run /usr/local/psa/admin/sbin/mchk -v

Where do we get these packages to re-install????
 
ReDirect is the error source in 8.4

It appears that the error is in the email boxes using redirect or groups with an email address that uses domain keys, such as Google or Yahoo - they are rejecting the keys and sending back a response which generates another redirect, etc.
 
I still cant use shortnames for sending email, but short is ok for incoming. So smtp has issues accepting short login names despite the /etc/xinet.d/ files have the short in them :(
 
Just tried that mail_fix...

root@els:~# sh mail_fix.sh
root@els:~#

Nothing happens... still with problem
 
the script lauches mchk in daemon mode, probably it is worth waiting for a little bit, check whether mchk is running with "ps aux".
 
the script lauches mchk in daemon mode, probably it is worth waiting for a little bit, check whether mchk is running with "ps aux".

After i run the script and do a "top" i see sometimes apear the 'mchk' command, but now that i believe its finished my problem with the mail remains... :|
 
Hi Monica,

I applied the patch and certainly sending email using IMAPS on my iphone I get failed authentication if I use short name for sending.

If I change sending back to full name I can send mail.

Incoming mail is still fine using short.

Thanks!

(PS I did restart both qmail and imap)
 
No problems I just wanted to provide some feedback. I look forward to the fix once it comes.

I assume this existing hotfix is not a problem and wont inevitably break something?

Just thinking aloud, people having this short name on sending and it wont work, are you also using domainkeys on sending email? I am.

Thanks!
 
Hey I found the FIX and thought I would share..

look at:

/etc/xinet.d/submission_psa

I found mine was missing SHORTNAMES=1

I edited it restarted xinetd (/etc/init.d/xinetd restart) and it works shortnames..

So plesk needs a hotfix to properly set shortnames=1 inside the submission_psa

I also noticed if I just say OK in the plesk gui toi the mail options, only smtp_psa and smtps_psa get the timestamp changed, submission_psa is not written to at all.

I also ticked off submission, then OK and then set back to on and OK. All I see is the filename gets renamed, but the timsstamp and contents do not get modified.

So there is a bug in plesk not generating the submission_psa on any mail changes!
 
Many Many Maillog errors

Hello all.
See the hotfix for mail issues after upgrade:
http://kb.odin.com/en/5256

There is way more happening with this upgrade than covered by the hotfix. Here are my logs:

May 13 06:20:51 ip-208-109-248-176 qmail: 1210674051.768310 status: local 0/10 r emote 9/20
May 13 06:20:51 ip-208-109-248-176 qmail: 1210674051.768346 delivery 3651: failu re: 64.202.189.86_failed_after_I_sent_the_message./Remote_host_said:_554_Message _refused./
May 13 06:20:51 ip-208-109-248-176 qmail: 1210674051.768377 status: local 0/10 r emote 8/20
May 13 06:20:51 ip-208-109-248-176 qmail: 1210674051.768408 new msg 9670400
May 13 06:20:51 ip-208-109-248-176 qmail: 1210674051.768439 info msg 9670400: by tes 3060 from <> qp 25913 uid 2522
May 13 06:20:52 ip-208-109-248-176 qmail: 1210674052.173833 starting delivery 36 52: msg 9670809 to remote [email protected]
May 13 06:20:52 ip-208-109-248-176 qmail: 1210674052.173918 status: local 0/10 r emote 9/20
May 13 06:20:52 ip-208-109-248-176 qmail-queue[26188]: mail: all addreses are un checkable - need to skip scanning (by deny mode)
May 13 06:20:52 ip-208-109-248-176 qmail-queue[26188]: scan: the message(drweb.t mp.wdZLeg) sent by #@[] to [email protected] sho uld be passed without checks, because contains uncheckable addresses
May 13 06:20:54 ip-208-109-248-176 qmail-queue-handlers[26189]: Handlers Filter before-queue for qmail started ...
[root@ip-208-109-248-176 ~]# tail /usr/local/psa/var/log/maillog
May 13 06:21:42 ip-208-109-248-176 qmail-queue[26438]: mail: all addreses are uncheckable - need to skip scanning (by deny mode)
May 13 06:21:42 ip-208-109-248-176 qmail-queue[26438]: scan: the message(drweb.tmp.XW8rIh) sent by to [email protected] should be passed without checks, because contains uncheckable addresses
May 13 06:21:42 ip-208-109-248-176 qmail-queue-handlers[26443]: Handlers Filter before-queue for qmail started ...
May 13 06:21:42 ip-208-109-248-176 qmail-local-handlers[26439]: [email protected]
May 13 06:21:42 ip-208-109-248-176 qmail-local-handlers[26439]: [email protected]
May 13 06:21:42 ip-208-109-248-176 qmail-queue-handlers[26443]: from=
May 13 06:21:42 ip-208-109-248-176 qmail-queue-handlers[26443]: [email protected]
May 13 06:21:42 ip-208-109-248-176 qmail-queue-handlers[26443]: hook_dir = '/var/qmail//handlers/before-queue'
May 13 06:21:42 ip-208-109-248-176 qmail-queue-handlers[26443]: recipient[3] = '[email protected]'
May 13 06:21:42 ip-208-109-248-176 qmail-queue-handlers[26443]: handlers dir = '/var/qmail//handlers/before-queue/recipient/[email protected]'
 
New changes on the KB adding:

If it does not help and you get "no such user" error in /usr/local/psa/var/log/maillog, for example during IMAP connections, make sure that all Plesk packages were upgraded to the Plesk 8.4 build (build84080*). Because Plesk 8.4 uses new optimized mail authorization mechanism that may not work with the old packages. On RPM based OSes you can check it with the command like:
# rpm -qa | grep psa | grep -v 840

Didn't work for me. (System Ubuntu 7.10)... keep losing clients... lost 3 clients already. :|
 
I can help you with this issue
My resume: http://www.odesk.com/users/~~9625e914c41aa8a5

!!! for all that have CentOS !!!!!!!!!!!
step 1: check installed rpm after plesk update
rpm -qa | grep psa | grep qmail

psa-qmail-rblsmtpd-0.70-cos4.build84080425.21
psa-qmail-1.03-cos4.build84080425.21

if you have other output than myne download new rpms from official site

STEPT 2:
you have to install this psa-qmail-1.03-cos4.build84080425.21.i586.rpm
and this psa-qmail-rblsmtpd-0.70-cos4.build84080425.21.i586.rpm

rpm -U psa-qmail-rblsmtpd-0.70-cos4.build84080425.21.i586.rpm #update
rpm -U psa-qmail-rblsmtpd-0.70-cos4.build84080425.21.i586.rpm #update rbl

if you het message that you have the latest version but it's not true uninstall previous version

rpm -e --nodeps your_previous_version
also with rbl
and install the new one
rpm -i psa-qmail-rblsmtpd-0.70-cos4.build84080425.21.i586.rpm
also with rbl RPM

STEP 3:
after that edit /etc/xinetd.dsmtp_psa

service smtp
{
socket_type = stream
protocol = tcp
wait = no
disable = no
user = root
instances = UNLIMITED
env = SMTPAUTH=1 SHORTNAMES=1
server = /var/qmail/bin/tcp-env
server_args = -Rt0 /var/qmail/bin/relaylock /var/qmail/bin/qmail-smtpd /var/qmail/bin/smtp_auth /var/qmail/bin/true /var/qmail/bin/cmd5checkpw /var/qmail/bin/true
}

STEP 4:
restart qmail, restart courier-imap
and have fun :)
 
Back
Top