[Tickets #13153] Re: Bugs in the current implementation for PARTIAL limiting (RFC 5267 [4.4]) in Horde's Imap_Client library

noreply at bugs.horde.org noreply at bugs.horde.org
Wed Apr 30 22:11:57 UTC 2014


DO NOT REPLY TO THIS MESSAGE. THIS EMAIL ADDRESS IS NOT MONITORED.

Ticket URL: http://bugs.horde.org/ticket/13153
------------------------------------------------------------------------------
  Ticket             | 13153
  Updated By         | Michael Slusarz <slusarz at horde.org>
  Summary            | Bugs in the current implementation for PARTIAL limiting
                     | (RFC 5267 [4.4]) in Horde's Imap_Client library
  Queue              | Horde Framework Packages
  Version            | Git master
  Type               | Bug
-State              | Unconfirmed
+State              | Assigned
  Priority           | 2. Medium
  Milestone          |
  Patch              | 1
-Owners             |
+Owners             | Michael Slusarz
------------------------------------------------------------------------------


Michael Slusarz <slusarz at horde.org> (2014-04-30 16:11) wrote:

> To fix this it should just enforce the usage of the provided partial  
> if it is a valid sequence range ('range_start:range_end'), as  
> specified in RFC 5267 [4.4].

This won't work, since 'partial' can be, for example, array(1, 2, 3).   
So we do need to convert to an Ids object first.  We just need to  
catch the single case where the range contains a single ID

> 2. In case there's a 'sort' option the current implementation  
> conditions the PARTIAL limiting to the availability of the 'SORT'  
> capability on the 'CONTEXT', even though it also states just below  
> the check that "RFC 5267 indicates RFC 4466 ESEARCH support,  
> notwithstanding RFC 4731 support."
> and PARTIAL limiting relies on 'ESEARCH' not 'ESORT' to retrive the  
> message UIDs that correspond to the PARTIAL limiting range that was  
> specified in the UID SORT command, properly taking into account the  
> 'sort' criterion:
> C: 4 UID SORT RETURN (PARTIAL 1:1) (DATE) US-ASCII UNDELETED
> S: * ESEARCH (TAG "4") UID PARTIAL (1:1 1)
> S: 4 OK Sort completed (0.000 secs).
>
> To fix this it should check for the availability of the 'SEARCH'  
> capability on the 'CONTEXT' as an alternative check that 'ESEARCH'  
> is available.

This fix isn't correct.

First, you're allowing an ESORT with PARTIAL return if CONTEXT=SORT is  
not available, which is not correct.

Second, support for CONTEXT=SORT (or CONTEXT=SEARCH) isn't true 4466  
ESEARCH support.  For the sort instance, ESEARCH-like behavior is  
available only if ESORT is available or CONTEXT=SORT is available.   
ESEARCH-like behavior is NOT available if we are using the SORT  
command and CONTEXT=SEARCH is available, since we are not using  
CONTEXT=SEARCH support in that code branch.  Thus the specific check  
for SORT is correct in this instance - CONTEXT=SEARCH availability is  
irrelevant.





More information about the bugs mailing list