Quoting Reindl Harald h.reindl@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