Re: [Imap-protocol] BINARY for broken MIME parts

On 6.12.2012, at 16.17, Alexey Melnikov wrote:

> 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"?

So:

a FETCH 1 BINARY[1]
* 1 FETCH (BINARY[1] NIL)
a OK [UNKNOWN-CTE] Invalid input?

I don't know how clients currently handle UNKNOWN-CTE. Maybe some would think that if it's returned then the server can never decode that content-transfer-encoding?..

_______________________________________________
Imap-protocol mailing list
[email protected]
http://mailman2.u.washington.edu/mailman/listinfo/imap-protocol