• We value your experience with Plesk during 2024
    Plesk strives to perform even better in 2025. To help us improve further, please answer a few questions about your experience with Plesk Obsidian 2024.
    Please take this short survey:

    https://pt-research.typeform.com/to/AmZvSXkx
  • The Horde webmail has been deprecated. Its complete removal is scheduled for April 2025. For details and recommended actions, see the Feature and Deprecation Plan.

Issue Failed to reset statistics for mail exceed limit

nethubonline

Regular Pleskian
Server operating system version
AlmaLinux release 9.3
Plesk version and microupdate number
Plesk Obsidian Version 18.0.59 Update #2
Hi all,

After the first time enable outgoing messages limit, it works fine at the beginning. When user exceeds the limit and I want to reset the statistics for outgoing limit, so I tried commands below, problem happens. Please help.

Case 1
Bash:
plesk sbin mailmng-outgoing --destroy
Result: stop limiting the outgoing email, user can send email more than the quota.
When the first email is sent, the maillog shows below because data.db not exists
Code:
Apr  1 20:57:46 test.plesk psa-pc-remote[546]: 784608048A: py-limit-out: stderr: ERROR:__main__:[Errno 1] Operation not permitted: '/var/lib/plesk/mail/outgoing/data.db'
When the second email is sent, the maillog shows below because data.db 0 byte
Code:
Apr  1 20:44:26 test.plesk psa-pc-remote[8635]: 71F0C106198A: py-limit-out: stderr: ERROR:__main__:no such table: domains


Case 2
Bash:
rm -rf /var/lib/plesk/mail/outgoing/data.db
Result is same as Case 1


Case 3
Bash:
plesk sbin mailmng-outgoing --destroy
plesk sbin mailmng-outgoing --cleanup --force
Result: user can't send any email. data.db 131072 bytes, mailog shows:
Code:
Apr  1 20:48:17 test.plesk psa-pc-remote[380]: 0FAC4106198F: py-limit-out: stderr: INFO:__main__:REJECT message as system user is not allowed to use sendmail
Apr  1 20:48:17 test.plesk psa-pc-remote[380]: 0FAC4106198F: py-limit-out: stderr: DATA REPLY:554:5.7.0 The message could not be sent. You are not allowed to use sendmail utility.
Apr  1 20:48:17 test.plesk psa-pc-remote[380]: 0FAC4106198F: py-limit-out: stderr: REJECT
Apr  1 20:48:17 test.plesk postfix/cleanup[982]: 0FAC4106198F: milter-reject: END-OF-MESSAGE from localhost.localdomain[127.0.0.1]: 5.7.0 The message could not be sent. You are not allowed to use sendmail utility.; from=<[email protected]> to=<[email protected]> proto=ESMTP helo=<test.com>
Apr  1 20:48:17 test.plesk postfix/smtpd[1013]: disconnect from localhost.localdomain[127.0.0.1] ehlo=2 starttls=1 auth=1 mail=1 rcpt=1 data=0/1 rset=1 quit=1 commands=8/9


Case 4
Bash:
plesk sbin mailmng-outgoing --cleanup --to-timestamp UTC_TIMESTAMP --force
Result: error shows:
Bash:
ERROR:__main__:supplied timestamp is invalid: 'UTC_TIMESTAMP'
exit status 1
 
Please do not use commands in the plesk sbin family, unless directed by the official documentation or staff. These are internal commands. Using them directly may result in unexpected changes or damage to your system.

If you want to raise the messages limit for a specific object (mail, domain, etc.) - just do so via the panel. This will result in subsequent messages being passed.
 
Hi

I don't think whole plesk sbin family are for plesk staff usage only, many tools there are descripted well and for users to use, e.g. plesk bin service_plan

But i know plesk sbin mailmng-outgoing is better to be directed by plesk staff, i use this command because i found IgorG's reply on this thread: Resolved - Reset statistics for mail exceed limit

Code:
you could directly remove records from the backend database /var/lib/plesk/mail/outgoing/data.db in messages table, filter by the associated objects.

You could also use:

# plesk sbin mailmng-outgoing --cleanup --to-timestamp UTC_TIMESTAMP --force

Actually using plesk sbin mailmng-outgoing is not a must for me, I just want to reset the statistics just like TorbHo
 
I don't think whole plesk sbin family are for plesk staff usage only, many tools there are descripted well and for users to use, e.g. plesk bin service_plan
plesk sbin (internal utilities) and plesk bin (public CLI) are different.

As I said before, just raise the limits according to your new needs.
 
