Error 550 - mailbox full, when the mailbox quota hasn't been reached

sbudach · 2022-08-19T15:24:32+00:00

Grommunio on Debian, latest updates applied, trying to send mail to user on Port 25 I am testing my Grommunio setup and I was trying to send a message from m...

crpb

I always were under the Impression that the Send, Receive and Storage-Quotas like the MS Exchange ones..
So a setting of 50MB stops receiving on a mailbox > 50MB :-)

https://docs.microsoft.com/en-us/exchange/recipients/user-mailboxes/storage-quotas?view=exchserver-2019

EDIT: I guess the "grommunio-admin cli" has a problem, but gromox works.

# grommunio-admin exmdb $mbx store get  |grep quota\|size
messagesizeextended                   175359140  167 MiB
storagequotalimit                       6291456  6.00 MiB
prohibitreceivequota                    5242880  5.00 MiB
prohibitsendquota                       4194304  4.00 MiB
normalmessagesizeextended             175151221  167 MiB
assocmessagesizeextended                 207919  203 kiB

EDIT2: You have to think of it as only Mailbox-Settings. Mail-Size-Limitations in Sending/Receiving are done in Postfix and don't have anything to do with gromox or am i totaly wrong... i don't know :-)

EDIT3:
And for Postfix postconf message_size_limit=$(( 50*1024*1024 )) should work... (not tested)

sbudach

Yeah… okay, granted I misread, what the different quotas where used for, it still stands that entering a Send quota limit of 4 GB translates into 4,00 MiB when viewed from grommunio-admin, so there is something wrong there.

crpb

So let's dive into that :-).
admin-web quota
admin-web sizeunits
admin-api exmdb

I would say that the admin-api(and web) doesn't care for anything less than a Megabyte(at least in that context of quotas) and the admin-cli only has that one function which maybe is also used for other values which are ~~Bytes~~ or Kilo-Bytes.

So this would mean that cliExmdbStoreGetDelete.printsize() would have to be extended to accept index=12 in that case if my rusty dev-skills aren't wrong o_0.

@jschroeder if i'm not mistaken, you are the person to ask right?

EDIT: it is stored in kB... had a 50 instead of a 5 in my shell-calc as i looked that up IIRC...

Grummel

However, something is not working properly with setting the quotas in the Admin-GUI. I habe following behavior: After successful import of a *.PST file into a user, this user is not able to send and receive any mails. Only after setting the quota limits for send and receive to 5 GB (may be less, I didn't test) and a reset of the settings in the Web-UI to factory defaults (forces you to make a new setup for the web-UI) the user can send and receive mails again. When decreasing the quotas back to a "normal" value of 25 MB, the user is again not able to send and receive mails. I'm running the community version with the latest updates.
May be somebody else can verify this as well.

crpb

Grummel
Yet again, 25MB would say your Mailbox only has 25MB of Storage-Quota. It doesn't have anything to do with Message-Size.

EDIT: Think about it like that. A Quota is Limitation on a Store, not on the individual Content of that given Store. And a Message is only Content.

And look at the Screenshot of the Quota-Usage+Limits https://community.grommunio.com/d/479-error-550-mailbox-full-when-the-mailbox-quota-hasnt-been-reached/5
It should become clear in the Web-Admin if your settings are usable.

I also whipped up a snippet for setting defaults.
https://community.grommunio.com/d/444-grommunio-scripting-snippets-notepad/14
Haven't tried them with grommunio-admin exmdb yet.

sbudach

crpb
One understands that, if one ever reads the admin manual, but who would that do - especially, if you're an experienced admin…? I have to admit, that I made that mistake, too. When going over the settings, I mistook "send quota limit" as Postfix' "max message size", which I intended to set, but which can't be set anywhere in the admin UI.

Btw, after performing the update yesterday, the values for the quotas set in the admin UI and the values returned by grommunio-admin exmdb <mailbox> store get still differ. Setting the unit to GB in admin UI causes grommunio-admin to display MiB - so 6 GB in admin UI result in 6.00 MiB in grommunio-admin.
It does, however, not cause new messages to be rejected, so maybe the admin UI is right after all and gromox-admin needs some work.

crpb

sbudach

Yeah, the Developer is currently not available :-). So the correct values have to wait.

