Discussion:
[Djigzo users] How to set ciphermail to not decrypt emails
Stephane
2014-08-12 20:29:39 UTC
Permalink
Hello,

I have been running my first deployment of ciphermail/djigzo for a few days, and I like it a lot.

I managed to configure pretty much everything how I wanted, but there is one thing which I could not find: is it possible to instruct the MPA not to decrypt incoming emails even if it has the correct private key to do it?

My use case is the following: I would like to use ciphermail to enforce outbound encryption and signature. On the other hand for inbound messages there is no enforcement of receiving only encrypted emails. However if received emails are encrypted I would like this to be more visible to users than just via the headers (as would be the case if decryption is done at MPA), and also ensure a maximum security in keeping the secrecy as close to the reader client as possible. I do not need virus/spam checking for encrypted messages at the gateway level.

One other reason for the request is that I suspect a bug, or at least an incompatibility with signed+encrypted messages that get incorrectly transformed into a message with a single attachment called smime.p7m which the webmail cannot identify. This occurs every time I receive a signed+encrypted email generated at the external sender from outlook through ciphermail and have cipermail decrypt the message (my server is set to not remove signature from messages - again I want users to have a maximum visibility of what happens to their communications). This was raised previously to this list (july 21st) but I could not see a final answer.

Once more, thanks for this great piece of software,

St?phane
-------------- next part --------------
A non-text attachment was scrubbed...
Name: smime.p7s
Type: application/pkcs7-signature
Size: 5695 bytes
Desc: S/MIME Cryptographic Signature
URL: <http://lists.djigzo.com/pipermail/users/attachments/20140812/91f057b8/attachment.bin>
Stefan Michael Guenther
2014-08-13 06:28:55 UTC
Permalink
Hi Stephane,
One other reason for the request is that I suspect a bug, or at least an incompatibility with signed+encrypted messages that get incorrectly transformed into a message with a single attachment called smime.p7m which the webmail >cannot identify. This occurs every time I receive a signed+encrypted email generated at the external sender from outlook through ciphermail and have cipermail decrypt the message (my server is set to not remove signature from >messages - again I want users to have a maximum visibility of what happens to their communications). This was raised previously to this list (july 21st) but I could not see a final answer.
we had a similiar problem with the smime.p7m attachement and Martijn solved it for us:


<quote>
For the record, since it might help someone else having a similar
problem, it turned out that the message was correctly decrypted however,
the resulting message was opaquely signed. An opaquely signed message
can only be read with an S/MIME aware application (a clear signed
message can be read like a normal email). Since the mail application
that had to extract the attachment was not capable of reading S/MIME
opaque signed email, it did not detect the attachment. The solution was
to have the gateway remove the digital signature by checking the
advanced S/MIME setting "Remove signature". The will remove the S/MIME
signature which then results in a normal email with the attachment.
</quote>

Stefan
Martijn Brinkers
2014-08-13 06:48:11 UTC
Permalink
Post by Stephane
Hello,
I have been running my first deployment of ciphermail/djigzo for a
few days, and I like it a lot.
I managed to configure pretty much everything how I wanted, but there
is one thing which I could not find: is it possible to instruct the
MPA not to decrypt incoming emails even if it has the correct private
key to do it?
My use case is the following: I would like to use ciphermail to
enforce outbound encryption and signature. On the other hand for
inbound messages there is no enforcement of receiving only encrypted
emails. However if received emails are encrypted I would like this to
be more visible to users than just via the headers (as would be the
case if decryption is done at MPA), and also ensure a maximum
security in keeping the secrecy as close to the reader client as
possible. I do not need virus/spam checking for encrypted messages at
the gateway level.
The gateway has been configured to always decrypt if there is a private
key available. In your case there are a couple of options. One option
would be to not relay email for your incoming domains through the
ciphermail gateway. Whether or not this works depends on your email
setup. Another option would be to change the mail flow. The complete
mail handling is described in the file config.xml. You can disable or
side-step the decryption part.
Post by Stephane
One other reason for the request is that I suspect a bug, or at least
an incompatibility with signed+encrypted messages that get
incorrectly transformed into a message with a single attachment
called smime.p7m which the webmail cannot identify. This occurs every
time I receive a signed+encrypted email generated at the external
sender from outlook through ciphermail and have cipermail decrypt the
message (my server is set to not remove signature from messages -
again I want users to have a maximum visibility of what happens to
their communications). This was raised previously to this list (july
21st) but I could not see a final answer.
This is not a bug but caused by the signing format of the sender. S/MIME
signatures come in two flavours: opaque signed and clear text signed.
With an opaque signature the message is encoded in a way that only an
S/MIME capable reader can show the message. An opaque message has an
smime.p7m attachment. The smime.p7m attachment is not encrypted and can
be opened with an S/MIME capable reader without requiring the private
key, With S/MIME clear signing the message is a normal message with an
smime.p7s attachment and can be viewed by a normal email client. Outlook
for example uses opaque signing when the message is signed and
encrypted. Therefore after encryption, the message will be an opaque
signed message with the smime.p7m attachemnt, Since you talk about
webmail I guess your webmail client does not know how to decode the
signed smime.p7m attachment. The workaround is to enable "remove
signature" option since this will convert the signed smime.p7m into a
normal message.

