Subset: newsletters
I think about this all the time.
The only thing holding me back from moving interi.org mail to ProtonMail is that I can’t use mutt with it yet (IMAP support is a promise, but I can’t find it at the moment…). That is how much I rely on text-only email.
But in an advisory role, do I recommend mutt as an email client? I don’t even personally know how to install it on most of their OSs, but also of course you go with the webmail solution. Email on web = killer app!
I suppose a useful tool would be how to block HTML email guides for all the major providers…
Anyhow, my thought is always elitist, because at a fundamental level I don’t feel it is a problem I have, personally. Phishing attempts are so obvious to me, a paranoid survivor, always filtering for social engineering attempts, like all the time, even when I shouldn’t be. In the article they even link to a separate piece with the hypertext, “stop clicking on the wrong thing”, and that pretty much sums up my feelings.
And then I think about all the free software that sends reasonable HTML mail (like Discourse), and having to modify that behavior to accommodate a text-only communication. Sounds like such a pain! But on the other hand, some projects make decisions that seem helpful, but endanger users (like WordPress linking to Google fonts) and how that can indirectly affect a lot of unsuspecting users (this is why I am always reporting WordPress plugins that link to external sites, so we can clean up the public repo of surveillance).
I’ve been thinking about this in the context of if I had one class (like, an hour or more, but just one sitting) to teach a group of people about how to use email, what would I include. Because I can probably swing that kind of thing with clients and random folks at the Hub. 
1 Like
One thing I keep coming back to, as HTML has gotten more robust and people have moved to things like markdown for lightweight markup; maybe the lightweight markup approach would be much better for some applications than html.
Would be interesting to see markdown handled as rich text in email for example. It nails most people’s use case with none of the security problems.
It’s helpful to that markdown is backwards compatible so to speak with text. It would therefore still be intelligible to clients not supporting it.
1 Like
Would that need a new MIME type? I forgot which project it was, by someone was talking about discovering Markdown from context, but I forget if that is easy or not.
The point I am flummoxed by is allowing remote resources to be loaded. There shouldn’t be any JavaScript allowed, and only inline CSS. Combine that with reasonable limits on message size, and I think we’d see an appreciable change in attacks.
I am guessing we don’t do that, collectively (again, I use mutt, makes me love email!), because most folks use a web-based client. Email has always been strongly tied to vendors, and blocking functionality in email is a disadvantage, so this relationship has been a race to the bottom.
It irks me so much, because the people most affected by this really can’t be bothered; they are struggling to get their jobs done, to support their families. The last thing they need is someone saying how bad their email software is, and they should know better. In fact, the email vendors should be going to bat for them.
I am not sure you would want to make it another mime type. That might foul up the desirability of it being backwards/forwards compatible with text. Maybe yet another x-header to clue email clients in? Its an inelegant solution but there is already a lot of bloat in that space. Why not one small extra addition?
I think part of it is that parsing HTML is a pretty complex problem, and most of the libraries for parsing it and displaying it are full blown browser engines. I haven’t looked at them lately but a lot of the stand alone simpler HTML rendering engines associated with GTK died a pretty quick death when webkit took over.
We have been seeing variations of this problem for more than a decade now and it isn’t going away. I remember when Yelp first switched to *gtkwebkit and similar vulnerabilities were identified in the next breath.
I personally think that is reasonable, especially as an easy way to prototype that kind of rendering in a client. But I flinched when I first read that. 
Now is as a good a time as ever to properly document all the web browsers out there right now…