Uploaded image for project: 'Jira Service Management Data Center'
  1. Jira Service Management Data Center
  2. JSDSERVER-8487

The "From:" header format in Request Created customer notification does not match the static string defined in 'Email from' global Jira settings

    • Icon: Bug Bug
    • Resolution: Fixed
    • Icon: Medium Medium
    • 5.13.0
    • 4.16.1, 4.17.0
    • Customer Notification
    • None

      Issue Summary

      With this bug fix, customer notifications like Customer-visible status changed / Public comment added are complying to the format defined in Email from global Jira settings but the Request Created customer notification is using the JSM portal name as its "From:" header.

      The Request Created customer notification that originate from 'Raise this request on behalf of' is complying to the format defined in Email from global Jira settings but this is not the case for customer notification triggered from customer's self-created request.

      This is specific to a use case where we want a static string in the "From:" header.

      Steps to Reproduce

      1. Jira administration » System » General configuration:  * Update *Email from  with a static string like 'IT Support'
      2. Log into the customer portal as customer
      3. Create a new request
      4. Check the customer notification

      Expected Results

      The Request created customer notification's "From:" header complies to the format defined in Email from global Jira settings.

      Actual Results

      The Request created customer notification is using the JSM portal name as its "From:" header.

      Workaround

      Note: This workaround needs a third party installation

      To rewrite the FROM name and FROM email addresses from JIRA and/or JIRA Service Desk:

      1. Install Postfix either on this server or on another trusted server you can administer.
      2. Configure the Postfix server to relay email to the Internet.
      3. Now configure Postfix to rewrite the outbound emails from JIRA.
      4. Create the smtp_header_checks file to set up the rewrite rules.
      5. A simple rule (uses regex syntax) would be like:
      /^From:.jira-support@domain.com./ REPLACE From: Support <support@domain.com>
      If JIRA Service Desk sends an email from "Bob Agent" <jira-support@domain.com> it will be replaced with "Support" <support@domain.com>, standardising the FROM name of the email from JIRA Service Desk.
      If the Customer triggers a workflow and the email has the customer name:
      "Customer Name" <jira-support@domain.com> will be replaced with "Support" <support@domain.com>
      You can add as many rules as required and target any part email header.
      Useful if you have multiple email addresses that JIRA Service Desk sends from.
      6. Edit the Postfix main.cf file, typically /etc/postfix/main.cf
      7. Add the line: smtp_header_checks = pcre:/etc/postfix/smtp_header_checks
      8. Restart Postfix
      9. In JIRA Admin, /secure/admin/OutgoingMailServers.jspa Change the Outgoing Mail, SMTP Mail Server to use a Postfix server as the destination.
      10. All email from JIRA and JIRA Service Desk will be delivered via Postfix.
      11. Test and verify OK.
      12. Adjust the configuration as per your requirements.

      This solution was based on this answer in the CentOS Stack Exchange, http://serverfault.com/questions/717719/how-can-i-strip-or-rewrite-the-senders-name-of-a-from-address-when-using-postfi#answer-724468

          Form Name

            [JSDSERVER-8487] The "From:" header format in Request Created customer notification does not match the static string defined in 'Email from' global Jira settings

            This is indeed an absolutely annoying problem. I banged my head to find out what's happening behind the scenes here (and to find this bug entry), and why sometimes the "From Name" is set to the Portal Name, but other times it's set to "E-Mail From" from the General Configuration Settings.

            According to documentation https://confluence.atlassian.com/jirakb/how-to-change-the-sender-s-name-of-the-service-management-notifications-933708029.html this should be set to the Portal Name - by default!.

            The next inconsistency is that the Customer Notifications' from address is exactly the same as the one used for the notification scheme (which is intended to be used for sending internal notifications).

            While the behavior for the from name seems to be a bug (as addressed here), it still is an absolute nightmare to administrate the way emails are being sent to customers!

            IMO the "from name" and "from address" should be two administratable fields within the "Customer notifications" page within JSM project settings. I don't see any reason why the from name should be the same as the portal name, and why the from address should be taken from the notification scheme. Changing things here as admin might have unknown side-effects to the mails without any reference to it!

            Atlassian, while fixing this bug, please also take into consideration to unify the process of where to administrate the outgoing mail settings (=from name, from address). Thanks!

            In the meantime, while this problem persists, I found a solution in a related ticket that explains on how to rewrite the from address/name/etc via postfix:
            https://jira.atlassian.com/browse/JSDSERVER-702?focusedCommentId=1007785&page=com.atlassian.jira.plugin.system.issuetabpanels%3Acomment-tabpanel#comment-1007785

            This works, but still I prefer to set these values within JSM directly and not come up with workarounds that require work in other pieces of software.

            Stephan Stahl added a comment - This is indeed an absolutely annoying problem. I banged my head to find out what's happening behind the scenes here (and to find this bug entry), and why sometimes the "From Name" is set to the Portal Name, but other times it's set to "E-Mail From" from the General Configuration Settings. According to documentation https://confluence.atlassian.com/jirakb/how-to-change-the-sender-s-name-of-the-service-management-notifications-933708029.html this should be set to the Portal Name - by default!. The next inconsistency is that the Customer Notifications' from address is exactly the same as the one used for the notification scheme (which is intended to be used for sending internal notifications). While the behavior for the from name seems to be a bug (as addressed here), it still is an absolute nightmare to administrate the way emails are being sent to customers! IMO the "from name" and "from address" should be two administratable fields within the "Customer notifications" page within JSM project settings. I don't see any reason why the from name should be the same as the portal name, and why the from address should be taken from the notification scheme. Changing things here as admin might have unknown side-effects to the mails without any reference to it! Atlassian, while fixing this bug, please also take into consideration to unify the process of where to administrate the outgoing mail settings (=from name, from address). Thanks! In the meantime, while this problem persists, I found a solution in a related ticket that explains on how to rewrite the from address/name/etc via postfix: https://jira.atlassian.com/browse/JSDSERVER-702?focusedCommentId=1007785&page=com.atlassian.jira.plugin.system.issuetabpanels%3Acomment-tabpanel#comment-1007785 This works, but still I prefer to set these values within JSM directly and not come up with workarounds that require work in other pieces of software.

            Jani Haiko added a comment -

            Any news on this? This is currently causing some confusion among our customers.

            Jani Haiko added a comment - Any news on this? This is currently causing some confusion among our customers.

              d905be0698b9 Thomas Bowes (Inactive)
              kwong2@atlassian.com KellyW (Inactive)
              Affected customers:
              10 This affects my team
              Watchers:
              18 Start watching this issue

                Created:
                Updated:
                Resolved: