What are mail loops
Mail loops are when an Email from JEMHC ends up back in a JEMHC mailbox. This is bad because it consumes your capacity plan 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 mail is ‘tagged’ with a header Precedence: bulk which by default JEMHC will block. This action stop the loop and prevents it from creating a comment/update that would trigger a further notification - such a case would be a runaway loop - JEMHC detects and blocks that. Yes, this still consumes a ‘msg’ from your Plan, but is an awful lot better than consuming ALL your plan. You can use JEMHC > Auditing > Inbound Messages to find these messages, scan the source issue to see where this comes from and fix.
Set Operation: Precedence Bulk on the Inbound Messages screen to filter to just that message type
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 address are, potentially, including them 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, 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 are not ignored by default as some customers use JEMHC Adhoc functionality to deliberately send mail to other mailboxes to create issues in other Projects. If you want to block senders, if done within JEMHC, the ‘mail’ would still be read, its more efficient for you to create a server side rule in incoming mailboxes to route/drop messages differently. 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 eg ‘alerts@blah.com’ is comprised of many users to ‘actually notify’ as well as JEMHC mailbox to ‘track’. In such cases, JEMHC will treat this address ‘as’ a user address or email only user address. Subsequent notifications to that address will resolve to the inbound mailbox. 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 capacity plan - its a consequence of your environment.
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 mailserver 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 DC version (JEMH). When this is available, we will have more custom capabilities on handling and processing mail recipients (tracked internally as JEMHC-2177)
Cloud mail service providers typically offer some way to lookup group addresses, as/when we are able to integrate with those services, we can dissolve the group into actual recipients, then pre-existing catchemail checks would be usable to block some delivery (tracked internally as JEMHC-2234)
Related to (2) in JEMH for DC had the capability to use Exchange to expand distribution group address via LDAP queries. With Atlassian ID and so on, we’re unsure whether this case is still needed, feedback through support, thanks!
Getting support
We are happy to help and will typically need an example email /issue screenshot to clarify how the loop occurs. Use JEMHC > Auditing > Incoming Messages to get and provide:
The incoming email via Export
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
