When receiving e-mails that do not correctly include information about the character encoding used, evolution is does not display the e-mail correctly, even when the character encoding used is revealed in the subject line.
By looking at the raw e-mail, I presume the correct way to specify character encoding is by using the "Content-Type" MIME header.
However, if the subject of the e-mail is encoded using a specific character encoding (by following the following standard: http://en.wikipedia.org/wiki/MIME#Encoded-Word), wouldn't it be safe to assume that the e-mail body - if it does not specifically specify a character encoding - uses the same character encoding as the subject? Are there any examples where this might not be the case?
I know this is one of those cases, where the easiest solution would be if the e-mail client sending the message would just follow the standard correctly, but I think that we as Linux users are currently in a situation where we gain more by adapting to the various flaws in non-standard e-mail clients, rather than try to get them to adhere to the standard, using our relatively tiny market share.
We do this with hardware drivers in the kernel - adapt to the various quirks that are there mostly because of non-standard ways in which Microsoft Windows handles the hardware. Why not do this as well with e-mail, which are quite a big part of any modern operating system?
Example:
I receive an e-mail with the following content:
Subject: =?iso-8859-1?Q?din_bestilling_-_ordre_nr_123456?=
Sender: "=?iso-8859-1?Q?someone@somewhere=2Edk?=" <email address hidden>
From: "=?iso-8859-1?Q?someone@somewhere=2Edk?=" <email address hidden>
Date: Mon, 21 Jun 2010 00:47:48 +0200
To: "=?iso-8859-1?Q?mymailaddress@mail=2Ecom?=" <email address hidden>
X-Priority: 3
X-MSMail-Priority: Normal
MIME-Version: 1.0
X-Mailer: JMail 4.4 by Dimac
Content-Type: text/html
Content-Transfer-Encoding: 8bit
The "Content-Type"-header does not correctly state that the character encoding used is ISO-8859-1, but the subject line uses an Encoded-Word to specify this information (and Evolution correctly displays the subject line).
Binary package hint: evolution
When receiving e-mails that do not correctly include information about the character encoding used, evolution is does not display the e-mail correctly, even when the character encoding used is revealed in the subject line.
By looking at the raw e-mail, I presume the correct way to specify character encoding is by using the "Content-Type" MIME header. en.wikipedia. org/wiki/ MIME#Encoded- Word), wouldn't it be safe to assume that the e-mail body - if it does not specifically specify a character encoding - uses the same character encoding as the subject? Are there any examples where this might not be the case?
However, if the subject of the e-mail is encoded using a specific character encoding (by following the following standard: http://
I know this is one of those cases, where the easiest solution would be if the e-mail client sending the message would just follow the standard correctly, but I think that we as Linux users are currently in a situation where we gain more by adapting to the various flaws in non-standard e-mail clients, rather than try to get them to adhere to the standard, using our relatively tiny market share.
We do this with hardware drivers in the kernel - adapt to the various quirks that are there mostly because of non-standard ways in which Microsoft Windows handles the hardware. Why not do this as well with e-mail, which are quite a big part of any modern operating system?
Example:
I receive an e-mail with the following content:
Subject: =?iso-8859- 1?Q?din_ bestilling_ -_ordre_ nr_123456? = 8859-1? Q?someone@ somewhere= 2Edk?=" <email address hidden> 8859-1? Q?someone@ somewhere= 2Edk?=" <email address hidden> 8859-1? Q?mymailaddress @mail=2Ecom? =" <email address hidden> Priority: Normal
Sender: "=?iso-
From: "=?iso-
Date: Mon, 21 Jun 2010 00:47:48 +0200
To: "=?iso-
X-Priority: 3
X-MSMail-
MIME-Version: 1.0
X-Mailer: JMail 4.4 by Dimac
Content-Type: text/html
Content- Transfer- Encoding: 8bit
The "Content- Type"-header does not correctly state that the character encoding used is ISO-8859-1, but the subject line uses an Encoded-Word to specify this information (and Evolution correctly displays the subject line).
ProblemType: Bug ature: Ubuntu 2.6.32- 22.36-generic 2.6.32.11+drm33.2
DistroRelease: Ubuntu 10.04
Package: evolution 2.28.3-0ubuntu10
ProcVersionSign
Uname: Linux 2.6.32-22-generic i686
Architecture: i386
Date: Mon Jun 21 13:19:05 2010
InstallationMedia: Ubuntu 10.04 "Lucid Lynx" - Alpha i386 (20100405)
ProcEnviron:
PATH=(custom, no user)
LANG=en_DK.utf8
SHELL=/bin/bash
SourcePackage: evolution