lst_hoe02(a)kwsoft.de wrote:
> in the menu for certificates/roots etc. there is a "invert selection"
> option which i was under the impression is useful to select *all* items.
> This could be handy to transfer all root-Certs for example, but as far
> as i can see the selection is only valid for teh actual page. Is this
> inteded behaviour or technical limited?
This is by design. Only the certificates that are in view are selected.
I do not like when items are selected without the user seeing them
selected. Suppose all certificates would have been selected and the user
presses 'delete'. Then suddenly all certificates would have been
deleted. Another reason for not selecting all certificates is that
Djigzo has been designed to support almost unlimited number of
certificates. It has been tested with 40.000 certificates. Storing all
certificates into a .p7b results in a 31MB file.
You can create a backup of the system using the backup manager page.
This however creates a full backup of all the settings. You only want to
backup all certificates?
What I can do is add an option to backup all certificates? This would
result in one big .p7b or .pfx file.
--
Djigzo open source email encryption
Hello
in the menu for certificates/roots etc. there is a "invert selection"
option which i was under the impression is useful to select *all*
items. This could be handy to transfer all root-Certs for example, but
as far as i can see the selection is only valid for teh actual page.
Is this inteded behaviour or technical limited?
Regards
Andreas
lst_hoe02(a)kwsoft.de wrote:
> i have altered the templates for "failed encryption"/"successful
> encryption" to use german umlauts in the messages.
>
> We have done this by altering
>
> Content-Type: text/plain
> Content-Transfer-Encoding: 7bit
>
> to
>
> Content-Type: text/plain; charset=UTF-8; format=flowed
> Content-Transfer-Encoding: 8bit
>
> I wonder if this has any drawbacks or if this could/should be the
> default for all non ASCII languages?
In general it's better not to use 8bit Content-Transfer-Encoding but to
use octet-stream or base64. The reason is that not all SMTP servers
support 8bit. If an SMTP server does not report that it supports 8bit
the SMTP server must convert it to non-8bit (for example to
ocetet-stream). Afaik Postfix will convert the message from 8bit to
octet-stream if needed but to be on the safe side it's better to use
octet-stream.
Kind regards,
Martijn
--
Djigzo open source email encryption
Hello
i have altered the templates for "failed encryption"/"successful
encryption" to use german umlauts in the messages.
We have done this by altering
Content-Type: text/plain
Content-Transfer-Encoding: 7bit
to
Content-Type: text/plain; charset=UTF-8; format=flowed
Content-Transfer-Encoding: 8bit
I wonder if this has any drawbacks or if this could/should be the
default for all non ASCII languages?
Many Thanks
Andreas
lst_hoe02(a)kwsoft.de wrote:
> we constantly get errors for a special CRL point from
> www.trustcenter.de. It is a LDAP URI as far as i can see and i have
> allowed LDAP through our firewall for Djigzo. I can see some traffic
> flow but Djigzo always complain with
>
> IO Exception downloading CRL. URI:
> ldap://www.trustcenter.de/CN=TC%20TrustCenter%20Class%203%20CA%20II,O=TC%20TrustCenter%20GmbH,OU=rootcerts,DC=trustcenter,DC=de?certificateRevocationList?base?.
> Message: null (mitm.common.security.crl.CRLStoreUpdaterImpl) [CRL
> Updater thread]
The root certificate contains two CRl distributionpoints:
http://www.trustcenter.de/crl/v2/tc_class_3_ca_II.crl
ldap://www.trustcenter.de/CN=TC%20TrustCenter%20Class%203%20CA%20II,O=TC%20TrustCenter%20GmbH,OU=rootcerts,DC=trustcenter,DC=de?certificateRevocationList?base?
The CRL can be downloaded from the HTTP URL. The LDAP server of trust
center however seems not to have the CRL.
You can get some more info on the exact error message by enabling DEBUG
mode for mitm.common.security.crl.CRLStoreUpdaterImpl (you can enable
DEBUG mode by going to Admin -> Logger Manager)
The error message is:
Caused by: javax.naming.NameNotFoundException: [LDAP: error code 32 - No
Such Object]; remaining name ''
As a test I tried to retrieve the CRL over LDAP using OpenLDAP
ldapsearch -x -H ldap://www.trustcenter.de -b "CN=TC TrustCenter Class 3
CA II,O=TC TrustCenter GmbH,OU=rootcerts,DC=trustcenter,DC=de" -t
certificateRevocationList
This also returns the same kind of error:
# LDAPv3
# base <CN=TC TrustCenter Class 3 CA II,O=TC TrustCenter
GmbH,OU=rootcerts,DC=trustcenter,DC=de> with scope subtree
# filter: (objectclass=*)
# requesting: certificateRevocationList
#
# search result
search: 2
result: 32 No such object
It seems that trustcenter's LDAP is at fault.
Because the CRL was already downloaded via HTTP this is not really a
problem because you downloaded a valid CRL.
Kind regards,
Martijn
--
Djigzo open source email encryption
Hello
we constantly get errors for a special CRL point from
www.trustcenter.de. It is a LDAP URI as far as i can see and i have
allowed LDAP through our firewall for Djigzo. I can see some traffic
flow but Djigzo always complain with
IO Exception downloading CRL. URI:
ldap://www.trustcenter.de/CN=TC%20TrustCenter%20Class%203%20CA%20II,O=TC%20TrustCenter%20GmbH,OU=rootcerts,DC=trustcenter,DC=de?certificateRevocationList?base?. Message: null (mitm.common.security.crl.CRLStoreUpdaterImpl) [CRL Updater
thread]
The root CA in question is attached for tests.
Regards
Andreas
> would it be possible to include a "In-Reply-To" and/or "References"
> header in the messages send on failed/succesful triggerd encryption?
> Is it maybe possible by altering the template?
> This would be useful as it possible to automatically associate the error
> with the trigger mail.
Yes that's possible. You have to edit the "failed encryption" template
and add the following header:
In-Reply-To: ${(mail.message.messageID)!""}
You can edit the "failed encryption" template for only one specific
sender or for the domain of the sender or for the global level.
My advice is to first try to change the template for just one specific
sender because the template should not contain template errors
(otherwise the failed encryption notification cannot be sent)
Here is an complete example template that works for me (the template is
between STRAT end END template):
===== START TEMPLATE ====
From: <${from!""}>
<#if to??>
To: <#list to as recipient><${recipient}><#if recipient_has_next>,
</#if></#list>
</#if>
<#if replyTo??>
Reply-To: <${replyTo}>
</#if>
Subject: The message could not be encrypted.
Content-Type: text/plain
Content-Transfer-Encoding: 7bit
Mime-Version: 1.0
In-Reply-To: ${(mail.message.messageID)!""}
The message with Subject
${subject!""}
has not been sent to the following recipients because the message could
not be encrypted.
<#-- we need to show the recipients of the source message -->
<#list mail.recipients as recipient>
${recipient}
</#list>
<#if body??>
${body}
</#if>
---
Djigzo open source email encryption
===== START TEMPLATE ====
Kind regards,
Martijn
Hello
would it be possible to include a "In-Reply-To" and/or "References"
header in the messages send on failed/succesful triggerd encryption?
Is it maybe possible by altering the template?
This would be useful as it possible to automatically associate the
error with the trigger mail.
Many Thanks
Andreas
lst_hoe02(a)kwsoft.de wrote:
>
>
> Not sure what you mean with opaque signed though...
There are two ways of signing data. One way signs the data and puts a
blob underneath, leaving the data readable. The other way, opaque
signing, renders the data unreadable.
Some mail servers decide that the formatting of a signed message is not
correct, and they change it, rendering the signature invalid. Opaque
signing prevents that.
dagdag
Christine
>
> Regards
>
> Andreas
>
--
dagdag is just a two-character rotation of byebye.
lst_hoe02(a)kwsoft.de wrote:
>
> Oh, i see. Opaque Signing is really bad for us...
> Are there any other clients doing this kind of signing?
>
Afaik only Microsoft products (Outlook and Outlook express). I don't
know why they do this because it even makes the complete message bigger
(because of the base64 encoding). Outlook and Outlook express will clear
sign the message when you only sign the massage. I think their thinking
was that if you are able to decrypt you are able to read an opaque
signed message.
The upcoming release of Djigzo will allow you to remove the signature
from a message. This would convert the opaque signed message to a normal
readable message. What I can add is an option that when checked it will
removed the signature from the message if the message is opaque signed.
Of course you would then loose the possibility of checking the signature.
--
Djigzo open source email encryption
