Djigzo release candidate 1.4.0

Gateway
1

Hi,

A release candidate of Djigzo 1.4.0 is available. This version has been
extensively tested and will be released soon. For those who are
interested in running it now can download it directly from the links
below. The documentation however is not yet updated with the new
features (this will be finished soon).

The release notes are shown below.

The upgrade guide can be downloaded from:

http://www.djigzo.com/documents/upgrade-guide.pdf

Kind regards,

Martijn Brinkers

···

=======================
Download links:

1) For Debian/Ubuntu

Djigzo
www.djigzo.com/downloads/djigzo-release-1.4.0-0/djigzo_1.4.0-0_all.deb
www.djigzo.com/downloads/djigzo-release-1.4.0-0/djigzo_1.4.0-0_all.deb.asc

Djigzo Web
www.djigzo.com/downloads/djigzo-release-1.4.0-0/djigzo-web_1.4.0-0_all.deb
www.djigzo.com/downloads/djigzo-release-1.4.0-0/djigzo-web_1.4.0-0_all.deb.asc

2) For RedHat/Centos

Djigzo
www.djigzo.com/downloads/djigzo-release-1.4.0-0/djigzo-1.4.0-0.noarch.rpm
www.djigzo.com/downloads/djigzo-release-1.4.0-0/djigzo-1.4.0-0.noarch.rpm.asc

Djigzo Web
www.djigzo.com/downloads/djigzo-release-1.4.0-0/djigzo-web-1.4.0-0.noarch.rpm
www.djigzo.com/downloads/djigzo-release-1.4.0-0/djigzo-web-1.4.0-0.noarch.rpm.asc

3) TAR distribution

Djigzo
www.djigzo.com/downloads/djigzo-release-1.4.0-0/djigzo_1.4.0-0.tar.gz
www.djigzo.com/downloads/djigzo-release-1.4.0-0/djigzo_1.4.0-0.tar.gz.asc

Djigzo Web
www.djigzo.com/downloads/djigzo-release-1.4.0-0/djigzo-web_1.4.0-0.tar.gz
www.djigzo.com/downloads/djigzo-release-1.4.0-0/djigzo-web_1.4.0-0.tar.gz.asc

4) Virtual Appliance

For ESX(i)
www.djigzo.com/downloads/djigzo-release-1.4.0-0/djigzo-virtual-appliance-esx-1.4.0-0.zip
www.djigzo.com/downloads/djigzo-release-1.4.0-0/djigzo-virtual-appliance-esx-1.4.0-0.zip.asc

For VMWare Player/Server
www.djigzo.com/downloads/djigzo-release-1.4.0-0/djigzo-virtual-appliance-1.4.0-0.zip
www.djigzo.com/downloads/djigzo-release-1.4.0-0/djigzo-virtual-appliance-1.4.0-0.zip.asc

5) Source

Djigzo
www.djigzo.com/downloads/djigzo-release-1.4.0-0/djigzo-src_1.4.0-0.tar.gz
www.djigzo.com/downloads/djigzo-release-1.4.0-0/djigzo-src_1.4.0-0.tar.gz.asc

Djigzo Web
www.djigzo.com/downloads/djigzo-release-1.4.0-0/djigzo-web-src_1.4.0-0.tar.gz
www.djigzo.com/downloads/djigzo-release-1.4.0-0/djigzo-web-src_1.4.0-0.tar.gz.asc

The .asc is the gpg signature of the file.

=======================
Release Notes:

New

* Different certificate request handlers can not be added using a
  pluggable infrastructure.
* Certificate request handler for Comodo has been added. With the Comodo
  certificate request handler, certificates from Comodo's managed PKI
  services (EPKI) can be automatically requested from the gateway.
* Certificates can now be requested in bulk. A comma separated text file
  containing the request details can be imported. The certificates will
  be requested using the selected certificate request handler.
* Email encryption header trigger has been added. Encryption of email
  can be triggered using a pre-defined email header (matched against a
  regular expression).
