I think I won't do any actual releases until it's mostly feature complete. Then maybe v1.1.alpha1 or v1.1.beta1. So if you want to test it before then, use CVS or the nightly snapshots.
I'm planning on keeping v1.1 almost completely compatible with v1.0. There could be some minor configuration file changes, but for most people v1.0's dovecot.conf should work with v1.1.
I want to update index file handling to use less locks and update dovecot.index file less often. The file formats would still stay backwards compatible with v1.0. After this I'm hoping to get index files working well with NFS even with attribute cache enabled.
Dovecot v2.0 then brings incompatible index files and more or less rewritten configuration file handling. It could still support old config file format and settings, but the default will be somewhat different.
I'm hoping to release the first alphas/betas in 2-3 months, with v1.1.0 maybe even as early as next summer. The good thing here is that index file code hasn't changed much since v1.0, so it should be stable. The bad thing is that I've added a couple of completely new indexes. I'm also quite busy for the next month, but I'm not sure how much it affects my coding. :)
The largest already implemented new features are:
+ Added support for IMAP UIDPLUS extension
+ IMAP SORT: Sort keys are indexed, which makes SORT commands faster.
+ IMAP THREAD: Threads are indexed into a dovecot.index.thread file.
It can usually be updated incrementally, so this makes THREAD fast.
+ Added Dovecot-specific X-REFERENCES2 threading algorithm.
It's similar to REFERENCES, but it doesn't do base subject merging
and it sorts the threads by their newest message.
+ When saving messages, update cache file immediately with the data
that we expect client to fetch later. Maildir-only currently.
+ Mailbox list indexes. Mailbox metadata is stored there, so STATUS
commands can return synchronized mailboxes' metadata simply by
reading a single mailbox list index file.
- FIXME: Currently works only with Maildir++ layout.
+ Expire plugin can be used to keep track of oldest messages in
specific mailboxes. A nightly run can then quickly expunge old
messages from the mailboxes that have them. The tracking is done
using lib-dict, so you can use either Berkeley DB or SQL database.
+ Namespaces are supported everywhere now.
- FIXME: except by convert plugin
+ Full text search indexing support with Lucene and Squat backends.
+ OTP and S/KEY authentication mechanisms (by Andrey Panin).
+ mbox and Maildir works with both Maildir++ and FS layouts. You can
change these by appending :LAYOUT=maildir++ or :LAYOUT=fs to
mail_location.Features that I'm planning on implementing:
- Fully supported shared mailboxes and IMAP ACL extension
- Replace Squat FTS indexes with my new design
- Case-insensitive searches with non-ASCII text as well
- Maybe add support for all kinds of IMAP extensions that can be easily supported. LEMONADE extensions especially: CONDSTORE, CATENATE and maybe even URLAUTH if I can figure out how it should work.
If a feature can be implemented completely as a plugin, it could still come in v1.1.beta stage, because it won't destabilize the rest of the Dovecot anyway.
Timo Sirainen wrote:
Features that I'm planning on implementing:
- Fully supported shared mailboxes and IMAP ACL extension
- Replace Squat FTS indexes with my new design
- Case-insensitive searches with non-ASCII text as well
- Maybe add support for all kinds of IMAP extensions that can be easily supported. LEMONADE extensions especially: CONDSTORE, CATENATE and maybe even URLAUTH if I can figure out how it should work.
If a feature can be implemented completely as a plugin, it could still come in v1.1.beta stage, because it won't destabilize the rest of the Dovecot anyway.
In my testing of using sql dictionary for quota, it appears pretty buggy. Are you aware of such problems? Either way, would you consider reliable dictionary quota support a target for 1.1? I did find that it seemed to blow maildir++ away in terms of performance. We have a few really large maildirs that basically choke when quota is enabled using maildir++ (200,000+ messages).
On top of the performance gains, gathering disk usage for billing changes from parsing hundreds of thousands of maildirsize files (and du -s or equivalent for those really large maildirs, ugh) to a single sql query, Even more, we could explore enforcing quota on our mail gateways if they just need a sql connection for realtime usage info. So, as you can imagine, I would love to be able to use dictionary in a production environment :)
And just to be clear, I am not trying to demand that any of this gets priority or anything, just trying to gauge your intentions and maybe throw out some ideas to show the potential value :) Congrats on hitting 1.0.0.
On Tue, 2007-04-17 at 15:41 -0400, Justin McAleer wrote:
In my testing of using sql dictionary for quota, it appears pretty buggy. Are you aware of such problems? Either way, would you consider reliable dictionary quota support a target for 1.1?
Actually I think I did it today. The biggest problem with v1.0 implementation was that expunges could be counted multiple times if multiple processes were running.
I ran imaptest for a while with 10 connections and in 3 different tests the dict quota always contained correct values, so I thought it was probably working.
I did find that it seemed to blow maildir++ away in terms of performance. We have a few really large maildirs that basically choke when quota is enabled using maildir++ (200,000+ messages).
Even if filenames had the ,S=size? Another problem is that the quota is read, and possibly recalculated, much more often than is really necessary.. I haven't fixed that yet in v1.1.
Timo Sirainen wrote:
On Tue, 2007-04-17 at 15:41 -0400, Justin McAleer wrote:
In my testing of using sql dictionary for quota, it appears pretty buggy. Are you aware of such problems? Either way, would you consider reliable dictionary quota support a target for 1.1?
Actually I think I did it today. The biggest problem with v1.0 implementation was that expunges could be counted multiple times if multiple processes were running.
I ran imaptest for a while with 10 connections and in 3 different tests the dict quota always contained correct values, so I thought it was probably working.
I was having problems with it seemingly not making updates at all. It would do the initial usage calculation when I logged in, but never updated when I sent a message or expunged anything. In the past (months ago) I also saw problems when sending a message to multiple recipients... I believe it would only update the first recipient or something like that. I was quite astounded by that, since deliver is run once per user, of course. So I was figuring there may be a problem in the dictionary proxy. But, let me double-check all of my configs. If 1.0 should be reliable except for the expunge problem, I'll spend some time today giving it a more thorough examination.
While I'm talking about dictionary quota, do you think it could be
configurable how to identify the users? I'd like to use uid rather than
username/email address, as our users can change their userids. It's not
a huge deal, I can make deleting/updating the quota table row part of
the rename process, but it would be nice and maybe others would benefit
from being able to tweak it.
I did find that it seemed to blow maildir++ away in terms of performance. We have a few really large maildirs that basically choke when quota is enabled using maildir++ (200,000+ messages).
Even if filenames had the ,S=size? Another problem is that the quota is read, and possibly recalculated, much more often than is really necessary.. I haven't fixed that yet in v1.1.
Yes, even then. Perhaps I made it sound a little worse than it was, but expunging a single message made the imap process hang for a while. I'm not sure how long, but definitely long enough that users would (rightfully) complain. I was expecting just an incremental update to be made to maildirsize, but it did the same after every single expunge. I'll do an strace on the process to get a better idea of what exactly is taking so long, but it's fine with quota set to 0, bad when set to anything else (enabled).
Justin McAleer wrote:
I was having problems with it seemingly not making updates at all. It would do the initial usage calculation when I logged in, but never updated when I sent a message or expunged anything. In the past (months ago) I also saw problems when sending a message to multiple recipients... I believe it would only update the first recipient or something like that. I was quite astounded by that, since deliver is run once per user, of course. So I was figuring there may be a problem in the dictionary proxy. But, let me double-check all of my configs. If 1.0 should be reliable except for the expunge problem, I'll spend some time today giving it a more thorough examination.
Ok, my problem with the quota flat out not being updated was some still unexplainable problems with mysql on the server I was using. The insert ... on duplicate key update ... query was successfully inserting new rows, but not ever updating. No error was given, just said 0 rows affected (which by definition shouldn't be possible). But anywho...
There is a definite problem delivering mail under load, though. Sometimes a single username will keep getting updated for all incoming mail, regardless of user. I have a group set up in postfix that sends to 100 random accounts. When I send to that group address, one user will get updated for each delivery (one user updated 100 times rather than each user once).
If I start up a script sending 15 msgs/sec (for example) to random accounts, some either apply to other users or get lost altogether. in one batch I sent to 350 unique users, yet the quota table only has 223 rows.
One last thing, when I sent a message to that huge account with 200,000+ messages, the initial quota calculation seemed to only count up the inbox, not the whole maildir.
I'll be happy to do whatever debugging you'd like to see for this stuff, just met me know... I didn't want to waste any more time doing things that may be of no help though.
Justin McAleer writes:
On top of the performance gains, gathering disk usage for billing changes from parsing hundreds of thousands of maildirsize files (and du -s or equivalent for those really large maildirs, ugh) to a single sql query,
Not sure how difficult it would be, but that would be a very nice feature.
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1
Timo Sirainen schrieb:
I think I won't do any actual releases until it's mostly feature complete. Then maybe v1.1.alpha1 or v1.1.beta1. So if you want to test it before then, use CVS or the nightly snapshots.
I'm planning on keeping v1.1 almost completely compatible with v1.0. There could be some minor configuration file changes, but for most people v1.0's dovecot.conf should work with v1.1.
I want to update index file handling to use less locks and update dovecot.index file less often. The file formats would still stay backwards compatible with v1.0. After this I'm hoping to get index files working well with NFS even with attribute cache enabled.
Dovecot v2.0 then brings incompatible index files and more or less rewritten configuration file handling. It could still support old config file format and settings, but the default will be somewhat different.
I'm hoping to release the first alphas/betas in 2-3 months, with v1.1.0 maybe even as early as next summer. The good thing here is that index file code hasn't changed much since v1.0, so it should be stable. The bad thing is that I've added a couple of completely new indexes. I'm also quite busy for the next month, but I'm not sure how much it affects my coding. :)
The largest already implemented new features are:
- Added support for IMAP UIDPLUS extension
- IMAP SORT: Sort keys are indexed, which makes SORT commands faster.
- IMAP THREAD: Threads are indexed into a dovecot.index.thread file. It can usually be updated incrementally, so this makes THREAD fast.
- Added Dovecot-specific X-REFERENCES2 threading algorithm. It's similar to REFERENCES, but it doesn't do base subject merging and it sorts the threads by their newest message.
- When saving messages, update cache file immediately with the data that we expect client to fetch later. Maildir-only currently.
- Mailbox list indexes. Mailbox metadata is stored there, so STATUS commands can return synchronized mailboxes' metadata simply by reading a single mailbox list index file.
- FIXME: Currently works only with Maildir++ layout.
- Expire plugin can be used to keep track of oldest messages in specific mailboxes. A nightly run can then quickly expunge old messages from the mailboxes that have them. The tracking is done using lib-dict, so you can use either Berkeley DB or SQL database.
- Namespaces are supported everywhere now.
- FIXME: except by convert plugin
- Full text search indexing support with Lucene and Squat backends.
- OTP and S/KEY authentication mechanisms (by Andrey Panin).
- mbox and Maildir works with both Maildir++ and FS layouts. You can change these by appending :LAYOUT=maildir++ or :LAYOUT=fs to mail_location.
Features that I'm planning on implementing:
- Fully supported shared mailboxes and IMAP ACL extension
- Replace Squat FTS indexes with my new design
- Case-insensitive searches with non-ASCII text as well
- Maybe add support for all kinds of IMAP extensions that can be easily supported. LEMONADE extensions especially: CONDSTORE, CATENATE and maybe even URLAUTH if I can figure out how it should work.
If a feature can be implemented completely as a plugin, it could still come in v1.1.beta stage, because it won't destabilize the rest of the Dovecot anyway. Hi Timo,
- Fully supported shared mailboxes and IMAP ACL extension will be very nice
will you include some quota warn code to lda like maildrop does ?
Mit freundlichen Gruessen Best Regards
Robert Schetterer
https://www.schetterer.org Munich/Bavaria/Germany -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.5 (GNU/Linux) Comment: Using GnuPG with SUSE - http://enigmail.mozdev.org
iD8DBQFGJTznfGH2AvR16oERAl+qAJ48qfm6XpfupgDCoWujZf3v3TNwJgCeJfeU EIbbGAv5F+GdzzBiD+bel5I= =KQKu -----END PGP SIGNATURE-----
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1
Timo Sirainen schrieb:
On Tue, 2007-04-17 at 23:32 +0200, Robert Schetterer wrote:
will you include some quota warn code to lda like maildrop does ?
There's already a patch for that in v1.0. So yes, I'll most likely include that to v1.1 once it gets ported.
Thx Timo , thats nice
Mit freundlichen Gruessen Best Regards
Robert Schetterer
https://www.schetterer.org Munich/Bavaria/Germany -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.5 (GNU/Linux) Comment: Using GnuPG with SUSE - http://enigmail.mozdev.org
iD8DBQFGJUpxfGH2AvR16oERAn8UAJ4nsha7CxYo+PcbR64wU76LgImYbACfXWwc O3VUhOjhfIGQbFtzHExiFzA= =SL68 -----END PGP SIGNATURE-----
Are all v1.0 patches and CVS HEAD now 1.1? Specifically I was
wondering if the quota rewrite (http://dovecot.org/list/dovecot/2006-
September/016134.html) is or will be in the 1.1 builds.
.tim
On Apr 17, 2007, at 2:53 PM, Timo Sirainen wrote:
On Tue, 2007-04-17 at 23:32 +0200, Robert Schetterer wrote:
will you include some quota warn code to lda like maildrop does ?
There's already a patch for that in v1.0. So yes, I'll most likely include that to v1.1 once it gets ported.
On Thu, 2007-04-19 at 00:30 -0700, Timothy Martin wrote:
Are all v1.0 patches and CVS HEAD now 1.1? Specifically I was
wondering if the quota rewrite (http://dovecot.org/list/dovecot/2006- September/016134.html) is or will be in the 1.1 builds.
Not all, but quota rewrite is.
- Fully supported shared mailboxes and IMAP ACL extension will be very nice
I agree wholeheartedly - this is one of the two biggest features I see as dovecot needing to make it numero uno without argument.
The other is single-instance storage... and I don't see a mention of that anywhere...
Timo - can you make a guess as to whether or not single-instance storage is even a possibility with 2.0?
A wiki page with a feature wishlist - complete with commenting from Timo on whether or not he sees the value of the feature and if so, a milestone target - would be very nice.
--
Best regards,
Charles
On Wed, 2007-04-18 at 07:49 -0400, Charles Marcus wrote:
The other is single-instance storage... and I don't see a mention of that anywhere...
Timo - can you make a guess as to whether or not single-instance storage is even a possibility with 2.0?
That'd be a dbox-only feature. I've been thinking about dbox a bit recently. I'll write a separate mail about that sometimes later. Anyway, it's possible that it gets implemented even for v1.1.
Timo - can you make a guess as to whether or not single-instance storage is even a possibility with 2.0?
That'd be a dbox-only feature. I've been thinking about dbox a bit recently. I'll write a separate mail about that sometimes later. Anyway, it's possible that it gets implemented even for v1.1.
There will be dancing in the streets when this happens (at least on my street)... ;)
Will it be easy to convert from maildir to dbox when it is stable?
--
Best regards,
Charles
On Fri, 2007-05-11 at 11:35 -0400, Charles Marcus wrote:
Will it be easy to convert from maildir to dbox when it is stable?
Convert plugin was created exactly for that. Although it doesn't yet support preserving UIDs. I'm planning on migrating my own mail from mbox to dbox some day, and I want to preserve the UIDs so there's a good chance of that being implemented :)
Mail.app handles UIDVALIDITY changes horribly. I had to delete all the IMAP accounts' caches and these Envelope* files until it finally reloaded the messages from server instead of just going to infinite loop..
Could the below be added to the list, too, if time allows?
* Add more comments in the source files. Add comments before eachsubroutine illustrating: 1. the purpose of the subroutine, 2. the arguments of the subroutine, and 3. the return value of the subroutine. Add some comments before if-else conditional statements about what and why.
So that people can read, hack and help on the source more easily. It really kills me to find out where to work to add the BASE64-PLAIN password scheme, although the result is actually not very difficult. There is just too little illustration in the source.
I understand that given the current large amount of the source, thismay not be easy to accomplish. But it would be better if this can be gradually done.
Tue, 17 Apr 2007 21:46:33 +0300 Timo Sirainen tss@iki.fi wrote:
-- Best regards, imacat ^_*' imacat@mail.imacat.idv.tw PGP Key: http://www.imacat.idv.tw/me/pgpkey.txt
<
I'd like dovecot to have option '-e' to edit configs like postfix has. I understand dovecot configs are much more complex and have nested blocks. But may be double-colon notation to qualify identifiers by block names will work, like:
dovecot -e 'socket listen::client::path=/tmp/dovecot-auth-client'
-- Sergey Ivanov
On Tuesday, April 17 at 05:58 PM, quoth Sergey:
I'd like dovecot to have option '-e' to edit configs like postfix has. I understand dovecot configs are much more complex and have nested blocks. But may be double-colon notation to qualify identifiers by block names will work, like:
dovecot -e 'socket listen::client::path=/tmp/dovecot-auth-client'
I would like that too---it would make supporting multiple virtual domains with different SSL keys (on different IP addresses, obviously) MUCH easier. Currently I need to maintain separate config files for each.
~Kyle
Power always thinks it has a great soul and vast views beyond the comprehension of the weak; and that it is doing God's service when it is violating all his laws. -- John Adams
On Tue, 2007-04-17 at 21:46 +0300, Timo Sirainen wrote:
I'm planning on keeping v1.1 almost completely compatible with v1.0. There could be some minor configuration file changes, but for most people v1.0's dovecot.conf should work with v1.1.
Please, this needs to be "Everyone's v1.0 dovecot.conf will work in v1.1." If you're going to change the configuration file format even in some subtle way, please bump the major version. Likewise with plugin support... if you're going to break API or ABI, please bump the major version. It's easy enough to avoid breaking compatibility gratuitously. People do not expect configuration files to need changing between minor releases and they'll be quite upset if things break.
Richard
Richard Laager wrote:
On Tue, 2007-04-17 at 21:46 +0300, Timo Sirainen wrote:
I'm planning on keeping v1.1 almost completely compatible with v1.0. There could be some minor configuration file changes, but for most people v1.0's dovecot.conf should work with v1.1.
Please, this needs to be "Everyone's v1.0 dovecot.conf will work in v1.1." If you're going to change the configuration file format even in some subtle way, please bump the major version. Likewise with plugin support... if you're going to break API or ABI, please bump the major version. It's easy enough to avoid breaking compatibility gratuitously. People do not expect configuration files to need changing between minor releases and they'll be quite upset if things break.
Richard
I second that.
Cheers,
Hugo Monteiro.
-- ci.fct.unl.pt:~# cat .signature
Hugo Monteiro Email : hugo.monteiro@fct.unl.pt Telefone : +351 212948300 Ext.15307
Centro de Informática Faculdade de Ciências e Tecnologia da Universidade Nova de Lisboa Quinta da Torre 2829-516 Caparica Portugal Telefone: +351 212948596 Fax: +351 212948548 www.ci.fct.unl.pt apoio@fct.unl.pt
ci.fct.unl.pt:~# _
Richard Laager wrote:
On Tue, 2007-04-17 at 21:46 +0300, Timo Sirainen wrote:
I'm planning on keeping v1.1 almost completely compatible with v1.0. There could be some minor configuration file changes, but for most people v1.0's dovecot.conf should work with v1.1.
Please, this needs to be "Everyone's v1.0 dovecot.conf will work in v1.1." If you're going to change the configuration file format even in some subtle way, please bump the major version.
Well, there is room for argument here... I would call a 'minor' version going from 1.0 to 1.0.1. For these increments, I totally agree.
However, going from 1.0.x to 1.1 is obviously a larger change, and I don't see a problem with *minor* config file changes, as long as they are well documented - and Timo has never failed to do that.
In virtually every case, I imagine Timo would also provide backwards compatibility, so it would be a non-issue...
Likewise with plugin support... if you're going to break API or ABI, please bump the major version. It's easy enough to avoid breaking compatibility gratuitously. People do not expect configuration files to need changing between minor releases and they'll be quite upset if things break.
Agree - but anyone who upgrades *anything* without reading the release notes is asking for trouble.
--
Best regards,
Charles
Charles Marcus wrote:
Richard Laager wrote:
On Tue, 2007-04-17 at 21:46 +0300, Timo Sirainen wrote:
I'm planning on keeping v1.1 almost completely compatible with v1.0. There could be some minor configuration file changes, but for most people v1.0's dovecot.conf should work with v1.1.
Please, this needs to be "Everyone's v1.0 dovecot.conf will work in v1.1." If you're going to change the configuration file format even in some subtle way, please bump the major version.
Well, there is room for argument here... I would call a 'minor' version going from 1.0 to 1.0.1. For these increments, I totally agree.
However, going from 1.0.x to 1.1 is obviously a larger change, and I don't see a problem with *minor* config file changes, as long as they are well documented - and Timo has never failed to do that.
Agreed, Dovecot was released as 1.0.0 for precisely this reason, I imagine. That being the case, 1.0 -> 1.1 should be seen as a significant update (at least worth reading for incompatibilities).
In virtually every case, I imagine Timo would also provide backwards compatibility, so it would be a non-issue...
Likewise with plugin support... if you're going to break API or ABI, please bump the major version. It's easy enough to avoid breaking compatibility gratuitously. People do not expect configuration files to need changing between minor releases and they'll be quite upset if things break.
Agree - but anyone who upgrades *anything* without reading the release notes is asking for trouble.
On Wed, 2007-04-18 at 07:17 -0400, Charles Marcus wrote:
Well, there is room for argument here... I would call a 'minor' version going from 1.0 to 1.0.1. For these increments, I totally agree.
That's a change in the micro version. http://en.wikipedia.org/wiki/Software_versioning#Numeric
Richard
I want to update index file handling to use less locks and update dovecot.index file less often. The file formats would still stay backwards compatible with v1.0. After this I'm hoping to get index files working well with NFS even with attribute cache enabled.
Music to my ears - as im sure with many other NFS sites.
Regards
Dean Manners
On Tue, 17 Apr 2007, Timo Sirainen wrote:
I think I won't do any actual releases until it's mostly feature complete. Then maybe v1.1.alpha1 or v1.1.beta1. So if you want to test it before then, use CVS or the nightly snapshots.
[...]
I'm hoping to release the first alphas/betas in 2-3 months, with v1.1.0 maybe even as early as next summer. The good thing here is that index file code hasn't changed much since v1.0, so it should be stable. The bad thing is that I've added a couple of completely new indexes. I'm also quite busy for the next month, but I'm not sure how much it affects my coding. :)
One question... I remember that such issue has been raised here some time ago, but I don't know if there were any decisions made... Is there a plan for using hard links in dovecot-LDA when the mail is going to be delivered to many recepients... In fact lack of such functionality is the only thing that holds me from switching in multiple locations to dovecot from cyrus-imap, which I really don't like (it requires LDAP, which I don't love as well ;)
Greetz,
Jacek Osiecki joshua@ceti.pl GG:3828944 "To nie logika, to polityka" (c) Kabaret pod Wydrwigroszem 2006
On Wed, 2007-04-18 at 10:51 +0200, Jacek Osiecki wrote:
One question... I remember that such issue has been raised here some time ago, but I don't know if there were any decisions made... Is there a plan for using hard links in dovecot-LDA when the mail is going to be delivered to many recepients... In fact lack of such functionality is the only thing that holds me from switching in multiple locations to dovecot from cyrus-imap, which I really don't like (it requires LDAP, which I don't love as well ;)
It's a bit annoying to implement. I could of course always just kludge it in some way, but perhaps when shared mailbox support is finished this could be implemented more easily:
- Run deliver as some kind of a master user having access to all users' mailboxes
- Write the mail to some temporary mailbox
- Copy it to the users' mailboxes. With maildir_copy_with_hardlinks=yes this'll make them hardlinks
The temporary mailbox is needed because otherwise it's possible that the message gets expunged before it's copied to all the users' mailboxes.
On Fri, 11 May 2007, Timo Sirainen wrote:
On Wed, 2007-04-18 at 10:51 +0200, Jacek Osiecki wrote:
ago, but I don't know if there were any decisions made... Is there a plan for using hard links in dovecot-LDA when the mail is going to be delivered to many recepients... In fact lack of such functionality is the only thing
It's a bit annoying to implement. I could of course always just kludge it in some way, but perhaps when shared mailbox support is finished this could be implemented more easily:
[...]
- Write the mail to some temporary mailbox
- Copy it to the users' mailboxes. With maildir_copy_with_hardlinks=yes this'll make them hardlinks
The temporary mailbox is needed because otherwise it's possible that the message gets expunged before it's copied to all the users' mailboxes.
Good point, I did not think of that - some user's sieve script could expunge the message... So - good luck with shared folders! :)
Greetz,
Jacek Osiecki joshua@ceti.pl GG:3828944 "To nie logika, to polityka" (c) Kabaret pod Wydrwigroszem 2006
Firstly, congratutulations on the official 1.0; we are now running this in production.
On Tue, 17 Apr 2007, Timo Sirainen wrote:
I'm hoping to release the first alphas/betas in 2-3 months, with v1.1.0 maybe even as early as next summer. [...]
Quick check: Is "next summer" envisaged as 2007 or 2008?
Features that I'm planning on implementing:
- Fully supported shared mailboxes and IMAP ACL extension
- Replace Squat FTS indexes with my new design
- Case-insensitive searches with non-ASCII text as well
- Maybe add support for all kinds of IMAP extensions that can be easily supported. LEMONADE extensions especially: CONDSTORE, CATENATE and maybe even URLAUTH if I can figure out how it should work.
Could I put in a request for the "logfile consistency" item mentioned on April 3rd (and receiving some support)? See: http://www.dovecot.org/list/dovecot/2007-April/021532.html and subsequent thread.
Many thanks.
--
: David Lee I.T. Service : : Senior Systems Programmer Computer Centre : : UNIX Team Leader Durham University : : South Road : : http://www.dur.ac.uk/t.d.lee/ Durham DH1 3LE : : Phone: +44 191 334 2752 U.K. :
On Wed, 2007-04-18 at 09:51 +0100, David Lee wrote:
Firstly, congratutulations on the official 1.0; we are now running this in production.
On Tue, 17 Apr 2007, Timo Sirainen wrote:
I'm hoping to release the first alphas/betas in 2-3 months, with v1.1.0 maybe even as early as next summer. [...]
Quick check: Is "next summer" envisaged as 2007 or 2008?
Although v1.0 took 5 years, I wouldn't call 2008 "early". :) So I meant 2007.
Could I put in a request for the "logfile consistency" item mentioned on April 3rd (and receiving some support)? See: http://www.dovecot.org/list/dovecot/2007-April/021532.html and subsequent thread.
Added in TODO. I'll probably write a mail about asking people's opinions on logging when I get closer to updating the logging code.
Timo Sirainen wrote:
Features that I'm planning on implementing:
- Fully supported shared mailboxes and IMAP ACL extension
- Replace Squat FTS indexes with my new design
- Case-insensitive searches with non-ASCII text as well
- Maybe add support for all kinds of IMAP extensions that can be easily supported. LEMONADE extensions especially: CONDSTORE, CATENATE and maybe even URLAUTH if I can figure out how it should work.
Hello Timo,
one thing i already discussed with you some time ago that would make some difference and open lots of possibilities, in my opinion, would be the ability to have a virtual INBOX that could be composed by a list of folders. That would make a world of difference to those who maintain a mixed service of pop and imap to their users.
Just from the top of my head, two great possibilities would be able to
1 - One could use server side filtering (sieve, maildrop, etc) to separate junk from the INBOX to make things look nice for IMAP users, but still allow POP users to retrieve their marked messages and not miss any false positives.
2 - If the list of folders could be a wildcard, allow POP users to retrieve ALL their messages, even if they're also regular IMAP based webmail users.
I'm sure other folks would find other ways to use such feature.
Best regards,
Hugo Monteiro.
-- ci.fct.unl.pt:~# cat .signature
Hugo Monteiro Email : hugo.monteiro@fct.unl.pt Telefone : +351 212948300 Ext.15307
Centro de Informática Faculdade de Ciências e Tecnologia da Universidade Nova de Lisboa Quinta da Torre 2829-516 Caparica Portugal Telefone: +351 212948596 Fax: +351 212948548 www.ci.fct.unl.pt apoio@fct.unl.pt
ci.fct.unl.pt:~# _
On 18 Apr 2007, at 11:11, Hugo Monteiro wrote:
2 - If the list of folders could be a wildcard, allow POP users to retrieve ALL their messages, even if they're also regular IMAP based webmail users.
What a fantastic idea! I have users that would love to be able to
use webmail when out of the office and then POP to pull in all emails
when back at work.
David
On Wed, 2007-04-18 at 11:11 +0100, Hugo Monteiro wrote:
one thing i already discussed with you some time ago that would make some difference and open lots of possibilities, in my opinion, would be the ability to have a virtual INBOX that could be composed by a list of folders. That would make a world of difference to those who maintain a mixed service of pop and imap to their users.
Yes, I've been thinking about virtual mailboxes also. There are a lot of nice things you could do with them. Like a virtual Trash mailbox listing all \Deleted messages would be nice. Will see when I get around to implementing them. :)
I'd suggest dropping any "alpha" or "beta" in the version string and treating "1.1.1" as the first public release. Use "1.1.0" as a prefix for pre-release versions and use a fourth number as your build number, like 1.1.0.123. The download page can explain the basics of this scheme so that newcomers don't assume it's a stable version.
This has the virtue of not requiring any knowledge in downstream packaging systems about the strings you'll use to denote various generations of prerelease. For example, RPM won't need to know that "1.1.rc1" comes before "1.1.0". (Building that kind of logic into every packaging system is a pain, when you consider that every upstream source names things differently.)
It also means that the public release won't be the buggy "dot-oh" that so many admins are accustomed to, but rather the dot-oh after all the known issues have been squeezed out, hence a dot-one. (Ie. it's a marketing trick to encourage adoption. ;))
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1
Hi Timo,
Features that I'm planning on implementing:
- Fully supported shared mailboxes and IMAP ACL extension fine...
What do you think about LDAP (or SQL,...) queries for each userparameter? Make it easyer to implement dovecot at raised and/or complex structures.
Mfg. Stefan Klatt
CaC, Computer and Communication Inhaber Stefan Klatt Triftstrasse 9 60528 Frankfurt Germany
Tel.: +49-(0)172-6807809 Tel.: +49-(0)69-67808-900 Email: stefan.klatt@cac-netzwerk.de -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.7 (MingW32) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org
iD8DBQFGJ8pq+AkeCg4UPr4RAgDzAJ4yZLrxVjcN5k1EbbKWox46nRAF5gCglPRK lx+/J0CxeKOqYUe9ceYUjoo= =g2CR -----END PGP SIGNATURE-----
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1
Stefan Klatt schrieb:
Hi Timo,
Features that I'm planning on implementing:
- Fully supported shared mailboxes and IMAP ACL extension fine...
What do you think about LDAP (or SQL,...) queries for each userparameter? Make it easyer to implement dovecot at raised and/or complex structures.
Mfg. Stefan Klatt
As far i remember Timo answered that acl parameters in sql should be no problem but coding has no primary
Mit freundlichen Gruessen Best Regards
Robert Schetterer
https://www.schetterer.org Munich/Bavaria/Germany -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.5 (GNU/Linux) Comment: Using GnuPG with SUSE - http://enigmail.mozdev.org
iD8DBQFGJ92xfGH2AvR16oERArUMAJ9tpEPUw6XVHNux0fKw5SlNJva3MQCeMv/V ywA99qMY8+agMXDPoiP6dgc= =kJp1 -----END PGP SIGNATURE-----
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1
Hi Robert,
Features that I'm planning on implementing:
- Fully supported shared mailboxes and IMAP ACL extension fine...
What do you think about LDAP (or SQL,...) queries for each userparameter? Make it easyer to implement dovecot at raised and/or complex structures.
As far i remember Timo answered that acl parameters in sql should be no problem but coding has no primary In my humble opinion this are two different jobs. I mean not only acl parameters. For me it would be very good to implement a few ldap queries to get all user parameters like uid, gid, path to emails.
CaC, Computer and Communication Inhaber Stefan Klatt Triftstrasse 9 60528 Frankfurt Germany
Tel.: +49-(0)172-6807809 Tel.: +49-(0)69-67808-900 Email: stefan.klatt@cac-netzwerk.de -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.7 (MingW32) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org
iD8DBQFGJ/C7+AkeCg4UPr4RAhxYAKD7wyxkhC4sUGKHxOGqN2jWzxnqiACeLtJu UF/DuIh9BuudKy2vCszZYSc= =n8QO -----END PGP SIGNATURE-----
On Thu, 2007-04-19 at 22:00 +0200, Stefan Klatt wrote:
What do you think about LDAP (or SQL,...) queries for each userparameter? Make it easyer to implement dovecot at raised and/or complex structures.
With SQL it's possible to create complex functions (at least with PostgreSQL..). With LDAP I suppose it could be useful, but it would make the code a lot more complex and since you're the first person who has wanted it, I'm not sure if it's worth the trouble. You could always create a custom checkpassword script instead.
participants (17)
-
Charles Marcus
-
David Blundell
-
David Lee
-
Dean Manners
-
Francisco Reyes
-
Hugo Monteiro
-
imacat
-
Jacek Osiecki
-
Justin McAleer
-
Kenneth Porter
-
Kyle Wheeler
-
Richard Laager
-
Robert Schetterer
-
Sergey
-
Stefan Klatt
-
Timo Sirainen
-
Timothy Martin