If a message is in MIME format and the preamble is encoded e.g. Content-Type: base64 Then the entire message fails to display, and in the case of a multipart/alternative none of the parts show up on the RHS icon bar. There is only a message/rfc822 icon which indicates the message size (1.20KB). Expanding the message structure shows shows a multipart/alternative with size 152B but the message window is still empty. A test message is attached based on the sample from: http://www.w3.org/Protocols/rfc1341/7_2_Multipart.html Version Info: Claws 3.8.0 GTK+ 2.24.10 / GLib 2.32.3 Locale: en_GB.UTF-8 (charset: UTF-8) Operating System: Linux 3.2.0-25-generic (x86_64) Ubuntu 12.04 LTS
Created attachment 1119 [details] Sample email that causes the failure
Hi, This is invalid according to the very paragraph you quote (7.2): As stated in the definition of the Content-Transfer-Encoding field, no encoding other than "7bit", "8bit", or "binary" is permitted for entities of type "multipart". The multipart delimiters and header fields are always 7-bit ASCII in any case, and data within the body parts can be encoded on a part-by-part basis, with Content-Transfer-Encoding fields for each appropriate body part.
Thanks for the quick response. I know it is invalid it is just that I receive a lot of emails from Windows clients which do this. I suspect it when a eight bit character set is in use, such as big5. It seems that all it would take would be to ignore any content-encoding header. A quick test shows that renaming the header to: X-IGNORE-Content-Transfer-Encoding: base64 and the message displays correctly. So I wrote a script: https://github.com/hxw/dotfiles/blob/master/bin/fix-mime-multipart.pl which can be bound to an Action and added to the toolbar Just added this in case anyone else has this problem