====
Alice has a Well-Known Encryption Apppliance
Bob has a mail processing appliance to direct the mail
Bob is running Djigzo
Alice sends a message to Bob
Subject:Test 03
Bob's mail processing appliance adds text [DJG-inbound] to the subject, giving:
Subject: Test 03,[DJG-inbound]
The mail processing appliance forwards the message on to Djigzo.
Djigzo forwards the mail on to the maibox server with the the header:
Subject:Test 03
Bob now is confused as to what happened to his subject header.
As far as I know this would be correct behaviour if we had specified Content-Type of
message/rfc822, that should trigger SMIME v3.1/3.2 "header protection", but this is NOT the
case as the Content-Type was not set. It's confusing for me as other S/MIME gateways do not have the same behaviour.
Do you maybe know of a setting to stop this happening ?
See james log file extract below to see the disappearing act.
Regards,
Jim
=====
27 Nov 2010 13:49:43 | INFO incoming | MailID: 1fc43643-1598-4837-8fec-652df483cf4b; Sender: jim(a)qa.xxx.net; Remote address: 192.168.50.32; Recipients: [jim(a)secure-mail-sandbox.com]; Subject: Test 03,[DJG-inbound]; Message-ID: <30106702.277.1290862166292.JavaMail.root(a)ncmous01.bank.prd>; (mitm.application.djigzo.james.mailets.Log) [Spool Thread #1]
27 Nov 2010 13:49:43 | INFO internal | MailID: 1fc43643-1598-4837-8fec-652df483cf4b; Sender: jim(a)qa.xxx.net; (mitm.application.djigzo.james.mailets.Log) [Spool Thread #1]
27 Nov 2010 13:49:43 | INFO decryptRemoveSignature | MailID: 1fc43643-1598-4837-8fec-652df483cf4b; Sender: jim(a)qa.xxx.net; (mitm.application.djigzo.james.mailets.Log) [Spool Thread #1]
27 Nov 2010 13:49:43 | INFO postDecrypt | MailID: 1fc43643-1598-4837-8fec-652df483cf4b; Sender: jim(a)qa.xxx.net; (mitm.application.djigzo.james.mailets.Log) [Spool Thread #1]
27 Nov 2010 13:49:43 | INFO transport | MailID: 1fc43643-1598-4837-8fec-652df483cf4b; Sender: jim(a)qa.xxx.net; Remote address: 192.168.50.32; Recipients: [jim(a)secure-mail-sandbox.com]; Subject: Test 03; Message-ID: <30106702.277.1290862166292.JavaMail.root(a)ncmous01.bank.prd>; (mitm.application.djigzo.james.mailets.Log) [Spool Thread #1]
Djigzo by default also protects the subject (i.e., the subject is
encrypted and signed). The main reason for this is that sometimes the
subject contains sensitive information. For example some automated
medical systems add sensitive information to the email subject. Because
the subject is protected as well, the message subject can be removed (or
changed into something non sensitive). After decryption, the original
(protected) subject will be placed back. You can disable this on the
sending side by changing the <protected> header settings in config.xml
(/etc/djigzo/james/config.xml which is a symlink to
/usr/share/djigzo/conf/james/SAR-INF/config.xml)
Change
<protectedHeader> subject </protectedHeader>
into
<protectedHeader> </protectedHeader>
Note: a space is required because empty values are not allowed.
This setting will only change the sending side. The receiver side will
restore protected headers if they are available. It is currently not
possible to disable this for the receiver side. Could you add a JIRA
request for this? (see https://jira.djigzo.com).
Kind regards,
Martijn Brinkers
···
On 11/27/2010 02:57 PM, Jim Leitch wrote:
Hi,
I noticed that Djigzo is rewriting the header.
Take the following example:
====
Alice has a Well-Known Encryption Apppliance
Bob has a mail processing appliance to direct the mail
Bob is running Djigzo
Alice sends a message to Bob
Subject:Test 03
Bob's mail processing appliance adds text [DJG-inbound] to the subject, giving:
Subject: Test 03,[DJG-inbound]
The mail processing appliance forwards the message on to Djigzo.
Djigzo forwards the mail on to the maibox server with the the header:
Subject:Test 03
Bob now is confused as to what happened to his subject header.
As far as I know this would be correct behaviour if we had specified Content-Type of
message/rfc822, that should trigger SMIME v3.1/3.2 "header protection", but this is NOT the
case as the Content-Type was not set. It's confusing for me as other S/MIME gateways do not have the same behaviour.
Do you maybe know of a setting to stop this happening ?
See james log file extract below to see the disappearing act.
Regards,
Jim
=====
27 Nov 2010 13:49:43 | INFO incoming | MailID: 1fc43643-1598-4837-8fec-652df483cf4b; Sender: jim(a)qa.xxx.net; Remote address: 192.168.50.32; Recipients: [jim(a)secure-mail-sandbox.com]; Subject: Test 03,[DJG-inbound]; Message-ID: <30106702.277.1290862166292.JavaMail.root(a)ncmous01.bank.prd>; (mitm.application.djigzo.james.mailets.Log) [Spool Thread #1]
27 Nov 2010 13:49:43 | INFO internal | MailID: 1fc43643-1598-4837-8fec-652df483cf4b; Sender: jim(a)qa.xxx.net; (mitm.application.djigzo.james.mailets.Log) [Spool Thread #1]
27 Nov 2010 13:49:43 | INFO decryptRemoveSignature | MailID: 1fc43643-1598-4837-8fec-652df483cf4b; Sender: jim(a)qa.xxx.net; (mitm.application.djigzo.james.mailets.Log) [Spool Thread #1]
27 Nov 2010 13:49:43 | INFO postDecrypt | MailID: 1fc43643-1598-4837-8fec-652df483cf4b; Sender: jim(a)qa.xxx.net; (mitm.application.djigzo.james.mailets.Log) [Spool Thread #1]
27 Nov 2010 13:49:43 | INFO transport | MailID: 1fc43643-1598-4837-8fec-652df483cf4b; Sender: jim(a)qa.xxx.net; Remote address: 192.168.50.32; Recipients: [jim(a)secure-mail-sandbox.com]; Subject: Test 03; Message-ID: <30106702.277.1290862166292.JavaMail.root(a)ncmous01.bank.prd>; (mitm.application.djigzo.james.mailets.Log) [Spool Thread #1]
Zitat von Martijn Brinkers <martijn(a)djigzo.com>:
Hi,
I noticed that Djigzo is rewriting the header.
Djigzo by default also protects the subject (i.e., the subject is
encrypted and signed). The main reason for this is that sometimes the
subject contains sensitive information. For example some automated
medical systems add sensitive information to the email subject. Because
the subject is protected as well, the message subject can be removed (or
changed into something non sensitive). After decryption, the original
(protected) subject will be placed back. You can disable this on the
sending side by changing the <protected> header settings in config.xml
(/etc/djigzo/james/config.xml which is a symlink to
/usr/share/djigzo/conf/james/SAR-INF/config.xml)
Change
<protectedHeader> subject </protectedHeader>
into
<protectedHeader> </protectedHeader>
Note: a space is required because empty values are not allowed.
This setting will only change the sending side. The receiver side will
restore protected headers if they are available. It is currently not
possible to disable this for the receiver side. Could you add a JIRA
request for this? (see https://jira.djigzo.com).
Is this standard S/MIME eg. to expected that every S/MIME kompatibel
client out there is able to "restore" the subject from encrypted mail?
So it would work to place in a dummy subject for every encrypted mail
to protect sensible information leaking out by the unecrypted subject?
Does this also work in case of signing without encryption?
Is this standard S/MIME eg. to expected that every S/MIME kompatibel
client out there is able to "restore" the subject from encrypted
mail? So it would work to place in a dummy subject for every
encrypted mail to protect sensible information leaking out by the
unecrypted subject? Does this also work in case of signing without
encryption?
Unfortunately this is not widely supported. Strangely enough it's
supported by Outlook Express but not by Outlook. The main reason I added
it was for gateway to gateway encryption because it allows you to
completely remove the from, to and subject headers from the encrypted
message.