The only safe email is text-only email
theconversation.com
theconversation.com
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:
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.
>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.
You can always get it unlisted.
After that don't start to send hundred of email by day. You need to build a reputation for your domain and ip.
As the parent comment says, set up directly spf, dkim and dmarc (also arc if you can). Rspamd can help you do that.
I've been running a personal mail server for 5 years with simply following those rules.
As I said, it's totally opaque crapshot.
I'd recommend trying http://dkimvalidator.com/ to make sure everything is perfect; having proper certs on your MXs seems to help too.
I run a pretty large email infra (~500k/minute) and I'd help you out if I can...
If you're still having problems with all that in place then why don't you just change IPs?
As for your help offer, thank you, but I'm good. It's usually other people who want to contact me, I rarely send the first message ever.
I mean.. If you get a solid result from dkimvalidator but google is still shitlisting you then I'd definitely consider moving to another host/dc/isp at least.
Depending on your size, it might be best just to make this someone else's problem (if you can) -- like google, o365, etc..
I'm working on a guide for setting this stuff up; still WIP [1] -- feedback appreciated!
1: https://medium.com/@cyberpunk_networks/nsa-proof-your-email-...
Does this not happen when you send your emails to someone else? Mad props if everyone you email uses encryption!
Maybe it's worse for non-English mail (maybe the statistical models are biased against "not English" even for people whom don't have English as a native language).
But I'm quite convinced google's (and to a lesser extent Hotmail/ms') "magic" spamfiltering is subtly (but annoyingly) broken.
Why does Gmail hate my domain? | https://news.ycombinator.com/item?id=9855030
How to Avoid Spam Filters | https://news.ycombinator.com/item?id=10465639
Hotmail | https://news.ycombinator.com/item?id=14210939
ESP | https://news.ycombinator.com/item?id=14201704
If there are others I'd appreciate a link as I try to connect them!
My current ISP, a local fiber provider, was not great getting going. Most of the IPs that they have are in at least 1 spam database, and it took a while for the ISP to reach out to the database maintainers themselves. Even then, since they're a small ISP, the IPs are still blacklisted. The ISP wasn't even a company when the IPs were added to these blacklists.
After a few months they were able to assign me an IP that wasn't in a blacklist somewhere. I still randomly have issues with the big providers though - gmail is probably the most annoying. Like dozzie, my SPF, DKIM, and DMARC setups are all valid.
Overall, I really enjoying running my own mail server. Every now and then there are a few annoyances, but it's worth it in the long run.
How do you do that? The vast majority of blocklists I've interacted with have been unwilling to deal with questions, instead responding only that if you fix "something" (not always specified) automated measures will remove it from the list eventually.
In my experience it has also been extremely difficult to deal with people using blocklists. It's easy to find a bunch of people using .tor.dan.me.uk rather than .torexit.dan.me.uk "just to be safe". Frankly, I'm not sure why the former list exists in the first place other than to be an arse? What threats do entry/relay nodes pose to you?
Whenever one of our mailer IPs was blacklisted by one of the big targets (hotmail, gmail, etc) it would only be for 24hours after which I'd put it back into the pools (although, at least initially perhaps for our more reputable clients to warm it back up before letting the more dodgy stuff through it again). If you host your own NS's for the sender domains flipping SPF ips/ranges is not too hard (it's all automated for us, anyway).
The big boys work that way at least in my experience. I'm sure sometimes you'd hit a 'somedomain.foo' domain which is using a blocklist style thing that their (usually inexperienced) sysadmins think prevents them from receiving spam; but they're not worth arguing with. If you're doing email at volume shifting sends to another range for that client is usually 'enough' to get them through if they care that much about that one segment to ask you to do it.
If it's not then we'd usually refund instead of trying to negotiate with such admins.
Honestly though, blacklists have never been an issue for me and I've sent a ridiculous amount of email over the last 10 years...
If neither of these tools highlight any issues it's pretty strange indeed.
This way, fewer people start email servers and, therefore, fewer potential competitors grow up.
Obviously I have no way to tell whether Google really does this, but if they would, the result would look exactly like this HN thread.
I'm probably totally wrong here, but note that there is absolutely no incentive for the large email providers to try to fix this mess and make email the free distributed network it once was.
I've been removed for now from their lists... but they tend to re-add IPs from previous ranges for no reason.
X-Hashcash: 0:030626:adam@cypherspace.org:6470e06d773e05a8
You can choose how much work you want to do and the recepient can specify thresholds for minimum work required. This header is all they have to store, and it's easily stored through existing email infrastructure. Your mail server can do it without your client's help, too. If you spent a second on a proof I'm sure grandma wouldn't notice, but it would be very difficult for spammers to do the same.
For one, it'll only work if both sender and receiver use it. Which means for 99.99% of mail traffic right now, it is utterly meaningless.
edit: Plus you also literally wasted everyone's time and energy.
I'd rather favor some kind of mechanism like grey-lists that don't require sender opt-in otherwise it'll be a dead technology just like GPG. (You can probably count the number of GPG emails within 1000 average mails on one hand)
I severely doubt any big player picks it up on grounds of it being cheaper and less energy intensive to simply greylist or blacklist.
Anyway, I agree on the waste of time+energy.
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 use emacs to read my email, and w3m to render HTML email as text. It does a good job. Newer emacs includes its own web browser (eww) but I have not tried it for HTML email rendering since I'm happy with w3m.
Replies always go out in plain text (my preference) but if you want to send HTML there are ways to e.g. write your email in org-mode markup and have it converted to HTML when you send. But IMO if you want to send "rich" email then just use a client that does that natively.
I have this as my .mailcap and it Just Works (TM) with mutt:
text/html; elinks -dump %s; nametemplate=%s.html; copiousoutput> text/html; iconv -f %{charset} -t UTF-8 | pandoc -f html -t plain --wrap=preserve; copiousoutput; nametemplate=%s.html; description="HTML eMail";
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.
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.)
https://news.ycombinator.com/item?id=7678729
If an increasing number of users aren't, then that is certainly a problem.
Which is already too late for anyone compromised by a drive-by download attack.
I think you missed my point. What if it isn't a phishing attack? Or even, what if it isn't just a phishing attack?
Your suggestion leaves users vulnerable by encouraging them to open suspicious looking links on the off chance it is, at most, a phishing attack.
> Browsers have a much greater ability to mitigate those.
Except when they don't. For what it's worth, I've also seen mobiles fall victim to drive-by download attacks.
> Also, a drive-by download email doesn't have to impersonate any particular sender, it just has to look like something that a user might want to click on.
E-mail worms are spread by the trust relationship between people known to each other (ie a user opening an attachment because it's from a recipient they know). I don't see why drive-by download attacks couldn't exploit the same human condition (ie "Hey bob, check out this link. It's awesome").
In fact I have seen that kind of malware in the wild, now I think about it.
You can create a misleading tooltip in HTML: <a href="https://www.megabank.com.phishingattempt.io" title="https://www.megabank.com">https://www.megabank.com</a>. But since modern browsers don't use tooltips to indicate link targets, users probably won't be looking there in the first place.
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.
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.
"See my comments in blue", strikethroughs, inline diagrams, bullet points, big red font for emphasis.
Of course that should all be done in a dedicated application, but who is going to provision and authorise users for that versus just adding Bob to the cc line and giving him implicit editing capabilities?
The functional overloading of corporate e-mail is a user-driven reaction to the awfulness of most " collaborative' software.
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.
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.
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.
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 that might be possible in the "old" gmail, I was referring to their newer "Inbox by gmail" client. I believe it never sends a text/plain email regardless of content (And it being their "newer" revamped client kind of shows what googles take on this is...)
Not that this surprises me in the least :-)
Perhaps once a month, maybe less, I have to use the toolbar button "Show HTML Temp" to do a one-off rendering of an email as basic HTML. Almost always the same offenders.
I find it such a success that I recommend it to my customers - none of which are computer experts, and most are not what I'd call "computer savvy". A process has to meet a high bar for me to recommend something like this to my customers.
Shame that when I explain how it can help in improving one's security that a vanishingly-small number of customers take me up on the offer!
If I asked 100 friends "did you use email today" 99 would say yes. If I said "did you do it on a computer" then 50 would say yes (those that work at an office). If I said "was it your own computer" then maybe 1 would say yes.
I think for us that sit at our own computers regularly, it's hard to imagine just how extremely rare it is for people to actually use desktop/laptops for personal use these days.
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.