• 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 Mail Handler

• JIRA email handlers don't scale, you will have problems with more than 50 or so inbound mail handlers (never mind the configuration). With 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 retains history of email received, and what happened, in case of failure, it is possible to exhume these emails and re-execute them against JEMH configuration Profiles until processing succeeds
• Round trip support for both JIRA users (via standard JIRA Notification schemes) as well as email users
• JEMH Profiles (configuration) include all inbound mail handling configuration. A Profile can be referred by one or many JEMH Mail Handlers (reducing complexity overall). 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)
  • JEMH has 'Directives' that are email supplied key/value pairs allowing issues to be manipulated (e.g. priority, custom fields, dueDate, workflow etc), during create, or comment, with blacklist/whitelisting and JIRA user group usage restrictions possible
  • 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, enabled regexp extraction of values from content, mapping to custom fields, but also, with such extracted values, its possible to translate these external values (eg priority 'must have' to internal 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 vs 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'
• Inline image support (a richer user experience), JEMH can inline 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 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 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 be mocked up, quickly, to valid configuration outcome, email content can be edited in situ. 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

Postfunctions

• 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 JEMH Event Listener can react to User Events as well as the usual Issue Events. Configuration can be added on a per-project basis, or globally, events can be enabled individually, and custom templates if created may be selected over the default 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).