* A certificate can now be automatically requested for a sender using
  the default selected certificate request handler (only if the sender
  does not yet have a valid certificate with private key).

Improvement

* When a large number of certificates were imported (60000 certificates)
  the certificates view (UI) was no longer 'snappy' enough. The
  certificate view has been optimized (only noticeable with large number
  of certificates).
* Some UI menu items are moved to left-hand submenu.
* SMS settings menu item has been moved to the SMS page.
* The message template to edit should now be selected from a drop down
  select.
* The restart and PDF import attachment wait animation has been replaced
  with an animated gif.

Bug fix

* The PDF reply URL didn't support unicode characters (only US-ASCII).
  The reply URL parameters are now UTF-8 encoded. This has been reported
  by Benedikt Zorn.
* When creating certificates, the email address wasn't added to the
  alternative names (only to the subject).
* The check whether a domain is a valid domain was not strict enough.
  Domains containing an underscore ("_") are no longer accepted as a
  valid domain.
* Under certain circumstances (when running under certain versions of
  VMware ESX) downloading a CRL over HTTPS could result in high CPU
  usage. A CRL distributionpoint should normally not contain a HTTPS URL
(RFC 5280). Only a few CAs however use HTTPS for the CRL
  distributionpoint URL. This has been reported by Andreas Beier.
* Java wrapper version upgraded to latest version. Sometimes the Java
  wrapper was not able to automatically restart Djigzo when the wrapper
  detected that Djigzo wasn't running (only happens under specific
  cirumstances).
* The Virtual Appliance console update menu items were incorrectly
  named. The menu items were named "Update" and "Upgrade" but they
  should have been named "Upgrade" and "Dist-upgrade".

--
Djigzo open source email encryption

2

After I pressed the send button I noticed a typo in the release notes:

"Different certificate request handlers can not be added..." should have
been "Different certificate request handlers can now be added..."

My apologies.

Kind regards,

Martijn

Martijn Brinkers wrote:

···

Hi,

A release candidate of Djigzo 1.4.0 is available. This version has been
extensively tested and will be released soon. For those who are
interested in running it now can download it directly from the links
below. The documentation however is not yet updated with the new
features (this will be finished soon).

The release notes are shown below.

The upgrade guide can be downloaded from:

http://www.djigzo.com/documents/upgrade-guide.pdf

Kind regards,

Martijn Brinkers

=======================
Download links:

1) For Debian/Ubuntu

Djigzo
www.djigzo.com/downloads/djigzo-release-1.4.0-0/djigzo_1.4.0-0_all.deb
www.djigzo.com/downloads/djigzo-release-1.4.0-0/djigzo_1.4.0-0_all.deb.asc

Djigzo Web
www.djigzo.com/downloads/djigzo-release-1.4.0-0/djigzo-web_1.4.0-0_all.deb
www.djigzo.com/downloads/djigzo-release-1.4.0-0/djigzo-web_1.4.0-0_all.deb.asc

2) For RedHat/Centos

Djigzo
www.djigzo.com/downloads/djigzo-release-1.4.0-0/djigzo-1.4.0-0.noarch.rpm
www.djigzo.com/downloads/djigzo-release-1.4.0-0/djigzo-1.4.0-0.noarch.rpm.asc

Djigzo Web
www.djigzo.com/downloads/djigzo-release-1.4.0-0/djigzo-web-1.4.0-0.noarch.rpm
www.djigzo.com/downloads/djigzo-release-1.4.0-0/djigzo-web-1.4.0-0.noarch.rpm.asc

3) TAR distribution

Djigzo
www.djigzo.com/downloads/djigzo-release-1.4.0-0/djigzo_1.4.0-0.tar.gz
www.djigzo.com/downloads/djigzo-release-1.4.0-0/djigzo_1.4.0-0.tar.gz.asc

