Re: client support for RFC 3516 (BINARY)?

Quoting Lyndon Nerenberg <[email protected]>:

> I think the changes to add that restriction might be a bit too  
> substantive for an errata.  (Barry, are you lurking  out there?)   
> Also, others have complained about parts of the document that are  
> ambiguous or just not clear, so maybe it's time for an update.

A real world BINARY issue, that was brought to my attention today, is  
the list behavior at vger.kernel.org.  I was told that incoming  
messages have mailing list information appended to them, regardless of  
the transfer-encoding of the content.

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.

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?

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.

michael

___________________________________
Michael Slusarz [[email protected]]

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