[Dovecot] Managesieve Quota
Has anyone (is anyone) working on adding quota support to dovecot's managesieve server? I was thinking about giving it a shot myself and I'd hate to duplicate work. It would be something very basic like a max bytes setting and the total sieve storage per user isn't allowed to exceed it.
~Seth
Seth Mattinen schreef:
Has anyone (is anyone) working on adding quota support to dovecot's managesieve server? I was thinking about giving it a shot myself and I'd hate to duplicate work. It would be something very basic like a max bytes setting and the total sieve storage per user isn't allowed to exceed it.
It is on my TODO list as you can see in the package's TODO file. However, currently, finishing the first release of the new Sieve implementation has priority.
Regards,
-- Stephan Bosch
Mail: s.bosch@utwente.nl Room: Zi 4006
On Thu, 2008-09-25 at 09:40 -0700, Seth Mattinen wrote:
Has anyone (is anyone) working on adding quota support to dovecot's managesieve server? I was thinking about giving it a shot myself and I'd hate to duplicate work. It would be something very basic like a max bytes setting and the total sieve storage per user isn't allowed to exceed it.
I think it would be nice to be able to use the standard quota plugin with managesieve so that all the same backends and configuration could be used. The main problem I see is:
Does anyone want (or need) to have the mail and sieve quota shared, instead of specifying separate limits for them?
With shared quota the code will probably have to have some kind of sieve hardcoding or write some kind of state files so it knows where to look when recalculating quota. So preferrably no-one needs this. :)
So without shared quota they could be configured as "sievestorage" and "sievefiles" which would also be visible using IMAP quota commands. Configuration could go like:
quota = dict:::proxy::quota quota_rule = *:storage=100M:sievestorage=1M:sievefiles=10
I guess this would currently complain about "sievestorage" and "sievefiles" being unknown settings, so perhaps the idea would still need some more thinking. I suppose the idea of showing the sieve quota in IMAP process could be dropped and instead the quota_rule would just be different for IMAP and managesieve processes with both using storage/messages limits.
And of course the quota plugin would need to be modified so that it supports counting arbitrary files instead of only messages.
Timo Sirainen wrote:
On Thu, 2008-09-25 at 09:40 -0700, Seth Mattinen wrote:
Has anyone (is anyone) working on adding quota support to dovecot's managesieve server? I was thinking about giving it a shot myself and I'd hate to duplicate work. It would be something very basic like a max bytes setting and the total sieve storage per user isn't allowed to exceed it.
I think it would be nice to be able to use the standard quota plugin with managesieve so that all the same backends and configuration could be used. The main problem I see is:
Does anyone want (or need) to have the mail and sieve quota shared, instead of specifying separate limits for them?
With shared quota the code will probably have to have some kind of sieve hardcoding or write some kind of state files so it knows where to look when recalculating quota. So preferrably no-one needs this. :)
So without shared quota they could be configured as "sievestorage" and "sievefiles" which would also be visible using IMAP quota commands. Configuration could go like:
quota = dict:::proxy::quota quota_rule = *:storage=100M:sievestorage=1M:sievefiles=10
No need for sharing from me. (In fact, I don't use mail quotas at all.) My only goal is to have some kind of sieve quota to prevent someone from filling the filesystem with garbage either intentionally or through a baldy written client.
~Seth
On Mon, 2008-09-29 at 10:01 -0700, Seth Mattinen wrote:
Timo Sirainen wrote:
On Thu, 2008-09-25 at 09:40 -0700, Seth Mattinen wrote:
Has anyone (is anyone) working on adding quota support to dovecot's managesieve server? I was thinking about giving it a shot myself and I'd hate to duplicate work. It would be something very basic like a max bytes setting and the total sieve storage per user isn't allowed to exceed it.
I think it would be nice to be able to use the standard quota plugin with managesieve so that all the same backends and configuration could be used. The main problem I see is:
Does anyone want (or need) to have the mail and sieve quota shared, instead of specifying separate limits for them?
With shared quota the code will probably have to have some kind of sieve hardcoding or write some kind of state files so it knows where to look when recalculating quota. So preferrably no-one needs this. :)
So without shared quota they could be configured as "sievestorage" and "sievefiles" which would also be visible using IMAP quota commands. Configuration could go like:
quota = dict:::proxy::quota quota_rule = *:storage=100M:sievestorage=1M:sievefiles=10
No need for sharing from me. (In fact, I don't use mail quotas at all.) My only goal is to have some kind of sieve quota to prevent someone from filling the filesystem with garbage either intentionally or through a baldy written client.
Maybe I'm overthinking the problem. There probably won't be more than a few scripts. It's probably simplest if the quota is always just recalculated by lstat()ing the files.
Timo Sirainen wrote:
Maybe I'm overthinking the problem. There probably won't be more than a few scripts. It's probably simplest if the quota is always just recalculated by lstat()ing the files.
Pretty much what I was thinking about doing. Calculate total size of the sieve scripts and compare it to a config setting. In watching my customers use Sieve, there is never more than a few scripts since Sieve only lets you have one script active at a time anyway. If they create more than one it's so they can test changes.
~Seth
On Tue, 2008-09-30 at 10:47 -0700, Seth Mattinen wrote:
Timo Sirainen wrote:
Maybe I'm overthinking the problem. There probably won't be more than a few scripts. It's probably simplest if the quota is always just recalculated by lstat()ing the files.
Pretty much what I was thinking about doing. Calculate total size of the sieve scripts and compare it to a config setting. In watching my customers use Sieve, there is never more than a few scripts since Sieve only lets you have one script active at a time anyway. If they create more than one it's so they can test changes.
I haven't looked at managesieve code, but it would also be nice if it wasn't possible to send it gigabytes of data and cause it to save it to disk and only after then check the quota. :)
Timo Sirainen wrote:
On Tue, 2008-09-30 at 10:47 -0700, Seth Mattinen wrote:
Timo Sirainen wrote:
Maybe I'm overthinking the problem. There probably won't be more than a few scripts. It's probably simplest if the quota is always just recalculated by lstat()ing the files.
Pretty much what I was thinking about doing. Calculate total size of the sieve scripts and compare it to a config setting. In watching my customers use Sieve, there is never more than a few scripts since Sieve only lets you have one script active at a time anyway. If they create more than one it's so they can test changes.
I haven't looked at managesieve code, but it would also be nice if it wasn't possible to send it gigabytes of data and cause it to save it to disk and only after then check the quota. :)
I have ;) That is currently possible as warned in the README and it definitely needs to be fixed.
Regards,
Stephan.
participants (4)
-
Seth Mattinen
-
Stephan Bosch
-
Stephan Bosch
-
Timo Sirainen