Kind regards,

Martijn Brinkers

PS you send the message with a different email address than the email
address you are registered with to the mailing list.
--
CipherMail email encryption

Open source email encryption gateway with support for S/MIME, OpenPGP
and PDF messaging.

http://www.ciphermail.com

Twitter: http://twitter.com/CipherMail
Stephane Schitter
2014-08-13 16:12:12 UTC
Permalink
Post by Martijn Brinkers
Post by Stephane
Hello,
I have been running my first deployment of ciphermail/djigzo for a
few days, and I like it a lot.
I managed to configure pretty much everything how I wanted, but there
is one thing which I could not find: is it possible to instruct the
MPA not to decrypt incoming emails even if it has the correct private
key to do it?
My use case is the following: I would like to use ciphermail to
enforce outbound encryption and signature. On the other hand for
inbound messages there is no enforcement of receiving only encrypted
emails. However if received emails are encrypted I would like this to
be more visible to users than just via the headers (as would be the
case if decryption is done at MPA), and also ensure a maximum
security in keeping the secrecy as close to the reader client as
possible. I do not need virus/spam checking for encrypted messages at
the gateway level.
The gateway has been configured to always decrypt if there is a private
key available. In your case there are a couple of options. One option
would be to not relay email for your incoming domains through the
ciphermail gateway. Whether or not this works depends on your email
setup. Another option would be to change the mail flow. The complete
mail handling is described in the file config.xml. You can disable or
side-step the decryption part.
The decrypt setting in config.xml did the trick. This is the best option in my case as I need to continue receiving public keys and have ciphermail catch them.
Post by Martijn Brinkers
Post by Stephane
One other reason for the request is that I suspect a bug, or at least
an incompatibility with signed+encrypted messages that get
incorrectly transformed into a message with a single attachment
called smime.p7m which the webmail cannot identify. This occurs every
time I receive a signed+encrypted email generated at the external
sender from outlook through ciphermail and have cipermail decrypt the
message (my server is set to not remove signature from messages -
again I want users to have a maximum visibility of what happens to
their communications). This was raised previously to this list (july
21st) but I could not see a final answer.
This is not a bug but caused by the signing format of the sender. S/MIME
signatures come in two flavours: opaque signed and clear text signed.
With an opaque signature the message is encoded in a way that only an
S/MIME capable reader can show the message. An opaque message has an
smime.p7m attachment. The smime.p7m attachment is not encrypted and can
be opened with an S/MIME capable reader without requiring the private
key, With S/MIME clear signing the message is a normal message with an
smime.p7s attachment and can be viewed by a normal email client. Outlook
for example uses opaque signing when the message is signed and
encrypted. Therefore after encryption, the message will be an opaque
signed message with the smime.p7m attachemnt, Since you talk about
webmail I guess your webmail client does not know how to decode the
signed smime.p7m attachment. The workaround is to enable "remove
signature" option since this will convert the signed smime.p7m into a
normal message.
This is very clear. Thank you!
Post by Martijn Brinkers
Kind regards,
Martijn Brinkers
-------------- next part --------------
A non-text attachment was scrubbed...
Name: smime.p7s
Type: application/pkcs7-signature
Size: 5695 bytes
Desc: S/MIME Cryptographic Signature
URL: <http://lists.djigzo.com/pipermail/users/attachments/20140813/b117c1bf/attachment.bin>
Stephane Schitter
2014-08-14 14:44:39 UTC
Permalink
Hello,

It seems the config.xml <decrypt> flag only influences the S/MIME
decryption. PGP decryption is still happening. I could not find a
similar setting the PGP section of the configuration, so is it possible
to turn this off as well?

Also, would you consider making this a global >> domain >> user setting,
so that emails to only a subset of users will not be decrypted?

Regards,

Stephane


-------------- next part --------------
A non-text attachment was scrubbed...
Name: smime.p7s
Type: application/pkcs7-signature
Size: 5716 bytes
Desc: S/MIME Cryptographic Signature
URL: <http://lists.djigzo.com/pipermail/users/attachments/20140814/d4358255/attachment.bin>
Martijn Brinkers
2014-08-14 14:59:14 UTC
Permalink
Post by Stephane Schitter
It seems the config.xml <decrypt> flag only influences the S/MIME
decryption. PGP decryption is still happening. I could not find a
similar setting the PGP section of the configuration, so is it possible
to turn this off as well?
Yes you are right. In the case of PGP decryption you can currently only
disable decryption by XML commenting the PGPHandler part in config.xml.
The only downside is that attached keys will not be extracted if this is
configured.

<!--
<mailet match="All" class="PGPHandler">
[SNIP]
</mailet>
-->

Note: I have not tested it but this should work

Restart the back-end after changing config.xml
Post by Stephane Schitter
Also, would you consider making this a global >> domain >> user setting,
so that emails to only a subset of users will not be decrypted?
Can you add a request for this to our JIRA (jira.djigzo.com) ?

Kind regards,

Martijn Brinkers
--
CipherMail email encryption

Open source email encryption gateway with support for S/MIME, OpenPGP
and PDF messaging.

http://www.ciphermail.com

Twitter: http://twitter.com/CipherMail
Loading...