On Fri, 2010-06-11 at 21:10 +0100, Timo Sirainen wrote:

On pe, 2010-06-11 at 14:00 -0500, Mike Abbott wrote:

...

Thank you Timo for beginning the port of URLAUTH, BURL, and CATENATE from 1.2 to 2.0. Attached please find two patches that finish the port to 2.0. One patch updates the dovecot-2.0-urlauth branch and is based on the tip of that branch. The other patch adds the full support to dovecot-2.0.beta5. The resulting URLAUTH/BURL/CATENATE code is the same.

I added the patch to http://hg.dovecot.org/dovecot-2.0-urlauth/

I'll take a closer look at it once v2.1 branch opens.

Some more comments, mainly about auth code changes:

I don't think there's any need to send "anonymous_username" to imap process? It just seems to want to know if the current user is anonymous or not. That same thing has been in my TODO list for a while already because ManageSieve could use that information too. So committed now: http://hg.dovecot.org/dovecot-2.0/rev/c41ba33b8e16

Something similar could be done about submit_user too. Instead of sending "submit_user=x", send both "master_user=x" and "submit". This would actually even allow getting rid of passdb {submit=yes} setting, because it could be just an extra userdb field. Although for convenience maybe it should stay..

"Attempted submit user login for non-imap service %s" check could be moved to lib-master. If master_login_auth_callback() sees that there's a "submit" field returned, require that master_login_init() has been called with MASTER_LOGIN_SUPPORT_SUBMIT_USER flag.

hook_delete_mailbox can be removed. The same can be done by hooking into mailbox.delete() method.

hook_select_send_urlmech needs to go too. I suppose SELECT code needs to be refactored to become more modular to allow plugins to mess with it.

Not sure about other stuff yet.

On 6.12.2010, at 17.32, Mike Abbott wrote:

...

Something similar could be done about submit_user too. Instead of sending "submit_user=x", send both "master_user=x" and "submit".

We chose not to overload master_user=x in this way so that code/plugins that check master_user without knowing about or checking the submit flag don't behave incorrectly. Accidentally granting a mere submit user all of a master user's powers would be unsafe.

Master user doesn't really have any special powers. Compared to a regular login, it just has less powers, because when ACL plugin is loaded the master user by default has no permissions to any mailbox. So if some part of the code doesn't check for submit_user, it assumes the user itself logged in, which could be worse than assuming a master user logged in.

The master user feature was originally written so that there could be pretty restricted master users logging in, such as spam learners accessing only spam mailbox or voicemail software accessing voicemail box. I think that's pretty similar to what submit user is. Maybe "master user" should have been named something more neutral, like "authentication user" or something..

On 6.12.2010, at 23.02, Mike Abbott wrote:

...

when ACL plugin is loaded the master user by default has no permissions to any mailbox.

But without the ACL plugin a master user has all of the regular user's access, including unlimited read/write/delete powers. Submit users don't because of COMMAND_FLAG_OK_FOR_SUBMIT_USER.

Yes, but this is just an additional check that's enabled when submit_user != NULL. If it wasn't checked, there would be no difference between a submit_user and a master_user. So might as well call it master_user and add a submit-flag to enable this extra restriction.

...

Maybe "master user" should have been named something more neutral, like "authentication user" or something..

Please no, not that. Do you know how messy it is already to grep through the code for the words "master" and "user"? If you do change this name make it something new to dovecot, like chameleon or usurper or something.

I know authentication user would be a pretty horrible name. That's why I named it master user, because I couldn't think of anything better :)

But I guess at least in wiki there should be more talk about "master user" not being the same as "admin user". There is actually already a check in imap-quota plugin that allows admin user to get quota for other users. This is checked from struct mail_user.admin boolean. Nothing ever sets that flag though..

Greetings Mike and Timo,

A question about BURL support in Thunderbird came up, and while there is an open bug, it apparently is still not implemented.

I'd love to see this get done, so I've been checking on the status of this in both postfix and dovecot...

Can someone comment on whether or not this was ever fully/properly implemented?

*/Charles/*/*

*/ On 1/14/2011 12:35 PM, Mike Abbott <michael.abbott@apple.com> wrote:

On Dec 5, 2010, at 11:17 PM, Timo Sirainen wrote:

...

I don't think there's any need to send "anonymous_username" to imap process? It just seems to want to know if the current user is anonymous or not. That same thing has been in my TODO list for a while already because ManageSieve could use that information too. So committed now: http://hg.dovecot.org/dovecot-2.0/rev/c41ba33b8e16 I just tried out this change and it does not replace the need for the anonymous_username field. I only now fully understand the comment: /* this is an anonymous login, either via ANONYMOUS SASL mechanism or simply logging in as the anonymous user via another mechanism */ Since the change does not distinguish between those two cases it breaks the "authuser" access identifier for the anonymous user when he is logged in non-anonymously. I would not really care about this edge case except that the contributed implementation requires that the username in the IMAP URL matches the authenticated user's username even for the "anonymous" and "authuser" access identifiers, in violation of RFC 4467 section 4. (The implementation requires a match because Dovecot does not (can not) reach into another user's mail storage.) This means that the "anonymous" and "authuser" access identifiers only work for the anonymous user in the implementation; your change makes the "authuser" access identifier always fail for the anonymous user. The anonymous_username field in the original contributed patch does distinguish between SASL ANONYMOUS and logging in as the anonymous user via another mechanism, so the "anonymous" and "authuser" access identifiers work properly for the anonymous user (but not for any other user).

If you can teach me how to make urlfetch_url() access any user's mail storage from an IMAP process logged in as a different user (subject to OS uid/gid permission constraints), I can make "anonymous" and "authuser" work for all users and use your change instead of the "anonymous_username" field.

Alternatively, you could edit your change to add the "anonymous" indication to the auth reply only for SASL ANONYMOUS authentications rather than for all anonymous-user authentications, unless that would cause trouble for ManageSieve.