The Only Safe Email is Text-Only Email (theconversation.com) 174
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).
D'oh (Score:5, Funny)
When you try to sound sincere but link to a PDF!
Re: (Score:2)
I can't open PDFs in Elm or Lynx.
Re: (Score:3)
Person Who Uses Plain Text and 13 Other Crazy People We Found. Click here to learn more...
Want to know why? Read the PDF! (Score:5, Funny)
"...should return to plain-text email (PDF)."
That's hilarious.
And the only safe encoding (Score:2, Funny)
Also: go ahead, explain to me why it is that my computer needs to have a turd glyph stored on it.
Re: (Score:3, Funny)
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.
Re: (Score:2)
case against unicode (Score:2, Informative)
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 [google.ch]
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 tha
Re: (Score:2)
IDK about the Unicode issue, but my mail client defaults to text only email.
When I get html formatted emails I have two options that I can set as default for untrusted senders:
render the incoming stream as text.
strip the HTML and attempt to render the text.
I opted for the latter, and it does present me with outright blank emails when the email is not even HTML but actually JS based content delivery in your in-box... which allows them to change the email contents after you've read it.
Trusted senders can be w
Text-only (Score:2)
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
unicode formatting (Score:2)
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).
utf-8 vs unicode (Score:2)
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 sy
Re: (Score:3)
Re: (Score:2, Interesting)
Perfectly safe:
X5O!P%@AP[4\PZX54(P^)7CC)7}$EICAR-STANDARD-ANTIVIRUS-TEST-FILE!$H+H*
Anatomy of the EICAR Antivirus Test File [nintechnet.com]--this is actually an interesting read.
Well...duh... (Score:5, Insightful)
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.
Re: (Score:2)
The default setting on OS X and now macOS is:
ta tam!
Text only.
Thanx for trolling.
Re: (Score:2)
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 in
Re: (Score:2)
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... [cisco.com]
Re: (Score:2)
Re: (Score:2)
Oh definitely no. Not death. Death is far too good for them. Serious, unrelenting, untreatable pain combined with utter social humiliation. For starters. While the psychopaths get to work on the long-term punishments.
Oh the irony (Score:5, Insightful)
So we should go back to Text-Only email for security reasons, and more information can be found in this totally safe PDF?
Re: (Score:2)
Yeah why use PDF? Maybe it's because pay layout is a powerful tool for presenting text and graphics in a way to provide additional clarity and meaning to a message. The idea of going to text only email is horrid and I cringe every time I see one.
Re:Oh the irony (Score:4, Insightful)
It seems to me that these things, in that we could really use a display format that can't actively do anything. For example, it should be possible to develop a safe subset of HTML that allows some basic formatting, but doesn't provide features that can create security holes. Similarly with PDF, we should be able to create a safe PDF format, and then set PDF viewers to only allow that form of PDF.
But no, that's not good enough. We need PDFs can can run Javascript and embed movies. For some reason.
Re: (Score:2, Interesting)
Like markdown?
Postscript language. (Score:2)
in this totally safe PDF?
Yes, Postscript is a turing complete language
(you can even write a ray tracer [github.com] 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 a
Comment Subject (Score:2)
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, cl
Disable embedded images? (Score:5, Insightful)
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.
Re: (Score:2)
RTF email (Score:3)
The Rich Text Format [microsoft.com] 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)
Re:RTF email (Score:4, Interesting)
The only time people run into issues is when a Microsoft Word document (.doc or .docx) is renamed to .rtf and loaded erroneously.
No, consider the wonderful "winmail.dat", which MS claims exists solely to protect RTF formatting for email. (It's actually what all poorly configured MS email clients send when they do attachments -- a tautology.)
And it's what poorly educated people send even after they've been told that their attachment is unreadable. It can't be THEIR fault, THEY can read it.
I've now officially given up on trying to get the information out of someone who sends winmail.dat attachments. I had one two days ago where I had to extract the attachment, copy it to a Linux system, install "tnef" (a package to deal with such crap), decode the winmail.dat, and then copy the resulting .doc file to another system where it could be read. And it turned out to be one page of text. A complete waste of time.
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).
How about if you can't say it without red flashing italic large fonts you just don't bother saying it at all? Simple text conveys a lot of information simply. You don't need a .doc or .pdf to convey one page of text.
And tag the image with a plain-text section for screen readers, search and OCR to deal with.
Once you've devolved into drawing pictures instead of using words, it is very hard to convey in words what the picture does. A "plain text section" that says "a diagram of what I'm talking about" is pretty meaningless. I've had to deal with this kind of thing for years on a website that I run. It has tons of images, all generated automatically. The "alt text" links cannot be generated that way, so they are all "an image".
Short story: if you can encapsulate the content of your image in a "plain-text section", JUST SEND THE PLAIN TEXT. You don't need the image after all, now do you?
Re: (Score:2)
How about if you can't say it without red flashing italic large fonts you just don't bother saying it at all? Simple text conveys a lot of information simply. You don't need a .doc or .pdf to convey one page of text.
I think it is reasonable that I want to underline or highlight parts of log files, or other technical information in order to provide context to the discussion. Tools like email should be expressive enough, rather than limiting everyone to the lowest common denominator.
Short story: if you can encapsulate the content of your image in a "plain-text section", JUST SEND THE PLAIN TEXT. You don't need the image after all, now do you?
Diagrams, drawings and photograph are pretty vital in many day to day communications. Want the gardener to trim back a certain hedge? Take a photo and draw a circle around the offending hedge. You perhaps grossly overestimate the language ski
Re: (Score:3)
Short story: if you can encapsulate the content of your image in a "plain-text section", JUST SEND THE PLAIN TEXT. You don't need the image after all, now do you?
Diagrams, drawings and photograph are pretty vital in many day to day communications.
"If" was a critical word in what I wrote. I highlighted it in the quote. You do realize that you can still have plain text email and include images, don't you? They don't have to be inlined to be useful.
for yours to be a reliable assumption.
You're right, for clearly the definition of "if" escapes many people.
Re: (Score:2)
You do realize that you can still have plain text email and include images, don't you? They don't have to be inlined to be useful.
I don't find attachments as useful as information that is well presented in context. Perhaps your verbal skills are above average, or at least better than my own, and you find text to be sufficient for anything you might wish to communicate.
Re: (Score:2)
https://blogs.cisco.com/securi... [cisco.com]
March 23, 2017
Re: (Score:2)
The Rich Text Format from back in the 20th century
The version of RTF I linked does not support OLE, so your CVE is not effective. Nice try though.
Re: (Score:2)
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 tex
Re: (Score:2)
Microsoft RTF goes back to 1987. I agree that some open standard would be better, but unfortunately RFC 1896 was not widely adopted. My non-MS environement creates and reads RTF documents and emails just fine. And it was a common format in the NeXTstep/OpenStep days. But seriously, I'm not interested in spending too much time bike-shedding this.
Re: (Score:2)
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
Text Only (Score:5, Interesting)
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]
Pine/Alpine (Score:3)
Re: (Score:2)
My email was text only Alpine.
Surprise! Alpine now renders HTML for you. Text-only Alpine is history. It may be limited to showing text because you're using it in an xterm, but it's showing the text from the HTML version.
Re: (Score:3)
Surprise! Alpine now renders HTML for you. Text-only Alpine is history. It may be limited to showing text because you're using it in an xterm, but it's showing the text from the HTML version.
Not history at all. You said it yourself: it's showing you the text out of the HTML. And only the text, because Alpine is still text-only. It's a compromise for the modern world (where getting HTML-only e-mails is far too common, even from places you might REALLY NEED to read messages from) but without the attack vectors that come with it. It doesn't render images, it doesn't follow tracking pixels. It doesn't do JS or any of that other dangerous, unnecessary bullshit. Just text.
I can't speak for yo
Re: (Score:2)
Not history at all. You said it yourself: it's showing you the text out of the HTML.
Which means it is no longer plain-text email only. I can remember when pine was.
And only the text, because Alpine is still text-only.
I get an amazing amount of email that Alpine shows me active links in.
but without the attack vectors that come with it.
Active links are attack vectors. It's bread and butter for most phishing attacks. "Your account will be disabled unless you click here" is not "plain text only". That it only shows text does not mean it is not processing things other than plain-text email.
Re: (Score:2)
Active links are attack vectors. It's bread and butter for most phishing attacks. "Your account will be disabled unless you click here" is not "plain text only". That it only shows text does not mean it is not processing things other than plain-text email.
Passive links; or at least what I'd consider "active" would be if the program were handling and opening them itself. Even old-school PINE had a "url-viewers" setup option though, and Alpine keeps this. It doesn't follow those links itself, it just sends them to an external program (and since it doesn't follow links internally, you're protected from auto-load nonsense). Plus it only sends them out if you want it to; you can turn that function off. It also asks you to confirm you want to open a link if yo
Re: (Score:2)
Passive links; or at least what I'd consider "active" would be if the program were handling and opening them itself.
Any link that results in the question "do you want to open this link" when I hit C/R is active. Passive is if I have to copy/paste it into something else. Passive is if I have to determine it is a URL and do something with it. Alpine is the former. It does something other than sit there and look at me on the screen. It determines what the URLs are and will perform specific actions on them.
Re: (Score:2)
We should all go back to using Pine... the best email client ever!
Re: (Score:2)
Re: (Score:2)
This is news?? (Score:4, Informative)
We've known this for many years. It's why the first thing I do with any mailreader is disable HTML.
That's no even safe (Score:5, Informative)
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.
Then why is it so unpopular? (Score:5, Insightful)
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.
Re:Then why is it so unpopular? (Score:5, Insightful)
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.
You have no clue what you're saying here. The "new message" flag is a function of the gui or text client, not the email itself. Alpine shows an "N" next to new messages, and that's pretty clear. Evolution uses bold to show new messages, in the message list.
Inline image embedding is abused by marketers, but it makes it far easier to send tutorials or support requests via screenshot sequences.
Images do not have to be inline to be useful.
Yes, clickable links are a security risk, but that's how password reset e-mails work now.
"Because some idiots who don't know good programming and security practices do it this way, it must be good."
News flash: there are mail systems that actually connect to anything in a message that looks like a URL as a way of testing for malmail. I sent someone an email with a link to a website I run and almost instantly I saw "them" access that link in the logs. Not them, the mail server that was scanning their incoming email. Any "one time reset" link sent to that user is not going to work, ever, because the server will have exhausted the "one time" access.
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.
Yes, and of course not. I do it all the time. "Line breaks" in the URL are not a problem. Firefox handles them just fine.
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.
If you don't know what you are talking about, please don't comment on technical things. Attachments are attachments. They are not part of the plain-text body.
The attachment file types themselves, however, are a mess. Outlook cries wolf at *every* attachment,
Say no more, I now understand why you think the way you do. Outlook is a piece of shit created by Microsoft that goes out of its way to avoid the existing standards for email, and is the source of the abomination known as "winmail.dat". If you think Outlook is some baseline to which good email practices should be compared, then you are ... well, enough said. The rest of your rant is thus made moot.
Re: (Score:2)
1. I was not referring to whether a new e-mail was bold or not, but how text is shown within an e-mail. The format changes when reading an e-mail body consisting of a multi-message thread is, in fact, a function of the e-mail formatting.
2. No, images don't *have* to be inline. However, there's a reason why many tutorials use that format - the format itself is useful.
3. So the way *your* mail scanner functions is the baseline for how things should work? What's your suggestion for a password reset methodology
Re: (Score:2)
1. I was not referring to whether a new e-mail was bold or not, but how text is shown within an e-mail.
No, you were pretty specific as to "clearing" the new mail in the thread, and this has nothing to do with what the email itself looks like. If you have an email client that changes the email itself to show status, then you have a very very poor email client. But we already know that.
3. So the way *your* mail scanner functions is the baseline for how things should work?
I said nothing about how my "mail scanner" works. I told you of how at least one of them DOES work, and why that makes one-time reset links useless. There goes your excuse for non-plain-text email based on "password reset links"
Re: (Score:2)
you are a clueless Microsoft wanker.
And you're just clueless if you think everybody is, or even should be, technically proficient enough to know a "search bar" from a "URL bar," especially when every single one of the major browsers have intentionally merged the two over the past few years.
Really, the whole thread including the article is relatively pointless. This is one of those "security vs convenience" discussions, and one that isn't even remotely new, and one that the world has firmly fallen on the convenience side of.
There is zero prob
Re: (Score:2)
And you're just clueless if you think everybody is, or even should be, technically proficient enough to know a "search bar" from a "URL bar,"
Show me where I said they needed to be. I said that it isn't an excuse to require crap in email more than plain text. The fact you paste a URL into a search bar instead of the address bar is your ignorance and not justification for new standards that you won't be any better capable of understanding.
There is zero probability that even a barely noticeable fraction of email users will suddenly decide to drop back to 1992 era email so there's little point even discussing it --
And yet here you are. Or is your participation just so you can jump down my throat for something I didn't say?
Re: (Score:2)
Show me where I said they needed to be.
You don't paste a URL into a SEARCH BAR, you nimrod. It's a URL.
You don't explicitly say it, but your phrasing certainly implies that you expect "nimrods" to know that.
And yet here you are.
I've never claimed to be above discussing pointless things. That said, I was referring more to the larger community "discussing" it in the sense of going to the trouble of writing and publishing academic papers and whatnot more than the sense of random posters on random forums ranting at each other for a few hours before the topic gets pushed to page 2..
Re: (Score:2)
1. I was not referring to whether a new e-mail was bold or not, but how text is shown within an e-mail.
No, you were pretty specific as to "clearing" the new mail in the thread, and this has nothing to do with what the email itself looks like. If you have an email client that changes the email itself to show status, then you have a very very poor email client. But we already know that.
My exact quote:
"The color separation makes it clear when you've cleared the 'new message' in the thread, as does the stylized header"
For the third time, I'm referring to the fact that replies generally start with a different text style than the rest of the thread when reading an e-mail in a window which shows a message, along with its replies, in reverse chronological order. Perhaps it wasn't perfectly worded, but that it what I was referring to, from the beginning. Whether it's better or worse than the cou
Re: (Score:2)
Ehh, I'm up for one more go-around...
My exact quote:
"The color separation makes it clear when you've cleared the 'new message' in the thread, as does the stylized header"
Yes. That's a function of the mail client and not the email itself.
At some level, whether by markup styling or the use of the ">" character, the e-mail body is where the information regarding what's new vs. what isn't is designated.
For the third time, I'm referring to the fact that replies generally start with a different text style than the rest of the thread when reading an e-mail in a window which shows a message,
Perhaps in pieces of crap like Outlook that don't care about email standards, but they don't look any different in any real email client. Any email client that changes the body of the email based on read or unread status is broken, period.
You've yet to name what you consider a "real e-mail client", and you're still missing my point. The body doesn't change its formatting based on whether a message is 'read' or 'unread', but rather an e-mail containing the text of several prior messages over the course of an e-mail exchange is shown with dif
Re: (Score:2)
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?
MS Office macros can also be quite useful. Do you enable those?
Re: (Score:2)
1. The popularity of Twitter and Slack is based primarily on their ability to handle synchronous communication, in which e-mail lacks. Moreover, while it's not possible to change the font on Twitter (dunno about Slack), Twitter does allow for links, images, and embedded videos, functions plaintext e-mail does not provide. Would Twitter still be popular without these abilities? That's a good question indeed, but neither Twitter nor Slack are long-form means of communication.
2. Yes, they're annoying and a was
Thunderbird, viewing in Plain Text ... (Score:4, Insightful)
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.
Re: (Score:2)
In Thunderbird, add HTML Mode to the toolbar which toggles between text only, simple html, and the full bollocks.
Re: (Score:2)
That is why I use mutt (Score:5, Interesting)
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.
Re: (Score:2)
I resemble that remark! I also use mutt as my primary email client. In addition to security and quick access to full headers, it is just plain faster, especially with 200+ daily. Best with nice big portrait terminals (140x140).
A few items need rendering (I prefer elinks2 over lynx 'cuz tables) and a very few get copied into a safe file for seamonkey image rendering.
Re: (Score:2)
I have very few tables in email, but if that changes, I will try elinks2. Thanks for the tip!
Re: (Score:2)
I do the same. However, the worst part is the multipart emails which contain a text/plain version with content:
> your email client does not understand HTML emails, bla bla bla
As if HTML to readable text/plain is so difficult.
Re: (Score:2)
As if HTML to readable text/plain is so difficult.
Indeed. Might be an attempt to force people on HTML, otherwise it makes zero sense.
Re: (Score:2)
elm here.
Re: (Score:2)
I used to be on elm (wayyy back), but I found mutt works better for me. It is a matter of taste though.
You can do safe email that is more than plain text (Score:2)
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.
Sim
I miss Usenet (Score:2)
Global warming (Score:4, Interesting)
Re: (Score:2)
Also, faster speeds for slow Internet connections!
Email is not safe at all (Score:2)
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 bec
The first thing that needs to change (Score:3)
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.
Re: (Score:2)
Spoofed sender addresses won't work so well if my server can't look up the domain MX record,
MX records are not mandatory. The standards are quite clear on that, and how to deal with it. Any mail filter that blocks based on a missing MX record is violating the standards.
But zealots will be zealots. All kinds of standards-breaking goes on in the name of spam fighting. Empirical knowledge reigns. Things like the seemingly ubiquitous list of valid email address characters that was developed by some ignorant web programmer and ignores the existing explicit valid list. (And yes, I'm referring to the mo
Re: (Score:2)
Server A contacts Server B with a mail notification, with a sender email address and message serial number.
Server B disconnects. At its leisure, it looks up the domain mail server for the sender's email address. Then, it contacts that server and requests the message by sender and message ID. If there is a match, server A responds to server B with the email. If there isn't, Server A knows somebody just failed to send it spam, and Server B knows somebody is using its name or address to send spam.
Bot nets
Re: (Score:2)
Server A contacts Server B with a mail notification, with a sender email address and message serial number.
There is no "serial number". The message id is part of the header. The "sender email address" appears in the From: header and may have no relation to server A at all.
Then, it contacts that server and requests the message by sender and message ID.
So you go all the way to getting the data from the message just to disconnect and then ask for it all again. And you may try to connect to a server that has not been involved in any part of the process.
If there is a match, server A responds to server B with the email.
Message ids are not authentication. Second, how does the server know to whom it has delivered the message? It is not sufficient to ask for "sen
Re: (Score:3)
Most (public) mail servers do most of that already. The only difference from what you're saying is that the "notify" is the entire email and the "pull" is just the reverse DNS lookup (and blacklist lookup and whatever other checks they do.)
The biggest problem is that all of this is optional, and many mail servers (especially private ones) are configured by default for ease of use rather than security (which makes sense -- there's no point hardening a system nobody can use in the first place.) Gmail has tr
Actually, you could hack those too (Score:3)
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.
I set my email client to plain text (Score:2)
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)
Forte Agent is my poison (Score:2)
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.
It used to be a joke on newbies... (Score:2)
"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 para
I bounced all HTML email (Score:2)
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.
Re: (Score:2)
Re: (Score:3, Insightful)
Only fanbois care about this
Re: (Score:2)
Text email also has a header.
This means there are vulnerable parsers in the server and client software.
Re: (Score:2)
Re: (Score:2)
Emojis are stupid
Re: (Score:2)
Re: (Score:2)
Re:Text-only Email safe? (Score:4, Informative)
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/... [carbon.cc]
If that works you have plain-text unicode support in your browser.
Re: (Score:2)
I have no problem rendering unicode on my terminals. Unicode doesn't have to do with text/binary.
While it isn't the hugest challenge in security, unicode at the string level is not easy to get right. You have to do the right thing at the ends of strings when hanging combining codepoints are present. And just recently, suddenly a standard change allows certain combiners to appear before their target base character rather than after. Tons of combiners can be piled up on a character. There are plenty of icky corners where bad code could crash the stack on a poor implementation. There are 4 times as m
Re: (Score:2)
Homer clearly doesn't know how to communicate effectively, I see no emojis at all in that page! Homer also needs to learn about how to get advertising sponsors, as that page was eerily free of advertisements for Trojan products.
Re: (Score:3)
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.
Re: (Score:3)
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
Re: (Score:2)
Re: (Score:2)
This. Can't sing praise of mutt enough. No bugs, just fleas :)
I once worked in an environment where we could choose our own mailer, most of us chose mutt. It's hellish fast with header caching. Starts up in subseconds, unlike outlook which I'm now forced to use at a different job. Still, work forces get to drink more tea when waiting for outlook to do things. Sounds nice, but think of the burden the extra kettle cycles place on the power grid.