[Dovecot] v1.2.beta1 released
http://dovecot.org/releases/1.2/beta/dovecot-1.2.beta1.tar.gz http://dovecot.org/releases/1.2/beta/dovecot-1.2.beta1.tar.gz.sig
Largest changes since v1.1 can be found from http://dovecot.org/doc/NEWS-1.2
Changes since alpha5:
- Added support for ESORT extension (also SORT .. RETURN (PARTIAL) from CONTEXT=SORT that allows windowing SORT results)
- pop3: If client idles for 10 seconds, commit transaction (allowing mbox to become unlocked).
- crashfixes to virtual mailboxes
- all kinds of bug fixes, error message improvements, etc.
- http://dovecot.org/patches/1.2/stats-plugin.c may give some interesting statistics about commands
There isn't really much left to do for v1.2.0 except some small fixing to shared mailbox code. And writing documentation for it..
Timo Sirainen <tss@iki.fi> writes:
http://dovecot.org/releases/1.2/beta/dovecot-1.2.beta1.tar.gz http://dovecot.org/releases/1.2/beta/dovecot-1.2.beta1.tar.gz.sig
Great news! :-)
[...]
There isn't really much left to do for v1.2.0 except some small fixing to shared mailbox code. And writing documentation for it..
Could we by any chance get the latest small changes/enhancements:
- 'c' and 'd' in setacl
- Displaying the actual user name instead of meta name "owner" on getacl output (see Bernhards patch in the "IMAP ACLs and global ACLs in v1.2" thread) in 1.2? I know it's a little late but I think that would greatly extend the compatibility with existing clients -- and would enable us to use the current upstream dovecot without any changes ... ;)
Oh and one more thing, I just discovered another small problem: one can't subscribe to shared user folders. I'll put the report in a new mail.
cheers sascha
Sascha Wilde OpenPGP key: 4BB86568 http://www.intevation.de/~wilde/ http://www.intevation.de/ Intevation GmbH, Neuer Graben 17, 49074 Osnabrück; AG Osnabrück, HR B 18998 Geschäftsführer: Frank Koormann, Bernhard Reiter, Dr. Jan-Oliver Wagner
On Wed, 2009-02-11 at 11:00 +0100, Sascha Wilde wrote:
Timo Sirainen <tss@iki.fi> writes:
http://dovecot.org/releases/1.2/beta/dovecot-1.2.beta1.tar.gz http://dovecot.org/releases/1.2/beta/dovecot-1.2.beta1.tar.gz.sig
Great news! :-)
[...]
There isn't really much left to do for v1.2.0 except some small fixing to shared mailbox code. And writing documentation for it..
Could we by any chance get the latest small changes/enhancements:
- 'c' and 'd' in setacl
Yes, this will definitely be included. I just wanted to do some tests before including it and thought it wasn't important enough to delay beta1 release because of it.
- Displaying the actual user name instead of meta name "owner" on getacl output (see Bernhards patch in the "IMAP ACLs and global ACLs in v1.2" thread)
That patch appears to be also changing owners to user=x? I wouldn't mind a patch that showed them to clients as user=x, but I don't want them to change when something else gets changed. Also I'm not entirely sure how it should be handled when user=x ACL is changed. Should it remove the owner? Should it change the owner instead? I think the owner ACLs are usually in global ACL files, so it's probably not possible to remove or change it, only add a new user=x.
Timo Sirainen <tss@iki.fi> writes:
On Wed, 2009-02-11 at 11:00 +0100, Sascha Wilde wrote:
Could we by any chance get the latest small changes/enhancements:
- 'c' and 'd' in setacl
Yes, this will definitely be included.
This is very good news.
- Displaying the actual user name instead of meta name "owner" on getacl output (see Bernhards patch in the "IMAP ACLs and global ACLs in v1.2" thread)
That patch appears to be also changing owners to user=x?
This is indeed quite possible -- I haven't seen it happen in my tests though...
As Bernhard wrote him self on the patch: we are not sure it is the right solution -- actually he is pretty sure it isn't ... ;-)
I wouldn't mind a patch that showed them to clients as user=x, but I don't want them to change when something else gets changed.
For us[0] changing what is shown to the client is sufficient. Actually on a second thought I agree with you, that keeping the special owner keyword internally is preferable.
Also I'm not entirely sure how it should be handled when user=x ACL is changed. Should it remove the owner? Should it change the owner instead?
This is a good point. IMO there are only a couple of possibilities:
we could define that only the server-administrator is allowed to change owner acls by means of setting global acls or manually editing the dovecot-acl files.
Rational: Users shouldn't be able to change the owners acls, to prevent them from shooting there own foots.
In this case changing the acl for the user which maps to "owner" would be silently ignored.
cyrus imapd actually tries[1] to implement a variant of this possibility in that it does not allow to remove the 'a' right from the owner: s setacl INBOX/foo 1@burlywood1.rgb lrswipkxtecd s OK Completed g getacl INBOX/foo
- ACL INBOX/foo 1@burlywood1.rgb lrswipkxtecda g OK Completed s setacl INBOX/foo 1@burlywood1.rgb lrs s OK Completed g getacl INBOX/foo
- ACL INBOX/foo 1@burlywood1.rgb lrskxca I think this is worth considering.
Allow everything allowed by the actual ACLs, so every user having a(dmin) rights is free to change all ACLs even if it leads to folders where no user has the right to change it any more.
Rational: unix philosophy, obey to user demands and don't be nuisance, shooting ones own foot is a basic freedom... ;-)
I think the owner ACLs are usually in global ACL files, so it's probably not possible to remove or change it, only add a new user=x.
I think that it would be best to always map the owners user name to the keyword "owner" and vice versa between the IMAP front end and the acl back end. This way user=x where x is the owners user name should never appear in an dovecot-acl file. So it boils down to the question if the individual acl-files should take precedence over the global one -- without having checked I assume this decision already has been made.
cheers sascha
[0] Actually IMNSHO this subject is not only relevant to us: - The acl aware clients I know of don't recognize the special meaning of "owner". - This makes perfect sense, as there is no specified way to decide if the string "owner" in an IMAP ACL reply denotes an user actually named owner or is an special keyword denoting "the user owning the folder". - Finally, even if an client would recognize "owner" as an special keyword, it wouldn't be able to figure out who the owner actual is. Which makes the information of rather low use. [1] I just tested some scenarios and it turned out they messed up on the details, so that one can actually end up with an folder which no user has admin rights one and the output of myrights and getacl is inconsistent -- quite funny!
Sascha Wilde OpenPGP key: 4BB86568 http://www.intevation.de/~wilde/ http://www.intevation.de/ Intevation GmbH, Neuer Graben 17, 49074 Osnabrück; AG Osnabrück, HR B 18998 Geschäftsführer: Frank Koormann, Bernhard Reiter, Dr. Jan-Oliver Wagner
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1
On Tue, 10 Feb 2009, Timo Sirainen wrote:
Cool thing, I jumped on it to try it out adn stumbled again over this:
- please add an advice to etc/dovecot-example.conf / login_max_processes_count that this setting also applies to SSL connections.
http://wiki.dovecot.org/LoginProcess mentions: "login_max_processes_count specifies the maximum number of login processes there can exist at a time (listening, non-listening and SSL/TLS-proxying processes combined)."
Bye,
Steffen Kaiser -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.6 (GNU/Linux)
iQEVAwUBSZw2O3WSIuGy1ktrAQLJbgf9GfbS+Q6fQ/1L9EDONn4zBQ1KZUrZUZqA j3fqznAFO1P8hf/X25rvedxt555fIk8SwCzu81TuZwxyYkWT0wJBstei4VmGFHP2 PEtWMAmMYryBtXtPnN3131iFUih6qMzCDoEIGlOC7s9Y2J4p0NOZCfpyrRlNgvDV g76wLOHfz/zhAKT6Ya0pN14BxQtxe1U5uyiQQPw5yMB7PpMou/ApcqNocz0TQ42n xJhaND5RHLMUahhleLqoeaOqdzBcngEBvxO9bLgkqj+DdmBER/kliHZUK+gVqJ54 q7L6x7t26nmDpW8KY0fnJ8/3otgXYNQWk/lztUkWhR1swJlqQ49qJg== =LejH -----END PGP SIGNATURE-----
On Thu, 2009-02-12 at 13:10 +0100, Sascha Wilde wrote:
- cyrus imapd actually tries[1] to implement a variant of this possibility in that it does not allow to remove the 'a' right from the owner:
I implemented this to Dovecot now too.
I think the owner ACLs are usually in global ACL files, so it's probably not possible to remove or change it, only add a new user=x.
I think that it would be best to always map the owners user name to the keyword "owner" and vice versa between the IMAP front end and the acl back end. This way user=x where x is the owners user name should never appear in an dovecot-acl file.
I did consider this too, but then I thought that it could cause wrong results in some special situations. For example if another user's mailbox is symlinked to your private namespace and you change your own rights, it really should change them and not the owner's.
So it boils down to the question if the individual acl-files should take precedence over the global one -- without having checked I assume this decision already has been made.
IIRC in v1.1 mailbox ACL files take precedence, but in v1.2 globals take precedence. I changed it because users shouldn't be able to override admin's decisions.
Timo Sirainen <tss@iki.fi> writes:
On Thu, 2009-02-12 at 13:10 +0100, Sascha Wilde wrote:
- cyrus imapd actually tries[1] to implement a variant of this possibility in that it does not allow to remove the 'a' right from the owner:
I implemented this to Dovecot now too.
Good. :)
I just gave it a try. I was a little worried when I saw that I was able to remove all admin rights from an folder by giving "a" to another user and let this user first remove "a" from the owner and then from him self -- fortunately the owner was still able to edit the acls (despite the missing administrator flag.), so everything is fine:
OK [CAPABILITY IMAP4rev1 LITERAL+ SASL-IR LOGIN-REFERRALS ID ENABLE AUTH=PLAIN] Dovecot ready. lo login bar secret lo OK [CAPABILITY IMAP4rev1 LITERAL+ SASL-IR LOGIN-REFERRALS ID ENABLE SORT THREAD=REFERENCES MULTIAPPEND UNSELECT IDLE CHILDREN NAMESPACE UIDPLUS LIST-EXTENDED I18NLEVEL=1 CONDSTORE QRESYNC ESEARCH ESORT SEARCHRES WITHIN CONTEXT=SEARCH ACL RIGHTS=texk ANNOTATEMORE] Logged in li list "" "*"
LIST (\Noselect \HasChildren) "/" "user"
LIST (\Noselect \HasChildren) "/" "user/foo@example.com"
LIST (\HasChildren) "/" "INBOX"
LIST (\HasNoChildren) "/" "user/foo@example.com/test-share" li OK List completed. g getacl "user/foo@example.com/test-share"
ACL "user/foo@example.com/test-share" "foo@example.com" akxeilprwtscd "bar@example.com" akxeilprwtscd g OK Getacl completed. s setacl "user/foo@example.com/test-share" "foo@example.com" -a s OK Setacl complete. g getacl "user/foo@example.com/test-share"
ACL "user/foo@example.com/test-share" "foo@example.com" kxeilprwtscd "bar@example.com" akxeilprwtscd g OK Getacl completed. s setacl "user/foo@example.com/test-share" "bar@example.com" kxeilprwtscd s OK Setacl complete. getacl "user/foo@example.com/test-share" getacl BAD Error in IMAP command "USER/foo@EXAMPLE.COM/TEST-SHARE": Unknown command. lo logout
BYE Logging out lo OK Logout completed.
OK [CAPABILITY IMAP4rev1 LITERAL+ SASL-IR LOGIN-REFERRALS ID ENABLE AUTH=PLAIN] Dovecot ready. loginb foo secret loginb BAD Error in IMAP command received by server. lo login elf 11 lo OK [CAPABILITY IMAP4rev1 LITERAL+ SASL-IR LOGIN-REFERRALS ID ENABLE SORT THREAD=REFERENCES MULTIAPPEND UNSELECT IDLE CHILDREN NAMESPACE UIDPLUS LIST-EXTENDED I18NLEVEL=1 CONDSTORE QRESYNC ESEARCH ESORT SEARCHRES WITHIN CONTEXT=SEARCH ACL RIGHTS=texk ANNOTATEMORE] Logged in li list "" "*"
LIST (\HasChildren) "/" "INBOX"
LIST (\HasNoChildren) "/" "INBOX/test-share" li OK List completed. g getacl "INBOX/test-share"
ACL "INBOX/test-share" "foo@example.com" kxeilprwtscd "bar@example.com" kxeilprwtscd g OK Getacl completed. s setacl "INBOX/test-share" "foo@example.com" +a s OK Setacl complete. g getacl "INBOX/test-share"
ACL "INBOX/test-share" "foo@example.com" akxeilprwtscd "bar@example.com" kxeilprwtscd g OK Getacl completed.
I'm not sure if every detail here is intended, but I think its an good solution.
I think the owner ACLs are usually in global ACL files, so it's probably not possible to remove or change it, only add a new user=x.
I think that it would be best to always map the owners user name to the keyword "owner" and vice versa between the IMAP front end and the acl back end. This way user=x where x is the owners user name should never appear in an dovecot-acl file.
I did consider this too, but then I thought that it could cause wrong results in some special situations. For example if another user's mailbox is symlinked to your private namespace and you change your own rights, it really should change them and not the owner's.
I haven't thought of that. I agree that in such cases the mapping would fail. However I think there are many setups where such symlink hacks are not used (and I guess with the new shared user namespaces and IMAP ACL front end there will be even fewer cases in which such tricks are useful) -- so maybe this could be configure able?
So it boils down to the question if the individual acl-files should take precedence over the global one -- without having checked I assume this decision already has been made.
IIRC in v1.1 mailbox ACL files take precedence, but in v1.2 globals take precedence. I changed it because users shouldn't be able to override admin's decisions.
I guess it's mainly a question if you see these global ACLs as mere defaults (in which case it should be possible to overwrite them) or as an administrative instrument. I don't really have any opinion which is more useful... :)
Once again many thanks for putting all this into 1.2!
cheers sascha
Sascha Wilde OpenPGP key: 4BB86568 http://www.intevation.de/~wilde/ http://www.intevation.de/ Intevation GmbH, Neuer Graben 17, 49074 Osnabrück; AG Osnabrück, HR B 18998 Geschäftsführer: Frank Koormann, Bernhard Reiter, Dr. Jan-Oliver Wagner
participants (3)
-
Sascha Wilde
-
Steffen Kaiser
-
Timo Sirainen