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.
What about spoofing and social engineering?
is ASCII.
Also: go ahead, explain to me why it is that my computer needs to have a turd glyph stored on it.
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.
Oh yeah! Mutt all the way, baby!
It's on by default, not just for the "market" but for users too, because we need to be able to see emojis and an image macro of a "minion" who doesn't like Mondays.
LessthansymbolSarcasmclosetagGreaterthansymbol
Exceptions don't make the rule, rendering email should be a toggle for the cases you need it. If any. An "always on" opt-in would be fine, user-elected consequences. If you're scared of people asking where the emoji are, just have one of those "Media content detected, may not render in safety-mode, click here to change?" or whatever float above.
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!
Yes, this is nearly correct. The only safe and secure email is encrypted text. Unfortunately, knowing the right answer and getting the population of the entire world to make the change are two entirely different things.
Thanks, Microsoft. Thanks, Apple. Thanks, Yahoo. Thanks, Google. There was once a time when computers were the coolest thing. They offered promise and potential, the same way a blank easel appeals to an artist. But then you guys came along and ruined everything. It isn't just email.
img=old-man-yells-at-cloud.png
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.
Because they're editors, not reporters. They expect others to do the actual reporting and submission, so they can "edit" the status from "submitted" to "posted" or "rejected".
APK quotes people (including myself) without context and should not be trusted. Just thought you should know.
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. . . .
The images for DjVu are typically scanned at 300-1200 DPI. Which is higher than your 8K monitor. So your A4 sheet of paper is probably 50% bigger on your 8K display than it would be in real life, you might want to scale it down a little bit to read it if you are close to your screen. There is enough information that you can scale up the bitmap pretty comfortably as well. Of course on a phone it would be downscale pretty significantly.
The main limitation to a bitmap format or really any typeset format is text reflow. The closest equivalent would be PDF, you usually are stuck with however the author chose to form the PDF file. The font sizes, the layout (1 column? 2 column? landscape?). But we had this limitation for hundreds of years using physical correspondence and it wasn't too big of a deal until recently.
Plain-text is the lowest common denominator and I can see the point of the article. But it's not hard to imagine solutions to the problem that are both relatively simple and more expressive than ASCII/UTF-8. Obviously we should discard any sort of e-mail standard (de factor or official) that is inherently insecure.
“Common sense is not so common.” — Voltaire
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?
though text base, I never was concerned about viruses. Problem I experienced was using my actual email address instead of creating "knownothing@nospam.com" then wonder why am I getting so much spam. But then the jpg images were just that, images. No hidden code within. Had lots of fun reading interesting stuff, ridiculous comments, etc. Maybe even if usenet is still popular, the computer is still vunerable by simply being online.
mfwright@batnet.com
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
Problem is it's not default. And without that being default, it is a vulnerability as most people don't change their default as is well known and often exploited by MS to comply with laws while effectively circumventing them. MS Office is a classic example: You can set save file defaults, to something other than MSOOXML but it is VERY hard to find the setting.
Oh, and I use Thunderbird regularly and it works very well, and have set it up in a multitude of environments. To have Thunderbird automatically interface with 3rd party products, could well be exploited in a similar fashion as email clients, interacting with a 3rd party component that is not a part of the main product.As for using Mozilla Thunderbird to schedule shared resources there IS in fact a way. But it is not user friendly as that is not a priority of Mozilla:
https://support.mozilla.org/en...
"Imagination is more important than knowledge" - Einstein
Even if you read as plain text, at some point, some code may parse the malicious code.
Not even RTF is safe https://blogs.cisco.com/securi...
6a be sure to put the new cover sheets on the TPS reports
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.
Let's be honest: unless you're sending and receiving email only from a whitelist of addresses, and encrypted end-to-end, email is not safe at all. Nevermind malware, clickbait, spoofing, phishing, and so on, unless you're doing as per above anything you send or receive can be compromised.
Of course what I'm saying is not that 'email is bad'; what I'm really saying is: the Internet, in general, has been so thoroughly compromised, that you can't trust it at all anymore. That's the world we've allowed to become reality, and I don't even know if it can be fixed.
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.
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.
Though I personnally agree with you (unicode, specially UTF-8, is way too useful for users of language that don't fit inside ASCII)...
Why not Unicode?
Google Zalgo
Unicode is extremely complex, and although it's not a turing-complete language, it can already be abused a lot to pretty much fuck up any layout.
(e.g.: When Slashdot didn't block them in the subject line, it was possible to abuse "text direction" marker to actually put arbitrary text on the right side of the subject. I.e.: write a troll flamepost with a title that could add "(Score: 5, Insightful)" right on the place where the actual scoring would normally go)
(e.g.: Zalgo text, where diactirics (extra accents on characters) and other such decoration is progressively used on text to make a complete unreadable mess of it)
etc.
Lots of potential abuse, so that's why /. which is primarily a english speaking site will severly limit unicode use (and English itself is a language that can possibly be written by using exclusively ASCII - e.g.: by ignoring the rare word where characters could be optionally accented).
"Sufficiently advanced satire is indistinguishable from reality." - [Tips: 1DrYakQDKCQ6y52z6QbnkxHXAocMZJE61o ]
in this totally safe PDF?
Yes, Postscript is a turing complete language
(you can even write a ray tracer in it).
BUT
postscript can only output to the document (or screen), and can't read input from the internet.
Thus, as long as there isn't a critical bug in the displaying software...
- (Adobe Acrobat reader, I'm looking at you right now !),
...and as long as there isn't some asinine extra feature implemented...
- (you can bet that someone at microsoft on the outlook team would dream of a document viewer that can automatically extract attachments embed inside PDF files and execute them)
...there isn't an actual risk in opening random PDF files, except that some might take a few hours to render.
(And other can generate 1000 - worth of pages on the printer with only a few lines of code, if you're so stupid to send a raw post-script to the printer without even looking at it).
"Sufficiently advanced satire is indistinguishable from reality." - [Tips: 1DrYakQDKCQ6y52z6QbnkxHXAocMZJE61o ]
Sylpheed is great as it doesn't render HTML.
I set my email client to plain text. 99% of emails I get are in plain text or are not worth reading (e.g. SPAM and junk). For the 1% of emails I get that aren't in plain text, are actually important and dont have a "go here to read this" link I turn on HTML, read the email, do what I need to with it and then turn HTML off again. (about the only time I have needed to do that recently is for vouchers from a fast food chain I visit regularly)
I POP3 my Email and Agent won't display HTML pages. I've used Agent since Win95 on, installing it once to D:\ and pulling shorcuts to it on every new install.
I'm starting to get a lot of Base64 but a webpage and nothing I'd open anyhow, most have a text only entry tacked on to the end just in case.
"You can get a computer virus by reading an email!" (And you should see your doctor to get a vaccination for that....)
Then, and thank you SO FUCKING MUCH, Bill the Gates, he made it possible.
I read and send all my email in plain text, unless a) whoever sent it didn't know what they were doing, and made it impossible to read that way, and b) I know *exactly* who sent it. Not under any other circumstance. And it's *email*. I want to know what you have to say to me, and I don't care what it looks like.
To paraphrase Sam Goldwin, if you've got a video, sent it youtube.
Oddly enough, I've never gotten malware'd.
Just the same day Slashdot changed the daily headlines again, (behind my back, without asking).
I now have to click the link ONE MORE TIME that says "Want to receive this in text?"
Tracy Johnson
Old fashioned text games hosted below:
http://empire.openmpe.com/
BT
Thunderbird has similar options :
- prefere plain text when available
- strip "advanced" formating (i.e.: remote bullshit and scripted crap) unless I whist list the correspondent.
The totally blank e-mail still happens (because, e.g. - the e-mail is entirely a remotely hosted picture - like a flyer).
But these e-mail never come from my usual correspondant any way.(*)
I don't even need to white-list them.
Nearly always they are some spam or other form of unsolicited mailing.
So I don't bother even paying attention.
If you're not even putting enough effort to make your mail decently readable,
you won't be spending any attention to you.
If that was some "important bill" and you subsequently try to sue me for not paying :
- you're a shitty company I won't deal any business with anymore, and won't even blink about it, there are tons of decent companies with whom to do business.
- be prepared to have your practice contested through consumer organisation. Welcome to Europe mother fucker.
----
even the HTML rich-editors used by my clueless friends :
- can output an alternative plain text form
- is simple enough that it can be displayed in "safe mode".
"Sufficiently advanced satire is indistinguishable from reality." - [Tips: 1DrYakQDKCQ6y52z6QbnkxHXAocMZJE61o ]
There was no reason to use the "Turing Complete" qualifier. You could have just said it isn't a language.
Modern Unicode is becoming so insanely complex, that it actually starts to border on a formatting language (like HTML and other markup language).
Just not a turing-complete one (i.e.: if you squint at it, it's closer to become HTML soon. Not Javascript).
"Sufficiently advanced satire is indistinguishable from reality." - [Tips: 1DrYakQDKCQ6y52z6QbnkxHXAocMZJE61o ]
Unicode is an encoding scheme.
Not quite exactly.
UTF-8 is an encoding scheme. As in "how should I represent Unicode codepoints in a bitstream"
(in UTF-8's case : ASCII is coded as is, codepoints > 128 are encoded with sequences of multiple bytes with their high bit on).
(Windows's UCS-2 is a different one, in that case it's : write everything as 16bit integers, and fuck everything above codepoint 65535/0xFFFF)
Unicode is a unified collection of codepoints.
- some codepoint represent glyph on the screen (more or less letters and similar symbols)
- some codepoint represent emojis (color icons)
then there are other codepoint that represent inscruction about how to draw the above two :
- there are instruction to change the colors of emojis (there's a special "skin color" code to use natural-looking skin color on smileys instead of the cartoonish yellow)
- there are instruction about which direction the text should flow
- there are instruction about how to combine other glyphs together...
- a pair of code points (FFFE and FEFF - BOM "Byte Order Mark") control the encoding itself and how you should decode the subsequent bit stream.
I was referring to these last categories of codepoints when I was saying that if you squint in a way at it, it starts to look like a some sort of formatting language.
By using these categories, you can really screw and destroy the layout of a HTML page.
"Sufficiently advanced satire is indistinguishable from reality." - [Tips: 1DrYakQDKCQ6y52z6QbnkxHXAocMZJE61o ]
at my first IT job and it was nearly 100% effective against spam.
This was at a time when everyone was getting 20-30 spam messages a day.
I can't for the life of me understand why this isn't done more - there is no compelling business reason to allow HTML email.
I normally don't reply to AC's claiming to be "APK" but I wouldn't want this much misinformation to go unanswered.
First link is addressed in my statement "The only time people run into issues is when a Microsoft Word document (.doc or .docx) is renamed to .rtf and loaded erroneously."
The second link is an OLE exploit and not supported by the RTF version I linked and referred to by the statement "The Rich Text Format from back in the 20th century ..."
Third link is a mispaste and doesn't work.
The fourth link refers to an interesting RCE, but I was not able to dig up the mechanism in the few minutes I spent writing this response. Maybe it's a valid reason not to use RTF, maybe it's just a bug in MS Office and associated DLLs and COM components.
Plain-text is not a panacea either, as we all are well aware of Unicode/UTF-8 bugs in several chat and email programs that allow stack smashing and shellcode. Granted those problems are theoretically easier to fix than an HTML5 email client's bugs.
“Common sense is not so common.” — Voltaire