Undesired email address suddently being added to request

[Joshua MD]

Hi,

I'm sorry for the long description but this problem is proving difficult to find the correct search terms for. So I want to make sure that I'm explaining the problem clearly

We are using on-prem Jira Service Desk (Server). We are set up to receive requests via email (Office 365). Emails are sent to an IT Support mailbox (support@company.com). We have an Exchange transport rule which will redirect relevant emails to another mailbox (itsupport@company.com). It is that mailbox which Jira Service Desk monitors and from which it will generate tickets. We do it this way because there are several regular emails (notifications, etc.) which are sent to support@company.com that we don't want generating tickets in JSD. So the transport rule selectively moves only the appropriate emails to itsupport@company.com.

Because the emails are originally sent to support@company.com and then redirected by Exchange to itsupport@company.com, the "To" field in the email header always reads support@company.com, even after being moved to the itsupport@company.com inbox. This is normal expected behaviour for this type of transport rule in Exchange. Up until a few days ago, this system/process was working beautifully. Jira would grab the email, generate a new ticket with the address in the "From" field being added as the "Reporter," and add any additional addresses found in the "To" or "Cc" fields to the "Request participants" field of the ticket. However, a few days ago, apparently on its own with no configuration changes to Jira or Exchange/O365, Jira now adds support@company.com to the "Request participants" field of every ticket.

One ticket, it didn't do it. Then, the next ticket, 30 minutes later, support@company.com was being added to the "Request participants" of every ticket. We examined the email headers and verified that nothing was different in the headers (specifically looking at the "To" field, which reads support@company.com on all the emails we examined). We tried rebooting the Jira Service Desk server, which resulted in no change to this new behaviour.

I have no idea what changed to cause this behaviour but the result is undesirable. We don't want support@company.com being added as a participant. It, among other things, causes unnecessary emails being sent to support@company.com and somewhat of a 'looping' effect. Has anybody experienced this? I've tried getting Exchange to modify the "To" field in the header, but have had no success with that. I also thought about an automation rule in Jira to remove that address from the "Request participants" field but, again, have not enjoyed any success there either.

I don't know why, after running Jira Service Desk for several months now, that it has suddenly changed its behaviour. We'd really like to have it back the way it was a couple weeks ago. support@company.com should not make its way into any field of the ticket.

I'm going around in circles now with this one and would really appreciate any suggestions, solutions, or even someone else stating they've experienced the same/similar thing.

[Andy Heinzer]

Hi Mike,

Thanks for the detailed post. Sorry to hear about this problem, it sounds rather frustrating.

I understand that you have been using an Exchange transport rule in order to redirect some selected messages from the first email address to a second email address that Jira Service Desk (JSD) is ultimately checking here for incoming requests. Also recently some messages have started to include the first address a requested participant here.

Jira Service Desk though has an expectation that end users are directly emailing the mailbox that JSD is checking here. In your case, that's not actually what is happening. This can have other unintended consequences as well, such as end users getting an email response from a different address then where they directed their message.  I don't really have an explanation for why this might have been working in a different way in the past but no changes have occurred to Jira or Exchange recently.

Ultimately, I think the best solution here is to remove this redirection of messages and instead let Jira Service Desk check the mailbox that end users are sending to. I understand if that is not the desired way in your case, but I believe this is the way in which Jira Service Desk's mail handler is expecting to work.

That said, I would be interested to take a closer look at the email headers of a message that behaves in this way. Perhaps we can learn more about your environment in order to better understand this from the details in the email headers. I would expect that Jira Service Desk would add any email address in the To and/or CC field of the email into the request participants field provided that Jira. However it is unclear to me where exact this first support email address is appearing within that received message in the second inbox.

It might be possible to restrict the sharing of requests here so that other email addresses are not being added to the request participants, but this would be a project wide setting. There are also setting you could change on the project level in order to control who customers/end users can share requests with. See Managing access to your service desk for more details on restricting who can raise requests and who customers can share requests with.

I hope this helps.  Let me know.
Andy