The Problem

Permissions on the support projects in https://support.atlassian.com (SAC) are configured to allow all actions to Atlassian and to the reporter (the customer), and no access to anyone else. That is customers can only see and do stuff on their own cases.

(Actually we also allow access to all members of the CC multi-user custom field, so that we can add in work colleagues of the reporter.)

This also, of course, applies to comments added to an issue via email. An email containing an issue key will be added as a comment on the issue, but only if the email address matches a user who is the reporter of the issue or Atlassian (or a member of the CC field).

However with this configuration, the following use case is a problem:

1. Customer gets an email notification from one of their cases in SAC. For example, the support engineer has responded to their case.
2. The customer's email client is configured so that their email address is set to a different one to their email address in SAC, often an email alias. For example, if their account in SAC has email address fsmith@example.com, the email address in their email client might be fred.smith@example.com.
3. The customer replies to the email.
4. SAC receives the email and:
   1. checks to see if there is a user with that email address
   2. creates a user if there isn't one
   3. then rejects the reply because the user does not have access to the issue. (The user for fsmith@example.com may have been the reporter, but the user for fred.smith@example.com does not have permission.)
   4. forwards it to the mail handler forward address for a human to deal with the error
5. One of our triage engineers deals with the error by manually adding the email content as a comment to the email, adds any attachments in the email, and uses his judgement to decide whether to add the "other" user (i.e. fred.smith@example.com) to the CC field for that issue. *

A variation of this is that the customer receives the email notification, hasn't got time to respond as they are about to go home, so forwards it to their home email account, then responds to it when they get home. Same result.

We get on average 10 of these per day on SAC.

The problem has the following impact:

• The triage engineer has to manually deal with them.
• We end up with multiple accounts for the same customer. In some cases, this leads to the customer reporting some issues as one user, and some as the other, then complaining that they can't see all their issues when they log in.
• The combination of dealing with the above two points takes the triage engineer on average 1 hour per day.
• We end up with a whole bunch of extra accounts we don't need. If/when we move to a single user base behind SAC, JAC and all our other systems, we (presumably) won't be able to account new accounts from emails anyway, so it is a problem we will have to deal with eventually anyway.

* If we do add the other user to the CC field (and it is not always the case that we do), we can then re-send the email to JIRA, and the email (and its attachments) will be added to the issue. However the email we need to resend is actually an attachment to the email that is sent to the forward mail box, and the only email client that we are aware of that will allow us to re-send an email attached to another email is ... mutt. Sigh.

The Proposed Solution

1. Add an extra parameter to all the comment email handlers called something like anonymouscomments. When anonymouscomments=true, if there is not a user in JIRA matching the email address, add the comment anonymously to the issue, with the first line of the comment displaying the email address and, if present, the full name pulled from the email.

Thus, the email is added to the issue as the customer would have wanted. No new user is created in JIRA, so no one who shouldn't have access to JIRA or the issue gets access. The email notification resulting from the new comment is sent out to the correct users.

However, given that the whole world can now add comments to issues in JIRA, this opens the door to spam and denial of service attacks. (Denial of service attacks because unlimited comments added to an issue eventually results in OutOfMemoryErrors.) In order to mitigate these:

2. For the specific case of anonymouscomments=true and there not being a JIRA user with the email address (i.e. when we are about to make an anonymous comment), rather than just matching against issue key in the email subject, also match the remainder of the email subject against the issue summary. If they don't match, don't add a comment and do the normal email error handling/forwarding.

This covers off the case where a malicious somebody with no access to the JIRA instance is just auto-generating issue keys and hammering the JIRA instance with emails with those keys.

3. Add another parameter to all the comment email handlers called something like maxcomments. Example usage: maxcomments=1000. The mail handler will not add a comment to an issue if there are already <maxcomments> comments on the issue. The JIRA admin could set this to a value higher than you would ever get in normal usage, but less than would start to cause OutOfMemoryErrors or related problems.

Note: In discussions about this problem and proposed solution, some people initially suggested that we should also send an email to the user saying that that their email address is different to the one in SAC. I don't think we should do this, as it is our experience of when we have done this when manually handling these problem emails, that this confuses and annoys some users. They don't understand or (legitimately, I feel) don't care. They just want it to work.

We have the same problem on one of our internal Atlassian JIRA instances, and I'm sure that there would be customers who have the same problem and would benefit from the solution.