• 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

Upgrade to 10.4.4 - check-quota filter errors

I have received following information from developers:
Looks like a problem with this mailbox. I can't recognize a root cause because there're no any logs for 8-th of January and this mailbox on the customer's machine.
 
Huh? Which mailbox? which machine? - This error is reproduced by ANY sent or received email within my server...not with a specific mailbox...
 
I think that he talk about server with login credentials that you have provided.
 
These are the commands they did:
990 less /usr/local/psa/var/log/maillog
991 less /usr/local/psa/var/log/maillog.processed
992 less /usr/local/psa/var/log/maillog.processed

They looked at the wrong log files...all my maillog is in /var/log/maillog

Please ask them to connect and check once again as I need this fixed please..
 
These are the commands they did:
990 less /usr/local/psa/var/log/maillog
991 less /usr/local/psa/var/log/maillog.processed
992 less /usr/local/psa/var/log/maillog.processed

They looked at the wrong log files...all my maillog is in /var/log/maillog

Please ask them to connect and check once again as I need this fixed please..

Correct place for Plesk maillog is /usr/local/psa/var/log/maillog
Why do you think that your Plesk installation has /var/log/maillog for maillog location?
 
Correct place for Plesk maillog is /usr/local/psa/var/log/maillog
Why do you think that your Plesk installation has /var/log/maillog for maillog location?

Igor, I am very surprised with where this conversation is heading...

I am the one who chose to have my mail logs in /var/log/maillog

Is there a problem in that? Shouldn't we focus on the problem itself please?

Thank you very much
 
I showed our discussion to developers and they will continue investigation.
 
I also see these errors also on new install

I also see these errors on a pretty fresh install of PPP 10.4.4. However, I see the errors in the context of a spammer trying to send spam to a non-existent user and then bouncing the email.

Here is a snipit from my logs located in /var/log/psa/maillog. Note the fourth line "check-quota filter." Why does it check the quota on a nonexistent user?

Jan 11 10:38:13 <hostname> postfix/smtpd[13217]: connect from ip-195-182-192-57.opensvit.ua[195.182.192.57]
Jan 11 10:38:14 <hostname> postfix/smtpd[13217]: 37DED240060: client=ip-195-182-192-57.opensvit.ua[195.182.192.57]
Jan 11 10:38:14 <hostname> postfix/cleanup[13222]: 37DED240060: message-id=<[email protected]>
Jan 11 10:38:14 <hostname> check-quota filter[13223]: Failed to run '/usr/sbin/postalias -q [email protected] hash:/var/spool/postfix/plesk/virtual', rc = 1
Jan 11 10:38:14 <hostname> /usr/lib64/plesk-9.0/psa-pc-remote[1928]: handlers_stderr: SKIP
Jan 11 10:38:14 <hostname> /usr/lib64/plesk-9.0/psa-pc-remote[1928]: SKIP during call 'check-quota' handler
Jan 11 10:38:14 <hostname> postfix/qmgr[15581]: 37DED240060: from=<[email protected]>, size=1338, nrcpt=1 (queue active)
Jan 11 10:38:15 <hostname> postfix/local[13225]: 37DED240060: to=<[email protected]>, orig_to=<[email protected]>, relay=local, delay=0.95, delays=0.89/0.02/0/0.04, dsn=5.2.1, status=bounced (This address no longer accepts mail. )
Jan 11 10:38:15 <hostname> postfix/cleanup[13222]: 09E28240063: message-id=<[email protected]>
Jan 11 10:38:15 <hostname> postfix/bounce[13227]: 37DED240060: sender non-delivery notification: 09E28240063
Jan 11 10:38:15 <hostname> postfix/qmgr[15581]: 09E28240063: from=<>, size=3350, nrcpt=1 (queue active)
Jan 11 10:38:15 <hostname> postfix/qmgr[15581]: 37DED240060: removed
Jan 11 10:38:15 <hostname> postfix/local[13225]: 09E28240063: to=<[email protected]>, orig_to=<[email protected]>, relay=local, delay=0.01, delays=0/0/0/0.01, dsn=5.2.1, status=bounced (This address no longer accepts mail. )
Jan 11 10:38:15 <hostname> postfix/qmgr[15581]: 09E28240063: removed
Jan 11 10:38:15 <hostname> postfix/smtpd[13217]: disconnect from ip-195-182-192-57.opensvit.ua[195.182.192.57]
 
I can observe this error at four machines running 10.4.4.
Mail is still delivered, but error log is filled by this.

Jan 14 12:36:12 46246 postfix/smtpd[11699]: connect from p5B3ADxxx.dip.t-dialin.net[91.58.213.xxx]
Jan 14 12:36:12 46246 postfix/smtpd[11699]: BFFE01751823B: client=p5B3ADxxx.dip.t-dialin.net[91.58.213.xxx], sasl_method=LOGIN, [email protected]
Jan 14 12:36:12 46246 postfix/cleanup[11703]: BFFE01751823B: message-id=<001b01ccd2b0$bad2dc80$30789580$@de>
Jan 14 12:36:12 46246 check-quota filter[11704]: Failed to run '/usr/sbin/postalias -q [email protected] hash:/var/spool/postfix/plesk/virtual', rc = 1
Jan 14 12:36:13 46246 postfix/qmgr[11638]: BFFE01751823B: from=<[email protected]>, size=2691, nrcpt=1 (queue active)
Jan 14 12:36:13 46246 postfix/smtp[11706]: BFFE01751823B: to=<[email protected]>, relay=mx1.gmx.net[213.165.64.102]:25, delay=0.43, delays=0.28/0.01/0.05/0.1, dsn=2.6.0, status=sent (250 2.6.0 Message accepted {mx058})
Jan 14 12:36:13 46246 postfix/qmgr[11638]: BFFE01751823B: removed
Jan 14 12:36:15 46246 postfix/smtpd[11699]: disconnect from p5B3ADxxx.dip.t-dialin.net[91.58.213.xxx]
 
Hello, we are also seeing this problem after an upgrade from 10.3.1 to 10.4.4 on 2012-01-20 on one of our production servers. Mail quota checks are being run on external email addresses, something is definitely wrong.

Igor do we have any update on this bug?

Thanks
 
I sometimes get this as well:

Jan 7 21:53:51 xxxcheck-quota filter[26310]: stat('/var/qmail/mailnames/xxxx.com/xxxx/Maildir') failed. Permission denied: 13
..........

You have a lost suid bits for quota-check handler:
-rwxrwxrwx 1 popuser postfix 35732 Nov 2 14:37 check-quota
 
Same here, heaps of 'Failed to run' entries
grep "Failed to run '/usr/sbin/postalias -q " /usr/local/psa/var/log/maillog| wc -l
447

# /usr/sbin/postalias -q [email protected] hash:/var/spool/postfix/plesk/virtual
# echo $?
1
# /usr/sbin/postalias -q [email protected] hash:/var/spool/postfix/plesk/virtual
[email protected]
# echo $?
0

Looks like check_quota filter dumbly runs this command for all the recipients instead of discriminating between local and non-local users, returning failure for non-zero exit code. The filter should instead, *I think*, check postalias exit code and proceed with the quota check on zero exit code only.
I wouldn't worry about these log entries, they're just annoying, otherwise pretty harmless. Unless the server does a very large number of deliveries.
 
Last edited:
Back
Top