Over Quota Reply Codes
Dovecot quota plugin returns code 554 5.2.2 when a user inbox is full.
Why 554 (transaction failed) instead of 552 (exceeded storage allocation)? Im curious behind the logic as im trying to determine the best code to use to reject a user sending more emails than their number-of-emails-limit quota.
If anyone has an option to share on the best code to return it would be appreciated;
550 (policy reasons)
552 (exceeded ... allocation)
554 (transaction failed)
5.2.2 (mailbox full)
5.5.3 (Too many recipients)
5.7.0 (Other security related)
5.7.1 (delivery not authorized)
Which fits best?
For the record, we also use 554 for Over Quota, but it is an interesting topic for conversation, eg why do we even indicate a permanent failure, when of course the person might make room in the next couple of hours.
It MIGHT be preferred to let the sender know as soon as possible, so he can advise the recipient by alternative means...
Maybe more clarity can be gleaned from RFC's on this matter, but in the end it is up to the email provider, which method they think is better.
Just make sure you also include an obvious message, eg.
lmprintf("554 User [%s] is over quota.\r\n", LM_STRING_BUFFER(addr));
On 2021-09-01 4:11 p.m., dovecot@ptld.com wrote:
Dovecot quota plugin returns code 554 5.2.2 when a user inbox is full.
Why 554 (transaction failed) instead of 552 (exceeded storage allocation)? Im curious behind the logic as im trying to determine the best code to use to reject a user sending more emails than their number-of-emails-limit quota.
If anyone has an option to share on the best code to return it would be appreciated;
550 (policy reasons) 552 (exceeded ... allocation) 554 (transaction failed)
5.2.2 (mailbox full) 5.5.3 (Too many recipients) 5.7.0 (Other security related) 5.7.1 (delivery not authorized)
Which fits best?
participants (2)
-
dovecot@ptld.com
-
Michael Peddemors