Item8384: Support HTML email
Current State: Closed
Target Release: n/a
I would like the MailInContrib to be able to handle HTML emails. There should be an option to use the HTML part of MIME messages, instead of the text part.
- 09 Jan 2010
will it support html and
text? one of the easiest way to get caught in spam filters is sending html only email.
- 10 Jan 2010
It will support html and text.
- 25 Jan 2010
I have implemented this, and written some tests. I will deploy this very soon, so that I may evaluate it in the real world.
interface is not mature - I am sure
it will change, and that will
affect the implementation.
I must also write plenty more tests
First, I must finalize the
. This is what I have in mind:
- The new
content field will have sub-fields (i.e. it is a perl hash)
type sub-field specifies which part of the mail to extract. Possible values:
text - extract the plain-text portion. This is the default
html - extract the HTML portion, if present. Extract the plain-text if there is no HTML portion.
external-resources field specifies if HTML email may reference resources not in the email. This applies to images, style sheets and scripts. Possible values:
allowed - The HTML may contain
http://... URLs for resources such as images, style sheets and scripts. This may pose a security risk, do not enable this unless you understand the security implications
disallowed - HTML tags that reference resources not contained in the email are removed. This is the default
inline-resources field specifies if HTML email may reference resources contained in the email. Possible values:
allowed - Inline resources (such as images and style sheets) are extracted from the email and attached to the topic. Corresponding URLs in the HTML are changed to refer to the attachments. This is the default
disallowed - Inline resources are not extracted.
Currently, the HTML is processed as follows:
<!DOCTYPE> is removed
<html> tag is removed
<head> tag is removed, with all of its content
<body> tag is changed to a
- The result is wrapped in another
<div> with a foswiki-specific class to provide for custom styling.
I suspect the div-with-style belongs in a template.
Feedback, suggestions, corrections etc most welcome
- 30 Jan 2010
That's exactly what I would have done. Wrapping it in a div-with-class is a good safety precaution. I concur that a template is desireable, but as a first pass, hard coding it isn't such a bad thing.
- 30 Jan 2010
I changed tack completely, regarding the setup interface. You now arrange a set of processors. Each processor can do one thing well. It is extensible.
- 01 Feb 2010
Implemented, and in-use. No further work planned.
- 19 Apr 2010