So, it seems like you're having trouble resetting the stats for how many messages you can send out in Plesk. Here's my suggestion for the first case.
Case 1: plesk sbin mailmng-outgoing --destroy
This command removes the data.db file, which is why you're seeing errors related to the missing or empty database. To reset the statistics without removing the limit, you should recreate the data.db file after destroying it. Try the following commands:
bash
plesk sbin mailmng-outgoing --destroy
plesk sbin mailmng-outgoing --init
 
Thank you @AlmaWalters

After run the commands you provided, the /var/lib/plesk/mail/outgoing/data.db file is recreated, however result is same as case 3, all users can't send any email. data.db 131072 bytes, mailog shows below.

Code:
Apr  4 09:51:27 test.plesk psa-pc-remote[59866]: 298A68049C: py-limit-out: stderr: INFO:__main__:REJECT message as system user is not allowed to use sendmail
Apr  4 09:51:27 test.plesk psa-pc-remote[59866]: 298A68049C: py-limit-out: stderr: DATA REPLY:554:5.7.0 The message could not be sent. You are not allowed to use sendmail utility.
Apr  4 09:51:27 test.plesk psa-pc-remote[59866]: 298A68049C: py-limit-out: stderr: REJECT
Apr  4 09:51:27 test.plesk postfix/cleanup[63349]: 298A68049C: milter-reject: END-OF-MESSAGE from localhost.localdomain[127.0.0.1]: 5.7.0 The message could not be sent. You are not allowed to use sendmail utility.; from=<[email protected]> to=<[email protected]> proto=ESMTP helo=<test.plesk.com>
Apr  4 09:51:27 test.plesk postfix/smtpd[63874]: disconnect from localhost.localdomain[127.0.0.1] ehlo=1 auth=1 mail=1 rcpt=1 data=0/1 rset=1 quit=1 commands=6/7

After further digging, I opened data.db and found the problem, below is missing after initial, that's why all users cannot send email
SQL:
INSERT INTO "mails" VALUES (1,'test',1,10);
INSERT INTO "domains" VALUES (1,'test.com',1,-1);
INSERT INTO "subscriptions" VALUES (1,1,100,1);
INSERT INTO "sysusers" VALUES (10000,'test.com_a9s2ndkzeon',1);

Is there any way to initial and re-add existing user to the DB? Otherwise, if the data.db file is somehow corrupted, the only solution is to disable outgoing restrictions.
 
Thank you @AlmaWalters

After run the commands you provided, the /var/lib/plesk/mail/outgoing/data.db file is recreated, however result is same as case 3, all users can't send any email. data.db 131072 bytes, mailog shows below.

Code:
Apr  4 09:51:27 test.plesk psa-pc-remote[59866]: 298A68049C: py-limit-out: stderr: INFO:__main__:REJECT message as system user is not allowed to use sendmail
Apr  4 09:51:27 test.plesk psa-pc-remote[59866]: 298A68049C: py-limit-out: stderr: DATA REPLY:554:5.7.0 The message could not be sent. You are not allowed to use sendmail utility.
Apr  4 09:51:27 test.plesk psa-pc-remote[59866]: 298A68049C: py-limit-out: stderr: REJECT
Apr  4 09:51:27 test.plesk postfix/cleanup[63349]: 298A68049C: milter-reject: END-OF-MESSAGE from localhost.localdomain[127.0.0.1]: 5.7.0 The message could not be sent. You are not allowed to use sendmail utility.; from=<[email protected]> to=<[email protected]> proto=ESMTP helo=<test.plesk.com>
Apr  4 09:51:27 test.plesk postfix/smtpd[63874]: disconnect from localhost.localdomain[127.0.0.1] ehlo=1 auth=1 mail=1 rcpt=1 data=0/1 rset=1 quit=1 commands=6/7

After further digging, I opened data.db and found the problem, below is missing after initial, that's why all users cannot send email
SQL:
INSERT INTO "mails" VALUES (1,'test',1,10);
INSERT INTO "domains" VALUES (1,'test.com',1,-1);
INSERT INTO "subscriptions" VALUES (1,1,100,1);
INSERT INTO "sysusers" VALUES (10000,'test.com_a9s2ndkzeon',1);

Is there any way to initial and re-add existing user to the DB? Otherwise, if the data.db file is somehow corrupted, the only solution is to disable outgoing restrictions.
Sorry I couldn't help you here. But it's awesome that you found a solution already. Well, we couldn't dig out in this issue deeper.
 
Back
Top