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

[noreply at bugs.horde.org]

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

Ticket URL: http://bugs.horde.org/ticket/13153
------------------------------------------------------------------------------
  Ticket             | 13153
  Created By         | daniel_bistriceanu at yahoo.com
  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
  Priority           | 2. Medium
  Milestone          |
  Patch              | 1
  Owners             |
------------------------------------------------------------------------------


daniel_bistriceanu at yahoo.com (2014-04-30 09:34) wrote:

The current implementation for PARTIAL limiting (RFC 5267 [4.4]) in  
Horde_Imap_Client_Socket class needs to be fixed in order to properly  
support PARTIAL limiting:

1. Using a partial range like 'x:x' breaks the current implementation  
for PARTIAL limiting, even though that partial range is perfectly valid.

For example, using '1:1'  the expected behavior would be to have a  
RETURN (PARTIAL 1:1:) in the IMAP command sent to the server.  
Something like 'C: 4 UID SORT RETURN (PARTIAL 1:1) (DATE) US-ASCII  
UNDELETED'.

Instead it sends: 'C: 4 UID SORT RETURN (PARTIAL 1) (DATE) US-ASCII  
UNDELETED', which is obviously an invalid IMAP command that returns  
'S: 4 BAD Error in IMAP command UID SORT: PARTIAL range broken.'

This issue is caused by the current behavior of converting the partial  
range to ids and then back to its string representation:  
strval($this->getIdsOb($options['partial']));

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].

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.