Catch up on stories from the past week (and beyond) at the Slashdot story archive

 



Forgot your password?
typodupeerror
Communications Privacy Security

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).
This discussion has been archived. No new comments can be posted.

The Only Safe Email is Text-Only Email

Comments Filter:
  • D'oh (Score:5, Funny)

    by Anonymous Coward on Tuesday September 12, 2017 @01:25PM (#55181819)

    When you try to sound sincere but link to a PDF!

  • by Anonymous Coward on Tuesday September 12, 2017 @01:25PM (#55181821)

    "...should return to plain-text email (PDF)."

    That's hilarious.

  • is ASCII.

    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)

      by Anonymous Coward

      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.

    • Why not Unicode? Especially when all the major platforms support a variety of languages using Unicode conventions! Everyone's not Slashdot!
      • case against unicode (Score:2, Informative)

        by DrYak ( 748999 )

        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

        • 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

          • 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

    • And the only safe encoding is ASCII.

      Then you go back to the dark days of code pages, which was its own headache, especially with eastern languages.

      It wouldn't be difficult to have a program highlight text that comes from another Unicode alphanumeric language block than your own. That way if someone tries to use similar looking characters, you'd have some notice. Also, it wouldn't be difficult to blacklist Unicode blocks, like the ones used for symbols. That would eliminate the emoticon issue.

    • Re: (Score:2, Interesting)

      by Anonymous Coward

      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)

    by evolutionary ( 933064 ) on Tuesday September 12, 2017 @01:30PM (#55181865)
    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.
    • The default setting on OS X and now macOS is:
      ta tam!
      Text only.

      Thanx for trolling.

  • Oh the irony (Score:5, Insightful)

    by Apotekaren ( 904220 ) on Tuesday September 12, 2017 @01:30PM (#55181867)

    So we should go back to Text-Only email for security reasons, and more information can be found in this totally safe PDF?

    • 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)

      by nine-times ( 778537 ) <nine.times@gmail.com> on Tuesday September 12, 2017 @03:23PM (#55182845) Homepage

      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)

        by Anonymous Coward

        Like markdown?

    • 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

  • 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

  • by ilsaloving ( 1534307 ) on Tuesday September 12, 2017 @01:35PM (#55181905)

    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.

  • by OrangeTide ( 124937 ) on Tuesday September 12, 2017 @01:36PM (#55181917) Homepage Journal

    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)

      by Obfuscant ( 592200 ) on Tuesday September 12, 2017 @02:08PM (#55182149)

      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?

      • 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

        • 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.

          • 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.

    • by Kaenneth ( 82978 )

      https://blogs.cisco.com/securi... [cisco.com]

      March 23, 2017

      • 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.

  • Text Only (Score:5, Interesting)

    by Bigbutt ( 65939 ) on Tuesday September 12, 2017 @01:39PM (#55181941) Homepage Journal

    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]

  • by dostert ( 761476 ) on Tuesday September 12, 2017 @01:45PM (#55181993)
    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.
    • 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.

      • by Mousit ( 646085 )

        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

        • 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.

          • by Mousit ( 646085 )

            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

            • 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.

    • by mspohr ( 589790 )

      We should all go back to using Pine... the best email client ever!

    • by Mousit ( 646085 )
      I started with PINE, moved to Alpine when that became the replacement, and to this day that is still the one and only e-mail client I use. It has come a long way since the earliest PINE days, but it's still overall just as familiar as it was. It's made some compromises over the years to maintain usability in the modern day (it renders HTML for example, but only the text out of it, not the rest, so no HTML attack vectors), but overall I still think it's one of the most secure e-mail clients out there.
  • This is news?? (Score:4, Informative)

    by JohnFen ( 1641097 ) on Tuesday September 12, 2017 @01:45PM (#55181995)

    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)

    by Trailer Trash ( 60756 ) on Tuesday September 12, 2017 @01:49PM (#55182019) Homepage

    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.

  • by Voyager529 ( 1363959 ) <.moc.oohay. .ta. .925regayov.> on Tuesday September 12, 2017 @02:00PM (#55182095)

    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.

    • by Obfuscant ( 592200 ) on Tuesday September 12, 2017 @02:27PM (#55182283)

      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.

      • 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

        • 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"

          • by Altrag ( 195300 )

            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

            • 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?

              • by Altrag ( 195300 )

                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..

          • 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

    • 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?

  • by fahrbot-bot ( 874524 ) on Tuesday September 12, 2017 @02:03PM (#55182113)

    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.

  • by gweihir ( 88907 ) on Tuesday September 12, 2017 @02:06PM (#55182133)

    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.

    • by redelm ( 54142 )

      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.

      • by gweihir ( 88907 )

        I have very few tables in email, but if that changes, I will try elinks2. Thanks for the tip!

    • 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.

      • by gweihir ( 88907 )

        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.

    • by PPH ( 736903 )

      elm here.

      • by gweihir ( 88907 )

        I used to be on elm (wayyy back), but I found mutt works better for me. It is a matter of taste though.

  • 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

  • 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.
  • Global warming (Score:4, Interesting)

    by eminencja ( 1368047 ) on Tuesday September 12, 2017 @02:50PM (#55182419)
    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 bec
  • by Baron_Yam ( 643147 ) on Tuesday September 12, 2017 @03:08PM (#55182637)

    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.

    • 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

      • 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

        • 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

    • by Altrag ( 195300 )

      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

  • by Solandri ( 704621 ) on Tuesday September 12, 2017 @04:04PM (#55183307)
    I used to manage an email server and mailing list back in the 1990s. The MBOX format [loc.gov] 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.
  • 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 para

  • 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.

Man is an animal that makes bargains: no other animal does this-- no dog exchanges bones with another. -- Adam Smith

Working...