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 at 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. -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 197 bytes Desc: This is a digitally signed message part URL: <http://dovecot.org/pipermail/dovecot/attachments/20080929/b7341c32/attachment-0002.bin>
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=10No 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