On Mon, 2007-09-10 at 10:55 -0400, Alan Ferrency wrote:
On Fri, 2007-08-31 at 17:42 -0400, Alan Ferrency wrote:
test@example.com:<snip>:3007:1000::/usr/boxes/username/example.com::userdb_mail=mbox:~/test^/.imap:INBOX=~/test userdb_uid=3007 userdb_gid=1000 userdb_home=/usr/boxes/username/example.com userdb_quota=dirsize:storage=100
Those userdb_uid/gid/home aren't needed.
This is a passdb file, used with userdb prefetch for pop and imap protocols (as well as being used directly as a userdb for the lda). They still aren't needed?
I think there isn't much point in using prefetch with passwd-file, because the information is already in memory and accessible with a fast hash table lookup. Having the information twice in the file eats more memory.
There was a reason I settled on using a prefetch userdb instead of a userdb passwd-file, but now I don't remember what it was. And looking at my conf, I am still using the userdb passwd-file later in the search path, to support deliver anyway, so it could most likely be improved.
I think this may have been related to file permissions: we didn't want to give all users read access to the userdb file after they've logged in, and prefetching allowed us to limit access to only the login/auth user. Running an smtpauth port for deliver kind of makes that a moot point anyway, though, so maybe we can clean things up a bit.
I am looking for support in the deliver lda for a "maximum message size" quota feature, which is configurable per user...
Well, I think you should rather put this to deliver itself. Otherwise you'd be limiting also IMAP APPEND command.
I don't really see the point of having this setting though. Why not have one global limit (which already exists in your SMTP server)?
Thanks.
Basically, we need this for backwards compatibility purposes, more than anything else.
We'd prefer to vendor-branch dovecot, so my current line of pursuit is using an external executable in the lda pipeline, only in cases when a per message limit is configured. I expect it would be far more efficient to put this inside dovecot, however.
Thanks, Alan Ferrency pair Networks, Inc. alan@pair.com