25 Mar
2016
25 Mar
'16
3:59 p.m.
On 03/25/2016 03:48 PM, Matthias Henze wrote:
Am 25.03.2016 um 14:42 schrieb Martijn Brinkers:
Thats what I wrote in my initial mail, MUA's only enforce this to be
able to store the mail in their sent folder and be able to make it
readable to the user.
Lets sum this up:
For sending an encrypted mail only the recipients public key is
required. In case of s/Mime, if the recipient has sent a signed mail, a
encrypted mail could be sent to him. This makes no statement about what
the recipient can do.
While typing one other thing comes to my mind. The other vendor can also
do mail archiving. When they want to archive the mail which is finally
sent, the encrypted mail, the certificate for the sender is required to
make it readable later.
If there is a requirement to archive the email after encryption, you can
configure a "global" S/MIME additional encryption key. If an email is
encrypted with S/MIME and a global additional S/MIME encryption key is
configured, the message will also be encrypted with the additional key.
See for more information:
https://www.ciphermail.com/documents/html/administration-guide/#pf3c
Kind regards,
Martijn Brinkers
--
CipherMail email encryption
Email encryption with support for S/MIME, OpenPGP, PDF encryption and
secure webmail pull.
https://www.ciphermail.com
Twitter: http://twitter.com/CipherMail
This is a
common (mis)behavior of e-mail clients, they refuse to sent
encrypted e-mail if they are not able to store the e-mail encrypted in
the "sent" folder. This is only possible if the *sender* also has a
certificate and a private key, but this not mandated by S/MIME standard.
I guess the other party simply adapted this behavior without rethinking
if it is useful for a gateway at all.
Oh I now see I completely misunderstood the original question :) As
Andreas already explained, email clients want to store the message
encrypted in the sent items folder and therefore requires that the
sender has a key. With a gateway this is not required.