[imp] Imp issuing improper "SORT" command at login?

[James Noyes]

On 2/25/19, 06:08, Jan Schneider wrote:
> Zitat von James Noyes <jnoyes-horde at retrogeeks.com>:
>> On 2/24/19, 15:56, Michael J Rubinsky wrote:
>>> Yes. RFC 6855 [3], and further clarified in Errata 4029:
>>>
>>>    Once an IMAP client has enabled UTF-8 support with the "ENABLE
>>>    UTF8=ACCEPT" command, it MUST NOT issue a "SEARCH" command that
>>>    contains a charset specification. If an IMAP server receives such a
>>>    "SEARCH" command in that situation, it SHOULD reject the command with
>>>    a "BAD" response (due to the conflicting charset labels). This also
>>>    applies to any IMAP command or extension that includes an optional
>>>    charset label and associated strings in the command arguments,
>>>    including the MULTISEARCH extension. For commands with a mandatory
>>>    charset field, such as SORT and THREAD, servers SHOULD reject charset
>>>    values other than UTF-8 with a “BAD” response (due to the conflicting
>>>    charset labels).
>>>
>> Ok, this clarifies that SEARCH with a charset should be rejected, but
>> only SEARCH or other commands that "include an optional charset label".
>> SORT and THREAD do not include an *optional* charset label, they
>> include a *mandatory* charset label.
>> The final sentence addresses SORT and THREAD specifically.  They still
>> need have the charset specified (because it is still mandatory), this
>> just clarifies that it shouldn't be any value other than UTF-8 and
>> risks rejection/BAD if it is.
>> Yes?
>
> That's how I understand it too.
>

It appears that both the author of Courier *and* the author of Dovecot 
also agree with that interpretation of the errata.

Here's Courier's response to the "UID SORT" command, with and without 
the "UTF-8" charset field:

> 6 UID SORT (ARRIVAL) ALL
< 6 NO Error in IMAP command received by server.

> 7 UID SORT (ARRIVAL) UTF-8 ALL
< * SORT 45 53 73 88
< 7 OK SORT done.

and here's Dovecot's response to the "UID SORT" command, with and 
without the "UTF-8" charset field:

> 6 UID SORT (ARRIVAL) ALL
< 6 BAD Error in IMAP command UID SORT: Missing search parameters (0.001 
+ 0.000 secs).

> 7 UID SORT (ARRIVAL) UTF-8 ALL
< * SORT 45 53 73 88
< 7 OK Sort completed (0.003 + 0.000 + 0.002 secs).

BOTH of these IMAP servers consider the missing "UTF-8" an error, and 
BOTH provide valid results when the "UTF-8" is present.

Luckily, it's ridiculously simple to change horde/imp's behavior (for 
both "SORT" and "THREAD").
It just takes four lines (not counting updating the comments to reflect 
the change in interpretation):

*** Horde/Imap/Client/Socket.php       2019-02-24 19:22:20.790613840 -0700
--- Horde/Imap/Client/Socket.php.fix   2019-02-24 20:30:12.962603327 -0700
***************
*** 2406,2411 ****
--- 2406,2413 ----
                * send the charset specification (RFC 6855 [3]; Errata 
4029). */
               if (!$this->_capability()->isEnabled('UTF8=ACCEPT')) {
                   $cmd->add($charset);
+             } else {
+                 $cmd->add('UTF-8');
               }
           } else {
               $cmd = $this->_command(
***************
*** 2755,2760 ****
--- 2757,2764 ----
           if (empty($options['search'])) {
               if (!$this->_capability()->isEnabled('UTF8=ACCEPT')) {
                   $cmd->add('US-ASCII');
+             } else {
+                 $cmd->add('UTF-8');
               }
               $cmd->add('ALL');
           } else {

With the above changes applied to my horde/imp install, everything works 
perfectly again, and the error on login is gone.