Subject: [imapext] GENURLAUTH pipelining

From: Jan Kundrát <[email-masked]>
Date: Wed, 17 Apr 2013 17:03:11 +0200

Hi,
I've noticed that my code for GENURLAUTH is rather dumb and also quite buggy -- it breaks when there are multiple GENURLAUTH commands in flight (yes, it's a serious bug, users sending multiple messages at once could send wrong ones to wrong senders). What I need to know is a reliable way of mapping the returned URLs into the commands which issued them. I suspect this might not be an easy problem to solve, though. Unlike ESEARCH, the GENURLAUTH contains no tag information to "tie" it back to the issuing command, so I think that one should either disable pipelining of GENURLAUTH altogether, or somehow guess the correct bidning based on the received URLs.

One could rely on the strict wording of RFC 4467's Chapter 5:

   An initial URL is built, ending with ";URLAUTH=<access>" but without
   the ":<mech>:<token>" components.  An authorization mechanism is
   selected and used to calculate the authorization token, with the
   initial URL as the data and a secret known to the IMAP server as the
   key.  The URLAUTH-authorized URL is generated by taking the initial
   URL and appending ":", the URL authorization mechanism name, ":", and
   the ASCII-encoded hexadecimal representation of the authorization
   token.

This means "ignore any URLs which do not begin with the string I sent". However, I can imagine all sorts of transformations a server might want to perform on the URLs they hand out -- the most trivial is case mangling for usernames/hostnames/mailboxes, but there are even harder-to-detect, yet legitimate (?) transformations like using a real FQDN for a server's hostname.

Apart from that, there's also the possibility of some semi-evil mangling like providing a different UID/UIDVALIDITY/mailbox triplet which might make a certain level of sense when e.g. dealing with virtual mailboxes like "[All messages]".

What is your advise here?

With kind regards,
Jan

-- 
Trojitá, a fast Qt IMAP e-mail client -- http://trojita.flaska.net/

---

From: Arnt Gulbrandsen <[email-masked]>
Date: Wed, 17 Apr 2013 22:05:30 +0200

In cases like that, the server is required to process the commands strictly in the order received. That solves the ambiguity.

Arnt

---

From: Alexey Melnikov <[email-masked]>
Date: Thu, 18 Apr 2013 19:57:14 +0100

On 17/04/2013 16:03, Jan Kundrát wrote:
> Hi,
> I've noticed that my code for GENURLAUTH is rather dumb and also quite 
> buggy -- it breaks when there are multiple GENURLAUTH commands in 
> flight (yes, it's a serious bug, users sending multiple messages at 
> once could send wrong ones to wrong senders). What I need to know is a 
> reliable way of mapping the returned URLs into the commands which 
> issued them. I suspect this might not be an easy problem to solve, 
> though. Unlike ESEARCH, the GENURLAUTH contains no tag information to 
> "tie" it back to the issuing command, so I think that one should 
> either disable pipelining of GENURLAUTH altogether, or somehow guess 
> the correct bidning based on the received URLs.
>
> This means "ignore any URLs which do not begin with the string I sent".
I think this is right.
> However, I can imagine all sorts of transformations a server might 
> want to perform on the URLs they hand out -- the most trivial is case 
> mangling for usernames/hostnames/mailboxes, but there are even 
> harder-to-detect, yet legitimate (?) transformations like using a real 
> FQDN for a server's hostname.

Maybe this needs clarifying in the RFC, but I would expect the server to 
return the prefix unchanged (or it should refuse to sign it).
I suppose you can do case insensitive comparison for the domain part of 
the URI.

> Apart from that, there's also the possibility of some semi-evil 
> mangling like providing a different UID/UIDVALIDITY/mailbox triplet 
> which might make a certain level of sense when e.g. dealing with 
> virtual mailboxes like "[All messages]".
>

---

From: Ned Freed <[email-masked]>
Date: Fri, 19 Apr 2013 04:15:10 -0700 (PDT)

> I think this is right.

I concur.

> I suppose you can do case insensitive comparison for the domain part of

Agreed as well. While I guess I could come up with cases where the server might
want to return an alternate URL, it's not the model the RFC defines. In
particular, the access control and security considerations associated with such
a transformation have not been looked at AFAIK.

				Ned