[Dovecot] few questions about 1.1*
Hi!
I'm testing 1.1, and have some questions. (How) Can I override the default maildir++ quota setting (I mean quota_rule) in the userdb, so that one won't have quota at all. Right now I'm setting a very high limit in the userdb with quota_rule=*:storage=99G in the extra field.
Prior to 1.1 I was using 1.0 and had fs quota. I've had set up dovecot so that the indexes were stored on another partition where there were no fs quotas for the users. Now I'm trying to use maildir++ quota, and wondering if there is still any use of keeping the index files on a separate partition.
This will be maybe a bit stupid, but do I still need the quota plugin to be loaded in the protocol {imap,pop3,lda} sections if I'm using the above mentioned new 1.1 maildir++ quota? Furthermore, will deliver be aware of the new quota system?
Thanks!
Daniel
On Thu, 2007-10-25 at 11:42 +0200, Daniel wrote:
I'm testing 1.1, and have some questions. (How) Can I override the default maildir++ quota setting (I mean quota_rule) in the userdb, so that one won't have quota at all. Right now I'm setting a very high limit in the userdb with quota_rule=*:storage=99G in the extra field.
storage=0
Prior to 1.1 I was using 1.0 and had fs quota. I've had set up dovecot so that the indexes were stored on another partition where there were no fs quotas for the users. Now I'm trying to use maildir++ quota, and wondering if there is still any use of keeping the index files on a separate partition.
Probably not, although if it's in a separate disk you might get better performance.
This will be maybe a bit stupid, but do I still need the quota plugin to be loaded in the protocol {imap,pop3,lda} sections if I'm using the above mentioned new 1.1 maildir++ quota?
Yes, quota support exists only in the quota plugin so it needs to be loaded.
Furthermore, will deliver be aware of the new quota system?
Yes (or not specifically, because it's all handled in generic mail handling code).
On 2007. October 26. 16:12.08 Timo Sirainen wrote:
On Thu, 2007-10-25 at 11:42 +0200, Daniel wrote:
I'm testing 1.1, and have some questions. (How) Can I override the default maildir++ quota setting (I mean quota_rule) in the userdb, so that one won't have quota at all. Right now I'm setting a very high limit in the userdb with quota_rule=*:storage=99G in the extra field.
storage=0 The strange thing is that the new settings won't get applied (I mean I can not override my default config). I have this in my dovecot.conf:
plugin { quota = maildir quota_rule = *:storage=100M quota_rule2 = Trash:storage=50M }
and here is snippet from my userdb:
leva::uid:gid:gecos:home::quota_rule=*:storage=0
Still, when I log in, I get this in my dovecot log:
Info: IMAP(leva): Quota rule: root= mailbox= storage=102400kB messages=0 Info: IMAP(leva): Quota rule: root= mailbox=Trash storage=51200kB messages=0
Prior to 1.1 I was using 1.0 and had fs quota. I've had set up dovecot so that the indexes were stored on another partition where there were no fs quotas for the users. Now I'm trying to use maildir++ quota, and wondering if there is still any use of keeping the index files on a separate partition.
Probably not, although if it's in a separate disk you might get better performance.
Okay, thanks!
This will be maybe a bit stupid, but do I still need the quota plugin to be loaded in the protocol {imap,pop3,lda} sections if I'm using the above mentioned new 1.1 maildir++ quota?
Yes, quota support exists only in the quota plugin so it needs to be loaded.
Thanks, acknowledged.
Furthermore, will deliver be aware of the new quota system?
Yes (or not specifically, because it's all handled in generic mail handling code).
I meant that will Deliver totally ignore the quota, and deliver the mails no matter how many bytes they are consuming, or will it bounce(or maybe something else?) back the mail to the MTA if the destination user is over quota?
Thanks!
Daniel
and here is snippet from my userdb:
leva::uid:gid:gecos:home::quota_rule=*:storage=0
userdb_quota_rule if you have it in passwd-file.
Furthermore, will deliver be aware of the new quota system?
Yes (or not specifically, because it's all handled in generic mail handling code). I meant that will Deliver totally ignore the quota, and deliver the mails no matter how many bytes they are consuming, or will it bounce(or maybe something else?) back the mail to the MTA if the destination user is over quota?
It'll bounce (or tempfail with quota_full_tempfail=yes). If you don't want that, don't load the quota plugin.
On 2007. October 26. 17:27.55 Timo Sirainen wrote:
and here is snippet from my userdb:
leva::uid:gid:gecos:home::quota_rule=*:storage=0
userdb_quota_rule if you have it in passwd-file. Oh thanks, how clever of me; I didn't notice that there is even a userdb_mail extra field in one the accounts... :\
Furthermore, will deliver be aware of the new quota system?
Yes (or not specifically, because it's all handled in generic mail handling code).
I meant that will Deliver totally ignore the quota, and deliver the mails no matter how many bytes they are consuming, or will it bounce(or maybe something else?) back the mail to the MTA if the destination user is over quota?
It'll bounce (or tempfail with quota_full_tempfail=yes). If you don't want that, don't load the quota plugin. Yes, I definitely want this!
Thanks again!
Daniel
On Fri, Oct 26, 2007 at 06:27:55PM +0300, Timo Sirainen wrote:
It'll bounce (or tempfail with quota_full_tempfail=yes). If you don't want that, don't load the quota plugin.
It would be interesting if deliver could toggle a field in some database once the user is over quota, so the inbound MTA can query it and reject e-mail upfront, instead of accepting it and bouncing.
Just thinking out loud... :-)
GeertOn Sat, 2007-10-27 at 11:05 +0200, Geert Hendrickx wrote:
On Fri, Oct 26, 2007 at 06:27:55PM +0300, Timo Sirainen wrote:
It'll bounce (or tempfail with quota_full_tempfail=yes). If you don't want that, don't load the quota plugin.
It would be interesting if deliver could toggle a field in some database once the user is over quota, so the inbound MTA can query it and reject e-mail upfront, instead of accepting it and bouncing.
It wouldn't be difficult to implement a plugin that does it. It would hook into save_init() and save_finish() functions and update database depending on if the saving succeeds or fails.
participants (3)
-
Daniel
-
Geert Hendrickx
-
Timo Sirainen