Prevent Mail Loops
What are mail loops
Mail loops are when an email sent from JEMHC finds its way back into a JEMHC mailbox. This is undesirable as it consumes your Plan allowance for no useful outcome.
Consequences of mail loops
When a mail is read, and subsequently processed (even if discarded), it will consume message and data from your monthly capacity plan. JEMHC will do its best to stop run away loops but incremental attrition is typically a result of local configuration and environment, and is therefore not a ‘bug’ in JEMHC. It is in your interest to diagnose and limit such traffic.
Identifying mail from loops
All JEMHC notification email includes a Precedence: bulk header, which by default JEMHC will block on the way in. This prevents comment/updates that would trigger a further notification - such a case would be a runaway loop. This consumes a message from your Plan allowance. You can find these problem messages via JEMHC > Auditing > Inbound Messages, then view the source Jira issue to see where this comes from and fix.
Set Operation: Precedence Bulk on the Inbound Messages screen to filter to view messages where this header was detected and blocked
Example Auditing output:
Example Report from audit entry
Common prevention steps
Setup your Profile > JEMHC Catchemail addresses
Profile > Catch Email Addresses defines what your Mailbox addresses are, configuring this and maintaining it is needed to prevent JEMHC considering given catchemail’s as ‘user addresses’.
If you do not set you Catchemail addresses, JEMHC will not know what your mailbox addresses are. This can lead to them being included on an issue, or even creating users with that address, causing a mail loop.
Portal / Jira users with email address matching your mailbox
No User should have a mailbox address, it makes no sense. As a system admin, Scan your User Management > Users for your incoming mailboxes and change those users addresses so they do not resolve to mailbox address that feed JEMHC.
Automated Actions by JEMHC
Ignoring Recipient Addresses
Recipient addresses/expressions set in Profile > Catch Email Addresses are ignored by JEMHC and will not be used for user lookup or for Email only custom fields. Ensure all your Profiles contain catchemail addresses specific the to mailbox you have associated those profiles with.
Precedence Bulk
JEMHC will (by default) automatically block all Precedence: Bulk tagged mail. Each message still deducts from your Plan allowance, but runaway loops are prevented. Its on you to diagnose the source and prevent (see Support later).
Manual Actions by you
Mailbox filtering of sender
Sender addresses aren’t ignored by default as some customers use JEMHC Adhoc functionality to send mail to other mailboxes to create issues in other Projects. It’s possible to block sender addresses in JEMHC, however the email would still be read. It's more efficient to create a server-side rule on incoming mailboxes to filter out emails as needed. Configuration of your mail server for this is out of scope for support.
More complex loops
Group recipient addresses on incoming mail
Its common to see scenarios where a group email address e.g. ‘alerts@example.com’ is comprised of many users to notify as well as JEMHC mailbox for tracking purposes. In such cases, JEMHC may treat this address as a notification candidate. Subsequent notifications to that address will resolve to the inbound mailbox, causing a loop. This is not caused by JEMHC and is hard to detect. Typically JEMHC depends on Precedence: Bulk handling to block the processing of such mails, but will have to process the mail, so it still affects your monthly plan allowance.
Group sender addresses on incoming mail
In the same way, the sender of mail may be a ‘group’ address. If that user exists in Jira already, it would be set as the reporter and notified. Again, your mail server would expand that address and deliver, again, JEMHC will block based on Precedence: bulk, and again consume mail. This also is a consequence of your environment.
Future capabilities
We plan to develop scripting support, which is already in the self-hosted version of the app. When this is available, more custom handling and processing mail recipients will be possible.
Cloud mail service providers typically offer some way to lookup group addresses, as/when we are able to integrate with those services, we can derive recipients from the group. Then, pre-existing catchemail checks would be usable to prevent a loop.
Related to point 2, the self-hosted version of the app can use Exchange to expand distribution group address via LDAP. With Single Sign-On services such as Atlassian ID, we’re unsure whether this feature is still needed. You can let us know by giving feedback through our support channel.
Getting support
We are happy to help and will typically need an example email and/or issue screenshot to clarify how the loop occurs. Navigating to JEMHC > Auditing > Incoming Messages will allow you to provide us with:
The incoming email via Export. Note that currently only the most recent 100 messages are retained and exportable, so you have to be quick!
A screenshot of processing details via View Report