Uploaded image for project: 'Jira Data Center'
  1. Jira Data Center
  2. JRASERVER-37918

Add reply-to header onto notification emails to prevent email client address collection problems

    XMLWordPrintable

Details

    • Suggestion
    • Resolution: Unresolved
    • None
    • None
    • None
    • 1
    • We collect Jira feedback from various sources, and we evaluate what we've collected when planning our product roadmap. To understand how this piece of feedback will be reviewed, see our Implementation of New Features Policy.

    Description

      NOTE: This suggestion is for JIRA Server. Using JIRA Cloud? See the corresponding suggestion.

      The way JIRA sends out emails currently can cause some confusion with the default address book behaviour of many mail clients.

      Lets consider a person called 'John Doe' with personal email address john.doe@example.com who also updates issues in a jira project with JIRA/project address jira@example.com

      If John updates an issue and a notification goes out from JIRA it currently will be sent with the from address header set to

      From: "John Doe (JIRA)" <jira@example.com>
      

      if a person receiving that notification clicks reply in their email client and sends a reply back to that notification, most email clients will by default then proceed to create an address book entry saying that John Doe's email address is jira@example.com

      That poses an issue the next time that user goes to write an email intended to go directly to John Doe rather than to JIRA, when they start typing John into the address field their mail client will then offer the JIRA address as a possible address for John potentially leading to them accidentally selecting the JIRA address and sending something confidential into the public JIRA project instead of the personal/private address they meant to send to.

      Thankfully there is a very simple tweak that could be made to the JIRA notification emails that prevents the problem. If the headers of the notification emails are updated to include a reply to header without a name attached so they are instead like the below example

      From: John Doe <jira@example.com>
      Reply-To: jira@example.com
      

      This means the email still looks the same when viewed in a mail client but when a user replies to it rather than the client seeing itself as replying to "John Doe <jira@example.com>" it instead sees itself as replying to "jira@example.com" which means the address book entry it adds doesn't include the name John Doe on it so there is no confusing second entry presented in the compose box the next time the user goes to compose an email to John Doe and no risk of the email being accidentally sent to the JIRA project address rather than John's person email address.

      The above fix was implemented by the JEMH plugin author for us 3 weeks ago, we have been making use of it in production for the last 3 weeks and it works brilliantly for alerts sent by JEMH (with no problems found by the large number of people we have using our JIRA server). Unfortunately since we still have some alert email sent natively by JIRA we are still having confusing address book entries being added in some cases when people reply to native JIRA notification emails. So we are requesting that Atlassian implements the same simple fix natively in JIRA, we believe as well as helping us it would benefit many of your other customers.

      Thank you for your consideration.
      -J

      Attachments

        Issue Links

          Activity

            People

              Unassigned Unassigned
              e25591fb1a6a Jason
              Votes:
              10 Vote for this issue
              Watchers:
              5 Start watching this issue

              Dates

                Created:
                Updated: