On 20.02.2017 12:47, Toni Mattila wrote:
>> imap: When BINARY FETCH sees invalid content, return NO [PARSE] reply
>> instead of [UNKNOWNCTE] (which is now used only for actually unknown
>> Content-Transfer-Encoding headers).
>
> Has this been tested with Roundcube webmail? I know Roundcube has some
> workarounds when dovecot now responds with that "[UNKNOWNCTE]".
I suppose we'll have to fix the Roundcube code where we do:
// handle UNKNOWN-CTE response - RFC 3516, try again with standard BODY
request
if ($binary && !$found && preg_match('/^' . $key . ' NO
\[UNKNOWN-CTE\]/i', $line)) {
Create a ticket for this, please.
In RFC3501 [PARSE] is described as "The human-readable text represents
an error in parsing the [RFC-2822] header or [MIME-IMB] headers of a
message in the mailbox.". So, is this really an appropriate error code
for this case?
--
Aleksander 'A.L.E.C' Machniak
Kolab Groupware Developer [http://kolab.org]
Roundcube Webmail Developer [http://roundcube.net]
----------------------------------------------------
PGP: 19359DC1 # Blog: https://kolabian.wordpress.com
