Re: client support for RFC 3516 (BINARY)?

Quoting Lyndon Nerenberg <[email protected]>:

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

For performance reasons, I would assume most servers are scanning for  
RFC 822 structure but not parsing the actual MIME data until a BINARY  
command is received.  So requiring rejection at injection time would  
be quite a performance hit, with no guarantee that the client will  
ever use BINARY.

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

I would think that many/most server implementers would take this  
approach instead, since it is much easier.  And I'm not sure I would  
disagree for performance reasons, not to mention that this appears to  
be the way that many of the BINARY servers currently operate.

As far as INVALID-CTE-SYNTAX ... do we need an additional response  
code?  I feel that UNKNOWN-CTE works here also (although the semantics  
might be a bit off).

 From a client perspective it just needs to know that data does exist  
in that part but it is due to some sort of decoding error, rather than  
the fact that the part doesn't exist for example, that is causing the  
data to not be displayed.  The actual reason the data can't be decoded  
is irrelevant for the client; it just needs to know that it may be  
able to display the content somehow using it's own algorithms to deal  
with broken data.

michael

___________________________________
Michael Slusarz [[email protected]]

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