Stop email loops

1 Mail looping
2 Mitigation through CatchEmail / JemhAddressee Regexps
3 Automated systems
4 Blocklisting
- 4.1 Blocklisting by sender
- 4.2 Blocklisting by subject (Out of Office blocker)
5 Related articles

Mail looping

An example of a loop would be when a mail is sent by Jira to the mailbox which is also the inbound processing mailbox.

Ideally, getting incoming mail addresses correctly identified via Catch Email Addresses or Addressee Regexps will solve this problem from the start. In order to stop runaway loops (where a comment is added to a comment effectively doubling in size every loop) which would eventually cause memory errors, JEMH has a specific configuration section. See Profile > Issue > Loop Detection. Here, a limit can be set, both on the maximum number of comments that JEMH will 'comment' on, and a maximum comment size. These measures will stop runaway message loops (eventually). Mail processing is very memory intensive. An email with attachments of size 10MB can take 5 times that to process. If you are running close to memory limits this could be enough to push you over the edge, causing a 'failure' to process' resulting in a re-processing of the same message again (not a 'new' email loop, just a re-processing loop). Changing Java Garbage Collection strategy could help, but could also make things a lot worse, such changes are significant and must always be dry run on a test system:

Mitigation through CatchEmail / JemhAddressee Regexps

If an Email > Catch Email Address is defined, and/or a Email > JEMH Addressee Regexp, then JEMH will be able to discount addressees for notification purposes that match. If your Jira has one mailbox, use a single Catch Email, if you have several, add them as comma-separated values. If you have many, perhaps a regular expression would work better.

If you have the ability to define a mail subdomain for Jira usage, e.g. xxxx@jira.myco.net then this will be perfect as your users will not be in that namespace, and you can use a jemhAddresseeRegexp of .*@jira.myco.net instead.

If you do not define an incoming mail address, when non-Jira notifications are enabled, JEMH will have no way to determine which addressee was your incoming mail address.

Automated systems

When an automated system sends an email to Jira, it's possible that a notification from Jira will trigger a rebound notification. JEMH has configurable limits that stop runaway rebound message processing from producing an Issue that is too large. A large enough issue cannot be loaded in physical RAM due to its size, and could in extreme cases cause an OutOfMemoryError in Jira.

If comment counts reaches more than a given number, they are forwarded rather than added to the issue (that would trigger a comment notification), this doesn't stop other users adding comments, but ensures that email sourced traffic is stopped.
If comment size reaches more than a given number, the same happens.

Blocklisting

Blocklisting by sender

Many common 'bounce' emails are not going to be useful to Jira, for example, anything coming from your local Mail Server 'postmaster'. JEMH supports outright blocklisting of email domains (e.g. postmaster@.*) that can be dropped silently without creating issues. This configuration is done per-Profile.

Blocklisting by subject (Out of Office blocker)

When senders cannot be blocklisted, perhaps because they are valid Jira users, JEMH can filter emails based on subject, blocklisting and dropping matches, this is especially useful for those Out of Office notifications that even SPAM up the Atlassian servers from time to time...