Djigzo Web
www.djigzo.com/downloads/djigzo-release-1.4.0-0/djigzo-web_1.4.0-0.tar.gz
www.djigzo.com/downloads/djigzo-release-1.4.0-0/djigzo-web_1.4.0-0.tar.gz.asc

4) Virtual Appliance

For ESX(i)
www.djigzo.com/downloads/djigzo-release-1.4.0-0/djigzo-virtual-appliance-esx-1.4.0-0.zip
www.djigzo.com/downloads/djigzo-release-1.4.0-0/djigzo-virtual-appliance-esx-1.4.0-0.zip.asc

For VMWare Player/Server
www.djigzo.com/downloads/djigzo-release-1.4.0-0/djigzo-virtual-appliance-1.4.0-0.zip
www.djigzo.com/downloads/djigzo-release-1.4.0-0/djigzo-virtual-appliance-1.4.0-0.zip.asc

5) Source

Djigzo
www.djigzo.com/downloads/djigzo-release-1.4.0-0/djigzo-src_1.4.0-0.tar.gz
www.djigzo.com/downloads/djigzo-release-1.4.0-0/djigzo-src_1.4.0-0.tar.gz.asc

Djigzo Web
www.djigzo.com/downloads/djigzo-release-1.4.0-0/djigzo-web-src_1.4.0-0.tar.gz
www.djigzo.com/downloads/djigzo-release-1.4.0-0/djigzo-web-src_1.4.0-0.tar.gz.asc

The .asc is the gpg signature of the file.

=======================
Release Notes:

New

* Different certificate request handlers can not be added using a
  pluggable infrastructure.
* Certificate request handler for Comodo has been added. With the Comodo
  certificate request handler, certificates from Comodo's managed PKI
  services (EPKI) can be automatically requested from the gateway.
* Certificates can now be requested in bulk. A comma separated text file
  containing the request details can be imported. The certificates will
  be requested using the selected certificate request handler.
* Email encryption header trigger has been added. Encryption of email
  can be triggered using a pre-defined email header (matched against a
  regular expression).
* A certificate can now be automatically requested for a sender using
  the default selected certificate request handler (only if the sender
  does not yet have a valid certificate with private key).

Improvement

* When a large number of certificates were imported (60000 certificates)
  the certificates view (UI) was no longer 'snappy' enough. The
  certificate view has been optimized (only noticeable with large number
  of certificates).
* Some UI menu items are moved to left-hand submenu.
* SMS settings menu item has been moved to the SMS page.
* The message template to edit should now be selected from a drop down
  select.
* The restart and PDF import attachment wait animation has been replaced
  with an animated gif.

Bug fix

* The PDF reply URL didn't support unicode characters (only US-ASCII).
  The reply URL parameters are now UTF-8 encoded. This has been reported
  by Benedikt Zorn.
* When creating certificates, the email address wasn't added to the
  alternative names (only to the subject).
* The check whether a domain is a valid domain was not strict enough.
  Domains containing an underscore ("_") are no longer accepted as a
  valid domain.
* Under certain circumstances (when running under certain versions of
  VMware ESX) downloading a CRL over HTTPS could result in high CPU
  usage. A CRL distributionpoint should normally not contain a HTTPS URL
(RFC 5280). Only a few CAs however use HTTPS for the CRL
  distributionpoint URL. This has been reported by Andreas Beier.
* Java wrapper version upgraded to latest version. Sometimes the Java
  wrapper was not able to automatically restart Djigzo when the wrapper
  detected that Djigzo wasn't running (only happens under specific
  cirumstances).
* The Virtual Appliance console update menu items were incorrectly
  named. The menu items were named "Update" and "Upgrade" but they
  should have been named "Upgrade" and "Dist-upgrade".

--
Djigzo open source email encryption

3

Zitat von Martijn Brinkers <martijn(a)djigzo.com>:

Hi,

