This site is operated by a business or businesses owned by Informa PLC and all copyright resides with them.Informa PLC's registered office is 5 Howick Place, London SW1P 1WG. Registered in England and Wales. Number 8860726.

Why Email Is Worth Saving

What if an Internet-scale, federated policy, authentication, and enforcement framework for trusted email delivery were available? It is.

Imagine a world where companies, governments, and individuals could send an email to anyone, and both the sender and receiver had a reasonable expectation that the communication therein was authentic. How would such lunacy change the dynamics of online messaging, end-user protection, and anti-fraud?

It's no secret that email as a global communications medium has become so polluted and mistrusted that companies and individuals are moving to other channels such as social media and mobile to regain the ability to have a "trusted" conversation. A recent study by the professional services company Towers Watson shows that 56% of employers are using social media as part of their overall internal communication strategy. This is creating a whole new set of risks and privacy concerns.

But contrary to popular opinion in some quarters, email is not dead. Email is the unsung hero of the global economy, the rusty workhorse that will likely be around forever. Facebook, Snapchat, Whatsapp, and other nominal email replacements are completely inadequate for personal B2C communication and sensitive P2P messaging, not to mention robust B2B communication. Email is worth saving and protecting.

Email authentication and encryption is not new. Many technologies exist to allow for encrypted email transport, such as TLS. Others exist to provide encrypted, authenticated email, like PGP and S/MIME. The most persistent problem with existing forms of one-to-one email authentication is that non-technically savvy individuals have to figure out how to make these systems work and keep them working. Try explaining the x.509 certificate expiration or revocation process to the normal email user. These systems have never really taken off, and many researchers are predicting the emergence of more user-friendly systems.

What if an Internet-scale, federated policy, authentication, and enforcement framework for trusted email delivery were available? What if the bones of this system were already deployed and supported by the biggest email receivers on the planet?

Enter a framework called DMARC
Domain-based Message Authentication, Reporting & Conformance (DMARC) is an emerging email delivery standard that has shown so much progress and potential that most of the email boxes in the world already support it -- even without an RFC number from the IETF. DMARC relies on two other standards, DKIM and SPF, to allow senders to sign their outbound email and announce authorized email servers per domain.

DMARC allows any email sender essentially to tell every receiver how to authenticate the email and what to do with unauthenticated mail. All this is done in a completely transparent way to the humans on either end. It does this by leveraging DKIM and SPF to create a transparent handshake between the email sender and the receiver via DMARC policy records presented as DNS TXT records. When an email received fails DKIM/SPF, it asks the sender what to do with this email. The sender's DMARC policy directs the receiver to do nothing, to quarantine the email, or to reject it.

Too good to be true?
Just like with any other sure thing, there are caveats. Deploying DMARC as a company is easy if you have a small number of domains and a small number of authorized email servers within a small number of domains. Things get more complicated as these numbers grow and third-party senders, consulting agencies, and others are added into the mix. Additionally, even though the top email receivers support DMARC, many others still do not. There are a few huge receivers (Google, Yahoo, Hotmail, etc.) supporting DMARC that support more than 3 billion mailboxes, but there are millions of other servers on a very long tail.

When/if fully deployed, DMARC allows for domain holders to protect their domains but not others. This will likely drive email spoofing of legitimate domains down dramatically. In its place, hackers will likely move further away from direct brand impersonation to other social engineering techniques, such as registering new domains (such as bankofamericapromotions.com). The good news is that these kinds of registrations are far easier to detect and stop.

While there is no doubt that the hackers will evolve and come up with new social engineering schemes and methods to continue to perpetrate phishing attacks, DMARC has remarkable promise. If and when it is fully standardized and deployed globally, it can fix a fundamental flaw in the technology that has underpinned the Internet from the very beginning.

Opportunities like this do not come along very often, and it is up to the security community at large to rally behind its adoption. Information security, online trust, and anti-fraud are all adversarial pursuits and, like American football, a game of inches. Any chance we get to complicate the efforts of our adversaries while simplifying ours -- making theirs more expensive and more time-consuming -- is a small victory in a long game.

Daniel Ingevaldson has a 15-year+ career including early infosec innovators like Internet Security Systems (ISS), where he was a member of the famed "X-Force" threat and vulnerability research group, and continued on in various research leadership, engineering, consulting, ... View Full Bio

@Marilyn, yes, I saw that. Very interesting. I have always prided myself on finding the glitches or flags in phishing emails. They are small these days, but I do catch them. I would love to be put to a comparison test (real vs. phish) to see how well I do!

It's not always that easy to tell anymore, @soozyg. Chris Hadnagy, a social engineering expert said in this week's Dark Reading Radio show that phishing emails are much more sophisticated than they used to be. Phishers are using spell check and hiring proofreaders as a "customer service option" to create branded, well-written emails that are very convincing...

@sara, if resources are constrained, and where aren't they?, then I suppose it's too much to ask for IT to build relationships with end users. Which is a shame. Because it sounds like this solution has promise but requires handholding and training. Perhaps the answer is bringing in outside help?

@whoopty I think email is totally worth saving, but ya know I REALLY wish that people would pick up the phone more often. I get tired of typing and staring at a screen, and I miss hearing people's voices. I think you get to know people so much better when you can hear them laugh -- not just see whether or not they capitalized LOL.

@Broadway @soozyg Maybe this is just another reason that IT departments need to become more snuggly and outgoing, instead of entirely remote, anonymous slaves to a helpdesk tickteting system. I think that IT departments are getting better at this, but it still seems that in the big companies it's hard to really get to know the IT staff by name, and therefore more unlikely that you'll go to them with questions and advice.

With my work it's almost entirely email communications - with some phone calls if we feel like going really retro - while for sure my personal communications have evolved into mostly social networking and skype based.

The transition from DevOps to SecDevOps is combining with the move toward cloud computing to create new challenges - and new opportunities - for the information security team. Download this report, to learn about the new best practices for secure application development.

In Pimcore before 5.7.1, an attacker with limited privileges can trigger execution of a .phar file via a phar:// URL in a filename parameter, because PHAR uploads are not blocked and are reachable within the phar://../../../../../../../../var/www/html/web/var/assets/ directory, a different vulnerabi...

In Pimcore before 5.7.1, an attacker with limited privileges can bypass file-extension restrictions via a 256-character filename, as demonstrated by the failure of automatic renaming of .php to .php.txt for long filenames, a different vulnerability than CVE-2019-10867 and CVE-2019-16317.