Lighthouse has a new layout. Prefer the old one? Return to the old layout, and switch back any time from the link at the top of each page.

certain Japanese messages with attachments cannot be rendered

#68

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! :-/

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

State: fixreleased
Milestone: none
Assigned to: benny benny

Activity

  1. benny
    benny
    • 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.

    March 1st, 2011 @ 09:00 AM

  2. benny
    benny
    • State changed from fixcommitted to fixreleased

    March 5th, 2011 @ 05:20 PM

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.