"Message could not be encrypted"

Good afternoon,

I've the following problem:

An external user is configured for mandatory encryption (to receive only
encrypted emails).

We have different users in our organization he wants to communicate
with, some of them encrypted, some unencrypted (unencrypted only in
incoming direction!). If that external user send's an unencrypted email
to one of our internal users, that email get blocked with an error

"The message with Subject

<Subject>

has not been sent to the following recipients because the message could
not be encrypted"

According to the documentation, the locality should determine the
direction of encryption, it seems that this doe not work as intended.

Is there any configuration setting to prevent that ?

regards

Christian

The gateway tries to encrypt if the recipient is an external recipient,
i.e., the locality property for that user is set to external, and
decrypt if the recipient is an internal recipient, i.e., the locality
property for that user is set to "internal".

My initial guess is that you did not configure your "internal users"
(i.e., the users for which you handle email) as having the "Internal"
locality. Check whether you have added a domain object for all the
domains you handle the email for (i.e., the list of MTA relay domains)
and that those domains have the locality property set to "Internal".

Because the default value for locality is "External", you need to
explicitly set this to "Internal" for the domains you handle the email for.

Kind regards,

Martijn Brinkers

···

On 11/18/2015 02:53 PM, christian(a)herndler.com wrote:

Good afternoon,

I've the following problem:

An external user is configured for mandatory encryption (to receive only
encrypted emails).

We have different users in our organization he wants to communicate
with, some of them encrypted, some unencrypted (unencrypted only in
incoming direction!). If that external user send's an unencrypted email
to one of our internal users, that email get blocked with an error

"The message with Subject

<Subject>

has not been sent to the following recipients because the message could
not be encrypted"

According to the documentation, the locality should determine the
direction of encryption, it seems that this doe not work as intended.

Is there any configuration setting to prevent that ?

--
CipherMail email encryption

Email encryption with support for S/MIME, OpenPGP, PDF encryption and
secure webmail pull.

Twitter: http://twitter.com/CipherMail

That did it, thank you !

Christian

···

On 18/11/15 15:16, Martijn Brinkers wrote:

On 11/18/2015 02:53 PM, christian(a)herndler.com wrote:

Good afternoon,

I've the following problem:

An external user is configured for mandatory encryption (to receive only
encrypted emails).

We have different users in our organization he wants to communicate
with, some of them encrypted, some unencrypted (unencrypted only in
incoming direction!). If that external user send's an unencrypted email
to one of our internal users, that email get blocked with an error

"The message with Subject

<Subject>

has not been sent to the following recipients because the message could
not be encrypted"

According to the documentation, the locality should determine the
direction of encryption, it seems that this doe not work as intended.

Is there any configuration setting to prevent that ?

The gateway tries to encrypt if the recipient is an external recipient,
i.e., the locality property for that user is set to external, and
decrypt if the recipient is an internal recipient, i.e., the locality
property for that user is set to "internal".

My initial guess is that you did not configure your "internal users"
(i.e., the users for which you handle email) as having the "Internal"
locality. Check whether you have added a domain object for all the
domains you handle the email for (i.e., the list of MTA relay domains)
and that those domains have the locality property set to "Internal".

Because the default value for locality is "External", you need to
explicitly set this to "Internal" for the domains you handle the email for.

Kind regards,

Martijn Brinkers