How to Decrypt an Encrypted Email – Simplify Recipient User Experience

When sending encrypted email using RMail services, the sender can choose one of the following options:

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

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:

1. 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.
2. 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”).

Know more: Secure Email

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.

You might also like