What Does It Mean to “Certify” Email?
by J.D. Falk
Director of Product Strategy
- Image via Wikipedia
The concept of “certified” email has been around for a long time. For example, Return Path Certification is a whitelist (actually two whitelists) consisting of IP addresses controlled by entities who send email which meets our certification standards. One of our competitors has a more complex system whereby entities who meet their certification standards are permitted to purchase virtual stamps, which are applied to individual messages via their own proprietary software. But in both cases the “certificate” is tied to the behavior of the source of the message, rather than to any characteristics of the message itself; for legitimate bulk email, that’s proven to be the best strategy.
This is all very different from the old-fashioned paper concept of certified mail, wherein your local postal carrier charges a bit extra and in return pays extra attention to what happens to your envelope or package. The sender receives a receipt proving that the postal service accepted the package, and may also receive an additional receipt indicating that the postal service delivered the package to the intended address. In some cases, this second receipt must include the signature of the recipient, or of some responsible party at the receiving address.
In the certified email concept, what’s been certified is that the sender of the message is following a set of standards or practices, and thus the message should receive preferential treatment: inbox placement, images automatically displayed, et cetera. In the certified postal mail concept, what’s certified is that the message was successfully sent and/or delivered and/or received, depending on the level of service. The same word, applied to different aspects of the transaction, results in entirely different products.
There’ve been various attempts to apply the postal concept of certified delivery or receipt to email. Years ago Claus Aßmann described the options and challenges for receipt notification using existing email standards. The primary issue is that it’s optional for both sides of the transaction: lack of receipt could mean the message didn’t reach its’ intended destination, or but it’s far more likely that the recipient’s mail software simply didn’t respond to the receipt request.
Proprietary solutions have found some success within communities of correspondents who need hard legal proof that a message was delivered and received; that’s what our partner RPost specializes in. Until now these have always been closed systems, relying on custom software on both the sending and receiving side. Sometimes the recipient has to click on a link and log into a web site to view and interact with the document, using email only as the method of notification; with others it’s an encrypted MIME part which most MUAs see as an attachment, and software on the recipient’s desktop is required to decode it.
There’s now an open standard, designed by the National Center for Informatics in the Public Administration of Italy (DigitPA) and soon to be published by the IETF as an Informational RFC. They’ve performed an interesting trick, creating a technical standard which matches the legal definition (in Italy) of Posta Elettronica Certificata (PEC) — certified electronic mail. If you can read technical specifications in Italian, click here; for English, click here.
Warning: extreme oversimplification ahead. Proceed with caution.
PEC tries to remain compatible with email as it exists today, which is always nice to see. A message is wrapped in a PEC “envelope,” basically an S/MIME signature with particular characteristics. Some of the original message headers are preserved, while others are transformed, and yet more are added. There are new requirements for transport and storage of messages, for logging along the way, and of course for disposition notification: was it read? Was it ignored? Was it quarantined because it contained a virus? (Seriously.)
What ties it all together is a centralized LDAP server, containing both S/MIME certificates and information on every PEC message signed by those certificates. So in effect, even though it is based on open standards, users of this scheme will still have to agree upon a single central authority who manages this LDAP server. Presumably the Italian government will choose to run their own; it may be more difficult for the average user elsewhere.
Incredibly, even without the certified delivery receipt provided by PEC or RPost, some courts already trust email enough to deem it an appropriate method of delivering court orders. In Canada, under some circumstances you can even use Facebook.
Will this PEC standard catch on? Dave Crocker’s review of the specification describes the issues (as he sees them) in great detail, concluding “It is widely — and I believe correctly — held that the primary barriers to success for this class of service are matters of operational and end-user usability.”
In other words: PEC has stumbled upon the messy border between what users want and expect, and what technology can accomplish. But then, isn’t that always the challenge?