ummm, hello?  anyone?

Quite the echo in here. You've probably googled this yourself but here's what I found. Note: Not tested.

From the EPiServer Mail Developer's Guide (note: this is for v 4.3, latest is 5 R2 I think but I could not find a PDF of it):

"EPiServer Mail Order Mail Specification 2.0 has support for RSA/AES-based encryption. If the
<BrokerPublicKey> parameter in EPiServerMail.config contains a valid public key at EPiServer Mail Editor
initialization; all outgoing order mails are encrypted."

"EPiServer Mail creates a unique symmetric key and uses it to encrypt the order mail content (found starting at -----BEGIN ORDERMAIL MESSAGE-----). The symmetric key and initialization vector is then encypted with the custom public RSA key of the EPiServer Mail installation and supplies it for decryption on the server side"

http://world.episerver.com/PageFiles/22706/Developers%20Guide_Rev4.pdf

Hi Arild.  Yes, I thought these forums were active, but I guess not.

What we are actually looking for is a way to encrypt recipient information (email addresses, names etc.).  We do not need to encrypt the outgoing emails.

Anyway, thank you for taking the time to reply.

Hi,

I actually think that this is the encryption that you're looking for.  How it works is like this:
In your EPiServer Mail installation, you collect the following data:

• Subject
• HTML body / Text body
• HTML recipient list / Text recipient list
• Scheduling information

This information is packed together in an "order mail" which is sent to your broker address (specified in the EPiServerMail.config, something@episervermail.episerver.com). This email is encrypted if the proper RSA keys are also present in the configuration file. That means that everything in the bullet list above is encrypted on its way to the server farm that will deliver the emails.

The EPiServer Mail service takes your ordermail, and creates one individual email for each recipient in the order mail, and that email is then delivered its recipient. That email is however not encrypted, but the most sensitive one (that contains the full recipient list and other stuff) is, which is what you want -- I think?

Thanks for the reply.

But what we need is for the recipient data to be encrypted while it sits in our CMS database.  The data "at rest" needs to be encrypted.  i.e. if someone were to gain access to the Recipient table in our database they would not be able to see any of the data.  It would be encrypted.

In that case, what you need is a recipient source. There is a sample implementation on this available for download here: http://world.episerver.com/Download/Categories/Modules/EPiServer-Mail/

and some documentation on the classes here:

http://world.episerver.com/Documentation/Items/Developers-Guide/EPiServer-Mail/Developers-Guide---EPiServer-Mail-50/Developers-Guide_Rev4/

Hope this helps!

I am however a little bit unsure about one part of this; after the emails have been retrieved from the external system (or rather, the custom recipient source), I believe that parts of them are saved to internal tables in EPiServer Mail to handle click statistics and unsubscriptions. If you are able to live without this functionality, there could be ways around storing it.

Ok, so maybe it is starting to come together.

In the use case of sending out a new mailing, step 1 is to import a list of recipients into EPiServer.  Here we would implement the IRecipientStore interface so that it encrypts the data before saving it to the DB?

And step 2 is to then send emails using the recipient list created above.  Here we would implement the IRecipientSource interface so that it decrypts the values upon retrieval?  And any time this particular recipient list is chosen it would know to use our custom recipient store?

Regarding your last post.  If we encrypt the email addresses before storing them in the Recipients table, they would be encrypted everywhere, right?  Which is good, but are you saying that this might break some other functionality such as statistics and unsubscriptions?

Thank you for the reply!

Well, the interfaces that you mention are intended to be a connection to a database somewhere that would store the actual email addresses, be it a Community, a flat file, or a CRM system. So these interfaces provide a "connection" for EPiServer Mail to retrieve the addresses. In order for us to reach the intended recipients, we will need to have access to the actual email addresses, so that we can put them in the order mail, and sent that on to the episerver mail server farm for onwards distribution to the recipients.

However, because the IRecipientSource will need to retrieve the plaintext addresses, the system will use them as it will with any other address from any of the built in sources. That means, it will (if I remember correctly) store the addresses that have opted out so that they will be excluded from any future mailings, if this data cannot be saved by the source. It will also save the recipient and the particular mailing for click statistics.

In short, there may be reasons for EPiServer Mail to store the email address regardless of the source in its own tables. If it does, it will save the plaintext address since that is what the source will need to provide in order for the mailing to reach its recipients.

Ok, let me digest this info for a bit.  Thanks again for the replies.

Follow up question.  Can the email tables be in a different database from the main CMS for a site?

i.e. we have an existing EPiServer CMS site.  We are adding Relate to it.  Can we set it up so that the tables for EPiServer Mail are in a different database than the tables for the main CMS for the same site?

If so then we could just encrypt the Mail database with TDE and be done with it. maybe.

Hi,

I'd look for other options. Even if it might be possible with older versions, this would put you in a situation which may hinder future upgrades.