Facebook
Twitter
-
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
11.0.9 - maildirsize quota header is corrupted
- Thread starter nevakee
- Start date
Switching to Postfix would not help you anyway.
Try to locate one of the offending mailboxes with something like '/usr/local/psa/admin/sbin/mailmng --get-mailbox-size --mailname <mailname> --domain-name <domain>' (written from the top of my head - consult with 'mailmng --help').
Then locate the Maildir++ quota file. It should be in something like /var/qmail/mailnames/<domain>/<mailname>/Maildir/maildirsizequota . Post it here for analysis (but don't copy & paste the content, instead just attach the file).
Try to locate one of the offending mailboxes with something like '/usr/local/psa/admin/sbin/mailmng --get-mailbox-size --mailname <mailname> --domain-name <domain>' (written from the top of my head - consult with 'mailmng --help').
Then locate the Maildir++ quota file. It should be in something like /var/qmail/mailnames/<domain>/<mailname>/Maildir/maildirsizequota . Post it here for analysis (but don't copy & paste the content, instead just attach the file).
Also, if you would be so kind, please run:
# /usr/lib64/plesk-9.0/mail_auth_dump; echo $?
Post the output here. Then look for any new messages in the mail log and post them here as well.
(Seems like this is not related to your problem, but I'm just curious what causes this fail in mchk. Thanks in advance.)
# /usr/lib64/plesk-9.0/mail_auth_dump; echo $?
Post the output here. Then look for any new messages in the mail log and post them here as well.
(Seems like this is not related to your problem, but I'm just curious what causes this fail in mchk. Thanks in advance.)
Thanks for your suggestions!
I could indeed nail it down with:
I stripped it down to two mailboxes and just deleted their "maildirsize" files. After that, the error message
However it seems that that did not fix the second problem with the failing "mail_auth_dump".
Here's the output you requested:
I also noticed that "mail_auth_view" prints the plain text passwords to the console, although the "enhanced security mode" is enabled. Is it supposed to do that? I would not expect it to!
I could indeed nail it down with:
and counter-checking for the error in the mail log.
I stripped it down to two mailboxes and just deleted their "maildirsize" files. After that, the error message
was gone when running "mailmng". I will keep checking the logs over the next days to see if that really solved the problem.
However it seems that that did not fix the second problem with the failing "mail_auth_dump".
Here's the output you requested:
I also noticed that "mail_auth_view" prints the plain text passwords to the console, although the "enhanced security mode" is enabled. Is it supposed to do that? I would not expect it to!
It's a pity that you did not save those files and posted them here. It might have helped Parallels to issue a patch or a more specific solution for other people with similar issue.
Also, if you've simply removed these files and they have not been restored (by you or any other software), then you effectively lifted any quota restrictions for those mailboxes. I'd suggest running /usr/local/psa/admin/sbin/mchk, which should fix that.
And it shouldn't. I think I noted that before. This is obviously another issue. I suppose it doesn't really affect product functionality. So, as you run this utility, do you get anything new in the logs?
Regarding this issue please also check:
1) After running mail_auth_dump utility, run
# /usr/local/psa/admin/sbin/mail_auth_view | grep '$AES' | wc -l
If this yields non-zero result, ask owners of corresponding addresses (# /usr/local/psa/admin/sbin/mail_auth_view | grep '$AES') to check whether their email is working (e.g. try to send email from these addresses).
2) Then check that this also results in 0:
# mysql -uadmin -p`cat /etc/psa/.psa.shadow ` psa -BN -e 'select * from accounts where type="sym" and password not like "$AES%"' | wc -l
Yes, it is. Otherwise you've might have gotten integration issues. Don't worry - the passwords are actually encrypted. Also, you must be root to use mail_auth_view. So everything is OK.
Here is the result for the 1st point:
That matches what I ment before: "mail_auth_view" shows the REAL plaintext passwords and not the encoded AES ones! Mail sending (with SMTP auth) and receiving (POP3, IMAP) works fine.
The result for the 2nd point:
I checked the accounts table and found out that these entries have the value "[BLOB - 0Bytes]". All these emails are forwarding email-accounts (meaning: no email aliases), mostly to another email of the same domain. However only some forwarding-addresses of each affected domain seem to have this problem, not all. I also found out, that some of these forwarding-addresses have a dedicated user account assigned, probably created during the upgrade from Plesk 9 to 10.
I'm going to experiment with recreating these emails.
The fact, that mail_auth_view displays the real passwords must mean, that they are somewhere saved in plain text. And imho that shouldn't be. Even root should not be able to see real passwords so easily. But that's another discussion
That matches what I ment before: "mail_auth_view" shows the REAL plaintext passwords and not the encoded AES ones! Mail sending (with SMTP auth) and receiving (POP3, IMAP) works fine.
The result for the 2nd point:
I checked the accounts table and found out that these entries have the value "[BLOB - 0Bytes]". All these emails are forwarding email-accounts (meaning: no email aliases), mostly to another email of the same domain. However only some forwarding-addresses of each affected domain seem to have this problem, not all. I also found out, that some of these forwarding-addresses have a dedicated user account assigned, probably created during the upgrade from Plesk 9 to 10.
I'm going to experiment with recreating these emails.
The fact, that mail_auth_view displays the real passwords must mean, that they are somewhere saved in plain text. And imho that shouldn't be. Even root should not be able to see real passwords so easily. But that's another discussion
Ok, I got it working!
Here's what I did:
I went through all the emails, that had a "[BLOB - 0Bytes]" password in the accounts table. If someone has to do that too, this query might be helpful:
Then I assigned some random password to each of these email addresses in the Plesk Admin GUI. They are simple forwarding-emails anyways and therefore should not support or require login. Then I saved each one again with an empty password (don't know if that actually mattered).
Finally I now have:
And mchk succeeds too:
Thanks for pointing in the right direction!
Here's what I did:
I went through all the emails, that had a "[BLOB - 0Bytes]" password in the accounts table. If someone has to do that too, this query might be helpful:
Then I assigned some random password to each of these email addresses in the Plesk Admin GUI. They are simple forwarding-emails anyways and therefore should not support or require login. Then I saved each one again with an empty password (don't know if that actually mattered).
Finally I now have:
And mchk succeeds too:
Thanks for pointing in the right direction!
I'm glad it worked out for you, MeaC!
Not necessarily. It just means that there is a way to get this data in plain text. Actually, if you look into the mail passwords database with sqlite3, you'll see that all mail passwords are really encrypted. Even if you didn't turn the enhanced security mode on!
There is a simple explanation to this. mail_auth_view was obviously left working to avoid integration issues since many people seem to use it in some way. There is a way to get plain text mail passwords since otherwise shared-secret mail authentication mechanisms would stop working and your customers would be forced to use insecure mechanisms that transfer passwords in plain text over the network.
Therefore, what you see is actually a sign of a more secure system, than a less secure one. Also note that if you have a root access to the system, then you can do virtually anything, so mail_auth_view is not a security hole in that sense, just a convenience.
The fact, that mail_auth_view displays the real passwords must mean, that they are somewhere saved in plain text. And imho that shouldn't be. Even root should not be able to see real passwords so easily. But that's another discussion
Not necessarily. It just means that there is a way to get this data in plain text. Actually, if you look into the mail passwords database with sqlite3, you'll see that all mail passwords are really encrypted. Even if you didn't turn the enhanced security mode on!
There is a simple explanation to this. mail_auth_view was obviously left working to avoid integration issues since many people seem to use it in some way. There is a way to get plain text mail passwords since otherwise shared-secret mail authentication mechanisms would stop working and your customers would be forced to use insecure mechanisms that transfer passwords in plain text over the network.
Therefore, what you see is actually a sign of a more secure system, than a less secure one. Also note that if you have a root access to the system, then you can do virtually anything, so mail_auth_view is not a security hole in that sense, just a convenience.
P_heck
Basic Pleskian
Coming from: http://forum.parallels.com/showthread.php?p=633655#post633655, I have read this thread and now have identified 2 files which seems to be corrupt (see attachment). Have deleted and recreated them - so let's see if this is now solved.
Oh, thank you very much, P_heck! I can now see the potential problem. The first line is empty. Maildir++ specifies that the first line must be a header, which is absent here. This must be causing errors.
Interesting how it got there. I have 2 theories.
1) At some point in time those files were edited manually.
2) Some third-party software corrupted the files.
Do you happen to have any additional mail software installed on the server that didn't come with Plesk?
Have this thread helped you to fix mail_auth_dump problems? Did you have Plesk 9 some time ago installed on this server?
Interesting how it got there. I have 2 theories.
1) At some point in time those files were edited manually.
2) Some third-party software corrupted the files.
Do you happen to have any additional mail software installed on the server that didn't come with Plesk?
Have this thread helped you to fix mail_auth_dump problems? Did you have Plesk 9 some time ago installed on this server?
Last edited:
P_heck
Basic Pleskian
Hello Nicolay,
neither I edited those files manually, nor I use another software. As I have Logcheck installed (which alerts me about any new error), I can exactly say, that this problem occurred immediately after the update from 10.4.4 to 11..0.9.
Can't answer your question on mail_auth_dump, as I didn't had this error (this was MeaC).
Ciao
Peter
R
rihad
Guest
I have same corruption errors in the logs, but my mchk worked fine:
# /usr/local/psa/admin/sbin/mchk --with-spam
==> Checking for: mailsrv_conf_init... ok
==> Checking for: mail_handlers_init... ok
==> Checking for: mailsrv_entities_dump... ok
==> Checking for: mail_admin_aliases... ok
==> Checking for: mail_auth_dump... ok
==> Checking for: mailman_lists_dump... ok
==> Checking for: mail_kav8_restore... ok
==> Checking for: mail_responder_restore... ok
==> Checking for: mail_postfix_transport_restore... ok
==> Checking for: mail_spam_restore... not exists
==> Checking for: mail_grey_restore... ok
==> Checking for: mail_mailbox_restore... ok
==> Checking for: mail_spf_restore... ok
==> Checking for: mail_dk_restore... ok
==> Checking for: mail_drweb_restore... ok
I also got messages like
Aug 1 22:00:31 debian /usr/lib/plesk-9.0/psa-pc-remote[15812]: Message aborted.
Aug 1 22:00:31 debian /usr/lib/plesk-9.0/psa-pc-remote[15812]: Message aborted.
Aug 1 22:00:32 debian /usr/lib/plesk-9.0/psa-pc-remote[15812]: Message aborted.
Aug 1 22:00:32 debian /usr/lib/plesk-9.0/psa-pc-remote[15812]: Message aborted.
what do they mean?
# /usr/local/psa/admin/sbin/mchk --with-spam
==> Checking for: mailsrv_conf_init... ok
==> Checking for: mail_handlers_init... ok
==> Checking for: mailsrv_entities_dump... ok
==> Checking for: mail_admin_aliases... ok
==> Checking for: mail_auth_dump... ok
==> Checking for: mailman_lists_dump... ok
==> Checking for: mail_kav8_restore... ok
==> Checking for: mail_responder_restore... ok
==> Checking for: mail_postfix_transport_restore... ok
==> Checking for: mail_spam_restore... not exists
==> Checking for: mail_grey_restore... ok
==> Checking for: mail_mailbox_restore... ok
==> Checking for: mail_spf_restore... ok
==> Checking for: mail_dk_restore... ok
==> Checking for: mail_drweb_restore... ok
I also got messages like
Aug 1 22:00:31 debian /usr/lib/plesk-9.0/psa-pc-remote[15812]: Message aborted.
Aug 1 22:00:31 debian /usr/lib/plesk-9.0/psa-pc-remote[15812]: Message aborted.
Aug 1 22:00:32 debian /usr/lib/plesk-9.0/psa-pc-remote[15812]: Message aborted.
Aug 1 22:00:32 debian /usr/lib/plesk-9.0/psa-pc-remote[15812]: Message aborted.
what do they mean?
Oh, that's very interesting. So maildirsize file gets corrupted periodically for the same mail and domain? Are there any third-party mail programs used by this user? Are there any suspicious scheduled tasks for this user?
No wonder here - the two errors are actually unrelated.
It means someone didn't finish sending email (i.e. SMTP session was interrupted in the middle). Usually nothing to worry about.
P_heck
Basic Pleskian
Well, periodically doesn't mean in fixed intervals:
30.06.12 03:06
31.07.12 12:11
01.08.12 09:59
02-08.12 11:50
I don't use any other mail prg. on the server. This problem started after upgrading to the new Plesk version 11!
Ciao
Peter
