On 01/-10/-28163 08:59 PM, lst_ho...@kwsoft.de wrote: > Zitat von Martijn Brinkers <mart...@djigzo.com>: > >> On 02/02/2011 09:57 AM, Manuel Faux wrote: >>>> Currently the domain certificate is only used for encrypting. For >>>> decryption the gateway works like any email client i.e, decrypt when >>>> possible. So what I'm thinking of is to add "strict mode", In "strict >>>> mode" a recipient will only receive the message decrypted if one of the >>>> following is true: >>>> >>>> 1. the message is encrypted with a certificate with private key >>>> containing an email address that matches the email address of the >>>> recipient. >>>> >>>> or, >>>> >>>> 2. the message is encrypted with a certificate with private key that >>>> was >>>> manually selected for the recipient >>>> >>>> or, >>>> >>>> 3. the message is encrypted with a certificate with private key that >>>> was >>>> manually selected for the domain of the recipient >>>> >>>> >>>> On non-strict mode the gateway behaves like it does not i.e, decrypt >>>> when possible. >>>> >>>> Am I missing something? >>> >>> I also think this behavior sounds reasonable, but I do not understand >>> why to >>> differentiate between those two modes. As far as I can follow, I do >>> not see >>> any need for decryption with a certificate's key which does not >>> contain the >>> correct e-mail address nor was manually associated with the user or >>> the domain. >>> When thinking about your pobox-scenario, Martijn, you could manually >>> assign the >>> pobox certificate with your actual email address and the decryption >>> would even >>> work in "high-secure mode". >> >> I think having two modes is better than having just one. The main reason >> for the decrypt if possible mode is that it's much easier from a >> management perspective. With the only decrypt when the email address >> match mode setting up an S/MIME tunnel for domain encryption requires >> both the sender and the recipient to setup the correct certificate. Also >> when forwarding you need to do more work. >> Some companies don't like to have encrypted email within their >> infrastructure because it cannot be scanned so they prefer to decrypt >> when possible. Whether or not you think "decrypt if possible" is a good >> thing or not depends on what you think a gateway should do. I therefore >> think having the two options is the best thing to do. I'll need to >> explain the pros and cons of the two approaches to make it easier for an >> end user to understand. > > I agree that if it is possible, let the user choose. > As i'm in progress updating the main server it would be nice if you > could estimate a timeframe for the next release including this change.
I'm currently working on new features, the main new feature is scanning of outgoing email for certain content based on regular expressions (for data leak prevention), but it could take about two weeks to finish it. The new release also has support for DSN. I will start working on the "strict mode" feature this week and need to decide whether I will backport it to the previous release or whether the new release will be finished soon enough. To answer your question I hope to have it finished within two weeks either the new release or a backport (or both). The majority of the work is testing and building the virtual appliances and testing them. If you want to work with a bleeding edge version (which is well tested btw) I can probably deliver faster. Kind regards, Martijn -- Djigzo open source email encryption
smime.p7s
Description: S/MIME Cryptographic Signature
_______________________________________________ Users mailing list Users@lists.djigzo.com http://lists.djigzo.com/lists/listinfo/users
smime.p7s
Description: S/MIME Cryptographic Signature
