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

[Reindl Harald]

Am 22.07.2014 19:00, schrieb 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).

the same applies for single mailbox full
so why handle the cases different?

> 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.

it makes things more complicated if you have different
behavior for 'mailbox full' and 'disk full'

>> 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.

which hardly leads to 'disk full' from one day to another
except the calculation assumes sunshine serveral contextes
and allows a few accounts to fill your whole storage

normally you have watchdogs which are crying out loud
if a storage goes below 25% free, daily logwatch shows
you the % of free space

http://en.wikipedia.org/wiki/File_system_fragmentation#Preventing_fragmentation
As time goes on, and the same factors are continuously present,
free space as well as frequently appended files tend to fragment
more. Shorter regions of free space also mean that the allocator
is no longer able to allocate new files contiguously, and has to
break them into fragments. This is especially true when the file
system is more full — longer contiguous regions of free space are
less likely to occu

> 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?

because it happens only a few times per decade and admin


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