View Issue Details

Jump to NotesJump to History
IDProjectCategoryView StatusDate SubmittedLast Update
0003116SOGoActiveSyncpublic2015-02-23 15:432015-02-26 21:01
Reporteralessice Assigned Toludovic  
PrioritynormalSeverityminorReproducibilityalways
Status resolvedResolutionfixed 
Platform[Client] AppleOSiOSOS Version7
Product Version2.2.16 
Fixed in Version2.2.17 
Summary0003116: Wrong charset in non UTF-8 email
Description

In iPhone/iPad with an ActiveSync account email, when a message has charset different from UTF-8 and characters like "è à °" is not displayed correctly.

Wrong charset as present in header:

=========
This is a multi-part message in MIME format.
--------------030108020609030306000302
Content-Type: text/plain; charset=windows-1252; format=flowed
Content-Transfer-Encoding: 8bit

Content-Type: text/plain; charset=iso-8859-15; format=flowed
Content-Transfer-Encoding: 8bit

In the Sogo webmail interfaces all works fine. For info, in apache/sogo.conf I found AddDefaultCharset UTF-8.

Steps To Reproduce

Send an email with charset type iso-8859-15, insert in the message characters as "è à °" and view in iOS7 via ActiveSync.

Additional Information

In the preview of the Mail.app the messagge is displayed correctly, but when you tap for read characters are replcaed with "???".

TagsNo tags attached.

Activities

tfu

tfu

2015-02-24 21:14

reporter   ~0008229

Can you please attach EML version of a message exposing the problem.
alessice

alessice

2015-02-24 21:25

reporter  

error1.eml (2,269 bytes)
alessice

alessice

2015-02-24 21:27

reporter   ~0008230

Attached.
tfu

tfu

2015-02-25 19:28

reporter   ~0008233

The problem is not iphone specific.
It can occur with any EAS client requesting a bodypreference->type= 4(MIME) in case the email charset!=utf-8 and the content-transfer-encoding=8bit.

The attached patch would fix the issue for mail with content-transfer-encoding=8bit, but maybe it would be better to sanitize any mail when type=4 is requested.
tfu

tfu

2015-02-25 19:29

reporter  

3116.diff (1,017 bytes)    
diff --git a/ActiveSync/SOGoMailObject+ActiveSync.m b/ActiveSync/SOGoMailObject+ActiveSync.m
index 23bb214..7386bc1 100644
--- a/ActiveSync/SOGoMailObject+ActiveSync.m
+++ b/ActiveSync/SOGoMailObject+ActiveSync.m
@@ -469,9 +469,10 @@ struct GlobalObjectId {
     }
   else if (theType == 4)
     {
-      // We sanitize the content *ONLY* for Outlook clients. Outlook has strange issues
+      // We sanitize the content *ONLY* for Outlook clients and if the content-transfer-encoding is 8bit. Outlook has strange issues
       // with quoted-printable/base64 encoded text parts. It just doesn't decode them.
-      if ([[context objectForKey: @"DeviceType"] isEqualToString: @"WindowsOutlook15"])
+      encoding = [[self lookupInfoForBodyPart: @""] objectForKey: @"encoding"];
+      if ([[context objectForKey: @"DeviceType"] isEqualToString: @"WindowsOutlook15"] || ([encoding caseInsensitiveCompare: @"8bit"] == NSOrderedSame))
         d = [self _sanitizedMIMEMessage];
       else
         d = [self content];
3116.diff (1,017 bytes)   
ludovic

ludovic

2015-02-26 16:30

reporter   ~0008234

I don't think the patch is good.

Outlook will only accept email with MIME parts in 8-bits. If you return the parts base64-encoded or quoted-printable-encoded, it'll display them incorrectly.

Moreover, the EAS response we send must be all using the same encoding, UTF-8. You can't specify a per-message encoding, as the whole EAS response (XML blob -> WBXML blob) HAS to use the same one.
tfu

tfu

2015-02-26 17:10

reporter   ~0008235

The patch doesn't change anything for outlook.
It adds the call to _sanitizedMIMEMessage->_sanitizedMIMEPart for 8bit encoded mails which re-encodes the mail to utf-8.

Currently _sanitizedMIMEMessage is called ONLY for outlook when type=4(MIME) is requested. Maybe it should be called in any case for type=4 requests and not only (as suggested in the patch) for 8bit encoded mail, because the condition might not work for multipart mails.
ludovic

ludovic

2015-02-26 20:57

reporter   ~0008236

I actually misread your patch - I thought you had a && instead of a || on your condition.
ludovic

ludovic

2015-02-26 21:01

reporter   ~0008237

https://github.com/inverse-inc/sogo/commit/5ceddc213ec08ccb5b44b07aae47921a19b36fd8

Issue History

Date Modified Username Field Change
2015-02-23 15:43 alessice New Issue
2015-02-24 21:14 tfu Note Added: 0008229
2015-02-24 21:25 alessice File Added: error1.eml
2015-02-24 21:27 alessice Note Added: 0008230
2015-02-25 19:28 tfu Note Added: 0008233
2015-02-25 19:29 tfu File Added: 3116.diff
2015-02-26 16:30 ludovic Note Added: 0008234
2015-02-26 17:10 tfu Note Added: 0008235
2015-02-26 20:57 ludovic Note Added: 0008236
2015-02-26 21:01 ludovic Note Added: 0008237
2015-02-26 21:01 ludovic Status new => resolved
2015-02-26 21:01 ludovic Fixed in Version => 2.2.17
2015-02-26 21:01 ludovic Resolution open => fixed
2015-02-26 21:01 ludovic Assigned To => ludovic