Bug 1275078 - postfix mbox default size of 50MB causes mail loss without clear logging
postfix mbox default size of 50MB causes mail loss without clear logging
Status: ASSIGNED
Product: Red Hat Enterprise Linux 7
Classification: Red Hat
Component: postfix (Show other bugs)
7.3
Unspecified Unspecified
unspecified Severity unspecified
: rc
: ---
Assigned To: Jaroslav Škarvada
qe-baseos-daemons
:
Depends On: 1275076
Blocks: 1400961 1472751
  Show dependency treegraph
 
Reported: 2015-10-25 11:43 EDT by Paul Wouters
Modified: 2017-10-03 21:17 EDT (History)
3 users (show)

See Also:
Fixed In Version:
Doc Type: If docs needed, set a value
Doc Text:
Story Points: ---
Clone Of: 1275076
Environment:
Last Closed:
Type: Bug
Regression: ---
Mount Type: ---
Documentation: ---
CRM:
Verified Versions:
Category: ---
oVirt Team: ---
RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: ---


Attachments (Terms of Use)

  None (edit)
Description Paul Wouters 2015-10-25 11:43:07 EDT
+++ This bug was initially created as a clone of Bug #1275076 +++

Description of problem:

When using mbox, postfix per default limits files in /var/mail to 50MB. procmail as the LDA is prevented from writing, and returns EX_CANTCREAT which causes the mail to fail with a permanent 5.x.x error. It is lost and never retried for delivery. This all happened while my /var/mail had 300G free disk space.

Either the default maximum should be significantly increased (eg 500) or should take into account the number of users and the amount of free spool disk space. Or should be disabled completely per default. The latter can be done using mailbox_size_limit=0

This was a bug that took me 6 months of hunting down because of the bad logging between procmail and postfix with no clue as to the reason why procmail dies with "can't create user output file."

I've filed a bug for procmail to change its return value to a temporary failure code - See #1275071 and #1275072

At a minimum I think we need to bump the 50Mb significantly to avoid breaking simple small postfix installs with a handful of users and a modern 1T disk.
Comment 3 Jaroslav Škarvada 2016-10-25 08:51:28 EDT
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.
Comment 4 Paul Wouters 2016-10-25 11:11:01 EDT
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
Comment 5 Jaroslav Škarvada 2016-10-25 12:15:33 EDT
(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.

Note You need to log in before you can comment on or make changes to this bug.