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