To allow an organization to adopt ePOST as its email infrastructure, ePOST must be able to interoperate with the existing email infrastructure. We sketch here how ePOST could be deployed in a single organization and interoperate with email services in the general Internet.
For inbound email, the organization's DNS server provides MX records referring to one of a set of POST nodes within the local organization. These nodes act as incoming SMTP mail gateways, accepting messages, inserting them into POST, and notifying the recipient's nodes. Suitable headers are generated such that the receiver is aware the message may have been transmitted on the Internet unencrypted. If no identity block can be found for the recipient in the local overlay, then the email ``bounces'' as in server-based systems.
The incoming mail gateway nodes need to be trusted to the extent that they receive plaintext email messages for local users. Typically, the desktop workstations of an organization's system administrators can be used for this purpose. These administrators own root passwords that allow them to access incoming email in conventional, server-based systems. Thus, ePOST provides the same privacy for incoming email from non-ePOST senders as existing systems.
Sending email to the outside world first requires determining that the desired email address is not already available inside the ePOST world. At that point, there may be a gateway service that can provide the appropriate certificate material to generate a standard cryptographic email in S/MIME or PGP format. This encryption is performed in the sending user's local node, before the data goes onto the network. If the recipient does not support secure email, then the email must ultimately be transmitted in the clear, so the ePOST proxy server can speak regular SMTP to the recipient's mail server.