[Djigzo users] Customer experience

Eamonn McGonigle eamonn at bogpeople.com
Wed Jun 17 21:48:52 CEST 2009

Hi Martijn,

I have been playing with Djigzo for a couple of months now and I think 
it is fantastic...so let me start by saying thanks for your hard work on 
it and for releasing it to the open-source community.

If you are looking for votes (!), I think #2 below is a real winner.  I 
have been evaluating Djigzo in comparison to Cisco's Ironport for a 
number of encryption requirements.  While the "gateway-to-gateway" 
S/MIME capabilities of Djigzo are ideal, I also have a requirement for 
clientless support which Ironport's PXE does very nicely (but at a steep 
price).  There appear to be a few other products out there covering the 
same ground (the ZixDirect at www.zixcorp.com and Trend Micro Private 
Post from Trend Micro, to pick two examples).  The PDF encryption in 
Djigzo doesn't meet the requirements because to achieve an adequate key 
length would require typing in a password so long that users would never 
find it acceptable.  I considered modifying your code to lengthen the 
PDF encryption password and increase the "alphabet" from which password 
characters were drawn but dropped the idea when I worked out how long 
the password would need to be to achieve even 128-bit key strength.  I 
would therefore be delighted to see Djigzo offer the kind of clientless 
capability you outline.

If I may venture a suggestion, I would have a slight concern about the 
idea that the encrypted blob is pushed up to the server where the 
decryption key is stored for decryption.  I would suggest that it is not 
ideal to have the decryption key and the encrypted content both on this 
server.  I know Cisco's Ironport works slightly differently.  The user 
receives the message in a HTML wrapper similar to what you describe 
below. When he logs onto the server, a script in his browser downloads 
the decryption key which is then used to decrypt the blob locally on the 
user's PC (done by a bunch of Javascript code which comes down with the 
HTML wrapper).  This approach has the advantage that the message content 
is never actually stored on the key server...only the decryption key 
(which is pretty useless without the message content).  I guess the 
obvious counter-argument is that the message is encrypted on this server 
in the first instance so uploading it again for decryption isn't a 
dramatic dilution of the security (once the encrypted message content 
isn't actually stored on the same server as the decryption keys). 

Best Wishes,

Martijn Brinkers wrote:
> Hi Dan,
> Dan Banach wrote:
>>    Sorry it's taken some time to respond. We deal with a wide range of
>> email recipients (large companies, small offices, individuals, etc.)
>> with a wide range of email encryption knowledge, so the ideal encryption
>> solution for us would be very flexible. Not only flexible for outgoing
>> mail, but also incoming mail as well. Some users/business' use PGP,
>> others use certs and some use the various other options. Being able to
>> communicate with them all is very helpful.
> Right now now I'm working on Blackberry S/MIME support for BIS users 
> (for BES users there is already S/MIME email). Once that is finished I 
> will start working on new major features. There are some features I 
> would like to start working on but I'm not sure which one that should be.
> Two main new features I was thinking about are:
> 1. PGP support
> 2. Client-less email encryption
> Nr 1 is clear. I will briefly explain nr 2.
> Client-less
> Currently Djigzo supports S/MIME and PDF encryption. Recipients that do 
> not want are cannot receive S/MIME or encrypted PDFs are currently not 
> supported. The new encryption functionality I would like to add is the 
> following:
> If an email sent to an external recipient needs to be encrypted and the 
> recipient cannot receive S/MIME email of an encrypted PDF the email will 
> be converted to a .html file. The original plain-text message (and 
> attachments) will be encrypted with a certificate for the external 
> recipient and added to the .html. The .html will be added to a general 
> message (which does not contain any sensitive information) and sent to 
> the recipient. The recipient opens the .html message in the email client 
> (can for example be hotmail). The .html will open a SSL connection to 
> the companies Djigzo server (which can be a dedicated server just for 
> the portal). The Djigzo server will show a login page. The recipient now 
> has to login. After the login the recipients browser will push the 
> encrypted 'blob' (contained in the HTML) to the portal. The portal will 
> decrypt the message with the private key of the recipient (which is 
> stored on the companies Djigzo server). The recipient can now read the 
> message and download any attachments (the portal uses SSL for secure 
> access).
> The main advantage is that the recipient only requires a browser. The 
> encrypted data is stored locally on the recipients system (there is no 
> long term copy on the Djigzo server). An attacker needs access to the 
> locally stored .html file AND the portal password to read the message.
> The message is encrypted with the same algorithm as a S/MIME message. 
> The only difference is that it's encoded inside a .html file.
> A disadvantage is that the Djigzo server needs to be accessible to 
> external recipients.
> Right now I'm leaning towards implementing feature 2 but it could be 
> that you or any other Djigzo user has another preference or request for 
> a feature. If so I'm all ears :)
>>  I
>> think another great feature you could include would be to grant internal
>> users the ability to manage their own decryption profiles. They should
>> be able to add/create there own certs/keys and create their own
>> passwords. Ideally it is tied into the directory via ldap or something
>> so authentication and user information is seamless.
> One problem is that currently the settings for an external user are 
> shared by all internal users. So, if internal user A changes settings 
> for external user E internal user B will also be affected. Do you want 
> the user list to be different for each internal user?
> Right now you can add admins with different roles. You can add an admin 
> that can add keys etc. but not change the MTA settings,
> Kind regards,
> Martijn
> _______________________________________________
> Users mailing list
> Users at lists.djigzo.com
> http://lists.djigzo.com/lists/listinfo/users

More information about the Users mailing list