Initial situation:

The email client of the user has encrypted emails which are illegible for them stored.

 

Cause:

1.The key material was migrated from a decentralised encryption structure to the central SEPPmail Secure E-Mail Gateway. The still encrypted emails stored in the client can thus no longer be read.
 

2.Emails will bypass the SEPPmail Secure E-Mail Gateway and reach the internal email server
 
Individual remedy:
The email flow is to be routed in a way that all incoming emails are routed via the SEPPmail Secure E-Mail Gateway.
 

3.The SEPPmail Secure E-Mail Gateway cannot decrypt the incoming emails but is configured in a way that it does not reject them (see Mail Processing Ruleset generator Encryption Incoming e-mails Reject mails if S/MIME decryption fails)
 
Individual remedy:

a.Activate Reject mails if S/MIME decryption fails
 

b.Check where the thus encrypted emails come from. It is possible that the Managed Domain Service has been activated for a domain which does not possess the matching private key (see EDIT MANAGED DOMAIN Settings S/MIME domain keys Create S/MIME domain keys for managed domain encryption for this domain and send public key to vendor pool).

 

Question:

How can encrypted emails locally stored in the email client be decrypted?

 

Answer:

At first, the option Reprocess mails sent to reprocess@decrypt.reprocess (see Mail Processing Ruleset generator General settings) must be activated.

The user must pack the encrypted email as an attachment in a new (carrier) email (do not forward!) and send it to the address "reprocess@decrypt.reprocess". The SEPPmail Secure E-Mail Gateway discards the carrier email, and the original, encrypted message in it is processed again and delivered. Naturally, one precondition is that the required private key for decryption of the SEPPmail Secure E-Mail Gateway is known.