Defer email via LMTP when there is 'no space left on device' instead of rejecting it

[Moritz Augsburger]

On 2014-07-22 17:31, Reindl Harald wrote:
> 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

The message could be already saved to disk by the MTA, so I don't see a
reason for a hard reject, if it could be fixed within some hours by the
admin (eg by expanding the volume, moving mailboxes between multiple
storage systems etc).

Mails aren't instant, and as long as the MTA handles it properly with a
reject after some failed delivery attempts I see no problem making it at
least configurable.

> 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 is
> to prevent "disk full"

In fact that's not the case in nearly all big mail systems. Available
storage is mostly average mailbox size x user count x safety margin.

Yes, it's an admin failure when no space is left, but why bother the
user or people trying to send mail to your users as long as the admin
can take countermeasures within adequate time?

Moritz

-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 181 bytes
Desc: OpenPGP digital signature
URL: <http://dovecot.org/pipermail/dovecot/attachments/20140722/b8822be7/attachment.sig>