Re: client support for RFC 3516 (BINARY)?

> So a message with single base64 encoded part is sent like:
>
> =====
> Content-Type: text/plain
> Content-Transfer-Encoding: base64
>
> <base64 data>
>
> <Plaintext Mailing List Trailer>
> =====

> Issuing a FETCH BINARY[] on this data produces inconsistent results.  A NO 
> [UNKNOWN-CTE] is possible, as well as trying to base64 decode as much as 
> possible while stripping the rest, and finally base64 decoding and leaving 
> the plaintext as is.

As a purist I would argue the IMAP server should never have accepted the 
message to begin with, but most implementations take it on faith the 
content matches what the metadata says is in there.

In this case, I'm not sure what to do.  The problem here is not a BINARY 
issue as such, but more of a general issue as to what a server should do 
when it discovers invalid data part way through a transaction.  The 
protocol in general doesn't provide a framework for dealing with this type 
of scenario.

My strong preference is for the server fully validate the message when 
it's being injected into the store, and reject these sorts of 
non-complaint messages at that time.  Most any IMAP store these days is 
already parsing the MIME structure at injection time, so it's really not a 
lot of extra work to validate the stated encodings match the body content 
as you're copying the message through.

> If 3516 is getting updated, might be useful to have a more consistent 
> definition of what it means to be "unable to trasfer decode" so that this 
> data is displayed consistently across servers.  i.e. Is it ok to do a 
> best-guess decoding?

Absolutely not.  You must follow the directive in the MIME header (in this 
case, perform a bese64 decode).

RFC3501 section 7.4.2 talks about ENcoding binary content as base64, but 
since this transformation cannot fail there is no provision for a failure 
mode.  For BINARY, that's not the case, as your example points out.  And 
it was a situation I never anticipated when I wrote 3516 (most likely 
because I am quite fascist about rejecting invalid content up front before 
it becomes a problem).

At the moment, I'm not sure there is any way out of this other than for a 
server supporting BINARY to validate the CTEs at injection time, and 
reject any messages with content encoding violations.  I don't think there 
is any way for a server that discovers bad base64 in the middle of a 
BINARY FETCH to recover gracefully.

I *adamantly* oppose any notion of passing through anything that fails the 
CTE decoding, as this presents a wonderful opportunity for malicious code 
injection into a naive client implementation.  In light of that security 
concern alone, I don't think there is any alternative but to add a "server 
MUST validate the body content correctly decodes before transmitting the 
decoded content to the client" or words to that effect to the BINARY 
specification.  If this is done at message injection time, the overhead 
will be minimal, and would allow the server to refuse to accept the 
message.  If implementers are insistent about accepting such malformed 
content, then we will have to add something like an [INVALID-CTE-SYNTAX] 
respose code so the server can send back "foo NO [INVALID-CTE-SYNTAX]" 
when the runtime check fails.

> Additionally, it might be useful to add implementation note that a client 
> should fallback to using FETCH BODY[] if the server returns NO.  The MUA that 
> the original reporter is using (I don't know what it is) is simply showing a 
> blank body for these kind of messages when a FETCH BINARY[] is unsuccessful.

This is so stunningly obvious it doesn't deserve mentioning.

--lyndon

_______________________________________________
imapext mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/imapext