I am having the same issue, even if I add the domain to the allow list it will still block some important e-mails from out clients. Also the CC'd persons are not automatically added as request participants and not shown anywhere. Furthermore, some e-mails are not being threaded correctly as comments in the tickets, I am receiving duplicate issues.

Current config:
Portal is open but it needs users to sign up so we can avoid anonymous tickets from portal or from chats.
Checking for valid issue keys in the summary is disabled.

Is there any other alternative way to set-up an e-mail channel rather that using JSM's e-mail channel? Because we're missing important notifications and these filters are creating huge issues.

Jason, giving my feedback here in addition to voting.  I would not have chosen Jira had I known issues like this existed.  I would expect to have the option to add a new ticket for any email without an existing ticket reference in the subject line.  This should be base functionality.  Using message ID's alone can cause issues when a user re-sends a sent email.  In our case, employee termination details are put in an outlook form and users will reference a previously sent form so they don't have to refill out all the information.  I understand it's not best practice and we can/will do business differently, but we should have the ability to modify service desk settings to accommodate us and not the other way around.  I sure hope this functionality is prioritized. 

Hi everyone,

Thanks for your patience. We are continuing to fix email-related issues in Jira Service Management. We are exploring ways of making this possible but no work is planned on this in the next six months.

Cheers,
Jason and the Jira Service Management Team

Hi everyone,

I'm one of the Product Managers on Jira Service Desk looking to improve our feature set around incoming email and solve some of the longstanding open issues. I'm currently trying to better understand the problems and various use cases so we can develop solutions that benefit all customers and prioritise them correctly. I'd love to reach out to you to better understand, not just the need for this feature, but also other issues around incoming email. If you would like to discuss your use cases and requirements further, please reach out to me at jdcruz@atlassian.com.

I'll provide updates on our roadmap soon once our team has triaged these issues. Thanks for your patience.

Cheers,
Jason

I too have this issue.  CC'd users are not added as watchers/requested participants, and when a CC'd user replies to the email a duplicate request is opened.  This causes lots of confusion as the reporter can not see responses from CC'd users.  I must manually copy the response to the original request, add the CC'd user as a watcher/requested participant, and close the duplicate request.  This is not acceptable.  

I am voting for this issue to be fixed. 

Just added my vote but sad to see the issue hasn't been discussed since 2016.  Is this still the current issue for this request?  My retail teams often CC several people on a request and expect all of them to get a response.  Even after explain that this doesn't work / isn't supported many times, they still think it will work this way and then get angry when it doesn't.  Now I have retail managers telling staff not to use the Helpdesk email because it's "broken".  Would love to be able to come back to them with a fix so that I don't have to fight with them about using the helpdesk. 

@Lingbo Lu

Thank you for reaching out. I would like to chat with you about our current problem.
However, if I click on the link you've send me, I'm just directed to the original ticket.

@Ruud Stechweji Interested to hear if Lingbo offered any insight to your issue by email?

Currently experiencing exactly what you described back in July.
We are encountering more and more situations where customer interactions are being "lost" because JSD lacks the ability to display users that were CC'd on emails sent to the service desk.

I have added my vote as a JIRA cloud user.

I like the concept Dan has raised. Coin siding with this, there needs to be a notification feature to enable and disable comment notification being sent to the users/email addresses captured in this cc'd field.

Here is the paradigm employed by our existing HelpDesk.

"External cc" is a separate field. This field gets populated when an incoming email creates an issue (which std Jira can do) and is thereafter used and updated:

• when mail gets sent to Reporter, "External cc" also gets a copy
• if a new email arrives and creates a comment, any additions / removals to the cc list are taken into account.

I.e. it works just like Outlook...which is what people expect. It avoids any bad complications like suddenly creating additional users etc etc and is simple incremental addition to the existing functionality. (of course, if someone on cc is already a registered user, then can be added as a Watcher instead).