currently we are using MS Exchange with individual X.509 certificates stored in the users’ outlook clients.
Some of our clients only accept encrypted mails, however their certificate does not match the receipients e-Mail address. For example: john.doe(at)company-com sends a sigend mail with a certificated issued for crypt(at)company-com, their e-mail gateway would decrypt mails sent to john.doe but encrypted with crypt(at)company-com. The problem is, that there is no way for Outlook to encrypt the mail with a certificate that does not match the receipient.
Is ciphermail able to handle such setups through auto-learning?
The gateway can be configured to encrypt all email to some domain using a “domain” certificate. So in your case you can configure the domain company-com to always use the S/MIME certificate crypt(at)company-com when sending email to any recipient of domain company-com.
This however cannot be done automatically because that would not be secure.
thanks this is very helpful. Doing a manual configuration for those domains seems reasonable.
iterating on that, I have a follow up question. E-Mail encryption serves as an end-to-end enryption, encrypting both, the transport of the mail, and the mail stored in the users’ mailboxes. I see how using an encrypting mail gateway makes things easier for “enterprise”-scale deployments, however mails are sent decrypted to the mailbox and there stored in plain-text.
Is it possible to use ciphermail in a way so, incoming mail is passed through the gateway, but it’s not decrypted but forwared directly to the users’ mailboxes so it stays there until viewed with the mail-client?
Well the use case would be to enforce encryption to certain receipient-domains. So the keys should be on the gateway as well as on the client. When the user forgets to encrypt an e-mail the gateway could jump in and encrypt the mail. However incoming encrypted mails should be sent directly to the user’s mailbox to not break end-to-end encryption.
the normal operation mode with encryption gateways usually is, that they receive unencrypted mails from the company’s mailserver that get encrypted on the gateway and then sent to receiving party. How the receiver handels encrypted messages is out of my control. This mode of operation has some advantages for administrators, like having a central point for certificate management, users don’t need to think about encrypting mails and the public certificates of incoming mails can be automatically learned by the appliance - among others.
The disadvantage is that mails stay unencrypted in my users’ mailboxes. So as I’ve explained before, my ideal scenario would be that users decrypt/encrypt their mails with outlook (as they are already doing) and the gateway jumps in for encrypting mails where the user has forgotten to press the button or the receiving party uses a domain certificate.
What I get from your answers is, that it should work as long as the gateway does not have the private certificates installed. If configured properly encrypted mails should just pass through the gateway. Since encrypting a mail does not requires only the receiver’s public key the private certificates of my users don’t need to be installed on the gateway. That being said, how does that impact the receiver of the mails? Usually encrypted mails also should be signed by the sending party if the receiver needs to get public key…
However if my users’ outlook clients would default sign every outgoing mail (which is already the case) there shouldn’t be much of problem with not having the private keys on the gateway?
are my assumptions correct? I personally would prefer an option where ciphermail also knows the private certificates, but does not decrypt the mails for final delivery. If the product is expanded with antivirus or antispam capabilites, the contents could still be checked and after it passes the checks it still gets delivered encrypted.
You can configure the SMIME handler to not decrypt incoming email. This requires a change to the mail flow configuration file (config.xml). Note however that these changes will be overwritten when you upgrade to a newer release.
<mailet match="All" class="SMIMEHandler">
uncompress will be disabled by default because the mail can become very large after
decompression. This can be used to 'inject' a extremely large email into the mail
system. The 'after filter' max message limit should be set to prevent decompressed
mails to become too large. If decompression is required enable this option and make
sure that the 'after filter' max message limit is set to a sane value.
<protectedHeader> subject </protectedHeader>
<removeSignatureAttribute> runtime.smime.removeSignature </removeSignatureAttribute>
<strictAttribute> runtime.smime.strict </strictAttribute>
<handledProcessor> message-was-smime-handled-incoming </handledProcessor>
After changing config.xml, you need to restart the back-end.
The mail config file describes how email will be handled.
You can for example create a configuration which encrypts all incoming email sent to internal recipients. With such a setup, all email will be stored in encrypted form in the mailbox of the recipient even for email which was received without encryption. This protects your mailbox against a hacker because every received email will be encrypted.