Disclaimer text breaking calendar invites

[sdonovan123]

Hello,

We started adding a text disclaimer at the top of email bodys stating the email is from an external source.  Since then many inbound emails that contain calendar invites particularly ical.  They come through as plain text with the disclaimer attached as att00001.txt.  

Has anyone else experienced this or know of what I should filter on to exclude them?

Thanks!

[marc.luescherFRE]

We had a similar issue, there are two possible ways to try to fix this:

a) create a filter to only add a disclaimer without ICS file attachments

b) modify the incoming controls to allow text and mime messages to come to your ESA.

c) you will also need to exclude all SMIME p7m and p7s file attachments otherwise your break signatures by adding your disclaimer

Hope that helps

Marc

[marc.luescherFRE]

re point b)

localeconfig


Behavior when modifying headers: Use encoding of message body
Behavior for untagged non-ASCII headers: Impose encoding of message body
Behavior for mismatched footer or heading encoding: Only try encoding from message body
Behavior when decoding errors found: Disclaimer is displayed as inline content and the message body is added as an attachment.


Choose the operation you want to perform:
- SETUP - Configure multi-lingual settings.
- CLUSTERSET - Set how multi-lingual settings are configured in a cluster.
- CLUSTERSHOW - Display how multi-lingual settings are configured in a cluster.
[]> setup

If a header is modified, encode the new header in the same encoding as the message body? (Some MUAs incorrectly handle headers encoded in a different encoding than the body. However,
encoding a modified header in the same encoding as the message body may cause certain characters in the modified header to be lost.) [Y]>

If a non-ASCII header is not properly tagged with a character set and is being used or modified, impose the encoding of the body on the header during processing and final
representation of the message? (Many MUAs create non-RFC-compliant headers that are then handled in an undefined way. Some MUAs handle headers encoded in character sets that differ
from that of the main body in an incorrect way. Imposing the encoding of the body on the header may encode the header more precisely. This will be used to interpret the content of
headers for processing, it will not modify or rewrite the header unless that is done explicitly as part of the processing.) [Y]>

Disclaimers (as either footers or headings) are added in-line with the message body whenever possible. However, if the disclaimer is encoded differently than the message body, and if
imposing a single encoding will cause loss of characters, it will be added as an attachment. The system will always try to use the message body's encoding for the disclaimer. If that
fails, the system can try to edit the message body to use an encoding that is compatible with the message body as well as the disclaimer. Should the system try to re-encode the message
body in such a case? [N]>

If the disclaimer that is added to the footer or header of the message generates an error when decoding the message body, it is added at the top of the message body. This prevents you
to rewrite a new message content that must merge with the original message content and the header/footer-stamp. The disclaimer is now added as an additional MIME part that displays
only the header disclaimer as an inline content, and the rest of the message content is split into separate email attachments. Should the system try to ignore such errors when decoding
the message body? [N]>

Behavior when modifying headers: Use encoding of message body
Behavior for untagged non-ASCII headers: Impose encoding of message body
Behavior for mismatched footer or heading encoding: Only try encoding from message body
Behavior when decoding errors found: Disclaimer is displayed as inline content and the message body is added as an attachment.

[sdonovan123]

I think this section right here is my issue.  It is currently set to Y.

Disclaimers (as either footers or headings) are added in-line with the message body whenever possible. However, if the disclaimer is encoded differently than the message body, and if
imposing a single encoding will cause loss of characters, it will be added as an attachment. The system will always try to use the message body's encoding for the disclaimer. If that
fails, the system can try to edit the message body to use an encoding that is compatible with the message body as well as the disclaimer. Should the system try to re-encode the message
body in such a case? [N]>

[marc.luescherFRE]

Happy to help.

We are running with disclaimers now for over 12 months and have not seen any other big issue other then the two I have mentioned.

The filter is very basic like this now :

CLITagExternalHeaderv4: if recv-listener == "InboundInterface" {
                            if NOT (header("X-IronPort-Filter") == "CLITagExternalHeader") {
                                if (NOT (attachment-filename == "smime.p7s")) OR (attachment-filename == "smime.p7m") {
                                    if NOT (mail-from-dictionary-match("WhiteListExternalTagging", 1)) {
                                        if NOT (mail-from-dictionary-match("KnownGroupDomains", 1)) {
                                            insert-header("X-IronPort-Filter", "CLITagExternalHeader");
                                            log-entry("CLITagExternalHeader");
                                            add-heading("External_Warning");
                                        }
                                    }
                                }
                            }
                        }

[sdonovan123]

Would just changing that option to Y resolve the issue or do I also need a filter like the one you provided?

[marc.luescherFRE]

First change the option , then you might still need the excludes i mentioned in a filter.

[vthnguyen1]

We currently have the same issue when Ironport sends outbound emails for appointments or invites to outside recipients using Office 365 or Outlook. The Ironport is configured to add disclaimers as footers to each outbound email.

However it works fine for outside recipients using Gmail, Yahoo email, or others but except Office 365 or Outlook.

We have tested by not adding disclaimers for certain senders, and then they can send out appointments or invites to outside Office 365 or Outlook recipients and those recipients can get and open the appointments or invites fine.

But why only Office 365 or Outlook are having this issue? Other email recipients not using Office 365 or Outlook have no problem.

Thanks!

[gkumarj]

Hi,

I guess your appliance is hitting below bug, you can try the workaround suggested that works.

https://bst.cloudapps.cisco.com/bugsearch/bug/CSCvh85675/?rfs=iqvred

Rgds,

Gagan

[vthnguyen1]

Hi Gagan,

We are in the current AsyncOS Version:12.1.0-087, but according to this bug CSCvh85675 it should be fixed in our current version. However it does not.

Can you help elaborating why it only happens to Office 365, Outlook or Exchange? And what the other ends (Office 365) would need to enable to make to fix this too if you know? We also have contacted with other ends' IT.

Thanks,