Zitat von Martijn Brinkers <[email protected]>:

On 01/-10/-28163 08:59 PM, [email protected] wrote:
Zitat von Martijn Brinkers <[email protected]>:

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.

Because i have to test the new mailserver anyway it would be fine to have something like a RC version which could later be replaced by the final release.

Many Thanks

Andreas


Attachment: smime.p7s
Description: S/MIME Cryptographic Signature

_______________________________________________
Users mailing list
[email protected]
http://lists.djigzo.com/lists/listinfo/users

Reply via email to