Quoting Reindl Harald <h.rei...@thelounge.net>:
Am 22.07.2014 17:11, schrieb Christian Rohmann:
In consequence this means the configuration option quota_full_tempfail
is applied in both cases. But to me there is a major difference between
a full disk (a.k.a "admin fucked up") and over-quota (a.k.a. "user has
simply too much stuff in his mailbox"). So I would like to be able tell
Dovecot to reject messages due to full mailboxes, but simply defer those
that cannot be stored due to a full disk (which I am to blame for).
To me this should result in two separate configuration options for the
two problem root-causes:
quota_full_tempfail
storage_full_tempfail
Or did I simply miss or completely misunderstood anything here?
no - in case of quota full i can take a phone and call the
RCPT, he can make free space due the phone call and say
"try it again please"
in case of disk full *this is* a permanent error likely not
correctable by the user given that after delete a message a
different one get a new and the disk is full again
that sort of mistakes happens one per decade and hardly
need special handling - if that happens your user quotas
are wrongly configured because the idea behind them isto prevent "disk
full"
Being that there are a million different ways to create a storage entity
and deliver to it, both of which is far outside the control of the user, I
don't think it's a bad idea to allow a delivery deferral for storage
issues.
For example, at that point in the code, /could/ an NFS/CIFS/local/remote
mount issue be reported as 'disk full', because the device is not
attached? If the answer is 'yes', then there should be an additional
option.
In my experience, users would rather have their mail delayed due to a
storage issue than outright rejected - especially when many rejections
would go to unattended mailboxes and can't be easily resent. Like my
Pizza Hut coupons. Don't go messing with my Pizza Hut coupons.
Rick
