#68 ✓fixreleased
mason-lighthouse (at fivespeed)

certain Japanese messages with attachments cannot be rendered

Reported by mason-lighthouse (at fivespeed) | March 1st, 2011 @ 02:51 AM

I have noticed that many, though not all, Japanese messages I receive, which are encoded iso-2022-jp and also have attachments cannot be rendered by MailMate. These messages render OK in Apple mail, and the .eml also render OK in quicklook.

I've attached two .eml files to demo this issue. You can see the problem just by dragging these onto MailMate. All mail from this particular company does not render correctly if an attachment is present, and it does otherwise.

These don't display correctly in BBEdit, either--until I use the Reopen Using Encoding command. IIRC, it is not 100% possible to 'sniff' or 'guess' the encoding of Japanese text using heuristics, so this makes sense. In the context of an email client, though, there is usually an explicit indicator of the encoding (as in this case). In pathological cases, though, sometimes broken mail systems lie about the encoding.

Therefore, I wonder how this issue can be best solved. It would be awesome if MM could guess right in every case, but if that is impossible, then perhaps the encoding used to display the message needs to be exposed to the user through a menu command (as is the case with BBEdit and Apple Mail).

I am sure dealing with various legacy multibyte text encoding schemes from the 1980s must be super fun! Enjoy! :-/

Comments and changes to this ticket

  • benny

    benny March 1st, 2011 @ 09:00 AM

    • State changed from “new” to “fixcommitted”

    Thanks for the very useful example messages.

    The problem is a bug in PHPMailer for multipart messages (e.g., messages with attachments). The Content-Type header is then as follows:

    Content-Type: text/plain; charset = "iso-2022-jp"

    The spaces around “=” makes MailMate fail to parse the charset (the spaces should not be there).

    The X-Mailer header shows:

    PHPMailer [version 1.73/EC Framework v0.90]

    I also found a message in my own collection with the same problem which was PHPMailer version 2.0 I think. I searched the bug tracker of PHPMailer and I found a related issue and it seemed to have been fixed, but I did not completely verify this.

    I have changed MailMate to be more lenient when parsing the parameters in a Content-Type header.

  • benny

    benny March 5th, 2011 @ 05:20 PM

    • State changed from “fixcommitted” to “fixreleased”

Please Sign in or create a free account to add a new ticket.

With your very own profile, you can contribute to projects, track your activity, watch tickets, receive and update tickets through your email and much more.

New-ticket Create new ticket

Create your profile

Help contribute to this project by taking a few moments to create your personal profile. Create your profile ยป

Mac OS X email client.

Shared Ticket Bins

People watching this ticket