Another way of looking at this scoreboard is as an approximate inverse ranking of webmail client security and leak vectors, with Gmail stripping far more dangerous elements than most webmail clients.
This is actually a great tool to find vulnerabilities in various webmail clients such as ProtonMail and Hey, just compare the HTML or CSS features they do not yet filter compared to Gmail, then do a search for "[feature] + exploit" to see how a feature could be abused, and then submit a bounty report.
For example, there are alot of good reasons that you may not want your webmail rendering SVG images (mXSS, appcache poisoning) or allowing CSS variables or imports.
And I'm pretty sure the list supported by Gmail could also be narrowed down further. There are some fantastic bounties lurking in here, just waiting to be discovered.
SVG is a minefield so massive it's hard to give an exhaustive list of everything that could go wrong. Especially when these kinds of assets might be hosted on user content domains and where webmail clients might allow access to the SVG content with inline disposition but outside of an IMG tag (most browsers enable/disable various SVG features such as JS or an app cache manifest according to context). There are also a ton of weird rendering modes that can be triggered for SVG (or MathML) and these can be used to bypass XSS sanitizers by means of mXSS which exploits differences in browser renderings when roundtripping content.
And sites with strong CSPs are often especially vulnerable to scriptless attacks, perhaps because they feel more protected. For example, in 2019, there was a bug bounty disclosure to Fastmail about a way to intercept and proxy all email attachment downloads, completely client-side, and yet without involving any JavaScript, simply using HTML5 AppCache. This also affected a whole lot of other providers, but the Fastmail team patched this within 24 hours, a pretty amazing response, and the quickest by far.
I've said it before, I'll say it again: the web needed a vector answer to jpeg, but what we got was a vector answer to html+css with all their commensurate vulnerabilities and complexities.
is PDF. Yeah, PDF has drawing commands. Most vector formats are based on command sequences, that map 1-1 with what you'd find in a drawing library like Cairo. EPS and PDF both work that way, which makes it even more of a typical vector format than SVG (which only does the command sequence thing with paths, AFAIK). Of course, it's not that well supported (the in-browser reader does who-knows-what to get it to render, I think it's converted to DOM elements), but it is the other major browser-supported vector format.
Fastmail's security is top notch. They're using Cure53's DOMPurify and their team understand these vectors really well, with strict filtering. Their pixel tracking blocking was better than Hey's when last I checked, and I reported three leaks to Hey that were not fixed for some time. Fastmail also run one of the best bounties I have ever participated in. I would even say significantly better than ProtonMail, having participated in both bug bounties.
Nice to hear that, I'm a Fastmail customer and the Android up is subpar on offline access (or unreliable connections, looks like it's basically hitting the network for everything. Knowing that at least security-wise it's a good product makes me happier.
Some more integration with other FastMail services (like calendar or "disk space" for files) mainly. Also normal MUAs on Android are usually ugly as hell, I still have to find one that I really like. But the online-only bug of FM client is really becoming an issue worth switching.
shrug dunno what other mail clients have but I've used Fastmail's email client for over a decade and never thought "wonder if someone else's is better".
> So discover them. Roll in your piles of cash from those easy picking bounties. Prove your point.
Sure, I already did. I earned the second highest bounty for Fastmail back in 2019 for exactly this kind of exploit. Since then I've reported to dozens of programs (OpenSSL, ClamAV, SpamAssassin, ProtonMail, Hey, Missive, Yahoo Mail, Yandex, Spark, Trello, Missive, AWS, Google Chrome) and rolled in a few tidy piles.
I have also written various pieces of open-source software that would have detected and prevented four separate zero-days, affecting Microsoft (and almost every AV engine, browser, and zip parser) [1][2], Gmail [3], Apple Mail [4], and countless open-source email servers [5].
Which guideline does it go against? Can you name even one?
The Luddite "ooh this is scary" posts always do well on HN. People are allowed to disagree. When someone cites completely and utterly irrelevant authority on the topic, it just betrays that they're playing the crowd. Amazing, albeit sad, how well it works here.
> Please don't comment about the voting on comments. It never does any good, and it makes boring reading.
> Be kind. Don't be snarky. Have curious conversation; don't cross-examine. Please don't fulminate. Please don't sneer, including at the rest of the community.
> When disagreeing, please reply to the argument instead of calling names.
I'm not quite sure what flaws in attachment handling/zip bombs [literally one of the oldest and most rudimentary features] and another to do with UI encoding has to do with this post. Neither have anything to do with advanced HTML support.
Software has bugs, story at 11. Should they have banned attachments as too scary and new?
That is a completely orthogonal bit to claim authority and "win". And it will probably work on many (citations, even if wholly irrelevant -- as these are -- are a magic pixie dust on HN [1]). Weird.
100% of the time that someone claims something is easy money, their claim is, shall we say, "dubious". It's noisy bluster.
Your Fastmail bounty [2] is impressive and kudos, but again it looks like it has to do with Fastmail's implementation details to support offline use.
>This page ranks email clients based on their support among the 182 HTML and CSS features
No thanks. I still recoil at the sight of a read-receipt and the only reason most companies include any of this dreck in an email in 2021 is to either track me or market to me.
That ship sailed the instant it got named "email" instead of something like "etelegram".
With mail, I can send anything that my printer can print, which is everything my word processor can handle (fonts, text decoration, foreground and background colors, inline images, graphs, tables, and more) and attach anything that fits in the envelope (a CD-ROM of arbitrary data in any format).
It was inevitable that email would end up being able to handle the electronic equivalent of all those things.
The problem with email is not that it now handles more than just plain text. The problem is that there was no early agreement on how to handle those things, so different implementors came up with different ways to do it, which eventually converged on using HTML. Not because HTML was necessarily the best way to do it, but because it was something they all already implemented for other things or was already available on the systems their mail clients ran on.
But modern HTML engines are designed for the web, so there still really needs to be some sort of agreement on a subset of HTML that handles the things necessary to make email like mail, without including things that make sense for the web but not for mail.
>But modern HTML engines are designed for the web, so there still really needs to be some sort of agreement on a subset of HTML that handles the things necessary to make email like mail, without including things that make sense for the web but not for mail.
What would you think only makes sense for the web and not for mail?
But if it was sent registered they can at least know that you received it. And from what I gather, the consensus of most jurisprudence is that given you received it, throwing it away unopened is on you.
If companies want to have inline images in their emails, they should have to send the image data along with the rest of the message. Email clients should not allow emails to load third party resources.
"Outlook (Windows)" is dead last in the "rankings". That's pretty much the only page on there that matters sadly; Determining which features work on Outlook for Windows and that's the maximum that can go into an HTML EMail.
Sure, I'd love to only send txt mails but that sadly does not align with the expectations/desires of the companies I've worked with.
If Microsoft could just bundle their Edge/Chromium renderer instead of their ancient WordHTML engine, or even the EdgeHTML engine of the previous Edge, they'd do the whole industry a huge favor. It's so frustrating their holding us back. Instead, they allow Google to push technologies like AMP for email for things that could probably be solved with standard HTML.
The situation is wild. In older Outlook versions they've used IE to render the received mails but used a custom engine when you were writing/editing an email. You could even use Word as an editor so you could generate the HTML using Word as your WYSIWYG IDE. I can understand why that needed some consolidation into one editor and one engine but re-using Word so they wouldn't have to create a new editor wasn't the best decision for the ecosystem.
WYSIWYG editors and rendering engines aren't things I know about so I wonder if there have been difficult engineering issues at that time or if they just went at it from a business standpoint of "people see mail like letters so they are documents for which we have word so let's use that".
//Edit: Looks like they were mainly interested in providing a great WYSIWYG experience using tools users are already familiar with: https://web.archive.org/web/20110311083708/http:/blogs.offic... great quote: "There is no widely-recognized consensus in the industry about what subset of HTML is appropriate for use in e-mail for interoperability. The “Email Standards Project” does not represent a sanctioned standard or an industry consensus in this area. Should such a consensus arise, we will of course work with other e-mail vendors to provide rich support in our products." - I guess their argument could be that there still is no "HTML standard for email" so they don't have to support anything they don't want to?
They could easily do that. But they want to use their Word component to compose replies to emails. So it needs to go through the WordHTML at some point..
And from that perspective, it's better to break the mail as it's coming in (so the sender gets blamed) rather than at the moment the user clicks reply.
Biggest joke is, they're already having a decent renderer on macOS.
You can load plain HTML as a .eml template into it and send it off... but not on Windows, you're stuck with some weird undocumented binary format there.
I will never believe or respect Microsoft's supposed "open source" renaissance until they do something about reading and writing proper HTML/CSS in Outlook-Windows. The damage from the last 15 years of WordHTML has been irreversible.
I like to use wheregoes.com to probe links. I'm surprised at how many redirects some of them have. I get that an ad link might go through an ad channel, but clicking one non-spam link from a reputable company can plant cookies from a whole bunch of websites.
Why is MJML a non-option? It was a huge time saver for me. Combine it with react-mjml and you can get typesafe email templates that work in pretty much any browser. I managed templates by hand for a long time, and it took me a couple weeks to replace everything with MJML, but it was worth it.
I'm remaking my workplace's transactional emails these days (order confirmation, receipt etc. for an online shop - emails customers also reply to when stuff doesn't go as expected). We want something responsive for smartphones, but are primarily a B2B company.
I made what they wanted with MJML. Looked good in a browser, gmail and phone.
Outlook had a few issues, can't remember which right now.
But replying from Outlook simply broke the styling completely. Gaps between each section, complete mess. Not the impression you want to give the customers when their order goes wrong. B2B means Outlook is what out customers use.
I've found that replying via Outlook is the ultimate integrity test of an eamil.
Now I'm making them by hand and it is a madening cargo cult bonanza. Takes a lot of time.
> This is an Outlook problem, not an MJML or even an HTML problem.
Though you are technically correct, I just don't think this is a constructive attitude. Half the job of making emails is working around (Outlook) bugs. This is just the annoying world email coding.
If MJML is content ignoring Outlook bugs, MJML just isn't a satisfying tool for email makers.
Sure, it'll get the job done for some marketing, but now the developer isn't learning skills that will make robust emails beyond that.
Making robust emails becomes a completely separate skillset and the developer who chose to invest time in MJML will have to start all over learninging the necessary skills if he needs to make email you can actually reply to.
> Though you are technically correct, I just don't think this is a constructive attitude.
I’ve worked in email for a decade, you do what you can with the tools you've been given. An email will never look perfect everywhere and while I agree with the general sentiment you’re talking about regarding folks learning proper email code rather than relying on tools, I also think the quality of emails sent is substantially higher now thanks to those tools.
Your boss is not your end user. The way your boss interacts with the emails you send is not the way your end users do. Optimising for your boss is not how this channel should work, though I appreciate there are a lot of bosses out there who don’t understand this.
My point is that, from the perspective of email, you frequently receive internal feedback that doesn't correspond to how users actually use email.
For example, if the org uses desktop Outlook but < 1% of your audience does, is it worth optimising the email for that audience based on internal feedback?
If someone notices that something weird happens when an email is replied to or forwarded, is that something worth acting on based on the real world frequency of that action?
I agree, I’ve had pretty good results using MJML now for several years (and I’ve been doing HTML emails since almost the 90’s!)
This is a problem area where a good abstraction framework is highly useful in my opinion.
That said I don’t specialise in email, it’s something I do “when I need to”. So if I was spending more time doing this sort thing, I might be more inclined to move down an abstraction level back to HTML/CSS and improve my knowledge of various client support.
To just get the job done though, MJML is highly recommended.
I see also a lot of mentions on this thread about replying to emails breaking the layout. Part of me thinks we’re fighting a losing battle here anyway so there is a limit to how much time it’s worth spending to make sure even replies are formatted nicely across all clients. But the other thing to consider is whether the email template is just trying to do too much.
I try and keep my email templates very sparse, clean and simple and I generally haven’t had too many issues with reply/forward formatting (that I’m aware of).
I don’t want a framework to lie to me about what it is that I’m writing.
I’m not interested in learning MJML. I’m interested in learning what subset of HTML and CSS email clients render and rasterize to.
That’s it.
I’m sick of stupid developers shilling their software product that I’m suppose to build other products with.
They do it with these cutesy photoshop/illustrator logos and dribbble crafted color schemes and drop in things like made with love in (city) in their README.mds on GitHub.
I want tools, not someone’s amateur marketing campaign.
The thing about email is that renderers aren't even implementing the same spec. There is no common subset to learn. Every client implements some vague mess of 1997-era HTML/CSS mixed with different random modern features. Any attempt to try to write anything slightly advanced manually will drive you insane. Mail clients will mangle your code in ways you can't imagine. Every client will mangle it slightly differently. Even the same client on different operating systems will behave differently.
Tools like MJML take a compiler approach to email. Why waste time trying to figure out how to implement a for loop in machine code and keep it updated every time a new processor comes out when you can just let the compiler do it?
Take the top email clients and you'll sure as hell find a common subset. I don't want something slightly advanced. Emails are text and images. That it's. There's nothing advanced about that, and I'm not looking for it, either.
The idea we need compilers for everything is idiot engineering.
If you just want text and images, you don't need CSS. Just the <img> tag - and even there you'll run into differences if you try and use the alt attribute.
And even that isn't trivial. For example, say you include an basic black on white icon, what happens if the user is using dark mode? If the image is transparent, it becomes entirely invisible. If it's non-transparent then it's ugly (white box). If you want to make it change depending on dark or light mode, now you have to use responsive CSS which works entirely differently in different mail clients. What happens if the image is bigger than their viewport? Hint: it is different in different clients.
And speaking of mail clients: one of the most popular mail clients is Outlook, which on Windows uses the Microsoft Word(!) HTML renderer and on Mac it uses WebKit. Gmail on web has its own HTML parser that outputs different HTML to what you wrote (and mangles your CSS class names). Apple Mail is probably the easiest to deal with.
It's not worth learning this stuff if you don't have to. It will not benefit your life in any way. The common subset you want is text/plain.
MJML is abstracted from Mailjet’s email builder. It’s based on real-world HTML needs and the stuff it renders is pretty easy to read. You’ll end up re-implementing something like it if you try to go simpler but have a lot of work to do.
>learning what subset of HTML and CSS email clients render
You can use Table and all its related fields, span, h_, and p. Anything else is risky.
For CSS you can set the font color and size. Setting a font itself is risky. Avoid using anything else including margins and padding as these largely don't work properly. multi layered tables are your margin and padding system. You also can only use inline styles. No classes, style tags or linked styles.
Great! Now document it, create a getting started template, some component snippets, and examples, and you basically have a project that I want in my toolkit.
Not being snarky here: Isn't that what MJML is? It has components and examples and does all the nasty nesting table hacks for you.
Asking because all I know of it is from their site. I have not used it myself. Does it have its own glitches that come along during the attempt to patch over other glitches?
No, it emphasizes itself over standards, and promotes compiling beyond the scope of inlining CSS. That's enough to turn me off. It's self serving. It's not serving my needs.
There's a big problem with Foundation for Emails right now - the Saas workflow requires Node v10, which is now unsupported. You can't easily start a new project. It's unclear if this will ever get fixed.
I think HTML emails are unnecessary.
It's only useful for advertising, marketing and tracking.
If you want to show fancy css and design, link a website.
If email was used as what it was designed for, writing electronic letters to each other and not spam and ads and marketing, we wouldn't have any of these problems.
I can't agree. I quite like html email. I just wish that it had an extremely cutdown subset (just colors, a few "header" sizes, italic, bold, underlined links), NO CSS allowed, no specifying of fonts other than say mono or "other". Maybe inline images links so that attached images could insert. No tables. Only <li> or <ul> Such a system would still be completely readable as plain old text. Now everyone thinks they have to use the kitchen sink approach or that there's not a middle ground.
Settings → Preferences → Show advanced preferences → Reading → View HTML, select Always display messages in plain text.
Settings → Preferences → Show advanced preferences → Compose & Reply → Compose format, select Plain text, plus untick When replying, use the same format as the original message.
I don’t think this is such a rare feature, though it’s generally not made obvious at least.
Sorry, I suppose I wasn’t very clear. I do this through Posteo and Tutanota already (though perhaps you could sell me on Fastmail with your insider knowledge ;).
What I mean is I wish companies would send their transactional emails and newsletters in plaintext. Images and the like could be sent as attachments, as opposed to creepy weblinks that track your opens and IP and everything.
I would pay each company $0.10 if they offered me the option of receiving all their emails in plaintext like this.
They'd probably make less money if you paid them, that's the problem.
And you'd also need to be able to somehow force them to <<only>> monetize you through direct payment, because what most companies do is, take your money <<and>> also sell your data, on top of that.
If you hang out on HN a lot, I can see how you might think “most companies” are selling your data.
But this is hilariously false. Nowhere near “most” companies are selling your data.
In fact, an overwhelmingly vast majority of all businesses don’t sell your data. This is true inside Silicon Valley and even more true outside of the Valley.
Even in Silicon Valley, most companies understand that selling products and services to customers is more profitable than trashing a customer relationship by selling a customer’s personal info to third parties.
Almost every mom-and-pop store sells your data to Facebook & co. That's what those fidelity cards are for. I didn't realize that either, until recently.
Secondly, we're all doomed. I recently read an article about Amazon's ad division being as big as AWS and growing as fast, if not faster:
But possibly only because they haven't yet added 'tech' to the hip abbreviation of their industry, and realised that data is valuable, possibly more valuable than whatever their actual business is?
I think people use 'selling my data' as an (inaccurate, sure) shorthand for 'collecting so much data about me and I don't really trust them not to sell it at some point'.
I used to think that was true. But these days, I think a huge portion of companies are placing advertising or user tracking software on their websites produced by advertisers or user tracking vendors who DO capture and sell the data.
You nailed it. Since the original post is about email, I'll use LiveIntent as an example. Does the New York Times sell my personal data? Maybe, but not egregiously. But they use LiveIntent ad tags in their emails, and those tags leak a ton of data.
Maybe not directly, but a huge number of companies use tools that involve data selling, even if the company doesn't realize it. Once a marketing guy sent me a LinkedIn tracking tag to put on our website for conversion tracking. It quickly became clear he didn't know anything about what LinkedIn would do with the information. I think that stuff happens all the time.
Until recently, I worked for a company that published email newsletters and they still sent a text version along with HTML. It started back in the Blackberry days and continued because we thought it made our emails look more credible for corporate email filters.
That's about three levels deeper than most users are comfortable navigating, and as such only a negligible fraction of users will ever see this setting, understand what it does, and change it. Too bad every enterprise solution defaults to HTML anyway.
I wrote out the full path to it, but Preferences is the default page in Settings, and Reading and Compose & Reply are just sections inside it. So it’s actually more like “go to Settings, click Show advanced preferences at the bottom of the page, and search for ‘plain’”. And yeah, it is an advanced preference, whether you’d prefer otherwise or not.
Most users probably don't care about HTML versus plaintext emails. The ones that do care would be the ones willing to pay $0.10 extra per month to enforce plaintext receipt, or willing to dig through a few levels of configuration to enable plaintext receipt.
TricepMail has granular/heritable switching between plain text or HTML, with or without images. For example, if you have a mailbox set to plain text but receive an email that you would like to render as HTML, it's just one click away for either the entire thread or just that message.
I really don't like HTML emails as they very often break with my dark theme. Especially those in Outlook, dark blue on dark gray is not very visible. I'd like to have only plain text emails, but some website do not put text version of their mails (notifications...).
On a very similar discussion (e-mail feature bloat; particularly HTML mail) I once heard somebody describe the software developers involved to have suffered from "Beach Boy Syndrome" (wouldn't it be nice if...)
I've been using thunderbird for probably 15 years and have forgotten about html emails. I can imagine they are popular but it is probably the great fishing surface the average user is exposed to.
You say that, but then a couple of times a month i get emails from a certain cultural society that for some reason always come out with the main text in one giant, one letter wide column… Both on the phone and outlook webmail!
I still only send plaintext myself, but clearly that ship has sailed. Many mailers don't even bother adding a proper text/plain alternative anymore.
I caved in and replaced mutt with Thunderbird personally. Not only for properly displaying HTML, but it was a big reason. Thunderbird sucks massively for composing plain text emails though, and no simple way to integrate an external editor...
> I caved in and replaced mutt with Thunderbird personally. Not only for properly displaying HTML, but it was a big reason. Thunderbird sucks massively for composing plain text emails though, and no simple way to integrate an external editor...
Have you considered emacs with notmuch and the Gnus renderer? It displays most HTML emails well, and when it doesn’t then a browser is just a quick ‘. b’ away. And of course there’s no need to integrate an external editor, because it’s integrated within the editor!
As a plus, it is simply amazing how quickly one can search local email.
I’m not saying it’s reasonable, I’m just saying I would prefer it. I also would prefer websites without ads and social networks without arbitrary “community rules” but it’s not going to happen.
And of course nowadays there is Markdown, which basically codifies a lot of earlier plain-text formatting conventions.
> Please don't say "there shouldn't be formatted text in email." That's not a reasonable position.
I don’t know about that, really. We got by fine with plain text messages for decades, and the formatting conventions were good enough to convey meaning and nuance.
Once email was in wide use by the general public, easy formatting was inevitable. HTML was everywhere, and so was the path of least resistance.
I thought it awful at the time, but "at the time" was literally more than two decades ago. HTML email is fine. MOST mail I get, professionally, has some formatting in it now. MOST mail I send probably does, too, to increase what a mentor of mine used to call "scan value."
Could I put all that in a Word doc and email THAT instead? Sure. But that would be a huge pain in the ass.
Improvements are awesome! That’s why I linked to the text/enriched RFC. I really wonder if anyone who downvoted actually read it, or just emotionally reacted.
I don’t think that HTML emails are really an improvement: full-fledged HTML engines bring in too many opportunities for exploits and privacy loss. They definitely add capability, but at too high a cost IMHO.
In general, I think that our industry would benefit from asking ‘can we?’ less and instead asking ‘ought we?’ more.
However, my thread is more "can we do it differently?" instead of "maybe we shouldn't do it at all"
I agree, HTML isn't right for email.
Some different approach, possibly a markdown variant, with decent style support (basic css like background colours, fonts, like markdown themes in a code editor), why not explore that.
There's no reason emails need to be plain. RTF is a horrible format, markdown is much more prevalent and easy to make a simple UI formatter that obeys the standard for non technical users.
I would say that, generally, higher complexity results in more possible attack vectors. Give that assumption, any client high on the list has more attack vectors than ones down the list.
I also think, though, that any open source client likely does a good job regardless of feature density, since its likely going to use well vetted code in core components.
Saying that, for example, Microsoft's or Apple's code isnt well vetted is unfair, but the amount of eyes that have seen the Microsoft html renderer vs the, say, WebKit one, is likely smaller and less diverse.
…as long as they contain the same content. I've seen e-mails where the HTML content is up to date, and the plain text part contains whatever was being sent a couple years ago, and hasn't been updated since then. Got me quite confused until I figured it out.
Its arbitrary cause there is no RFC about the ah-hoc choices email client softwares have made over the years that have kinda become de facto "standards"
Targeting HTML rendering engines which are email clients.
Fortunately (at least for some of the newer features to be included)
Links to MDN are available, and caniuse both link to we spec). CSS min for example is working draft.
https://www.w3.org/TR/css-values-4/#math-function
With 90% desktop/mobile browser general usage support, 50% email usage support.
I made the mistake of giving too many companies my email address when those stupid black-the-page popups come up asking for my email. I am in the process of unsubscribing from every one of those emails; there is usually a small “unsubscribe” link at the bottom of them, and they are usually pretty good about honoring unsubscription requests.
These days, I disable Javascript on any site which has the audacity to put a popup in the middle of the page as I am reading it. Any site with is not readable without Javascript is one I leave and don’t go back to.
The kinds of sleazy outfits which do not honor unsubscribes are the kinds of places email providers are really good about black listing.
This seems pretty useful. I'm actually working on a project right now (https://postheat.com) to automate all the styling and html for devs and I've had to learn most of this the hard way...
I think you need some example search b/c I was not sure how to use the tool at first.
I still prefer text-only emails. I block as much external content as possible and usually those marketing and elaborate designs are all broken. It is very rare that I allow exceptions.
That being said, I can see the usefulness of this tool for developers, I just wish people would rely more on plain text.
It would be great if the JSON data could be easily plugged into a linter so you could quickly validate if you are likely to have issues on a given client or not.
It's tempting to make shouldiemail.com and just answer "No" for all these features. Seriously though, it must be years between every time I see an HTML email which would not have been improved by being plain text.
What the average HN user and the average user want is worlds apart. The average person likes their emails to be nicely designed like a website with blocks of colour and the site logos.
When they see a plain text email from a site they would be more likely to think they are being scammed than to be impressed at its simplicity and ability to display in the terminal.
When every website is hacking around broken table layouts to get them to render in outlook (essentially Word), something is wrong and should be fixed.
I posit that the average user doesn't want to put the time into reading plain text to find out if the email is worth their attention, images and colours are easier and quicker to process. A lot of information can be communicated quickly with some photos and a nicely formatted graphically rich message, probably with a large link button that takes the user to a relevant web page for further engagement.
This is not an endorsement of the practice, just an observation.
But do they really? Most those "nicely designed" emails, to be honest, are spam. Either outright spam, like v14g4 and p3n1s pills (modern mail systems deal with those well enough), or only slightly more respectable spam like "you bought in our store once, so now we will hound you forever with ads for our good and services that you don't need anymore".
Among this sea of garbage, there are rare islands of useful updates - like genuine newsletters I subscribed to, or email from my doctor about test results, or reminder from my bank that they are going to deduct that car payment, whether I like it or not, so there better be money there, etc. And of course Amazon shipping notifications! If all those need any HTML, then only the most rudimentary one.
Of course, if you asked a user whether they'd want to get ugly marketing spam or beautiful one, I guess they'd choose the beautiful one. But that's not the right thing to ask.
This is absolutely not my experience. Spam uses HTML formatting, sure, but it's not "nicely designed".
"Nicely designed" emails are things like flight confirmations, invoices, shipping notices, and that kind of transactional email. The common thread is that some entity with Real Money To Spend on a graphic designer is sending a (usually form) email to lots of people. Most spam outfits do not have those kinds of resources, especially since they need to change up their emails constantly to avoid spam filters.
The closest I would say that the "pretty" stuff gets to spam is newsletters and particularly political fundraising emails; I'm on a lot of political party lists after spending copious college free time working on campaigns.
The common thread about those non-spam transactional e-mails you mention is also that they're usually barely above plaintext. They usually contain some minimally styled table, and some of the company colors. Maybe their logo somewhere. That's in stark contrast from the spam these same companies send, which is where all that "Real Money To Spend on a graphic designer" goes. Compare e.g. the spam PayPal sends you vs. the e-mails confirming payments you've made. In my experience, this is pretty universal.
And speaking of universal heuristic, in my experience, the quality and relevance of content is strongly inversely correlated with the quality of design. The prettiest websites out there are ones that deliver negative value. The best designed (according to modern trends) user interfaces are the ones with worst ergonomy, wasting user time the most.
And yes, the subset of spam that's most recognized - ED pills, reproductive organ enlargement, members of royalty looking for help managing their finances - they tend to be very simply designed. But their distinguishing feature isn't simplicity of design. It's the carelessness. Typos, bad grammar, highly visible formatting mistakes, etc. When, on occasion, one of that "old school" spam messages tries to pose as a legit transactional e-mail, you can see through the deception by noticing the carelessness in replicating the design of the company being impersonated.
> And speaking of universal heuristic, in my experience, the quality and relevance of content is strongly inversely correlated with the quality of design. The prettiest websites out there are ones that deliver negative value. The best designed (according to modern trends) user interfaces are the ones with worst ergonomy, wasting user time the most.
This is just plain untrue, and seems to color your impression of email as well. See e.g. Delta vs Southwest (more polished look is more ergonomic site/app), or New Relic vs Datadog public-facing sites (indistinguishable in "quality" of the design, for competing products where IMO Datadog is better).
What are some examples that put the inverse correlation in your mind?
V1gr4 spam isn't nicely designed, but marketing we-arent-really-spam-because-we-have-unsubscribe-link spam - surely is. That includes political marketing too, of course, selling politicians is just another form of selling.
I run an email forwarding service[1] so I deal with spam a lot.
Spam usually has bad formating, mixed charset, old/broken layoyt etc.
Most of time, spam are odd designs. Example they only have HTML and didn't have the corresponding plain text part. They have large pictures and too little text, they have many "invisible" part so that hide behind element to trick you to click the wrong thing.
Even in plain-text, spam tend to include random links, very long text, weird chracter etc
A nicely design, or a plain-text emails(only plain text) with nice format all are good signal of non-spam.
In other word, consistency is signal of non-spam emails. But sometime marketing emails-which you never explicitly subscribe to, you just register for an account and got marketing emails, can also be consider spam, but from google/hotmail point of view they don't consider these are spam and that's reason they have Promotion tab to put thing in there
This may come down to whether you consider marketing email from legitimate businesses to be "spam" or if you reserve the term for the more scammy/seedy type of mail.
I unsubscribe from marketing mails, those are legally required to have an unsubscribe link in them. You should try clicking on that if you don't like marketing mail. If they don't stop you can threaten legal action in both EU and US without issue.
If it doesn't have this link, it's spam. If it's trying to get me to buy something I didn't explicitly wishlist on a store, it's spam. If it's unsolicited marketing, it's spam.
And even if I were to include all marketing email, including those I am interested in, then plaintext mail would still constitute the majority of spam mails I receive.
I personally found out that it's easier and faster to train my spam filter to move these mails into the spam folder. (I'm using claws-mail with bogofilter, which works quite well.)
Whenever I have to interact with a company, I check the spam folder for their replies.
The majority of mails in my spam folder is html mail.
It's safer as well. Some (most?) of those "unsubscribe" links have a unique ID hooked in with your email in some database so they know that they have a hit and can send more email to you.
Well, they need something to be able to tell which email to remove from their DB too.
Not all is as sinister as it looks.
The simply solution is to just can any senders that don't respond to unsubscribe requests. But those will be just as bad in plaintext as in HTML, so I don't see why Plaintext means it's not spam, they can do the same thing Plaintext.
The majority of mails in my spam folder is plaintext mail. Second place are the extremely malformed HTML mails. Almost any wellformed HTML mail I receive is solicited at minimum.
I can recommend using the unsubscribe link if you forgot to uncheck the newsletter checkbox during registration. Alternatively send them a mail to A) remind them of the SPAM-CAN act or your local equivalent legislation and B) that they should delete your mail from the newsletter. That works almost always, if not you can always threaten legal action (where I live, that's an easy 600€ of profit in a courtroom).
That's... what I said. I mentioned the unsubscribe link for solicited marketing mails, where that is in fact relevant. Unsolicited email would be pretty damn illegal in my home country to begin with (and a GDPR violation).
It is illegal but very common. Many of those emails with unsubscribe links are unsolicited. They either spam all their former customers no matter if they have opted in or not or they just buy links. Yes, the unsubscribe links work but what they do is in obvious violation if the gdpr and other laws.
Very few companies would risk those lawsuits, especially in Europe the fines can get rather exponential for repeat violators and I don't think it's much different in the US either. If the unsubscribe works, that is the end of the story for me, and a reminder to check for small newsletter checkboxes when signing up to things.
I very rarely get marketing mails from any reputable company that are completely unsolicited. In most cases it's a followup from trying out an offering or updates to products I'm using or are adjacent to those. If I'm not interested, I either ignore them or unsubscribe if it's repeatedly not interesting.
This is a much more effective "spam" strategy compared to "all HTML is spam".
Spam sent to different domains (especially in different TLD) tends to be different so experience can be different.
In my observations badly formatted spam exists, but have big intersection with the spam which is relatively easy to filter out. Nicely formatted HTML spam on other hand is hard to filter because the only difference with legitimate marketing email is lack of any consent from the sender. Sure I can hit an unsubscribe link and my be never will get spam from the same domain again, but spammer will know that this email is active and will include the address in spam send on behalf of other customers.
Well, that is where the line of solicited and unsolicited mails fall, spammers are generally unsolicited (so no previous mail address confirmation), their unsubscribe links won't work and >90% of them are plaintext with the remainder having bad or illformed HTML. 99.8% of marketing mails I get have an unsubscribe link that works because it forgot to uncheck the newsletter when signing up, those are not an issue. And those are usually HTML mails with well formed formatting.
I just looked through my Junk folder and it took me about 30 seconds to find an email that was sent as plain text. Most of this time was spent digging through Mail's menus to figure out how to show the raw message.
> What the average HN user and the average user want is worlds apart. The average person likes their emails to be nicely designed like a website with blocks of colour and the site logos.
Do they? Do they really like it? Did anyone actually asked? And no, A/B testing your design's capability to trick the user into paying you money isn't measuring whether they like it or not.
I have an alternative proposal: average user just accepts what they're given, because they have no other choice. Nobody listens to their opinion (again, tracking and telemetry is not the same as listening to people). Abusive designs and patterns are adopted industry-wide very quickly, so there's rarely an opportunity for the user to vote with their wallet - after all, they can't choose something that's not available in the first place. On top of that, the average user lacks the mental models and language to conceptualize what is wrong and how much better technology could be if it was slightly less abusive. All they can do is accept that computers are annoying, and casually complain about this to friends and family.
There's a reason the most popular media is video and images and the main social media platforms are practically platforms for sharing video and images.
The average person all over all the world is almost functionally illiterate (literacy level of a middle schooler or maybe high schooler, at best). They really, really don't want text. They'll only read as much as they have to, and they will definitely choose images over text if they can.
I don't even think it's a matter of liking or disliking, but more a matter of being blind to the standard formatting (something that most deal with on their jobs).
At the end of the day if you see another blob of text, you either skim through it looking for what matters or you just delete/archive it.
They could even hate it, but it just stands out for better and worst.
> Do they? Do they really like it? Did anyone actually asked?
Oh yeah, they do like it and want it. That is why they use it. And yes, I talked with a guy who was literally like "I like the emails colorful and such, but we found through testing developers respond better to plain, so I send plain to them".
> What the average HN user and the average user want is worlds apart. The average person likes their emails to be nicely designed like a website with blocks of colour and the site logos.
Taste is generated. Cool trendy startups make "nicely designed" emails, users come to expect that. If scam emails looked "nicely designed" and Google sent emails in plaintext, the "nicely designed" emails would be considered untrustworthy. As a counterpoint, an "average user" wants software to work, and forcing every email client to parse HTML (which is far outside the scope of what an email client should do, especially with html as complex as it is today) often breaks things in unexpected ways.
In my opinion, html and plaintext are both inappropriate for email. HTML is far too complex, and plaintext is a bit too simple. I think a markdown-like syntax would be the best balance, but I'm pretty sure that ship has sailed.
From what I've seen from average user, they tend to struggle pasting text with the same font into their email reply, struggle to quote parts of the message or email hyperlinks in usable manner.
And thus is what people have come to expect, sadly, IMHO. Except for the technically inclined/HN userbase. Though another comment said Germans prefer plaintext emails w/o attachments.
Wouldn't say that is entirely true. Germans prefer HTML mail that amounts to simple rich text, ie bold and italic fonts, possibly some color highlighting if you're really daring. Pure plaintext isn't that well appreciated.
> Except for the technically inclined/HN userbase.
This community is as much an echo chamber as anywhere else. Just because an opinion is common here doesn't mean it's correct or reflects the wider population.
Beauty is no quality in things themselves: It exists merely in the mind which contemplates them; and each mind perceives a different beauty. One person may even perceive deformity, where another is sensible of beauty; and every individual ought to acquiesce in his own sentiment, without pretending to regulate those of others. - Hume, D
A commercial project aims for profit, not public service. The previous post explains why they are popular demands. And it is natural for commercial project to satisfy popular demands.
I've corresponded with others, also German, and they had the same preferences, even if not as explicitly stated as the examples in my other comment there.
We used to have our German newsletter available in plain text and styled. The vast majority of people chose the styled version. Not even 1 % picked text. No dark patterns involved, a simple radiobox. We do not offer the text version anymore.
I’m not the person you are responding to and I’m also a software dev (ie. not the average user), but I prefer a nice looking email that includes some simple graphics and formatting. So that’s at least one person that prefers that kind of thing to a plain text email and I’m pretty sure I’m not alone. I think we can probably agree that there is a large subset of the population that likes “nice looking” websites, so why would emails be different.
> Now, with the emphasis on imagery across the web, users strongly preferred images that could be seen full screen or at a larger scale, looked high-quality, and showed detail clearly.
That article seems positively rife with weird assumptions, all to present email marketing in a favorable light. It's bad enough that I don't really trust the quote you gave from it.
> Because several of these constraints have been remedied over the years, many of the concerns that users had about subscribing have disappeared.
Read: Because we stopped asking permission and instead started spamming everybody who gave us their email address, people stopped thinking that not subscribing had any effect.
> The increase in sheer email volume over the years has created a scenario where people can’t possibly give all messages their full attention, so they care less about what they receive because they know they can easily ignore the noise or choose what they invest their time in.
Read: Our entire industry spams people so much that people know it's not worth reading.
> It’s no longer used strictly to describe unsolicited email messages. Participants in our study used the word “spam” to describe solicited marketing emails that they considered random, impersonal, irrelevant, with too much promotional hype, or coming in high volume.
Read: We required an email address for things that don't need one, then treated that as permission. How dare people consider our spam to be spam?
> Now that organizations are required to include an Unsubscribe link in their newsletters, this task has become easier.
If a company assumes that an email address given for identification can be used for marketing, or that it can be shared with third-parties/affiliates for marketing, then they are already pretty shady. I honestly have no way of knowing whether it's an actual Unsubscribe link, or whether it's a signal that the email address is actively read by a human and so should receive more spam.
> If users keep getting unwanted newsletters, the messages will start to backfire and become regular reminders that they’re annoyed with your company. Better to let them go.
This part I do agree with. Better still would be to not assume permission to send marketing to somebody just because there was a pre-checked both on a form.
Fully agree. When we launched our service, we used really simple plain text mails and we had users complaining that they looking unprofessional and spammy. We didn't go crazy with our email design, and we're certainly not pushing the limits of what's possible to use in an email, but just adding a bit of color, a log and some text formatting made a big difference. Haven't heard a complaint since.
I looked at the mail I really wanted to read from the most reputable entities (banks, government, business partners,...). Usually there is a logo at the top and the rest is mostly plain text with minimal formatting. A nice, colorful email, sometimes from the same companies usually mean one thing: ad.
This is no different from snail mail, where important communication is usually on standard white paper while ads are high quality prints on nice goossy paper.
And obviously, "average users" notice the pattern. Just like my father who almost trashed an important tax-related mail just because it looked too nice, he thought it was an ad.
So the "average user" prefer to see nice ads, I can get that. But what the average user really prefers no ads at all.
I disagree; while fancy stylings can be excessive, being able to use things like screenshots, headings, and tables is very useful. Sure you can do images and tables through attachments, but that adds extra steps which are inconvenient.
Recently, I sent a longer-form announcement email and I think it really benefited from simple formatting. Headers that were visually distinct made it easier to parse, and in one place I set an image to float right which I felt made it less disruptive. I even set a max-width on the whole email, which I think works far better than the hard-wrapped text that some people write.
Almost every day, I find myself sending and receiving screenshots placed in context with some text and bullet points. Dare I say it: I love HTML emails
It at least implies a certain lack of technical expertise on the part of organizations that send such HTML only emails. The same for when they put completely unformated garbage in the text part. If W3M can do a better job starting with their HTML email you have to ask yourself why they couldn't of done at least that instead of whatever they did.
> What’s lame is when there is no plaintext alternative.
Or worse yet, when the plaintext alternative version is broken/incomplete.
I regularly receive mail where the plaintext alternative version has templating variable names instead of actual values, where the html version has the values.
Also, systems that send mail where the plaintext alternative version is only something along the lines of “Your email client does not support HTML. Please read this newsletter at” and then a link. But of course, my client can read html too, I just have it set to view the plaintext version by default.
One of these days I will probably just set it to always prefer the html version instead. I use mutt, with elinks taking care of html to plain text conversion. I’ve been running my mail server for years.
But anyways it might soon be time for me to switch to hosted mail. I have a provider in mind.
Sometimes plain text alternative is so bad that one forced to use HTML version anyway. I've tried plain text emails in Atlassian Jira settings - emails it sends are badly formatted and have lots of empty lines, likely they make plaintext version from HTML one with something like `lynx --dump`.
If it was sent personally to you by somebody who knew your preference you might be right, but realistically the number of people who cares or who have any issue with HTML mails is going to be sub 0.1%, so it is almost certainly more a case of don't care, not worth considering.
There's a very small set of text decorations which would suit virtually all cases.
And there was a long history (about 100 years) of monospaced, mono-sized, typographic conventions based on typewriters and cheap reproduction (carbon paper, spirit duplicators, xerography), before the desktop-publishing era brought us out of that in the 1980s. The problem with formatting is that, like Johnny Rocco in Key Largo, someone always wants more, and not for your benefit but theirs.[1]
In the Web world, counter to an argument elsewhere in this thread (https://news.ycombinator.com/item?id=27113404), my experience is that Web design isn't the solution, Web design is the problem. Straight ASCII text (via w3m or other text-mode browsers), or Reader Mode (where supported) is vastly preferable to many, many nines worth of sites' prescribed designs.
One thought I've had is that user agents could provide, at user discretion, additional typographic control to sites. But for the basics you're limited to 7-bit (not 8) ASCII. Everything else is earned, and you'd best degrade very gracefully.
I've seen websites written where every individual paragraph has an explicitly-specified location. I've seen blogs written entirely in header-level tags. I've seen writers who add nonbreaking whitespace to the start of every paragraph. I've seen blink, marquee, and carousel abuse. I've seen foreground and background colours you wouldn't believe. Attack ships on fire off the shoulder of Orion....
I would be fine if my client would neatly format a limited markdown format and other clients supported entering it in a WYSIWYG fashion, as long as all the displayed content is part of the transmitted message (no further connection to the net) and the client is guaranteed not to execute any sender-supplied code or transmit any data when links or images are displayed.
Just a heads up that screen readers will tend to read sentences like that as "I think you meant MATHEMATICAL BOLD SMALL B MATHEMATICAL BOLD SMALL O MATHEMATICAL BOLD SMALL L MATHEMATICAL BOLD SMALL D comma MATHEMATICAL ITALIC SMALL I MATHEMATICAL ITALIC SMALL T MATHEMATICAL ITALIC SMALL A MATHEMATICAL ITALIC SMALL L MATHEMATICAL ITALIC SMALL I MATHEMATICAL ITALIC SMALL C and U N D E R L I N E" and so on which can be extremely unpleasant
I don't get why you're being downvoted. Every time Unicode support or rich text formatting comes up on HN someone wants to show off how "smart" they are.
I got an almost identical comment when I said HN doesn't support any formatting, except for italic and link formatting.
Inputting by hand (or maybe with a script - who cares anyway?) random Unicode characters to show that rich text is actually possible is the opposite of "smart" in a discussion between reasonable adults.
I did it by hand. There are websites to do this, but I’m not interested in doing this for any regular purpose, so I don’t think I have them saved. Besides, it’s more interesting to do it manually; you learn things about how Unicode works if you involve yourself in the low-level details once in a while.
> the opposite of "smart" in a discussion between reasonable adults.
I don't think you need to be so negative about this.
Most people are unaware that Unicode has that kind of character and even fewer people know what it does to screen readers.
The difference between showing off knowledge and trying to be show people a cool thing you know about is intent and it's REALLY hard to get that across on the internet.
Not sure about every HTML being plain text but I do wish I had $20 for every overly image heavy email that has no meaning what so ever unless I do "show images." Don't brands understand a fair number of ppl have their email client *not* display images by default?
Unless you are using Mutt or similar I don't think anybody does not show images by default. I know thunderbird has no problem showing me images that are included in the email.
Remote images are a crime, break the ability to search ofline or keep a record of ones conversation but they have one key advantage for brands which is to spy on you.
Rainloop web client used by Disroot and some others defaults to not showing images and needs you to click a button to display them. IIRC Protonmail is the same in its webmail.
The only non-web client I've used much in recent years is aerc, which is basically covered under "mutt" in this case.
Honestly I'm using Thunderbird only because of two things:
- Plain Text Mode
and
- uBlock Origin Extension is available (that can block also embedded JS)
People underestimate the attack vector of emails. I'm glad those scammers haven't figured out (at least until now) how XSS could work in Gecko with XUL. Heap spraying could easily be a thing, given that MS Outlook also still uses their outdated rendering engine.
I typically compose all messages in Markdown and then convert that into rendered HTML. So if you believe in the expressiveness of Markdown (which I hope you do), then HTML rendering is absolutely necessary.
Unfortunately, desktop Outlook is miserable with HTML support [1]. In particular, code blocks and quotes become an unreadable mess. The only way that I've found to include readable code blocks is to copy from VS Code, which somehow has the magic HTML combination that Outlook understands.
FWIW, I just don't support HTML email and only for a small handful of services and senders do I ever get burned. If my email client did a pass over the HTML and gave me all the text followed by all the links that would be sufficient (right now I sometimes simulate that by opening up the raw MIME and grabbing what I need). Like, do we live in a world where this even matters? How is your life being made worse by people using these features? E-mail was explicitly designed in a way to support emails that have both HTML and non-HTML, and for people like us--"worst case"--the HTML can be stripped to text and it is fine.
For most regular emails and newsletters I would agree. Those who truly care to know which HTML and css tags are available in email client are sending some for of ad.
Say you’re a webshop and a customer has signed up for you “newsletter” then you kinda need HTML emails to show your advertised product directly in an email client.
Homer didn't need rich text to write the Trojan War. Neither did Shakespeare, nor Ovid for their writing. My emails are way less ambitioned and are fine written in poor text.
But, almost everyone does? Would you prefer all web articles to be strictly in plain text, same colour? No font changes between text and code, no colors for quotations, no indented multilevel bullet points? Basically, nothing that markdown can do. In your opinion, those things don’t improve ease of reading, right? What about syntax highlight in code - nobody needs that either, am I getting it right?
And how are emails any different from web articles? Both contain structured thoughts represented as structured text, both often contain code and quotations, lists and so on. Why special treatment?
I also prefer plain text email. HTML email is no good, I think. However, you can use a multipart message with a plain part if wanted; Heirloom-mailx and other plain text email clients will then display the plain text part in that case.
You could specify "Content-type: text/markdown" if you want Markdown (although I don't know which email clients will understand that), although I think that plain text is OK.
I also dislike email newsletters or email discussion lists; either way, I would prefer NNTP.
Apologies, just someone who recently had a customer try to convince me I should rewrite my FPGA code to handle his one or two off product (but very expensive) product for free :) so I understand why developers can't target every user haha.
This is actually a great tool to find vulnerabilities in various webmail clients such as ProtonMail and Hey, just compare the HTML or CSS features they do not yet filter compared to Gmail, then do a search for "[feature] + exploit" to see how a feature could be abused, and then submit a bounty report.
For example, there are alot of good reasons that you may not want your webmail rendering SVG images (mXSS, appcache poisoning) or allowing CSS variables or imports.
And I'm pretty sure the list supported by Gmail could also be narrowed down further. There are some fantastic bounties lurking in here, just waiting to be discovered.