Email REJECTED due to Jira mail loop filter
Platform Notice: Cloud - This article applies to Atlassian products on the cloud platform.
Summary
Learn why emails may be rejected as "Sent from within the project" in your service project's mail.
Using email forwards
Instead of using the service project's default email handler, or directly connecting your custom mailbox to the project, you may choose to configure a rule on your mail provider to forward emails to your service project.
This may cause duplicate entries on your project's mail logs. Where one email is processed and others get rejected as "Sent from within the project." For example:
Why is the email forward causing this?
When using a forwarding rule, the headers from the NEW REQUEST email will be like this:
Delivered-To: project@domain.com
X-Forwarded-To: project@domain.com
X-Forwarded-For: forwarding.address@domain.com project@domain.com
Delivered-To: forwarding.address@domain.com
From: Reporter name <reporter@domain.com>
Date: Thu, 12 Jan 2023 13:32:34 -0300
Message-ID: <AAAAaa8BB5CccC=ddd1E+5fFFffff7Zggg0hHhH0II3JJ5KK6LL@mail.domain.com>
Subject: Test
To: forwarding.address@domain.com
The example headers above indicate:
- project@domain.com is the custom email address for the project.
- forwarding.address@domain.com is the email address where customers send requests. This address forwards emails to project@domain.com, which create requests.
Due to these headers, Jira will set the FROM (reporter@domain.com) as the Reporter of the request and the TO (forwarding.address@domain.com) will be added as a Request participant. As a Request participant, the forwarding email will receive notifications as any other customer, so when the agent changes the status or adds a comment, both the reporter and participant will be notified.
Any notification received by forwarding.address@domain.com as a participant will be sent again to project@domain.com which will process the email and it will be rejected as the FROM is jira@myinstance.atlassian.net (the email used to send out notifications in your project).
How to fix this?
Option 1
Connect the mailbox directly to the project, and don’t use a forwarding rule. Using the example above, if the requests are sent directly to project@domain.com, the problem won’t happen.
Option 2
The forwarding.address@domain.com is only added as a Request participant because it has an active account on your site. The project's mail handler and forward emails don't need to have accounts to create requests via mail handler.
To remove the loop, revoke access for the accounts created by these emails:
For portal-only accounts, see Revoke access for portal-only customers.
For Atlassian accounts, see Remove or suspend a user.