• Capability to pull mail into JIRAJira, 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 Mail Handler

• JIRA email handlers don't scale 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 Jira users (via standard JIRA 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 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 blacklist/whitelisting and JIRA 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 Jira specific values 'blocker' via JEMH Aliases.
• Customizable templates (Text, HTML, Subject) for all events. Ability to preview template edits (render the template) at edit time
• Customizable notifications for email users v.s. JIRA Jira account holders (enable different events)
• 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'
• In-line image support for a richer user experience), JEMH can in-line pasted images with wiki markup 'inline', both on the created issue and:
• Outbound notification supporting inline images, if an issue includes an inline notification, JEMH can mail that out
• Blacklisting of emails by subject out of the box, based on regexp.
• Blacklisting of all standard JIRA 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, allow JIRA 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 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.

Event Listener

The Event Listener can react to issue events as well as user events, and generate notifications for them.  Configuration of notifications can be done on a per-project basis, or globally.  Events can be enabled individually, and custom templates if created may be selected over the default JIRA Jira template. Its also possible to script mutation of the event, to 'decide' that because issues have certain properties, that a custom Issue Event needs to be fired (sending a different notification).