Email problems after 8.4.0 update

[dzappone]

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

Made absolutely no difference for me. Seems like a reasonable summary of steps. Question: what exactly does mail_auth_dump do? When I use mail_auth_view (which I am guessing show's the same data that mail_auth_dump manipulates I get no results returned - in fact it looks like this:

+--------------------------------------+-----+--------------------------------------+
|             address                  |flags|               password               |
+--------------------------------------+-----+--------------------------------------+
+--------------------------------------+-----+--------------------------------------+
Flags
        A - account disabled
        D - domain disabled
        E - password encrypted

 

[105547111]

I have got problems with users trying to send mail. They have to use full names@domain not just short names.

This makes me think there is another set of files elsewhere for smtp, smtps, imap and imaps but for sending, as short works for incoming but not outgoing.

Any idea's where to look? Its not /etc/courier-imap as this is incoming.

 

[dash]

Made absolutely no difference for me. Seems like a reasonable summary of steps. Question: what exactly does mail_auth_dump do? When I use mail_auth_view (which I am guessing show's the same data that mail_auth_dump manipulates I get no results returned - in fact it looks like this:

+--------------------------------------+-----+--------------------------------------+
|             address                  |flags|               password               |
+--------------------------------------+-----+--------------------------------------+
+--------------------------------------+-----+--------------------------------------+
Flags
        A - account disabled
        D - domain disabled
        E - password encrypted

mail_auth_dump utility gets data about mail-users and passwords from mysql database and map it into the file(/var/lib/plesk/mail/auth/passwd.db), which is used by all plesk mail-auth utilities.
mail_auth_view allows to view auth-data from this file.
mail_auth_dump is called during upgrade. but maybe upgrade on your server was failed for some reason before this call.
Try to run mail_auth_dump and after that run mail_auth_view to check that auth-file was created successfully.

 

[dash]

I have got problems with users trying to send mail. They have to use full names@domain not just short names.

This makes me think there is another set of files elsewhere for smtp, smtps, imap and imaps but for sending, as short works for incoming but not outgoing.

Any idea's where to look? Its not /etc/courier-imap as this is incoming.

Is there env = SHORTNAMES=1 SMTPAUTH=1 line in your /etc/xinetd.d/smtp_psa, smtps_psa ?

 

[paco68]

I have got problems with users trying to send mail. They have to use full names@domain not just short names.

This makes me think there is another set of files elsewhere for smtp, smtps, imap and imaps but for sending, as short works for incoming but not outgoing.

Any idea's where to look? Its not /etc/courier-imap as this is incoming.

Restart your VPS or Server!

 

[dzappone]

Try to run mail_auth_dump and after that run mail_auth_view to check that auth-file was created successfully.

Cool, thanks for the info.

No it's not creating the auth file. It still shows the same empty table. Now how could that be failing and what file is is the auth file?

As a site note I do not (and I don't know if I should) have a /etc/xinetd.d/smtp_psa, smtps_psa file either.

 

[dash]

Cool, thanks for the info.

No it's not creating the auth file. It still shows the same empty table. Now how could that be failing and what file is is the auth file?

As a site note I do not (and I don't know if I should) have a /etc/xinetd.d/smtp_psa, smtps_psa file either.

What OS do you use?
Are there any errors during mail_auth_dump running in console?

 

[dzappone]

What OS do you use?
Are there any errors during mail_auth_dump running in console?

I've got:

Plesk Control Panel version: psa v8.4.0_build84080425.19 os_Ubuntu 7.10
Operating system: Linux 2.6.22-14-server

And no errors running mail_auth_dump in the console. In fact the timestamp of the files (assign, cdb, poppasswd) all seem to get updated but the contents don't change - file size remains the same - poppasswd is empty. The passwd.db seems to be updating just fine when changes are made to passwords.

It seems there is some sort of disconnect somewhere - but I have no idea.

Thanks for all the help and suggestions.

 

[105547111]

Is there env = SHORTNAMES=1 SMTPAUTH=1 line in your /etc/xinetd.d/smtp_psa, smtps_psa ?

Unfortunately YES

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

service smtps
{
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 /usr/sbin/rblsmtpd -r bl.spamcop.net -r sbl-xbl.spamhaus.org /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
}

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 /usr/sbin/rblsmtpd -r bl.spamcop.net -r sbl-xbl.spamhaus.org /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
}


only thing weird is submission has 1 space between fields on the env line the others have more than one???

 

[dzappone]

Clean Install - New System

I did a clean install on a new system twice - Ubuntu 7.10 and Plesk 8.4. It has the exact same problem. No email users can authenticate. I'd say there's a bug with 8.4 or the 8.4 install on at least Ubuntu 7.10 and probably some other distros as well.

 

[intelitech]

Got it fixed somehow.

This smtp auth issue was driving me crazy for the past several hours. The passwords would not get accepted as if they were wrong. Did all fixes described here to no avail. I got and untarred full 8.4 distribution package and force installed psa-qmail and spam-assasin and rblsmtpd, etc. Nothing worked. Then I noticed that "Real-time Blackhole List client for qmail" changed to "not up to date" in the autoupdater. Auto Installed it and issue got resolved. Don't know if it was new update from Parallels or I did unintentional reinstall of "Real-time Blackhole List client for qmail" or could be something else.

Hope this info helps someone.

Mike.
Intelitech.nu

 

[dash]

I've got:

Plesk Control Panel version: psa v8.4.0_build84080425.19 os_Ubuntu 7.10
Operating system: Linux 2.6.22-14-server

And no errors running mail_auth_dump in the console. In fact the timestamp of the files (assign, cdb, poppasswd) all seem to get updated but the contents don't change - file size remains the same - poppasswd is empty. The passwd.db seems to be updating just fine when changes are made to passwords.

It seems there is some sort of disconnect somewhere - but I have no idea.

Thanks for all the help and suggestions.

The passwd.db is the only significant file.
Reapply Mail options on Server->Mail page. I mean change it, press OK, after that set it again as necessary and press OK again.
Check you seperserver file:
If you use Debian or Ubuntu it's a /etc/inetd.conf
If you use rpm based systems it's /etc/xinet.d/smtp_psa, smtps_psa
You are interested in
SHORTNAMES=1, if you use shortnames
SMTPAUTH=1, if you use smtp auth
POPAUTH=1, if you use "smtp after pop"

Check /etc/courier-imap/imapd, imapd-ssl, pop3d, pop3d-ssl
You are interested in SHORTNAMES=1, if you use shortnames

RESTART ALL NECESSARY SERVICES:
/etc/init.d/psa restart

 

[jstapels]

Same problem Ubuntu 7.10

I'm having the same problem as many others. I upgraded to Ubuntu 7.10 and suddenly noone can authenticate to IMAP. I have tried many/all the steps outlined in this thread to no avail. I hope that Plesk takes a look at this problem quickly as my customers are very unhappy.

For the record, my poppasswd file is blank, but I know in past versions of plesk that it was not.

 

[jstapels]

UPDATE: I found that running the Plesk 8.3 version of mchk -v as well as restoring the 8.3 version of authpsa solved my problem. For those that don't have proper backups (like me!), I was able to extract the old versions using the 8.3 deb files found here: http://autoinstall.plesk.com/PSA_8.3.0/dist-deb-Ubuntu-7.10-i386/base/

the mchk tool is in the psa_8.3.0-ubuntu7.10.build83071218.20_i386.deb

the authpsa file is in the psa-courier-imap-add_8.3.0-ubuntu7.10.build83071218.20_i386.deb

This is clearly a hack. I only hope that the Plesk team resolves this issue quickly.

 

[dzappone]

The passwd.db is the only significant file.
Reapply Mail options on Server->Mail page. I mean change it, press OK, after that set it again as necessary and press OK again.
Check you seperserver file:
If you use Debian or Ubuntu it's a /etc/inetd.conf
If you use rpm based systems it's /etc/xinet.d/smtp_psa, smtps_psa
You are interested in
SHORTNAMES=1, if you use shortnames
SMTPAUTH=1, if you use smtp auth
POPAUTH=1, if you use "smtp after pop"

Check /etc/courier-imap/imapd, imapd-ssl, pop3d, pop3d-ssl
You are interested in SHORTNAMES=1, if you use shortnames

RESTART ALL NECESSARY SERVICES:
/etc/init.d/psa restart

Ok, having done all that it still is not working. I'm using Ubuntu 7.10. I've tried with shortnames and full. I've tried all authentication options. I've tried pop, pop w/ssl, imap and imap w/ssl.

The imapd, imapd-ssl, pop3d and pop3d-ssl file all have these lines at the end:


MAILDIRPATH=Maildir
AUTHMODULES="authpsa"
MAILPASSWD="/var/qmail/users/poppasswd"


The pop3d file also has this line - though if I comment it out it makes no difference.

POP3DHOSTNAME=localhost.localdomain

Leading me to think that the password file is /var/qmail/users/poppasswd which is empty and remains empty regardless of mail_auth_dump or mchk -v being run. It would seem based on those config settings that poppasswd is where authpsa is looking to authenticate passwords against. It's empty so it's failing is my thought - if the passwd.db is the only significant file then I'm not sure why pop3d points to poppasswd unless that's change and it should be pointing elsewhere. I'm pretty sure that the blank poppasswd is the root of this evil. I could be wrong but that's certainly what all signs point to.

Thanks again for the suggestions.

 

[dzappone]

UPDATE: I found that running the Plesk 8.3 version of mchk -v as well as restoring the 8.3 version of authpsa solved my problem. For those that don't have proper backups (like me!), I was able to extract the old versions using the 8.3 deb files found here: http://autoinstall.plesk.com/PSA_8.3.0/dist-deb-Ubuntu-7.10-i386/base/

the mchk tool is in the psa_8.3.0-ubuntu7.10.build83071218.20_i386.deb

the authpsa file is in the psa-courier-imap-add_8.3.0-ubuntu7.10.build83071218.20_i386.deb

This is clearly a hack. I only hope that the Plesk team resolves this issue quickly.

Thanks for the tip - I'll try it first thing tomorrow.

 

[sergius]

Thanks for the tip - I'll try it first thing tomorrow.

Hello dzappone,

Could you please post here about result tomorrow?

 

[sergius]

Hello dzappone,

Could you please post here about result tomorrow?

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

dzappone, could you send me PM w/ credentials for access to your problem server?

 

[DCoats]

Sergius, any Idea why with freebsd5.5 that the domainkeys being enabled for any domain would not allow any mail to be sent to the server from outside clients?
May 9 15:16:09 vortex qmail-remote-handlers[88732]: domainkeys-handler exited with status 31
May 9 15:16:09 vortex qmail-remote-handlers[88732]: call_handlers: stop call handlers because handler 'dd51-domainkeys' not PASS (31)
May 9 15:16:09 vortex qmail-remote-handlers[88732]: call_handlers: stop call handlers from dir '/usr/local/psa/qmail//handlers/before-remote/global'
May 9 15:16:09 vortex qmail: 1210360569.172809 delivery 713: failure: handlers_permanentfail/

Then ofcourse the mail bounces back with "handlers permanentfail"

 

[dzappone]

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

dzappone, could you send me PM w/ credentials for access to your problem server?

Have done so. I realize the risk of using tools from previous versions but if I cannot get this fixed by any other means I may have to do so. Please keep me appraised via PM of the status if possible. I have warned all my clients against making changes to their sites until further notice.

Thanks for the help.