6.0.0-alpha12
6/11/25

[#8393] charset problem in html file in attachment
Summary charset problem in html file in attachment
Queue IMP
Queue Version 4.3.2
Type Bug
State Not A Bug
Priority 1. Low
Owners
Requester patrick.guiran (at) linagora (dot) com
Created 07/01/2009 (5824 days ago)
Due
Updated 07/07/2009 (5818 days ago)
Assigned
Resolved 07/02/2009 (5823 days ago)
Github Issue Link
Github Pull Request
Milestone
Patch No

History
07/07/2009 09:40:13 PM Michael Slusarz Comment #4 Reply to this comment
Hi, thanks for your quick answer. One part of the problem is that the
content-type of the part is wrong. It's setted with a call like this :
  $msg->setCharset(NLS::getCharset());
So every html part gets an "UTF-8" encoding, which can be wrong.
What would you say about reading and setting charset for an html attachment ?
There is no way to determine the charset of a file uploaded via RFC 
1867.  And there is no reliable way to auto-determine the charset of a 
text file.  Therefore, we fall back to the only information we are 
provided from the remote OS - the charset supported by the browser.
07/02/2009 06:45:02 AM mloiseleur (at) linagora (dot) com Comment #3 Reply to this comment
Not a bug.  Meta tags have all sorts of security implementations for
inline display, so they are necessarily stripped from the HTML
source.  Charset must be indicated in the content-type for the part,
not a meta tag.  If you want to view an unadulterated version,
download the file to your local machine and view the local copy.
Hi, thanks for your quick answer. One part of the problem is that the 
content-type of the part is wrong. It's setted with a call like this :

  $msg->setCharset(NLS::getCharset());

So every html part gets an "UTF-8" encoding, which can be wrong.

What would you say about reading and setting charset for an html attachment ?



Regards,
07/02/2009 06:27:40 AM Michael Slusarz Comment #2
State ⇒ Not A Bug
Reply to this comment
Not a bug.  Meta tags have all sorts of security implementations for 
inline display, so they are necessarily stripped from the HTML source. 
  Charset must be indicated in the content-type for the part, not a 
meta tag.  If you want to view an unadulterated version, download the 
file to your local machine and view the local copy.
07/01/2009 02:31:23 PM patrick (dot) guiran (at) linagora (dot) com Comment #1
Priority ⇒ 1. Low
New Attachment: capture.jpg Download
Patch ⇒ No
Milestone ⇒
Queue ⇒ IMP
Summary ⇒ charset problem in html file in attachment
Type ⇒ Bug
State ⇒ Unconfirmed
Reply to this comment
When I send a mail with a HTML document as attachment, the XSS filter 
remove all <!--a75c305b1c0a6022--><meta> tag.



By removing the <!--a75c305b1c0a6022--><meta http-equiv="Content-Type" 
content="text/html; charset=ISO-8859-1"> tag, the content of the 
attachment isn't displayed correctly, due to charset problem, as my 
browser is configured with UTF-8 charset.



See the capture to see the problem.



To solve the problem, the only solution I have found is to disable the 
XSS filter on <!--a75c305b1c0a6022--><meta> tags, by commenting lines 
146 to 150 of file lib/Horde/Text/Filter/xss.php, ie. the definition 
of the <!--a75c305b1c0a6022--><meta> tag pattern, in the $malicious 
array.



Regard

Patrick,

Saved Queries