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.
The government claims we should only use plain text email. And to tell us this, they use a PDF.
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
ftw.
It's well-known that advertisers use the images in their emails to track who does and doesn't read them.
For that reason, I always block images in my email client. 99% of the time the images are unimportant. If I want images I will visit your web site.
Email was never intended for viewing of web content, it should be for text-based correspondence only.
There is a setting in Outlook called "Read all mail as plain text". A separate one for composing New messages as well. I'm no M$ fan but Outlook is pretty good, if you work at a large organization there is nothing better for email+calendaring.
Wake me up when Mozilla Thunderbird can schedule conference rooms and add GoToMeeting details automatically.
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
The battle between HTML e-mail and plain text e-mail was lost years ago, the HTML e-mail people won. I use plain text e-mail, but I'm not dumb enough to think I'm going to convince other people HTML e-mail is bad.
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.
1. Install mutt
2. Only open email in Mutt
3. When in doubt, go to step 1
4. Any questions, call our support desk.
5. If line is busy, email the support desk.
6. Print TPS reports.
7. Email your supervisor when you are done with step one.
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 problem with what you propose is image scaling. What looks nice on your mobile phone looks tiny on my 8K monitor... which is 1/2 of what original HTML was designed for.
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?
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
and one massive wad you pulled out. No shit? That's been known for decades. Only idiots think text only is novel.
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.
You seem deprived. Here is a 5byte pr0n for you
(.Y.)
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.
You post reveals some very basic misunderstandings about email transport. I would not allow you to run corporate mail services without some significant training first!
I find that if someone sends me a pure text email, I can safely bet that they have a higher level of understanding of technology.
Really, it's just that simple. I don't get HTML mail from people who are highly skilled and knowledgeable computer scientists, ever.
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.
You all realize the same arguments you're using to justify text-only could be applied to the web and it's attendant problems?
Lord love a duck! It shouldn't take a couple of couple of professor types to tell you that html mail is unsafe and auto-loading images auto verifies you e-mail address. I switched these options off more than 10 years ago about the time these 'features' started to appear.
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 ]
Here you go. Live video.
Have gnu, will travel.
The problems w/email are scripts and, potentially, links. Images? When was the last time you saw a bug in legacy image handling of GIF's, jpg's and png's? I've seen some new image formats that had bugs, but the old ones?
But even putting images aside -- I don't recall any bugs involving text formatting & markup. There's a big difference between full blown browser supported HTML, and basic text formatting used even on this site!
Are you reading this message? It's been formatted with HTML-markup. When's the last time slashdot has been a vector for a virus?
Seem like the researchers are just plain stupid if they can't differentiate between text markup commands and automation. Even slashdot allows links to articles -- are those suppose to be unsafe? What happens if I have the text "https://www.google.com/search?q=is+this+safe", in my text. Is that inherently unsafe?
Maybe its time for people to stop running around telling us the sky is falling?
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)
My email client does not include or invoke a display routine, so even the exploits relating to text rendering are of no use against me. Instead, whenever it receives an e-mail, my email client selects a random chunk of addressable memory and overwrites the memory at that location with the contents of the inbound e-mail. Then, whenever my system crashes, I know I have mail, and it's probably important. If I decide to read my emails, I review my system core dumps. If nothing intelligible is logged there, it probably wasn't important anyway.
Clearly, there is no need for a well-defined interpreted-mode sandbox with a restricted interface to isolate the data and executable that handles the data (which may optionally include support scripting if all resources are packaged with the data), so that only a frame-buffer and keystrokes need to be considered!
SMTP requires 7-bit ASCII. This is THE standard.
MIME is also part of the standard, but 7-bit ASCII is REQUIRED to be included as well.
Any email server that doesn't include the 7-bit ASCII is flawed, out of spec. Have them fix it.
I kept getting blank emails from a support organization (outsourced). I told them it wasn't working, knowing it was because their email servers didn't follow the spec.
Ended up speaking to an Exchange admin there - showed him the RFC - he fixed his group of 100+ Exchange servers at the next maintenance window and all their emails had information again.
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.
http://nakedsecurity.sophos.com/2012/05/09/what-the-rtf-mac-and-windows-users-at-risk-from-boobytrapped-documents/?utm_source=Naked+Security+-+Sophos+List&utm_medium=email&utm_campaign=1920f4ec20-naked%252Bsecurity
http://www.dshield.org/forums/diary/Getting+the+EXE+out+of+the+RTF/6703
http://www.avertlabs.com/research/blog/index.php/2007/05/25/rich-text-malware/" ADD_DATE="1314658632
http://nakedsecurity.sophos.com/2014/03/25/microsoft-issues-patch-for-word-zero-day-booby-trapped-rtf-files-already-used-in-attacks/?utm_source=Naked+Security+-+Sophos+List&utm_medium=email&utm_campaign=545ff7263f-naked%252Bsecurity&utm_term=0_31623bb782-545ff7263f-418465757
APK
P.S.=> Want more? Ask - the apps using RTF format can have issues w/ it too... apk
"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.