Recently there has been a resurgence of an old security idea that “plain text email is the only safe email”. The ASCII Ribbon campaign from 1998 was precisely about this. It shut down in 2013 as it fell on deaf ears.
Is it time to bring back this idea and perhaps even turn it into a respected adage? Is it even possible given the content richness of emails these days?
While there are several advantages to doing this, and yes, it will significantly tighten security, it will not fix all email security problems. HTML email has, perhaps rightfully so, been compared to a minefield. But one must always keep in mind that the fundamental problem in email is that of authentication. Is the sender of the message who you think it is? Plain text emails still have this problem. One can always craft phishing messages in plain text (our DMARC explainer shows several examples where this is done). Replying to a sender involves no clicks of suspect links, but are you really replying to who you think you are? Similarly downloading and running attachments in a message can be done with plain text emails as attachments are simply a MIME part. Plain text emails support attachments.
The problem of authentication is being addressed by ideas like SPF, DKIM and DMARC but until they are properly implemented by the senders and enforced by the recipients, the problem will remain. Furthermore, even they do not address all attack vectors pertaining to the authentication of the sender. Mail transfer agents often combine them with real time blacklists that block emails based on the senders IP. The reputation and authenticity of the sender is the root of the problem.
HTML rich emails provide several attack vectors to be exploited and removing HTML would certainly eliminate those. Everything from cleverly hiding legitimate text to bypass spam filters using formatting tricks, to fancy CSS capable messages that change URLs after they have been delivered to your inbox would be eliminated. Emails formatted to look like they are from your banking institution requesting a change in password would be eliminated. My life programming techniques to catch exploits would be made easier. But as we saw with the ASCII Ribbon campaign, nobody listened. Apparently we love our HTML rich emails, but do we really need them?
Picture a world where a plain text only email policy is enforced. From a functional perspective, would you or your organization really suffer? The vast majority of solicited emails are typically just conversations between a group of people. In office environments where meetings have to be scheduled, Outlook is not the only option. Meetings can be organized using tools independent of email. Calendars can and do exist independent of email. Marketing departments would no doubt suffer the most as they benefit most from HTML rich emails that contain analytics providing useful feedback on whether messages have been read. Similarly newsletters would look plainer and require copying and pasting links. But to be honest, are they that different from spam? I have programmed spam filters to detect newsletters and marketing messages.
I believe we could live in such a world, but it would require the use of several tools, and we know that most people generally don’t want that. People love that one, universal tool that does everything. Several attempts have been made to replace email with such tools. Remember Google Wave? The reality is that we turned email into something it was never designed for and will continue using it. While I like this resurgence of plain text email, and believe that combined with modern authentication mechanisms it would significantly increase security, I do not believe that it is an attainable goal. Focusing on stronger protection for email will probably continue to be the only real solution here, with strong malicious URL and Attachment Defense, spam detection and filtering, protection from phishing tactics and provide a more viable path to protect email and its users, whether in txt or html.
Leave a Comment