KMail displays at the top of the email: "Note: This is an HTML message. For security reasons, only the raw HTML code is shown." The email has following headers: Content-Transfer-Encoding: base64 Content-Type: text/html; charset="utf-8" When decoding using `base64 -d`, I see that it contains `<tt style="background: #ebebeb; font-size: 13px;"><input type="number" value="1"/></tt>` I did not "click here" to render HTML in KMail. All HTML parts of the email are replaced using their MarkDown (?) equivalent (which is as it should be), except for the HTML-escaped <input/> element, which is actually being rendered as an input field (which is a bug). I.e. I can enter a number or use the up/down buttons to change the value. I.e. it is not being replaced by a pure-text string. I would expect to see the unescaped <input type="number" value="1"/> string, instead of the rendered input field. Version: 5.6.1 (which is not available in Bugzilla) Package-Version: 4:17.08.1-0neon+16.04+xenial+build31
Test case please :)
(In reply to Laurent Montel from comment #1) > Test case please :) I crafted an email in RFC 2822 form, which probably would reproduce the issue, but I have no way of testing it, because the KMail {File > Import Messages ...} menu entry is greyed out. Hence I cannot import the message and see how KMail would render it. How do I import messages into KMail / activate this menu entry?
File->open no ?:)
Created attachment 108374 [details] Test case / example email The attached email demonstrates the issue. Do you have an explanation why I can open a message but not import one?
This is not restricted to <input> tags, but works with every HTML tag. e.g. the text <a href="#">test</a> in a HTML-only mail will produce an actual link when viewed in the "save HTML code only view", but renders as expected after allowing HTML.