Although SmarterMail is able to send & receive S/MIME encrypted email via POP3/IMAP/EAS/EWS/MAPI/SMTP when using an email client that supports S/MIME encryption, the SmarterMail webmail is unable to generate or view S/MIME encrypted messages as there is no Key Pair mechanism contained in the webmail. 

In order to view the S/MIME message you would need to have the Private Key for the Key Pair that was used to encrypt the message loaded into memory in the email client to decrypt and view the message. Without the Private Key the message cannot be decrypted and viewed.

As S/MIME is an end-to-end security measure it is not intended for webmail where email is still classified as "in transit" instead of "at rest". The IETF RFC 8551 requires the Private Key be kept accessible to the user but inaccessible from the mail server, which cannot be done with webmail.

So it's a technical limitation of webmail...

My question is: is this limitation general to ALL webmails, or does it only occur with SmarterMail?

In this case, if I try with GMAIL or Exchange Online will I have the same problem or are they able to display the message?

(note: I will have some test messages sent and I will also do some tests with GMAIL, Exchange Online and other webmails... But I can't do it right away...)

I add:

the problem occurs even if I MYSELF write an email from SmarterMail webmail and simply attach a signed file (typically a signed PDF that has the extension .p7m).

In this case, after sending the email, I can't even read the email myself (which I find in the SENT ITEMS folder) because the above warning appears...

Is it normal?

Yes, this is an inherent design limitation of webmail environments.  If you give away your key to the mail server, it is no longer private to you.  If you don't give it away, you cannot use webmail from any location.   There are some products that try to hack the problem, but I  recommend staying away from them. 

We have added this functionality to webmail in our upcoming release of SmarterMail, which is coming to BETA soon! Since this has been implemented internally and will be coming soon to a public download, I'll mark this thread as Resolved. 

It depends on the mechanism you are using for message encryption and decryption. We use an appliance that is doing it and the message arrives decrypted in the mailbox so you are able to read it.

To be more specific about what new functionality exists, we will now verify signed email. I believe this applied to both S/MIME and PGP. Encryption is still on the clients to do. Webmail does not support reading/writing encrypted email at the moment we can only show you that it IS encrypted, as this would involve uploading your certs to webmail. It's a big can of worms.

Hello Matt

Thanks, I see that the same way as you do. The problem with encryption and decryption is that the PublicKey must be publicly accessible or attached to the mail and the PrivateKey must be managed locally, in a multi-tenancy environment you have the problem of inter-mandator routing meaning a mail would be encrypted but not mer decrypted so you have to work with gateways there.

I have good experience with an encryption appliance like Seppmail / CipherMail etc..

Incoming mailflow:

Sender > Spamfilter > CipherMail > Relay on SmarterMail

Outgoing mailflow

Sender > SmarterMail > CipherMail > Outbound SMTP or direct send to recipient

greets, Roger