Disclaimer and Meeting requests sent as attachments

[jsalgado2001]

I came into an environment where they have a C170 on firmware 9.7.0-125.  I am not familiar with these devices so please explain in detail if you have any suggestions.

When sending an outbound Exchange 2010 calendar appointment to another organization that uses Exchange, they receive the email but no calendar appointment.  There is a disclaimer message rule on the C170 that applies to all outbound email as well.  

The receiver of the calendar appointment in the external organization receives an email with 2 attachments. One is ATT00001.txt and the other is ATT00002.htm.  They are both the same and contain the disclaimer of the sending organization that should normally be at the footer of the email.

Any incoming calendar appointment from an outside organization comes through fine and we can accept the appointment.
Also if I sent a calendar appointment to gmail.com it seems to show up correctly as an appointment in gmail as well.

Just sending a calendar appointment out from here is to any external organization using Exchange or O365 seems to be an issue.

Any ideas???

[Mathew Huynh]

Hello,

Generally this happens due to encoding mismatch from disclaimer and body of the email.

I would suggest to test this change when you have a time of low mail-flow

On your ESA go to the CLI

Use localeconfig

Press enter 2x so you get to this prompt

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? [Y]> Y

Regards,

Matthew

[jsalgado2001]

Matthew,

I did come across something similar in the forums about 4 years ago.  Unfortunately since I don't know these devices can you be more specific in the change you want me to make.
I can SSH into the box, but just a note, it is part of a 3 node cluster, so I'm not sure at what level the change needs to be made.
Would you be able to provide exact steps to change and reverse after I SSH into the one box?  Or if it is easier, can I see the settings in the GUI interface?  I'm a noob when it comes to these devices.
Thanks for your help.

[Mathew Huynh]

Hello,

SSH into your ESA.

You will be prompted with machine.esa> localeconfig

You will be given a few prompts.

Press enter twice or press enter until you get to the output:

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? [Y]> Y

Then change the current settings

I do not have access to my devices at this moment to share the full output.

Regards,
Matthew

[Mathew Huynh · Accepted solution]

Hello,

Output looks like this once SSH (CLI) is used.

c370.lab> 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: Try both body and footer or heading encodings

Choose the operation you want to perform:
- SETUP - Configure multi-lingual settings.
[]> 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.) []> Press Enter here to keep your current setting

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.) []> Press Enter here to keep your current settings

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? []> Y

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: Try both body and footer or heading encodings

Choose the operation you want to perform:
- SETUP - Configure multi-lingual settings.
[]> Press Enter

c370.lab> commit

Regards,

Matthew

[The-Messenger]

I have a similar or the same issue.  After implementing a disclaimer (footer) on incoming messages some invites were scrambled, those sent from gmail.com and some others.

Removing the disclaimer resolved the issue.

If I do set Disclaimers to "Y, the system should try to re-encode the message body", will this open up other possible formatting issues? 

What is the disadvantage to the Yes setting?

[Mathew Huynh]

Hello,

I have not noticed any issues nor comments after such changes were made previously.

Regards,

Matthew