A release candidate of Djigzo 1.4.0 is available. This version has been
extensively tested and will be released soon. For those who are
interested in running it now can download it directly from the links
below. The documentation however is not yet updated with the new
features (this will be finished soon).

Half an hour ago i thought of asking for a release candidate and voila... :wink:
Unfortunately there is nothing in for us today :frowning:
As far as i understand the new features are only for automatic
cert/key enrollment for the internal users so more needed for rather
large deployments.

May i ask what the timeframe (if any) is for the following features
(sort by importance IMHO)

- DSN support according to RFC 1891
( Needed to get DSN request through when sending mail)

- Automatic public key fetch by LDAP
( Needed to make it easier to get public keys from services like
www.bridge-ca.org)

- User viewable tagging (subject extension) for incoming signed/encrypted mail
( Sometimes it is really useful if the user is able to check)

- Timestamp support when signing
( Not really useful today but more in a long term if clients or
mailarchives are able to check )

Many Thanks

Andreas

4

Hi Andreas,

Half an hour ago i thought of asking for a release candidate and voila... :wink:
Unfortunately there is nothing in for us today :frowning:

I'm sure there will be plenty of new features in future versions that
will please you :slight_smile:

May i ask what the timeframe (if any) is for the following features
(sort by importance IMHO)

- DSN support according to RFC 1891
( Needed to get DSN request through when sending mail)

Isn't this the task of the MTA (i.e. of Postfix)? afaik Postfix supports
RFC 3461 which is the succession of RFC 1891. I probably misunderstand
your request so could you explain to me what you mean with "DSN support
according to RFC 1891"?

- Automatic public key fetch by LDAP
( Needed to make it easier to get public keys from services like
www.bridge-ca.org)

I might be working on this feature next because a client might have a
need for this feature. I do not have a clear timeframe but it shouldn't
take too long.

- User viewable tagging (subject extension) for incoming signed/encrypted mail
( Sometimes it is really useful if the user is able to check)

If I understand you, you want to add some sort of banner to the message
containing the security information? something similar to what's added
to the headers but now visible for the end-user?

- Timestamp support when signing
( Not really useful today but more in a long term if clients or
mailarchives are able to check )

I haven't had time to think about this. From our previous discussion the
biggest problem with this is client-side support for checking the
timestamp'd signature. The request has been placed in the development
agenda but with a low priority.

Kind regards,

Martijn Brinkers

···

--
Djigzo open source email encryption

5

Zitat von Martijn Brinkers <martijn(a)djigzo.com>:

Hi Andreas,

Half an hour ago i thought of asking for a release candidate and
voila... :wink:
Unfortunately there is nothing in for us today :frowning:

I'm sure there will be plenty of new features in future versions that
will please you :slight_smile:

No doubt at all :slight_smile:

May i ask what the timeframe (if any) is for the following features
(sort by importance IMHO)

- DSN support according to RFC 1891
( Needed to get DSN request through when sending mail)

Isn't this the task of the MTA (i.e. of Postfix)? afaik Postfix supports
RFC 3461 which is the succession of RFC 1891. I probably misunderstand
your request so could you explain to me what you mean with "DSN support
according to RFC 1891"?

The problem is that the whole *chain* of smtp servers up to the
recpient inbox must support DSN which is a extension of ESMTP, to be
useful. In the Djigzo case the Java based James SMTP server does not
support DSN until recently?? So it is more a problem of James than a
problem with Postfix or Djigzo actually...
The DSN ends at the Djigzo gateway because of this so it is not
possible to request a DSN beyond there.

- Automatic public key fetch by LDAP
( Needed to make it easier to get public keys from services like
www.bridge-ca.org)

I might be working on this feature next because a client might have a
need for this feature. I do not have a clear timeframe but it shouldn't
take too long.

Nice to here!

- User viewable tagging (subject extension) for incoming
signed/encrypted mail
( Sometimes it is really useful if the user is able to check)

If I understand you, you want to add some sort of banner to the message
containing the security information? something similar to what's added
to the headers but now visible for the end-user?

