On 2/25/19, 06:08, Jan Schneider wrote:
Zitat von James Noyes <[email protected]>:
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.
--
imp mailing list
Frequently Asked Questions: http://wiki.horde.org/FAQ
To unsubscribe, mail: [email protected]
