MBOX-Line: From alexey.melnikov at isode.com  Thu Dec  6 06:17:24 2012
To: imap-protocol@u.washington.edu
From: Alexey Melnikov <alexey.melnikov@isode.com>
Date: Fri Jun  8 12:34:49 2018
Subject: [Imap-protocol] BINARY for broken MIME parts
In-Reply-To: <CDD9BF88-A87D-41CB-A668-E2A7FE5CFE20@iki.fi>
References: <CDD9BF88-A87D-41CB-A668-E2A7FE5CFE20@iki.fi>
Message-ID: <50C0A8F4.4070405@isode.com>

Hi Timo,

On 04/12/2012 11:12, Timo Sirainen wrote:
> Another BINARY issue not specified by the current BINARY RFC: How to handle fetching BINARY[x] or BINARY.SIZE[x] when the MIME part exists but contains invalid base64/quoted-printable data? The possibilities I think would be:
>
> a) Just ignore the invalid data and reply as best as you can. I'm not sure if this is actually useful in any case since the result will be invalid, and it might even cause security problems in case viruses try to exploit it at some point when virus scanner and IMAP server do the decoding differently. I remember reading a few years ago a lot of reports about this issue.
>
> b) Reply NIL to BINARY[x] and 0 to BINARY.SIZE[x] and overall reply OK to the FETCH.
>
> c) Abort and return NO to the FETCH, similarly to as for [UNKNOWNCTE] handling, except without that resp-code.

I think both b) and c) would be Ok. But b) is probably less likely to 
surprise client authors.

> I implemented b) today for Dovecot, thinking that it would probably cause less client confusion than c) and would be more secure then a).

Maybe it is worth to do b) but also return "UNKNOWNCTE"?


