• Capability to pull mail into Jira, creating and comment on issues, add attachments etc. It does that by specifying a (singular) target project. The relationship is one handler/project to one mailbox

• Ability to consume emails from unregistered users (but not the ability to include those users in updates to created issues)

• Ability to create users from their email address

• Depending on the 'choice' of mail handler different 'capabilities' can be gained, but they cannot be used together.

• HTML email has a basic conversion to wiki markup compatible output

Inbound

email

• Scalability - with large numbers of inbound mail handlers there are significant resource and maintenance overheads. Using JEMH, you can route many addresses from a common mailbox to many projects, effectively supporting n projects with n mailboxes with one mailbox connection (this is why JEMH was first written).

• Auditing - JEMH optionally retains history of emails received and what happened in case of failure.  Once the failure has been addressed, it is possible to re-process these emails

• Round trip support for both

• Jira users (via standard

• Jira Notification schemes) as well as email users

• JEMH configurations (Profiles) include all inbound mail handling configuration. A Profile can be referred by one or many JEMH Mail Handlers, reducing complexity. Profiles can be exported and imported, allowing environment migration, and supply for support purposes.

  • Project Mappings within Profiles allow mail to be routed to Projects based on Rules, Sender or

• • Jira mailbox Recipient, Keyword (body/subject) or sender user group. Each Mapping underlying Rule can be used to route mail and customize how they are created (change assignee, priority, labels etc)

  • Directives are commands that are email supplied key/value pairs allowing issues to be modified (e.g. priority, custom fields, workflow).  These can be applied during create or comment, with

• • Blocklist/

• • allowlisting and

• • Jira user group usage restrictions as needed

  • Field Processors are different 'interpreters' for email supplied content, most enable Directives supplied in a different way. The most versatile of these is the Regexp Field Processor which enables extraction of values from emails via Regular Expressions. Values are mapped to custom fields, but also, with such extracted values, its possible to translate these external values (e.g. priority 'must have' to internal

• • Jira specific values 'blocker' via JEMH Aliases

• • .

• Email compatibility, JEMH has extensive support for fixing defective emails. The world is full of mail sources generating 'broken' emails that are not possible to process with default handlers. JEMH can fix many structural issues 'on the fly'

• Full image support for a richer user experience

• , including image inlining

• Blocklisting of emails by subject out of the box, based on

• Regular Expressions.

• Blocklisting of all standard

• Jira images when attached, of image attachments based on size (e.g. <5K), of images specifically uploaded (signature image) based on their hash

• BETA: Status notifications,

• allowing Jira to notify email-only users of open/recently-closed issues.

• Auto creation of users, but, integrated with LDAP for user lookup and correct userID usage in

• Jira instead of just email address

• JEMH is designed for extensibility, key feature points are extendible making new implementations for customers specific requirements possible

• Test Cases are a feature of JEMH that allow simple email scenarios to help validate configuration.  Test email content can be edited on-the-fly. Exporting email content from auditing to Test Cases is common, and also allows problem emails to be provided for support

Ad-hoc notifications

• Ability for users to mail out template driven content to specified issue participants and email-only users, including selected issue attachments, feature can be secured to Roles on a per-project basis

Post Function notifications

• Ability to drive notifications from workflow, similar feature set to the Ad-hoc notification, but also including a JEMH Custom Field for transition-specific (notification with) selected attachments.

Outbound emails

Its powerful event-based notification system can react to issue

and user events

and generate notifications for them.

• Control which projects JEMH monitors, and what specific events it should create notifications for

• Separate Jira user notifications from non-Jira user notifications

• Custom notification templates can be made for all events if desired. You can preview custom template edits while editing them.

• Its also possible to change or ignore a received event based on a user defined script, allowing further control over notification behaviour