By Chris Meidinger
When my colleague Erika commented that it's email's birthday month - RFC 821 was posted in August of 1982 - I figured we ought to say happy birthday here on the blog. I set about looking for a more specific date for the RFC's release than "August 1982" to figure out when the exact birthday is, and (of course) my first thought was "well, there must be a mailing list archive somewhere that will have the original announcement from when the RFC was first officially published". Right, I just assumed the advent of the email age was announced by email because, how else?
That's how ubiquitous email is. How could there have been a time before email? Growing up in the 80's I've never really known a time without email. My father taught then and still does teach at a large research university, which put him way ahead of the curve in terms of email access both for himself and for the professors and researchers he was in professional contact with at his and other universities, so I really can't remember a time before near instant business email communication was simply a given in the home. You didn't always have it on your phone, that's only been the last 10-15 years, but everyone had email. I'm pretty sure the first machine in the house to have email - or, much more importantly for me, it was able to run a space invaders clone - was a Kaypro II. Later, I started to sing along to the noise of the modem - you guys all remember that right? (If you've forgotten it, the first 15 seconds of this will bring it right back.) The 80's were a heady time. If you want an amazing journey/flashback/adventure story to remind you of some of the great stuff from the 80's - from the game Zork to the movie War Games - check out Ready Player One, by Ernest Clein; it brings back memory after memory for someone who was young in the decade after disco.
Anyway, fast forward to 2014, and a lot has changed. Back when email was developed, the network that would become the internet was not just young, it was still being built. The question was not "how can we build a communications system with military-grade security?", the question was "can we get this to work? can we relay an electronic message from here to another country and have it arrive in a readable format?". The RFC that originally described the SMTP protocol was released less than a year after the RFC for TCP, about a year before the RFC for telnet. That's how experimental all this stuff was. Remember trying to eliminate telnet from your networks in favor of SSH? Back when email was invented, good old pitifully-insecure telnet wasn't even standardized.
It's hard to blame anyone for not having baked security into the fundamental email protocols at the time. Delivering the mail was hard enough. In the intervening years, the base RFC's were revised: email got RFC2821 and 2822 in 2001, and then it got 5321 and 5322 in 2008, but authentication was never fully addressed. In today's complex global landscape of cyber threat, the lack of authentication in email is starting to look like its "original sin" to the modern eye. (I borrow that turn of phrase from Pat Peterson because I think he's right on the money with it.)
SPF and DKIM came around in the two-thousands, but neither one was enough to solve the authentication problem all the way. SPF doesn't survive forwarding, and DKIM is a bit too fragile on its own due to legitimate message modification breaking the signature. SPF's policy layer has weakened over the years, and DKIM's nascent policy layer, ADSP, never really got off the ground. So, although there were some good technologies available, there still wasn't really a way to know that an email was truly sent by the party it claimed to have been sent by.
When DMARC was announced in Spring 2012, email got an early 30th birthday present: a framework to overlay the existing authentication mechanisms and finally, after thirty years, authenticate email and know whether it authenticated. Neither of the technologies previously had a feedback mechanism, a way for someone sending an authenticated email to know whether that authentication was in fact validated by the recipient. You can liken it to logging on to a computer and just getting an empty prompt, not knowing whether your credentials had been accepted. It was all guesswork with SPF and DKIM, particularly when you look at the negative case: I have some idea whether my own messages bounce, but how can I know whether messages sent by criminals in my name are being delivered?
With DMARC, reports are sent back including the authentication results for every message - whether it did or did not authenticate and how - no matter whether you sent it, a third party sent it at your request, or whether a malicious actor sent it from thousands of miles away. Finally the sender got feedback about whether authentication was successful. In addition, DMARC gives email senders the ability to request particular handling by receivers if messages could not be authenticated, like getting an "Access Denied" message when logging on to a system. Of course, it is critically important to system integrity that a user is not logged on after an incorrect password has been entered, but instead sees their logon rejected. The DMARC policy layer handles that: messages from the bad guys no longer get through to the users and consumers with whom you've built a relationship. That relationship is a digital asset that was long under-protected, and still is by many enterprises.
Email has gotten, if you will, many birthday presents over the years: new SMTP extensions like TLS encryption, or MUA AUTH, various improvements to MIME like S/MIME or standardized DSN's, even new transmission types like ESMTP and LMTP. However, among all of those extensions and all their coverage of new use cases and improvements on the handling of old ones, I believe that DMARC is special. Many "presents" over the years have improved security but, next to TLS which, like HTTP/S before it, essentially wrapped another existing technology for use by mail exchangers, DMARC is the biggest security leap forward and impacts average people's lives the most. Without peer, DMARC adds the most unique security benefit: it ensures that you are you and nobody else on the internet can be you. That's a big deal.
Happy Birthday, Email!
Your Friend, Chris.
When my colleague Erika commented that it's email's birthday month - RFC 821 was posted in August of 1982 - I figured we ought to say happy birthday here on the blog. I set about looking for a more specific date for the RFC's release than "August 1982" to figure out when the exact birthday is, and (of course) my first thought was "well, there must be a mailing list archive somewhere that will have the original announcement from when the RFC was first officially published". Right, I just assumed the advent of the email age was announced by email because, how else?
That's how ubiquitous email is. How could there have been a time before email? Growing up in the 80's I've never really known a time without email. My father taught then and still does teach at a large research university, which put him way ahead of the curve in terms of email access both for himself and for the professors and researchers he was in professional contact with at his and other universities, so I really can't remember a time before near instant business email communication was simply a given in the home. You didn't always have it on your phone, that's only been the last 10-15 years, but everyone had email. I'm pretty sure the first machine in the house to have email - or, much more importantly for me, it was able to run a space invaders clone - was a Kaypro II. Later, I started to sing along to the noise of the modem - you guys all remember that right? (If you've forgotten it, the first 15 seconds of this will bring it right back.) The 80's were a heady time. If you want an amazing journey/flashback/adventure story to remind you of some of the great stuff from the 80's - from the game Zork to the movie War Games - check out Ready Player One, by Ernest Clein; it brings back memory after memory for someone who was young in the decade after disco.
Anyway, fast forward to 2014, and a lot has changed. Back when email was developed, the network that would become the internet was not just young, it was still being built. The question was not "how can we build a communications system with military-grade security?", the question was "can we get this to work? can we relay an electronic message from here to another country and have it arrive in a readable format?". The RFC that originally described the SMTP protocol was released less than a year after the RFC for TCP, about a year before the RFC for telnet. That's how experimental all this stuff was. Remember trying to eliminate telnet from your networks in favor of SSH? Back when email was invented, good old pitifully-insecure telnet wasn't even standardized.
It's hard to blame anyone for not having baked security into the fundamental email protocols at the time. Delivering the mail was hard enough. In the intervening years, the base RFC's were revised: email got RFC2821 and 2822 in 2001, and then it got 5321 and 5322 in 2008, but authentication was never fully addressed. In today's complex global landscape of cyber threat, the lack of authentication in email is starting to look like its "original sin" to the modern eye. (I borrow that turn of phrase from Pat Peterson because I think he's right on the money with it.)
SPF and DKIM came around in the two-thousands, but neither one was enough to solve the authentication problem all the way. SPF doesn't survive forwarding, and DKIM is a bit too fragile on its own due to legitimate message modification breaking the signature. SPF's policy layer has weakened over the years, and DKIM's nascent policy layer, ADSP, never really got off the ground. So, although there were some good technologies available, there still wasn't really a way to know that an email was truly sent by the party it claimed to have been sent by.
When DMARC was announced in Spring 2012, email got an early 30th birthday present: a framework to overlay the existing authentication mechanisms and finally, after thirty years, authenticate email and know whether it authenticated. Neither of the technologies previously had a feedback mechanism, a way for someone sending an authenticated email to know whether that authentication was in fact validated by the recipient. You can liken it to logging on to a computer and just getting an empty prompt, not knowing whether your credentials had been accepted. It was all guesswork with SPF and DKIM, particularly when you look at the negative case: I have some idea whether my own messages bounce, but how can I know whether messages sent by criminals in my name are being delivered?
With DMARC, reports are sent back including the authentication results for every message - whether it did or did not authenticate and how - no matter whether you sent it, a third party sent it at your request, or whether a malicious actor sent it from thousands of miles away. Finally the sender got feedback about whether authentication was successful. In addition, DMARC gives email senders the ability to request particular handling by receivers if messages could not be authenticated, like getting an "Access Denied" message when logging on to a system. Of course, it is critically important to system integrity that a user is not logged on after an incorrect password has been entered, but instead sees their logon rejected. The DMARC policy layer handles that: messages from the bad guys no longer get through to the users and consumers with whom you've built a relationship. That relationship is a digital asset that was long under-protected, and still is by many enterprises.
Email has gotten, if you will, many birthday presents over the years: new SMTP extensions like TLS encryption, or MUA AUTH, various improvements to MIME like S/MIME or standardized DSN's, even new transmission types like ESMTP and LMTP. However, among all of those extensions and all their coverage of new use cases and improvements on the handling of old ones, I believe that DMARC is special. Many "presents" over the years have improved security but, next to TLS which, like HTTP/S before it, essentially wrapped another existing technology for use by mail exchangers, DMARC is the biggest security leap forward and impacts average people's lives the most. Without peer, DMARC adds the most unique security benefit: it ensures that you are you and nobody else on the internet can be you. That's a big deal.
Happy Birthday, Email!
Your Friend, Chris.