Zammad: Optional disable support for HTML emails

Hi @MichaelHierweck

to make it more clear to me. What is the problem (use case) with HTML email?

Note: Only agents can write html emails and also "plain text" attachments are attached to all outgoing emails (so if you use pine/mutt and so on, you have not disadvantage).

-Martin

Our business partners are kind of old-fashioned and safety-conscious. They expect emails to be both text/plain and GnuPG signed. But maybe old-fashioned is legacy in 2016... ;)

GnuPG is nice and also feasible with html emails (multipart with text+html in there). :)

We keep this issue open to see if somebody is also interested in text only emails.

I usually use text-only emails, too. In my email program I switch to HTML-mails only in special cases.

Generally speaking I'd say that today old-fashioned users like me have to accept the fact, that HTML-mails are standard.

In the case of zammad I think it still would be helpful to have a text-only email editor: the built in editor has a lot of problems with editing HTML ... Today, as soon as I hit such a bug, I open zammad messages with Thunderbird and answer from there. This happens quite often.

I'd very much support this request. Not only because I - as a principle - never write HTML mails, but also because I'm used to send customers tabular overviews and indent-formatted information like

 | row 1    | row 2    |
 +----------+----------+
 | field 11 | field 21 |
 |   sub 11 |          |
 | field 12 | field 22 |
 +----------+----------+

which just looks crappy, unreadable and unprofessional when looked at in a formatted environment:

+----------+----------+
| row 1 | row 2 |
+----------+----------+
| field 11 | field 21 |
| sub 11 | |
| field 12 | field 22 |
+----------+----------+

Ideal would be, if the format could be selected per mail with a default format, which can be set by each agent.

I'm not completely sure how incoming mails should be treated, but I would probably suggest:

• incoming mail is text/plain: Display in monospaced/teletype type font. Replies can only be sent as text/plain
• Incoming mail is text/html _and_ text/plain: The HTML formatted part should be displayed and kept. For the reply, the agent should be able to choose between plain and html. The respective part of the original mail is then used for the cited part. Citing the text-only part of html mails often renders this part unusable (esp. when it contained tables, lists etc.). Therefore we should have the option to keep it formatted
• Incoming mail is text/html only: Same as for plain/html mails

just my 2c

This is so important I just created my github account to comment on this. HTML mails keep me from using Zammad for my business. It would make my company look stupid if we sent out HTML mails.

HTML for e-mails is considered evil by most professionals. It's explained in the wikipedia, so I expected this to be common knowledge.

HTML is used far too often and causes far too many problems, among these are:

• Security issues. (Embedded tracker-items, JS, CSS...)
• False expectations about e-mails combined with bad style of communication (e.g. using colors instead of proper quotation)
• Much more complicated automatic processing (need to find your way through MIME-containers, then get rid of tags...)
• Much larger size
• Compatibility problems (Don't expect MUAs to process HTML!)
• Accessibility issues for people with a disabilities. Just think about color blind or fully blind users.
• Very clumsy editing. Zammad is actually the best example. Those HTML mails are PITA in the editor.
• Quotation. Just how do you insert ">" and where? What do you do when there's a blockquote-, p- or div-tag or even an img right in the middle of it?
• The German BSI recommends to display HTML as plaintext. So compliance issues might arise in the future.

Usually, the receiver defines how she wants e-mails to be presented/formatted. HTML breaks this rule and allows the sender to define fancy (unreadable?) fonts, background images and other bells 'n whistles while these will partially or completely disappear in the receiver's client, depending on her settings. This means the sender's expectations aren't met, while the receiver won't know if the mail is displayed as expected by the sender. This can't happen with plaintext.

I think plaintext processing should always come first in development and have higher priority. HTML is to be considered an extra, not the other way round.

I agree and hence support this issue

dito, waiting for this option since the first comment.

First of all, many thanks for your participation on the Zammad open source project. We recognize your need for this. However, it's currently not on your (short)list of upcoming features. This means that we probably won't work on it in at least the next year unless we find a sponsor. Another option would be sending a pull request. We are happy to support you on that to get it in the required quality and form to do it the Zammad way.
Since there is no new input on the defined requirements, which are pretty already clear already, I ask you to limit your urge for this feature to emojis on the initial post. Sending comments creates a lot of noise and distracts us from our work on Zammad and slows us down. Otherwise I have to lock the conversation. Feel free to start a vivid discussion over at our community board https://community.zammad.org/ which is the right place for that.
Thanks for your understanding and support!

Bringing this issue back into the spotlight. The address conformation email's coming from Github are now malformed html and as such is causing products like ProofPoint to mangle the email in transit. The desire for plain-text email should once again be reviewed since fragile html formatting causes issues with commercial email filters. I agree it's unreasonable to expect GitHub to regression test against every vendor but the lack of the ability to control email delivery format kinda puts the responsibility on GitHub to do such regression testing

https://useplaintext.email/
https://useplaintext.email/#why-plaintext

I would be willing to throw a bit of money in a pot to get this feature added, likely not enough to fund it on my own though. I looked around a bit and have seen a number of other GitHub issues tagged with prioritised by payment; I assume that means it is possible for users to fund specific features they would like to see?

I also really want support for plain text mails. The best would be if its flexible as @fthommen point out.

Sorry this went below my radar again.
Please contact sales [at] zammad [dot] com.

Our colleagues will figure out the cost and if it's too much also check if it qualifies for a payment pool for several people to carry this on.

My guess is that this is currently blocked by the future to be editor for Zammad.
Zammad currently has no way to tell if you may format a mail or not which may be troublesome in my opinion as of now.

Here is an inofficial quick hack that tries to completely disable sending of the html part in all emails.
Warning: not tested in production yet, may break other stuff, your mileage may vary.

This is a patch for experts running Zammad themselves and know how to apply, test and debug their installation.
However if you only want to send out text/plain mails (e.g. for security reasons), you can give it a try.

```patch
--- app/models/channel/email_build.rb.org 2021-03-18 17:43:54.776830273 +0100
+++ app/models/channel/email_build.rb 2021-03-18 17:49:45.262137627 +0100
@@ -63,4 +63,9 @@
# generate plain part
attr[:body] = attr[:body].html2text
+

• # a hack to only send out text/plain mails, see feature request
• # https://github.com/zammad/zammad/issues/325
• # remove the generated html_alternative part so it cannot be send out:
• html_alternative = false
  end

``` (applied against zammad Version: 3.6.0-1615986441.da478686.buster from the official Debian Buster package,/opt/zammad`)

We did contact Zammad sales a while back about this feature and it looked like it would had to become a real small project, which would have been beyond our budget. Instead we volunteeringly paid a small three digit sum to the https://www.zammad-foundation.org/ so they get something back for their nice Free Software product and maintain it. If you like this patch, please consider also paying the Zammad foundation. :)