Slashdot Mirror
The Only Safe Email is Text-Only Email (theconversation.com)
Sergey Bratus, Research Associate Professor of Computer Science, Dartmouth College, and Anna Shubina, Post-doctoral Associate in Computer Science, Dartmouth College write: The real issue is that today's web-based email systems are electronic minefields filled with demands and enticements to click and engage in an increasingly responsive and interactive online experience. It's not just Gmail, Yahoo mail and similar services: Desktop-computer-based email programs like Outlook display messages in the same unsafe way. Simply put, safe email is plain-text email -- showing only the plain words of the message exactly as they arrived, without embedded links or images. Webmail is convenient for advertisers (and lets you write good-looking emails with images and nice fonts), but carries with it unnecessary -- and serious -- danger, because a webpage (or an email) can easily show one thing but do another. Returning email to its origins in plain text may seem radical, but it provides radically better security. Even the federal government's top cybersecurity experts have come to the startling, but important, conclusion that any person, organization or government serious about web security should return to plain-text email (PDF).
When you try to sound sincere but link to a PDF!
"...should return to plain-text email (PDF)."
That's hilarious.
We all know that embedded codes for dynamic engines in your OS or even the program reading the messages is just an invitation for trouble.
Microsoft lead the with with VB.Script in Outlook. ("I luv you" too...), then as marketing people wanted to decorate with fancy email signatures we started embedding HTML/Javascript, leading to clever tracking on web servers and javascript routines. The worst part is the default for email clients and web client is all HTML/Javascript.
We need the default on all email stuff to be text only for our own protection as well as the general health of cyberspace.
"Imagination is more important than knowledge" - Einstein
So we should go back to Text-Only email for security reasons, and more information can be found in this totally safe PDF?
She: Hey, are you a traitor? Me: No, I'm atheist.
I've always configured all my email clients to not autodownload linked images unless I specifically want them. This blocks trackers and such, but if people start embedding javascript in email, then that doesn't help much.
The Rich Text Format from back in the 20th century does not support macros and there are no known exploits for it in the last 18 years. The only time people run into issues is when a Microsoft Word document (.doc or .docx) is renamed to .rtf and loaded erroneously. But with e-mail the MIME types and integrated viewer and editor would avoid that file extension hole. (that same hole would exist for .txt if MS Office were the default program for that extension, mostly that's just Office being terrible)
Theoretically a safe subset of HTML is possible, but nobody wants to maintain some subset parser with no standard. (standard might be as simple as HTML3.2 without JavaScript or IMG tags to external sites). Perhaps W3C or others should create an HTML profile for safe email.
Myself I'd rather have the sender render and encode a highresolution bitmap file which compresses bilevel images very well allowing for high resolution (like DjVu format). And tag the image with a plain-text section for screen readers, search and OCR to deal with. You get perfect typesetting and good illustration for your email, with far less complexity of dealing with HTML or RTF layout, font differences between systems, etc. (again my example sucks because nobody standardized it)
“Common sense is not so common.” — Voltaire
Been reconfiguring my email and web clients to send text only and not to display or download images. Fun at corporate when I don't see folks idiot corporate icons and backgrounds. Heck, I seldom click on attachments from others in the company (certainly not from external sources) for a couple of hours at minimum. I already know my boss doesn't love me :)
A couple of years back, corporate came out with a standard signature block with html, images, and links. I kicked back with a request for a text only signature block due to various issues with how we manage servers plus provided a link to the Usenet RFC for signatures. They responded with an updated standard that included a text based block with dashdashspace (-- ) :)
[John]
Shit better not happen!
is ASCII.
Also: go ahead, explain to me why it is that my computer needs to have a turd glyph stored on it.
Because Stargates can't connect without a point of origin.
Anyone having deja vu? I used to work on a dumb terminal hooked up to a large Sun serve. My email was text only Alpine. After years of fancy new computers and email systems, what are many IT directors going towards? A central VMware server, dumb terminals, and text based email.
We've known this for many years. It's why the first thing I do with any mailreader is disable HTML.
Email my mother a plain text email that says "Your Adobe Flash is out of date, copy this link into your browser to update it" and she's probably going to do it. The only safe computer for her is something like a commodore 64 without internet access.
Do you have ESP?
The folks at Dartmouth may well be correct in that plaintext e-mail is safest. However, does that really make it the best solution anymore?
Look, I've got "that secretary" who uses borderline-illegible script fonts on stationery and ConstantContact blasts annoy me, as well. HTML mail does indeed have its downside and I don't disagree that it opens up at least some amount of security holes.
At the same time, plaintext e-mail has its faults, too. The color separation makes it clear when you've cleared the 'new message' in the thread, as does the stylized header. Inline image embedding is abused by marketers, but it makes it far easier to send tutorials or support requests via screenshot sequences. Yes, clickable links are a security risk, but that's how password reset e-mails work now. Do you really expect users to copy the complete URL into the address bar without an issue? If there's a line break in there, you're really screwed.
All of that hasn't even begun to address attachments, because technically it is possible for mail attachments to count as both a part of plaintext e-mails and not. Attachments are a mess, but we've stopped allowing people to e-mail executable files, for the most part. The attachment file types themselves, however, are a mess. Outlook cries wolf at *every* attachment, which makes it "the dialog box to ignore" - itself a UI problem of its own faults. The fact that the last few ransomware attacks I took care of were sourced from a malicious ActiveX payload on a Word document is only as stupid as the fact that there is still a whole lot of software that depends on ActiveX and Macros to function. If Microsoft is too easy a target, then Adobe has some splanin' to do when it comes to the fact that javascript can be embedded into a PDF. I've only seen it ever legitimately used for calculations and validations; is it really that hard to have a dedicated software function for that? The list of such issues is quite extensive, but I think my case on this point is made.
Ultimately, the fact that HTML mail is as ubiquitous as it is has to do with the fact that e-mail as it was originally designed (plaintext, 80x25) is no longer meeting the needs of most people who use it. However, its extensibility is amongst the reasons why e-mail is still as heavily used as it is, long after its contemporaries (IRC, Usenet, others) have faded into niche roles while e-mail is still mainstream.
Meanwhile, most free e-mail providers are pretty good at filtering malicious e-mails, spam filters for on-prem mail filters have reached a pretty good level of maturity, so there are plenty of safeguards in place that have brought the danger down significantly, to the point where e-mail is one piece of the vector rather than the vector itself, and has been for some time.
I pose this question to the Slashdotters who agree with the Dartmouth researchers: Whenever sweeping legislation or military action comes up around here, a post based on Ben Franklin's thoughts regarding trading liberty for security are almost invariably stated, and frequently modded up to a +4 or +5. Now that the "liberty for security" question is on the other foot, when we're discussing trading liberty (more useful e-mail) for security, why does the mindset seem to be flipped? I'm not saying free-for-all e-mail with no spam filters or blacklists are ideal, but I am saying that for all of the ways that e-mail gets abused, it's gotten to the point where it is all but guaranteed to prompt the user before causing trouble, if it gets through the IP blacklists, keyword blacklists, attachment filters, virus scanners, default mail client settings, attachment warnings, application warnings, and UAC prompts...I doubt plaintext would have solved the issue in itself. To champion a function regression in the name of 'security' sounds like the kind of mindset which, according to Franklin, deserves neither liberty nor security.
I use Thunderbird and POP3, view my messages in Plain Text, have Javascript and all plugins disabled -- for those cases where I have to view the message body as HTML because (for some reason) nothing (or not everything) displays in Plain Text mode (which annoys me to no end, anyone have a workaround?).
I'm confident that I'm not missing out on anything by viewing in Plain Text, 'cause it's freaking email, not art.
It must have been something you assimilated. . . .
Sure, I had to make one concession to the ASCII-challenged, I now filter HTML through lynx as more and more people do not even understand a request for "non-HTML" email these days, but that is it. With very rare exceptions this is entirely enough for email.
Most ACs are not even worth the keystrokes to insult them. Be generically insulted by this and ignored otherwise.
An email format which is well-defined, simple enough for most experts to understand completely, and which has no homoglyphs or other situations that can fool the eye, can be safe.
Well-defined means the is no undefined behavior in the specification. Well-defined also pretty much guarantees that the email cannot result in "open ended" behavior beyond the bare necessities, such as saving a file or printing it, or possibly launching a sandboxed application that is in a separate sandbox from the web browser.
Simple enough for most experts to understand means it's less likely that an email client will have bugs exploitable by a poisoned email.
Not having situations that can fool the eye rules out using colors that are visually similar, fonts that are visually similar, and fonts with very similar characters, and the like. However, it does not prohibit using simple markup languages which have features such as "bold" as long as those behaviors are well-defined in the specification. It does not restrict you to "ASCII" or "UTF-8" or to specific fonts, but it would prohibit fonts or combinations of fonts that show characters similarly. For example, in ASCII, some fonts display 0 and O as nearly identical, or l and 1 as nearly identical. Those fonts should be prohibited in any "safe" email specification, as they make social engineering much easier: "Hey Joe, copy and paste into your web browser to go to 'http://www.notevi1site.example.com' where the font makes it look like 'http://www.notevilsite.example.com'" might fool someone into thinking it was not evil when it is.
A safe email specification can even provide for "safe" pictures. It can allow pictures in certain formats provided the picture format is itself a "safe" format and client clearly indicates to the user they are pictures rather than text.
Out of necessity, any practical email standard should provide for "somewhat safe" method of handling file attachments. One way is to require the client only save the files in a "containerized" file format (e.g. mime/.eml, uuencode, zip, etc.), ready to be scrubbed by security software, which will be responsible for declaring it "safe" before saving the file in its final form. This is a compromise of course, as no security software is perfect and "one size does not fit all" for security. Malware researchers may NEED to exchange samples of live malware, but everyone else should have such files flagged and deleted before they can gain a foothold.
Knowledge is how to play a game, intelligence is how to win, wisdom is knowing what game to play.
Only fanbois care about this
I don't read your sig. Why are you reading mine?
advertisers are doing me a favor by sending emails crammed full of tracking images. It is so easy to send these kinds of emails to the junk folder with a simple filter.
If I could filter my physical mail based on the color and texture of the paper I would cut out most of the junk mail. (and maybe toss out some of the semi-junk correspondence from businesses I use, hardly a flaw in this plan)
But really, I don't think it is a valid to argue on what Email was "intended" for when it's changed so much in the four decades. The users ultimately get to determine what Email is really for and how it should be used, and not the long retired designers. Unfortunately "users" includes spammers, who exert more influence on how Email is used than they deserve.
“Common sense is not so common.” — Voltaire
I have no problem rendering unicode on my terminals. Unicode doesn't have to do with text/binary. It has to do with font support. Either you need a console font that supports the code points you use or whatever set of X/gui fonts for your graphical terminals.
As an example of this, I just downloaded Homer's Iliad and Odyssey in the original greek encoded as UTF-8. I can edit the files in vim just fine and dumping them to my terminal works as well. You can pull one up here:
http://carbon.cc/~jhord/Homer/...
If that works you have plain-text unicode support in your browser.
Rendering plain text email is so much simpler and uses so much less CPU time/power that it could easily have a measurable effect on the global warming.
And the only safe encoding is ASCII.
Then you go back to the dark days of code pages, which was its own headache, especially with eastern languages.
It wouldn't be difficult to have a program highlight text that comes from another Unicode alphanumeric language block than your own. That way if someone tries to use similar looking characters, you'd have some notice. Also, it wouldn't be difficult to blacklist Unicode blocks, like the ones used for symbols. That would eliminate the emoticon issue.
Email needs to be 'notify and pull' not 'push'.
My mail server should be deciding if it wants to accept mail, and it should require an outbound connection attempt using DNS to do so. Spoofed sender addresses won't work so well if my server can't look up the domain MX record, or if the listed mail server doesn't know anything about the email I think it has for me.
Just that basic change would kill a lot of crap right off the bat.
Perfectly safe:
X5O!P%@AP[4\PZX54(P^)7CC)7}$EICAR-STANDARD-ANTIVIRUS-TEST-FILE!$H+H*
Anatomy of the EICAR Antivirus Test File--this is actually an interesting read.
Well, what about unicode?
The biggest unicode concern I know about is spoofing. With text messages I guess you'd have the risk that people will respond to an email address that isn't who they think it is, or copy and paste a URL that doesn't take them where they expect to go. This vulnerability isn't any worse with text rather than HTML mail.
Post may contain irony: discontinue use if experiencing mood swings, nausea or elevated blood pressure.
I used to manage an email server and mailing list back in the 1990s. The MBOX format most text-based email programs used for storing mail uses two carriage returns and a "From " at the beginning of the next line as the deliminator for a new mail. That's it.
Occasionally people would send an email to the list which randomly had two blank lines followed by "From " as the first word of the next line. If your (text-based) email client wasn't smart to look at subsequent lines to determine that the person had just randomly typed it in the body of the email rather than the actual start of a new email, it would display it as if it was a new email message.
One day someone sent an email to the mailing list which deliberately abused this. The body was crafted so that the "From" in it and subsequent text was formatted like it was a real, separate email. And the people whose clients interpreted it as a new email got duped into thinking the mail list admin had banned them from the mailing list for inappropriate remarks. The perp was just playing a joke of course, but I shudder to think what modern spammers and phishers would do with that capability.