messages from from certain email agent(s) are not properly stripped with strip quotes

Problem

When using a Jira Service Management Mail Handler (configured in Project Settings > Email Requests) to process incoming emails, the Strip Quotes functionality does not work as expected in some cases.

If an agent replies to a notification to add a new comment to a request, depending on the mail client that is used and the encoding of the email content, the email might not be stripped at all. As a result, a comment containing the entire email thread including the quoted email will be added to the ticket.

We found that this bug occurs with a combination of the following factors:

• the email contains both text and html contents
• the html content is is using charset="us-ascii" as the content type
• the email contains single-quote and/or double-quote characters

This bug was observed when agents were using Outlook Client: Microsoft 365 Apps for Enterprise to reply to emails.

Environment

• Jira Service Management (JSM) Sever/Data Center 4.0.0 and any higher version
• JSM project using a JSM mail handler configured in Project Settings > Email Requests to process incoming emails

Steps to Reproduce

1. Install JSM on any version 4.0.0 and above
2. Create a JSM project
3. Configure a JSM Mail Handler in that project in Project Settings > Email Requests
4. Raise a request in the project and trigger a notification from that request (by adding a comment for example)
5. Reply to the request using a Mail Client that sends emails in using the "us-ascii" encoding, and make sure to include text with single quote and double quote characters in that reply

Example of source of an email reply that triggers the bug:

Content-Type: multipart/alternative; boundary="000000000000f37b3105e7adb3e5"

--000000000000f37b3105e7adb3e5
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: quoted-printable

he's not in the office today.

On Thu, Aug 18, 2022 at 11:05 PM Julien Rey <test@atlassian.com> wrote:

> test
>

--000000000000f37b3105e7adb3e5
Content-Type: text/html; charset="us-ascii"
Content-Transfer-Encoding: quoted-printable

<div dir=3D"ltr">he&#8217;s not in the office today.</div><br><div class=3D"g=
mail_quote"><div dir=3D"ltr" class=3D"gmail_attr">On Thu, Aug 18, 2022 at 1=
1:05 PM Julien Rey &lt;<a href=3D"mailto:test@atlassian.com">test@atlassian=
.com</a>&gt; wrote:<br></div><blockquote class=3D"gmail_quote" style=3D"mar=
gin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1=
ex"><div dir=3D"ltr">test</div>
</blockquote></div>

--000000000000f37b3105e7adb3e5--

Expected Results

The quoted message will be stripped by the mail handler and a comment will be added to the request without the quoted message:

Actual Results

The quoted message is not stripped by the mail handler and a comment is added to the request including the quoted message:

Note

The bug does not occur when the Mail Client uses the UTF-8 charset to send emails. For example, if the content of the email reply is as follows, the quoted email is stripped as expected:

--000000000000f37b3105e7adb3e5
Content-Type: text/plain; charset="UTF-8"

he's not in the office today.

On Thu, Aug 18, 2022 at 11:05 PM Julien Rey <test@atlassian.com> wrote:

> test
>

--000000000000f37b3105e7adb3e5
Content-Type: text/html; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable

<div dir=3D"ltr">he&#39;s not in the office today.</div><br><div class=3D"g=
mail_quote"><div dir=3D"ltr" class=3D"gmail_attr">On Thu, Aug 18, 2022 at 1=
1:05 PM Julien Rey &lt;<a href=3D"mailto:test@atlassian.com">test@atlassian=
.com</a>&gt; wrote:<br></div><blockquote class=3D"gmail_quote" style=3D"mar=
gin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1=
ex"><div dir=3D"ltr">test</div>
</blockquote></div>

--000000000000f37b3105e7adb3e5--

Note the difference between the way the single quote is encoded for "he's":

• in ASCII

  he’s
  

• in UTF-8

  he's
  

Workaround

There is no workaround for this, besides using a Mail Client that uses the UTF-8 charset instead of us-ascii when sending email replies.

A bugfix is being developed for future versions.