Defer email via LMTP when there is 'no space left on device' instead of rejecting it
Hello dovecot-users,
(This problem was being discussed a little in this thread from 2011: http://www.dovecot.org/list/dovecot/2011-May/059009.html)
I noticed (using LMTP) that Dovecot handles 'no space left on device' just like an 'over-quota', if I read this part of method "static int client_deliver(struct client *client, const struct mail_recipient *rcpt, struct mail *src_mail, struct mail_deliver_session *session)" "lmtp/commands.c" correctly:
--- cut --- [...] else if (storage != NULL) { error = mail_storage_get_last_error(storage, &mail_error); if (mail_error == MAIL_ERROR_NOSPACE) { client_send_line(client, "%s <%s> %s", dctx.set->quota_full_tempfail ? "452 4.2.2" : "552 5.2.2", rcpt->address, error); } else { client_send_line(client, "451 4.2.0 <%s> %s", rcpt->address, error); } ret = -1; [...] --- /cut ---
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?
Regards
Christian
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 is to prevent "disk full"
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
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
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_fragmentat... 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
On 22.07.2014 19:00, Moritz Augsburger wrote:
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.
My point exactly. The message was accepted from the MTA already, but simply could not be delivered into the mailbox. This is a rare case yes, and yes, disk space has to be monitored. But this is not the point. The point is, what happens when it happens anyways, against all odds.
Bounced / rejected messages for something that will be usually be resolved very quickly and the messages can then be delivered after all is just not very nice for users. The admin made a mistake and the users have to deal with the problems is just not my approach.
But in the end I don't even want to argue that rejecting the messages might not be a valid behavior for some. That's why I suggested to make this configurable, just like the quota behavior.
Regards
Christian
Hey Timo and all,
may I PING this subject once again to maybe get Timo's opinion.
On 23.07.2014 11:26, Christian Rohmann wrote:
Bounced / rejected messages for something that will be usually be resolved very quickly and the messages can then be delivered after all is just not very nice for users. The admin made a mistake and the users have to deal with the problems is just not my approach.
But in the end I don't even want to argue that rejecting the messages might not be a valid behavior for some. That's why I suggested to make this configurable, just like the quota behavior.
I'd really like to hear Timo's view on having lmtp do a (configurable) DEFER when the disk is full which is, most likely, a "temporary" error.
Storage is cheap nowadays, it just has to be configured to the right volume and at the right time. Would be nice of Dovecot would not punish users (by bouncing their mail) for mistakes the admin made ;-)
Thanks,
Christian
On 05 Aug 2014, at 14:45, Christian Rohmann crohmann@netcologne.de wrote:
may I PING this subject once again to maybe get Timo's opinion.
On 23.07.2014 11:26, Christian Rohmann wrote:
Bounced / rejected messages for something that will be usually be resolved very quickly and the messages can then be delivered after all is just not very nice for users. The admin made a mistake and the users have to deal with the problems is just not my approach.
But in the end I don't even want to argue that rejecting the messages might not be a valid behavior for some. That's why I suggested to make this configurable, just like the quota behavior.
I'd really like to hear Timo's view on having lmtp do a (configurable) DEFER when the disk is full which is, most likely, a "temporary" error.
My opinion: It shouldn't be configurable - it should always cause temporary error. The only thing I'm slightly worried about is if write failures because of "user's filesystem quota full" will always return EDQUOT error for write() instead of ENOSPC, but I suppose they will in any modern OS. And it would require changing MAIL_ERROR_NOSPACE definition a bit inside Dovecot, but that's less of an issue.
I'll change this once I have some time&energy. Patches welcome also.
On 10 Aug 2014, at 01:19, Timo Sirainen tss@iki.fi wrote:
I'd really like to hear Timo's view on having lmtp do a (configurable) DEFER when the disk is full which is, most likely, a "temporary" error.
My opinion: It shouldn't be configurable - it should always cause temporary error. The only thing I'm slightly worried about is if write failures because of "user's filesystem quota full" will always return EDQUOT error for write() instead of ENOSPC, but I suppose they will in any modern OS. And it would require changing MAIL_ERROR_NOSPACE definition a bit inside Dovecot, but that's less of an issue.
And a bit more generic statement about anything related to errors in Dovecot:
Problems that admins can solve are temporary errors for users and the'll need an error logged. Problems that are caused by users themselves (like over quota) are usually not temporary errors and they shouldn't have errors logged (since admin can't usually do anything about them anyway).
On Sun, Aug 10, 2014 at 01:31:47AM +0300, Timo Sirainen wrote:
Problems that admins can solve are temporary errors for users and the'll need an error logged. Problems that are caused by users themselves (like over quota) are usually not temporary errors and they shouldn't have errors logged (since admin can't usually do anything about them anyway).
Depends on the environment; in many cases, the admin could, or may even be expected to, raise the quota.
Also, you're assuming that users will be able to interpret an error message, even a clear one, correctly, and that the MUA will always convey the error to the user. I am not sure either of these assumptions are always true. Logging is important so when the user calls in with "I can't do X", the admin can see why quickly.
w
On 10-8-2014 06:18, Will Yardley wrote:
Depends on the environment; in many cases, the admin could, or may even be expected to, raise the quota.
!but should not!
Quota should be set according to some rules, and never be raised because of a 'quota reached'.
What is the use of 'quota' if the admin raises your quota when things are full?
On Sun, Aug 10, 2014 at 06:24:47PM +0200, Luuk wrote:
On 10-8-2014 06:18, Will Yardley wrote:
Depends on the environment; in many cases, the admin could, or may even be expected to, raise the quota.
!but should not!
Quota should be set according to some rules, and never be raised because of a 'quota reached'.
A few things on this:
- "Should" is a matter of opinion, and different environments have different business requirements. I've worked as a sysadmin for almost 15 years, in a variety of different settings (small startup, larger startup, later acquired by a corporation, academic), and I've found that there's always *some* squeaky wheel who is going to make a lot of noise and get their quota raised. In several roles, in fact, that person is often another technical person, who also happened to be my boss. In fact, I've been in plenty of situations where quotas can't be set at all, or are set so high that they're basically useless. I thought (at times) that changing to a different setting, for example, education, might change this, but I have not found this to be the case.
In a pure ISP / hosting provider type situation, it is often necessary to have a strict policy about quotas; however, on the corporate side of that same organization, there are often different business requirements.
So, if you enjoy the cozy situation of being able to tell your users what quota they can have, in all circumstances, more power to you, but I don't think this is typical in the "real world". And, in a sense, it needen't always be. If more disk space is what whoever the most important users in your organization "need" to get their work done in a way that's comfortable for them, it may well be the case that this is exactly what you'll need to provide for them -- especially if the organization is willing to fund the hardware necessary to support larger quotas for some, or all, users.
Again, even if the quota policy is strict, it's not always the case that users understand the error message they get, even if their MUA presents it in a friendly way.
In many cases, users aren't able to delete mail to get under their (hard) quota without having the quota raised temporarily. If their mail client deletes by copying messages into the trash, then purging, for example, I've seen cases where the only way for the user to trim down their usage is to temporarily increase the quota long enough for them to get their usage down.
Some environments (and some users) require a more "high touch" approach than others.
What is the use of 'quota' if the admin raises your quota when things are full?
One use is to prevent a mail loop or other problem affecting one or two users from filling up a storage volume. Another is so that usage requirements (and exceptions to default quotas) can be tracked.
Regardless of how individual organizations handles quotas, I don't see how having Dovecot log an over quota event would be a bad thing.
w
Am 11.08.2014 um 22:44 schrieb Will Yardley:
- In many cases, users aren't able to delete mail to get under their (hard) quota without having the quota raised temporarily. If their mail client deletes by copying messages into the trash, then purging, for example, I've seen cases where the only way for the user to trim down their usage is to temporarily increase the quota long enough for them to get their usage down
that is all fine and true but that don't change the fact that if there is 'no space left on device' someone did not do his job properly and a full disk happens all 10 years
do you really think that a mailservers job is to handle that all 10 years happening mistake special? why?
Luuk dovecot@vosslamber.nl hat am 10. August 2014 um 18:24 geschrieben: Quota should be set according to some rules, and never be raised because of a 'quota reached'. What is the use of 'quota' if the admin raises your quota when things are full?
Guys, you are mixing up user quota and the "disk full" or better "no space left on device" situation. The whole point of my question or rather "feature request" was, to change the behavior of Dovecot when the whole disk (read: affects all users,regardless of their set quota and its current usage) is full and there is no space left to store any new messages.
Dovecot already does support to either reject or defer on a reached quota of a particular user. The problem I was talking about is the agreeably rather seldom admin f&$"-up of not properly maintaining the disk space or any other resource. But in the end, I hate to punish users (a.k.a "people") and send them looking for their bounced email because of this very temporary problem.
Regards
Christian
On 10.8.2014 06:18, Will Yardley wrote:
On Sun, Aug 10, 2014 at 01:31:47AM +0300, Timo Sirainen wrote:
Problems that admins can solve are temporary errors for users and the'll need an error logged. Problems that are caused by users themselves (like over quota) are usually not temporary errors and they shouldn't have errors logged (since admin can't usually do anything about them anyway).
Depends on the environment; in many cases, the admin could, or may even be expected to, raise the quota.
If you're expected to raise the quota in case it's exceeded, don't set it in the first place, there is no point to it. Or - if you really want that exercise in futility - use quota_warning and raise it automatically.
As for running out of disk space completely - well I assume you're using some kind of monitoring service, so just add a check for free disk space and you're done. There's really no need to cover this in Dovecot.
On -10.01.-28163 20:59, Jiri Bourek wrote:
On 10.8.2014 06:18, Will Yardley wrote:
Depends on the environment; in many cases, the admin could, or may even be expected to, raise the quota.
If you're expected to raise the quota in case it's exceeded, don't set it in the first place, there is no point to it. Or - if you really want that exercise in futility - use quota_warning and raise it automatically.
Where exactly did you read "automatically"?
Users need reminders not to be disk hogs. Managers want to be asked before company resources get allocated. Sysadmins may want to verify that it's actually the *user* using the disk space and not some software or e-mail problem. Quotas and their getting exceeded provide a hook for all these (non computer-only) procedures, even if the quota eventually *does* get raised for all cases of proper need.
As for running out of disk space completely - well I assume you're using some kind of monitoring service, so just add a check for free disk space and you're done. There's really no need to cover this in Dovecot.
dovecot already has code to detect this situation because catching potential error conditions is what well-written software *does*. The request at hand is about how exactly it should propagate the error back to its client.
Regards, J. Bern
*NEU* - NEC IT-Infrastruktur-Produkte im http://www.linworks-shop.de/: Server--Storage--Virtualisierung--Management SW--Passion for Performance Jochen Bern, Systemingenieur --- LINworks GmbH http://www.LINworks.de/ Postfach 100121, 64201 Darmstadt | Robert-Koch-Str. 9, 64331 Weiterstadt PGP (1024D/4096g) FP = D18B 41B1 16C0 11BA 7F8C DCF7 E1D5 FAF4 444E 1C27 Tel. +49 6151 9067-231, Zentr. -0, Fax -299 - Amtsg. Darmstadt HRB 85202 Unternehmenssitz Weiterstadt, Geschäftsführer Metin Dogan, Oliver Michel
On 12.8.2014 13:04, Jochen Bern wrote:
On -10.01.-28163 20:59, Jiri Bourek wrote:
On 10.8.2014 06:18, Will Yardley wrote:
Depends on the environment; in many cases, the admin could, or may even be expected to, raise the quota.
If you're expected to raise the quota in case it's exceeded, don't set it in the first place, there is no point to it. Or - if you really want that exercise in futility - use quota_warning and raise it automatically.
Where exactly did you read "automatically"?
Users need reminders not to be disk hogs. Managers want to be asked before company resources get allocated. Sysadmins may want to verify that it's actually the *user* using the disk space and not some software or e-mail problem. Quotas and their getting exceeded provide a hook for all these (non computer-only) procedures, even if the quota eventually *does* get raised for all cases of proper need.
You can do all of those things as a reaction to quota_warning e-mail sent to you _before_ the account exceeds its quota. No need to hit the error path by actually exceeding the quota.
On 08/10/2014 12:31 AM, Timo Sirainen wrote:
On 10 Aug 2014, at 01:19, Timo Sirainen tss@iki.fi wrote:
I'd really like to hear Timo's view on having lmtp do a (configurable) DEFER when the disk is full which is, most likely, a "temporary" error.
My opinion: It shouldn't be configurable - it should always cause temporary error. The only thing I'm slightly worried about is if write failures because of "user's filesystem quota full" will always return EDQUOT error for write() instead of ENOSPC, but I suppose they will in any modern OS. And it would require changing MAIL_ERROR_NOSPACE definition a bit inside Dovecot, but that's less of an issue.
And a bit more generic statement about anything related to errors in Dovecot:
Problems that admins can solve are temporary errors for users and the'll need an error logged. Problems that are caused by users themselves (like over quota) are usually not temporary errors and they shouldn't have errors logged (since admin can't usually do anything about them anyway).
Do you plan to support MTA queries about mailbox status (overquota,no space left on device)? It would allow MTA to deploy its own policies before sending "RCPT TO:" reply. "Socket map" protocol may be handy.
On 12.8.2014 00:42, Andrzej A. Filip wrote:
On 08/10/2014 12:31 AM, Timo Sirainen wrote:
On 10 Aug 2014, at 01:19, Timo Sirainen tss@iki.fi wrote:
I'd really like to hear Timo's view on having lmtp do a (configurable) DEFER when the disk is full which is, most likely, a "temporary" error.
My opinion: It shouldn't be configurable - it should always cause temporary error. The only thing I'm slightly worried about is if write failures because of "user's filesystem quota full" will always return EDQUOT error for write() instead of ENOSPC, but I suppose they will in any modern OS. And it would require changing MAIL_ERROR_NOSPACE definition a bit inside Dovecot, but that's less of an issue.
And a bit more generic statement about anything related to errors in Dovecot:
Problems that admins can solve are temporary errors for users and the'll need an error logged. Problems that are caused by users themselves (like over quota) are usually not temporary errors and they shouldn't have errors logged (since admin can't usually do anything about them anyway).
Do you plan to support MTA queries about mailbox status (overquota,no space left on device)? It would allow MTA to deploy its own policies before sending "RCPT TO:" reply. "Socket map" protocol may be handy.
This is already supported for Postfix. Look for quota-status policy service.
participants (10)
-
Andrzej A. Filip
-
Christian Rohmann
-
Jiri Bourek
-
Jochen Bern
-
Luuk
-
Moritz Augsburger
-
Reindl Harald
-
Rick Romero
-
Timo Sirainen
-
Will Yardley