Hi,
A new Djigzo Gateway release candidate (2.1.1) is available.
http://www.djigzo.com/beta.html
Release notes:
New
* Advanced S/MIME setting "Always use freshest signing certificate"
added. If checked, every time the sender needs to sign a message,
the most recent (i.e., the latest "not before" date) signing
certificate will be used (GATEWAY-14).
* Advanced PDF setting "Only encrypt if mandatory" added (GATEWAY-22).
If checked, PDF encryption will only be activated if encryption is
mandatory.
* DLP setting "Quarantine on failed encryption" added. If checked and
encryption is mandatory and a message cannot be encrypted, the
message will be quarantined and not "bounced". Note: this required
minor changes to the "DLP quarantine" template.
* Quarantined emails can now be "released as-is". When a quarantined
email is released as-is, no further processing of the email is done
and the email is immediately delivered.
* The admin can now specify how many rows the grid should show per
page (users, certificates, MTA queue) (GATEWAY-23)
* The admin can now filter for specific email in the MTA queue.
* The MTA logs are now by default shown in "raw" format (i.e., in
exact same order as the log file). To view the MTA logs grouped on
queue ID (the old behavior), the admin should select "Grouped".
* If a certificate chain is valid, the issuer of the certificate in
the certificate view can be clicked to open the issuer certificate
view.
Improvements
* The BlackBerry and mobile settings are moved to a specialized mobile
settings page. New role ROLE_MOBILE_MANAGER added.
* Some settings are moved to advanced settings.
* New charsets can be added to the PDF encryption module (should be
enabled from the command line) to support charsets not supported
"out of the box" by Acrobat reader. For example certain Turkish
characters are not supported "out of the box" by Acrobat reader
(GATEWAY-20)
* If a certificate was available for a recipient, a user object was
always created for that recipient. The user is no longer added by
default.
Bug fix
* With S/MIME "strict mode" enabled, S/MIME messages were only handled
by the S/MIME handler if the recipient had a valid certificate with
private key. If a digitally signed message was received for a
recipient not having a private key, the certificates were not
extracted from the message and the signature was not removed when
"Remove signature" was enabled for that recipient. The message is
now always handled by the S/MIME handler. (GATEWAY-27)
* Under certain special conditions, the base64 encoder of Javamail
sometimes created lines with more than 76 characters (only a few
characters extra). OpenSSL (which is used by some S/MIME gateways)
cannot handle base64 encoded parts containing lines longer than 76
characters. Javamail has been updated (GATEWAY-29)
This release has been extensively tested. If no "show stoppers" are
found within the next two weeks, it will be released as the new stable
version.
Kind regards,
Martijn Brinkers
···
--
Djigzo open source email encryption
Zitat von Martijn Brinkers <martijn(a)djigzo.com>:
Hi,
A new Djigzo Gateway release candidate (2.1.1) is available.
http://www.djigzo.com/beta.html
Release notes:
Improvements
* If a certificate was available for a recipient, a user object was
always created for that recipient. The user is no longer added by
default.
What is the reasoning behind this one? I found it handsome to which
addresses where handled by S/MIME and which not by consulting the user
list.
Regards
Andreas
My thinking was that you only need to add a user when you need to
override an inherited setting. Adding an external user when a
certificate is available for the user resulted in a lot of pointless
users when using domain to domain encryption since a certificate is
available for every sender.
I can however see your point in that it helps you to see for which
external users a certificate is available. The old behavior can be
reenabled by replacing
RecipientHasCertificates=matchOnError=false,false
with
RecipientHasCertificates=matchOnError=false,true
but this requires you to change the config.xml file. I guess you want it
to be configurable from the GUI? 
Kind regards,
Martijn
···
On 01/-10/-28163 08:59 PM, lst_hoe02(a)kwsoft.de wrote:
Zitat von Martijn Brinkers <martijn(a)djigzo.com>:
Hi,
A new Djigzo Gateway release candidate (2.1.1) is available.
http://www.djigzo.com/beta.html
Release notes:
Improvements
* If a certificate was available for a recipient, a user object was
always created for that recipient. The user is no longer added by
default.
What is the reasoning behind this one? I found it handsome to which
addresses where handled by S/MIME and which not by consulting the user
list.
--
Djigzo open source email encryption
I will add a setting that allows you to specify whether you want a user
to be created automatically when the recipient has a certificate. If you
use domain to domain encryption you can then set the domain setting for
that particular domain to not add a user for every recipient of that
domain.
Kind regards,
Martijn
···
On 07/28/2011 09:52 AM, Martijn Brinkers wrote:
On 01/-10/-28163 08:59 PM, lst_hoe02(a)kwsoft.de wrote:
Zitat von Martijn Brinkers <martijn(a)djigzo.com>:
Hi,
A new Djigzo Gateway release candidate (2.1.1) is available.
http://www.djigzo.com/beta.html
Release notes:
Improvements
* If a certificate was available for a recipient, a user object was
always created for that recipient. The user is no longer added by
default.
What is the reasoning behind this one? I found it handsome to which
addresses where handled by S/MIME and which not by consulting the user
list.
My thinking was that you only need to add a user when you need to
override an inherited setting. Adding an external user when a
certificate is available for the user resulted in a lot of pointless
users when using domain to domain encryption since a certificate is
available for every sender.
I can however see your point in that it helps you to see for which
external users a certificate is available. The old behavior can be
reenabled by replacing
RecipientHasCertificates=matchOnError=false,false
with
RecipientHasCertificates=matchOnError=false,true
but this requires you to change the config.xml file. I guess you want it
to be configurable from the GUI?
--
Djigzo open source email encryption
Zitat von Martijn Brinkers <martijn(a)djigzo.com>:
Zitat von Martijn Brinkers <martijn(a)djigzo.com>:
Hi,
A new Djigzo Gateway release candidate (2.1.1) is available.
http://www.djigzo.com/beta.html
Release notes:
Improvements
* If a certificate was available for a recipient, a user object was
always created for that recipient. The user is no longer added by
default.
What is the reasoning behind this one? I found it handsome to which
addresses where handled by S/MIME and which not by consulting the user
list.
My thinking was that you only need to add a user when you need to
override an inherited setting. Adding an external user when a
certificate is available for the user resulted in a lot of pointless
users when using domain to domain encryption since a certificate is
available for every sender.
I can however see your point in that it helps you to see for which
external users a certificate is available. The old behavior can be
reenabled by replacing
RecipientHasCertificates=matchOnError=false,false
with
RecipientHasCertificates=matchOnError=false,true
but this requires you to change the config.xml file. I guess you want it
to be configurable from the GUI?
It isn't that important to clutter the GUI with just another setting i
guess, it just was "handsome" to quickly alter problematic receivers
because the user already exists. Would it be possible to not auto
create users for domains the domain-to-domain encryption is configured
or something like "auto-create-user-strict-mode" so only users are
auto created when exactly matching certificates are involved?
Regards
Andreas
···
On 01/-10/-28163 08:59 PM, lst_hoe02(a)kwsoft.de wrote:
Zitat von Martijn Brinkers <martijn(a)djigzo.com>:
Zitat von Martijn Brinkers <martijn(a)djigzo.com>:
Hi,
A new Djigzo Gateway release candidate (2.1.1) is available.
http://www.djigzo.com/beta.html
Release notes:
Improvements
* If a certificate was available for a recipient, a user object was
always created for that recipient. The user is no longer added by
default.
What is the reasoning behind this one? I found it handsome to which
addresses where handled by S/MIME and which not by consulting the user
list.
My thinking was that you only need to add a user when you need to
override an inherited setting. Adding an external user when a
certificate is available for the user resulted in a lot of pointless
users when using domain to domain encryption since a certificate is
available for every sender.
I can however see your point in that it helps you to see for which
external users a certificate is available. The old behavior can be
reenabled by replacing
RecipientHasCertificates=matchOnError=false,false
with
RecipientHasCertificates=matchOnError=false,true
but this requires you to change the config.xml file. I guess you want it
to be configurable from the GUI?
It isn't that important to clutter the GUI with just another setting i
guess, it just was "handsome" to quickly alter problematic receivers
because the user already exists. Would it be possible to not auto create
users for domains the domain-to-domain encryption is configured or
something like "auto-create-user-strict-mode" so only users are auto
created when exactly matching certificates are involved?
Detecting whether the recipient is using domain to domain encryption is
possible but a lot more work than using a setting and slower since
instead of just retrieving the list of all certs, a check should be done
to see whether the cert was a domain cert or not. It's doable but if I
have to choose between an extra advanced setting or checking for domain
certs etc. I prefer the extra setting.
Yesterday there was a question about syncing with LDAP and getting a
list of users that are using S/MIME encryption so I guess you are not
the only one that likes that feature so I guess it's better to allow the
admin to decide whether to automatically add a user or not.
It isn't that important to clutter the GUI with just another setting..
I moved some settings (the mobile settings) to a specialized page. This
Perhaps I can move certain properties to a specialized page?
Kind regards,
Martijn
···
On 01/-10/-28163 08:59 PM, lst_hoe02(a)kwsoft.de wrote:
On 01/-10/-28163 08:59 PM, lst_hoe02(a)kwsoft.de wrote:
--
Djigzo open source email encryption
Zitat von Martijn Brinkers <martijn(a)djigzo.com>:
Zitat von Martijn Brinkers <martijn(a)djigzo.com>:
Zitat von Martijn Brinkers <martijn(a)djigzo.com>:
Hi,
A new Djigzo Gateway release candidate (2.1.1) is available.
http://www.djigzo.com/beta.html
Release notes:
Improvements
* If a certificate was available for a recipient, a user object was
always created for that recipient. The user is no longer added by
default.
What is the reasoning behind this one? I found it handsome to which
addresses where handled by S/MIME and which not by consulting the user
list.
My thinking was that you only need to add a user when you need to
override an inherited setting. Adding an external user when a
certificate is available for the user resulted in a lot of pointless
users when using domain to domain encryption since a certificate is
available for every sender.
I can however see your point in that it helps you to see for which
external users a certificate is available. The old behavior can be
reenabled by replacing
RecipientHasCertificates=matchOnError=false,false
with
RecipientHasCertificates=matchOnError=false,true
but this requires you to change the config.xml file. I guess you want it
to be configurable from the GUI?
It isn't that important to clutter the GUI with just another setting i
guess, it just was "handsome" to quickly alter problematic receivers
because the user already exists. Would it be possible to not auto create
users for domains the domain-to-domain encryption is configured or
something like "auto-create-user-strict-mode" so only users are auto
created when exactly matching certificates are involved?
Detecting whether the recipient is using domain to domain encryption is
possible but a lot more work than using a setting and slower since
instead of just retrieving the list of all certs, a check should be done
to see whether the cert was a domain cert or not. It's doable but if I
have to choose between an extra advanced setting or checking for domain
certs etc. I prefer the extra setting.
In this case the extra setting is the better way to go of course.
Yesterday there was a question about syncing with LDAP and getting a
list of users that are using S/MIME encryption so I guess you are not
the only one that likes that feature so I guess it's better to allow the
admin to decide whether to automatically add a user or not.
It isn't that important to clutter the GUI with just another setting..
I moved some settings (the mobile settings) to a specialized page. This
Perhaps I can move certain properties to a specialized page?
Maybe it's time to group the S/MIME special settings like
"strict-mode", "skip-invites" and the like on one page...
Regards
Andreas
···
On 01/-10/-28163 08:59 PM, lst_hoe02(a)kwsoft.de wrote:
On 01/-10/-28163 08:59 PM, lst_hoe02(a)kwsoft.de wrote: