Interesting ... a pattern where an optional part comes before a
mandatory part 
Please let me know if I'm right. I've a mail with the following headers:
X-Djigzo-Info-Encryption-Algorithm-0: 3DES, Key size: 168
X-Djigzo-Info-Encryption-Recipient-0-0: CN=StartCom Class 1 ....
X-Djigzo-Info-Encryption-Recipient-1-0: CN=StartCom Class 2 ....
X-Djigzo-Info-Signer-ID-0-1: CN=StartCom Class 1 ....
X-Djigzo-Info-Signer-Verified-0-1: True
X-Djigzo-Info-Signer-Trusted-0-1: True
X-Djigzo-Info-Signer-Email-0-1: name(a)doamin.net
X-Djigzo-Info-Encryption-Algorithm-0 = First action was encryption of
the mail due to the LEVEL 0
X-Djigzo-Info-Encryption-Recipient-0-0 = First certificate used for
encryption due to the INDEX 0 of LEVEL 0
X-Djigzo-Info-Encryption-Recipient-1-0 = Second certificate used for
encryption due to the INDEX 1 of LEVEL 0
X-Djigzo-Info-Signer-ID-0-1 = Second action was signing the mail with
this certificate
X-Djigzo-Info-Signer-Verified-0-1 = The mail content was not modified
while transfer
X-Djigzo-Info-Signer-Trusted-0-1 = My local Ciphermail trusts the
certificate used for signing
X-Djigzo-Info-Signer-Email-0-1 = The mail is signed by the user using
this e-mail address
Further more:
If after all this the mail will be encrypted again the headers will
start with: X-Djigzo-Info-Encryption-Algorithm-2
If after this additional encryption the message gets signed again the
headers will start with: X-Djigzo-Info-Signer-ID-0-3
For my usage:
Every encrypted mail has *always* *at least* these *two* headers:
X-Djigzo-Info-Encryption-Algorithm-*
X-Djigzo-Info-Encryption-Recipient-*
Every signed mail has *always* *at least* these *four* headers:
X-Djigzo-Info-Signer-ID-*
X-Djigzo-Info-Signer-Verified-*
X-Djigzo-Info-Signer-Trusted-*
X-Djigzo-Info-Signer-Email-*
···
Am 04.04.2016 um 09:48 schrieb Martijn Brinkers:
On 04/03/2016 06:56 PM, Matthias Henze wrote:
Hi,
I've created a proof of concept Thunderbird add on (based on Display
Mail User Agent), which indicates if a incoming mail was encrypted an/or
signed. At the moment I'm a bit confused about the Ciphermail Headers. I
need to understand them better. What's all about these numbers?
-0-0
-1-0
-0-1
These are the combinations I found so far. But I found no rule when a 1
appears and if, why. Could there be other numbers? My problem is that I
can ask the TB API only for complete headers and not for fragments. This
is why I need to know which combinations are possible.
Besides of these numbers I also need a good explanation what exactly
could be derived form the headers. E.g. is it possible that a signed
mail is verified but not trusted and vice versa.
An S/MIME email can be encrypted and signed on multiple (CMS) levels. In
most cases a message is first signed and then encrypted. However a
message can for example also be signed, then encrypted and again signed.
In principle there can be an unlimited number of levels of signing and
encryption (although most S/MIME clients will probably not be able to
handle the message). An message can also have multiple signers for the
same level. So for example the message is first signed by person A *and*
person B and then encrypted. Or to make it more exotic, a message if
first signed by person A, then encrypted, then signed by the gateway.
The information about these CMS levels is stored in the headers with
-0-0. -1-0 etc. For a brief explanation of these headers see:
https://www.ciphermail.com/documents/html/smime-setup-guide/#pf2a
If you need more detailed information please let me know.
Kind regards,
Martijn Brinkers
--
MHC SoftWare GmbH
Fichtera 17
96274 Itzgrund/Germany
voice: +49-(0)9533-92006-0
fax: +49-(0)9533-92006-6
e-mail: info(a)mhcsoftware.de
HR Coburg: B2242
Geschaeftsfuehrer: Matthias Henze