Disclaimer+ Encryption issue

richardacarey · ‎08-13-2009

Hello,

This seems to be a weird problem.

I recently edited the company disclaimer by cutting/pasting/editing from a text editor so it would word wrap. It worked like a charm.

There are a few users who need to use PKI based encryption instead of the CRES due to the policies of the vendors they do business with.

I was informed that the external recipients now receive the encrypted emails with a blank body.

After looking at many other possible reasons with no luck, I decided to temporarily take away the disclaimer/footer from the outbound emails and lo and behold, the encryption issue went away.

Any ideas what may cause this and if there is a solution? I have already converted the disclaimer to both HTML and text format with no luck.

Any help would be greatly appreciated. Thanks.

Andrew Wurster · ‎08-20-2009

we need more specifics here.... versions, models, mail_logs, message samples, and so on.

andrew

richardacarey · ‎08-21-2009

The reason for this issue is apparently due to the fact that the disclaimer rule that I have set for outbound mail will have to pull apart the message to insert the disclaimer/footer. Since the message is encrypted via PKI, the content becomes unreradable after it reassembles the message. I initally put the following message filter in place:

no_footer_in_encrypted_msgs: if (sendergroup == "RELAYLIST") AND (NOT
(encrypted))
{
add-footer("disclaimer");
}

That did not work although it did successfully diferentiate between inbound and outbound mail.

Instead I created an outbound content filter that had a higher precedence than the disclaimer rule. I had it look for a specific LDAP group and made the 6-7 people who were having issues members of that group. Problem solved.

steven_geerts · ‎08-22-2009

Hi Ricarey,

I assume that your PKI encryption is performing S/Mime encryption.
When a message is S/Mime encrypted, all the original body parts (plain text, HTML, attachments etc.) are replaced by one S/Mime encrypted body part.
If you tamper that body later on (for instance by adding a disclaimer) the decryption will fail. The logic behind this is simple: encryption is used to make sure trusted information is transported in a secure way, if there is something or someone tampering with the message on it's way from sender to recipient, it might also have tampered with the protected content... so do not trust this message...

By creating your rule you have done exactly what you should do: exclude encrypted messages from tampering. (I hope I was able to explain you the theory behind it)

Best regards,

Steven