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

On Mon, Dec 10, 2012 at 9:56 PM, Timo Sirainen <[email protected]> wrote:

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


I would think [PARSE] would be more appropriate than UNKNOWN-CTE.  Or just
stick with [ALERT].

Also, what if there is more than one message requested?  We usually just
fail to return the broken message and respond NO to the whole fetch, but
return all the non-broken messages.

Also, I wouldn't use "Invalid input", maybe its just my thinking, but I
would think the "input" is the IMAP command, but its an invalid message
data.

Brandon

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