[RCD] If Content-Transfer-Encoding can't be parsed, should Roundcube read the content as 7bit?

Hi there,

One of our customers has an application that sends him emails with XML files attached. This app doesn't write the correct headers, so it looks like this:

--AaBb--984dfgeSSd3532 Content-Type: application/xml; name=whatever.xml Content-Transfer-Encoding: base64Content-Disposition: attachment; filename=whatever.xml

<really><long><xml><file><here><without><line><breaks>

You can see that Content-Transfer-Encoding was supposed to be base64, but it has a lame syntax error. The XML file is not base64 encoded, it is very long XML in a single line.

Because of this, when the client downloads the attachment from Roundcube, the XML is broken because Roundcube added line breaks to its contents, giving us somtething like:

<this_is_a_brok en_tag>blahblah </this_is_a_bro ken_tag>

The RFC 2045 [1] states that the default value of Content-Transfer-Encoding is 7bit, that's why we would expect such line breaks to respect the character limit (I know that the message is malformed), but if this limit isn't respected, should Roundcube really try to "fix" the message like rcube_imap_generic::handlePartBody() does? Is this the intended behavior or should Roundcube return the contents 'as is' to the user?

Sorry if this is confusing.

[1] http://tools.ietf.org/html/rfc2045#section-6

Thanks! Pedro Padron

List info: http://lists.roundcube.net/dev/ BT/aba52c80