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.

Example Auditing output:

Open

Example Report from audit entry

Open

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’.

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

1. 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.

2. 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.

3. 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