How do I stop/modify emails on security issues?


When a user reports a security issue, an email is sent back to them in plain text. All subsequent activity on the issue is also reported by email to all watchers and paticipants.

As it's not really feasible to encrypt such emails, I have been looking for a way to stop notifications for issues that are reported as security issues. Beyond creating a separate project with its own notification scheme, does anyone have a suggestion for how emails could be stopped based on the security level field?

Alternately, is there a way to control what information is sent in emails and controlling that depending on the security level?


5 answers

1 accepted

0 votes
Accepted answer

I've raised an issue suggesting that the content of notifications for issues with a security level set should be controlled.

0 votes

You mention the security level field - Jira will only send email to people who can see an issue, so if you're using security levels, that could stop the emails to people who shouldn't see them.

(Unless you've configured something like the JETI plugin which allows you to leak information to users who couldn't normally see it)

Hi, Nic.

It is true that Jira limits access to certain people, but our problem is that it still sends emails to those people in plain text, including the reported details of the problem, which is insecure.

Then you need to find out what you have configured that is letting it leak this information and turn it off.

If a user cannot see an issue, Jira will not send email to them, unless you've bypassed the security on emails. It's usually a plugin like JETI or a script-runner function to send extra emails or a post-function to do the same. Or, you might have set up a dummy user with a group email address.

I don't think you read what I wrote, Nic.

Emails are not being sent to people who should not be receiving them. That is not the problem.

The problem is how the emails are being sent. I can find no way of configuring Jira to stop sending emails, or to modify the content of emails, when the issue is a security issue. So the details of security issues are being sent by email, unencrypted and open to interception.

Mmm, it was spectacularly unclear. You've never defined what a "security issue" is for a start. I was assuming you needed to hide them properly from users and had implemented that.

Now I understand that you've got an issue type that you don't want to send email for, but your users should still be able to see it in Jira.

Simple answer - move them to a project with a notification scheme that says "don't send email"

I don't think there's another way to supress email directly without hiding the issues, which means people won't see them in the ui either.

I've never been accused of being "spectacularly unclear" before. We could go around in circles like this for a while, if you like.

We are using a pretty ordinary security scheme with a level field that distinguishes security issues.

I'd prefer not to split our project as it's rather large with many people involved. I had considered that, but it seems there should be alternatives.

I found a feature request that looks like it would do something similar to what you are looking for. I suggest voting for it if it will fit your needs.

You could create a fake smtp server(maybe a relay service) that could scan the email and filter (drop) the email messages before forwarding them on. The smtp relay service could run on the same machine as Jira. The relay service could interface with a secure smtp service if you want to deliver the email securely.

The solution we eventually adopted was to hack the email templates used by Jira. In the templates, there is potential to distinguish security issues and act selectively.

#if ($issue.securityLevel)
        output a simplified version masking details
        output the normal thing

I've reported this issue as a bug to Jira JRA-37581, but Jira doesn't think this is something worth changing. Hopefully they'll change their mind.

It's good to know that we now have a more secure instance of Jira than Jira themselves.

Suggest an answer

Log in or Sign up to answer
Community showcase
Published Nov 27, 2018 in Portfolio for Jira

Introducing a new planning experience in Portfolio for Jira (Server/DC)

In the past, Portfolio for Jira required a high degree of detail–foresight that was unrealistic for many businesses to   have–in   order to produce a reliable long-term roadmap. We're tur...

2,698 views 18 21
Read article

Atlassian User Groups

Connect with like-minded Atlassian users at free events near you!

Find a group

Connect with like-minded Atlassian users at free events near you!

Find my local user group

Unfortunately there are no AUG chapters near you at the moment.

Start an AUG

You're one step closer to meeting fellow Atlassian users at your local meet up. Learn more about AUGs

Groups near you