0 votes
by (300 points)

This is what I see in message source

Content-Type: message/rfc822;
    name*0="=?UTF-8?Q?Kudi_=E2=80=93_Je_suis_un_client_commercia?= =?UTF";
Content-Disposition: attachment;
    filename*0="=?UTF-8?Q?Kudi_=E2=80=93_Je_suis_un_client_commercia?= =?UTF";

Thunderbird shows this attachment name correctly: Kudi – Je suis un client commercial – -Optimisation des processus.eml

But when I read it using rebex attachment's name is:
Kudi – Je suis un client commercia=%3FUTF-8%3FQ%3Fl=E2=80=93-Optimisationdesprocessus.eml%3F=

Is there any way to get "clean" name? Or at least clean extension? We save it under guid.originalextension.

Applies to: Rebex Secure Mail

1 Answer

0 votes
by (146k points)
edited by

Update: We added a workaround for this in 2019 R4 release.

This message seems to be attempting to use MIME parameter encoding according to RFC 2231. This is very rare - Rebex Mail and Thunderbird are one of few email parsers that can actually handle mail messages using RFC 2231 parameter encoding.

Unfortunately, the way that particular message encodes those headers is very wrong. It's not the proper RFC 2231 approach, but rather a strange mix-up of RFC 2231 and the common MIME-style header encoding (which was not originally supposed to be used for encoding of MIME paramaters, but almost all email clients use it for that purpose, so it became a de-facto standard).

Rebex Mail does support both RFC 2231 and MIME-like parameter encodings, but it does not support a mix of both. Thunderbird either has a workaround for that, or this is just a lucky coincidence due to the way their parsers work.

This said, it looks like adding a workaround for messages with this kind of invalid encoding to Rebex Mail would be rather simple for us. We'll try to add it to the next release.

But please be aware that the message is broken, and that the proper solution is to fix the software that created it.