Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Add option for default display format #906

Open
cketti opened this issue Nov 20, 2015 · 52 comments
Open

Add option for default display format #906

cketti opened this issue Nov 20, 2015 · 52 comments
Labels
type: enhancement New features or improvements to existing features.

Comments

@cketti
Copy link
Member

cketti commented Nov 20, 2015

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

@nd2s
Copy link

nd2s commented Mar 24, 2016

+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
Copy link
Contributor

"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
Copy link

francwalter commented Mar 24, 2016

...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
Copy link

nd2s commented Mar 24, 2016

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
Copy link

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
Copy link

nd2s commented Mar 24, 2016

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

@njeyaakili
Copy link

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
Copy link
Contributor

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

@nd2s
Copy link

nd2s commented Apr 5, 2016

@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
Copy link

dicer commented Jan 3, 2017

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
Copy link

Hund commented Jan 4, 2017

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
Copy link

nd2s commented Jan 4, 2017

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
Copy link
Contributor

@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
Copy link

dicer commented Jan 10, 2017

@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
Copy link
Contributor

Ah no, we're not that naive ;)

@Valodim
Copy link
Contributor

Valodim commented Mar 1, 2017

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

@Valodim Valodim added the good first issue Ideal for newcomers to start contributing label Mar 1, 2017
@vatsalsura
Copy link
Contributor

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

@philipwhiuk
Copy link
Contributor

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

This comment has been minimized.

@Hund

This comment has been minimized.

@DPTJKKVH

This comment has been minimized.

@Almtesh

This comment has been minimized.

@Hund

This comment has been minimized.

@DPTJKKVH

This comment has been minimized.

@DPTJKKVH

This comment has been minimized.

@DPTJKKVH

This comment has been minimized.

@yosh-se

This comment has been minimized.

@n-st

This comment has been minimized.

@cketti
Copy link
Member Author

cketti commented Feb 12, 2019

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 cketti removed the good first issue Ideal for newcomers to start contributing label Feb 12, 2019
@cketti

This comment has been minimized.

@thunderbird thunderbird locked as off-topic and limited conversation to collaborators Feb 13, 2019
@thunderbird thunderbird unlocked this conversation Feb 20, 2019
@mklhmnn

This comment has been minimized.

@nmz787

This comment has been minimized.

@francwalter

This comment has been minimized.

@Almtesh

This comment has been minimized.

@cketti
Copy link
Member Author

cketti commented Apr 28, 2020

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

@shiroyagi
Copy link

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
Copy link

Hund commented Jan 30, 2022

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
Copy link

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

@spacecowboy
Copy link

Any updated plans for this?

Happy to contribute a suggested implementation.

@bohwaz
Copy link

bohwaz commented Dec 20, 2023

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
Copy link

Hund commented Dec 21, 2023

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
Copy link

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

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

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
type: enhancement New features or improvements to existing features.
Projects
None yet