Project

General

Profile

Actions

Feature #30838

closed

Option to parse HTML part of multipart (HTML) emails first

Added by Go MAEDA about 5 years ago. Updated almost 5 years ago.

Status:
Closed
Priority:
Normal
Assignee:
Category:
Email receiving
Target version:
Start date:
Due date:
% Done:

0%

Estimated time:
Resolution:
Fixed

Description

Currently, when mail_handler receives a multipart email that contains both text and HTML part, it tries to retrieve text parts first. HTML parts are processed only when the email does not have any text parts.

However, in 2019, unlike in 2007 which is the year when mail_handler was introduced, HTML mail is becoming increasingly mainstream. Although most emails still have both text and HTML parts, the text part of some email is useless. For example, a simple message "Please open with a mailer which supports HTML emails" or auto-generated text from the HTML part. In such cases, we can get better text by parsing the HTML part with MailHandler.html_body_to_text method than retrieving the content of the text part.

In order to cope with such circumstance, I propose to add an option "Preferred part in HTML emails" to set the parsing order of multipart emails. The setting has two options, "Text" and "HTML". The first option is the default and keeps the current behavior of mail_handler (that means mail_handler tries to get text part first). When Admin chooses the second option "HTML", mail_handler tries to get HTML part first and converts the HTML to plain text. Text part is retrieved only when the email does not have HTML part.

  • Setting name: "Preferred part in HTML emails"
  • Available options: "Text" (Default), "HTML"

I am sure that this feature is really beneficial for users who use the email receiving feature. Since Admin can determine the behavior and the default does not change the current behavior at all, this feature never causes compatibility problems.


Files

add_settings_incoming_emails.png (106 KB) add_settings_incoming_emails.png Yuichi HARADA, 2019-02-22 05:46
30838-preferred-part-multipart-email.patch (5.52 KB) 30838-preferred-part-multipart-email.patch Yuichi HARADA, 2019-02-22 05:51
30838-preferred-part-multipart-email-without-gui.patch (3.43 KB) 30838-preferred-part-multipart-email-without-gui.patch Use configuration.yml instead of adding a new setting to the admin page Go MAEDA, 2019-02-26 03:03

Related issues

Related to Redmine - Patch #38408: Remove experimental flag from "Preferred part of multipart (HTML) emails" settingClosedGo MAEDA

Actions
Actions

Also available in: Atom PDF