K-9: 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.

[DPTJKKVH]

I think this ticket is becoming very relevant in light of this security issue: https://lists.gnupg.org/pipermail/gnupg-users/2018-May/060315.html

I'm in no position to criticize anyone since this is free software maintained by volunteers in their spare time. However I hope that this is enough to motivate the team to fix this long outstanding issue.

Maybe it's motivation to accept "secure default" as a general principle as well.

As alwys, I am willing to chip in some money on bountysource if thats required. Just name a price and I'm sure we will find enough ppl to contribute to the goal.

[Almtesh]

Hello,
I came here to post this issue, but it already exists.
What is the news about that?

[w201403]

Nothing changed, Émilien. Everything is still 11.01.2019, 10:10, "Gilles Émilien MOREL" [e-mail]:Hello,I came here to post this issue, but it already exists.What is the news about that?—You are receiving this because you are subscribed to this thread.Reply to this email directly, view it on GitHub, or mute the thread.

[Almtesh]

Really, that's strange, K9 can display both HTML and plain bodies and already has a configuration managment, why this feature is not implemented yet?

[w201403]

Probably, the position of the developers is the same: few people need a plain text. Well, why change something.

11.01.2019, 10:43, "Gilles Émilien MOREL" [e-mail]:

Really, that's strange, K9 can display both HTML and plain bodies and already has a configuration managment, why this feature is not implemented yet?

[DPTJKKVH]

For security and privacy reasons. Would be sad if the devs don't value those enough, don't you agree?

[w201403]

Developers are good. K9 Mail is single mail client on my phone for many years. But I don't understand connection between security, privacy and plain-text/HTML choose option.

11.01.2019, 10:58, "DPTJKKVH" [e-mail]:

For security and privacy reasons. Would be sad if the devs don't value those enough, don't you agree?

[DPTJKKVH]

Not a problem I explain it. (And yes K9 is good but I disagree with the devs on certain decisions.).

In 2018 there were several security vulnerabilities that were exploitable only when email was displayed in html mode. K9 wasn't necessarily vulnerable to those but the issue is that displaying html code is increasing the attack surface. It is code that is interpreted and run similar to a piece of software.

Both malicious actors and tracking/advertising companies use html code to execude the second you open and display an email in html mode. This can easily avoided by offering the option (not forcing anyone) to display emails only in plain text mode. This way the email body is not interpreted and executed like software but simply printed as static text. This greatly reduces attack surface and effectively protects against companies tracking your behaviour.

All we ask is that @cketti gives us the option like most other email clients do. K9 is great but forcing us into html mode is one of two major drawbacks that could be easily avoided.

[w201403]

Thanks for the explanation! I just didn't understand a bit. We seem to be talking about the fact that it is impossible to enable the function "plain test only". I'd like this option too and very agree with your security thoughts

11.01.2019, 11:17, "DPTJKKVH" [e-mail]:

>

—
You are receiving this because you are subscribed to this thread.
Reply to this email directly, view it on GitHub, or mute the thread.

[Almtesh]

@anonymous73, I'm trying Fairmail and it seems to do the job about that. It refuses to display HTML bodies without a warning message.

[DPTJKKVH]

@Almtesh
Thank you so much! I'm looking for valid alternative for years and this is truly looking promising! I will give it a try today and report back!

[Hund]

FairEmail have a horrible UI. It might be more "modern" than K9, but at least I can view more than two messages in the lists at the time.

And we shouldn't even mention the non-removable header reminding you to pay for the pro-version to get more features.

[DPTJKKVH]

@Hund Pro-Features are mandatory anyway if you want PGP encrypted email. And why else use k9 or FairEmail if you don't care for security and privacy? There are way better alternatives out there if you focus an looks and convince only.

[Almtesh]

@Hund, FairMail displays plain-text body by default, precisly what K9 doesn't.

[Hund]

@DPTJKKVH You're missing my point. It might be released under the GPL v3 license and technically libre software.

But having a "free" version as in freeware isn't very libre and shouldn't be promoted as such.

Don't get me wrong though, K9 isn't perfect and I wouldn't mind replacing it with something equally good that can display plain text messages. I just don't think FairEmail is a very good ethical or usable option.

[DPTJKKVH]

@anonymous73 FairEmail. Fully open source and security and privacy focused. Can be installed via GPlay and F-Droid.

[DPTJKKVH]

@anonymous73 No registration needed. Just donate 5$ if you use F-Droid or direct apk installs for all pro features via his website (accessible within app) or if you use the PlayStore just use the in-app purchase option.

And yes: I am absolutely willing to pay someone who creates good code for my privacy.

[DPTJKKVH]

@anonymous73 FairEmail is in works for a couple of months if you look at the github repo. Dunno what you mean: https://github.com/M66B/open-source-email

[yosh-se]

@anonymous73 Can you please stop using the issue-tracker as a marketing platform for other mail-clients? I get it, we want plain-text but spamming threads will only get people frustrated.

Do you have anything constructive to add?

[n-st]

@anonymous73 Please make sure to @mention people when you are looking for their opinion or reaction. They might not be subscribed to a particular issue.

As for your remarks, this is how the situation appears to me at the moment: You are coming across (at least to me) as very aggressive and accusatory ("questioning the intentions of the developers" in your very first post). Please keep in mind that this will alienate people and may cause them to discard your arguments, regardless of their merit.

Re "spamming": Discussing unrelated software at this length (currently 15 posts discussing the pros and cons of FairEmail) is usually considered off-topic on a project's issues. I'm sure people appreciate the suggestion of an alternative, but discussing its license and monetisation structure are not conducive to solving this issue here.
(And a minor addition: you can edit your posts to add information or correct typos, while keeping the issue discussion concise.)

Re "constructive input": The encoding bug is somewhat concerning, but should be dealt with in a separate issue (to make it easier to find, and to separate discussions to avoid clutter and confusion).

In conclusion: I am hoping for plaintext-by-default to be implemented, just as you are. But all-caps insults and flaunting possible alternative software are very unlikely to help move this matter forward — it may achieve the opposite by causing users and developers to ignore this thread because it no longer adds useful information.

[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]

If you have found a bug and want it fixed open a new issue with enough information so someone else can reproduce it.

[mklhmnn]

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.

Could you please explain why you make this decision? Too much work to implement/maintain? Don't care about security? Don't want to attract power users?

[nmz787]

It's clear this feature isn't interesting to "modern" users, but I'm really needing an email client that can author/compose plaintext only emails. It isn't clear if k9 can do this, but from the long history of this ticket, my guess is no.

[francwalter]

As I understand this issue/enhancement, it isn't about composing plaintext only emails, but to display only the text part.
As I understand k9mail, it cannot compose HTML-Mails anyway.

[Almtesh]

If K9 cannot compose HTML mails, what's the point to show HTML bodies by default?

[cketti]

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