> Rich text features desirable for end users include things like inline images, bold or italicized text, and so on. However, the tradeoff isn't worth it. Images can simply be attached to your email, and you can employ things like asterisks, /slashes/, _underscores_, or UPPERCASE for emphasis.
Well, why bother writing his own post in rich text then? He has headings, bold, links, grey font at the bottom, image.
Don't get me wrong - for high security systems/environments, plaintext is way to go. For everyday life use cases I prefer html. Although with Markdown rendered text I would be pretty happy. And enough for author to cover his post sans the green/red boxes and grey text.
But emails can be reference documents too! In fact I would argue most work emails that are longer than a few lines are a reference document of some sort.
Then you are better off using some format that can stand alone as a file such as PDF. If it is a reference document that is intended to be edited on an ongoing basis it is better to use something like a wiki. Having to root around in your email to find a reference document is pretty inefficient and annoying.
All of the reasons given against HTML emails hold at least equally well against PDF: it's a vector for phishing and tracking, ripe with client vulnerabilities, less accessible and not displayable on a terminal. For me as a reader having to read both an E-Mail and the attached PDF is also annoying, and many people will simply skip reading the PDF.
why not let people syntax highlight the way they want? some people dislike syntax highlighting, some like high contrast highlighting, some like blue-tinted highlighting, etc. why do you get to decide for everyone what colour strings should be?
send the plaintext code snippet and they'll decide.
For the life of me I can’t remember the syntax for a particular thing I do in the JavaScript console at work. Someone showed me the trick in an email about seven years ago and about once a month I need to do this thing so I search my inbox for the email so I can remember the syntax.
It might be "easier and faster" to send an email than to, for instance, upload to a dedicated snippet manager, but literally everything after than that is slower and more difficult.
Exactly, work mailboxes are a treasure trove of automatically-archived information. I'd argue that these days, emails form more of a "knowledge base" than any other single repository of information for most organisations.
This is very true and yet the search tools supplied with these knowledge bases are terribly inadequate. Is there a better, standalone tool out there for turning email archives, from multiple sources, into a usable database with a powerful query language?
Not sure if that's what you're looking for, but you could use notmuch[0]. Haven't used it a lot, but I think it can import an mbox? Maybe you can merge multiple mboxes together?
I looked into that a few times, just haven't had the patience to get through the setup process. Maybe I'll get it done this time. There goes my afternoon :)
I was keeping an eye on this in the hope that someone had a good answer for it. What features would you consider adequate for this kind of email search? At the moment I just have everything in Thunderbird and it does a passable full-text search on a ~5gb mailbox but I haven't experimented with anything fancier.
email is a terrible place to keep reference documents.
"where's the information on that?" "oh, you should have it in your email somewhere. I think I got one a few months ago about it"
no. just. no. If you care _at all_ about your reference documents you get them out of email ASAP.
And that's ignoring that anyone can delete old emails and thus not have what you considered a reference doc but they just considered old mail. Or that the server could loose your emails and no-one has they synced locally these days.
> email is a terrible place to keep reference documents.
Newsgroups are better in that regard. You can reference the message using the message-id value. A lot of newsgroups would have FAQS posted every 30 days or so. A reference document that's periodically updated could be sent the same way.
That's pretty much a non-sequitur. HTML is better in email as well as "reference documents" according to the opinions of many. You don't like thing. Okay.
RFC 822 is plaintext. That's a reference document. Don't see why HTML would be an argument for a reference document. In fact, tex is a good format for reference documents, it diff's well and can produce .ps/.pdf outputs among others.
Before MIME was common, people used to insert uuencoded data within the email message. IIRC, certain email clients would display the decoded content inline with the surrounding text.
Email is supposed to be easy to quote, just like you’ve used a block quote in your comment. I assume it’s obvious that rich text is difficult to quote, but a quick explanation is that the invisible formatting characters used to represent rich text behave inconsistently when re-contextualized for a quote.
Since when? I have never heard anyone say this in my entire life. I want emails to look good. So I guess people are different and we can't draw a simple conclusion about what people want from email?
I’m not sure what you’re saying here. Is it that you’ve never heard of the concept of quoting a passage of an email? Or are you saying “sure people do that, but it doesn’t matter if it’s easy”?
Or perhaps the parent commenter is part of the lost generation of email users that never properly used quoted replies in email conversations. And this is not necessarily an comment on the age of the parent commenter, but rather about what email programs were common at the time. I blame Outlook mainly for this, but Gmail hasn’t done much to help here either.
The use of quotes in replies is also part of the article and is definitely a better way to go with bottom replies than the current default of top replies.
It would be easy if there were a single accepted way to quote in rich text. (Seriously, the block quote tag has been around for eternity!) I don't think it works well in plain text either.
It's far better than trying to keep count of how many ">" are in play, and deal with the vagaries of soft linebreaks and hard linebreaks and wrapping of plaintext.
Some people sending plain text mails also wrap them manually.
If my window is small (maybe because I am using a small screen), the text is painful to read.
And a non manually wrapped plain text is not wrapped at all in some cases.
By all means, send me plain text mails, it will be lighter for my self-hosted inbox, but don't wrap them manually.
If you are going to abuse /this/ kind of `formatting`, however, you are making your mail harder to read for me. These are tags anyway, just not HTML tags. I'd prefer you use the real formatting that is correctly handled in most cases, but I will adapt.
> There are two main types of emails on the internet: plaintext and HTML. The former is strongly preferred
You will need to back this up because this is not what I observe.
My email client takes care of my privacy and my security, and you can use it too if you are concerned, it's a cross platform maintained free software. It's okay.
My problems with HTML emails is colors: if you want to use something like a night mode, you will see emails with hard coded white background and black texts, or worse, only black texts.
You may be able to ignore colors but people will assume you can see them. Maybe an extension like dark background on light texts when using a browser for reading emails who do the trick, but I don't.
It’s an outdated standard and a terrible idea nowadays, since it makes emails unreadable on mobile devices. I’d really love to use plain-text emails — hell, I use plain text for everything — but they’re sadly not a good idea today, unless you want your emails looking like crap on every mobile device.
This is the one blemish (in my view) on fastmail's record. I love them otherwise.
I initially came to the same conclusion as you, but after receiving one too many badly quoted HTML emails (and after some lost hours unsuccessfully trying to understand how fastmail web, gmail, thunderbird and ios mail.app do HTML quoting (hint: they're all subtly different)), I decided to double-down on format=flowed.
The main arguments in the fastmail blog you reference are:
1. Lack of support
2. Lack of people sending/reading plain text email
3. HTML bloat is no longer a real concern
Then they make some implementation difficulty arguments
1. Implement an editor that supports only semantic blockquoting
2. Fix "embarrassing line wrap" due to clients that lack support
For the first 3 arguments, I would say that lack of support from other clients doesn't mean that a client shouldn't support it. I regularly posted to usenet with Thunderbird (which supports format=flowed) and had people respond to my posts with clients that didn't support that feature.
To them (and when viewing the message source), the messages still appeared to be hard-wrapped. When viewing the messages in Thunderbird, the parts I typed were softwrapped. "Embarrassing line wrap" simply did not happen (no matter many times a given piece of text was quoted). "Embarrassing line wrap" was only an issue because certain clients would further re-wrapped quoted text without taking the quote markers into account instead of just leaving it alone or properly re-wrapping it.
Text editors like emacs and vim have features that will easily re-wrap quoted email text. Thunderbird has a feature where you can highlight quoted text and press ctrl-r to rewrap it. So I don't really see how it's difficult to eliminate the "embarrassing line wrap" issue when there are open source programs out there that have the capability (for several decades now) to fix it.
And I think they're missing the point by saying that HTML bloat is no longer an issue. It's not the amount of text that's transferred; it's how readable it is in a client that doesn't support rendering that text. IOW, reading raw HTML is not that easy.
As for implementing an editor that only supports semantic block quoting, I think they're missing the point again. It should be the person who's composing the email who decides whether a particular section of text should be hard-wrapped (meaning no trailing whitespace at the end of each line). You could have a feature where you highlight the text you want hardwrapped and then use a key combination or context menu to apply that change. The rest of the text is assumed to be soft-wrapped and will have trailing whitespace at the end of each line unless that line followed by a blank line.
The RFC you quoted actually refers to line lengths within a MIME message as a whole (headers and body), and only after Content-Transfer-Encoding has been applied, not before.
In other words, your text parts can have lines of arbitrary line length, provided you encode them as QuotedPrintable or Base64 and set the Content-Transfer-Encoding header accordingly, which most email clients do.
> If my window is small (maybe because I am using a small screen), the text is painful to read. And a non manually wrapped wrapped plain text is not wrapped at all in certain cases.
If the MUA (Mail User Agent) does not soft wrap text, then text without hard wraps is painful to read. This also applies to text that's not meant to be soft wrapped (source code, error message output, log messages, etc.).
There is an RFC [1] that addresses this issue by introducing a format= flowed option in the MIME headers.
The reason it's 72 characters is to allow for quoted text, which gets indented relative to the new text. That would allow a line in an email that's 72 characters long to still fit within 80 characters if it's prefixed with 8 quote characters. For example:
>>>>>>>>This line was 72 characters long, but is now 80 characters long instead.
Still looks pretty
bad on anything
less
than 72 characters
because there's
random
newlines in the
middle of
paragraphs.
Content should be
separated from
presentation.
Additionally 72
characters implies
monospace
fonts which have
been shown to be
less
readable.
Not necessarily. There are times where text should not be wrapped (code snippets, error messages, or log output), but if text is softwrapped, then there's no way to prevent that text from getting wrapped unless you use some time of mark up like HTML or markdown. This requires that the client supports that type of markup which isn't always the case.
There is an RFC[1] that describes the format=flowed option in the MIME headers that addresses the wrapping issue (where text that should be soft-wrapped should have trailing whitespace at the end of each line). That would work with email clients that support that feature and will still appear to be hard-wrapped to email clients that do not. So, unlike HTML or markdown, we don't require those who use clients that only support plain text to update their clients to support a new feature. We can use that feature in clients that support it and have a sensible fallback for clients that do not.
> If text is softwrapped, then there's no way to prevent that text from getting wrapped unless you use some time of mark up like HTML or markdown
Precisely. HTML and markdown separate content from presentation, so content that should never be wrapped - like ```code``` or <blockquote>code</blockquote> is handled properly.
>If my window is small (maybe because I am using a small screen), the text is painful to read.
If your screen is so small that it can't display 80 characters across then pretty much anything you look at it with is going to look odd. Any HTML formatting such as tables will also be painful to read.
I like big characters. I can be far from my screen to read, use a low brightness and never have tired eyes.
I just checked on my phone some random opened web page: with my settings (which are far from the default - I raise the DPI setting and the font size so I have small UI elements but big texts), it displays 45 characters per line on portrait mode. Actually the font size is a bit too high, but I don't really care as far as most web pages are readable. I'm fine with scrolling the occasional big HTML table, and will change the settings if this becomes annoying.
So, yes, sometimes, my screen displays less than 80 characters and is perfectly usable. And this fact is not really of my correspondent's business, whether they choose to manually wrap at 80 characters, 72 characters, 42 characters or some other arbitrary number of characters. Actually, nobody knows that apart from people who read this comment. I display text as I see fit (and this is totally an intended pun).
You’re missing the point that anything longer than 80 chars is harder for the human. Ideally it should be 65.
That said, wrapping is better left to the mail client, and let the user adjust their window to suit. My chief gripe at this point is that some email clients (gmail anyway) will get confused by outsized inline images and wrap on them, even if that means letting text drift off the side of the screen!
Plaintext email is really troublesome if one wants to mail in an right-to-left language. There's simply no compatible way to override the direction/embedding without HTML * , so content is often scrambled.
Many mailers won't even align to right automatically if all input is in an right-to-left language. In practice, HTML email is the only compatible way to get a semi-decent experience for these languages.
* To answer the obvious: the unicode bidi override characters are not a solution. They are often stripped out, and editing zero-width characters is a very 'pleasant' experience.
I came here to say exactly this. It's even harder for the real right-to-left use in the ones I speak, where we frequently mix Hebrew/Arabic with English, for using certain words that just don't exist.
Plaintext mailers completely mangle emails like this, making them beyond unreadable. Mutt to its credit does the best job.
Where are these characters stripped out? I can see that these create security issues with urls that get rendered with changed field order to look benign.
I meant stripped from the mail body - though I suspect these programs would also strip them out of the other fields (I haven't checked that). In general, working with zero-width characters is a bad idea from both security and usability POV and is not a practical solution.
The result is that the only reasonable and compatible way to mix LTR (left-to-right, like English) and RTL (right-to-left, as with ME languages) is with HTML email. Note that in most cases rendering is an LTR context, so even sending RTL on its own will fare poorly.
What a load of bollocks. The arguments against come down to, 'you are an idiot who can't figure out phishing links' and, well, that's it. Something about marketing emails. Stupid. Luddite. I'm surprised they don't insist you use a monospace type face in your email reader to give it that late eighties feel.
I have always used HTML email, even when it was new and poorly supported. I want people who read my email to see a nice appearance. I like bold face and sometimes images.
"Strongly preferred". An appeal to the Authority Fallacy is an indication of a weak argument. Or, no argument at all.
I think this opinion is strongly worded and might get some heat, but I think you touch on something important.
Plaintext email often serves as an in group shibboleth to distinguish “us” from “the other lusers”. Does it have merit beyond that, or do these articles just reinforce that?
I think the main issue at play here is quoting. In particular, how bad rich text/html mail programs are at dealing with inline quoting. In my opinion, that’s the main “feature” of email communication that has been lost over the years. On the top replies make it difficult to follow a nested thread of emails.
If html email clients handled this better, I don’t think there would be as much of a problem. I think you’re right though that plain text acts as a bit of a shibboleth to differentiate “advanced” users vs luddites. But the main thing that I’ve heard people complain about with respect to html email is the loss of inline quoting.
Plaintext has its issues too— in particular long line soft wrapping. Which some would argue would be better supported if html email hadn’t become so popular.
I absolutely agree -- the aspect of email I miss from the good ol' days was well-trimmed replies and doing so inline. Threaded inboxes and smart trimming helps, but not completely.
However I think that HTML clients handle this well enough but the etiquette has been completely lost.
Because it messes up the order in which people normally read text.
> Why is top-posting such a bad thing?
>> Top-posting.
>>> What is the most annoying thing in e-mail?
The cultural aspect of this web page is pretty clear in that the author even formats his HTML to look like plaintext, which is completely unnecessary from a technical perspective. In fact it took extra effort to do that, as opposed to just allowing each browser to supply its default font.
If an HTML phishing email is hiding an obviously malicious URL behind an image or button, then yeah, that URL would be more visible in a plain text email.
But it's also visible in the address bar of the browser after you click it... and people will fill in the form anyway.
Plain text doesn't solve complacency and distraction, it doesn't solve URL composition tricks and redirect wrappers, it doesn't solve spoofing, and it doesn't solve malicious attachments.
If Google's account emails were all plain text, I'm sure phishers would figure out how to make them look as identical to Google's emails as possible, and still get some people.
IMO we already know some good ways to mitigate phishing, but their implementation is spotty: DMARC, hardware token 2FA, and good IT practices in terms of patching, privilege, and backups.
Ideally, it would be nice to enable phishing links to be identified before they are clicked. This could prevent the remote server from logging any metadata about the browser accessing the link (date/time, browser type, ip address, etc). It also prevents any possibility of browser vulnerabilities being taken advantage of.
What might be an interesting solution is to standardize an addition in the SMTP standard to require the ability to verify message ID's and also return some kind of Content Security Policy equivilent.
Every mail message gets assigned an ID. When you receive a message from support@paypal.com, it would be nice if your mail client could connect to paypal.com and ask if the message ID was legitimate and it would reply that it was, and that the only URL's whitelisted in the email would be example.com, anotherexample.com, etc.
Some downsides that would need to be addressed is that this would mean email clients would inadvertently expose their IP address to the sending server, and some thought would have to be used to prevent fraudulent emails from just replaying existing message ID's.
I just feel like there is a possible solution that the industry isn't seeing or implementing.
This is basically what DMARC is intended to do. The receiving email server checks SPF to see if the sending IP is authorized to send on behalf of the "from" domain. If SPF fails, it checks the DMARC policy to see what to do. If the DMARC policy on that domain is set to "reject," the email is discarded and the user never sees it.
The risk with this system is that, if it is misconfigured at all, some of your legitimate email will get discarded too. Seems like this would also be a risk of your proposed system.
So, for now most folks are either not using DMARC or have their policy set to "none", which generates reports on spoofing but doesn't discard any emails.
And I should be clear here that this only stops domain-based spoofing. Phishing emails can still succeed without that. I could send you an email with the visible "from" address "Paul Graham, YCombinator" or "Paypal Support" and the from email address of dklj09qw43jadj0u9qoi4jjdoi089ue@example.com. If you don't bother to check the email address, you could still get fooled.
You're right. That was too strongly said. Some people are naive or make a mistake. However, nobody I know lacks for emphatic instruction to never, ever click a link on an email. If your bank wants you to login, use your own bookmark.
I’d love someone to convince me I’m wrong - but I think we’ve lost this fight.
Years of use of plaintext hostile clients by people who read our emails means bottom posting or inline replies are seen as extremely strange, and impossible when you have one of those “seven email deep” threads forwarded to you. (I know, I know, “snip it down”, but sometimes I just don’t have those minutes in my day ;))
Wrapping as well has given me trouble - I'm not sure what I settled on but I went through a period of having some users see my emails come across poorly formatted. And to that note, IIRC Outlook doesn’t do a passable job with plaintext mail, instead shoving monotype text in an ugly system font. The last time I checked I don’t think it converted > into quoting and just vomited them up.
I don’t know what the solution is beyond reluctantly accepting that we have to both consume AND produce HTML email now, and make tools that do it gracefully.
I would agree I gave this fight up sometime in early 2000s.
Since email is only valuable as a network, it didn’t make a lot of sense to me to constantly argue with colleagues to send plain text + html, let alone to only send plain text. Ultimately, I decided using elm was my issue, and they were doing the natural thing.
There's no losing as long as you're being the change you want to see. I will always send plaintext emails and I have the technical skill to dig into the raw email and decode the encoded HTML data manually or rip out the relevant authorization URL/strings.
You’ve just made the problem an externality. While you have the skill and desire to do that - and to be clear, as a mu user I do the same dance when I need - inbound messages are rarely the problem for me.
What is a problem is outbound messages. When I try to do (what I think is) the right thing and trim the message and reply inline or bottom post, confusion abounds. I’ve had messages missed because the recipients told me they thought I accidentally sent an empty reply and didn’t scroll past the “on July 24th, superkuh wrote:”
Whose fault is that? Is it the 20 people on the distribution list who learned email protocol from years of Outlook and not “the right places?” I don’t feel comfortable pushing that blame onto them.
> I’ve had messages missed because the recipients told me they thought I accidentally sent an empty reply and didn’t scroll past the "on July 24th, superkuh wrote:"
A common way to handle this when writing to people who aren't likely to expect an inline response is to put "Responses inline below:" at the very beginning, and then respond inline as usual.
I'll admit that, in the past, I passively-agressively did things like respond to emails inline and then use my editor to remove all quoted text before sending my reply.
I mean, I get it. There are some things about plaintext that are nice, or that really appeal to the kind of people who read HN. I used to have arguments about this, too -- but it was 20 years ago. Today, the ship has fucking SAILED.
And you know what? It's GREAT. I send formatted email constantly -- and they're better for it. Being able to embed screenshots is awesome. Being able to use color, or bold, or italics, makes a difference in communication.
It's done. I'm not going back to plaintext, and I can't imagine most people will, either. There's no good reason to (in particular, the downfalls of HTML the author lists are all either easily solved or are issues orthogonal to the format of the email.)
> Being able to embed screenshots is awesome. Being able to use color, or bold, or italics, makes a difference in communication.
Yet, you cannot do any of that on HN (other than a limited case like italic). But, we can communicate just fine without those features.
I suppose it's really a difference of a read once message versus having a discussion. In a read once message, you can format it like you describe. That's how most blogs and web pages work. But if you want to have a discussion, then plain text with very limited markup works best since it minimizes the required vertical scrolling and it allows you to see the overall discussion since you can view more messages in the given screen space.
Communicating just fine is not the same as communicating at optimum.
In the analog world, you could just hand over a white, plaintext birthday card. Or you could give one with a motive, color, some doodles and maybe a memorable photograph attached.
Which one is more memorable?
"It's used by marketing." is not an arguments against it. We have sophisticated spam filters. Update your rules then.
I would say that the birthday card example is a read once message example, and not something that's going to be discussed at length like a patch on a development mailing list.
Some forums actually work a lot better WITH embedded images.
To pick just one example[1]: a lawn forum where people will try to ask a question, or share an experience, and go back and forth trying to describe the details. A photo cuts that pain out and enriches the conversation.
An internet forum (presumably we're referring to a public forum here) is a very different communication medium than email (especially when used in a professional context)
I've seen professionally-oriented PHP forums and they are no better than any casual-interest oriented PHP forum.
Tons of visual clutter with all kinds of rectangles nested inside each other all over the screen with little apparent purpose for any of them. Join dates of users are given higher visual precedence to the date a comment was made (why is the join date of a user even visible on a discussion page at all?? That's pointless clutter!) 90% of users attaching signatures to every comment they leave with the signature body being longer than whatever remark they left, and often being filled with shitty animated gifs that look like they were stolen from somebody's geocities page.
It's a trash medium. Fundamentally flawed. Trying to fix typical PHP forums is like trying to polish a turd.
> In the end what happens is people use text overlays in the IMAGES in order to reply to each other.
Oh my god. At my work, HR likes their email super-formatted to a degree that's not portably achievable with even hand-written HTML. The solution someone once came up with? Their email consists of a single embedded image the size of a typical monitor. All text, all information is in that image. They also have a requirement for everyone to use their standard format for "professional" signatures in their own mail. Of course, those are also embedded images. In a discussion, with each reply of each person, the corresponding signature image is included.
I wish I could tell them that email only allows for plain text, but of course that's not the case.
Given it's HR, could a case not be made for accessibility which an embedded image doesn't allow.. they might be responsive if talking in HR terms and priorities.
> In the end what happens is people use text overlays in the IMAGES in order to reply to each other.
That doesn't sound optimum use of image at all.
> Or you can make the message memorable.
And use image that make it even more memorable at the same time.
Text and images are tools, both can be misused, but that doesn't means that they are bad. Remember SMS text? Works for sure, clearly not optimal, yet text is pretty good to make message memorable.
I can explain in a thousand word an issue on a page, but you can also just share a screenshot. That's an optimum use of images. Sure you could just write "see screenshot #1", "see screenshot #2", etc.. but I'm pretty sure you'll agree that it's not optimum.
Optimum for me would be links along with client integration to open said links inline. Links for example in a plaintext email are clickable - not because of HTML, but client integration. The same can be done on image links.
That way the big screenshots don't destroy the flow of text like in http://example.jpg [+] (open inline) and instead information is condensed and digested in the most optimum way possible.
It's not text or images that make forum content good or bad or memorable. It's good people doing good work. And different people work well in different media. Saying that text is the only legitimate form of media is both ignorant and disrespectful.
I'd argue that that's a shortcoming of the platform and not the medium in that context. Having the ability and abusing it are two completely different things.
And we got along 'just fine' before computers were invented. Should we stop all progress because we don't really 'need' any new stuff we are inventing?
My experience has been that some professionals are not actually very good at communicating in the first place. They won't read a detailed email, and instead prefer body language and rapport to substance. Perhaps the need for pictures and fonts in an email is related to this problem.
>Yet, you cannot do any of that on HN (other than a limited case like italic). But, we can communicate just fine without those features.
Can we?
Comments can't have tables, so you almost never see any actually tabular data like statistics. I frequently see people misstating copied across data, or getting confused by things that would be simple in a table.
Quoting from the article is very difficult, as laws and guidance often use formatting despite being very simple documents. I've run into this a few times when trying to quote GDPR guidance, and people very often misunderstand quotes.
People frequently struggle making lists, or having problems with ambiguity about which point a comment is replying to.
Code snippets just don't work on mobile.
> then plain text with very limited markup works best since it minimizes the required vertical scrolling and it allows you to see the overall discussion
Sure, if your discussion is short and shallow point-scoring! For in-depth discussion headings or any structure at all is really important.
> Comments can't have tables, so you almost never see any actually tabular data like statistics. I frequently see people misstating copied across data, or getting confused by things that would be simple in a table.
It can be done in plain text, but I don't commonly see it. For example:
Column 1 Column 2
first second
third fourth
> Quoting from the article is very difficult, as laws and guidance often use formatting despite being very simple documents. I've run into this a few times when trying to quote GDPR guidance, and people very often misunderstand quotes.
I have quoted statutes from federal and state laws numerous times as part of a discussions where copying and pasting the text into a plain text format works. For example, a bullet point becomes an asterisk.
> People frequently struggle making lists, or having problems with ambiguity about which point a comment is replying to.
I think it's a lack of convention. I spent a lot of time on email lists, forums and newsgroups and have seen various conventions, but most people didn't struggle to make lists. The most common convention was just to use numbering or asterisks to indicate items in a list:
* item 1
* item 2
3. item 3
4. item 4
> Code snippets just don't work on mobile.
Code is one type of text that shouldn't be soft-wrapped, but the lines are frequently too long to render without wrapping on a mobile.
> Sure, if your discussion is short and shallow point-scoring
Not all online discussions are like that. For example, look at the mailing lists for the Linux kernel and git. I've also seen many substantial discussions on sites like this and reddit. In the past, I've learned a lot from newsgroups (usenet).
The OP's point is that it might be better if HN allowed slightly more formatting than it does. Personally, while I wouldn't want full-bore HTML, I'd like to see a more substantial subset of Markdown[1] supported. Your own examples of tables, lists, and block quotes would look a lot better if they were, you know, actual tables, lists, and block quotes.
[1]: Markdown isn't perfect, but it's pretty well-known, and by design mimics a lot of conventions that came from plain text email to start with.
> Your own examples of tables, lists, and block quotes would look a lot better if they were, you know, actual tables, lists, and block quotes.
I would agree with what you said about tables (which, in my experience, is an uncommon use case), but the rest can easily be rendered in plain text. Block quotes, in particular, could be done by indenting the text by several spaces (or a tab), just like it's done on HN.
FWIW, your plain-text table is not as accessible with a screen reader as an HTML one. For the past two decades or so, screen readers have had commands for navigating tables, reading the row and column headers, etc. But those only work with something like HTML or a Word document, where the structure is well-defined.
Format is a kind of moderation and guidance. With email, anything goes, but it's usually direct communication, where the rules are organically decided between the participants. With a zillion participants, that can't happen, so limiting the options is useful.
>This is a reference document, not an email, you twit.
Abot 25% of the emails I write, and 90% of the important ones, are reference material for the people that get them. Screenshots, hghlights, and links to external documentation all make my email communication better, faster, and more useful to the recipients.
I suspect you are being downvoted because people don't realize you are quoting the document. It's a shame that HN features articles that are written in a style that doesn't follow the basic standards of civility and quality that is expected of comments.
Unless the recepient is color blind or has another impairment. Also instead of highlighting important parts, one might focus on important parts in the first place.
That said there are valid uses for formatting. But unfortunately most of the formatted mails are harder to digest than needed. Especially if it becomes a longer exchange and people start highlighting in quoted mails.
No, this is not true at all. People will _only_ read the color part and skip anything else, which is equally bad to not finding it immediately, if not worse.
And there are also color blind people for whom the color might be even worse than the lack of it.
Yes. The argument almost defeats itself: why do you waste my time with irrelevant stuff? Why did you make read a whole page of details before coming to the critical point?
That has been my experience: make your messages as short and straight to the point as possible. Put the most important stuff first and the gory details only the curious will read, last. That goes for documentation too.
HTML mail gives the illusion that fancy formatting can make up for mediocre writing skills. That's sad, because no amount of bold face, color or indentation can fix an inconsistently structured piece.
You learn that stuff at school, make your tuition fees (and/or the time you have been forced to invested in it instead of being young and having fun) worth it.
What I hate about HTML email is that it tends to set its own font size, sometimes even font face. Like... Keep your dirty hands away from my config of how I like my mails to be displayed when I read them. But no, every mail is now a snowflake and has to have its own styling, even though it doesn't provide any value.
It won't die, because the argument has the same merit today that it always has. That being said, I think it's useful to attach images to an email (not necessarily embed them in the content of the email, but attach them for sure).
IMO HTML email is worse today than it's ever been. Often when I get an HTML email it takes me longer to parse it. On the bright side, the presence of HTML is a decent indicator of a marketing email that can safely be ignored.
> I find that a very large percentage of the html email I receive is actually hurting readability by way of formatting.
This is exactly right. In principle, html is just as convenient, but in practice it regularly fails. Something I really hate is a message with big images that add nothing. If I have to scan a message to figure out what's being said, there's a high probability I will leave it for later, which means it never gets read at all.
I would say that the real performance drain is top posting, which seems to go hand in hand with HTML emails.
With top posting, in order to read a mail - especially one that is a few levels deep in a thread - becomes an exercise in jumping back and forth, trying to find context and make sense of who replies to what, finding relevant sentences (often hidden in a mess of signatures).
With bottom posting and proper curated quoting, context is a glance away, and it's easy to see who said what in reply to what.
I'm sure this would be possible with HTML mails as well, but I've never seen it happen. It's all just a mess of hard to find information in the least sensible order imaginable.
It is not, so long as you first quote the relevant part you are replying to.
At some point you can also trim the tail as you see fit (I don't find it necessary because my mail client does a good enogh job at hiding that part unless I click on a "show wverything" button.
Technically it appears that I'm advocating for a combination of inline and top posting. Quoting the relevant wikipedia part:
> The interleaved reply style can also be combined with top-posting: selected points are quoted and replied to, as above, and then a full copy of the original message is appended.
Indeed, it would be nice if the netizens of the world would wake up to this. Sadly, I think it's unlikely to improve any time soon and so I'll stick to top posting and threading in the email client.
it's 99% psychological but I also 100% agree. Just posted a top level comment about how it has absolutely changed my life with regards to email. If you're having trouble keeping up with email and aren't afraid of the command line i _highly_ recommend using a cli client. Neomutt is a bitch to set up because there aren't any good action oriented docs, but it's been worth every bit of effort. There are other clients that are much easier to set up (like alpine) but neomutt has so much power and for me being able to write in markdown and convert to HTML for normal folks was a requirement.
the 1% that isn't psychological is how much faster _everything_ is when dealing with a plaintext client (neomutt in my case). "Power Users" use the keyboard to navigate gmail. Normal (neo)mutt users use those _all_ the time and they're faster because there's so much less for the computer to do with each keystroke.
This isn't a thing, which makes me think you're arguing in bad faith.
Clients load images asynchronously, and no personal email is sent with a logo and catchphrase header. I've never seen that in my entire life and I've been using email with a lot of people, for a long time.
Formatting is an issue however, and the addition of formatting to email can be useful and add to the conversation.
To take the hn example again, the text portion of your comment is broken on mobile because hn doesn't support proper formatting. This has made your comment harder to read.
Asking for permission before rendering external images != not loading at all, even though we could live without external images and just include everything inline.
That may be the reason for some people. I disallow loading images until I click, for security and privacy reasons. But I want to see pictures of my aunt's dog if she sends it.
I consider this to be more like a polemic to shift the overton window of acceptable email restrictions.
Probably much of what we enable in email could be restricted without loss of actual useful features. Each feature adds attack surface, complexity, and compatibility concerns that can be avoided by using the simplest possible subset of features.
Our offices don't use any of that chatroom crud and I'm extremely thankful for the lack of extra imposed distractions, not to mention the horror stories of being reachable 24/7 because of Slack/Riot/etc.
Why require another medium for communication when email works just fine? What is the point in joining a chatroom to talk to one person only to be spammed by everyone else in the room? For those cases where email is insufficient, walking over and talking or making a phone/video call are IMHO better.
> Why require another medium for communication when email works just fine?
I’m guessing you’ve never actually worked with these chat clients yet?
The difference is light and day. Of course there is annoying parts, but like plaintext email I guess, just having everyone write in the same format soothes the brain.
And no awkward quotes or history in every damn email (because your client is going to mess up that thread!).
Having slack doesn't necessarily mean having to be reachable 24/7. Chatrooms fill the use case of day-to-day chat and other more short-lived information.
As for distractions, that comes down to bad work culture. Hacker News & Lobste.rs are far more distracting for me. I simply get around to slack/email when I get around to it, with the exception of my boss pinging me. Thankfully he only messages me for important things.
If you email me I'm going to assume it's something actually important / something that will have some longevity vs some question on slack. Since people wear headphones due to idiotic open workspace culture, messaging someone on slack is far easier than walking up to them (unless your question is actually important/urgent, of which most are not).
Your phone or video call better be very important. Those are blockers, especially video calls. I prefer to call the latter time-wasters since, well, they're almost always a complete waste of my time. The only useful video calls I've done are with syncing up with another developer, which I cannot do locally now that I work remotely. Aside from this I prefer leaving the luxury of video calls for my parents.
I would disagree, You can make Text-only links look fairly harmless too. The issue is more often that people do not look at all, even in text-mail, what the link points to, not that they can't see it (plus you can hover and the browser still shows the URL once you open it)
>Privacy invasion and tracking
Only if you use an ancient and outdated client that doesn't block external resources by default or proxies them over another server.
>Mail client vulnerabilities
Only an issue if the client rolls their own HTML renderer. Outlook uses the IE Trident Engine, Thunderbird uses Firefox' engine, Gmail transforms using the Chromium engine internally. That means the email client is usually as secure as the respective browser, unless you use a mail client that rolls their own engine.
>HTML emails are less accessible
Possibly, depends on the sender. You can make them more accessible than Text though because you can prevent the screenreader from trying to read out the link or irrelevant information.
>Some clients can't display HTML emails at all
Most mail clients will usually bundle a text-version of the mail, some MTAs also do this on their own. Doesn't really matter in practise since 99.99% of people use a mail client that can display HTML.
It feels a bit like complaining that people on the highway drive so fast that you can't properly merge into the rightmost lane with your oldtimer car.
>Rich text isn't that great, anyway
And tbh, this last one basically seals it; this is a website made to rant from the personal perspective of someone who blocks mails containing any HTML from their services and has quite the history of throwing people using their lib under the bus over personal preferences.
I don't see how any of this is relevant when even the site itself admits that using a multipart mail with both text and HTML is sufficient, why should I even begin to send plaintext instead of doing that?
Unless your mailclient is garbage, it handles multipart and will understand the mail.
I'll address more of your comment later, but for now let's start here:
>Only an issue if the client rolls their own HTML renderer. Outlook uses the IE Trident Engine, Thunderbird uses Firefox' engine, Gmail transforms using the Chromium engine internally. That means the email client is usually as secure as the respective browser, unless you use a mail client that rolls their own engine.
This is not true. You can't just drop a modern web browser into an email client and have it magically be secure - if you do, your client will be broken and insecure. A huge number of browser features have to be removed - loading external images, stylesheets. scripts, images in stylesheets (except datas URLs, so add a special codepath for that). Things like animations aren't desirable, nor forms, etc. The list of things you have to turn off is huge and getting longer with each browser release. And you had better keep up with those releases, as each one fixes a half dozen security bugs which are inevitable in a technology whose specification alone is a million lines.
That stuff is actually not that hard, mozilla's engine has compile flags for that stuff and the patches you have to make are minimal. There are a few methods for runtime restrictions too, they're quite extensive in their capabilities and sufficient for sandboxing a mail.
Mozilla's engine is a giant multi-million lines-of-code ball of C++ and Rust and JavaScript weighing in at nearly 200 MiB - not including dependencies. And what if I don't want to support the browser monoculture? Implementing a new one is a daunting task (nigh impossible), but rendering plaintext is easy peasy.
HTML email in practice doesn't need much more than what w3m supports, in some places less - no need for w3m's frame, cookie, or FTP support. w3m is smaller than mutt.
Limiting HTML mail to an agreed subset could actually be a winnable fight compared to more impractical suggestions.
Let's say 50% (or even 30%). How much more code would have been needed to correctly render most of the rest? I strongly doubt it's 200 MiB, probably much closer to w3m's size. HTML email is in practice a large subst of HTML4+a tiny bit of CSS.
Sorry, I realised that's what you were talking about after the edit window closed. Though, a lot of mail is sent by mailing services not individual clients (and all the awful ones really don't like sending useful plaintext mail).
Hahaha, that's rich. Those laws are not enforced. I actually consulted with a blind friend when writing that up and he agrees that every HTML email is a nightmare for him. Top posting too.
However, a significant portion of HTML mail I receive happily violates "accessibility laws" and omit to provide a text-only part. I know that, since I actually rely on accessibility to do my daily work.
To clarify, is your problem with HTML emails that omit a text/plain part, or only HTML emails that have images with no alt text? If the latter, I think the solution is to advocate for accessibility in HTML emails, not plain-text emails. After all, well-structured hypertext has its own accessibility benefits, since most current screen readers have lots of commands for navigating that structure. This is why I disagree with advocating for plain-text email in the name of accessibility, as this campaign does.
Screen readers should be able to deal with HTML-only mails for the most part, otherwise you should send the sender of that mail a reminder about those laws.
Are you actually a user of accessibility? To me, it doesn't feel like you are. If I am right, please refrain from patronizing people who actually do. In my book, you have no idea how horrible the situation has become over the last 5 to 10 years. Accessibility used to be a thing, yes. These days, it is mostly a happy accident.
I've never talked to anyone who actually used accessibility tools. I'm aware of the W3C standards. Are there any other resources that developers can use to produce stuff that works well with real-world accessibility software?
This, to the untrained eye, might at first glance look like a paypal.com link. In fact, it belongs to verified-account.com and it abuses the capability of URLs to contain a username and password to make it look legit.
Wow, I knew Firefox warns for these by default so I thought nobody would ever use this for a phishing attack anymore but it looks like Chrome just meekly follows the standard. That's too bad, really, this is a very easy way to create very realistic phishing mails.
You are about to log in to the site “google.com” with the username “www%2Epaypal%2Ecom”, but the website does not require authentication. This may be an attempt to trick you.
Is “google.com” the site you want to visit?
From the error message it sounds like if this was an attacker controlled site configured to require authentication it wouldn't trigger? If so it's not that useful a defense since whether to require auth is entirely under the attacker's control.
Finally back at a computer, can reply to this in full now:
>I would disagree, You can make Text-only links look fairly harmless too. The issue is more often that people do not look at all, even in text-mail, what the link points to, not that they can't see it (plus you can hover and the browser still shows the URL once you open it)
It would be difficult to argue that it's not at least more difficult to phish people with plain text.
>Only if you use an ancient and outdated client that doesn't block external resources by default or proxies them over another server.
This works until you click any link in the typical marketing email, or click "show images" to make the email readable. Remember that you have to train these careful behaviors into non-technical end-users.
>You can make them more accessible than Text though because you can prevent the screenreader from trying to read out the link or irrelevant information
This only sounds useful for spam or marketing emails (which are the same thing 99 times out of 100).
>It feels a bit like complaining that people on the highway drive so fast that you can't properly merge into the rightmost lane with your oldtimer car.
This is an uncharitable interpretation. We don't use these email clients because we're old fogeys, but because they're better and more efficient for our workflow and needs.
For the vast majority of people html formatting is better and more efficient for their communication needs. Bold and highlighted text, section headers, tables and inline images are all very very standard and useful things to have in emails. These are not niche use cases.
I have never seen an email with a table in it, HTML or not.
Inline images are not useful, just attach them. Leave your giant signature with your company logo at the door.
What's left is section headers and bold text. Use asterisks for emphasis and # for section headers and you can communicate quite effectively. We seem to manage pretty well here on Hacker News without most of these features, wouldn't you say?
I often use inline images in emails, for the same reason I put images inline in other writing. I recently wrote an email summarizing some debugging I had done so someone else could pick it up. It looked like:
text describing steps
image of graph
link to graph source
more text
another graph
link to graph source
etc
We're all using email clients that display messages like this well, and it makes communicating complex ideas much faster.
I'd give up HTML email if I could still have format=flowed and inline images, but that's not what's on offer.
I routinely insert org-mode tables into emails I send at work (now that I think about it, that's a little funny, given that I'm consistently pro-HTML-email in these threads).
It was not. The HN page contains html. Notice how the comments are in a different font and color from the metadata above each comment? Notice how that improves readability?
Downvoted comments are less readable due to decreased contrast (though I assume that's intentional so people well skip over them instead of responding).
One reason I would add is archiving. Having managed some large, archived mailing lists, one of the headaches is dealing with formatted text. Even plaintext can be a pain in this regard (differences between email chain formatting, fixed-width lengths, etc.). HTML is even more troublesome...
I just want to put it out there, that regardless of if this is a "fight worth fighting" or not. Email was a nightmare for me. I could not keep up. Coworkers would catch themselves and laugh when they asked if I'd gotten an email.
Switching to neomutt has changed everything for me. I now mmaintain Inbox Zero.
I write in markdown. I convert it into a multipart email with HTML in one keystroke for everyone else.
Other benefits:
I don't know this for a fact, but i suspect that HTML email has got to _suck_ for visually impaired people using screen readers.
plaintext email means no tracking by marketers, or facebook, or anyone else.
plaintext emails are also _way_ shorter. There is so much less crap to mentally deal with when all the marketing BS has been stripped away.
plaintext emails give you a glimpse into just how much you're tracked too. Nevermind the privacy aspects of seeing the real url, you see that the "real" url is multiple lines long because of all the tracking they've embedded in it. It makes you think twice before clicking it.
For the convenience of anyone that may consider licensing and language it's written in a relevant part of their choice of software, here's the list of recommended e-mail clients in the submission with licensing and programming language info:
- aerc: MIT, Go
- alpine: Apache 2.0 (parts 4-clause BSD), C
- claws mail: GPLv3, C
- Gnus: LGPLv2+, elisp
- KMail: GPLv2 (parts GFDLv1.2, parts LGPLv2.1), C++
- mutt: GPLv2, C
- SquirrelMail: GPLv2, PHP
Side note:
> (context: ProtonMail) It's also recommended that you visit Settings → Account → Identity and remove the default email signature.
It bears noting that free accounts on ProtonMail cannot remove the ProtonMail advertisement in the signature, cf. [1].
It would be great if you inserted a screenshot of your client in action in the README.md. In my experience screenshots have excellent information density when it comes to evaluating software :)
2. Can you give me plain english instructions for composing plaintext emails by default?
Lumail is a console-based client, much like mutt. To compose an email your editor is launched. If no editor is configured vim will be used.
Plaintext composition is the only thing that is supported.
3. Does it hard-wrap your plaintext emails at 72 columns?
The mail client doesn't, since it opens a temporary file with your configured editor. You could configure your editor to enable/disable wrapping ..
4. Does it support format=flowed?
As above.
5. When replying to a message, does it put your reply above or below the quoted message you're repying to by default? Can you change this setting? How?
The editor opens a temporary file into which the quoted body of the mail you're replying to has been placed.
I configure my editor to be `vim +/^$ ++1` which puts the cursor above the mail, but below the headers.
You could do something similar to place the cursor at the bottom, but that would require a suitable editor-specific command to be set.
I greatly prefer top posting because it emphasizes what I'm looking for in a email reply which is new information. Moreover, modern email clients automatically hide the quoted text so only the reply, with the new information, is visible but context is available if necessary.
For example:
---
Let's meet at 8 pm.
(Show more from person A).
---
Typically, the context will be clear from reading the reply and the sender. If not, I can establish context by clicking on the link:
---
Let's meet at 8 pm.
> Agreed, when should we meet?
>> I think we should meet face-to-face to discuss this.
>>> This is a super-important discussion.
>>>> I propose to implement HTML mails.
>>>>> Plaintext mails suck. I missed important information because the mail used asterisks instead of bold text.
---
With top posting, I can stop reading the previous mails as soon as I understand what's going on. Consider the opposite with bottom posting: Here I would have to read the entire context from the beginning or am at the mercy of how other people edited the context.
EDIT: Put --- on individual lines. Fixed asterisks formatting.
That's only relevant because you're including your whole thread (or part of it, if there's forks) in your email. As far as I know, there's no real reason for people to do this anymore. Email clients should be able to handle email threads themselves, and then the recipient can decide how they want to sort it.
If you're only replying to things that are specifically relevant to the section (what quoting was traditionally used for), then bottom-posting doesn't make sense.
I had the same reaction and at the bottom it goes more into details of the reasoning why plaintext is better. I, however disagree on pretty much all the points.
Yes, but some of the rationale is up to dispute, or simply out dated. For example, there is not an email client these days that do not render rich text/HTML. Those who do not, will convert it to plain text. Nothing to lose.
Besides making phishing easier (by disguising links, unless you hover over them), what exactly does HTML add?
Most people simply bang out a bunch of text without any formatting: what does wrapping HTML around that add? I have yet to see a layman someone add useful typographic flourishes to any business communications. Any "advanced" formatting has always come from marketers.
People use bold and italics, section headers, inline images, tables, text highlighting. The list goes on. Is it really that hard to wrap your head around the fact that formatting is useful for communication?
Not in my experience. They hit reply, type something at the top with whatever the defaults are, and hit send.
> Is it really that hard to wrap your head around the fact that formatting is useful for communication?
I have all of Edward Tufte's books, as well Bringhurst's Typographic Style, and Chicago: I am aware of the usefulness of typography. I simply have not seen it in my day-to-day e-mails at work or in personal life (except for marketing spams).
I see useful text formatting every day in the emails I send and receive. A reasonable person would accept that other people’s use cases and preferences are valid instead of writing haughty diatribes about what the platonic ideal of email should look like.
I accept that other people's use cases and preferences differ.
But given the carnage that HTML e-mail being the normal has caused in phishing and other privacy invading manners, I question whether the benefits of those use cases and preferences out-weight the detriments of the practice. Just ask John Podesta:
> SecureWorks concluded Fancy Bear had sent Podesta an email on March 19, 2016, that had the appearance of a Google security alert, but actually contained a misleading link—a strategy known as spear-phishing. (This tactic has also been used by hackers to break into the accounts of other notable persons, such as Colin Powell). The link[10]—which used the URL shortening service Bitly—brought Podesta to a fake log-in page where he entered his Gmail credentials.[1][9][11][12] The email was initially sent to the IT department as it was suspected of being a fake but was described as "legitimate" in an e-mail sent by a department employee, who later said he meant to write "illegitimate".[13][14][15]
HTML emails are mainly used for marketing - that is, emails you probably don't want to see in the first place. The few advantages they offer for end-users, such as links, inline images, and bold or italic text, aren't worth the trade-off.
The idea that marketing emails = "you don't want them" is fairly popular in some crowds, but it's contradicted by the tremendous business success of using marketing emails. The reality is that most people want and use marketing emails.
For example, I'm signed up for marketing emails from several airlines and these routinely save me money when booking vacations. Cheap airline tickets are a limited resource, so real-time notification of new availability has financial value to me.
Same with end-of-season sales for clothing I like. One company gives email recipients 1-2 days to shop before the sale is posted publicly on the website and social media.
It also ignores the tremendous popularity of email newsletters, which employ HTML formatting to improve the user experience, exactly the same way content websites do. In fact HTML email newsletters are often better than websites, because email clients don't execute javascript. The advertising is far less intrusive.
but it's contradicted by the tremendous business success of using marketing emails
I know advertising is effective, it IS manipulating me. That's WHY I don't want it. "I don't want them" is not contradicted by the success of marketing, it's reinforced by the success of marketing.
Does it matter? The default is HTML, the majority of mail is HTML (or atleast multipart). So why does it matter if GMail defaults to what the majority is doing? Everyone (99.9999% of people) can receive and send HTML, so just do that, it's the informal standard for mail now.
It's great that you think that it matters but I don't think that what you think that it matters matters in practise, really, the world is HTML email now.
The people you are interacting are not sending HTML email on purpose, but simply by accident because of details. I would hazard to guess that if the default was changed that they would not noticed.
Given all the communications that you receive, how often have typographic 'flourishes' been added in a useful way that would need mark up more advanced that ASCII/Unicode?
Given the following (from the article):
* HTML as a vector for phishing
* Privacy invasion and tracking
* Mail client vulnerabilities
* HTML emails are less accessible
What exactly does adding mark up give you on a day-to-day basis over a text/plain Content-Type?
This ship has long ago sailed. People are using email less and less these days as it is, anyway. I get personal emails less than once a week now.
You'd be better off pushing people to using email for communication in place of walled-garden IM or social platform du jour (which I also think will be a losing battle in general, but perhaps more worthwhile), in which case being able to make your email look nicer might even be a draw.
The part about ProtonMail and Tutanota seems pretty biased. I would like to hear how the author suggests that they should implement IMAP and SMTP without compromising the encryption.
It sounds like the author prefers dubious advantages to real improved security.
That's quite ridiculous considering that according to him HTML emails are:
>"... a security nightmare, are mostly used for advertising to you and tracking you, are less accessible for many users, and don't offer anything especially great for it."
The data in a protonmail account is encrypted with your own key. How is protonmail supposed to encrypt an email if they receive it unencrypted over SMTP?
There are various ways. One would be to use standard imap and decrypt the message on the client. Their bridge sort of does that but with proprietary protocol.
Either way, that has absolutely nothing to do with the security issues of html email. Eg phishing and tracking still works when you decrypt the message and open it.
I'm on mobile so I can't give you an adequte response, but I can link you to a previous commment I wrote on the subject...
Or I would, but pasting seems to be broken on my phone as well. If anyone can search HN for "Sir_Cmpwn Protonmail" and link the relevant comment I'd appreciate it very much.
The page is about setting up email clients to send plain text emails, but most of the reasons given why plaintext is preferable are about receiving email. The remaining reasons are either "rich text isn't that great" or are trivially solved by the client (extracting plain text from a rich text email isn't hard on non-marketing emails).
Yeah, this is the part that is eventually going to bite us ... hard. It is just straight up insane to allow random entities access to the vast attack surface of a web browser. Unfortunately no one seems to even care about present day ongoing attacks. We will have to wait until someone comes up with a worm that takes down email and possibly the whole net.
The attitude of high-skilled tech people to think that their stripped down, interface-less, and brutalist version of something has to be simply better than anything else needs its own German term, something like Schadenfreude or Treppenwitz. I'm sure some of the German readers here can work out something.
Other than that "Hackerwahn" ("hacker mania") sounds like a nice term for this as mostly low-level hackers seem to show this kind of behavior. (Note: This is not meant as an insult or a generalization.)
Not having inline images is an issue though. It helps immensely with readability and usability. Especially with people that aren't as computer-savvy.
Partly because many email-clients will list attachments below the mail content. And since it is standard practice to include the previous mail when responding you have to scroll a kilometer to get to the bottom with the attached images.
That is just unusable. Yes, it is an issue with bad clients and not plaintext. But nonetheless it is a big issue.
I think 95% of the email formatting complaints regarding images are related not to this, but to highly-formatted signatures (usually with a variety of social media links)
I don't know if I've ever seen bottom-posting in my life. They have particular weak arguments against that as well. It is very useful when forwarding a message or including someone else as cc.
It is very useful for you, the sender. It is a nightmare for the receiver. Whenever I receive one of those forwarded top posted thirty mail long horrors I just ignore everything and hope I can guess context from whatever you wrote in the last email. The alternative is to spend an hour deciphering the blob of goo that is actual mail messages mixed with signatures, attachments, all being meaningless replies to questions I haven't yet read - because top posting.
Sending me such a thing is equivalent to telling me "Fuck you, your time is worth nothing to me."
>The alternative is to spend an hour deciphering the blob of goo that is actual mail messages mixed with signatures, attachments
You mention attachments, which implies you've been included in all the previous emails. In which case, your email client should be splitting them (often referred to as "conversation" view).
Otherwise, how does it make any difference if the infinite nesting is at the top or the bottom? Or by "top posting" do you just mean replies without trimming?
I would say that top posting does mean replies without trimming. In theory, they're not the same, of course. In practice, I've seen top posting with trimming a total of... well, zero times.
And in either case, reading something from top to bottom is certainly easier than to read something in the order of:
Last 3% of the message, followed by the bits that are 93-97% into the message, followed by the bits that are at 86-93% of the message, followed by the bits... every email is like watching Memento. With each scene in whatever typeface that particular person's email client thought was a good idea to enforce upon me. And sometimes purple.
Yes, everything you need to know ought to be in the mail itself but often you need context or surrounding details or just some information as to why the question arose.
You can in the very most cases figure that out by skimming a couple of previous mails in the thread. Very quick and saves another round trip, which can be very annoying if you are on different time-zones.
When forwarding a message you should include the thread as RFC 2822 attachments (RFC number recited from memory, may be wrong). Your mail client should make this easy for you.
Is it not ironic that the very website promoting the benefits of plain text, uses a textual medium consisting of bold, underlined, colorized, and other font effects? Something that can only be achieved via HTML enhanced emails!
I think this is unfortunately mostly preaching to the choir. The "industry" is moving in the opposite direction - the page should have a section on "AMP for email".
In more that 20 years I cannot remember when I last saw a well marked up HTML email that wasn't miss aligned due to missing closing tags or some other stupid mistake. They are always filled with utter useless and distracting crap and for some reason people tend to think that that is better than simply focusing on the flipping point of the message.
And no, I don't want people to embed screenshots in the message body, I much prefer attachments.
Claws-mail has a beautiful setting called: "Render HTML messages as text", and if that doesn't work because the HTML message is too messed up -> Delete to trash!
Edit: People can't figure out how to make relative well formed HTML for the browser, yet someone thought it was a good idea to introduce the mess to email. Go figure!
The problems with HTML email originate in the days when clients like Outlook would produce horrendous, non-responsive HTML that were basically entire embedded web pages; the idea that the sender should be able to dictate the font of an email is a bit ridiculous, not to mention the layout, and the result was often broken depending on the email client.
Emails aren't web pages, but they do benefit from formatting (bold, italics, links, paragraphs), all of which lead to better emails overall. After all, everyone has their plaintext style (asterisks for emphasis, or maybe underscores, etc.) and HTML formalizes those conventions in a way that has been standard for decades and even centuries if you consider typesetting in general.
I like the idea of HTML email better than I like the implementation. I'd love to see a minimal HTML subset that only included formatting (including paragraphs, indentation and blockquoting), images and links. No tables, no box model, fonts or styling. We can keep full HTML for fancy marketing emails, but letter-form email should be simple and impossible to abuse.
These days, of course, most email is HTML simply because that's the default for almost all email apps (Gmail, Outlook, Spark, Polymail, etc.). It's not true that only marketing emails use HTML, as the author claims.
This is counter to my own experience. I am using (plain text) email since 27 years. Including inline quoting and avoiding top posting at all costs.
People used bold (not sure how to render a '*' in HN) /italic/ and _underscore_ consistently on lists, newsgroups and -- rarely, as seldomly needed -- in private correspondence.
I learned how to do this by example. Everyone being very disciplined about this in the 90's still.
This started deteriorating rapidly in the wake of eternal September [1] and Outlook becoming the standard client in the corporate world, using HTML as default.
Personally I blame Outlook for HTML email hell foremost.
It is very simple to display plain text email, omitting aforementioned formatters and applying them. The same goes for displaying in a proportional font (detecting intended indentations from the original and replicating them with tabs, on the fly).
Using such formatters is just another (and not even alien) form of inline markup. Actually the very one that inspired markdown, ReST, etc.
The only reason people use HTML email is that it's the default. Not that it's better in any way.
>We can keep full HTML for fancy marketing emails, but letter-form email should be simple and impossible to abuse.
You had me convinced up until this part. Marketing emails are, IME, the most prone to being abusive. If anyone deserves to have their fingers rapped every time they try to get fancy with HTML mail, it's the scumbags that send marketing email (which is by definition spam).
I was always a strong advocate for plain text emails. Because for many years my mail client was Mutt, I saw everything plain text. Now that clients are graphical, it bothers me to know others might be reading my plain text emails with a "Times New Roman" font, and not a monospaced (as god intended it to be).
So, to avoid that, I use HTML on my emails. Yes, it makes them a bit bigger. Yes, they go against my very belief. Yet, they look like I want them to be seeing.
overwriting HTML styles is harder than setting how to format plaintext. HTML styling has order of magnitude more customization options than plaintext, which has three that I can think of: font, font size, tab width. Almost all clients have customization for plaintext, I haven't seen one that can override HTML customizations.
One interesting anecdote about plain text not being the default in most popular email clients come from my own PublicEmails.com email-to-blog-post project. People would experiment with it and the allowed list of HTML tags for formatting (https://publicemails.com/blog/display/772/37f6f81d9a) but would get confused when the tags would render verbatim instead of being processed correctly. They didn't realize they were in HTML mode by default in most email clients like Gmail, and that they would have to manually switch back to plain text if they wanted to use HTML tags.
I ended up adding a question to the FAQ to address this issue specifically, though people still get confused from time to time. There is a touch of irony about it - to get HTML tags to work, you have to be in plain text, not HTML mode. Once you're in HTML mode all that's needed for formatting is the client's own formatting controls.
I'd like to see formatting for email that doesn't have the security and privacy vulnerabilities and complexity of HTML email. Markdown would be fine. Inline images can refer only to attachments in the same message, not to arbitrary URLs. Maybe some restrictions on links to reduce their effectiveness in phishing emails. It would be fine. It would be everything you actually need.
> I'd like to see formatting for email that doesn't have the security and privacy vulnerabilities and complexity of HTML email. Markdown would be fine
Markdown supports arbitrary HTML, and so has exactly the privacy and security implications of HTML (though there extensions available which limit this, and are standard in some markdown processors and expected by default in some markdown variants.)
Who does this page cater to though? The recommended tools are programs that are packaged for Linux or need compiling[1]. If they want to convince anybody who already does not prefer plaintext then they should be targeting the Windows and macOS crowd.
[1]: Later some tools such as thunderbird or configuration for Apple Mail and Gmail are mentioned. They should be top and center.
I've also disabled wrapping (as recommended in that document), however I'm not a big fan of it. I do think that plain text wrapped at 72 or 80 characters looks much nicer. I wish thunderbird allowed me to select portions of the text to wrap, or to disable wrapping for selected portions (e.g. a code snippet). Is this handled better in other email clients?
It will because every line would end in a single trailing whitespace character. But that doesn't mean you cannot use Thunderbird with format=flowed enabled to respond to patch emails. Unless you're including a patch in the message and expect someone to use git am to apply it to their local git repo, having format=flowed set won't matter.
> I wish thunderbird allowed me to select portions of the text to wrap, or to disable wrapping for selected portions
You can sort of do it by copying unwrapped text from another program and pasting it into Thunderbird as quoted text (ctrl-shift-o or paste as quotation). But you will need to manually remove the quote markers from the beginning of each line.
I think it comes down to a lack of flexibility with the MUA composer. If you're using an editor like vim to compose the email, it would be easy enough to read the patch into the message by running
:r file-containing-patch
And then visually highlighting text and running:
:'<,'>s/$/\s/
to append whitespace to lines you don't want to be hard-wrapped in clients that support format=flowed
It seems to me this webpage uses "bottom-posting" to include both what Wikipedia [1] calls bottom-posting and what it calls interleaved posting or inline replying. For example, in the section called "Top posting", the webpage advises you to "Write anything you have to say underneath the quote it pertains to.", which is interleaved posting (unless you only quote one thing).
Is this abuse of language common? Am I actually on the side of bottom-posters because they really mean "write anything you have to say underneath the quote it pertains to" rather than "reply to everything at the bottom"?
I reallyREALLY wish they'd make a new release (there is work on still going on but the latest release is from 2013). SquirrelMail is my favorite webmail since it was first available on a shared host i used early 2000s or so. So simple and lightweight. But the lack of releases apparently made Debian to remove it, then followed by several other hosts. I could set up a VPS to have it myself but i do not really want to bother with mail administration (if anything, not wanting to bother with mail was one of the main reasons i switched to shared hosting - which initially had SquirrelMail, to my delight, but sadly got rid of it some months later).
Plaintext email was doomed from the moment it got named "email" rather than "etelegram". Regular mail can include graphics, different fonts, color, bold, etc., so it is natural to expect email to handle that too.
Early email systems could not, but because they ran on systems that could only display simple text, the natural assumption is that they were plain because of technological limitations.
Once GUI systems became the norm, removing that limitation, it was inevitable that email would follow.
This is not to say that HTML email is good. It was inevitable that email would support rich text, inline attachments, and stuff like that that, but HTML did not have to be the way that was done.
> When you reply to an email, many email clients will infer and include a quoted version of the message you're replying to above the text of your reply, or else prompt if the context is ambiguous. This is normal-- it happens in clients that conform to RFC -1 which use data gleaned from your input to prevent long email threads containing the entire history of the discussion in an increasingly long and nested footer on every email. This is called "top post prevention" and is required in all conforming clients. Please email your admin if your client doesn't conform to this specification.
There are just different use cases for plaintext and HTML email. I can't implement plaintext only email in some environments because it just won't work with who I'm communicating with.
> Notice: Use of IMAP and SMTP with Protonmail requires the use of a special third-party bridge. Protonmail is not recommended for this reason.
I am a bit tired of this campaign against Protonmail by Sir_Cmpwn. Yeah you can't use SMTP directly. But if he was being objective would gmail not get a disclaimer "Google read your emails to work out what to sell you, and pass this on to government surveillance too"...Outlook is not recommended because... insert whichever gripe about protocols is on your mind.
It could be a different format altogether - something third as the golden mean.
Alternatives: Markdown (we need specification for that) or HTML v2.0 or something else.
Requirements to such format:
- it shall provide only one way of text -> rendering and rendering -> text so WYSIWYG can be implemented in non-controversial manner.
If HTML then HTML v. 2.0 as the last version that supported WYSIWYG editing (as it has no CSS). CSS is allowed to be applied by email agent application (user's theming) but not from the body of the message.
Agree. Hyperlinks and the subset used by term emulators today. For example bold and tables can be rendered on even terminal emulators today. Another issue is probably captioning.
I use Claws Mail with the "Fancy HTML Viewer" plugin -- by default emails get rendered in plaintext but I can hit a few buttons to see the HTML version if I really need to (only happens occasionally). I only compose messages in plaintext, as do most of my coworkers, and it works great. The only thing that's still a problem is top posting... as much as I hate it, I'm not going to be That Guy and reply to a 8-email-deep 6-participant chain at the bottom.
> HTML emails are mainly used for marketing - that is, emails you probably don't want to see in the first place
Wait what?
Maybe you're subscribed to the wrong newsletter, but in my case, I'm subscribed to products / brand I like, I'm aware that I will receive advertisement / product updates and I'm fine with it !
The claims against Protonmail and Tutanota (possibly others, but the are the two I saw) are from a place of ignorance. Both are the way the re because they are decrypted clientside.
IMAP/SMTP needs a bridge or is inaccessible because of the needed decryption step.
For me it's not about the screen width. It's simply unergonomic to read wide lines of text. Ever wondered why book pages are vertically-oriented? I don't want my eyes to run a marathon from left to right with each line of text.
Thanks, I apparently found out that Claws Mail had Windows version. Default Windows E-mail client does not support text mode at all and I prefer text mode, so I'll try it.
You can apply the information on this page to configuring your mail client (and should!). It's also intended to serve as a one stop resource for cataloguing plaintext support in most, if not all, mail clients, in the future.
Well, why bother writing his own post in rich text then? He has headings, bold, links, grey font at the bottom, image.
Don't get me wrong - for high security systems/environments, plaintext is way to go. For everyday life use cases I prefer html. Although with Markdown rendered text I would be pretty happy. And enough for author to cover his post sans the green/red boxes and grey text.