GNOME Bugzilla – Bug 317083
Headers containing =?iso-8859-1?Q? are interpreted literally.
Last modified: 2006-01-03 14:05:12 UTC
Distribution/Version: Gentoo Linux 2005.1 The following e-mail is a real example. It was imported from a mbox, which content was identical to the e-mail itself as received from gmail. (please excuse me, I've "masked" e-mail address to preserve myself from spam.) START E-MAIL From noreply-orkut-@-google.com Mon Sep 19 10:12:16 2005 X-Gmail-Received: 4e603a25a81f7a20d73e3be9f2c6fd0ff1b9b72f Delivered-To: leo.fontenelle-@-gmail.com Received: by 10.70.37.12 with SMTP id k12cs39074wxk; Mon, 19 Sep 2005 05:16:03 -0700 (PDT) Received: by 10.70.110.19 with SMTP id i19mr1301446wxc; Mon, 19 Sep 2005 05:16:03 -0700 (PDT) Return-Path: <noreply-orkut-@-google.com> Received: from oproxy.google.com (oproxy.google.com [64.233.162.130]) by mx.gmail.com with ESMTP id i34si949134wxd.2005.09.19.05.16.03; Mon, 19 Sep 2005 05:16:03 -0700 (PDT) Received-SPF: pass (gmail.com: domain of noreply-orkut-@-google.com designates 64.233.162.130 as permitted sender) Received: by oproxy.google.com with SMTP id n15so13791822nzg for <leo.fontenelle-@-gmail.com>; Mon, 19 Sep 2005 05:16:03 -0700 (PDT) Received: by 10.36.186.50 with SMTP id j50mr2755534nzf; Mon, 19 Sep 2005 05:12:24 -0700 (PDT) To: "=?iso-8859-1?Q?Leonardo Fontenelle?=" <leo.fontenelle-@-gmail.com> From: "=?iso-8859-1?Q?orkut?=" <noreply-orkut-@-google.com> Reply-To: "=?iso-8859-1?Q?orkut?=" <noreply-orkut-@-google.com> Message-ID: <98d78ff7-add5-456d-bfca-f68cccc1cbbd-@-orkut.google.com> Date: Mon, 19 Sep 2005 05:12:16 -0800 (PST) Content-Type: text/plain; charset=iso-8859-1 Content-Transfer-Encoding: quoted-printable Subject: =?iso-8859-1?Q?orkut - Andre Reverte escreveu um recado para voc=EA?= Status: RO X-Status: RC X-KMail-EncryptionState: N X-KMail-SignatureState: N X-KMail-MDN-Sent: Ol=E1 Leonardo, Andre Reverte deixou um recado para voc=EA. Para ver o perfil de Andre clique: http://www.orkut.com/Profile.aspx?uid=nnnnnnnnnnnnnnnnnnnnn Para ler este novo recado, visite o orkut. http://www.orkut.com/Scrapbook.aspx * * * Para controlar os emails de notifica=E7=E3o, acesse suas Configura=E7=F5es de conta: http://www.orkut.com/Settings.aspx FINISH E-MAIL Actual Results: (Reading from GUI) To: "=?iso-8859-1?Q?Leonardo Fontenelle?=" <leo.fontenelle-@-gmail.com> From: "=?iso-8859-1?Q?orkut?=" <noreply-orkut-@-google.com> Reply-To: "=?iso-8859-1?Q?orkut?=" <noreply-orkut-@-google.com> Subject: =?iso-8859-1?Q?orkut - Andre Reverte escreveu um recado para voc=EA?= Message body is displayed correctly Expected Results: To: "Leonardo Fontenelle" <leo.fontenelle-@-gmail.com> From: "orkut" <noreply-orkut-@-google.com> Reply-to: "orkut" <noreply-orkut-@-google.com> Subject: orkut - Andre Reverte escreveu um recado para você How often does this happen? Everytime. Once I used Evolution before (2.0.3?) and the issue was already there.
Changed to Miscellaneous, as it happens also with downloaded messages too.
This is correct behaviour. RFC 2047 is very explicit about space being disallowed in quoted words, I quote: 2. Syntax of encoded-words An 'encoded-word' is defined by the following ABNF grammar. The notation of RFC 822 is used, with the exception that white space characters MUST NOT appear between components of an 'encoded-word'. You should ask Google to fix their software so that it sends correct encoded-words. It's not allowed to put encoded words inside double quotes, either.
Thanks for the bug report. This particular bug has already been reported into our bug tracking system, but please feel free to report any further bugs you find. *** This bug has been marked as a duplicate of 302991 ***
actually this isn't a duplicate of 302991, since that bug is about Evolution displaying the octet value 0x80 as the glyph |00| |80| rather than the euro sign (€), even though the charset is declared to be ISO 8859-1. in other words, the broken client sends out characters from the CP-1252 coded character set, but claims the characters are in ISO 8859-1. the RFCs don't have anything to say about that... anyway, that bug doesn't really touch on RFC 2047 decoding at all. it's just a request to be a bit lenient and special case the octet value 0x80, so that it maps to the Unicode U+20AC. personally, I don't see a great harm in that. _this_ bug, however, asks Evolution to break compliance with RFC 2047, which would be bad.