Vote #79849
完了Option to parse HTML part of multipart (HTML) emails first
0%
説明
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.
journals
--------------------------------------------------------------------------------
Go MAEDA wrote:
> 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"
The "Preferred part of multipart (HTML) emails" has been added to [Administration] > [Settings] > [Incoming emails].
I attached a patch.
!{width:500px;border:1px solid #ccc;}add_settings_incoming_emails.png!
--------------------------------------------------------------------------------
I forgot to attach a patch.
--------------------------------------------------------------------------------
Do you see any side effect if we switch to HTML part first without adding a new setting?
--------------------------------------------------------------------------------
Marius BALTEANU wrote:
> Do you see any side effect if we switch to HTML part first without adding a new setting?
Maybe it is OK to read an HTML part first by default. It works without a big problem, I think. But I feel anxiety that some users will encounter unexpected behavior of the HTML email parser or some users don't like that converted text has Textile/Markdown markups such as bold, italic, underlines, and headings.
Therefore, I think we had better add an option to control which part is extracted. It does not have to be in the admin GUI. Adding a setting in the configuration.yml file is also OK.
The following is a summary of my post. Marius, what do you think?
* Reading an HTML part first is OK
* We had better have an option to control the preferred part in the admin GUI or configuration.yml.
--------------------------------------------------------------------------------
Go MAEDA wrote:
> The following is a summary of my post. Marius, what do you think?
>
> * Reading an HTML part first is OK
> * We had better have an option to control the preferred part in the admin GUI or configuration.yml.
I agree, it is safer.
--------------------------------------------------------------------------------
I modified the patch not to add a setting on the admin page. Instead, it reads the setting from configuration.yml. We can avoid increasing the complexity of the admin page.
I think that this setting should not be changed often or easily, so the configuration.yml may be a good place to put the setting.
We may change the default value to 'html' in the future version of Redmine but I think it is safer to stay in 'plain' in Redmine 4.1 because this unreleased feature is not widely tested and used yet in the production environments. Maybe it is better to mark this feature as "Experimental" like Markdown formatter introduced in Redmine 2.5 (#15520).
--------------------------------------------------------------------------------
Setting the target version to 4.1.0.
--------------------------------------------------------------------------------
If this setting is supposed to be configureable, I do think that it belongs on the Settings page rather than the @configuration.yml@ file.
When considering the distinction between the "server administrator" who is responsible for the software itself and the Redmine administrator who is responsible for the projects and communication, I don't see this setting in the realm of the server administrator. Instead, i think it should be up to the Redmine administrator to decide based on the emails they receive whether to prefer one or the other option.
As for the feature itself, I'm in favour of seeing it added to Redmine (although I hate that it is apparently necessary in the first place due to broken email senders who abuse perfectly fine technology without any gain)
--------------------------------------------------------------------------------
Holger Just wrote:
> If this setting is supposed to be configureable, I do think that it belongs on the Settings page rather than the @configuration.yml@ file.
Thank you for the advice. It makes sense. I attached attachment:30838-preferred-part-multipart-email-without-gui.patch to avoid increasing the complexity of the setting page, but now I think the setting should be on the page.
--------------------------------------------------------------------------------
Committed the patch. Thank you for improving Redmine.
--------------------------------------------------------------------------------
The caption of the options for the setting is hardcoded in source:trunk/app/views/settings/_mail_handler.html.erb@17913#L21 and cannot be localized.
--------------------------------------------------------------------------------
Go MAEDA wrote:
> We may change the default value to 'html' in the future version of Redmine but I think it is safer to stay in 'plain' in Redmine 4.1 because this unreleased feature is not widely tested and used yet in the production environments. Maybe it is better to mark this feature as "Experimental" like Markdown formatter introduced in Redmine 2.5 (#15520).
I completely agree, let mark this feature as "Experimental".
--------------------------------------------------------------------------------
Marius BALTEANU wrote:
> I completely agree, let mark this feature as "Experimental".
Done in r18072.
--------------------------------------------------------------------------------