An Analysis of EMail for delivery of Clinical Data
February 26th, 2008 andrewAnalysis of SMTP
for Secure and Reliable Document Delivery.
It has been proposed that secure email in the form of S/MIME over SMTP (Simple Mail Transfer Protocol) be used for the transmission of documents such as Electronic Medical Records (EMR) with high reliability. This article discusses the limitations of using SMTP for such delivery based on its poor suitability to meeting the requirements for high reliability document delivery, in particular in the context of that required for EMR transmission.
To begin discussion, one needs to define what the requirements for high reliability of document delivery might look like. There principal factors are as follows.
- Timely Delivery. One should expect that a document be delivered within an acceptable timeframe. This can vary depending on the needs of the document, however for many types of EMR, delivery times are expected to be in the order of seconds or minutes, especially when the nature of the data they convey is likely to age quickly.
- In-Order. One should expect that documents originating from the same source be delivered in the same order in which they originate from the source.
- No Duplicates. One should expect that an original document be received once and only once at the destination.
- Detection of delivery failure. One should be able to notify the sender that delivery failed for whatever reason.
- Secure Delivery. One should expect that a document be delivered intact and free of alteration and also be subject to typical expectations of a secure transmission. There are several aspects of this but the principal components are encryption and authentication.
- Safe from Unsolicited input. One should expect that documents be originated only by originators who are authorized to transmit such documents and that the system is free from unsolicited documents being injected into it.
- Safe from Hijacking. One should expect that the delivery system at both ends be predictable and free from interference.
This list is not necessarily exhaustive, but covers most of the needs required for reliable delivery.
Now let us see how SMTP deals with these factors. I base my analysis on the experience I have gathered in more than 15 years in the development of email clients and servers and from managing an ISP.
Timely Delivery.
The SMTP system can transmit an email through its system very quickly under ideal conditions. Typically, times are of the order of < 1 minute and comprise the sum of the following components.
1. Transmission by the MUA (Mail User Agent) to the first MTA (Mail Transfer Agent).
2. Transmission by Intermediary MTAs to other Intermediary MTAs or the Destination MTA. This step may occur zero or more times.
3. Receiving the document from the destination MTA to the destination MUA.
In step 1 and 3, there may be hidden processes that the user is unaware of, such as virus scanner software or corporate email conversion gateways when the internal mail protocols is not SMTP. Some of the steps involve complex and time variable operations such as looking up the DNS system which further compounds any delays.
There are many factors that can impede the throughput of the MTAs. These include server failures due to hardware failure, server overload due to SPAM (unsolicited email), email worms, and other hostile Denial-of-Service (DoS) attacks directed specifically at a given server. In the short term, email may be delayed anything from 30 minutes up to 4 hours (depending on site configuration) if an intermediary email server is not available for reasons such as network deterioration of any sort, or general unavailability due to maintenance etc. Generally users of email accept that delivery is not necessarily immediate, their experience being that of the real world “snail mail”, the physical postal system. A minor temporary delay caused by a communication failure between MTAs can often cost up to several hours even when the temporary delay lasts only for a brief time like a few seconds. There is no way for a MTA to determine when to resend an email based on network conditions although some servers do have some degree of intelligence if there are a large number of emails waiting to be sent to a particular MTA. Generally if an email can’t be sent, it will be queued for resending with a retry of between 30 mins to 4 hours. There are no rules for how often email should be resent – it is entirely arbitrary and at the whim of the administrators of the MTAs.
However, when a mail server is in a non-optimal state, such as when an internet worm is at the peak of its activity or a rather active group of spammers are busy, mail can be delayed for more than 24 hours, sometimes several days, especially if the source of unsolicited email into the system cannot be controlled. Clearly such a level of delay for important documents such as EMRs would be totally unacceptable, and generally when such events occur, they are totally outside the control of the sender or receiver of these documents.
Another contributory factor towards server delays is that very often in a large organization such as a Telco or large ISP, the mail server may be providing service for 100,000 users or more. Having that many user active, although not necessarily concurrently using the server, does place a high demand on general throughput, and often throughput is sacrificed for scalability.
In Order
There is no concept of ordering delivery of emails in SMTP. Mail will get delivered whenever it can. Mail can and will arrive out of order, especially if delays occur for the many reasons outlined above.
No Duplicates
Generally, the mail system will not send duplicates as usually the MTAs will take ownership of an email as it transitions through the system. There are however occasions when these systems fail in various ways, and it is possible to receive duplicate emails, for example if a MTA has suffered a catastrophic failure and needed to be restored from a backup, or a poorly configured server having been fixed. Failures and mistakes do occur in the administration of sometimes unwieldy MTAs. One other source of duplicates is that due to significant delays in transferring an email, a sender may resend the message.
Detection of Delivery Failure
The SMTP system by nature is a push system. There is no inbuilt mechanism to notify that the MUA of the recipient has received the document. Although there are modest extensions to SMTP for the acknowledgement of delivery, they generally rely on end-end acknowledgement of some kind in the MUA software.
Secure Delivery
This is a wide topic and encompasses the issues surrounding S/MIME. As with all security related issues, absolute best practice in the industry should be followed at all times. For truly secure transmissions to take place, both encryption and authentication with fully verifiable PKI must be followed. Any weak link will reduce the ultimate security. Proof of identity through authentication is absolutely necessary.
Safe from Unsolicited Input
SPAM, internet worms and viruses, and mail bombing can have a very adverse affect on both MTAs and MUAs. The essentially anonymous authentication system which the SMTP system is based around allows for unsolicited email to enter the system unchecked. While good configuration of servers is important to prevent SPAM, spammers are evolving more advanced methods to circumvent these measures. Also the proliferation of consumer based computing systems with less than average immunity to Viruses, Trojans and various other Malware has seen the rise of internet worms which can penetrate even the best engineered consumer ISP networks.
Safe from Hijacking
While technically a security related issue, there is a range of attacks at the network management layer which could interfere with the safety of email transmissions. When a MUA sends and receives emails, they generally do so via an internet account of some kind. For transmission of email, the MUAs use SMTP, the same protocol used for MTAs to communicate, however at the final receiving end, MUAs typically use POP3 or IMAP to receive the emails from the MTAs. This invariably requires an authenticated login of some kind. While there are measures to prevent eavesdropping of usernames and passwords in such a service, generally one is restricted by what the ISP supplies. Often there may be no choice of authentication method (plaintext passwords are common), and the ISP will often not allow the customer to operate their own SMTP server at the customer’s premises, nor will they allow direct access to SMTP servers other than those operated by the ISP. Since passwords are sent in plaintext over the network, it is entirely feasible that the account login may be hijacked, possibly without knowledge of the recipient. For example an eavesdropper may read mail without leaving a trace, and could also possibly remove emails without the genuine recipients knowledge. Even if the emails are secured with S/MIME, they could still use the knowledge to harvest email addresses for other purposes such as denial of service. Emails when sent and received carry a good deal of additional header information, and this information could be used by a hostile attacker to find weaknesses in the SMTP systems which comprise the virtual EHR system.
Other studies
There have been a number of studies made on the reliability of email for general use. A Google search on the phrase “email reliability” brings up a number of useful links. Here are some references to get started.
http://en.wikipedia.org/wiki/Email discusses the basics of email.
http://itmanagement.earthweb.com/columns/executive_tech/article.php/3500506 cites some studies.
http://www.broadbandreports.com/shownews/36176
http://www.terryscomputertips.com/computers/email-reliability-in-this-internet-world.php
http://www.cbsnews.com/stories/2005/02/28/tech/main676962.shtml
Conclusion
This discussion only scratches the surface of the issues. Given the large number of points of failure for the SMTP system, it could hardly be relied upon for timely delivery of messages containing important documents where the age of the information is important. As for security, as long as best practices are followed, S/MIME should provide at least the same level of security as SSL or PGP encrypted HTTP since it uses tried and true Public Key Encryption. That however needs to be tempered with the reality that the login accounts of MUAs are still prone to hijacking in various forms. Since there are other more suitable protocols available that provide a more direct connection between endpoints (e.g. HTTP), one should consider that S/MIME be used only as a last resort when all else is unavailable. One would have a very poor internet experience indeed if the only services available were SMTP and POP3. That the SMTP system is the target of choice for the delivery of SPAM and other Malware should be sufficient warning to look at the alternatives.
My considered opinion is that using SMTP for the secure delivery of EMR is at best a poor second to better protocols like HTTP or SSH, and at worst a recipe for disaster - lawsuits from both the civil and medical fronts just waiting to happen.