GNOME Bugzilla – Bug 608350
Evolution does not display some mails
Last modified: 2010-06-09 13:22:37 UTC
I'm currently trying to use Evolution-MAPI to access the Exchange 2003 server at my workplace. It's running a lot faster than OWA, but sometimes, a mail is not displayed at all (Evolution will not display the white box containing the mail text, leaving that part of the window gray). View source still works though. I thought it had to do with some "interesting" HTML markup, but looking at the messages they seem to be text-only. After looking at a few correctly and incorrectly displayed messages I found the following pattern: All mail from Exchange seems to have the multi-part header, followed by: --=-kdlWc5ULiSTmnJ8z+LsD Content-Transfer-Encoding: 8bit Content-Type: text/plain; charset="CP28591" (after that the text part). The non-displayed messages have a somewhat different header, for example: --=3D-i2A0W1m8PaHtYiHIXZDh Content-Transfer-Encoding: 8bit Content-Type: text/plain; charset=3D"CP28591" Seems the equals sign is escaped in these messages. I have no idea of the relevant MAPI/mailbox standards, but I know it's annoying not to be able to open a mail, so I'd be grateful if someone with knowledge of the specs could take a look at this issue.
I tried sending a mail manually (telnet port 25), and it looks like Exchange adds that stuff even when it wasn't included in the original message: 220 blah Microsoft ESMTP MAIL Service ready at Tue, 16 Mar 2010 13:35:15 +0200 HELO swbr1435n 250 blah Hello [1.2.3.4] MAIL FROM: berend.deschouwer@ucs-software.co.za 250 2.1.0 Sender OK RCPT TO: berend.deschouwer@ucs-software.co.za 250 2.1.5 Recipient OK DATA 354 Start mail input; end with <CRLF>.<CRLF> Subject: Halo How are ye? . 250 2.6.0 <9b96107d-cdae-4abe-bef1-6955f3db54d9@blah> Queued mail for delivery and this was the resultant source: Received: from swbr1435n (1.2.3.4) by blah (1.2.3.5) with Microsoft SMTP Server id 8.2.176.0; Tue, 16 Mar 2010 13:35:56 +0200 MIME-Version: 1.0 Message-ID: <9b96107d-cdae-4abe-bef1-6955f3db54d9@blah> To: Undisclosed recipients:; Return-Path: berend.deschouwer@ucs-software.co.za Date: Tue, 16 Mar 2010 13:35:56 +0200 Subject: Halo Reply-To: "berend.deschouwer@ucs-software.co.za" <berend.deschouwer@ucs-software.co.za> From: "berend.deschouwer@ucs-software.co.za" <berend.deschouwer@ucs-software.co.za> Content-Type: multipart/related; type="multipart/alternative"; boundary="=-9iDtfFpdh/HxJE+OAVzF" --=-9iDtfFpdh/HxJE+OAVzF Content-Transfer-Encoding: 8bit Content-Type: text/plain; charset="CP20127" --=-9iDtfFpdh/HxJE+OAVzF--
That means Exchange (or MAPI???) is adding Content-Type stuff if it's missing. It auto-adds MIME stuff. Notice that the content of my e-mail went missing. If I add the content-type headers in my port 25 tests, the mail is not modified, and it comes straight through.
If I do the exact same test, but I add a content-transfer-encoding: quoted-printable header, exchange mangles the = to =3d, and Evolution chokes: MAIL FROM: berend.deschouwer@ucs-software.co.za 250 2.1.0 Sender OK RCPT TO: berend.deschouwer@ucs-software.co.za 250 2.1.5 Recipient OK DATA 354 Start mail input; end with <CRLF>.<CRLF> To: berend.deschouwer@ucs-software.co.za Subject: Halo Content-Transfer-Encoding: quoted-printable Content-Type: multipart/related; type="multipart/alternative"; boundary="=-Ycv5DObyrAsDvgKCTd3z" --=-Ycv5DObyrAsDvgKCTd3z Content-Transfer-Encoding: 8bit Content-Type: text/plain; charset="UTF-8" Help --=-Ycv5DObyrAsDvgKCTd3z-- . 250 2.6.0 <d945cb15-7793-47f6-b12e-e1d9cc46a08c@blaht> Queued mail for delivery becomes Received: from swbr1435n (1.2.3.4) by blah (1.2.3.5) with Microsoft SMTP Server id 8.2.176.0; Tue, 16 Mar 2010 13:48:02 +0200 To: berend.deschouwer@ucs-software.co.za Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Message-ID: <d945cb15-7793-47f6-b12e-e1d9cc46a08c@blah> Return-Path: berend.deschouwer@ucs-software.co.za Date: Tue, 16 Mar 2010 13:48:02 +0200 Subject: Halo Reply-To: "berend.deschouwer@ucs-software.co.za" <berend.deschouwer@ucs-software.co.za> From: "berend.deschouwer@ucs-software.co.za" <berend.deschouwer@ucs-software.co.za> Content-Type: multipart/related; type="multipart/alternative"; boundary="=-8tE5bLFlCpEGOjUa9N84" --=3D-8tE5bLFlCpEGOjUa9N84 Content-Transfer-Encoding: 8bit Content-Type: text/plain; charset=3D"UTF-8" Help =00 --=3D-8tE5bLFlCpEGOjUa9N84-- --=-8tE5bLFlCpEGOjUa9N84--
RFC 2046, section 5.1 reads The "multipart" boundary delimiters and header fields are always represented as 7bit US-ASCII in any case so the server is wrong. Either Exchange or some server component (virus scanner? auto-disclaimer attacher?) mangles the body in a non-standard way. Still, it would be nice if Evo worked around the bug.
Thanks for a bug report. This particular one got fixed within bug #586093. The issue was with transport headers received from the exchange server. Evolution-mapi used all of them (with any Content-Transfer-Encoding and other Content* headers, but then used its own encoding and content* for subparts. Patch from the above bug added a skip for Content* headers in transport headers received from the server, which fixed the issue. I'm marking this as a duplicate of the older bug and suggest you to use 0.30.1 or later version of evolution-mapi. *** This bug has been marked as a duplicate of bug 586093 ***