I have posted my workaround here

https://jira.atlassian.com/browse/JRACLOUD-15129?focusedId=3429016&page=com.atlassian.jira.plugin.system.issuetabpanels%3Acomment-tabpanel#comment-3429016

Salve, ci sono aggiornamenti in merito?

Jason,

Per other commenters, the problems with outlook are:

1. Images added as attachments.
2. Table formatted signatures get blown up and take up an immense amount of screen real-estate.
3. This was never a problem in Jira Server, which we were forced to migrate from. If it work on Jira Server, why not Jira Cloud?

Brandon

@Allison Stewart, going forward, I recommend you asking questions like these in the community forum. 

The short answer is: Yes. However, without knowing about regex or at least knowing someone who knows, it's maybe too hard. Many software developers know about regex. Below I've made a simple example:

{{issue.description.replaceAll("((%Profile\.YextUser\.Name%)[\s\S]*?(<End-token>|\Z))","=== Signature removed ===\n")}}

In order to remove multiple occurrences of signatures in the email (chain of replies), <End-token> will have to be replaced by a token ending your signature-table. Otherwise, only the first occurrence of a signature will be removed along with anything that follows. 

This sounds like a possibility for me, but I am not at all familiar with regex.  But, all of our signatures start with the coding %Profile.YextUser.Name%.  This is the beginning of massive table of user headshot, address, logos, icons, etc...  

Would you think it's possible to set up an automation with this?  And how?

@Karsten Zacher Nielsen , Have tried something similar, problem for us is getting all 1100+ employees to sign off with the same signatures is not viable, and many of the common sign off's such as " with regards , thanks, and regards will often come up in the wording in the body of the email, which pretty much makes the automation unviable to use. 

The biggest gripe I have is that we are paying big dollars to Atlassian for a service that is inferior in many ways to the product they made us migrate from. Seriously if they have the developers to make the things they sell, then it cannot be hard to just get it right. If the signatures actually rendered correctly it would solve the first issue, if the images actually rendered at a constrained size it would solve the second issue and if they allowed automation to be able to remove images by hash it would solve the third issue. I have read most of the posts in this thread and those 3 solutions alone would solve 95% of the issues people have. 

I dont see Atlassian applying a discount to their customers due to their product being broken ? so how about they just fix the issue 

@Allison Stewart (and others), post processing is what we can do using automations. For example, you can use "Edit issue fields" on Description with a (terrible) regex like this:

{{issue.description.replaceAll("((Best regards|Mit freundlichen Grüßen)[\s\S]*?(C365C\}\s\*([\s\S]{2,64})\*\{col[\s\S]*?mailto:([a-zA-Z0-9\-\.]*@[a-zA-Z0-9\-\.]*.[a-zA-Z]{2,3})[\s\S]*?)?(\*From:\*|\*Fra:\*|-Original Message-|\Z))","=== Signature removed from mail sent by: $4 / $5 ===\n")}}

It takes a while to figure out the details playing around with some web regex evaluator like regex101.com. 

The regex above removes signatures even if the issue Description is fed with a chain of mails. It's not 100% bullet proof, and it shares the problem you mentioned about keywords ("Thanks" in your case). Anyway, it works in most of our situations.  

Same for me.  Our signatures are structured as tables.  To use a special character in the custom detection method to indicate the start of that table doesn't work.  Sure, I can use "thanks" and it works great.  But then I'll never be able to use the word "thanks" in the body of the message. I can't tell my users to avoid key words.

What about some kind of post-processing after the email/signature are put into the description?  Couldn't you provide something to scrape the description field and eliminate everything after a certain custom character or something?

If catching it on the front doesn't work, then provide a post-process on the back.

Hey Jason,

I feel like half of the problem here is that the mail imports into the description field.

Where possible the description field should be populated with the top part of the mail, which is most likely to describe what a user actually wants to be done.

There will be some cases where this is not correct or you can't detect the most recent reply for whatever reason. Why not have the original mail accessible as an attachment. Or in a separate tab? That way the agent can review the mail (as they would the description anyway), ascertain what the user actually wants and then populate the description with that. It also means that you can view the original formatting of the mail as well as the TO + CC recipients, which is otherwise inaccessible information in Jira. https://jira.atlassian.com/browse/JSDCLOUD-11383 

The fact that a poorly formatted 20+ thread mail with a billion stupid logo attachments is pasted into the 'Description' field in the main ticket view UI... You can tell from the comments, makes people mad. It's more difficult to find what action the agent needs to take.

You are in control so will need to follow.  @Jason D Cruz if you can stress to your teams that Outlook is the #1 Email client in the world then Gmail.  I will try the "custom detection" feature and let you know if it works, same for the other two 15-July posts.