The core RPost software and functionality is located on server infrastructures called the "RPost Registration System." These servers contain the core Registered E-mail® operational software and systems to prove delivery and content of e-mail, to add a Digital Seal™ to e-mail, to validate the Registered Receipts™ , and to generate Receipt and e-Mail Authentications.

The RPost Registration System™ receives and processes only e-mail that has been tagged by the sender to be "Registered". It is important to note that the RPost Registration System™ does not retain any e-mail or any components of an e-mail (read more).

RPost encryption uses the Microsoft CryptoAPI 2.0 NIST FIPS-141-1 validated instances of the SHA-1 and 3DES (triple DES) algorithms.

RPost's technology, business policies and practices, and physical and network facilities have been inspected and certified by the U.S. Government as meeting Federal Standards for the handling of critical and confidential messages. The United States Postal Service sponsored U.S. Government inspectors, TRW Information Systems Security Officers, and PriceWaterhouseCoopers Information Systems Security consultants to perform a full Risk Assessment and Sensitivity, Criticality, and Accreditation review of the RPost Registration System™ . The result was the United States Postal Service Accreditation of the RPost Registration System™ for sensitive and critical government applications and certifying industry best practices for network security, availability, and business procedures. Registered E-mail® complies with the U.S. Privacy Act.

The United States General Services Administration (GSA) has approved the RPost Registered E-mail® product and pricing, and AT&T,, Sprint, and Qwest's government divisions offer Registered E-mail® for acquisition through the GSA Information Technology Federal Service Supply Schedule 70. In addition, AT&T certifies the availability of the Registered E-mail® service for customers.

RPost is Bobby Approved. Bobby tests web pages using the guidelines established by the World Wide Web Consortium's (W3C) Web Access Initiative (WAI), as well as Section 508 guidelines from the Architectural and Transportation Barriers Compliance Board (Access Board) of the U.S. Federal Government.

The RPost Registration System™ has over twenty patents pending with the core patents filed in countries around the world.

Common Questions:

What are my service integration options?
Mail Server Filter or Desktop Client Plug-in:

An RPost Mail Server Filter is software package designed to integrate with the customer mail server itself. The core functionality of the filter is to parse the subject line of all outbound messages and check for the presence of a message tag at the beginning of the subject line that indicates that the message is to be "Registered". An example of such a tag is: (R). The filter will reroute messages that are indicated by such a tag to the RPost Registration Networks. All other messages will be routed normally.

RPost currently has filters for most major enterprise mail servers.

An example of an RPost Desktop Client Plug-in is a COM+ Add-In for Microsoft Outlook e-mail clients. When the RPost package is installed it adds a 'Send Registered' button to the message compose window and the Registered E-mail® Options to Tools/Options tab. The user would use the "Send Registered" button to send only those messages via the RPost Registration Networks. The software uses a re-addressing method to redirect the message.

This functionality exists in Microsoft Outlook. What can Registered E-mail® offer me that Outlook message tracking and read receipts cannot?
Microsoft Exchange can utilize the read receipt and delivery receipt features for message tracking for internal messages. Microsoft Outlook can also request a read receipt for external Internet messages. The Microsoft read receipt feature however requires interaction and compliance on the part of the recipient as well as a compatible mail client. Such a read receipt is also a plaintext file that offers no protection of integrity. This is very different from the service the RPost offers. RPost creates a Delivery Receipt that will prove the time sent and delivered, the content (including any attachments) delivered and the delivery status. RPost uses industry standard cryptographic technologies in a unique way to ensure that validity and integrity of the receipt.

Are Microsoft Read Receipts™ compatible with RPost technology?
Yes. RPost Delivery Receipts can incorporate the information generated by Microsoft Outlook clients into the data gathered for delivery status information. However, this is only one of a number of methods utilized to verify delivery status.

We have a PKI implementation in our environment. Does this eliminate the need for Registered E-mail?
No. A PKI implementation does not eliminate the need for Registered E-mail®. In an environment where a PKI system is correctly implemented, digital certificates can be used to provide message integrity, confidentiality, authenticity and non-repudiation. The recipient of a message can use the PKI system to prove the integrity and authenticity of a message assuming the chain of CA trust is valid and unbroken. However, the sender cannot use PKI to prove that a message was delivered to an external recipient. In fact the PKI system does nothing for the sender to verify and prove message delivery. The RPost system can work in conjunction with the PKI system to add value to the messaging process with proof of delivery. Further, RPost Digital Seal technology can extend authentication to the second, third+ recipient as e-mail is forwarded (recipients can verify authorship and original content). With PKI systems, often the act of forwarding an e-mail breaks the capability for a future recipient to verify the e-mail origin and authenticity.

How does Registered E-mail® integrate with PKI implementations?

1. Outlook Digital Certificate Integration options.
The RPost Add-In for Microsoft Outlook has the option to integrate with users' digital certificates. However, this option is only compatible with certain PKI implementations. The Registered E-mail® software can utilize commercial X.509 certificates that are stored in the Outlook Local Address Book for recipients. The user can configure one certificate from the local user certificate store to be defined as the e-mail user certificate. If this option is used the Outlook, a user can send "Registered" messages that are encrypted and signed using the RPost Add-In.

2. RPost Mail Server Filter and PKI Integration.
If an RPost Mail Server Filter is installed then mail clients can send "Registered" messages using the subject-line tagging method (see RPost Mail Server Filters above). If this method is used, then messages can be encrypted using any PKI implementation.

How can I trust the security of the RPost system?
Security is of paramount importance to RPost at every level. To this end all business infrastructure, procedures and policies are designed to meet strict security standards.

RPost classifies all customer e-mail as both sensitive and critical and takes appropriate measures to ensure the security and availability of this information. Also note that RPost information systems do not store customer messages. Third party accreditation of RPost infrastructure and operations was undertaken by the United States Postal Service in the form of a Security Certification & Accreditation process. This was broad in scope covering everything from network security to financial stability and viability. Various USPS contractors were used in the process including TRW and PriceWaterhouseCoopers. The conclusion of the process was that RPost's infrastructure and operations ensure scalability, security, availability, performance and resilience.

For further information on RPost security request the whitepaper: "RPost Security Certification".

Can you prove that the message was opened?
The RPost system uses a variety of methods to establish the delivery status of Registered E-mail®. The ability to prove whether the message was opened depends on the technical configuration of the recipient environment. RPost can prove a message was opened in some but not all cases.

Can the recipient mail server prevent you from proving delivery?
The minimum standard for proof of e-mail delivery is delivery to the mail server. If a message is delivered, the RPost system will gather evidence to prove this in 100% of cases.

Is any action required on the part of the recipient to prove delivery?
No action is required on the part of the recipient to prove delivery. If the recipient acknowledges delivery through the use of existing read receipt technology (eg. Microsoft Outlook read receipt) then this information with be utilized to further enhance the delivery status information.

When I opened your email, a pop up appeared asking me to confirm receipt. I marked "no". Did you still obtain a receipt for the delivery?
Yes. Confirmation of receipt by the end user is not required to prove delivery. However, if the end user does confirm receipt in this way the information will be used.