Add option for default display format

[cketti]

Allow the user to display text/plain parts of emails by default.

[nd2s]

+1billion

I'm now waiting for years for this standard feature. And I'm still getting tracked by every company because there is no usable email client for Android that can display standard text mails. It's like in Windows Wonderland...

Because of the word default in the ticket's title: When in text/plain mode the app should not show HTML even if there is no text part available. Maybe there should be three options:

• HTML, when possible
• Text, when possible
• Force text (<- this is the important one)

[philipwhiuk]

"And I'm still getting tracked by every company "

Email tracking only happens with HTML e-mails if you chose to show remote content, which is an option K-9 has long supported to turn off. Where privacy issues come up they are fixed - see #712

The only reason to prefer text is to make it easier to read content, rather than have to suffer the whims of whatever design the email marketeers come up with. It won't even save bandwidth as it will be happening client-side.

The fact that this is the only reason is likely the reason this issue hasn't been a priority.

If you chose force text do we strip tags or show you a blank email?

PS: (+1 billion is not helpful - there's GitHub reactions for that). Also ....

[francwalter]

...When in text/plain mode the app should not show HTML even if there is no text part available...

Is there any email-client sending html-emails without any text-part? Isn't this written in some RFC to send minimum text-part and deliberatly html-part too?

[nd2s]

Sorry but this is nonsense. I don't want a default insecure-mode and bug-fixes when someone finds a problem. The standard should be secure. I really got mad when I saw myself getting tracked when testing a company newsletter a few month ago.

(Easier to read is of course a big point too, on mobile.)

Force text: No text content available. Kind of standard in all mail clients I have used so far. Happens very rarely anyway (mostly spam that was already moved into Junk). Mostly shitty newsletters and spammers.

[njeyaakili]

The user should be able to able to set which part of a multi-part message they want to see by default, and not (as is the current case) be forced to viewing only the html part. If the user can see the text part they can at least tell if the embedded URLs are of a tracking nature or not and also can better tell whether there is a phishing issue at play.

[nd2s]

@njeyaakili The user can't see anything when viewing the text part (except the text part itself). HTML part can be totally different.

[njeyaakili]

Right, but you can see the URLs presented in the text part, and make an informed decision based on that. Yes, the html part's URLs may be totally different, but if I'm viewing the text part I really don't care what the html part's URLs are (and am saved from the various traps/scams easily hidden in the html). In a desktop world I can mouse-over the html-part URLs and try to see what's going on. You might be able to do this with a pen-enabled mobile device (e.g., some samsung products), but mostly you can't with mobile clients, so being presented with an available text-part gives the user a cleaner environment to make decisions from.

[philipwhiuk]

I've thrown together a quick implementation of the three original options. It seems to work as desired.

[nd2s]

@philipwhiuk I can't really test it but took a look at the code (without much/any knowledge of the codebase). If I understand correctly you are basically just putting the plain text into the HTML view + adding some default css.

Not sure how that looks but sounds usable to me (nice!). Was that all that's needed for that feature or is there anything missing?

[dicer]

I also see this as a security problem: The webview will always have some security holes. Especially in older versions of Android. Newer ones update it over the play store, but there is also people out there with no play store access (for whatever reason).
You could still deliver exploits by declaring them plain/text and wait for k9mail to put them into a webview, right?
So I would advocate to implement this feature WITHOUT the html/web view when showing plaintext.

[Hund]

Considering the security issues and the fact that emails is about text, plain good old text - makes it feel a bit weird that there's even a disqussion about this.

[nd2s]

Considering the relevance and age of this ticket and the fact that there is/was an improvement ready that hasn't been released: don't get your hopes up - this won't be done.

[philipwhiuk]

@dicer That's a nice idea, but I don't see the value. If it's all text-plain stuff and escaped properly there's no security issue. There's an overhead in terms of rendering it completely differently in terms of maintenance.

@Hund There's no discussion about whether it should be done. But lots of stuff should be done - personally as a developer I prioritise stuff that could/does affect me considering I have limited time to devote to it.

@nd2s There was feedback to rework my implementation idea so it is done in a better way. I need to get back to @cketti's code review comments. Personally I prioritise this below app stability and other features so injecting time to rework it has not happened yet.

[dicer]

@philipwhiuk Ok, if all the html is escaped, the risk is a lot lower. Javascript is turned off as well I see. Most exploits would need Javascript enabled anyway or some kind of images, which would not be displayed as well. Only very few bugs in basic html as far as I know.
Just want to make sure we do not just get what the mime header says to be plain text (even if it isn't) and put it in a html view. Then an attacker could just send the html exploit in the plain text part of the email and it would still render.

[philipwhiuk]

Ah no, we're not that naive ;)

[Valodim]

This should be simple to implement - the text parsing logic is already there, just need to show it :)

As a first iteration, a simple switch in the menu (similar to "Switch to dark theme") should do (see also #1397). Starting point MessageContainerView.displayMessageViewContainer

[vatsalsura]

Was the PR 748 merged into the master? If not what was the problem in it.

[philipwhiuk]

It wasn't (hence the status is closed not merged) because, as @cketti noted we were in the process of radically redesigning how K-9 stored messages in order to cope with PGP/MIME which required better handling of headers and message structure.

Also it took an inefficient approach I believe. My earlier attempt also wasn't merged.

The issue here is doing it at the right level so we aren't unnecessarily converting content.

[cketti]

Some of you seem to be mistaking this for a discussion forum. We use the issue tracker to track feature requests and bugs. At this point I think there is no relevant information any of you could add to this topic. If you feel the need to post your opinions or journey to find an alternative client, please use the mailing list.

As for the hope people put into this feature: We won't make text/plain the app default. I also don't want to make it a special case with dedicated support (i.e. displaying the text/plain part in a TextView component).
If you want to trade the extended formatting options HTML brings for a reduced attack surface, that's fine. But K-9 Mail won't be that email client for you. You'll have to look somewhere else.

PS: If you feel the urge to answer to this post, don't! Use the mailing list.

[cketti]

Please use the mailing list for discussion on what you believe K-9 Mail should or should not support.

[shiroyagi]

The reason this is important to me is that certain html formatted mails have pages that are too wide to read on a small screen. If you zoom out it is too small to see (even in landscape orientation), and panning side-to-side for each line is too painful. Viewing the plain text with line wrapping to fit the screen would solve this. The only way I have been able to read such mails is to reply and read the quoted message, then discard it.

[Hund]

Please use the mailing list for discussion on what you believe K-9 Mail should or should not support.

Your mailing list seems to be some Google product. How do I participate without an account?

The reason this is important to me is that certain html formatted mails have pages that are too wide to read on a small screen. If you zoom out it is too small to see (even in landscape orientation), and panning side-to-side for each line is too painful. Viewing the plain text with line wrapping to fit the screen would solve this. The only way I have been able to read such mails is to reply and read the quoted message, then discard it.

Considering the age of this and the fact that it haven't been implemented yet, I highly doubt that this he will implement basic email functionality like reading the plaintext version of e-mail messages.

I don't know why he refuses to. It's quite weird if you ask me, but this is his project and it's up to him to do whatever he wants with it.

[MoneyForCoding]

Now that K-9 joined forces with Thunderbird, will we ever see this option?

[spacecowboy]

Any updated plans for this?

Happy to contribute a suggested implementation.

[bohwaz]

It is quite annoying to have HTML view, often it's not really made for mobile and you have to zoom on and out just to read the content. This is an accessibility issue.

[Hund]

What other e-mail clients do we have? This, and the fact that we can't reply with proper top to bottom quotes, have made me start to avoid using e-mail on my phone.

[NormPlum]

HTML emails can be used for phishing, so there's another reason to use plain-text only:

https://lutrasecurity.com/en/articles/kobold-letters/

[pcause]

any update on this?

[seniordevel]

How many votes for this standard feature are needed, until the maintainers/developers here spend some attention on this request ?

[Hund]

How many votes for this standard feature are needed, until the maintainers/developers here spend some attention on this request ?

Considering the age of this ticket, I would say never.

[jivanpal]

@cketti Is #1397 still considered desirable and a prerequisite of this feature?

[cketti]

@jivanpal: It's almost the same feature. I don't think it matters much which one you start with.

• Toggle view between plain Text and HTML #1397 is about adding a way to either display the text/plain or text/html part of a message and some UI mechanism to switch from one to the other.
• This issue is about adding a way to either display the text/plain or text/html part of a message and a setting to specify which one to start with.

Though I imagine once people change the default to display the text/plain part, they'll find out that often text/plain parts are less than helpful. So it won't be long before they also want #1397.

[seniordevel]

Considering the age of this ticket, I would say never.

Consider that this feature is standard in most common email applications:

-- It is an improvement in readability for visually impaired persons like me
....as well as it improves privacy....
--- since html may contain code allowing to send hidden 'read confirmation'

[jivanpal]

@cketti:

It's almost the same feature. I don't think it matters much which one you start with.

So, to clarify, has your opinion has changed since you wrote #3891 (comment) ? :

What I want is an option to switch between the alternative parts of an email. And when we have that it also makes sense to configure which one should be the default.

---

I imagine once people change the default to display the text/plain part, they'll find out that often text/plain parts are less than helpful.

Respectfully, this is just ignorant of the very real set of users that actively prefer to and do read all emails in plaintext. The people requesting this feature are the kind of people that are already using plaintext as default in Thunderbird Desktop etc. without complaints or frequent toggling back to HTML view. I don't personally use plaintext often, but I know several people that use it exclusively, and would hazard a guess that somewhere between 1% and 5% of people in technically-minded professions such as software development and cybersecurity have this preference, not to mention those with accessibility needs.

---

What was the outcome of meetings re #6198, at which time #1397 was apparently under consideration but ended up not being developed?

[kewisch]

The message view is a very central component of the app certainly making it fairly complex to change. I believe the prior mention of redesigning was related to the conversation view plans, which we didn't have time to pursue in 2024. I'm considering this for the 2025 roadmap, but I suspect it will rather be a number of smaller projects leading up to a change.

I can certainly understand that users would like to see this, and those who prefer plain text for various reasons are valid in wanting this to happen. We don't have any data on what % of users prefer plain text, it may be possible to get this data from desktop in lieu.

If someone wants to work on this and is willing to provide mockups we can review together before beginning with the implementation there is a chance it could be done quicker, but otherwise I'll have to see how we can prioritize this on the roadmap for 2025. I'll keep this in mind as a highly requested feature. To the original question, there is no specific number, but I do take votes both here and on Mozilla Connect into account when looking at what my team is going to be working on.

[jivanpal]

@kewisch Thank you for this response, I really appreciate it.