When sending encrypted email using RMail services, the sender can choose one of the following options:
|Decryption at Recipient||Description|
|i. Pre-Arranged Password||Sender and receiver coordinate an exchange of a pre-arranged password the sender uses to encrypt and the recipient uses to decrypt the message.|
|ii. Schema Used for Password||Sender informs in the email body or subject of the schema that recipient should apply for them to input the decryption password (i.e. last 4 digits of social security number followed by birth year)|
| iii. Auto-Send of Password
|RPost system automatically transmits a separate email in advance to recipient, informing the recipient what the decryption password is for the forthcoming encrypted email.
The sender can opt to either generate their own sender decryption password, or set the RPost system to generate a random system generated decryption password.
|iv. Permanent Personalized Password||Upon receipt of first RPost encrypted email, recipient can opt to create a personal decryption password — all future email received encrypted using the RPost system from ANY sender, will convert en route to be able to be decrypted with the recipient’s permanent personalized password.
Note, if the sender is set to auto-send the decryption password set by sender by email to the recipient, and the recipient has set their own personalized decryption password, they will no longer receive the advance auto-send of email with the decryption password as the decryption password will have been converted en route to be the recipient’s personalized decryption password.
|v. Re-Direct to Transport Layer Encryption||En route to the recipient, RPost system tests the recipient connection and if determined to be able to accept a secure transfer with the TLS protocol, RPost converts to a message format for TLS encrypted transfer – recipient does not need to decrypt as the email is decrypted by the recipient server automatically. If the secure connection terminates early or is not available, the RPost system reverts to message level encryption for delivery.|
|vi. Large File Encrypted Transfer||The sender can opt to transmit an attachment or very large files such that the recipient can collect them through a secure connection and decryption password process as described in points (i) – (iv) above.|
Note, the sender can set their domain or email address to prepare the message such that it automatically uses one of the above methods for the recipient to decrypt/view the message.
For example, the sender could opt to start with scenarios (i), (ii), or (iii) and send the recipient an introductory encrypted email, suggesting (or requesting) the recipient to create their own personalized password as described in scenario (iv). Or, the sender could opt to start with scenarios (i), (ii), or (iii) and have the RPost system automatically test and deliver as described in scenario (v) or revert back to scenarios (i), (ii), or (iii).
In summary, consider with RPost service the sender can opt to send encrypted messages by Message-Level Encryption, Transport Layer Encryption, or a combination. As such, there are four scenarios for encrypted transmission. In all cases, the encrypted message is delivered direct to the recipient’s desktop; RPost never requires the recipient to visit a website to collect their email unless large file transport service is used.
SENDER ——— Path A ——–> SERVICE PROVIDER (RPOST) ——- Path B ——> RECIPIENT
|Encrypted Data Flow||Path A||Path B||Recipient Decryption|
|1. Desktop-to-Desktop||Message-Level Encryption||Message-Level Encryption||Methods (i), (ii), (iii), (iv), (vi).|
|2. Desktop-to-Server||Message-Level Encryption||Transport Layer Encryption||Method (v)|
|3. Server-to-Desktop||Transport Layer Encryption||Message-Level Encryption||Methods (i), (ii), (iii), (iv).|
|4. Server-to-Server||Transport Layer Encryption||Transport Layer Encryption||Method (v)|
1. OPTIONS FOR PATH A: SENDER TO PROVIDER
A sender using RPost’s Outlook plug-in has two administrative settings. Once set by the sender or sender IT department, they are transparent from a user perspective. When sending Registered Email™ messages with the encryption option selected, the message will either:
- Message Level Encrypt. This is done locally at sender’s desktop (invisible to sender) using an embedded RPost digital certificate for PKI encryption. The sender does not need their own digital certificate.
- Transport Layer Encrypt. This is done by transmitting, relying on TLS transmission encryption. Here, the sender would need assurance that they were transmitting to RPost using TLS encryption (or SSL encryption for large file transfer).
2. OPTIONS FOR PATH B: SENDER TO PROVIDER
RPost will deliver the sender’s message encrypted, using one of the following techniques as selected by the sender in their administrative settings:
1. Message Level Encrypt. This is done using 256-Bit AES PDF encryption salted with a unique decryption code. The email body text is converted to PDF and encrypted with the attachments embedded in the PDF in their native format. The receiver receives a Registered Email™ message with the encrypted message attached in PDF format.
2. Transport Layer Encrypt. If the sender has selected this option, RPost tests to determine if the receiver server supports and will accept at that moment a secure connection for TLS encrypted transmission. If it can, RPost delivers the message via the encrypted connection to the recipient server and the message displays in the recipient’s inbox in a standard email message form with markings on it so the sender knows that it had been transmitted encrypted and contains sensitive or protected information.
3. AUDITABLE PROOF OF ENCRYPTED DELVIERY
It is important to note that will all options, the sender does receive verifiable and auditable proof of compliance with regulated (HIPAA, FSA, GLB, FDCPA, etc.) encrypted delivery requirements – a patented capability unique to RPost service. These options discussed can be sent by individual senders or sender’s IT departments, in most cases.
Consider the Council of Insurance Agents and Brokers (CIAB) top level evaluation criteria in their recommendations.
When considering data breach, we are considering two points, a data breach when the data is (a) within the sender’s control (i.e. where the email is sent from sender to recipient – “security of sender-controlled data”); and (b) after the data leaves the sender’s control (i.e. if there is a data breach on the recipient’s system or after the recipient forwards the information on to others – “downstream data breach”).
In reference to protection from downstream data breach, CIAB cites as the most important criteria, as having “Auditable proof of compliance”.
CIAB goes on to state, “It seems that only RPost has a robust mechanism in place to provide an auditable record of precisely what message content (body text and attachments) was in fact sent and received in an encrypted manner to each intended recipient. This is important because, in the case where there is a data breach after the email has reached the recipient (in the recipient’s environment, or after they have passed the information along to others), the sender will need to retain information to prove that the breach did not happen “on their watch” – that they in fact complied with the data security requirements and delivered the information in a compliant, encrypted manner.
RPost addresses this issue by having built its encrypted email service on top of its core Registered Email™ service, which The Council of Insurance Agents and Brokers endorsed in 2004 as the best way to prove email content, time, and delivery with court-admissible records. By doing this, RPost provides not only effective encryption, but also the most robust proof and record of compliance with the rules of regulators.