Yes , this should be a easy work around to see if the message was
signed/encrypted before it reached the gateway. No Outlook user willl
every read e-mail headers :frowning:

- Timestamp support when signing
( Not really useful today but more in a long term if clients or
mailarchives are able to check )

I haven't had time to think about this. From our previous discussion the
biggest problem with this is client-side support for checking the
timestamp'd signature. The request has been placed in the development
agenda but with a low priority.

No problem, i will try to get involved at Thunderbird etc. to see if
there is some work in progress on the crypto part. Maybe there will be
a chance to throw it in :slight_smile:

Regards

Andreas

6

Hi Andreas,

The problem is that the whole *chain* of smtp servers up to the
recpient inbox must support DSN which is a extension of ESMTP, to be
useful. In the Djigzo case the Java based James SMTP server does not
support DSN until recently?? So it is more a problem of James than a
problem with Postfix or Djigzo actually...
The DSN ends at the Djigzo gateway because of this so it is not
possible to request a DSN beyond there.

Ok I'll look into it. Can't promise anything but I'll do my best :slight_smile:

- User viewable tagging (subject extension) for incoming
signed/encrypted mail
( Sometimes it is really useful if the user is able to check)

If I understand you, you want to add some sort of banner to the message
containing the security information? something similar to what's added
to the headers but now visible for the end-user?

Yes , this should be a easy work around to see if the message was
signed/encrypted before it reached the gateway. No Outlook user willl
every read e-mail headers :frowning:

What might be problematic is that a banner can be easily spoofed. Any
djigzo-* header is removed when the email enters Djigzo. Therefore the
security headers cannot be spoofed. With a security banner (a text or
HTML text part) it's nearly impossible to detect whether the banner is
spoofed. So, the banner should only be viewed as informational.

No problem, i will try to get involved at Thunderbird etc. to see if
there is some work in progress on the crypto part. Maybe there will be
a chance to throw it in :slight_smile:

Yes that would be nice to see whether Thunderbird supports it. Perhaps
TrustedBird (a security enhanced Thunderbird) already supports this?

http://www.trustedbird.org

Kind regards,

Martijn

···

--
Djigzo open source email encryption

7

Zitat von Martijn Brinkers <martijn(a)djigzo.com>:

Hi Andreas,

- User viewable tagging (subject extension) for incoming
signed/encrypted mail
( Sometimes it is really useful if the user is able to check)

If I understand you, you want to add some sort of banner to the message
containing the security information? something similar to what's added
to the headers but now visible for the end-user?

Yes , this should be a easy work around to see if the message was
signed/encrypted before it reached the gateway. No Outlook user willl
every read e-mail headers :frowning:

What might be problematic is that a banner can be easily spoofed. Any
djigzo-* header is removed when the email enters Djigzo. Therefore the
security headers cannot be spoofed. With a security banner (a text or
HTML text part) it's nearly impossible to detect whether the banner is
spoofed. So, the banner should only be viewed as informational.

I would suggest to alter the subject with added Tag like "[WAS
CRYPTED]" at the end similar to triggered encryption when sending, and
the Tag should be unconditionally removed at first incoming stage to
prevent spoofing.

No problem, i will try to get involved at Thunderbird etc. to see if
there is some work in progress on the crypto part. Maybe there will be
a chance to throw it in :slight_smile:

Yes that would be nice to see whether Thunderbird supports it. Perhaps
TrustedBird (a security enhanced Thunderbird) already supports this?

http://www.trustedbird.org

Will have a look what others have to say according this...

Many Thanks

Andreas

8

I would suggest to alter the subject with added Tag like "[WAS CRYPTED]"
at the end similar to triggered encryption when sending, and the Tag
should be unconditionally removed at first incoming stage to prevent
spoofing.

Yes you are right. Using a subject is easier

Kind regards,

Martijn

···

--
Djigzo open source email encryption