Summary | text/html email gets interpreted as text/plain |
Queue | IMP |
Queue Version | 4.0 |
Type | Bug |
State | Not A Bug |
Priority | 1. Low |
Owners | |
Requester | gskinner (at) ycp (dot) edu |
Created | 01/05/2005 (7500 days ago) |
Due | |
Updated | 12/09/2008 (6066 days ago) |
Assigned | |
Resolved | 01/05/2005 (7500 days ago) |
Github Issue Link | |
Github Pull Request | |
Milestone | |
Patch | No |
Google aleart mail takes this format.
(Japanese version. its charset was iso-2022-jp,
and it was encoded using base64.)
so horde user can not read them ;-(
MIME message. If you are not seeing that message, it is
overwhelmingly likely that you have not enabled viewing of text/html
parts.
New Attachment: HTMLsample.eml
Google aleart mail takes this format.
(Japanese version. its charset was iso-2022-jp,
and it was encoded using base64.)
so horde user can not read them ;-(
New Attachment: 1130785636.M782092P21615V0000000000000902I02A94042.correo1,S=6056:2,S
New Attachment: html-type-fix.patch
tolerant with this kind of mail.
Mail reader are usually tolerant about this and it's hard to ask some
people to fix non-compliant and buggy softwares which send this emails.
I had to apply this patch to my horde 2/Imp installation (not a pretty
solution, if someone knows a better way to do it ...) to be able to
display this html mails.
State ⇒ Not A Bug
New Attachment: example.txt
Priority ⇒ 1. Low
Type ⇒ Bug
Summary ⇒ text/html email gets interpreted as text/plain
Queue ⇒ IMP
State ⇒ Unconfirmed
driver, but rather get passed to the text/plain. This only seemed to
be occuring when the only thing that was sent was an html message.
If the html is part of a multipart email, then it seems to display it
right.