Steakie

sbudach i promise to investigate and debug this thoroughly asap

crpb

sbudach but which can't be set anywhere in the admin UI.

If i understood the mechanism correctly it kinda is. But i didn't figure it out yet.... too dumb for some things :-).

https://docs.grommunio.com/man/grommunio-admin-dbconf.html

@Steakie maybe you could help with that?
We just want to set default postconf-values via webadmin/grommunio-admin and actually apply them.
I think i once asked that in October or so and just got the reference to the man.. But i haven't had any luck with it...

That's my last try...

# postconf smtp_use_tls=no
# for file in `grommunio-admin dbconf list postfix |sed '1d'`; do grommunio-admin dbconf get postfix $file; done
smtp_sasl_auth_enable=yes
smtp_sasl_security_options=noanonymous
smtp_sasl_password_maps=lmdb:/etc/postfix/sasl_passwd
smtp_use_tls=yes
# grommunio-admin dbconf commit postfix
# postconf smtp_use_tls
smtp_use_tls = no

Steakie

crpb Not quite sure what this is or does, but i think it's equivalent to my web implementation
https://docs.grommunio.com/admin/administration.html#db-configuration

crpb

Steakie
I succesfully used it via the grommunio-admin-api, but if recreate it via the Web-Admin from scratch the configuration will not be applied. Neither on the OVA-Image or the Debian-Installation.
When i change the value in the CLI afterwards it does what it is supposed to.
After a quick look at @ journalctl i found the following line on the Debian-Host
uwsgi[7200]: Failed to restart postfix.service: Interactive authentication required.
Then i tried it w/o the systemctl restart/reload in "grommunio-dbconf/postfix" as postconf should take care of it IIRC. But that didn't help either.

crpb

Ahh, haven't looked at that Doc in a long time :-). I will give it a try.
.. I should have read it again *g*. Thanks for the hint.

*Endlich hats im Stübche geklinkelt*

crpb

I extended the Showcase a bit :P

https://community.grommunio.com/d/444-grommunio-scripting-snippets-notepad/14

jschroeder

Hi,

the quotas displayed by the CLI are incorrect, as they are actually measured in kibibytes instead of bytes (admin-web displays these values correctly)
the postfix configuration is not applied properly when modified via admin-web because there is no suitable trigger to run and, unfortunately, the only workaround that comes to my mind is to modify single values via CLI

I just submitted the fix to (1) and it should become available in the coming days. (2) requires some more thought and might take a bit longer…

crpb

jschroeder the only workaround that comes to my mind is to modify single values via CLI

Just a thought, but maybe an additional systemd-service(script) which takes care of all those $privileged tasks.
And with something like that it could be initiated.

#!/bin/env python
from pystemd.systemd1 import Unit
from pystemd.dbuslib import DBus
dbus = DBus(user_mode=True)
ourbus=dbus.__enter__()
e=ourbus
myservice = Unit("myservice.service", bus=e, _autoload=True)
myservice.Unit.Start(b"replace")

pystemd
At least that's the easy way to call an systemd-service without working through dbus.

jschroeder

I think there are two separate problems.

The first problem is that admin-web can only perform modifications on the file-level, while the trigger running postconf -e is only available on the key-level and thus never run.
Reloading the postfix service does not have any effect either because there is currently no way to update the postfix configuration. This can hopefully be solved by providing an appropriate file-level trigger, but I still have to test this approach.

The second problem is that the AAPI service might not have sufficient privileges to call systemd. This is an issue specific to Debian due to the ancient polkit version that does not support JavaScript rules.
I'm not sure whether pystemd can solve this issue as the current systemctl exec implicitely uses D-Bus as well.

crpb

No, pystemd will not help with anything of that. It's just an easy to use implementation for such simple Calls(and maybe more..).
Personally I use this kind of pystemd-snippet's to run long-running sql-queries which can be invoked by web-applications and/or with .timers. But those are all running in the individual $user-session...

I will ask those evil Maintainers on OFTC how to maybe implement that in a safe way :).

crpb

I guess the Main-Issue is solved.