Uploaded image for project: 'Jira Platform Cloud'
  1. Jira Platform Cloud
  2. JRACLOUD-44107

To Be Able to Create Issues By JIRA Mail Handler Fingerprint

    • 12
    • Our product teams collect and evaluate feedback from a number of different sources. To learn more about how we use customer feedback in the planning process, check out our new feature policy.

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

      Problem Definition

      When JIRA receives a mail to create issue from another JIRA instance, having X-JIRA-FingerPrint prevents JIRA to create issue and throws the below error in the logs:

      Received message with another JIRA instance's fingerprint
      

      For more detailed information you can refer to:
      https://confluence.atlassian.com/display/JIRAKB/JIRA+Email+Finger+Print

      Suggested Solution

      To enable the administrator to have an option to be able to create issues. However, this might lead to loop issues.

      This feature is to avoid loop and loop detection so we do not recommend to enable it, unless we get Atlassian Development Team idea about it.

      Do note that Atlassian do not support customization as described on the documentation as outlined in our Atlassian Support Offerings. Please only try if you are confident on doing so and we strongly encourage customers to perform the check on test environment first before applying to production.

      Explanation By Customer(In the comments):

      The increasing number of JIRA instances, and how we'd like them to work together, raises an interesting use case for us:
      Desired Outcome
      What we'd like to do is create issues in our JIRA instance from another organisation's JIRA emails to us. We can't do that because our JIRA handler detects these emails as correctly belonging to another JIRA instance.
      Steps:
      Organisation A (OrgA) and Organisation B (OrgB) both have their own JIRA instances.
      OrgA sends support request email to OrgB
      OrgB JIRA mail handler detects email and creates issue (Issue Key ORGB-1)
      OrgB sends JIRA issue notification to OrgA
      OrgA JIRA mail handler detects email and create issue (Issue Key ORGA-1)
      OrgA JIRA local users / groups can use ORGA-1 to track issue progress with OrgB without needing access to OrgB JIRA.
      Actual Outcome
      Organisation A (OrgA) and Organisation B (OrgB) both have their own JIRA instances.
      Steps:
      OrgA sends support request email to OrgB
      OrgB JIRA mail handler detects email and creates issue (Issue Key ORGB-1)
      OrgB sends JIRA issue notification to OrgA
      OrgA JIRA mail handler detects email from OrgB and rejects it with the following error in the logs: "Received message with another JIRA instance's fingerprint"
      No issue is created in OrgA JIRA.
      This would be extremely useful because it allow users or user groups issue visibility and tracking with issues lodged with another organisation's JIRA.

            [JRACLOUD-44107] To Be Able to Create Issues By JIRA Mail Handler Fingerprint

            Atlassian Update - March 2024

            As I did not receive any responses to this comment I am closing this ticket.

            If you do not think this issue should have been closed, please add a comment here saying why and we can reopen it.

            Anusha Rutnam added a comment - Atlassian Update - March 2024 As I did not receive any responses to this comment I am closing this ticket. If you do not think this issue should have been closed, please add a comment here saying why and we can reopen it.

            Do the watchers of this ticket still experience this issue? I am not able to reproduce it and we have not had any recent reports. The confluence article referred to in the Description refers to Jira Server, not Cloud, so I'm wondering if this error still occurs. Thank you!

            Anusha Rutnam added a comment - Do the watchers of this ticket still experience this issue? I am not able to reproduce it and we have not had any recent reports. The confluence article referred to in the Description refers to Jira Server, not Cloud, so I'm wondering if this error still occurs. Thank you!

            Shanief added a comment - - edited

            It's rather bizarre that 6.5 years later, Jira still does not natively provide a way for two Jira instances to integrate - or at least ingest email from other Jira instances. This might simply be solved by allowing Jira admins to allowlist Jira instance fingerprints.

            Shanief added a comment - - edited It's rather bizarre that 6.5 years later, Jira still does not natively provide a way for two Jira instances to integrate - or at least ingest email from other Jira instances. This might simply be solved by allowing Jira admins to allowlist Jira instance fingerprints.

            Tim Rix added a comment -

            We just moved our web team's support process to Jira Service Desk from an ancient version of Request Tracker and found out about this unanticipated feature.  The web team uses a single support email address to receive product service alerts from outside vendors and user/staff reports of website issues.  The vendor alerts are for integrated services within the website umbrella that this team needs within a single ticketing application.  Because some of these outside vendors use Jira to manage their own email alerts to customers, necessary tickets for the web team are being blocked.

             

            The settings as they are prevent completely separate companies from using Jira or Jira Service Desk to communicate with each other.  This would work great if settings existed to only block X-JIRA-FingerPrint header emails from within an organization and allow emails between organizations.  

            Best,

            Tim

            Tim Rix added a comment - We just moved our web team's support process to Jira Service Desk from an ancient version of Request Tracker and found out about this unanticipated feature.  The web team uses a single support email address to receive product service alerts from outside vendors and user/staff reports of website issues.  The vendor alerts are for integrated services within the website umbrella that this team needs within a single ticketing application.  Because some of these outside vendors use Jira to manage their own email alerts to customers, necessary tickets for the web team are being blocked.   The settings as they are prevent completely separate companies from using Jira or Jira Service Desk to communicate with each other.  This would work great if settings existed to only block X-JIRA-FingerPrint header emails from within an organization and allow emails between organizations.   Best, Tim

            Thanks for creating this issue Sam.

            The increasing number of JIRA instances, and how we'd like them to work together, raises an interesting use case for us:

            Desired Outcome

            What we'd like to do is create issues in our JIRA instance from another organisation's JIRA emails to us. We can't do that because our JIRA handler detects these emails as correctly belonging to another JIRA instance.

            Steps:

            Organisation A (OrgA) and Organisation B (OrgB) both have their own JIRA instances.

            1. OrgA sends support request email to OrgB
            2. OrgB JIRA mail handler detects email and creates issue (Issue Key ORGB-1)
            3. OrgB sends JIRA issue notification to OrgA
            4. OrgA JIRA mail handler detects email and create issue (Issue Key ORGA-1)
            5. OrgA JIRA local users / groups can use ORGA-1 to track issue progress with OrgB without needing access to OrgB JIRA.

            Actual Outcome

            Organisation A (OrgA) and Organisation B (OrgB) both have their own JIRA instances.

            Steps:
            1. OrgA sends support request email to OrgB
            2. OrgB JIRA mail handler detects email and creates issue (Issue Key ORGB-1)
            3. OrgB sends JIRA issue notification to OrgA
            4. OrgA JIRA mail handler detects email from OrgB and rejects it with the following error in the logs: "Received message with another JIRA instance's fingerprint"
            5. No issue is created in OrgA JIRA.

            This would be extremely useful because it allow users or user groups issue visibility and tracking with issues lodged with another organisation's JIRA.

            Kind Regards,

            Tran

            ARDC Services added a comment - Thanks for creating this issue Sam. The increasing number of JIRA instances, and how we'd like them to work together, raises an interesting use case for us: Desired Outcome What we'd like to do is create issues in our JIRA instance from another organisation's JIRA emails to us. We can't do that because our JIRA handler detects these emails as correctly belonging to another JIRA instance. Steps: Organisation A (OrgA) and Organisation B (OrgB) both have their own JIRA instances. OrgA sends support request email to OrgB OrgB JIRA mail handler detects email and creates issue (Issue Key ORGB-1) OrgB sends JIRA issue notification to OrgA OrgA JIRA mail handler detects email and create issue (Issue Key ORGA-1) OrgA JIRA local users / groups can use ORGA-1 to track issue progress with OrgB without needing access to OrgB JIRA. Actual Outcome Organisation A (OrgA) and Organisation B (OrgB) both have their own JIRA instances. Steps: OrgA sends support request email to OrgB OrgB JIRA mail handler detects email and creates issue (Issue Key ORGB-1) OrgB sends JIRA issue notification to OrgA OrgA JIRA mail handler detects email from OrgB and rejects it with the following error in the logs: "Received message with another JIRA instance's fingerprint" No issue is created in OrgA JIRA. This would be extremely useful because it allow users or user groups issue visibility and tracking with issues lodged with another organisation's JIRA. Kind Regards, Tran

              Unassigned Unassigned
              somidi Sam Omidi (Inactive)
              Votes:
              12 Vote for this issue
              Watchers:
              13 Start watching this issue

                Created:
                Updated:
                Resolved: