https://www-user.tu-chemnitz.de/~heha/email.en.htm
http://problemkaputt.de/email.htm
https://www.gaertner.de/~neitzel/email-to-mn.html
http://www.karo-electronics.de/448.html
...and of course there's this:
>Hotmail is typically deleting all emails that I am sending. ... Monopolists like gmail.com won't accept any messages sent from my mail server.
The main caveat is that you will have a very hard time getting your email accepted if it comes from a home connection IP range instead of some host provider but if you do have a dedicated server and follow the guidelines (SMTPS, DKIM, SPF etc...) it just works, at least in my experience.
It seems weird to me to have to find out the preferred way of communication to this level of detail, I already loathe that one cient of mine that only uses Facebook messenger for all communication.
In work I have to accept whatever my colleagues, clients and bosses will send me. For personal communication I use mail with two people. And services that let you choose whether they'll send you plain text are practically inexistent.
For emails sent by an evil client that doesn't provide a plain text version, you can consider a tool that attempts to convert HTML to plain text (though I don't have a suggestion for this yet). Fall back on reading the HTML version only if the above fail.
- experience from working on / using my own mutt-like terminal email client.
I'd argue in most cases you really don't need any fancy styles and markup. Although upon writing this I'm now wondering if unstyled HTML might provide improved accessibility over plaintext. What are people's experiences on the matter?
Although I respect that some people may find greater value in carefully styled marketing emails, to me it just feels a bit overengineered at times. How many man-hours have been spent trying to get marketing emails to look the same across all major clients? Are slight variations really such a horrible thing?
As we're on the subject, I'll add the following suggestion to gmail users: go to Settings and changing the Images option to "Ask before displaying external images". External images are regularly abused to track if the email has been viewed, which I consider creepy.
In this case, things like a marketing email or simply the follow-up email to signing up to some service provide that signal since the user can see how much effort was invested in making the communication look attractive.
My understanding was that external images are automatically fetched and cached on their servers by Google, so they can't be reliably used to track message views [1]. Has this changed?
[1] https://gmail.googleblog.com/2013/12/images-now-showing.html
It will still prevent the sender from setting cookies for you, or learning your IP and user agent.
I can confirm that every time you open email, open is get tracked. (what is not get tracked is your IP/OS/etc)
So in fact Gmail made online marketers job easier.
Yep. Email formatted for 65 to 78 monospaced characters with hard carriage returns (as per *nix mailing lists) look much worse on devices that are narrower or wider than this. HTML paragraphs don't have the problem.
Text-only emails can and will still contain links, which users will still click on. Misleading domain names will work just as well in the email body as they do in the address bar. Even if (as this article seems to imply should be done) mail clients don't make the links clickable, users will still copy-paste them. (Not to mention that the usability benefits of making links clickable are significant enough that mail clients won't forgo them just for a speculative hypothetical security benefit.)
The authors seem to think that inserting a "speed bump" here will cause users to pay closer attention and not be fooled. This is not how humans work, especially very busy humans who get too much email and just want to get through it as quickly as possible.
Also, the reference to JavaScript in email leads me to question whether the authors have any idea what they're talking about. Mail clients don't execute JavaScript.
The quote from US-CERT isn't "meaningful"?
FWIW, I'm the first to bitch about security experts that sacrifice usability in the name of security any day, but for once I completely agree with them.
> Also, the reference to JavaScript in email leads me to question whether the authors have any idea what they're talking about. Mail clients don't execute JavaScript.
https://stackoverflow.com/questions/3054315/is-javascript-su...
And that's only until someone finds a way to make them execute Javascript anyway. I don't think it ever actually happened, but not using an HTML engine drastically reduces the attack surface for sure.
...that brings up the other elephant in the room: Unicode. More specifically, https://en.wikipedia.org/wiki/IDN_homograph_attack
The 0/O/i/1/l/I distinction is a classic one that can be somewhat mitigated by good font choice (plaintext emails are often presented in monospace, so that helps a little), but some of the other sets of Unicode characters are designed to look identical to ones in the ASCII range, often using the exact same glyphs.
For those who use non-English characters exclusively, it is not possible to use ASCII only emails, but non-Unicode encodings are still helpful in this situation --- e.g. the Cyrillic characters most known for IDN homograph attacks aren't even encodable in 8859-1 or Shift-JIS.
Speaking of JavaScript in e-mail, gmail doesn't allow you to send or receive .js files (even tarred up), which is somewhat inconvenient, and I'm not really sure what attack that prevents. Maybe there is a mail client out there that will happily execute attached js?
The attack prevented is simply having the user open the attachment, allowing the sender to execute arbitrary JavaScript on their machine in the file:// context. (Modern browsers have made the security consequences of this somewhat less dire than they once were, but it's still not something you want to do if you can help it.)
Maybe not on purpose, but EmailPrivacyTester.com has found several clients in the past (usually webmail) which do.
Admittedly this requires a level of knowledge that the average user may be missing. But I find it really helps inform my opinion of any borderline-suspicious emails.
I switched to a text only email client a few months back. I really don't think I am missing anything. HTML content tends to be chaff/advertising.
The MUA could strip out any HTML embedded in the actual markdown, render to HTML locally (for display) and you have nice formatting without the risks or cruft of email HTML.
And of course if you choose to view in text only mode, you don't actually lose any semantic meaning.
https://stackoverflow.com/a/25812177
https://tools.ietf.org/html/rfc7763
https://tools.ietf.org/html/rfc7764
(March 2016)
Previous HN discussion: https://news.ycombinator.com/item?id=13176743
Just because they used to be called MIME types and were designed for email, I wouldn't treat those RFC's as being about email support specifically.
Here's the entry that I wrote about it (includes my mutt config): https://smalldata.tech/blog/2016/09/10/gmail-with-mutt
The mail client is a web browser. In many cases it's an actual web app in an actual web browser. The solution has to be to make them safer for the user. Maybe a subset of html can be whitelisted, maybe link targets should be rendered more clearly, maybe something else.
If the user wants safety, switching to plaintext is a very wide step forward.
Is that representative? Where do you get email from? Did you change preferences on things like mailing lists in order to get to that percentage?
Also: what kind of client do you use? iOS mail does send plain text emails as text/plain (which is fantastic) but if you look at e.g. inbox (gmail) it doesn't even allow sending plain text emails as far as I'm aware.
I think one thing that is not being considered is that for most customers, branding and the consistency thereof are key indicators of trustworthiness - especially when dealing with financial information. HN users are rare creatures, they have technical context the average end user does not have. The rise of phishing has lead users to pay a great amount of attention to subtle hints of impropriety, like being taken from one sort of visual experience to a vastly different one. We saw vast improvement across all meaningful metrics when we switched from plain text to HTML emails that utilized branding consistent with our website.
As with everything that humans deal with, there are tradeoffs here. And I'm extremely concerned that this position taken to it's logical extreme would lead to the web being transformed into something that is "safer" but much less useful and dynamic. One outcome of this could be the slow death of the open web in favor of siloed networks and platforms serving actually functional content in "safe" ways.
You could maybe see banks having plaintext communication as an optional, but I doubt they'd make it default (allowing users to switch to html).
Isn't this problem already solved with certificates online? Shouldn't this be solvable the same way? E.g. a bank sends an email containing a link to the content with some special attribute. The web browser displays the content if and only if the sender domain of the email (e.g. hsbc.com) is also the domain from which the content will be downloaded.
First...
1. In the menu, go: Mail > Preferences > Viewing.
2. Uncheck "Load remote content in messages".
3. Move to the "Composing" tab.
4. Select "Plain Text" for Message Format.
5. Uncheck "Use the same message format as the original message".
Second...
In Terminal, copy/paste this command to set plain-text preference to true:
defaults write com.apple.mail PreferPlainText -bool true
I've found a quick tell if someone uses Outlook is if I send them a text/plain message, they'll send one back and there's no format=flowed. At that point I'll usually send them HTML mail.
A good example is a newsletter from say, Quora or Medium; Newsletters usually have links to a story or a news feed article. If this was done using plain text, the link would be one long mashup of characters, because they usually include an authentication token or something like that. In this case, using an html link or button is clearly the better option.
HTML is like structured text for web pages.
Well, that's a yet more hostile thing that one has to put up with. I follow news through newsletters, and I'd prefer they were in plain text and with normal links. My reader knows how to wrap lines and make link-like things in plain text clickable. But unfortunately if I wanted to enforce that I'd have to avoid news...
So keep the main headers text-only as well (which most sane software does anyway).
I sometimes wonder how long it's going to stay. My guess is: until the end of the internet.