There are two main types of emails on the internet: plaintext and HTML.
What about MIME? You can just send both as multipart/alternative, which is what many clients actually do.
The former is strongly preferred, but often isn’t set up by default.
There is a reason for that: even the most basic typography such as bold text isn’t supported. In addition many clients render with proportional fonts by default, and stuff like aligned tables are essentially impossible in plain text email.
Look, I’m not a huge fan of HTML email either, I send plain text emails, but it does exist for a reason, and “always use plain text” without addressing the reasons it exists doesn’t strike me as very constructive.
I remember a “text/rtf” MIME type being proposed at some point (IIRC in some RFC, not related to Microsoft’s RTF format) which is essentially a stripped down version of HTML for email. That never really went anywhere though. Something like markdown rendering might also work.
Interestingly enough Gnus will highlight text as bold in a markdown-esqe way, just like it makes links clickable. After all, Markdown’s syntax was just a (kind-of) formalisation of the style that was commonly used for email exchange.
It does /italics/ and _underlining_ too. It also has a whole bunch of other cool features, like linkifying/buttonizing things like C-h v gnus-button-alist RET or (info "(elisp) Integer Basics"). Highly recommend anyone using Gnus to skim through gnus-art.el at some point.
Sometimes I wish that basic formatting, like bold/italic/underlined, were part of Unicode, in the form of characters similar to ANSI escape codes, and you’d be able to use bold text everywhere.
It could say mathimatical fraktur “you can” end mathematical fractur or something. I mean honestly this also makes screen readers a pain for reading mathematical texts as well so I don’t think that it’s completely reasonable to call this “working as intended”. It’s really working in the laziest and simplest possible interpretation. The goal shouldn’t be to only use characters that screen readers currently support, it should be to fund and sponsor screen reader development such that they can be used. If each character over and entire word or sentence uses a character modifier, it’s really stupid for it to repeat it over and over. Additionally, you don’t need to say “Mathematical Fraktur” because there’s only one Fraktur, kinda hinting at how this screenreader is busted. NVDA has a thing where you can flip on to normalize the characters, which is a perfectly sensible solution.
It is important to point out that it does badly break voiceover though, and probably JAWS so good catch. This is coming from someone who uses screenreaders at times. Yes it sucks to have a busted screenreader, no the solution is not to avoid using anything that breaks the busted screenreader.
Yes it sucks to have a busted screenreader, no the solution is not to avoid using anything that breaks the busted screenreader.
Totally – but also we have a really well-supported near-universal markup language that works for making text bold/italic/underlined right now and not just for latin letters and it also works well with all sorts of existing display and indexing systems and MUAs and MTAs and it’s called HTML.
you can encode underlined and bold text with overstriking. for example a bold a would be a^Ha and an underlined b would be b^H_ . i wouldn’t do it in email though.
In rhetoric, antimetabole (/æntɪməˈtæbəliː/ AN-ti-mə-TAB-ə-lee) is the repetition of words in successive clauses, but in transposed order; for example, “I know what I like, and I like what I know”. It is related to, and sometimes considered a special case of, chiasmus. – wikipedia
Looks like the definitions reach each other. Linguist expert out there? :)
It’s a terrible default. If someone gets a lot of e.g. bot registrations from Tor, they should have that option, but it’s really stupid for a static document site that cannot receive any interaction from the outside world.
Do you think it should scan and interpret all the content on all the pages it serves to decide which get Tor filtering? Or what’s your alternative implementation that achieves the same level of protection with the labor cost of adding some firewall rules? Gotta be something their management would agree with.
Bam! There it is! That could be a great sell since they’d spend less resources on the CAPTCHA’s in the first place. Maybe (depends on implementation). I’ll try to remember and mention it when I run into Cloudfare employees. :)
There’s the ages-old ASCII Ribbon Campaign. One can sometimes find the ASCII ribbon in old postings in mailing list archives. I am sure the website at some time hold a message that said the ASCII ribbon campaign has ended and failed, but appearently somebody set it up again. The OP might consider linking to it.
Long live the ribbon!
_
ASCII ribbon campaign ( )
against HTML e-mail X
/ \
This is called “top posting” and is strongly discouraged.
This recommendation should be tempered by the golden rule of email of etiquette, which is pick a format and stick with it. The only style worse than top posting is when half of the people on a list are top posting and the other half are posting inline. This makes finding relevant information a massive pain and can confuse some email clients drastically. If the culture of your email list is to top post, then bite the bullet and do it, because trying to be the renegade will only lead to greater confusion.
That being said, if you’re the first to reply or setting a new precedent, then take this as a great and powerful opportunity to make a community of better netizens.
While I agree with what you wrote, I don’t get why bottom posting is encouraged? That ways the receiver first sees the quoted text, and only after scrolling down gets to read the actual content.
While I agree with what you wrote, I don’t get why bottom posting is encouraged? That ways the receiver first sees the quoted text, and only after scrolling down gets to read the actual content.
This recommendation should be tempered by the golden rule of email of etiquette, which is pick a format and stick with it. The only style worse than top posting is when half of the people on a list are top posting and the other half are posting inline. This makes finding relevant information a massive pain and can confuse some email clients drastically. If the culture of your email list is to top post, then bite the bullet and do it, because trying to be the renegade will only lead to greater confusion.
That being said, if you’re the first to reply or setting a new precedent, then take this as a great and powerful opportunity to make a community of better netizens.
This is called “top posting” and is strongly discouraged.
Seriously though, I think it’s odd that people use bottom posting in forums like this one fluently, but find it so difficult in emails. I’m inclined to blame bad default behaviour of certain clients.
Bottom posting isn’t to be used indescriminately. You should delete any text from the original message which isn’t directly relevant to what you have to say, and interleave short quotes with short responses underneath. You can also just remove the original quote entirely if it’s not necessary.
OK, that I also agree with. But how is that related to top/bottom posting? Seems like the thing to encourage here is selective quotes, not top/bottom posting.
That’s not my experience. At least in the communities I’ve participated in, bottom-posting describes the practise of not trimming the quoted mail at all, and is frowned upon.
“But if plaintext is so good, why is this page written in HTML?”
This is a reference document, not an email, you twit.
I think it would be better to try and justify the answer to this question. Why is a reference document different than an email? Two reasons immediately come to mind:
It’s longer.
Because it’s a reference document, the assumption is that it will be viewed in an environment that supports HTML (or PDF).
#1 sounds silly, but I think it’s the more compelling reason. In a short document, you feel less pain from the lack of adequate typography, and don’t need hyperlinks between sections. There are also good reasons why you would never want to send an email that is this long.
That’s a decent reason, but imho, neither immediately obvious, nor completely overwhelming. I think I estimate the gap between what’s good for documents and what’s good for email as much smaller than you do.
Edit: I meant to say that while I disagree with the overall claim, and I think the choice to brush off that objection weakened the piece, I really appreciate this article, for carefully stating the case for something that’s often a shibboleth.
I think I estimate the gap between what’s good for documents and what’s good for email as much smaller than you do.
I agree there is something missing in the analysis. One problem with plain text (for either docs or e-mails, but mainly docs) is that I can’t specify proportional fonts for text and fixed width fonts for code.
That seems like a really minor feature, but it makes a big difference for readability IMO. (BTW this web page is very nicely designed, but I still think it could benefit from proportional fonts.)
I often switch my e-mails to plain text because there is no mixing of prose and code in them – i.e. this issue is moot. But most of my web pages have both prose and code, so I use HTML of course.
So for me it isn’t “e-mail vs. docs” but “prose-only vs prose + code”.
In fact there’s exactly one place in Oil’s docs where I don’t have proportional fonts, and that’s because I want INSTALL.txt to be primarily a plain text document. But honestly it sort of annoys me vs. the other docs on the site:
edit: And of course I also like the hyperlinks in HTML, although when I write e-mails I’m fine just pasting in plain text URLs. I don’t make as much of an effort to make e-mails pretty.
So INSTALL.html is derived from a plain text document? You have some way to make the headers in the HTML document bold and large, so maybe you could use a similar approach to make the non-code prose variable width.
Yeah it’s actually just markdown, but I want to be primarily text. So I avoid the normal backtick syntax, because that would read funny from the terminal. Likewise for links.
But not for the headers and indents.
So I think it’s actually a good example of the tradeoff between text and markup. I almost always favor markup, except in this one case. It’s slightly deoptimized for the web, but I don’t think it matters very much.
HTTP is a protocol that is targeted to anyone to access to the content, and the medium for documents.
SMTP is a protocol addressed to selected recipients. It is the medium of choice for conversation and messages.
My opinion:
I have nothing against transmitting HTML in MIME mail. The point is: why do you send a document when what you want is sending a message? It is not much different than application/pdf, just an encoding question.
Formatting email in html makes the stack really more complex: your mail client needs to be a complete web browser, or offload it to an actual browser. Adding to that the need for MIME, but non-ASCII characters also often make the clients use MIME…
The rest is not specific to HTML in emails so I don’t post it here…
I use Fastmail, which doesn’t support wrapping. I don’t think it’s a particularly good idea to wrap at 72 chars (it is a display preference so it should be a receiver-side matter), but on lists where that’s the norm I just compose the email in my text editor and use the reflow feature.
When you’re in the webmail editor in Fastmail and you’re in plain text mode, you can hit C-m to hard-wrap the email. When I get some time I’ll send a patch to the website to add this info.
I think the vast majority of the email clients mentioned on the website do hard wraps, no? The only alternative to hard wraps is format=flowed AFAIK (tell me if I’m wrong) and, based on Fastmail’s 2 years-old blog post, it sounds like very few clients implement it?
Yes, lots of software does hard wraps, but that doesn’t make it a good thing. I’m often using NeoMutt with Vim, but I specifically disable hard wraps, I’m enabling only soft wraps.
“soft wraps” is when the receiving client does text wrapping, just like any text editor, right? (i.e. the sender didn’t include any line returns in their paragraphs?). I’m confused as to why this isn’t the recommended default? (i.e. make people send email without line returns, and configure their client to do soft wrapping).
For example, the author of the plaintext.email website asks people to hard-wrap their emails when sending to sourcehut mailing lists, when it seems to me it would be vastly superior to let receiving clients do soft wrapping on the fly so that it works with any type of display width? Am I missing something?
If you’re missing anything, then I’m missing the same thing as well. I see no reason why the client shouldn’t be able to perform soft wrapping by its own.
Using 80x25 terminal? No problem, I’ll wrap the text for you to fit your current terminal. Using variable font width and a mobile phone? No problem, I’ll just wrap the text for you accordingly.
I mean, Lobste.rs comment box does soft wraps and there are no problems with that. I.e. I can’t imagine why anyone would want to enable hard wraps in Lobste.rs comment box? Similar to this, I don’t see why anyone would want to enable hard wraps in e-mails as well. If some software doesn’t support soft wrapping, it seems it’s a broken software, because vast majority of e-mail applications DO support soft-wraps.
One weak argument could be used that it’s more convenient to read text when it’s placed inside a column instead of spanned across large wide-screen monitor. But then you can just instruct your software to wrap the email to 80 characters and you’re done, no need to include CR/LF inside the e-mail. And if one’s software doesn’t support it, just resize the window and you’re done!
As for plaintext.email website, the author has lots of opinions that are directly opposite to mine, so I can’t really explain the rationale for most of the arguments :)
I can’t imagine why anyone would want to enable hard wraps in Lobste.rs comment box?
If you read a suitably nested comment thread on mobile, you end up with a word a line, then a few letters on a line. This would be a good reason to not infinitely soft wrap.
i’m not sure if this should be recognized by commenting here, as it feels outright like a troll attempt.
assuming this is a reaction to https://lobste.rs/s/ktvzwl/use_plaintext_email :
asking users and giving directions to use plaintext isn’t “gatekeeping”. by using this word you apply a negative spin on the plaintext email site, maybe even on the author. i don’t want to see this kind of conversation here.
edit (after the archived version was linked here):
Request for Guillotine: 1
really? that low?
Upon the dismantling of the original mailing lists due to the
power vacuum caused by several high-profile Alpine Linux core
contributors leaving the project due to burnout or personal reasons,
the individual behind SourceHut, aka sr.ht, stepped up to provide new
mailing list software in order to make themselves an instrumental
part of the Alpine Linux ecosystem and deeply embedded in the core
development team. This is commonly described as a “position of power”.
Scientists have not yet discovered whether this “position of power”
in the Alpine Linux community has yielded any benefits that are
typically borne of “positions of power” in enterprises that matter,
such as fame, wealth, or high-altitude sexual escapades. While it is
too early to make a total judgement call, there is no indication that
any of these facets of being in a “position of power” are to become
true.
As far as I’m aware, according to the Fediverse feed of the author of “useplaintext.email”[1], the site sprang up as a response to people asking why - all of a sudden - they couldn’t contribute to the mailing list[2] in the IRC channel. This happened without any warning to any user or developer, and was solely at the whims of the individual who was now in charge of the mailing list software (and made the useplaintext.email website).
The individual who wrote that site locking people out from contributing to a Linux distribution because they came into control of the mailing lists does, however, probably qualify.
The submitter of this link actually orphaned all of their packages because going through the hassle of having a different email client just to contact the mailing list was not worth the hassle for what is ultimately a volunteer effort.
thats all well, but it doesn’t warrant “Request for Guillotine” and smear campaigns. dropping the packages is unfortunate, but if it feels that it is the right thing to do it’s a personal decision.
good alternatives are:
try to discuss it reasonably, preferably not via a microblogging service which are a shitty medium to to that.
write a patch for the mailing list software so that only the html part is dropped, and ask for inclusion of this patch.
ask if you can host the mailinglist instead, with the settings you want. this bears the risk that other people are fine with blocking html mails and your offer is politely declined.
write a patch for the mailing list software so that only the html part is dropped, and ask for inclusion of this patch.
I personally did just that, and it was rejected. I also tried to offer a self-reply patch, and that was also denied:
21:47:53 <awilfox> I didn't see any question about this on the discuss archives: is there a way to have self-replies copied to your email? on virtually all mailing lists I'm subscribed to, when I email the list I receive a copy back (which is reassuring that the ML software did not eat it and there were no MX issues). I'm not getting self replies on sr.ht MLs.
21:48:18 <ddevault> no, this is not possible
21:48:39 <awilfox> would a patch adding this option be considered?
21:48:47 <ddevault> probably not
try to discuss it reasonably, preferably not via a microblogging service which are a shitty medium to to that.
Yeah, microblogging services are certainly not ideal. It’s been discussed at length in the IRC channels (which are the official communication medium for the project). I’ve seen discussions about lack of action after said discussions in places elsewhere. Namely, the person in control doubling down on leaving it disabled.
write a patch for the mailing list software so that only the html part is dropped, and ask for inclusion of this patch.
The mailing list software is developed by the same person who runs it. I believe this was raised and was responded to with a firm “no”.
ask if you can host the mailinglist instead, with the settings you want. this bears the risk that other people are fine with blocking html mails and your offer is politely declined.
No idea where anyone is at with that. I will point out this part from the site:
This was described by the Alpine Linux project lead as:
a surprise and unintentional (except from a single person)
super annoying to get locked out of participation like this
imho, unacceptable
So I’m not sure there’s a consensus even there.
fork the distribution.
I don’t know if you can get more fringe than a fork of something like Alpine Linux. Perhaps forking Void Linux? Forking over issues that are surmountable with encouragement and a correct understanding (e.g., it’s inconvenient for developers who use mobile devices, it breaks screen readers (and consequently affects those with low or no vision), and provides no feedback to users if their emails are dropped) is, in my view, pointless. I personally feel forking a project is kind of a “last resort” sort of thing.
That said, I haven’t ever forked a project, so perhaps it isn’t. I’d appreciate your own view on that if you disagree.
Yeah, microblogging services are certainly not ideal. It’s been discussed at length in the IRC channels (which are the official communication medium for the project). I’ve seen discussions about lack of action after said discussions in places elsewhere. Namely, the person in control doubling down on leaving it disabled.
i’m not involved in alpine linux, so i didn’t know about these discussions.
The mailing list software is developed by the same person who runs it.
i see it this way: the developer has the spare resources to host the list, providing it for free to the alpine linux community. i don’t think that the community is forced by anyone to use it. if the majority decides the list software is fine, then that’s the consensus. of the project lead thinks it’s unacceptable, it is maybe time to look for an other place to host the list at. blaming someone giving out free things is just plain wrong.
I don’t know if you can get more fringe than a fork of something like Alpine Linux. Perhaps forking Void Linux? Forking over issues that are surmountable with encouragement and a correct understanding (e.g., it’s inconvenient for developers who use mobile devices, it breaks screen readers (and consequently affects those with low or no vision), and provides no feedback to users if their emails are dropped) is, in my view, pointless. I personally feel forking a project is kind of a “last resort” sort of thing.
my list was in increasing “drama-steps”, yes. forking almost always isn’t the right solution.
my point is that the reaction here (calling for beheading) isn’t a way to fix issues, it’s just flaming because something isn’t the way one wants it to. i know that it is hard today for many people if their points of view aren’t accepted as the only right one, but then it may be time for a fork instead of destructive behavior.
That said, I haven’t ever forked a project, so perhaps it isn’t. I’d appreciate your own view on that if you disagree.
i neither, but there are “forks” of slackware for example, which mostly are additional package sets and tools though.
forking doesn’t has to mean that you go completely different paths.
I’m only going to quote short parts, not to take them out of context but simply to make this thread easier to read as it gets further indented left.
i’m not involved in alpine linux, so i didn’t know about these discussions.
Fair. Me neither, other than being in the IRC channels. I already have a bouncer on Freenode so I just idle in there. I use Alpine quite a bit for Docker so it’s nice to see what’s going on in there sometimes.
i see it this way …
You raise a good point, however I take one small issue with this: This particular “feature” was never raised by the person who offered the hosting until after the transition had taken place. I can’t immediately think of a real-world analogy, but I imagine you don’t need one.
To offer to host the mailing list then lock out a portion of the user base until they fit your world view is, in my (in the big picture, unqualified and irrelevant) opinion, in pretty bad taste. This should have been raised as a condition prior to the implementation.
As to who is at fault for this, I wouldn’t be able to say. I don’t know if it’s unreasonable to assume that a mailing list software would not drop emails given undisclosed criteria.
my point is that the reaction here …
Agreed, although based on context of the document one could infer that it was aimed at the practice of locking users out itself, given the first line being “Elitism-Free Working Group”. Thinking otherwise is uncomfortable in my opinion.
i think that it just hasn’t occured to them that this would be a problem. i’d always assume plaintext on mailinglists, especially on lists of distributions etc. the lock-out was an unfortunate side effect of this. that the list shouldn’t just drop the mails but bounce them is a valid point though. “things just went wrong”, probably because of bad communication not bad intents.
Agreed, although based on context […]
i didn’t like this document because of linguistic tactics, it’s more-or-less authored anonymously, and full of ad hominem arguments. it’s bad taste and counterproductive.
my point is that the reaction here (calling for beheading) isn’t a way to fix issues, it’s just flaming because something isn’t the way one wants it to.
Well beheadings rarely fix anything, but we can’t be sure until we try. What if the head grows back? I thought that website to be pretty funny anyway, but I guess YMMV. Maybe a satire tag would’ve helped. :)
i know that it is hard today for many people if their points of view aren’t accepted as the only right one, but then it may be time for a fork instead of destructive behavior.
If someone makes a website about how colonialism is cool, is it destructive to make the opposite website, or just discussion?
I wasn’t aware of that (I also wouldn’t be affected by it, being a TUI email user). That does seem like a harsh sudden requirement for continued participation/contribution in the project.
I presume this is partly triggered in reply to all the noise about the SuperHuman client….
Interesting point here…
Privacy invasion and tracking
The accusation levelled against HTML emails is that marketers use HTML e-mails which provide things like a tracking pixel or other minutia in order to discern as to whether or not you have opened and read the e-mail. E-mail providers such as Google will automatically cache all remote content and serve it from its own server to prevent your IP address being leaked to the owner of the server to which the tracking pixel points. This also masks the time at which you open the email. Additionally, bad actors are also known use knives. An adequate justification for using scissors or an egg-wash brush to cut bread has yet to be seen.
Apparently Superhuman is an invitation-only Gmail front-end so something doesn’t match up….
If I send you an email using Superhuman (no matter what email client you use), and you open it 9 times, this is what I see:
Ok, I think the original blogger overstated the capabilties wrt gmail and retracted that in a later post. With gmail it can see when opened, not location.
However it seems clear that for a number of other email clients out there you can see both, and even when you revisit.
I expect to see a few more “via email” replies to this post :^)
Anyhow, good stuff. I’d recommend neomutt (https://neomutt.org) over mutt, lots of great features already patched into it. It handles HTML emails just fine by piping them through w3m, with the ‘copiousoutput’ option in the mailcap making it display like any other email.
I’m not a huge fan of the whole concept of elitism (and its broad application to things where doing the “elite” thing is something quick and low effort like downloading a second free mail client and not, say, spending years earning a PhD) but suddenly introducing new requirements into a project that didn’t have them before, when even the project lead dislikes them, is pretty bad.
This phenomenon has been named “not being a contrarian” by the scientific community.
Being a contrarian can be very fun though :) So here’s my contrarian hot take: email is bad, just in general, the whole thing. Mailing lists: kill them with fire. More like failing lists!
That means using things that are very complex on the inside, using very complex servers, complex formats, complex protocols, hard to get right, using a complex centralized security model, complex everything, and even complex wording on that sentence!
E-mail is not much better on complex side.
But I agree that when you take “it’s working” for granted, it actually feels smooth!
Now you also rely on Google (for maintaining the web browser), Google (for Gmail), Google (for publishing the web standards), Microsoft (for GitHub), and Google (for choosing the crypto protocol to use through page-rank’ing higher pages using their favorite protocol du jour), then Google (for hosting the server) and Google (for developing the language the website is written in).
Feel free to replace the placeholder Google to whatever you want, you get a more realistic vision that is really not THAT catastrophic. After all, human rely on each other right? It’s not like running your mail server in your corner…
In the end, SMTP is not that good for spreading the news… What if you weren’t there when the conversation did start! You’ll have to fetch the archive for some HTTP (hey there you again!) mirror…
So. We need: something that feel as complete and smooth as phabricator, that is as trivial as SMTP (it’s really a simple protocol, MIME + old mailer daemon + weird mail client are to blame). Anyone here? (the sound of echo: here, here, he…)
Oh Hi IM2000! What are you doing all alone down that hill? You lost your smtpd? You don’t have an httpd? Come, I’ll take care of you…
Well, the mail submission process could be a lot more complex (encoded in XML RPC with requiring to start over HTTP, then switching off to websocket transmitting JSON), there would still be tools to send email, making as easy to call mail() in PHP.
So there would be as many plugin-pirated wordpress website spamming around as now.
While we are at designing things, why make it hard to implement? There is a limited amount of thing we can engineer, so adding complexith is reducing the amount of things we can build.
If downloading an HTTP page was as hard as cross-compiling GCC, would the web even exist?
So, using domain names as if they’re Twitter hashtags is continuing, I see.
Again, there’s not a mention of Gmail and its malicious ways here.
After this individual stepped in to provide this “service”, the ability to contribute to the mailing lists using e-mail with HTML ceased.
That’s hilarious.
Anyway, I find it amusing this article is written without HTML, to counter that other one. Say, perhaps I should register a domain and participate in this dumbassery. It looks like an easy way to get attention, since everyone loves to share their opinions and personal preferences and it’s just technical enough for people to feel smart while discussing it. No, I won’t.
So, using domain names as if they’re Twitter hashtags is continuing, I see.
It’s way easier to remember “stop-gatekeeping.email” than “www.example.com/doc/wp/2019-07-24/stop-gatekeeping-email-6655321.html”.
Say, perhaps I should register a domain and participate in this dumbassery. It looks like an easy way to get attention, since everyone loves to share their opinions and personal preferences and it’s just technical enough for people to feel smart while discussing it.
The textual web should have stayed at HTML 2.0 – didn’t the WYSIWYG HTML editor of Netscape Navigator Gold produce clean code, that could have been a compromise for email, too?
Where are email- and web clients rendering text/markdown directly themselves?
It is not. It is issue with email clients that can’t correctly parse multipart/mixed content, and did not separate text/html parts from application/pkcs7-mime parts. HTML only allowed sending those contents out to the attacker. Without botched parsing there wouldn’t be any problems. But still, it is true that HTML allowed to exfiltrate the data.
It’s weird to see the word “gatekeeping” here. Usually gatekeeping involves patterns which make assumptions about the capabilities of the user, whereas in this case advocating for plaintext email is all about avoiding making assumptions about the capabilities and making allowances so that everyone can have access.
making allowances so that everyone can have access
There’s a difference in advocating for plain text emails, or automatically rendering a plain text alternative in the mailing list processor (both of which would do that) and silently blocking every mail that comes as HTML (which prevents access by those with mail clients that are HTML only, like some versions of Google Mail)
There’s a large mail client that everyone seems to be ignoring here: iOS Mail.app.
The Mac OS X Mail.app can do plain-text only, but iOS can’t. No alternatives were given for iOS. I don’t want to have to buy an Android phone just to contribute to mailing list discussions while I’m travelling. (I have tried Android before and I didn’t enjoy it.)
The few advantages they offer for end-users, such as links[…], aren’t worth the trade-off.
I must vehemently disagree. I’m afraid you’re putting the challenges of HTML email for client implementors, and the unsuitability for a software development workflow that many would consider archaic (emailing patches in the message body), ahead of a good user experience for everyone else. That’s putting the cart before the horse, isn’t it?
Consider links in particular. Do we really want to expose long, arcane URLs to end-users? I’m sure you’re used to it, because you use a TUI email client. But is that really the experience that we want for the whole world?
There’s also an accessibility angle here. Try reading a plain-text email with long URLs with a screen reader. Not a pleasant experience, is it? Sure, the user could shut up the speech, move past the URL, and keep reading. But still, proper inline links are a much better user experience.
I read the archived version, and it is so hilariously wrong. Quotes pulled out of nowhere, quoting yourself without any source and putting it like it’s not you saying it, and lines like this: “This phenomenon has been named “not being a
contrarian” by the scientific community.”
Loading it was noticeably slow on my end, too, and I wouldn’t call 171 kB pretty small - not when a PNG version at the same resolution is ~14 kB, as converted by ImageMagick.
There is info on email clients that support plaintext email in that page. Only two email clients don’t support sending plaintext emails at all: Afterlogic and Mailspring.
Exactly - the site explains why plaintext email is better for the end user in simple terms goes through most common mail clients to explain how to use plaintext email.
Furthermore, there are simple instructions on how to contribute if somethingvisn’t mentioned.
It’s not elitist - this is very much by the people, for the people, in the people’s interest.
To clarify, I wasn’t referring to the Alpine situation, simply to the site and its message. The Alpine situation is certainly different, if they didn’t know that HTML mail would be blocked.
Having said that, I don’t think that it should have been as much ofva surprise as some people are saying it was; Drew is very open aboutvhis views on the matter, and you’d have thought that at least a brief check of who they were dealing with would have been performed.
I don’t have anything against the end user (elitism). They are picking whatever matching their skillset or their neighbor use.
Now if you are in the middle of a technical discussion on a mailing list about the network, I’m okay with throwing away mail with broken encodings, mail with HTML, mail with a too large signature, …
It’s up to the community that build the mail stack to know what they are doing while proposing a TinyMCE-like in their webmail interface. I look at you Google.
A point that I think interesting : people using simple technology are elitist against people using crazy (google-scale) technology stacks provided for free and granted without maintenance. Are we not there touching to the core of some decaying hacker culture of working with your own tools ? But hate needs to not be mixed with it.
Now, Google does what the user asks for. Google also can mitigate most of the vulnerabilities that goes along with email because it’s Google.
My conclusion:
HTML comes to mail.
Everyone on gmail.
Google is big.
If I’m recalling correctly, I think that the author is incorrect about Apple Mail not wrapping automatically. It was my understanding that it breaks long lines (for plaintext only) during the sending process.
This is good netiquette advocacy and I support it. Now for the usual nitpicking:
I’m not really clear why this says that macOS Mail doesn’t support bottom posting - what’s the criteria?
I use it in plaintext mode, and I often use it to reply inline and edit the quoted text of a message. If you have a part selected when you hit “Reply”, it only quotes your selection, too, which can be handy.
Also, just for “fun” you might want to add an anti-recommendation for the Microsoft “Outlook Web App” which is not regular Outlook and does not support any kind of plain text. What’s worse, if you reply inline using a sane client, someone using the OWA will not see your reply text unless they know to click the little ellipsis and look through - all the lines will be the same color, but some will not have the quote mark.
But, if your email has the word “congratulations” it will animate confetti when you open it. Congratulations!
Most web-based mail solutions seems to be business-oriented, unfortunately, so even if you have some support for plain-text, you lack basic associated features like ability to read and write mails using monospaced (or fixed-width, if you prefer) fonts. You’re basically forced to use your own CSS overriding vendor’s ones or go with some existing browser extensions doing it for you. Or run vim, :set ft=mail, write mail, :%y, and paste it to your browser, if you don’t want to configure standalone e-mail client displaying monospaced fonts when reading and writing mails.
I tried contacting Zoho Mail in the past to make them improve the situation. After generic response (“It would be much appreciated, if you could share more specific details on the issue you are facing, along with relevant screenshots, so that we could analyze and guide you accordingly.”), I expressed my displeasure that they ask for more details and screenshot, as it felt like they wanted to talk me out of continuing discussion, even though all necessary information were provided in my initial feedback. But in the end I provided screenshot of mockup showing current state (no monospaced font when reading/writing mails) and what would be desired to have (monospaced font used when reading/writing mails). I never received the response.
(For context, what’s the state in Zoho Mail: In Settings > Mail > Compose you can choose Courier as Font Family or specify system font you have, but if your Editor Mode is Plain Text, font options are not applied, they only change default font for Rich Text… And there are still no options for font used for reading. There is Font Family in General > System, but it affects whole zoho interface and there is no monospaced font to choose from, even if someone would be ok to have whole UI using it.)
Gmail is not better either…
Personally I haven’t sent my feedback to them regarding lack of monospaced fonts for plain-text mails, but I suspect people did it in the past many times.
One could also see it as embodying the GB Shaw quotation: The reasonable man adapts himself to the world: the unreasonable one persists in trying to adapt the world to himself. Therefore all progress depends on the unreasonable man.
One of the big qualms I have with work is the use of HTML email. Between organizations the reply chain can get really messy and hard to focus on what is being discussed.
All my personal correspondence is done in plaintext though.
Highly amusing to see Squirrelmail on the list of recommended clients, even though it hasn’t seen any action in the last 7 years. I remember poking at the code… let’s just say a very long time ago and wasn’t impressed with the code quality even back then. Who knows what vulnerabilities it’s riddled with at this point.
One of the most sensible and lightweight web mail clients that I know of is RoundCube. It doesn’t have much in the way of fancy features, just keeps its UI out of the way and lets you get your shit done. (And is actively maintained.)
In fact I sent the details about Squirrelmail, with question “should we even add this, last release in 2013”, and Drew answered “Hey, at least one webmail that does everything correct by default”. So, while it is old, it is the only webmail that does what this website propagates.
I tried out mutt a few weeks ago. It was blazing fast and I was excited to be able to use powerful macros. However, there are many emails I get that I want to be in HTML - my company newsletter and film newsletters to be exact. The escape latch from text is not easy to use in mutt. It requires setting up a trigger to save the email to a file and open it in a browser. We have to acknowledge the reality and see that people do want to receive some emails in HTML.
Then within mutt, if I’m reading an email I know is in HTML, I hit ‘v’, then select the HTML section and it launches lynx with the HTML portion. All other text types are handled by mutt directly.
This does help with HTML-formatted mostly-text emails. But my point is that many emails I want to read have images in them and I want the full fidelity of a browser to read them.
I had previously tried:
text/html; /usr/bin/google-chrome ‘%s’; test=test -n “$DISPLAY”;
I have the same problem as you: I subscribe to a bunch of newsletters about movies and comics and it’s kind of the point to receive an HTML email that can show you the pictures. I also tried mutt and was almost happy with it until I ran against the arcane knowledge of mailcap files and my inability to make a config that (1) works and (2) is cross-platform (since I’m using an obligatory dotfiles repository across my machines). I’d looooove for someone to write a tutorial for that kind of stuff.
via
cadey
3 years ago
What about MIME? You can just send both as multipart/alternative, which is what many clients actually do.
There is a reason for that: even the most basic typography such as bold text isn’t supported. In addition many clients render with proportional fonts by default, and stuff like aligned tables are essentially impossible in plain text email.
Look, I’m not a huge fan of HTML email either, I send plain text emails, but it does exist for a reason, and “always use plain text” without addressing the reasons it exists doesn’t strike me as very constructive.
I remember a “text/rtf” MIME type being proposed at some point (IIRC in some RFC, not related to Microsoft’s RTF format) which is essentially a stripped down version of HTML for email. That never really went anywhere though. Something like markdown rendering might also work.
Interestingly enough Gnus will highlight text as bold in a markdown-esqe way, just like it makes links clickable. After all, Markdown’s syntax was just a (kind-of) formalisation of the style that was commonly used for email exchange.
It does /italics/ and _underlining_ too. It also has a whole bunch of other cool features, like linkifying/buttonizing things like
C-h v gnus-button-alist RETor(info "(elisp) Integer Basics"). Highly recommend anyone using Gnus to skim throughgnus-art.elat some point.text/enriched, RFC 1563. I’m pretty sure Apple Mail used to use it before they switched to HTML.
Ah yes, this is what I meant. Thanks. I don’t know why I remembered it as text/rtf.
Microsoft Outlook actually supports “Rich Text”
https://support.office.com/en-us/article/change-the-message-format-to-html-rich-text-format-or-plain-text-338a389d-11da-47fe-b693-cf41f792fefa
Which they claim is supported only by:
Yes, that’s the RTF-based format Exchange used to use.
Sometimes I wish that basic formatting, like bold/italic/underlined, were part of Unicode, in the form of characters similar to ANSI escape codes, and you’d be able to use bold text everywhere.
𝔜𝔬𝔲 𝔠𝔞𝔫.
Please don’t do this, it badly breaks screen readers.
It could say mathimatical fraktur “you can” end mathematical fractur or something. I mean honestly this also makes screen readers a pain for reading mathematical texts as well so I don’t think that it’s completely reasonable to call this “working as intended”. It’s really working in the laziest and simplest possible interpretation. The goal shouldn’t be to only use characters that screen readers currently support, it should be to fund and sponsor screen reader development such that they can be used. If each character over and entire word or sentence uses a character modifier, it’s really stupid for it to repeat it over and over. Additionally, you don’t need to say “Mathematical Fraktur” because there’s only one Fraktur, kinda hinting at how this screenreader is busted. NVDA has a thing where you can flip on to normalize the characters, which is a perfectly sensible solution.
It is important to point out that it does badly break voiceover though, and probably JAWS so good catch. This is coming from someone who uses screenreaders at times. Yes it sucks to have a busted screenreader, no the solution is not to avoid using anything that breaks the busted screenreader.
Totally – but also we have a really well-supported near-universal markup language that works for making text bold/italic/underlined right now and not just for latin letters and it also works well with all sorts of existing display and indexing systems and MUAs and MTAs and it’s called HTML.
fair. When I don’t have it I’ll probably resume abusing unicode.
you can encode underlined and bold text with overstriking. for example a bold a would be a^Ha and an underlined b would be b^H_ . i wouldn’t do it in email though.
While I agree to some but not all the points, it is a beautiful chiasmus with the other post it points to:
Hats off for that point.
Hats off for that word!
Wouldn’t that be antimetabole where the format is | HTML | plain text | plain text | HTML |?
I’ve never heard of either, but that’s what I got from the wikipedia definition. Thanks for the rabbit hole!
Looks like the definitions reach each other. Linguist expert out there? :)
psa: the document now live at this domain has silently removed the parts calling for beheading and dirt throwing. i recommend looking at the archived version for comparison: https://web.archive.org/web/20190725050122/https://stop-gatekeeping.email/
edit: there is a changelog at the bottom, so it’s not silently dropped. may be that i’ve missed that.
Amusingly the site won’t load for me.
ButtCloudFlare literally gatekeeping me with a captcha for using Tor :(You really blame them when their operating requirements include minimizing liability?
It’s a terrible default. If someone gets a lot of e.g. bot registrations from Tor, they should have that option, but it’s really stupid for a static document site that cannot receive any interaction from the outside world.
Do you think it should scan and interpret all the content on all the pages it serves to decide which get Tor filtering? Or what’s your alternative implementation that achieves the same level of protection with the labor cost of adding some firewall rules? Gotta be something their management would agree with.
A more reasonable default would be to not show CAPTCHA until a POST request has happened.
Bam! There it is! That could be a great sell since they’d spend less resources on the CAPTCHA’s in the first place. Maybe (depends on implementation). I’ll try to remember and mention it when I run into Cloudfare employees. :)
It has no A or AAAA records. No MX record either.
Read it on the Wayback machine
It’s a domain just purchased for cheap, I guess this will be fixed soon if there ever is a bug.
Given how DNS works there might be different delays between the moment where the record is published and when it is made available.
Maybe it is a cache issue…
To accelerate domain changes:
From the users side, I use a local (dq) cache that points at the root servers, so I can flush my cache myself.
It does have A (and AAAA) records:
it just doesn’t respond to ANY queries by following RFC 8482
Now it does. When I tested, it wasn’t responding to either A, AAAA, or ANY.
There’s the ages-old ASCII Ribbon Campaign. One can sometimes find the ASCII ribbon in old postings in mailing list archives. I am sure the website at some time hold a message that said the ASCII ribbon campaign has ended and failed, but appearently somebody set it up again. The OP might consider linking to it.
Long live the ribbon!
This recommendation should be tempered by the golden rule of email of etiquette, which is pick a format and stick with it. The only style worse than top posting is when half of the people on a list are top posting and the other half are posting inline. This makes finding relevant information a massive pain and can confuse some email clients drastically. If the culture of your email list is to top post, then bite the bullet and do it, because trying to be the renegade will only lead to greater confusion.
That being said, if you’re the first to reply or setting a new precedent, then take this as a great and powerful opportunity to make a community of better netizens.
While I agree with what you wrote, I don’t get why bottom posting is encouraged? That ways the receiver first sees the quoted text, and only after scrolling down gets to read the actual content.
Does this answer your question? :)
Seriously though, I think it’s odd that people use bottom posting in forums like this one fluently, but find it so difficult in emails. I’m inclined to blame bad default behaviour of certain clients.
Bottom posting isn’t to be used indescriminately. You should delete any text from the original message which isn’t directly relevant to what you have to say, and interleave short quotes with short responses underneath. You can also just remove the original quote entirely if it’s not necessary.
Thing is, it’s just too much of a hassle for most people which is why we ended up with top posting.
OK, that I also agree with. But how is that related to top/bottom posting? Seems like the thing to encourage here is selective quotes, not top/bottom posting.
Bottom posting is not the opposite of top posting, despite what the name implies. The “selective quoting” style is generally known as bottom posting.
Interesting, thanks for clearing that up.
This somehow reminds me of naming things. ¯_(ツ)_/¯
Here’s your missing arm back: ¯\_(ツ)_/¯
Maybe useful: https://shru.gg/r
Thanks for the tip! Easy to break though: “¯\_(ツ)/¯ wait, why is this italic? oh, that’s better… but now my other arm is missing :/”
Oh hold on, do you mean that paste doesn’t work on Lobsters?
No, you just need an extra backslash:
¯\\\_(ツ)\_/¯Aha, okay, I’ll add that in. Thanks! Should be fixed in ~60s.
Oh wow! Nice, thanks.
That’s not my experience. At least in the communities I’ve participated in, bottom-posting describes the practise of not trimming the quoted mail at all, and is frowned upon.
Interesting that this understanding varies. Might I ask which communities you’re referring to?
In particular I think that’s the excepted interpretation in the Debian community. But from what I remember it was generally so on usenet too.
I think it would be better to try and justify the answer to this question. Why is a reference document different than an email? Two reasons immediately come to mind:
#1 sounds silly, but I think it’s the more compelling reason. In a short document, you feel less pain from the lack of adequate typography, and don’t need hyperlinks between sections. There are also good reasons why you would never want to send an email that is this long.
That’s a decent reason, but imho, neither immediately obvious, nor completely overwhelming. I think I estimate the gap between what’s good for documents and what’s good for email as much smaller than you do.
Edit: I meant to say that while I disagree with the overall claim, and I think the choice to brush off that objection weakened the piece, I really appreciate this article, for carefully stating the case for something that’s often a shibboleth.
It’s the same reason man pages are not plain text.
Rendered with nroff they are.
Yoda, the man page author.
That nroff outputs plain text, I meant.
Plain text that nroff outputs, meant I.
I agree there is something missing in the analysis. One problem with plain text (for either docs or e-mails, but mainly docs) is that I can’t specify proportional fonts for text and fixed width fonts for code.
That seems like a really minor feature, but it makes a big difference for readability IMO. (BTW this web page is very nicely designed, but I still think it could benefit from proportional fonts.)
I often switch my e-mails to plain text because there is no mixing of prose and code in them – i.e. this issue is moot. But most of my web pages have both prose and code, so I use HTML of course.
So for me it isn’t “e-mail vs. docs” but “prose-only vs prose + code”.
In fact there’s exactly one place in Oil’s docs where I don’t have proportional fonts, and that’s because I want INSTALL.txt to be primarily a plain text document. But honestly it sort of annoys me vs. the other docs on the site:
https://www.oilshell.org/release/0.7.pre1/doc/INSTALL.html
vs
https://www.oilshell.org/release/0.7.pre1/doc/osh-manual.html
edit: And of course I also like the hyperlinks in HTML, although when I write e-mails I’m fine just pasting in plain text URLs. I don’t make as much of an effort to make e-mails pretty.
So INSTALL.html is derived from a plain text document? You have some way to make the headers in the HTML document bold and large, so maybe you could use a similar approach to make the non-code prose variable width.
Yeah it’s actually just markdown, but I want to be primarily text. So I avoid the normal backtick syntax, because that would read funny from the terminal. Likewise for links.
But not for the headers and indents.
So I think it’s actually a good example of the tradeoff between text and markup. I almost always favor markup, except in this one case. It’s slightly deoptimized for the web, but I don’t think it matters very much.
Source: https://github.com/oilshell/oil/blob/master/INSTALL.txt
Doesn’t markdown treat paragraphs with a 4 space or 1 tab indent as code blocks?
My 1 cent:
My opinion:
The rest is not specific to HTML in emails so I don’t post it here…
No it doesn’t, it can just interpret a subset.
Good news!
I use Fastmail, which doesn’t support wrapping. I don’t think it’s a particularly good idea to wrap at 72 chars (it is a display preference so it should be a receiver-side matter), but on lists where that’s the norm I just compose the email in my text editor and use the reflow feature.
When you’re in the webmail editor in Fastmail and you’re in plain text mode, you can hit C-m to hard-wrap the email. When I get some time I’ll send a patch to the website to add this info.
As for
format=flowedthey said it wasn’t worth implementing 2 years ago, but things could change.And thanks to hard wraps, the e-mail will be harder to read on non-standard resolutions like in mobile phones.
I think the vast majority of the email clients mentioned on the website do hard wraps, no? The only alternative to hard wraps is
format=flowedAFAIK (tell me if I’m wrong) and, based on Fastmail’s 2 years-old blog post, it sounds like very few clients implement it?Yes, lots of software does hard wraps, but that doesn’t make it a good thing. I’m often using NeoMutt with Vim, but I specifically disable hard wraps, I’m enabling only soft wraps.
“soft wraps” is when the receiving client does text wrapping, just like any text editor, right? (i.e. the sender didn’t include any line returns in their paragraphs?). I’m confused as to why this isn’t the recommended default? (i.e. make people send email without line returns, and configure their client to do soft wrapping).
For example, the author of the plaintext.email website asks people to hard-wrap their emails when sending to sourcehut mailing lists, when it seems to me it would be vastly superior to let receiving clients do soft wrapping on the fly so that it works with any type of display width? Am I missing something?
If you’re missing anything, then I’m missing the same thing as well. I see no reason why the client shouldn’t be able to perform soft wrapping by its own.
Using 80x25 terminal? No problem, I’ll wrap the text for you to fit your current terminal. Using variable font width and a mobile phone? No problem, I’ll just wrap the text for you accordingly.
I mean, Lobste.rs comment box does soft wraps and there are no problems with that. I.e. I can’t imagine why anyone would want to enable hard wraps in Lobste.rs comment box? Similar to this, I don’t see why anyone would want to enable hard wraps in e-mails as well. If some software doesn’t support soft wrapping, it seems it’s a broken software, because vast majority of e-mail applications DO support soft-wraps.
One weak argument could be used that it’s more convenient to read text when it’s placed inside a column instead of spanned across large wide-screen monitor. But then you can just instruct your software to wrap the email to 80 characters and you’re done, no need to include CR/LF inside the e-mail. And if one’s software doesn’t support it, just resize the window and you’re done!
As for plaintext.email website, the author has lots of opinions that are directly opposite to mine, so I can’t really explain the rationale for most of the arguments :)
If you read a suitably nested comment thread on mobile, you end up with a word a line, then a few letters on a line. This would be a good reason to not infinitely soft wrap.
I just tried this and it works great, thank you for the information!
i’m not sure if this should be recognized by commenting here, as it feels outright like a troll attempt.
assuming this is a reaction to https://lobste.rs/s/ktvzwl/use_plaintext_email : asking users and giving directions to use plaintext isn’t “gatekeeping”. by using this word you apply a negative spin on the plaintext email site, maybe even on the author. i don’t want to see this kind of conversation here.
edit (after the archived version was linked here):
really? that low?
yes, that low. throw more dirt.
As far as I’m aware, according to the Fediverse feed of the author of “useplaintext.email”[1], the site sprang up as a response to people asking why - all of a sudden - they couldn’t contribute to the mailing list[2] in the IRC channel. This happened without any warning to any user or developer, and was solely at the whims of the individual who was now in charge of the mailing list software (and made the useplaintext.email website).
The individual who wrote that site locking people out from contributing to a Linux distribution because they came into control of the mailing lists does, however, probably qualify.
The submitter of this link actually orphaned all of their packages because going through the hassle of having a different email client just to contact the mailing list was not worth the hassle for what is ultimately a volunteer effort.
thats all well, but it doesn’t warrant “Request for Guillotine” and smear campaigns. dropping the packages is unfortunate, but if it feels that it is the right thing to do it’s a personal decision.
good alternatives are:
I personally did just that, and it was rejected. I also tried to offer a self-reply patch, and that was also denied:
Yeah, microblogging services are certainly not ideal. It’s been discussed at length in the IRC channels (which are the official communication medium for the project). I’ve seen discussions about lack of action after said discussions in places elsewhere. Namely, the person in control doubling down on leaving it disabled.
The mailing list software is developed by the same person who runs it. I believe this was raised and was responded to with a firm “no”.
No idea where anyone is at with that. I will point out this part from the site:
So I’m not sure there’s a consensus even there.
I don’t know if you can get more fringe than a fork of something like Alpine Linux. Perhaps forking Void Linux? Forking over issues that are surmountable with encouragement and a correct understanding (e.g., it’s inconvenient for developers who use mobile devices, it breaks screen readers (and consequently affects those with low or no vision), and provides no feedback to users if their emails are dropped) is, in my view, pointless. I personally feel forking a project is kind of a “last resort” sort of thing.
That said, I haven’t ever forked a project, so perhaps it isn’t. I’d appreciate your own view on that if you disagree.
Note: I haven’t been able to find the source for the Alpine Linux project lead quote, so it might as well be fake
i’m not involved in alpine linux, so i didn’t know about these discussions.
i see it this way: the developer has the spare resources to host the list, providing it for free to the alpine linux community. i don’t think that the community is forced by anyone to use it. if the majority decides the list software is fine, then that’s the consensus. of the project lead thinks it’s unacceptable, it is maybe time to look for an other place to host the list at. blaming someone giving out free things is just plain wrong.
my list was in increasing “drama-steps”, yes. forking almost always isn’t the right solution.
my point is that the reaction here (calling for beheading) isn’t a way to fix issues, it’s just flaming because something isn’t the way one wants it to. i know that it is hard today for many people if their points of view aren’t accepted as the only right one, but then it may be time for a fork instead of destructive behavior.
i neither, but there are “forks” of slackware for example, which mostly are additional package sets and tools though. forking doesn’t has to mean that you go completely different paths.
I’m only going to quote short parts, not to take them out of context but simply to make this thread easier to read as it gets further indented left.
Fair. Me neither, other than being in the IRC channels. I already have a bouncer on Freenode so I just idle in there. I use Alpine quite a bit for Docker so it’s nice to see what’s going on in there sometimes.
You raise a good point, however I take one small issue with this: This particular “feature” was never raised by the person who offered the hosting until after the transition had taken place. I can’t immediately think of a real-world analogy, but I imagine you don’t need one.
To offer to host the mailing list then lock out a portion of the user base until they fit your world view is, in my (in the big picture, unqualified and irrelevant) opinion, in pretty bad taste. This should have been raised as a condition prior to the implementation.
As to who is at fault for this, I wouldn’t be able to say. I don’t know if it’s unreasonable to assume that a mailing list software would not drop emails given undisclosed criteria.
Agreed, although based on context of the document one could infer that it was aimed at the practice of locking users out itself, given the first line being “Elitism-Free Working Group”. Thinking otherwise is uncomfortable in my opinion.
Very good point. Thank you.
i think that it just hasn’t occured to them that this would be a problem. i’d always assume plaintext on mailinglists, especially on lists of distributions etc. the lock-out was an unfortunate side effect of this. that the list shouldn’t just drop the mails but bounce them is a valid point though. “things just went wrong”, probably because of bad communication not bad intents.
i didn’t like this document because of linguistic tactics, it’s more-or-less authored anonymously, and full of ad hominem arguments. it’s bad taste and counterproductive.
Well beheadings rarely fix anything, but we can’t be sure until we try. What if the head grows back? I thought that website to be pretty funny anyway, but I guess YMMV. Maybe a satire tag would’ve helped. :)
If someone makes a website about how colonialism is cool, is it destructive to make the opposite website, or just discussion?
I wasn’t aware of that (I also wouldn’t be affected by it, being a TUI email user). That does seem like a harsh sudden requirement for continued participation/contribution in the project.
I presume this is partly triggered in reply to all the noise about the SuperHuman client….
Interesting point here…
Apparently Superhuman is an invitation-only Gmail front-end so something doesn’t match up….
I took a poke at some image rich email in my mail box…. and yes indeed, the images come from https://ci3.googleusercontent.com/proxy/
Very interestingly I can wget the images successfully. ie. WITHOUT my gmail credentials.
Have they encoded my credentials in the URL?
The cache control header is Cache-Control: max-age=300 so which is pretty short.
So is superhuman have some deal with gmail? Or is it using a public api on gmail?
A bit more experimentation reveals if you insert a picture from a web address, it assumes the pic is public anyway and doesn’t require credentials.
If you upload a pic, the url is so long wget barfs, (but curl seems to work) and replies “403 Forbidden”
u wot m8
This seems to be a response to use plaintext email
Ok. Didn’t see that thread go by…. and if you wade all the way down to the references it references that so you’re right.
Still SuperHuman seems to have defeated the proxying somehow (unless it doesn’t work it’s magic on gmail)
Gmail proxies the requests only when asked, so Superhuman still knows when the email was opened, but not the IP address of the person who opened it.
Aha! I think I have spotted a difference….
If the sender base64 encodes the email, gmail doesn’t proxy image urls!
(I noted this analysing an excellent phishing mail)
https://mikeindustries.com/blog/archive/2019/06/superhuman-is-spying-on-you
Ok, I think the original blogger overstated the capabilties wrt gmail and retracted that in a later post. With gmail it can see when opened, not location.
However it seems clear that for a number of other email clients out there you can see both, and even when you revisit.
I expect to see a few more “via email” replies to this post :^)
Anyhow, good stuff. I’d recommend neomutt (https://neomutt.org) over mutt, lots of great features already patched into it. It handles HTML emails just fine by piping them through w3m, with the ‘copiousoutput’ option in the mailcap making it display like any other email.
I’m not a huge fan of the whole concept of elitism (and its broad application to things where doing the “elite” thing is something quick and low effort like downloading a second free mail client and not, say, spending years earning a PhD) but suddenly introducing new requirements into a project that didn’t have them before, when even the project lead dislikes them, is pretty bad.
Being a contrarian can be very fun though :) So here’s my contrarian hot take: email is bad, just in general, the whole thing. Mailing lists: kill them with fire. More like failing lists!
Would you advocate NNTP instead? Protocol on top of JSON on top of HTTP that seems pretty popular these days?
GitHub. GitLab. Phabricator. Bugzilla. Forums. I’ll take fscking phpBB over a mailing list.
That means using things that are very complex on the inside, using very complex servers, complex formats, complex protocols, hard to get right, using a complex centralized security model, complex everything, and even complex wording on that sentence!
E-mail is not much better on complex side.
But I agree that when you take “it’s working” for granted, it actually feels smooth! Now you also rely on Google (for maintaining the web browser), Google (for Gmail), Google (for publishing the web standards), Microsoft (for GitHub), and Google (for choosing the crypto protocol to use through page-rank’ing higher pages using their favorite protocol du jour), then Google (for hosting the server) and Google (for developing the language the website is written in).
Feel free to replace the placeholder Google to whatever you want, you get a more realistic vision that is really not THAT catastrophic. After all, human rely on each other right? It’s not like running your mail server in your corner…
In the end, SMTP is not that good for spreading the news… What if you weren’t there when the conversation did start! You’ll have to fetch the archive for some HTTP (hey there you again!) mirror…
So. We need: something that feel as complete and smooth as phabricator, that is as trivial as SMTP (it’s really a simple protocol, MIME + old mailer daemon + weird mail client are to blame). Anyone here? (the sound of echo: here, here, he…)
Oh Hi IM2000! What are you doing all alone down that hill? You lost your smtpd? You don’t have an httpd? Come, I’ll take care of you…
The triviality is a huge factor in SMTP being overrun with spam.
I don’t care about protocols being trivial. Why should anyone?
Well, the mail submission process could be a lot more complex (encoded in XML RPC with requiring to start over HTTP, then switching off to websocket transmitting JSON), there would still be tools to send email, making as easy to call mail() in PHP.
So there would be as many plugin-pirated wordpress website spamming around as now.
While we are at designing things, why make it hard to implement? There is a limited amount of thing we can engineer, so adding complexith is reducing the amount of things we can build.
If downloading an HTTP page was as hard as cross-compiling GCC, would the web even exist?
Yeah, well, you know, that’s just, like, my opinion.
Is NNTP actually coming back? I would be completely on-board with this.
So, using domain names as if they’re Twitter hashtags is continuing, I see.
Again, there’s not a mention of Gmail and its malicious ways here.
That’s hilarious.
Anyway, I find it amusing this article is written without HTML, to counter that other one. Say, perhaps I should register a domain and participate in this dumbassery. It looks like an easy way to get attention, since everyone loves to share their opinions and personal preferences and it’s just technical enough for people to feel smart while discussing it. No, I won’t.
It’s way easier to remember “stop-gatekeeping.email” than “www.example.com/doc/wp/2019-07-24/stop-gatekeeping-email-6655321.html”.
You’re rude.
Use bookmarks!
What’s wrong with interesting domain names? No need to be an asshole about them.
I believe the issue is with using domain names as if they’re Twitter hashtags.
I read it more as contemptuous distaste than an “issue” per-se
That’s an issue.
The textual web should have stayed at HTML 2.0 – didn’t the WYSIWYG HTML editor of Netscape Navigator Gold produce clean code, that could have been a compromise for email, too?
Where are email- and web clients rendering text/markdown directly themselves?
I don’t remember how clean Gold’s was, but Composer 4.x didn’t validate properly.
Guess who had a job in 2009 converting 450 HTML files made with Composer 4.7 (that no HTML lib would touch due to validation errors) to a CMS? :D
I thought that I will see EFAIL somewhere in there.
Yes! That is not a PGP issue, that is a mail client issue.
Concretelly, its HTML mail issue.
It is not. It is issue with email clients that can’t correctly parse multipart/mixed content, and did not separate text/html parts from application/pkcs7-mime parts. HTML only allowed sending those contents out to the attacker. Without botched parsing there wouldn’t be any problems. But still, it is true that HTML allowed to exfiltrate the data.
The IRC discussion is archived at https://dev.alpinelinux.org/irclogs/%23alpine-devel-2019-07.log
2019-07-11 20:10:30 and 2019-07-24 10:36:31 seem related.
As to my current knowledge, community/tor is one of the affected packages.
It’s weird to see the word “gatekeeping” here. Usually gatekeeping involves patterns which make assumptions about the capabilities of the user, whereas in this case advocating for plaintext email is all about avoiding making assumptions about the capabilities and making allowances so that everyone can have access.
There’s a difference in advocating for plain text emails, or automatically rendering a plain text alternative in the mailing list processor (both of which would do that) and silently blocking every mail that comes as HTML (which prevents access by those with mail clients that are HTML only, like some versions of Google Mail)
There’s a large mail client that everyone seems to be ignoring here: iOS Mail.app.
The Mac OS X Mail.app can do plain-text only, but iOS can’t. No alternatives were given for iOS. I don’t want to have to buy an Android phone just to contribute to mailing list discussions while I’m travelling. (I have tried Android before and I didn’t enjoy it.)
Aren’t there alternative mail clients on iOS?
God, this is petty.
I must vehemently disagree. I’m afraid you’re putting the challenges of HTML email for client implementors, and the unsuitability for a software development workflow that many would consider archaic (emailing patches in the message body), ahead of a good user experience for everyone else. That’s putting the cart before the horse, isn’t it?
Consider links in particular. Do we really want to expose long, arcane URLs to end-users? I’m sure you’re used to it, because you use a TUI email client. But is that really the experience that we want for the whole world?
There’s also an accessibility angle here. Try reading a plain-text email with long URLs with a screen reader. Not a pleasant experience, is it? Sure, the user could shut up the speech, move past the URL, and keep reading. But still, proper inline links are a much better user experience.
I read the archived version, and it is so hilariously wrong. Quotes pulled out of nowhere, quoting yourself without any source and putting it like it’s not you saying it, and lines like this: “This phenomenon has been named “not being a contrarian” by the scientific community.”
I’d mitigate this with considering this as a gut reaction. That provoke a gut-gut-reaction in return on everyone.
An aside: The SVG is quite big and didn’t load directly, maybe compress it using https://github.com/svg/svgo
It’s pretty small actually, file size and image dimensions both. Are you doing something odd with your web browser?
Loading it was noticeably slow on my end, too, and I wouldn’t call 171 kB pretty small - not when a PNG version at the same resolution is ~14 kB, as converted by ImageMagick.
You’re right, I ran it through svgo and got it down to 80K.
What if you can’t because your client literally doesn’t let you? Demanding email in one form or another is extremely elitist.
There is info on email clients that support plaintext email in that page. Only two email clients don’t support sending plaintext emails at all: Afterlogic and Mailspring.
Exactly - the site explains why plaintext email is better for the end user in simple terms goes through most common mail clients to explain how to use plaintext email.
Furthermore, there are simple instructions on how to contribute if somethingvisn’t mentioned.
It’s not elitist - this is very much by the people, for the people, in the people’s interest.
If this was “by the people, for the people”, then the people involved (the contributors to Alpine Linux) probably should have been /asked/ first.
But then, the people have spoken, so I suppose this whole silly thing doesn’t matter any more.
To clarify, I wasn’t referring to the Alpine situation, simply to the site and its message. The Alpine situation is certainly different, if they didn’t know that HTML mail would be blocked.
Having said that, I don’t think that it should have been as much ofva surprise as some people are saying it was; Drew is very open aboutvhis views on the matter, and you’d have thought that at least a brief check of who they were dealing with would have been performed.
And the iOS Mail client.
There is nothing elitist in preventing big security risk. What do you miss ?
Which shouldn’t be an issue anyway because Unicode has an emoticon block.
Edit: looks like you removed that part, sorry
I don’t have anything against the end user (elitism). They are picking whatever matching their skillset or their neighbor use.
Now if you are in the middle of a technical discussion on a mailing list about the network, I’m okay with throwing away mail with broken encodings, mail with HTML, mail with a too large signature, …
It’s up to the community that build the mail stack to know what they are doing while proposing a TinyMCE-like in their webmail interface. I look at you Google.
A point that I think interesting : people using simple technology are elitist against people using crazy (google-scale) technology stacks provided for free and granted without maintenance. Are we not there touching to the core of some decaying hacker culture of working with your own tools ? But hate needs to not be mixed with it.
Now, Google does what the user asks for. Google also can mitigate most of the vulnerabilities that goes along with email because it’s Google.
My conclusion:
HTML comes to mail. Everyone on gmail. Google is big.
If I’m recalling correctly, I think that the author is incorrect about Apple Mail not wrapping automatically. It was my understanding that it breaks long lines (for plaintext only) during the sending process.
Otherwise, good post. I support 👍.
Can you send me an email with long lines to sir@cmpwn.com so I can re-evaluate it?
Will have to wait until I get home, but I’m very curious to find out so I will definitely sent you one ASAP.
Apple Mail user here. Mail.app doesn’t automatically wrap, but there’s a plugin, MailFlow, that does it: https://github.com/arachsys/mailflow
There’s also MailWrap, which provides slightly different features from MailFlow: https://github.com/arachsys/mailwrap
Thanks for debunking my bad information! My apologies to the author.
This is good netiquette advocacy and I support it. Now for the usual nitpicking:
I’m not really clear why this says that macOS Mail doesn’t support bottom posting - what’s the criteria?
I use it in plaintext mode, and I often use it to reply inline and edit the quoted text of a message. If you have a part selected when you hit “Reply”, it only quotes your selection, too, which can be handy.
Also, just for “fun” you might want to add an anti-recommendation for the Microsoft “Outlook Web App” which is not regular Outlook and does not support any kind of plain text. What’s worse, if you reply inline using a sane client, someone using the OWA will not see your reply text unless they know to click the little ellipsis and look through - all the lines will be the same color, but some will not have the quote mark.
But, if your email has the word “congratulations” it will animate confetti when you open it. Congratulations!
This is perfect! Still trying to find an email client for Ios which would only show plain-text versions, but don’t think one exists. :/
Relevant: https://lobste.rs/s/yhnrbu/stop_gatekeeping_email
Most web-based mail solutions seems to be business-oriented, unfortunately, so even if you have some support for plain-text, you lack basic associated features like ability to read and write mails using monospaced (or fixed-width, if you prefer) fonts. You’re basically forced to use your own CSS overriding vendor’s ones or go with some existing browser extensions doing it for you. Or run vim,
:set ft=mail, write mail,:%y, and paste it to your browser, if you don’t want to configure standalone e-mail client displaying monospaced fonts when reading and writing mails.I tried contacting Zoho Mail in the past to make them improve the situation. After generic response (“It would be much appreciated, if you could share more specific details on the issue you are facing, along with relevant screenshots, so that we could analyze and guide you accordingly.”), I expressed my displeasure that they ask for more details and screenshot, as it felt like they wanted to talk me out of continuing discussion, even though all necessary information were provided in my initial feedback. But in the end I provided screenshot of mockup showing current state (no monospaced font when reading/writing mails) and what would be desired to have (monospaced font used when reading/writing mails). I never received the response.
(For context, what’s the state in Zoho Mail: In Settings > Mail > Compose you can choose Courier as Font Family or specify system font you have, but if your Editor Mode is Plain Text, font options are not applied, they only change default font for Rich Text… And there are still no options for font used for reading. There is Font Family in General > System, but it affects whole zoho interface and there is no monospaced font to choose from, even if someone would be ok to have whole UI using it.)
Gmail is not better either… Personally I haven’t sent my feedback to them regarding lack of monospaced fonts for plain-text mails, but I suspect people did it in the past many times.
feeling like rip van winkle here.
JavaScript email anytime soon? No! Web ASM email, so you can ship a viewer along with the email.
https://en.wikipedia.org/wiki/Hiroo_Onoda
One could also see it as embodying the GB Shaw quotation: The reasonable man adapts himself to the world: the unreasonable one persists in trying to adapt the world to himself. Therefore all progress depends on the unreasonable man.
I want an email address @ this domain name.
One of the big qualms I have with work is the use of HTML email. Between organizations the reply chain can get really messy and hard to focus on what is being discussed.
All my personal correspondence is done in plaintext though.
Highly amusing to see Squirrelmail on the list of recommended clients, even though it hasn’t seen any action in the last 7 years. I remember poking at the code… let’s just say a very long time ago and wasn’t impressed with the code quality even back then. Who knows what vulnerabilities it’s riddled with at this point.
One of the most sensible and lightweight web mail clients that I know of is RoundCube. It doesn’t have much in the way of fancy features, just keeps its UI out of the way and lets you get your shit done. (And is actively maintained.)
Although no release since 2013, Squirrelmail does still have updates on the development branch and nightly builds, including CVE remediation.
For example:
https://sourceforge.net/p/squirrelmail/code/14829/
In fact I sent the details about Squirrelmail, with question “should we even add this, last release in 2013”, and Drew answered “Hey, at least one webmail that does everything correct by default”. So, while it is old, it is the only webmail that does what this website propagates.
I tried out mutt a few weeks ago. It was blazing fast and I was excited to be able to use powerful macros. However, there are many emails I get that I want to be in HTML - my company newsletter and film newsletters to be exact. The escape latch from text is not easy to use in mutt. It requires setting up a trigger to save the email to a file and open it in a browser. We have to acknowledge the reality and see that people do want to receive some emails in HTML.
I use
muttand here’s what I do: I have a .mailcap file with the following entries:Then within
mutt, if I’m reading an email I know is in HTML, I hit ‘v’, then select the HTML section and it launcheslynxwith the HTML portion. All other text types are handled bymuttdirectly.This does help with HTML-formatted mostly-text emails. But my point is that many emails I want to read have images in them and I want the full fidelity of a browser to read them.
I had previously tried: text/html; /usr/bin/google-chrome ‘%s’; test=test -n “$DISPLAY”;
I have the same problem as you: I subscribe to a bunch of newsletters about movies and comics and it’s kind of the point to receive an HTML email that can show you the pictures. I also tried mutt and was almost happy with it until I ran against the arcane knowledge of mailcap files and my inability to make a config that (1) works and (2) is cross-platform (since I’m using an obligatory dotfiles repository across my machines). I’d looooove for someone to write a tutorial for that kind of stuff.
Instead of viewing the HTML in a browser you can dump it into the pager:
muttrc: auto_view text/html alternative_order text/plain text/html
mailcap: text/html; links -assume-codepage utf8 -dump %s; copiousoutput