Regarding the logging I agree that it should be improved, but I think we shouldn't divert from the upstream defaults especially for the stable product.

I also think that 'mailbox limit reached' is permanent error, not transient (like DNS failure, connectivity error, etc.). It's fatal error that will not just go away without admin/mailbox owner intervention on the SMTP server. There are various opinions about it, but according to RFC2821:

"It is difficult to assign a meaning to "transient" when two different sites (receiver- andsender-SMTP agents) must agree on the interpretation.  Each reply
in this category might have a different time value, but the SMTP
client is encouraged to try again.  A rule of thumb to determine
whether a reply fits into the 4yz (i.e. transient) or the 5yz (i.e. permanent) category (see below)
is that replies are 4yz if they can be successful if repeated
without any change in command form or in properties of the sender
or receiver (that is, the command is repeated identically and the
receiver does not put up a new implementation.)"

(I added transient/permanent explanatory notes). I think that important is "change in command form or in properties of the sender or receiver", I think that increasing mailbox or deleting its content is changing properties of the receiver. Moreover most of the mailbox full or similar errors I have ever seen on the internet were 5yz, i.e. permanent. Also I don't think it's good idea to change this for stable product.

The important thing is that we solve the problem of mail being lost. Regardless of where in the mail processing stack we do that, the end result should be that if the mailbox is full, the sender should receive an error back so it knows the mail has not been delivered.

I had to deal with this issue on and off for two years before figuring out what was going on and why some people often had their mail lost when sending it to me. They just happened to send me PDFs a lot which would trigger the incoming project folder to hit the maximum

(In reply to Paul Wouters from comment #4)
> The important thing is that we solve the problem of mail being lost.
> Regardless of where in the mail processing stack we do that, the end result
> should be that if the mailbox is full, the sender should receive an error
> back so it knows the mail has not been delivered.
> 
> I had to deal with this issue on and off for two years before figuring out
> what was going on and why some people often had their mail lost when sending
> it to me. They just happened to send me PDFs a lot which would trigger the
> incoming project folder to hit the maximum

I will take a look, this maybe bug. It should bounce something sensible if the message is undeliverable.

Sorry for delay, I tried to reproduce the problem, but it works for me:
# rpm -q postfix
postfix-2.10.1-6.el7.x86_64
# rpm -q procmail
procmail-3.22-36.el7_4.1.x86_64
# postconf mailbox_command=/usr/bin/procmail
# systemctl restart postfix
# ll /var/spool/mail/testmail
-rw-rw----. 1 testmail mail 100000000 Nov 16 16:41 /var/spool/mail/testmail
# ll /var/spool/mail/yarda
-rw-rw----. 1 yarda mail 3115 Nov 16 16:41 /var/spool/mail/yarda
# telnet localhost 25
# Trying ::1...
Connected to localhost.
Escape character is '^]'.
220 <HOST> ESMTP Postfix
ehlo localhost
250-<HOST>
250-PIPELINING
250-SIZE 10240000
250-VRFY
250-ETRN
250-ENHANCEDSTATUSCODES
250-8BITMIME
250 DSN
mail from: yarda
250 2.1.0 Ok
rcpt to: testmail
250 2.1.5 Ok
data
354 End data with <CR><LF>.<CR><LF>
hi
.
250 2.0.0 Ok: queued as 41F54235679F
quit
221 2.0.0 Bye
Connection closed by foreign host.
# cat /var/spool/mail/yarda
...
Original-Recipient: rfc822;testmail
Action: failed
Status: 5.2.0
Diagnostic-Code: x-unix; procmail: Error while writing to
    "/var/spool/mail/testmail"
...

So it seems to work, it bounced back 5.2.0 error. Well, 5.2.2 would be nicer, but 5.2.0 is also OK.

Btw regarding the 4/5 error code, sendmail is also returning 5 for this type of errors.

Red Hat Enterprise Linux version 7 entered the Maintenance Support 1 Phase in August 2019. In this phase only qualified Critical and Important Security errata advisories (RHSAs) and Urgent Priority Bug Fix errata advisories (RHBAs) may be released as they become available. Other errata advisories may be delivered as appropriate.

This bug has been reviewed by Support and Engineering representative and does not meet the inclusion criteria for Maintenance Support 1 Phase. If this issue still exists in newer major version of Red Hat Enterprise Linux, it has been cloned there and work will continue in the cloned bug.

For more information about Red Hat Enterprise Linux Lifecycle, please see https://access.redhat.com/support/policy/updates/errata/

Development Management has reviewed and declined this request. You may appeal this decision by using your Red Hat support channels, who will make certain  the issue receives the proper prioritization with product and development management.

https://www.redhat.com/support/process/production/#howto