Posted: 14 Nov 2018 10:16 EST Last activity: 16 Nov 2018 4:33 EST
Email listener not able to decrypt email.
Email listener is processing plain email (not encrypted).
But there are some secure systems which are sending encrypted email to our listener inbox and listener is failing to process with below error for same.
PRPC failed to process the attached email.
The reason(s) for the failure may be internal to the application or caused by external dependencies.
The following issues were detected during processing:
* Unable to decrypt email MIMEMessage:
* Key not found for Listener's email address
* No certificates found for Listener's email address
You may need to verify the state of inbound and/or outbound mail servers.
Please check PRPC logs for details.
I tried to open the encrypted email received in listener inbox using my desktop outlook client but it was failing with "Your Digital Id Name Cannot Be Found By The Underlying Security". So imported required certificate in my outlook and now I'm able to read the encrypted email.
So I am looking for how and where to import this certificate so that listener can read the encrypted message.
The Sender of these emails must have used a specific certificate to encrypt these emails.
Find out who sent them - and ask them to tell you who they are meant for. (And which Certificate they used to encrypt, and where they got that from).
I'm *pretty* sure PRPC isn't able to decrypt incoming s/Mime emails: and (personally) I think this is probably just fine:
I'm not sure what the use-case would be to give the Email Listener an s/Mime key (or indeed a set of keys?) enabling it to decrypt incoming emails - only (presumably?) to translate them automatically into plain-text and save them ? (The *transmission* encryption - see below - is enough I would say?)
(Note: PRPC *is* able to *encrypt* (outgoing) emails for sure: but that doesn't require a secret key - only a public certificate: and there *is* a use-case for this).
The PDN articles given above, although they also relate to encryption : relate to the *transmission* of emails in a secure way - once the email have reached their destination, they are effectively plain-text again.
SSL/TLS here acts a 'secure envelope' while emails are in transit; but S/Mime means the 'letter' itself is written in a 'secret code'.
I hope this makes sense; and if I'm wrong about the Email Listener not being able to decrypt - I hope somebody can correct me.