Re: [Dovecot] Poll: Quota near full behavior? [Was: Feature request? Make deliver quota inclusive!]
On Fri, 2010-02-19 at 06:10 -0500, Charles Marcus wrote: > > > I certainly wouldn't want to accept a message in this case, user > > might be 1K under quota, but get 20m file now that might be a > > whoopie doo :) but what if 130K users did same. > > Well, I'd argue that if you're allowing messages that big already for > 130K users, then you should have enough spare storage to handle such a > situation - although you and I both know the likelihood of even 10% of > those 130K users encountering such a situation is next to null, so I > don't think it's a valid argument. Storage is designed based on guaranteed quota storage for each user, plus anticipated growth Why should we suffer huge expense just so every user who maxes out their quota can exceed it? Your idea might be fine for a small home office, but when you deal with thousands of users, it is an insane configuration. > That said - in an enterprise environment like that, you'd be assigning > group and domain level quotas too to keep any one group/customer from > using up all of the storage on the server, right? No, think an ISP or University student mail system.
Re: [Dovecot] Poll: Quota near full behavior? [Was: Feature request? Make deliver quota inclusive!]
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 On Fri, 19 Feb 2010, Charles Marcus wrote: Ahh... so, this would only be a [potential] problem in the case of [a] user[s] that didn't login for a long time... and I guess you could even deal with that by some kind of nightly cron job... A cron job mailed me, if a spool files exceeded some limit. Then I needed to determine, why the user does not read the mails. It was a closed user group, no public service or something like that. Regards, - -- Steffen Kaiser -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.6 (GNU/Linux) iQEVAwUBS352SL+Vh58GPL/cAQLJyggAhcQqx+VOhY60eC8l9g+xEG8sEIztiM7H BbLYycBqd5h8nG+A0zPhq2YL7N1cCYQ4328pizaPx6uDlK0pulYY9hcf65BIRhBn hH3fRRxPyYq1AvI25PVob/xVHoo/u8l58VtiVE2L2Kd+fjNRHvbfIeIrcnUs6Ab8 nHKMPWrDlhNJZ6JPaYNcT4hxLJR/k3WGsamMx+ILsTkijEJzAqudPliKttBNcuK9 8Ticeb/gyoOIlpitXekajmg0iFBSm2xPGX/4CxL73aSygzy+S8yMjpCoydOzWROh /hS9RO/qPeUD6ySTZIslpJNj9HpZKpOh/q3drRom8EXx3vDp0daWKw== =F2Mk -END PGP SIGNATURE-
Re: [Dovecot] Poll: Quota near full behavior? [Was: Feature request? Make deliver quota inclusive!]
On 2010-02-19 3:16 AM, Steffen Kaiser wrote: > On Thu, 18 Feb 2010, Charles Marcus wrote: >> On 2010-02-18 11:09 AM, Steffen Kaiser wrote: >>> Actually, I once had a system where the request was "we do not >>> send over quota notices, all mails have to arrive". Hence, >>> deliver should have no quota - well, a very high quota actually >>> -, but a quite strick IMAP quota. >> So simply leaving everything in the INBOX defeats the quota? > Not directly. > > Incoming mails were spooled to /var/mail/user. Upon login via IMAP or > POP and when /var/mail/user changes those mails were slurped into > ~user/<> by the imap/pop server process. Ahh... so, this would only be a [potential] problem in the case of [a] user[s] that didn't login for a long time... and I guess you could even deal with that by some kind of nightly cron job... -- Best regards, Charles
Re: [Dovecot] Poll: Quota near full behavior? [Was: Feature request? Make deliver quota inclusive!]
On 2010-02-18 4:53 PM, Noel Butler wrote: >>> Personally I think the best way would be, if the user isn't over >>> quota at the time of a message delivery, deliver that message, >>> *regardless* of whether or not it puts the user over quota. >> Wonder if there's anyone who wouldn't want this behavior? One >> exception could be that if mail is larger than the user's entire >> quota limit, it wouldn't be accepted. And this would happen only >> for deliver/lmtp, not imap append (because it would give user an >> error message directly). > I certainly wouldn't want to accept a message in this case, user > might be 1K under quota, but get 20m file now that might be a > whoopie doo :) but what if 130K users did same. Well, I'd argue that if you're allowing messages that big already for 130K users, then you should have enough spare storage to handle such a situation - although you and I both know the likelihood of even 10% of those 130K users encountering such a situation is next to null, so I don't think it's a valid argument. That said - in an enterprise environment like that, you'd be assigning group and domain level quotas too to keep any one group/customer from using up all of the storage on the server, right? -- Best regards, Charles
Re: [Dovecot] Poll: Quota near full behavior? [Was: Feature request? Make deliver quota inclusive!]
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 On Thu, 18 Feb 2010, Charles Marcus wrote: On 2010-02-18 11:09 AM, Steffen Kaiser wrote: Actually, I once had a system where the request was "we do not send over quota notices, all mails have to arrive". Hence, deliver should have no quota - well, a very high quota actually -, but a quite strick IMAP quota. So simply leaving everything in the INBOX defeats the quota? Not directly. Incoming mails were spooled to /var/mail/user. Upon login via IMAP or POP and when /var/mail/user changes those mails were slurped into ~user/<> by the imap/pop server process. So the users saw at most as many mails that would fit into the filesystem quota. This setup ditched for large mails sometimes, because the slurp worked strictly sequentially. Regards, - -- Steffen Kaiser -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.6 (GNU/Linux) iQEVAwUBS35I37+Vh58GPL/cAQIzjQf/boOMd/7YN4YO4FoRw4XrN/UU7fS9/fvZ HvSShMhPygavUdN/appmd7Ee/4drO6Ck93UG6FOt8kGHk9XDkwGOf8rHLZZ9uNsZ hpTCvZjVO77h4s9jxEDchlJVKKJJvDL5g1rQtt8SQtO4MVqdzxwvC97W4txB3VnT bQqDKa9PPRwQNjJ/7YpkIcx5gYTyWarC4AiLPDxzbyaEt8iyukY7TPf8p4TCLHnr WgaPho6hSm3LtbHUjpf0mAo9/pFVXeDiNeX6UYYrx5iiHCi7Jhg4CMHx/LUEK2DH PEokT7MhyIoTLRiYJnZ/TgojGWDpvxoXtECzluWpkWmAt2aK+o3UxQ== =3Pud -END PGP SIGNATURE-
Re: [Dovecot] Poll: Quota near full behavior? [Was: Feature request? Make deliver quota inclusive!]
On Thu, 2010-02-18 at 16:20 +0200, Timo Sirainen wrote: > On Thu, 2010-02-18 at 09:05 -0500, Charles Marcus wrote: > > Personally I think the best way would be, if the user isn't over quota > > at the time of a message delivery, deliver that message, *regardless* of > > whether or not it puts the user over quota. > > Wonder if there's anyone who wouldn't want this behavior? One exception > could be that if mail is larger than the user's entire quota limit, it > wouldn't be accepted. And this would happen only for deliver/lmtp, not > imap append (because it would give user an error message directly). I certainly wouldn't want to accept a message in this case, user might be 1K under quota, but get 20m file now that might be a whoopie doo :) but what if 130K users did same. -- Kind Regards, SSA Noel Butler L.C.P No. 251002 This Email, including any attachments, may contain legally privileged information, therefore remains confidential and subject to copyright protected under international law. You may not disseminate or reveal any part to anyone without the authors express written authority to do so. If you are not the intended recipient, please notify the sender and delete all relevance of this message including any attachments, immediately. Confidentiality, copyright, and legal privilege are not waived or lost by reason of the mistaken delivery of this message. Only PDF and ODF documents are accepted, do not send Microsoft proprietary formatted documents.
Re: [Dovecot] Poll: Quota near full behavior? [Was: Feature request? Make deliver quota inclusive!]
On 2010-02-18 11:09 AM, Steffen Kaiser wrote: > Actually, I once had a system where the request was "we do not send over > quota notices, all mails have to arrive". Hence, deliver should have no > quota - well, a very high quota actually -, but a quite strick IMAP quota. So simply leaving everything in the INBOX defeats the quota?
Re: [Dovecot] Poll: Quota near full behavior? [Was: Feature request? Make deliver quota inclusive!]
On 18 February 2010 16:41, Timo Sirainen wrote: > It's not about how much work adding that setting is. It's that I don't > think there should be settings for stuff that (almost) everyone sets > only one way. Useless extra settings cause bugs and bloat, both to code > and documentation. Understood and in agreement. Since I always switch it on in my MTA, I vote to make deliver quota inclusive. .warren
Re: [Dovecot] Poll: Quota near full behavior? [Was: Feature request? Make deliver quota inclusive!]
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 On Thu, 18 Feb 2010, Charles Marcus wrote: But in the modern age, just delivering mail until the quota is exceeded then rejecting seems to be the simplest thing to do, and imo should be the default... You change the "quota" from a (hard) limit to a (soft) suggestion that way. As I said, I agree with you. happy, but why complicate things unnecessarily? It is really simple... Actually, I once had a system where the request was "we do not send over quota notices, all mails have to arrive". Hence, deliver should have no quota - well, a very high quota actually -, but a quite strick IMAP quota. Regards, - -- Steffen Kaiser -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.6 (GNU/Linux) iQEVAwUBS31mJ7+Vh58GPL/cAQLLLQf/Vxy0mIxhXqq/0aJZyUmFRvax5XWs47TD G09OElD2V/TKg7JTlkINDfpxputjhXH7uVoZ7+Hza2KPimdokdO12zh6XoBLnpFp QStHyh/gADcBFISDxslVGdwVwXUT9pN8Ou22NEHgU/J8klscxS3yhBKZVt5HwfOQ W+vZfPwgq/iYSRCyZOUEcFnRQxgqhLXny0dv6opfChBW2x/ubGkqMoBGSB1u0gTN KVfOKkV3C5Qz5RfxalV5J4g9oVo8XTTgy4Jf4T+dPtzK59OQ/sHPP/F04RyODGS8 f+Mjulzh6u4ZDvfpWkUdkB4FAh4TeYHmec/H+ecefdga4qUz7NdAsA== =+CFH -END PGP SIGNATURE-
Re: [Dovecot] Poll: Quota near full behavior? [Was: Feature request? Make deliver quota inclusive!]
On 2010-02-18 9:57 AM, Steffen Kaiser wrote: > But I'd like the "deliver a message if user is under quota and the > message is smaller than quota". > Or an option "deliver may exceed the quota by X", sort of like the > quota_rules for Trash, but for the service. Possible not all scenarios > can tweak a special .conf for deliver containing increased quota_rules. As long as this is configurable, that should be enough to make everyone happy, but why complicate things unnecessarily? It is really simple... User has quota assigned User allows mail to pile up Eventually, a message is delivered that puts user over quota Mail is rejected until user deals with over quota state Why put the LDA to all the work of calculating if one message will cause user to go over quota but not another? Even worse is calculating a certain 'allowance' of over quota... The only time I can see this being an issue is when the quota in question is ridiculously low (10MB?), where the user could receive a whole lot of tiny text messages, but one message with a fairly large attachment could take up the whole quota. But in the modern age, just delivering mail until the quota is exceeded then rejecting seems to be the simplest thing to do, and imo should be the default...
Re: [Dovecot] Poll: Quota near full behavior? [Was: Feature request? Make deliver quota inclusive!]
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 On Thu, 18 Feb 2010, Timo Sirainen wrote: On Thu, 2010-02-18 at 15:57 +0100, Steffen Kaiser wrote: But I'd like the "deliver a message if user is under quota and the message is smaller than quota". The current behavior? Is that what you really meant? Oh, I left out one word: "if the user is under quota currently" aka before delivery. Actually your idea. I just rephrased to emphase, that now the before-deliver situation is tested and not the final one and that you have already forseen the case, that a message is unable to fit into the mailbox at all. Latter reminds me to possibly change my "over quota" reply into: "user over quota or message too large". Or an option "deliver may exceed the quota by X", sort of like the quota_rules for Trash, but for the service. That should be possible already. But it's not really the same as "allow one mail to exceed quota". I think not. You can craft a special .conf for deliver, but you can increase the quota programmatically only in SQL or in dovecot.conf, but not for the other user DBs. And because of Sieve's fileinto, you cannot add a quota_rule just for INBOX, but you would need to alter (increase) the general, basic quota. It's not the same, but it would come close enough :) When the "service" deliver has a quota exception, an user cannot exploit the exception directly. Regards, - -- Steffen Kaiser -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.6 (GNU/Linux) iQEVAwUBS31f9r+Vh58GPL/cAQKjQQf/cb8KOJj96JzCZXKNAZtkOeoTb9bMErft +T+V0oO+mXoir66uHOakMDSlGRV4avUhkyo0vGTdqPNVqJjluvoyPbf/+RBgcImx wJX7apv5S8ve/++etCLUiPV5IFcqi+IYrQqbsBuoqFfoCd7I4eBBBz3U+3og5WzY djxW3GCNeVsO4sLGNk6sa/bJPAEQq2emDbQr2GeUwQgQrX8RRHG9yQqGO4izi4r1 +zIdghqn4C+SILTa4jpUFgzhoup5DdVdX8+biliQ3RoVGSRQ2fqftzzWkQ7+ZFvt JPT30C/axteE3qJWxKsp4nXL/tSgzxet3Gj5HNvBC2BeMTLGzQvDNg== =kkmZ -END PGP SIGNATURE-
Re: [Dovecot] Poll: Quota near full behavior? [Was: Feature request? Make deliver quota inclusive!]
On Thu, 2010-02-18 at 15:57 +0100, Steffen Kaiser wrote: > But I'd like the "deliver a message if user is under quota and the message > is smaller than quota". The current behavior? Is that what you really meant? > Or an option "deliver may exceed the quota by X", sort of like the > quota_rules for Trash, but for the service. That should be possible already. But it's not really the same as "allow one mail to exceed quota". signature.asc Description: This is a digitally signed message part
Re: [Dovecot] Poll: Quota near full behavior? [Was: Feature request? Make deliver quota inclusive!]
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 On Thu, 18 Feb 2010, Sven Eulberg wrote: Over quota is over quota... Perhaps it's better to drop a line in the user's inbox e.g. 'mail from m...@address.com rejected because there was not enough space in your inbox...' or something else. So both sender AND recipient are informed and I'm sure the owner will THEN tidy up his mailbox. :-) Well, wait long enough and those messages fill the partition. Moreover, if it is spooled, the message gets delivered more than once. One could count the unique, failed messages and then display a virtual message: "Since you've last read this notification message at 2010-02-13 23:23, 327 messages could not spooled into your INBOX, because you are over quota." When it is read (not seen), the count resets. But I'd like the "deliver a message if user is under quota and the message is smaller than quota". Or an option "deliver may exceed the quota by X", sort of like the quota_rules for Trash, but for the service. Possible not all scenarios can tweak a special .conf for deliver containing increased quota_rules. Regards, - -- Steffen Kaiser -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.6 (GNU/Linux) iQEVAwUBS31Vab+Vh58GPL/cAQIZaggAgkRAjrNbYLSSddqMmVLoV+IvBZuqPfpq TzOdDRE2BOndvKWhxf3qnZxw5gwYImfDRUYD9//GfKFR1jEjJ3Nd8kobdsY5g4Px WIfvzPoYtcsemeWDI4PNnJJsSa/gozUVRMdtjUrVF4/Pj9rD04uevGLJfNRdnHbW RNYD511UW96nkgV7iHlfk7rvQremVaShLadHlcBAITDH58xPl8YO+wjNmHaBF+hU BMiiufOHdpMb2DnONhpJkNFZCo53uQ3KXRhZeMsUFj0yIcJKFKhetDl9CZ51P0L8 jYznDTbQzxzPVwn/S5cI4IA7m0kYTEIFwTpuoZQJsmgIvphwhyZaBQ== =M9kd -END PGP SIGNATURE-
Re: [Dovecot] Poll: Quota near full behavior? [Was: Feature request? Make deliver quota inclusive!]
> On Thu, 2010-02-18 at 09:05 -0500, Charles Marcus wrote: >> Personally I think the best way would be, if the user isn't over quota >> at the time of a message delivery, deliver that message, *regardless* of >> whether or not it puts the user over quota. > > Wonder if there's anyone who wouldn't want this behavior? One exception > could be that if mail is larger than the user's entire quota limit, it > wouldn't be accepted. And this would happen only for deliver/lmtp, not > imap append (because it would give user an error message directly). > Over quota is over quota... Perhaps it's better to drop a line in the user's inbox e.g. 'mail from m...@address.com rejected because there was not enough space in your inbox...' or something else. So both sender AND recipient are informed and I'm sure the owner will THEN tidy up his mailbox.
Re: [Dovecot] Poll: Quota near full behavior? [Was: Feature request? Make deliver quota inclusive!]
On Thu, 2010-02-18 at 16:29 +0200, Warren Baker wrote: > I am not sure how much work it would involve but I would prefer to > have a config option to either disable or enable the behaviour. It's not about how much work adding that setting is. It's that I don't think there should be settings for stuff that (almost) everyone sets only one way. Useless extra settings cause bugs and bloat, both to code and documentation. signature.asc Description: This is a digitally signed message part
Re: [Dovecot] Poll: Quota near full behavior? [Was: Feature request? Make deliver quota inclusive!]
On 18 February 2010 16:20, Timo Sirainen wrote: > > Wonder if there's anyone who wouldn't want this behavior? One exception > could be that if mail is larger than the user's entire quota limit, it > wouldn't be accepted. And this would happen only for deliver/lmtp, not > imap append (because it would give user an error message directly). I am not sure how much work it would involve but I would prefer to have a config option to either disable or enable the behaviour. Much like Exim's 'quota_is_inclusive' transport setting. With this setting set to false, Exim accepts all messages until the quota has been exceeded. When set to true (default setting) it calculates the current message size and rejects it if it pushes the user over quota. .warren
[Dovecot] Poll: Quota near full behavior? [Was: Feature request? Make deliver quota inclusive!]
On Thu, 2010-02-18 at 09:05 -0500, Charles Marcus wrote: > Personally I think the best way would be, if the user isn't over quota > at the time of a message delivery, deliver that message, *regardless* of > whether or not it puts the user over quota. Wonder if there's anyone who wouldn't want this behavior? One exception could be that if mail is larger than the user's entire quota limit, it wouldn't be accepted. And this would happen only for deliver/lmtp, not imap append (because it would give user an error message directly). signature.asc Description: This is a digitally signed message part
