Plesk 11.5.30 bug - courier-imap module "authpsa"

[carragom]

Hello,

I'm hitting this issue too. I'll try to summarize what I think it's happening, please let me know if you disagree.

* With the correct user/password everything works fine.
* If the user does not exists at all, you get a "Login Failed" error. As expected.
* If the user exists and you try to log in an incorrect password the returned error from courier is NOT "Login Failed" as expected. But a temporary server error.
* This incorrect error causes some email clients to get confused and do all kinds of crazy things (Horde) or handle it more nicely (Roundcube) which displays the following error "Connection to storage server failed.".
* This incorrect error WILL confuse the user for sure. The end user should get a nice "Login Failed" message instead of "There is something broken with the server, no idea what" message.
* This problem is caused by the authpsa module, this module is doing it's job but it's not correctly communicating the result back to the courier-authdaemon and so the daemon response is not accurate.
* This should be fixed ASAP.

At the end if this page http://www.courier-mta.org/authlib/README.authdebug.html there is some scarce docs about the process.

My plesk version:
Parallels Plesk Panel v11.5.30_build115130819.13 os_CentOS 6

Error log with DEBUG=2, credentials and names have been modified:
Feb 18 12:09:52 myserver courier-pop3d: Connection, ip=[::ffff:127.0.0.1]
Feb 18 12:09:56 myserver courier-authdaemon: received auth request, service=pop3, authtype=login
Feb 18 12:09:56 myserver courier-authdaemon: authpsa: trying this module
Feb 18 12:09:56 myserver courier-authdaemon: authpsa: authentication request with service='pop3' authtype='login' authdata='[email protected].'
Feb 18 12:09:56 myserver courier-authdaemon: authpsa: auth_psa_common(user='[email protected]', pass='123')
Feb 18 12:09:56 myserver courier-authdaemon: authpsa: password for '[email protected]' is plain '123456'
Feb 18 12:09:56 myserver courier-authdaemon: authpsa: password for account '[email protected]' is wrong
Feb 18 12:09:56 myserver courier-authdaemon: authpsa: sysusername=popuser, sysuserid=110, sysgroupid=31, homedir=<null>, address=<null>, fullname=<null>, maildir=<null>, quota=<null>, options=<null>
Feb 18 12:09:56 myserver courier-authdaemon: authpsa: clearpasswd=<null>, passwd=<null>
Feb 18 12:09:56 myserver courier-authdaemon: authpsa: TEMPFAIL - no more modules will be tried
Feb 18 12:09:56 myserver courier-pop3d: LOGIN FAILED, [email protected], ip=[::ffff:127.0.0.1]
Feb 18 12:09:56 myserver courier-pop3d: authentication error: Input/output error

 

[JuliusT]

I want to stress that indeed something is really very wrong with the way plesk handles courier-auth with postfix, and the way it logs errors.
My logs are full of
plesk courier-authdaemon: authpsa: short mail addresses are not allowed, got 'xxx'
Mar 5 14:45:59 plesk courier-imapd: authentication error: Input/output error
ever since I switched to postfix last night.

This is so NOT good. Please, parallels, do your homework next time you brag about it being fine to switch MTA's. It's a mess.

 

[Nikolay.]

This is so NOT good. Please, parallels, do your homework next time you brag about it being fine to switch MTA's. It's a mess.

It's fine. It's not fine to allow usage of short email addresses (without the domain part), more so not notifying your users to switch to full addresses beforehand.

 

[JuliusT]

It's fine. It's not fine to allow usage of short email addresses (without the domain part), more so not notifying your users to switch to full addresses beforehand.

It would be fine if Parallels would inform us about such beforehand, which it did not do. It's nowhere to be read, in fact, regarding the switching of MTA.
I'd be fine with it changing to not allowing usernames as login without the @domain part, but honestly, for most server software I work with it is exactly the other way around; It will not accept [email protected] as a valid login.
Not to mention the fact that I only asked for it to change MTA, not update any of the config. If I had free time left, I'd be fine with such arrogant updating and upgrading, without informing or warning the admins no less(!), but I have no free time left.

Stop defending bad practices like that. It looks dumb.

Besides, if this would be the only error after changing MTA from qmail to postfix, but oooh no; I ended up seeing a really large queue of deferred messages (about 200) in just one day. Then I found that this was in the logs as well:

Mar 6 00:12:05 plesk postfix/smtp[5269]: connect to mx.ym.163.com[123.58.178.105]:25: Connection timed out
Mar 6 00:12:05 plesk postfix/smtp[5270]: connect to mail.jult.net[91.228.53.46]:25: Connection timed out
Mar 6 00:12:05 plesk postfix/smtp[5271]: connect to mx3.planet-work.com[79.99.164.17]:25: Connection timed out
Mar 6 00:12:05 plesk postfix/smtp[5271]: connect to mx2.planet-work.com[2a01:648::44]:25: Network is unreachable
Mar 6 00:12:05 plesk postfix/smtp[5271]: connect to mx3.planet-work.com[2a01:648::17]:25: Network is unreachable

Which is totally mind-boggling. Telnet to the same addresses and ports works fine. Ping works, DNS resolves just fine. What on earth is all this?

After researching I also found that for some reason /etc/xinetd/smtp.psa and smtps.psa were with dots instead of underscores, which they should be.
After changing that config, a lot, but still not all, messages suddenly got sent out.

I think Parallels has some serious educating to do regarding postfix config. It's just not working.
I'm reverting to qmail, hoping it will all work again (probably not, seeing that they've decided to upgrade stuff for me as well with the MTA-switch script, while I never asked for that in the first place).

And let's hope it allows short mail names again, because nope, I'm sure as heck not going to ask all those (by now) really pissed off users to change their mail-client config because psa wants them to.

 

[Thomas-ReinerR]

I Have a same problem...After upgrade in 11.5.3 Do you have a solution ?
courier-imaps: LOGIN FAILED, method=PLAIN

1 mail in 2 computer with the exactly same configuration. 1 computer work ( no problem) and the another failed... And i have the same log on the top !