[Dovecot] Dovecot development status v1.0
Timo,
Regarding: http://www.dovecot.org/list/dovecot/2005-January/006144.html
I would like an estimate of where you are on the path to a released (dovecot-1.0). I have read your statement regarding the -stable series and am wondering when we see the first feature complete -beta of v1.0?
Thank for your hard efforts. I have been a happy customer for about a year.
Ray
On 4.6.2005, at 03:27, Raymond Lillard wrote:
I would like an estimate of where you are on the path to a released (dovecot-1.0). I have read your statement regarding the -stable series and am wondering when we see the first feature complete -beta of v1.0?
There are just two missing features:
Keyword support for maildir. Shouldn't take too long to code, but I no-one's really asked for it and there are still other things to do.
Master process split into 3 processes: config, log and master. And some other major changes to how all Dovecot's processes work together and how configuration is read, parsed and verified. This simplifies things a lot and makes it possible to do some nice things.
Some things this change makes possible are: processes die while starting. Instead it just won't try to start them
- Dovecot LDA won't need a separate config file anymore
- Config file process can be replaced, for example with one that reads it from SQL database
- Makes it much more easier to write support for having different configuration based on user, domain, ip-block or whatever
- Master process won't kill itself anymore if some of its child
for next 5 minutes
- Just in general it makes everything so much simpler and prettier :)
I've been implementing this slowly over the last few months. Takes annoyingly long (it's boring), but it's getting there. In the mean time IMAP and POP3 code in 1.0-tests keep stabilizing nicely. So after this one large change things may be a bit unstable for a while, but after that 1.0 should be very near :)
Timo Sirainen wrote:
There are just two missing features:
- Keyword support for maildir. Shouldn't take too long to code, but I no-one's really asked for it and there are still other things to do.
Is Keyword support the bit that allows my Thunderbird and Becky! users to 'label' their messages as important/personal/etc? If so, it's the one thing that's been stopping me from moving to 1.0...
-- Curtis Maloney
On Mon, Jun 06, 2005 at 01:36:10AM +0300, Timo Sirainen wrote:
There are just two missing features:
How about the mixing of Maildir and mbox? (See the thread I started previously at http://dovecot.org/pipermail/dovecot/2005-March/006390.html) Any steps in this direction? Could this be made easier after those changes?
It would be really a useful possibility - but I have had little time to deal with our IMAP recently (still running Dovecot 0.99), so I didn't do any real work towards it myself...
-- Tom
-- Tom Alsberg - hacker (being the best description fitting this space) Web page: http://www.cs.huji.ac.il/~alsbergt/ DISCLAIMER: The above message does not even necessarily represent what my fingers have typed on the keyboard, save anything further.
On 6.6.2005, at 09:30, Tom Alsberg wrote:
On Mon, Jun 06, 2005 at 01:36:10AM +0300, Timo Sirainen wrote:
There are just two missing features:
How about the mixing of Maildir and mbox? (See the thread I started previously at http://dovecot.org/pipermail/dovecot/2005-March/006390.html) Any steps in this direction? Could this be made easier after those changes?
These changes don't help that problem at all. I was thinking about leaving this after v1.0 as it would require pretty large changes. It would be a nice feature though.
09:43, lunedì 6 giugno 2005 - Timo Sirainen scrive: |> On 6.6.2005, at 09:30, Tom Alsberg wrote: |> > On Mon, Jun 06, 2005 at 01:36:10AM +0300, Timo Sirainen wrote: |> >> There are just two missing features: |> > |> > How about the mixing of Maildir and mbox? (See the thread I started |> > previously at |> > http://dovecot.org/pipermail/dovecot/2005-March/006390.html) |> > Any steps in this direction? Could this be made easier after those |> > changes? |> |> These changes don't help that problem at all. I was thinking about |> leaving this after v1.0 as it would require pretty large changes. It |> would be a nice feature though.
I just read the thread. I am not shure to understand the question.
I succesfully configured dovecot-1.0test68 so that the same user can have both a Mailbox and a Maildir and can access it by pop3, pop3s, imap and imaps protocols with the same password. I have not very large acconts (26 users for a total of 1.2 GBytes) but it is regularly running since the start of May.
If that is the problem I will be glad to post the details about my configuration; sorry for annoing instead.
Claudio
-- Claudio Succa PERTEL - Torino - Italy +39-011-437.4141 http://www.pertel.it http://www.uniassist.it http://www.progettocapolinea36.it
On Mon, 2005-06-06 at 11:40 +0200, Claudio Succa wrote:
|> > How about the mixing of Maildir and mbox? (See the thread I started |> > previously at |> > http://dovecot.org/pipermail/dovecot/2005-March/006390.html) |> > Any steps in this direction? Could this be made easier after those |> > changes? |> |> These changes don't help that problem at all. I was thinking about |> leaving this after v1.0 as it would require pretty large changes. It |> would be a nice feature though.
I just read the thread. I am not shure to understand the question.
I succesfully configured dovecot-1.0test68 so that the same user can have both a Mailbox and a Maildir and can access it by pop3, pop3s, imap and imaps protocols with the same password. I have not very large acconts (26 users for a total of 1.2 GBytes) but it is regularly running since the start of May.
You probably defined different namespaces for mboxes and maildirs?
What the thread was about was the ability to have a directory containing both mboxes and maildirs and Dovecot would detect itself when opening the mailbox if it's mbox or maildir, without any special configuration.
13:19, lunedì 6 giugno 2005 - Timo Sirainen scrive: |> On Mon, 2005-06-06 at 11:40 +0200, Claudio Succa wrote: |> > |> > I just read the thread. I am not shure to understand the question. |> > |> > I succesfully configured dovecot-1.0test68 so that the same user can |> > have both a Mailbox and a Maildir and can access it by pop3, pop3s, |> > imap and imaps protocols with the same password. I have not very large |> > acconts (26 users for a total of 1.2 GBytes) but it is regularly |> > running since the start of May. |> |> You probably defined different namespaces for mboxes and maildirs?
Yes.
|> |> What the thread was about was the ability to have a directory containing |> both mboxes and maildirs and Dovecot would detect itself when opening |> the mailbox if it's mbox or maildir, without any special configuration.
Ah. I read again the thread and finally understood its real meaning.
Thanks for your answer (and for Dovecot of course), Claudio
-- Claudio Succa PERTEL - Torino - Italy +39-011-437.4141 http://www.pertel.it http://www.uniassist.it http://www.progettocapolinea36.it
I've been implementing this slowly over the last few months. Takes annoyingly long (it's boring), but it's getting there. In the mean time IMAP and POP3 code in 1.0-tests keep stabilizing nicely. So after this one large change things may be a bit unstable for a while, but after that 1.0 should be very near :)
I personally think one small issue in the current dovecot is kind of a showstopper. If a user exceeded their quota, dovecot will just plain not work at all. So a user can also not delete their email to remedy the situation.
This is what happens when a customer (without previously having used dovecot) connects:
A002 SELECT "INBOX" A002 NO Internal error occured. Refer to server log for more information. [2005- 05-31 17:56:36]
The internal error is a 'quota exceeded'.
I think at the very minimum someone should be able to delete email...
Regards,
Cor
Cor Bosman wrote:
I've been implementing this slowly over the last few months. Takes annoyingly long (it's boring), but it's getting there. In the mean time IMAP and POP3 code in 1.0-tests keep stabilizing nicely. So after this one large change things may be a bit unstable for a while, but after that 1.0 should be very near :)
I personally think one small issue in the current dovecot is kind of a showstopper. If a user exceeded their quota, dovecot will just plain not work at all. So a user can also not delete their email to remedy the situation.
This is what happens when a customer (without previously having used dovecot) connects:
A002 SELECT "INBOX" A002 NO Internal error occured. Refer to server log for more information. [2005- 05-31 17:56:36]
The internal error is a 'quota exceeded'.
I think at the very minimum someone should be able to delete email...
Regards,
Cor
Cor,
I agree with you. I've resorted to having a script run to check quotas twice a day and sending notifications (I have a fairly large difference in soft and hard limits set) to each user that they are over their quota and what remaining grace time they have so they can remove mail from the server as appropriate.
On occassion I have to temporarily increase a user's quota just to allow them to connect and remove their email.
The problem as I see it, however, isn't specifically a Dovecot issue. the quotas are filesystem level quotas, and in order to move/delete/etc mail, the user would have to have persmissions to write files on the filesystem (which it does not). Obviously having the imap/pop3 portions of dovecot running as root is not an option.
It would be nice if dovecot had an application level quota facility, but I think it's been made pretty clear that it's not a priority feature at this time (correct me if i'm wrong, anybody)
Alan
This is what happens when a customer (without previously having used dovecot) connects:
A002 SELECT "INBOX" A002 NO Internal error occured. Refer to server log for more information. [2005- 05-31 17:56:36]
The internal error is a 'quota exceeded'.
I think at the very minimum someone should be able to delete email...
Regards,
Cor
Cor,
On occassion I have to temporarily increase a user's quota just to allow them to connect and remove their email.
Well, this really is not an option for us. We have 200.000+ customers. The administrative overhead is just too large.
The problem as I see it, however, isn't specifically a Dovecot issue. the quotas are filesystem level quotas, and in order to move/delete/etc mail, the user would have to have persmissions to write files on the filesystem (which it does not). Obviously having the imap/pop3 portions of dovecot running as root is not an option.
Well, it should be possible, after all UW can do it..and if they can...;) To delete a file, theoretically there should be no writing necessary. Just unlink the file and forget about updating indexes (btw, our indexes are on a seperate filesystem without quotas!). Actually it seemed dovecot wanted to create the dovecot-uidlist file, and barfed on not being able to do that.
Cor
On Mon, 2005-06-06 at 12:51 +0200, Cor Bosman wrote:
Well, it should be possible, after all UW can do it..and if they can...;) To delete a file, theoretically there should be no writing necessary. Just unlink the file and forget about updating indexes
It's not so simple, because the error could come at any point, even in the middle of updating indexes. I'd have to check all write operations and make sure they can correctly fallback to just keeping indexes in memory.
(btw, our indexes are on a seperate filesystem without quotas!). Actually it seemed dovecot wanted to create the dovecot-uidlist file, and barfed on not being able to do that.
This is another problem. Hmm. I tried to look up some of my older explanations for this, but couldn't. Well, here goes again:
Mails need to be assigned UIDs with IMAP. If the UIDs aren't written to dovecot-uidlist file, it's possible that different mails will get different UIDs between logins. This really confuses clients which have cached mails locally.
If we assumed that:
When maildir filenames are sorted, the newly arrived mails come always after old ones. Dovecot doesn't currently satisfy this requirement even itself, if multiple mails are saved within a second. Have to change that..
After user has expunged mails, there is space to write dovecot-uidlist file.
No new clients try to open the mailbox between expunging and dovecot-uidlist locking. (This requirement could be avoided by using fcntl() or similar locking.)
Then I think it *might* work correctly.
mbox has similar problem, but the solution is much easier and can probably be made fully working and race-free without any special conditions.
Anyway, you can specify different directory for dovecot-uidlist using :CONTROLDIR=path in default_mail_env.
On Tue, 2005-06-07 at 09:29 +0200, Cor Bosman wrote:
Anyway, you can specify different directory for dovecot-uidlist using :CONTROLDIR=path in default_mail_env.
Is there a known migration path for this? Can you instruct dovecot to first look in CONTROLDIR, and then in $MAIL and save the result in CONTROLDIR?
How about the included patch? Not tested, but Should Work. :)
On Mon, 2005-06-06 at 19:42 +0900, Alan Premselaar wrote:
It would be nice if dovecot had an application level quota facility, but I think it's been made pretty clear that it's not a priority feature at this time (correct me if i'm wrong, anybody)
There already exists a quota plugin which supports checking/enforcing quota just by summing up sizes of all files in user's mail directory. Not a very good idea to use with maildir. Other methods for keeping track of quota should be somewhat easy to implement on top of the quota plugin.
Cor Bosman wrote:
I've been implementing this slowly over the last few months. Takes annoyingly long (it's boring), but it's getting there. In the mean time IMAP and POP3 code in 1.0-tests keep stabilizing nicely. So after this one large change things may be a bit unstable for a while, but after that 1.0 should be very near :)
I personally think one small issue in the current dovecot is kind of a showstopper. If a user exceeded their quota, dovecot will just plain not work at all. So a user can also not delete their email to remedy the situation.
This is what happens when a customer (without previously having used dovecot) connects:
A002 SELECT "INBOX" A002 NO Internal error occured. Refer to server log for more information. [2005- 05-31 17:56:36]
The internal error is a 'quota exceeded'.
I think at the very minimum someone should be able to delete email...
Regards,
Cor
I think you may find it works (users can delete mail) if you put the Dovecot indexes on separate filesystem (preferably unquota'd). I haven't tested it, though. It seems to me that it is similar to the mailbox on a read-only filesystem case.
Best Wishes, Chris
--+---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+- Christopher Wakelin, c.d.wakelin@reading.ac.uk IT Services Centre, The University of Reading, Tel: +44 (0)118 378 8439 Whiteknights, Reading, RG6 2AF, UK Fax: +44 (0)118 975 3094
The internal error is a 'quota exceeded'.
I think at the very minimum someone should be able to delete email...
Regards,
Cor
I think you may find it works (users can delete mail) if you put the Dovecot indexes on separate filesystem (preferably unquota'd). I haven't tested it, though. It seems to me that it is similar to the mailbox on a read-only filesystem case.
We have indexes on a seperate local filesystem without quota. It seems the problem is with creating the dovecot-uidlist file in $MAIL.
Cor
Cor Bosman wrote:
I think you may find it works (users can delete mail) if you put the Dovecot indexes on separate filesystem (preferably unquota'd). I haven't tested it, though. It seems to me that it is similar to the mailbox on a read-only filesystem case.
We have indexes on a seperate local filesystem without quota. It seems the problem is with creating the dovecot-uidlist file in $MAIL.
Cor
Ah, Maildir! In that case, you need to add :CONTROL=/some/other/filesystem/%u or whatever in the "default_mail_env" (or "location" for namespaces) setting. It's not documented, but was mentioned in an earlier thread about read-only mailboxes.
Best Wishes, Chris
-- --+---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+- Christopher Wakelin, c.d.wakelin@reading.ac.uk IT Services Centre, The University of Reading, Tel: +44 (0)118 378 8439 Whiteknights, Reading, RG6 2AF, UK Fax: +44 (0)118 975 3094
I think you may find it works (users can delete mail) if you put the Dovecot indexes on separate filesystem (preferably unquota'd). I haven't tested it, though. It seems to me that it is similar to the mailbox on a read-only filesystem case.
We have indexes on a seperate local filesystem without quota. It seems the problem is with creating the dovecot-uidlist file in $MAIL.
Cor
Ah, Maildir! In that case, you need to add :CONTROL=/some/other/filesystem/%u or whatever in the "default_mail_env" (or "location" for namespaces) setting. It's not documented, but was mentioned in an earlier thread about read-only mailboxes.
We have about 20 servers that customers can connect to. We try and put them on the same server every time, but we cant guarentee that since servers can crash or whatever.
All servers mount an NFS filesystem with a maildir based $MAIL. Indexes are on a local FS, since most of the time customers do actually connect to the same server, and indexes on NFS are a nightmare anyways.
The dovecot-uidlist seems like it cant be on a local FS. So we'd have to create a completely seperate NFS filesystem without quotas so all our 200.000 customers can have 1 file on it? :) Well, if we have to we have to..but it seems there could be a better solution..
Cor
participants (8)
-
Alan Premselaar
-
Chris Wakelin
-
Claudio Succa
-
Cor Bosman
-
Curtis Maloney
-
Raymond Lillard
-
Timo Sirainen
-
Tom Alsberg