Webmail severe extended character handling issue

Posts: 2
Joined: Thu Oct 06, 2016 5:59 am

Webmail severe extended character handling issue

Postby hsar2 » Thu Oct 06, 2016 6:20 am

MailEnable Standard, v9.50

When opening a mail in webmail, and the reading pane is off, extended characters (happens with greek) are being displayed correctly the first time the message is opened.
As i noticed by monitoring the postoffice folder, when this happens, the server re-encodes the mail file (.mai), obviously thinking that the message needs to be translated to something.
From that point on, all extended characters are messed up, no matter what the mail is opened with (webmail, imap client, text editor). The .mai file encoding/translation is incorrect.
This issue does not occur if the reading pane is enabled.
As it seems, when the message is previewed and therefore mark as read, opening the mail does not lead to a reencoding of the .mai file.
In short, if an unread file is opened, it gets damaged.

A simple aspx fix to avoid what seems to be a bug, would probably be to mark the mail as read before opening it?

Webmail has been set to use utf-8 from within the program, and utf-8 is listed as the client encoding when using webmail.

Site Admin
Posts: 8648
Joined: Mon Mar 22, 2004 4:44 am
Location: Melbourne, Victoria, Australia

Re: Webmail severe extended character handling issue

Postby MailEnable-Ian » Thu Oct 06, 2016 11:13 pm


Can you provide an example message .mai file so we can emulate? Attach a copy and send to support@mailenable.com. Or private message me with the URL for the web mail client and mailbox credentials so we can emulate the behavior.

Ian Margarone
MailEnable Support

Posts: 2
Joined: Thu Oct 06, 2016 5:59 am

Re: Webmail severe extended character handling issue

Postby hsar2 » Fri Oct 07, 2016 4:23 am

In order to reproduce the error, turn off the reading pane, send a mail with e.g. "abc - αβγ" as content to the account of interest, double click (or right click) to open it (or chose reply or forward). The first time the message is opened it should be displayed correctly. At that time, if you are monitoring the .mai file, you'll notice it gets modified (and it's size increases).
If you return to the inbox and try to open the message again, you'll notice that the "αβγ" part of the original content will have been replaced by seemingly meaningless characters.

I can send a sample .mai if you want, better yet two (original and modified/unreadable), but meanwhile, it seems that I managed to fix the issue, by bypassing the reencoding of the message.

By adding two modifications in the client.js file, so that the message gets marked as read in the beginning of the OpenMessage and the ProcessComposeCmd functions, the message does not get reencoded, the original mail is retained, hence the bug is avoided.

The modifications i did are the following:

function OpenMessage(B, H, A) {
// custom code **
MarkMessageAsRead(B, H);
// original code follows

function ProcessComposeCmd(F, C) {
if (!gAllowPageActions) {
return false
if (F == "Reply" || F == "ReplyAll" || F == "Forward") {
if (!HasSingleItemSelected()) {
return false

// **** custom code
{ var B = GetSelectedFolderPath();
B = B.replace(/&lt;/g, "<");
B = B.replace(/&gt;/g, ">");
var A = gSelectedIM.GetFirstSelectedItem();
// **** original code follows

Let me know if you still need me to send sample .mai files, cause in order to do so, I'll have to replace the modified client.js file with the original on a working server.


Who is online

Users browsing this forum: No registered users and 1 guest