Item8384: Support HTML email
Priority: Enhancement
Current State: Closed
Released In:
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.
--
MichaelTempest - 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.
--
WillNorris - 10 Jan 2010
It will support html and text.
--
MichaelTempest - 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.
The
Config.spec
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
Config.spec
. This is what I have in mind:
- The new
content
field will have sub-fields (i.e. it is a perl hash)
- The
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.
- The
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
- The
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:
- The
<!DOCTYPE>
is removed
- The
<html>
tag is removed
- The
<head>
tag is removed, with all of its content
- The
<body>
tag is changed to a <div>
- 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
--
MichaelTempest - 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.
--
CrawfordCurrie - 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.
--
MichaelTempest - 01 Feb 2010
Implemented, and in-use. No further work planned.
--
MichaelTempest - 19 Apr 2010