Collaboration in the Enterprise from the perspective of Anthony Holmes, an IBM Premium Support Manager

Why disclaimer software normally breaks email signatures and encryption

Anthony Holmes  11 July 2008 12:46:30 AM
Here's a (fairly) quick description as to why software that adds corporate disclaimers will break email encryption and electronic signatures using Public/Private key standards like X.509.

I'm talking about the software used in many organisations that adds a standard corporate disclaimer at a gateway when the emails are being sent to the internet.

(And when I speak of electronic signatures I'm not talking about signatures that show your phone number and corporate logo. I'm talking about electronic signatures that prove that you were the person who sent this message and that nobody has tampered with the message.)


Imagine the structure of an email:
Header information used in any SMTP Message (SendTo, Subject, SMTPOriginator and Routing fields, etc)
Multi-Part S/MIME Message

The body of the text is here.

Any attachments are also contained here.

If you've encrypted the message, this will be a box of encrypted information, entirely unreadable unless you have the Private Key to read this document. You created this encrypted version by using the Public key of the Recipient which you've got in your possession.

(One of the 'parts' might be a plain text version of the body of the email in case the recipient is unable to read MIME formatted messages on their email system. But it will still be encrypted if you encrypted this email.)
At the end there's the electronic signature. If any single byte of information within the Multi-Part SMIME Message is changed, then the signature is invalidated.



It's conceptually impossible for anybody except the original sender (who also possesses the Recipient's Public Key) to legitimately create or change the Multi-part SMIME Message component. Any attempt to do so without the Sender's Private Key and the Recipient's public key will:

a) break the electronic signature, and
b) mean that it is no longer properly encrypted.

Any attempt to "staple" a disclaimer onto the end of the message after the sender has pressed "Send" is an attempt to tamper with the message. That's exactly what the electronic signature is guarding against.

(The Header information isn't encrypted, so the Subject or the SendTo fields etc. could be changed without breaking the encryption. Some of these fields can also be changed without breaking the signature, but this doesn't help you because they won't display a disclaimer. I guess there's a chance that you could squeeze the disclaimer into the Subject line after the email has been sent: that's not a pretty approach, but it might work.)

If you really want to have a corporate disclaimer and also allow encrypted/electronically signed emails, the best bet would probably be to tap into Notes' standard (non-electronic) Signature functionality to add the disclaimer before the message is sent, so the sender will sign and encrypt the message which already has the corporate disclaimer in it. You set up users with a (non-electronic) Signature that has the disclaimer, and then find a way to prevent them from changing/removing the disclaimer (possibly by making changes to the mail file design).

Another alternative would be to use a tool like PGP Zip to create an attachment that is encrypted, and simply email that.

The third approach would be to delay the point at which the email is encrypted, so that it isn't the client who does this, but it happens at the Gateway instead. There's at least one commercial product that does this.