Item8384: Support HTML email

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

Commenting is disabled while not logged in