Recently I have been busy upgrading our email server adding DKIM (DomainKeys Identified Mail), DMARC (Domain-based Message Authentication, Reporting, and Conformance) and SPF (Sender Policy Framework). The question – why has it taken so long for adoption of secure messaging standards?
Email or electronic mail emerged in 1970’s when academics began networking their computers and sought a standard for exchanging communications. By 1982 Simple Mail Transfer Protocol (SMTP) promised an interoperable standard (albeit one that is anything but “simple”) for connecting computers worldwide via an email service.
While the accomplishment of enabling a worldwide email network, given the plethora of machine types, operating systems and mail programs should not be overlooked, given that it has run now largely successfully for nearly 50 years, fundamental weaknesses in architecture were present from the beginning.
Principally, the original design of SMTP had no facility to authenticate senders, or check that servers were authorized to send on their behalf.
The absence of “trusted identity” is rooted in a more generalised flaw in design of public internet which grew around core of DNS – domain names (conconical textual names for Internet Protocol IP numeric addresses) representing computers on a network.
Inability to reliably verify sender/recipient has resulted in a worldwide public electronic messaging system which is unreliable, untrustworthy and fundamentally insecure.
On corporate LANs by mid 1990’s enterprise messaging typically provided by IBM’s Lotus Notes or Microsoft Exchange already had many features integral to a reliable and trusted messaging platform.
Identity could be resolved via LDAP to Active Directory – a secure enterprise wide inventory of devices and individuals or roles.
Messages could be cryptographically signed to maintain integrity and quality of service (QOS) ensured for example that a message was delivered, opened and acknowleged via a read receipt (did everyone remember to read the chairman’s annual review email?).
Strangely, on public internet, due in part I think to decentralisation, the absence of trusted federated identity protocol and relatively high computational cost of cryptography, features central to secure messaging were never adopted.
As a result even today, there is no certainty an email will be delivered. Or indeed that a message originated from the proported sender.
Which is perhaps acceptable in context of a casual social chat between friends. But when we are talking business correspondence, financial matters, government or legal communications – the result is an email infrastructure that is simply not fit for purpose.
Despite advances in textual heuristics based profiling/scoring, delivery whitelists / blacklists and categorisation of messages the prevalence of SPAM and message spoofing scams signpost the basic need to verify message origination and prevent impersonation has never been properly addressed.
DKIM which uses SSL identity certificates appended to DNS record and cryptographic key based message signing of fields in message envelope is a step towards establishing trusted identity.
We are not talking about message encryption here – arguably on public civilian internet maintaining a plain text message body as standard should endure.
Rather, trusted identity means we can be relatively (more) certain of who a message came from. Yes, that is a genuine message from your bank, utility provider, local government agency, legal department or tax office.
A related problem is in absence of a reliable directory service, how is it possible to know how to contact someone? Unlike enterprise LDAP public internet has never had a contact phone book. Trying to find an individuals contact details now – it is nearly impossible!
Having covered identity, lets consider other features missing from email.
Supported by postal services for many decades – guaranteed or priority delivery. Simply, the idea that a recipient must acknowledge receipt (typically with a signature).
Law enforcement presently tasked with delivering summons, court communications etc are spending a fortune in terms of Police time and endangering lives of rank and file when as recently as 1990’s in many cases a telephone call from station to a UK landline (registered to an address) was considered acceptable.
Contacting anyone reliably by mobile telephone and even more so via email – how is this possible today?
Also, the notion of message priority – I was at a music festival recently and a payment message from a food van online payment terminal could not get through as mobile network was saturated by live streamers sending social video content.
These use cases fall into a set of QOS (quality of service) features.
Looking ahead to internet of things when my house, car, toaster, smoke alarm, intruder detection system and billions of other smart sensor based devices are predicted to become internet enabled, trusted identify and QOS become absolutely vital.
Consider a smart home notifying fire department that a blaze is detected – reliability, message integrity and trust must be present in such a system from the start.
Having worked recently with message queue platforms (Hive/MQTT/Mosquito) on systems where message volumes and flow rates can be substantial, QOS that encodes TTL (time to live) and priority is vital in processing large message flows.
When a receiver is un-contactable or offline, messages may be stored for a period and discarded based on criteria like number of re-tries or after a given timeout. Try to deliver this message once this week, then discard it. SMTP does not have this class of feature.
At dawn of Internet of Things, where number of devices transmitting messages over IP networks is projected to grow exponentially, what features and requirements should a messaging infrastructure include? It seems trusted identify, security and QOS are central concerns.
The internet, at its core is fundamentally a messaging platform.
Email (SMTP) is outdated, lacking core features, unreliable and insecure. It should and probably will be superceded by message queue technology (MQTT publish/subscribe).
Ideally, any future protocol should continue to be an open standard backed by a global consortium such as RFC from Internet Engineering Taskforce (IEEE).
Goodbye Multi Mime Part Email. Goodbye SMTP. Goodbye SPAM. it was nice to know you!