On 2010-02-18 3:51 AM, Steffen Kaiser wrote:

On Sun, 14 Feb 2010, Joachim Boltz wrote:

...

This is a important for me because sometimes users are lazy. They think "oh, still 10% left, no reason to delete mail" while in the meantime large messages are already bounced, while some small ones arrive in the

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.

Then, obviously, from that point on, delivery will fail until the user deals with their over quota issue.

--

Best regards,

Charles

On 18 February 2010 16:20, Timo Sirainen tss@iki.fi 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

On 18 February 2010 16:41, Timo Sirainen tss@iki.fi 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

-----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 mail@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. <joke>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.</joke>

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

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

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

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

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

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