Documentation for JIRA 6.3. Not using this? See below:
(JIRA 6.2.x documentation | JIRA Cloud documentation | earlier versions of JIRA)

Skip to end of metadata
Go to start of metadata

JIRA can be configured to automatically create issues or comments on existing issues based on incoming messages received by a mail server or external mail service.

This is especially useful in a helpdesk or support scenario, where users send support queries via email that you wish to track with JIRA. Subsequent email messages about the issue (for example, responses to Email Notifications) can be automatically recorded as comments. Additionally, any attachments in the emails can automatically be attached to the issue (with appropriate configuration).

Configuring issue or comment creation from email

Issues and comments in JIRA can be generated either from:

  • email messages sent to an account on a POP or IMAP mail server, or
  • messages written to the file system generated by an external mail service.

On this page:

Step one: Configure a mail server/service

POP or IMAP email messages

To set up issue and comment creation from email, you will need to create a mail account for a POP or IMAP mail server that JIRA can access – typically, one mail account for each JIRA project. For example, for the 'ABC' project, you might establish an account abc-issues@example.com

JIRA will periodically scan for new email messages received by your mail account (via a service) and appropriately create issues or comments for any emails it finds (via a mail handler).

JIRA's mail handlers can also optionally create new user accounts for senders not previously seen. See the Create a new issue or add a comment to an existing issue section for more details.

(warning) Note that this is not possible if you are using External User Management.

Once you have created a mail account on a POP or IMAP mail server, configure JIRA to receive email from that mail server account.

File system messages

To set up issue and comment creation from messages written to the file system by an external mail service, your external mail service must be able to write these messages within the import/mail subdirectory of the JIRA Home Directory.

External mail services are very much like the POP or IMAP services above, except that instead of email messages being read from a mail account, they are read from a directory on the disk. External mail services are useful because they overcome the potential security risks associated with anonymous mail accounts. Instead you can simply configure your external mail service to dump incoming email messages within the JIRA Home Directory's import/mail subdirectory, which is scanned periodically.

Please also be aware that JIRA expects only one message per file, so your external mail service should be configured to generate such output.

(info) Note — how JIRA handles messages on a mail server/service:

  • For mail accounts, JIRA scans email messages received by your mail account's 'Inbox' folder. However, for IMAP mail servers, you can specify a different folder within your mail account.
  • If JIRA successfully processes a message, JIRA deletes the message from your mail account (on a POP or IMAP mail server) or file system (i.e. for file system messages).
  • If JIRA does not successfully process a message, the message will remain either in your mail account or on the file system.

Step two: Configure a mail handler

Once you have configured JIRA to receive messages from a mail server/service, you configure JIRA to handle these messages through a 'mail handler'.

To configure a JIRA mail handler:

  1. Log in as a user with the JIRA Administrators  global permission.
  2. Choose > System. Select Mail > Incoming Mail to open the Incoming Mail page.
    (tick) Keyboard shortcut: g + g + start typing incoming mail
  3. Click the Add incoming mail handler button (or the Edit link next to an existing mail handler) in the Mail Handlers section to open the Mail Handler dialog box.
  4. Specify a Name that describes what your mail handler will do — for example, 'Create issues or comments from Example Company's IMAP mail server'.
  5. Select the mail Server that you configured in step one (above). This is either a POP or IMAP mail server or the Local Files option for an external mail service that writes messages to the file system.
  6. Specify the Delay (in minutes) between the mail handler's running time. This effectively defines the frequency with which JIRA scans the Server that you specified in the previous step.
  7. Choose the type of mail Handler from dropdown list. For more information, refer to the Mail Handlers section below.
  8. If you chose either an IMAP mail server or the Local Files option in the Server field, then a Folder Name field appears below the Handler  dropdown list:
    • For an IMAP mail server, if you want mail handler to scan for new messages from a folder other than the 'Inbox' in your mail account, specify the name of that folder here.
    • For the Local Files option, if your file messages are being written to a subdirectory within the import/mail subdirectory of the JIRA Home Directory, specify the subdirectory structure (within import/mail) here.
  9. Click Next to continue with specifying the remaining options specific to mail Handler you selected above. For more information, refer to the Mail Handlers section below.
  10. (Optional) Click the Test button to test your mail handler. If you are using Local Files as the server, copy a saved email that contains a "Subject: " line to the configured directory. JIRA will remove this file after it is parsed, or log a message about why an issue could not be created. You may have to specify the project, issuetype and reporterusername properties as a minimum configuration.
    A sample email file might look like this:
    To: jira@example.com
    From: some-jira-user@example.com
    Subject: (TEST-123) issue summary title here
    Body of the email goes here 
  11. Click the Add / Save button to save your mail handler.

(info) Note — the relationship between JIRA mail handlers and services:

  • A JIRA mail handler is part of a JIRA service. Hence, when you create a mail handler, its service will appear as an entry on the Services page.
  • Be aware that editing mail handlers can only be performed through the Mail Handlers page (described above).
  • On the Mail Handlers page, clicking the Delete link associated with a mail handler removes that handler. Since a mail handler is part of a service, then if you delete a mail handler's service on the Services page, its associated handler will also be removed from the Mail Handlers page.

Mail handlers

 JIRA provides the following default mail handlers:

For more information about how these mail handlers create issues and comments in JIRA, refer to Issue/comment creation (below).

Also refer to the Handy tips with mail handlers (below) for tips on tweaking mail handlers to allow JIRA to handle the following types of email messages:

  • Email sent from people without a JIRA user account.

Create a new issue or add a comment to an existing issue

This message handler creates a new issue, or adds a comment to an existing issue. If the subject contains an issue key, the message is added as a comment to that issue. If no issue key is found, a new issue is created in the default project.

To configure a 'Create a new issue or add a comment to an existing issue' mail handler:

  1. If you have not already done so, begin configuring your mail handler (above).
  2. On the Create a new issue or add a comment to an existing issue dialog box, complete the following fields/options:

    Project

    Specify the project key of the default project to which new issues are created by this handler — for example, JRA.

    (info) Note:

    • This field is only relevant for issue creation, not for issue commenting.
    • If an email message contains an issue key in its subject line and that issue key exists in your JIRA installation, the handler will add the email message content as a comment on the issue, regardless of which project the issue is in.
    Issue TypeChoose the default issue type for new issues.
    Strip QuotesSelect this check box to remove quoted text from from an email message's body (e.g. from previous email replies) before the body's content is added to the JIRA issue's comment.
    Catch Email Address

    If specified, only email messages whose To:, Cc:, Bcc: lines contain the recipient specified in this field will be processed — for example, issues@mycompany.com

    Upon specifying an address here, all email messages whose To:, Cc:, Bcc: lines contain addresses other than the Catch Email Address are ignored. This is useful if you have multiple aliases for the same mail account (e.g. foo-support@example-co.com and bar-support@example-co.com aliases for support@example-co.com) for multiple mail services (e.g. each one to create issues in separate JIRA projects).

    (info) Note: in practice, this option is rarely useful and should not be confused with the more common Default Reporter. You can only specify one catch email address and one issue type per mail handler.

    Bulk

    This option only affects 'bulk' email messages whose header has either its Precedence: field set to bulk or its Auto-Submitted field set to no. Such messages would typically be sent by an automated service. When such an email message is received, the following action will be performed, based on the option you choose:

    1. Ignore the email and do nothing.
    2. Forward the email (i.e. to the address set in the Forward Email text field).
    3. Delete the email permanently.

    It is generally a good idea to set bulk=forward and set a Forward Email address, to prevent mail loops between JIRA and another automated service (eg. another JIRA installation).

    Forward Email

    If specified, then if this mail service is unable to handle an email message it receives, an email message indicating this problem will be forwarded to the email address specified in this field.

    (info) Note: An SMTP mail server must be configured for this option to function correctly.
    Create Users

    Select this check box if you want JIRA to create new user accounts from any received email messages whose From: field contains an address that does not match one associated with an existing JIRA user account. This allows the creator of the email message to be notified of subsequent updates to the issue, which can be achieved by configuring the relevant project's notification scheme to notify the Reporter of updates.

    The username and email address of these newly created JIRA user accounts will be the email addresses specified in the From: fields of these received messages. The password for these new JIRA users is randomly generated and an email message is sent their addresses informing them about their new JIRA user account.

    Users created this way will be added to the 'jira-users' group and given application access to JIRA (and therefore take up a license).

    (info) Note: this option is not compatible with Default Reporter field option below and as such, choosing the Create Users option will hide the Default Reporter option.

    Default Reporter

    Specify the username of a default reporter, which will be used if the email address in the From: field of any received messages does not match the address associated with that of an existing JIRA user — for example, a JIRA username such as emailed-reporter

    (info) Note:

    • This option is not available if the Create Users check box is selected.
    • Please ensure that the user specified in this field has the Create I ssues  project permission for the relevant Project (specified above) as well as the Create Comments   project permission for the other relevant projects to which this mail handler should add comments.
    • When an issue is created and this option is specified, the email message's From: field address is appended in a brief message at the end of the issue's Description field, so that the sender can be identified.
    Notify Users

    Clear this check box if you do not want JIRA to send out an email message notifying users whose accounts have been created by the Create Users option above.

    (info) Note: this option only functions if the Create Users check box has been selected.

    CC Assignee

    Select this check box if you want JIRA to automatically assign the issue created to a JIRA user:

    • Who's email address (registered with their JIRA account) matches the first matching address encountered in the To:, then Cc: and then Bcc: field of the email message received.
    • Who also has the Assignable User project permission for the relevant Project (specified above).
    CC Watchers

    Select this check box if you want JIRA to automatically add JIRA users to the issue created, where those users' email addresses (registered with their JIRA accounts) match addresses encountered in the To:, Cc: or Bcc: fields of the email message received.

    (info) Please note that when an issue is created, new JIRA users created by the Create Users option (above) cannot also be added to the issue's watchers list by this CC Watchers option. JIRA users must already exist in JIRA's userbase, and must have an email address.

  3. Test and save your mail handler (above).

Add a comment from the non quoted email body

This message handler creates a comment, but only uses the 'non quoted' lines of the body of the email message. A quoted line is any line that starts with a '>' or '|' symbol and such lines of text will not be added to the comment. The issue to which the comment is added is chosen from the first issue key found in the email subject. The author of the comment is taken from the address of the email message's From: field.

To configure an 'Add a comment from the non quoted email body' mail handler:

  1. If you have not already done so, begin configuring your mail handler (above).
  2. On the Add a comment from the non quoted email body dialog box, complete the following fields/options:

    Catch Email AddressIf specified, only email messages whose To:, Cc:, Bcc: lines contain the recipient specified in this field will be processed — for example, issues@mycompany.com

    Upon specifying an address here, all email messages whose To:, Cc:, Bcc: lines contain addresses other than the Catch Email Address are ignored. This is useful if you have multiple aliases for the same mail account (e.g. foo-support@example-co.com and bar-support@example-co.com aliases for support@example-co.com) for multiple mail services (e.g. each one to create issues in separate JIRA projects).

    (info) Note: in practice, this option is rarely useful and should not be confused with the more common Default Reporter. You can only specify one catch email address and one issue type per mail handler.

    Bulk

    This option only affects 'bulk' email messages whose header has either its Precedence: field set to bulk or its Auto-Submitted field set to no. Such messages would typically be sent by an automated service. When such an email message is received, the following action will be performed, based on the option you choose:

    1. Ignore the email and do nothing.
    2. Forward the email (i.e. to the address set in the Forward Email text field).
    3. Delete the email permanently.
    Forward Email

    If specified, then if this mail service is unable to handle an email message it receives, an email message indicating this problem will be forwarded to the email address specified in this field.

    (info) Note: An SMTP mail server must be configured for this option to function correctly.
    Create Users

    Select this check box if you want JIRA to create new user accounts from any received email messages whose From: field contains an address that does not match one associated with an existing JIRA user account. This allows the creator of the email message to be notified of subsequent updates to the issue, which can be achieved by configuring the relevant project's notification scheme to notify the Reporter of updates.

    The username and email address of these newly created JIRA user accounts will be the email address specified in the From: field of the message. The password for the new user is randomly generated, and an email is sent to the new user informing them about their new account in JIRA.

    Users created this way will be added to the 'jira-users' group and given application access to JIRA (and therefore take up a license).

    (info) Note: this option is not compatible with Default Reporter field option below and as such, choosing the Create Users option will hide the Default Reporter option.

    Default Reporter

    Specify the username of a default reporter, which will be used if the email address in the From: field of any received messages does not match the address associated with that of an existing JIRA user — for example, a JIRA username such as emailed-reporter

    (info) Note:

    • This option is not available if the Create Users check box is selected.
    • Please ensure that the user specified in this field has the Create Issues project permission for the relevant Project (specified above) as well as the Create Comments project permission for the other relevant projects to which this mail handler should add comments.
    Notify Users

    Clear this check box if you do not want JIRA to send out an email message notifying users whose accounts have been created by the Create Users option above.

    (info) Note: this option only functions if the Create Users check box has been selected.

  3. Test and save your mail handler (above).

Add a comment with the entire email body

This message handler creates a comment based on the entire body of the email message received. The issue to which the comment is added is chosen from the first issue key found in the email subject. The author of the comment is taken from the address of the email message's From: field.

To configure an 'Add a comment with the email body' mail handler:

  1. If you have not already done so, begin configuring your mail handler (above).
  2. On the Add a comment with the entire email body dialog box, complete the following fields/options:

    Catch Email AddressIf specified, only email messages whose To:, Cc:, Bcc: lines contain the recipient specified in this field will be processed — for example, issues@mycompany.com

    Upon specifying an address here, all email messages whose To:, Cc:, Bcc: lines contain addresses other than the Catch Email Address are ignored. This is useful if you have multiple aliases for the same mail account (e.g. foo-support@example-co.com and bar-support@example-co.com aliases for support@example-co.com) for multiple mail services (e.g. each one to create issues in separate JIRA projects).

    (info) Note: in practice, this option is rarely useful and should not be confused with the more common Default Reporter. You can only specify one catch email address and one issue type per mail handler.

    Bulk

    This option only affects 'bulk' email messages whose header has either its Precedence: field set to bulk or its Auto-Submitted field set to no. Such messages would typically be sent by an automated service. When such an email message is received, the following action will be performed, based on the option you choose:

    1. Ignore the email and do nothing.
    2. Forward the email (i.e. to the address set in the Forward Email text field).
    3. Delete the email permanently.
    Forward Email

    If specified, then if this mail service is unable to handle an email message it receives, an email message indicating this problem will be forwarded to the email address specified in this field.

     

    (info) Note: An SMTP mail server must be configured for this option to function correctly.
    Create Users

    Select this check box if you want JIRA to create new user accounts from any received email messages whose From: field contains an address that does not match one associated with an existing JIRA user account. This allows the creator of the email message to be notified of subsequent updates to the issue, which can be achieved by configuring the relevant project's notification scheme to notify the Reporter of updates.

    The username and email address of these newly created JIRA user accounts will be the email address specified in the From: field of the message. The password for the new user is randomly generated, and an email is sent to the new user informing them about their new account in JIRA.

    Users created this way will be added to the 'jira-users' group and given application access to JIRA (and therefore take up a license).

    (info) Note: this option is not compatible with Default Reporter field option below and as such, choosing the Create Users option will hide the Default Reporter option.

    Default Reporter

    Specify the username of a default reporter, which will be used if the email address in the From: field of any received messages does not match the address associated with that of an existing JIRA user — for example, a JIRA username such as emailed-reporter

    (info) Note:

    • This option is not available if the Create Users check box is selected.
    • Please ensure that the user specified in this field has the Create Issues project permission for the relevant Project (specified above) as well as the Create Comments project permission for the other relevant projects to which this mail handler should add comments.
    Notify Users

    Clear this check box if you do not want JIRA to send out an email message notifying users whose accounts have been created by the Create Users option above.

    (info) Note: this option only functions if the Create Users check box has been selected.

  3. Test and save your mail handler (above).

Create a new issue from each email message

This message handler creates a new issue for each incoming message.

To configure an 'Create a new issue from each email message' mail handler:

  1. If you have not already done so, begin configuring your mail handler (above).
  2. On the Create a new issue from each email message dialog box, complete the following fields/options:

    Project

    Specify the project key of the default project to which new issues are created by this handler — for example, JRA.

    (info) Note:

    • This field is only relevant for issue creation, not for issue commenting.
    • If an email message contains an issue key in its subject line and that issue key exists in your JIRA installation, the handler will add the email message content as a comment on the issue, regardless of which project the issue is in.
    Issue TypeChoose the default issue type for new issues.
    Catch Email Address

    If specified, only email messages whose To:, Cc:, Bcc: lines contain the recipient specified in this field will be processed — for example, issues@mycompany.com

    Upon specifying an address here, all email messages whose To:, Cc:, Bcc: lines contain addresses other than the Catch Email Address are ignored. This is useful if you have multiple aliases for the same mail account (e.g. foo-support@example-co.com and bar-support@example-co.com aliases for support@example-co.com) for multiple mail services (e.g. each one to create issues in separate JIRA projects).

    (info) Note: in practice, this option is rarely useful and should not be confused with the more common Default Reporter. You can only specify one catch email address and one issue type per mail handler.

    Bulk

    This option only affects 'bulk' email messages whose header has either its Precedence: field set to bulk or its Auto-Submitted field set to no. Such messages would typically be sent by an automated service. When such an email message is received, the following action will be performed, based on the option you choose:

    1. Ignore the email and do nothing.
    2. Forward the email (i.e. to the address set in the Forward Email text field).
    3. Delete the email permanently.
    Forward Email

    If specified, then if this mail service is unable to handle an email message it receives, an email message indicating this problem will be forwarded to the email address specified in this field.

     

    (info) Note: An SMTP mail server must be configured for this option to function correctly.
    Create Users

    Select this check box if you want JIRA to create new user accounts from any received email messages whose From: field contains an address that does not match one associated with an existing JIRA user account. This allows the creator of the email message to be notified of subsequent updates to the issue, which can be achieved by configuring the relevant project's notification scheme to notify the Reporter of updates.

    The username and email address of these newly created JIRA user accounts will be the email address specified in the From: field of the message. The password for the new user is randomly generated, and an email is sent to the new user informing them about their new account in JIRA.

    Users created this way will be added to the 'jira-users' group and given application access to JIRA (and therefore take up a license).

    (info) Note: this option is not compatible with Default Reporter field option below and as such, choosing the Create Users option will hide the Default Reporter option.

    Default Reporter

    Specify the username of a default reporter, which will be used if the email address in the From: field of any received messages does not match the address associated with that of an existing JIRA user — for example, a JIRA username such as emailed-reporter

    (info) Note:

    • This option is not available if the Create Users check box is selected.
    • Please ensure that the user specified in this field has the Create Issues project permission for the relevant Project (specified above) as well as the Create Comments project permission for the other relevant projects to which this mail handler should add comments.
    • When an issue is created and this option is specified, the email message's From: field address is appended in a brief message at the end of the issue's Description field, so that the sender can be identified.
    Notify Users

    Clear this check box if you do not want JIRA to send out an email message notifying users whose accounts have been created by the Create Users option above.

    (info) Note: this option only functions if the Create Users check box has been selected.

    CC Assignee

    Select this check box if you want JIRA to automatically assign the issue created to a JIRA user:

    • Who's email address (registered with their JIRA account) matches the first matching address encountered in the  To: , then Cc: and then Bcc: field of the email message received.
    • Who also has the Assignable User project permission for the relevant Project (specified above).
    CC Watchers

    Select this check box if you want JIRA to automatically add JIRA users to the issue created, where those users' email addresses (registered with their JIRA accounts) match addresses encountered in the To:, Cc: or Bcc: fields of the email message received.

    (info) Please note that when an issue is created, new JIRA users created by the Create Users option (above) cannot also be added to the issue's watchers list by this CC Watchers option. JIRA users must already exist in JIRA's userbase, and must have an email address.

  3. Test and save your mail handler (above).

Add a comment before a specified marker or separator in the email body

This message handler creates a comment from the body of an email message - but ignores any part of the body past a marker or separator that matches a specified regular expression (regex).

For mail systems like Lotus Notes and Outlook, the core content of an email message is separated from other (e.g. replied or forwarded) content in the body by some predictable text string like '---- Original Message ----' or 'Extranet\n email.address/DOM/REG/CONT/CORP@CORPMAIL'. Hence, use this message handler, which can take any valid regex, to filter core from extraneous content from various different mail systems.

Also note that the issue to which the comment is added is chosen from the first issue key found in the email subject.

The Add a comment before a specified marker or separator in the email body mail handler has the following behavior with respect to received email messages:

  • If the regex pattern (specified in the mail handler) is found, the text in the email message body before the first regex pattern match is used for the comment and the remainder of the body is discarded.
  • If the regex pattern (specified in the mail handler) is not found, the entire text in the email message body is used for the comment.
  • If no regex pattern is specified in the mail handler, the entire text in the email message body is used for the comment.
  • If the regex expression specified in the mail handler is erroneous, the entire text in the email message body is used for the comment.

To configure an 'Add a comment before a specified marker or separator in the email body' mail handler:

  1. If you have not already done so, begin configuring your mail handler (above).
  2. On the Add a comment before a specified marker or separator in the email body dialog box, complete the following fields/options:

    Split Regex

    Specify a regular expression matching the text that separates the content of the email message mail body from other (replied or forwarded) content in the body.

    (info) Please Note:

    • The regex must begin and end with a delimiter character, typically '/'.
    • Commas are not allowed in a regex, as they are used to separate each mail handler field/option when they are integrated into a JIRA service and there is not (as yet) an escape syntax.

    For example:

    /----\s*Original Message\s*----/

    or

    /_____________*/
    Catch Email AddressIf specified, only email messages whose To:, Cc:, Bcc: lines contain the recipient specified in this field will be processed — for example, issues@mycompany.com

    Upon specifying an address here, all email messages whose To:, Cc:, Bcc: lines contain addresses other than the Catch Email Address are ignored. This is useful if you have multiple aliases for the same mail account (e.g. foo-support@example-co.com and bar-support@example-co.com aliases for support@example-co.com ) for multiple mail services (e.g. each one to create issues in separate JIRA projects).

    (info) Note: In practice, this option is rarely useful and should not be confused with the more common Default Reporter. You can only specify one catch email address and one issue type per mail handler.

    Bulk

    This option only affects 'bulk' email messages whose header has either its Precedence: field set to bulk or its Auto-Submitted field set to no. Such messages would typically be sent by an automated service. When such an email message is received, the following action will be performed, based on the option you choose:

    1. Ignore the email and do nothing.
    2. Forward the email (i.e. to the address set in the Forward Email text field).
    3. Delete the email permanently.
    Forward Email

    If specified, then if this mail service is unable to handle an email message it receives, an email message indicating this problem will be forwarded to the email address specified in this field.

    (info) Note: An SMTP mail server must be configured for this option to function correctly.
    Create Users

    Select this check box if you want JIRA to create new user accounts from any received email messages whose From: field contains an address that does not match one associated with an existing JIRA user account. This allows the creator of the email message to be notified of subsequent updates to the issue, which can be achieved by configuring the relevant project's notification scheme to notify the Reporter of updates.

    The username and email address of these newly created JIRA user accounts will be the email address specified in the From: field of the message. The password for the new user is randomly generated, and an email is sent to the new user informing them about their new account in JIRA.

    Users created this way will be added to the 'jira-users' group and given application access to JIRA (and therefore take up a license).

    (info) Note: this option is not compatible with Default Reporter field option below and as such, choosing the Create Users option will hide the Default Reporter option.

    Default Reporter

    Specify the username of a default reporter, which will be used if the email address in the From: field of any received messages does not match the address associated with that of an existing JIRA user — for example, a JIRA username such as emailed-reporter

    (info) Note:

    • This option is not available if the Create Users check box is selected.
    • Please ensure that the user specified in this field has the Create Issues project permission for the relevant Project (specified above) as well as the Create Comments   project permission for the other relevant projects to which this mail handler should add comments.
    Notify Users

    Clear this check box if you do not want JIRA to send out an email message notifying users whose accounts have been created by the Create Users option above.

    (info) Note: this option only functions if the Create Users check box has been selected.

  3. Test and save your mail handler (above).

 

Custom mail handlers

You can design your own message handlers to better integrate your own processes into JIRA. Such custom mail handlers configured using the standard procedure above.

For more information about creating custom mail handlers, see Adding your own email handling classes.

Issue/comment creation

The following points describe how JIRA processes each incoming email message and determines how its content gets added as either a comment to an existing issue or a new issue altogether.

  • The subject  of an email message is examined for an existing issue key:
    • If an issue key is found in the subject, the content of the email message's body is processed and added as a comment to the issue with that issue key.
    • If an issue key is NOT found in the subject, the in-reply-to header  is examined:
      • If the email message is found to be a reply to another email message from which an issue was previously created, the body is processed and added as a comment to that issue.
      • If the email message is NOT found to be a reply, a new issue is created.

For example, an email message to a mail account foo@example-co.com on a POP or IMAP mail server configured against a JIRA server will be processed as follows:

  • Issue Creation:
    • The subject of the email message will become the issue summary.
      (warning) Since all issues require a summary, each email message intended for issue creation should include a subject.
    • The body of the email message will be the issue description.
    • A bug will be created for project 'JRA' with the above information. (This is essentially based on the mail handler configuration above).
    • Any attachments to the email message will become attachments to the issue (assuming attachments have been enabled in JIRA).
      (info) To ensure compatibility with various operating systems, any of the following characters in the filename will be replaced with an underscore character: \, /, ", %, :, $, ?, *, <, |, >.
    • If the incoming email is set to a high priority, the corresponding issue will be created with a higher priority than the default priority that is set in your JIRA system.
  • Comment Creation:
    • The body of the email will become a comment on the issue.
    • Any attachments to the email will become attachments to the issue (assuming attachments  have been enabled in JIRA).

Handy tips with mail handlers

To allow JIRA to handle email messages sent from people without a JIRA user account:

  1. Create an 'anonymous'/'dummy' mail account on your mail server/service (above).
  2. Create an equivalent 'anonymous'/'dummy' JIRA user account, whose Email field matches the mail account you created in the previous step.
  3. When configuring your mail handler(s) (above) to handle messages from this mail account, set the Default Reporter to this 'anonymous'/'dummy' JIRA user account.

Best practices (pre-processing JIRA email messages)

For JIRA production servers, we recommend that setting up the following email message pre-processing:

  • Since JIRA mail handlers remove successfully processed email messages from your mail server, ensure that your mail is sent to a backup folder so that a record of what mail JIRA processed is available.
  • If your mail folder contains replies to JIRA's email notifications, set up rules that filter out auto-replies and bounces.
    If you do not do this, there is a strong possibility of mail loops between JIRA and autoresponders like 'out of office' notifications. JIRA sets a 'Precedence:bulk' header (unless you have disabled this) and an 'Auto-Submitted' header on outgoing email, but some autoresponders ignore it.
    There is no bulletproof way of detecting whether an email is a bounce or autoreply. The following rules (in procmail format) will detect most autoreplies:

    Even with these rules, you may encounter autoreplies with nothing in the headers to distinguish it from a regular mail, In these cases you will just need to manually update the filters to exclude that sender.

  • Set up a filter to catch email with huge attachments. JIRA uses the standard JavaMail library to parse email, and it quickly runs out of memory on large attachments (e.g. > 50 MB given 512 MB heap). As the un-handled mail is not deleted, it will be reprocessed (causing another OutOfMemoryError) each time the mail service runs.
    In practice this problem is rarely seen, because most mail servers are configured to not accept email with huge attachments. Unless you are sure your mail server will not pass a huge attachment on to JIRA, it is best to configure a filter to prevent JIRA encountering any huge attachments.
  • Set up spam filtering rules, so JIRA does not have to process (and possibly create issues from) spam.

Troubleshooting

 JIRA's Logging & Profiling page has configuration options for Outgoing and Incoming mail.

 

Whenever you create a new (or edit an existing) mail handler (above), a Test button is available to allow you to test your mail handler's configuration to ensure it works as expected.

 

A useful tip for debugging mail-related problems in JIRA is to set the -Dmail.debug=true property on startup. This will cause protocol-level details of JIRA's email interactions to be logged in catalina.out (or standard output). If you cannot resolve a problem yourself, please refer to the Getting Help page.

Common problems

  • If JIRA does not appear to be creating sending emails or creating issues and comments from email, your JIRA instance could be experiencing OutOfMemory errors. Please check your log files for OutOfMemory errors. If there are OutOfMemory errors, please restart JIRA and investigate the errors.
  • If you find some incoming emails simply disappear, check that you have not accidentally started a second copy of JIRA (e.g. in a staging environment) which is downloading and deleting mails. See the Disable email sending/receiving section of the Restoring Data page for flags you should set to prevent mail being processed.
  • If replies by email of JIRA's notifications list JIRA's SMTP server rather than the configured handler POP account (ie, in Outlooks' 'Reply-to' functionality), the project needs to be configured to add a 'reply-to' header in outgoing notifications. This can be configured in the project view for that particular project in JIRA's Administration.
  • If HTML/Rich Text formatting is not being process correctly by JIRA, this is an expected behavior. The email comment handler was designed to do plain text conversion.

 

 

112 Comments

  1. Does anyone know why, when I add the service, it does not give me any errors despite apparently not processing the emails?

    When I put in an invalid port number, I can see a "Connection Refused" error message in the data directory /log/atlassian-jira.log file.

    However, when I use the correct port, I do not see anything about any errors. Any ideas on what I can do to get this working?

    Thanks!

  2. Anonymous

    "Issue/Comment Creation" should assign issue as well - to person reporting it, or (preferably configurable) alternatively to single person (eg. manager).

  3. I had a similar problem, got fixed after I defined the Handler Parameters properly:

    E.g. Handler Parameters: "project=EKRI, issuetype=1, catchemail=ekrwiki@direction.biz, bulk=forward"

    Create your handler parameter as above, the meanings of the handler parameters are explained on the page above, for project use Project Key and NOT Project Name.

  4. Anonymous

    How would you make this work that the email issue could be added to multiple projects? This would require for example having the project key name in the subject line of the email.

  5. Anonymous

    Can I do that steps (1-12) via SOAP or Jelly script?

  6. Sys

    After upgrading to 4.3 this service started to fail. There are new parameter added "Protocol" (which is not mentioned here) which allows to choose between IMAP and POP. I understand IMAP was the default and only option until now, so if choose it and test connections it shows:

    Unfortunately no connection was possible. Review the errors below and rectify:

    ConnectionException: +OK The Microsoft Exchange POP3 service is ready.

    If I choose POP and test connections it reports connection successful. However either setting doesn't work and report following error in a log:

    Error connecting to host 'server name' as user 'user name' via protocol 'imap': javax.mail.AuthenticationFailedException: AUTHENTICATE failed.

  7. Anonymous

    After the upgrade, we are having the problem that E-mail replies are working fine and being added as comments and E-mail notifications are being sent out to watchers, etc.  If there is an attachment included with the E-mail (even a rather small one, under 100k) no E-mail notification is going out at all.  The comment gets added and the attachment is added also but no E-mail notification of activity to anyone.

    Is anyone else seeing this?

  8. Anonymous

    Is there anyway to use a regex on the subject of an email itself?

  9. Anonymous

    Hi,
    I am trying to setup "create issue handlers" using one email account with multiple distribution lists for different projects.
    I already have one email inbox account working with one project. But for security purposes, I'd like to have one email account created and distribution lists to be tied up to that email account.
    Let's say I have Project X and Project Y. I will have one email account jira@foo.com (actual email account) and 2 distribution lists (issue@foo.com and ticket@foo.com) tied up to jira@foo.com email inbox.
    Can I setup handlers for each project using distribution lists and a single email inbox?
    Thanks in advance,
    Mehmet
    Hi,

    I am trying to setup "create issue handlers" using one email account with multiple distribution lists for different projects.

    I already have one email inbox account working with one project. But for security purposes, I'd like to have one email account created and distribution lists to be tied up to that email account.

    Let's say I have Project X and Project Y. I will have one email account jira@foo.com (actual email account) and 2 distribution lists (issue@foo.com and ticket@foo.com) tied up to jira@foo.com email inbox.

    Can I setup handlers for each project using distribution lists and a single email inbox?

    Thanks in advance.

  10. Anonymous

    • So I have the email account, and verified I can send emails to it and am able to read emails within that account's box.  The mail side of things is working!
    • I have the email server setup in JIRA and the Test Connection works (and fails if I muck it up).  So Jira can SEE the POP3 Mail Server (MS Exchange)
    • I have the Email Comment Service setup in JIRA to reach out to the mail server (and JIRA's machine can successfully ping that address and port)
    • I have the handler.params correctly referencing the KEY of the project with comma-delimited settings:
      • project=XXX, issuetype=3, createusers=false, bulk=forward
    • I send an email to the box with the name of an issue in the subject:
      •  XXX-4 - Email test

    Nothing happens.  The emails are in the box.  I can read them with Thunderbird.  I now have about 10 emails in the box, none of them are being processed by JIRA.  I tried with SSL on and off.  I tried with a blank (default) port, and explicit port setting.  Again, nothing.

    How do you get JIRA to actually go get the emails??

    joseph.morgan@ignitesales.com

    1. Anonymous

      The email account that you're sending the emails from belongs to a valid JIRA user?

      I believe that in order for them to be picked up, the "from" email has to belong to a JIRA user that can add issues to that particular project.  Hope that helps!

  11. Anonymous

    I would like to default each inbound email to a specific JIRA User rather than the recipient in the "TO" field of the email.

    I feel as if I'm missing something straightforward (smile)  Is there a handler to allow me to do that?

    1. Anonymous

      So, apparently, the ccassignee handler will prevent either TO or CC emails from being assigned to inbound tickets.  The language above led me to believe otherwise.  Using that handler has produced the desired affect of assigning all tickets to the default user.

  12. Anonymous

    how to assign an issue to someone by email?

  13. Anonymous

    Hi,

    creating an issue from email works very well.

    Is ist possibel to send an automatic create-ticket-notification email to the issue-creator (like the assigned user)?

  14. Anonymous

    How do you receive the tickets but not create an attachment for every email signature included?  We want to create tickets every time an email is sent to our helpdesk, and want to accept attachments for times when Users provide a screenshot of the problem.  Unfortunately many of them, or our internal team have email signatures which include the company logo...

     

    Is there anyway to automagically remove the email signatures attachments?

  15. Hello,

    Is it possible to "link" 2 services? Resp. having 2+ services working on every email?

    1. Strip of the signature with "Add a comment before a specified marker or separator in the email body"
    2. Then remove all the reply-lines with "Add a comment from the non quoted email body"

    I just get one service running. The first service already handles the mail so the 2nd does not have anything to do as the mail is already processed.

     

    Another issue:

    I retrieve the mails from a POP-mailbox. Seems that Jira deletes the retrieved mails from my inbox; usually one could select the option "delete after retrieval / leave message on server".

     

    Any idea?

    BR, Markus

    1. Hey,

      JIRA mail services and handlers do not support chaining. In JIRA, services are just responsible for fetching the message, delivering it to a associated handler and finally delete the message if the handler was able to successfully handle it.

      Good news is that as of JIRA 5.0 you have a new plugin point which makes writing and using mail handlers quite easy. So you could compose such handler on your own.

      Regarding POP mails being deleted - this is how JIRA works by design. There is no option (which I am aware of) which allows you to leave message on the server.

      Cheers,

      Wojtek

    2. JEMH is a single handler that has support for comment stripping and will have support for arbitrary attachment stripping in 1.0 for JIRA5, as well as a bunch of other things.  If there is something you want to do that JEMH doesnt, Id like to hear about it.

      As Wojtek says, the default handlers are focussed in what they do.

      re:leaving on the server, if you happen to use GMAIL, even if JIRA says 'delete', Gmail actually retains the email history.  Why did you want to leave the mail on the server though?

      1. Hi Andy, I am using JEMH 0.9.9 with Jira 4.4 and Gmail. I'd like to add comments from the non quoted email body but can't seem to make it work. Can you send me specific instructions on how to do this? 

        Thanks in advance, 

        Olivier

  16. Hello Wojtek,

    thanks for your reply and tip.

    We currently update our Jira instance to to 4.4.4 (as 5.0 is not yet released). I'll check in 5.0 to define our own mail handler.

    Thanks & Regards, Markus

  17. I arrived at this page from this location:

    https://studio.plugins.atlassian.com/wiki/display/JMH/JIRA+Advanced+Mail+Handler

    Which says:

    "The issuetype parameter is a number specifying the default issue type, and the association between numbers and issue types are explained in http://www.atlassian.com/software/jira/docs/latest/issue_creation_email.html#handler_params. An issue is assigned to this default type if the user did not specify the issue type in the email message. This parameter is mandatory."

    This is the page to which the link in the above quote brought me, and I'm probably missing something, but I can't find anywhere on this page that explains the association mentioned in the afore referenced quote.

    Can someone please help me to understand this association, or point me to where to find this information?

    Thanks,

    Allison

    1. That plugin is indicated as being JIRA 4.0.2 compatible only, if thats ok, moving along:  What it wants is the numeric ID of the issue type, you can find this through your local JIRA admin console https://yourJIRA/secure/admin/ViewIssueTypes.jspa hover over the edit button, you'll see the ID as a URL parameter.

      If that handler doesn't work out for you, there is also JEMH which is compatible with current JIRA 4.4.4 and you can refer to issueTypes by name.

    2. Hi Allison,

      I've requested that the developer of this plugin update their page so that the documentation links lead to the correct version of the JIRA documentation.

      Cheers,

      Giles.

  18. Hi Andy, I am still using JEMH 0.9.9 with Jira 4.4 and Gmail. When I email comments to a ticket, I notice that the lines are broken at about 75 characters (with spaces), leaving most of the screen width available unused. I did a test sending an email with a continuous string of characters (without spaces) and found that the lines are not broken at the 75 character mark. Any idea why that is? Is it coming from the email handler or something else? 

    Thanks, 

    Olivier

    1. hmm, probably not best place for support type questions, would suggest https://answers.atlassian.com/ I am monitoring (smile).  I suspect the issue is coming at the client end, outlook?  Dig out an old mail from 'all mail' on gmail, the truth will be there...

  19. Anonymous

    Hi,

    Its great to have this feature in JIRA 5.0, Congrats!!!

    I was wondering to find in this document how to parse information (with an specified format) within the mail body to JIRA custom fields. It this something that can be done?

    We are running JIRA Studio and we can not install custom plugins such JEMH... 

    Thanks,

    Charlie

    1. Hi, I am afraid that with JIRA Studio (OnDemand) you are not allowed to install custom plugins. Parsing e-mail with a specified format into JIRA custom fields is not difficult to implement, but would have to be delivered as a custom plugin.

  20. Anonymous

    Hi Wojciech,

    Thanks for your fast resoponse (smile)

    It would be possible to parse information contained in the subject into the customs fields? like: project=XXX, issuetype=3, createusers=false, bulk=forward, customfield1=A, customfield2=B... 

    Cheers,

    Charlie

    1. as I indicated, handling custom fields would require writing custom plugin or using for example JEMH (both ways not supported in OnDemand - at least at the moment).

  21. Hi to all,

    I have two question:

    1. It's possible customize issue type without specify the parameter in service configuration?
    2. It's possible manage a  create-ticket-notification email? 

    Thx

    1. Hi,

      https://answers.atlassian.com is a much better place to post such questions. Please try reposting them there and also clarify what you mean in both points (what kind of mail handler, what is the context of this requirement, what do you mean by managing notification e-mail). The clearer the question, the better the answers.

      1. Hi,

        I'll post a question on https://answers.atlassian.com. (smile)

        Thx a lot

         

  22. Hi all,

    How can I specify version to place newly created JIRA ticket from e-mail?

    AFAIK it's automatically created in 'Unscheduled' section, and it gets boring - always move it to needed version.

     

    Thank you!

    1. I don't think the default can do that, however, with JEMH, you can use @affectsVersions=1.1 and @fixVersions=1.2 at the start of the email (amongst other ways) to nominate versions.  In fact, its also now possible to use Project Mappings to route email and have them 'target' both a fixVersion and an affectsVersion.

      1. Anonymous

        Hi,

        Is there any plan to add JEMH in OnDemand?

        Thanks

        C

        1. The scalability of the OnDemand platform comes at a price, limited 3rd party plugins.  JEMH 'for Download' is still rapidly evolving and isn't a good fit for a static roll out.  A future JEMH 'OnDemand' is possible but is a significant undertaking.

           

  23. Anonymous

    Sorry for the anonymous comment, none of the other three Atlassian logins I've already registered for seem to work here.

    In JIRA 4.4.3, I was able to configure the Mail Handler to accept bulk precedence messages.  This was important because of JIRA lack of a built in issue scheduling system, and our use of Google Calendar to work around this.  In JIRA 5.0.3, I'm unable to configure the mail handler to accept bulk messages.  My only options are to delete it, ignore it, or forward it.  Is this something just limited in the UI, that I could change by hand in the database?  Or is this a functionality change in JIRA 5?

    -krellinst (tech_mgr@krellinst.org)

    1. Hi, 

      That's a side effect or our recent UI improvements to mail handler configuration. We did not think that some people would be using bulk e-mails in this way. You should be able to hack this behaviour by removing "bulk=XXX" setting from mail service configuration string ("Handler parameters"). You can do it also by going to <base URL>/secure/admin/EditService!default.jspa?id=<your mail service id> (you can find mail service id by hovering on Delete link in Services menu).

      I've raised  JRA-28160 - Restore support for just ignoring bulk header in mail handler UI Resolved  to track the fix.

      Cheers and sorry for this extra bump on your way to upgrade to JIRA 5.0.x,

      Wojtek

      1. Anonymous

        Thanks very much!

  24. Anonymous

    Hi,

    we recently upgraded from Jira 4.x to 5.

    everything works fine except once you create an issue we dont get notification anymore, i thought the upgrade would not change anything?

    Any suggestions how i can solve this problem?

    1. Anonymous

      I'm a project leader. If I create a ticket i don't receive any notification (i have even tries to add reporter to the system) other receive it. if a member of a team creates one, he doesn't receive it,but other do.

      1. Hi there,

        Please check if the "My Changes" is set as "Notify Me" in the User Preference Managing your User Profile

  25. Scenario:

    • userX: unknown user
    • supportUser: registered JIRA user
    • imapAccount: support@domain.tld

    If userX sends an email to imapAccount, an issue is opened (can this issue be unassigned?)

    If supportUser assigns that issue to himself, and writes a comment, does the userX get an email? so that a discussion can be started and more information can be requested if needed? something like a ticketing system

    If I ask google about this it keeps sending me to this page (sad)

    Thanks

    1. Hi,

      If we decide to configure the handler to auto-create user accounts then the conversation can normally start (and I know of many companies which use JIRA in exactly this way as you describe) and all the communication will be logged to JIRA as the comment to this issue.

      Good thing is that in practice such users don't need to have active JIRA accounts (so you are not forced to use JIRA Unlimited license to cope with multiple users). Everything will work fine even if they cannot log in (they will be communicating just by e-mail).

      Cheers,
      Wojtek 

      1. Hi Wojciech

         

        I just tried excatly what you described. What happens to me:

        1. I receive an Email (as administrator - global permissions) that i have a conflict with the users. so it looks like i would receive this email everytime a new user sends a ticket
        2. The sender still did not receive an email, probably because he has no permission to log in to JIRA

         

        How can i reach the behaviour described by you?

         

        Regards,

        Yves

        1. This description is not sufficient for me to understand your problem. I suggest raising a support request where you better describe what is going on (and include log files and the e-mail you are getting) and we will try to help you. Please reference this comment in your support case.

          Cheers,
          Wojtek 

          1. Hello all,

            Just bumping in with a small clarification: JIRA has been designed primarily as an issue tracking software, and all users that have login credentials count towards the user limit. There is no option to create "inactive" accounts that would receive notifications, but not be accounted for in the user limit. We know it is a challenge for our customers who wish to use it for helpdesk/support, and don't want to pay for every customer to be able to access JIRA. We're actively working on a solution to meet the functional and budgetary needs for folks like you; in the meantime, if purchasing a higher user license is not a possibility, you might consider a few possible workarounds:

            - a third-party plugin, JIRA Enterprise Mail Handler that will allow you to capture the email addresses of anonymous users who create issue via email in a custom field- this effectively allows to both identify the user from this field, and send outgoing notifications to that (non-registered) 'anonymous' user). Another plugin, the JIRA Email This Issue Plugin offers a nearly identical 'email to user from custom field' feature. (mind that this option is not available for OnDemand users, as they can't install third-party plugins)

            - JIRA's Share Issue feature allows you to notify anonymous users about issue status.

            - the JIRA Issue Collector plugin allows you to embed a feedback form on any webpage that visitors can use to submit feedback in the form of a JIRA issue. The JIRA Issue Collector is included in JIRA as of JIRA 5.1., including JIRA OnDemand.

            Cheers,

            Dora

             

            1. Hey,

              Whereas I agree to what you say wrt what JIRA was primarily designed for, I am pretty sure that people who have been successfully using JIRA in the set-up similar to what I described (either with inactive users or putting the original reporters into custom field and then using special notification scheme which notifies them) would be surprised. Be warned though that some code customizations (custom plugins) may be involved here (smile)

              Cheers,

              Wojtek

            2. Anonymous

              "There is no option to create "inactive" accounts that would receive notifications, but not be accounted for in the user limit."

              That's not true. If you use Crowd you can do it.

  26. Anonymous

    How can we handle a mandatory field to be populated throiugh email (not using JEMH.... neither are the plans). Thanx.

    1. Anonymous

      p.s. I mean a Custom mandatory list type field

      1. Anonymous

        write a post function to set the value if its empty.

        1. Anonymous

           A post function cant be an alternative to what user can choose and should be allowed to choose.. Thanx anyway

          1. Anonymous

            Sorry, I thought you wanted to set a default value for a custom field, permanently, for email senders, which can be done through a post-function.  If you want users to provide that, you're right, cant be done in a post-function.  Sounds like you have both hands tied behind your back, time to reconsider requirements or limitations.

  27. Anonymous

    We have configured acording to the above instructions. It works fine for as long as we use seperate email address for each project. But we need it to be configuted for one email address which can be used for all projects we have. This enables our support staff to deal with one perticular email for all enabled projects. How could we create this using 'JIRA Enterprise Mail Handler' plugin. We are using JIRA 5.1.2 version. Or do you have clearly instructed document like the above one?

     

    1. If you can support KEY@your.domain.com, just tick the 'Project > Project Auto Assign', failing that Project Mappings can be used also.  Please post follow up questions on answers or the JEMH forum where others may benefit from the answers?

  28. Anonymous

    Running into an issue where incoming mails are correctly creating an issue, but the body of the email is not being loaded into the description field.

    No notable warnings or errors in the logs.

  29. A customer ran into an issue where he was trying to create comments into issues with success, but an e-mail was been forwarded to him with an error.

    The problem was that he had two times the 'Forward e-mail' parameter into his handler, fixed the issue removing one of them.

    Kind regards.

     

  30. Why does every email i send in to create an issue or comment have these **** in them

     

    Arik, here are the details for this project****

    ** **

  31. Is there a java start-up parameter/other solution which can turn this off? When you create a test environment, you probably want to turn incoming mail off  - so your test instance wont eat up all the emails until you can reach the administration page.

    1. Bah, I found it (smile)

      You should set:

      -Datlassian.mail.fetchdisabled=true

       

       

       

  32. Hi,

    While creating an issue via email, JIRA id is able to create but Assignee and Reporters are not getting ID via email. 

    Note: we configured SMTP and POP and Mail handlers correctly but we are unable.

    Can someone please help me out ASAP.

    Janardhan

  33. Is the handler able to create a sub-task via email by mentioning the parent issue's key? Currently it creates orphans as there is no additional configuration option for sub-task issuetype's parents.

    Anyone tried to do this?

    1. I don't think so, but JEMH can, with the JEMH email Directive : parentIssueKey, that can be triggered for example, in the subject with #parentIssueKey=ABC-123, or customized with Aliases to #parent=ABC-123

      1. Anonymous

        Hi Andy, Is your plugin now a paid or free as I think earlier was free. Regards Deepak

        1. Anonymous

          Hi Deepak,  yes, the last 12monhts of dev time has to be supported, its paid if you want to make use of the for configuration and the more advanced features.  There is still a free mode that has a restricted set of features and is still driven from a property file (with all pain that stems from it).  Many features have just not been implemented/accessible via this mode.  Two FieldProcs are available, basic and At Prefix.  You can generate a free eval though the license screen.

      2. Thanks Andy,

         

        We realized, that it can be too complicated to figure out the parent issue key, so will not go into this direction at this time.

  34. Anonymous

    Is it possible to mention anyone in the reply?

    For example if you respond to an email with the comment
    "Thanks @Pete I will look into it"

    It will process as a mentions in JIRA and send the email to Pete?  This would be really handy.

  35. We tried the following regular expression to see whether a double slash in a separate line can be used as the 'Split Regex'. It didn't work.

    /^//$/

    Any particular reason for that?

    Thanks!

    1. Anonymous

      Sameera: Escape the slashes in your regex. eg. /^\/\/$/

  36. Anonymous

    I'd really like to be able to use the "summary" field or another custom field to indicate where the email message should be posted, rather than the issue key. Issue keys, to my knowledge, are set up by Jira, and are not editable - but I'd rather use a unique shortcode that we have for every issue, that is much easier to remember instead of trying to remember all the Issue Keys for forwarding messages to Jira....

    1. Anonymous

      I'm not sure what value one generated number will be over another?  Can you provide an example, how well will it scale past 1000 issues?

      1. Perhaps the JEMH plugin can handle defining what JIRA project is used in a more flexible way. But a tool like JIRA relies on the issue keys it generated to provide lots of the functionality. Using your own unique identifiers in a custom field may to cause difficulties later on when you want to do other things with JIRA. I'd stick to issue keys.

        1. Yes, agree, Issue Keys are the primary ID for JIRA, however, when integrating other systems with their own primary key things get more grey.

          JEMH has many email content processors, one of these is the Regexp Field Processor, the configuration of which allows a user to set a regular expression on content in subject or body, the value of which that represents a remote system ID/key.  The type of this field can be text/numeric.  I would guess that numeric types would index faster that text fields. The purpose of this mapping is purely to tie-in remote system email notifications to a currently open JIRA issue, if no existing issue has the same key, then a new issue would be created.

          The Regexp FP also allows arbitrary email content mapping to JIRA fields, as well as translating remote system values into JIRA friendly values (e.g. for select list compatibility) through value Aliasing.

  37. Has anyone  find how to remove the email signature in the issue generation, because it is very uncomfortable?

    Thanks in advance.

    1. Read above, re: Add a comment before a specified marker or separator in the email body, you could use a regexp to match signature lead ins.

  38. Anonymous

    (posting as anonymous as I'm having problems logging in currently)

    We're using JIRA 5.2, and have the following problem: when users try to create a new issue using email, if the subject of the email matches an old issue WITHOUT including an issue ID, these messages can be appended as comments to an old issue. It was my understanding that in order to append a comment, the subject must contain the actual issue ID of the issue you are trying to update, and not simply match the subject.

    So, if I have a CLOSED ticket such as "PROJ-123 This is a test" and someone sends an email with "Subject: This is a test", it can be appended to issue PROJ-123 even though that issue ID is not explicitly added to the subject line of the message. The expected behavior is that this message would result in a new issue ticket being created.

    The strange thing is, it doesn't seem to be consistent behavior. Sometimes, it does seem to work as expected, but other times, we're seeing messages unexpectedly being added to old issues. I've not yet been able to identify the factor that could cause it to sometimes work. 

    Suggestions?

    1. JIRA 5.2.3 introduces new handling of emails with a 'reply-to' header, which is what I think you're seeing.

      Theory goes, any JIRA based email is tied to an issue, and has a reply-to header.  If you take that email and switch its content around, it will still get associated, this I think can mean trying to associate with another ticket by modifying the subject doesn't work?

      The only way to guarantee an email goes to an issue is either reply to a notification on that issue, or to create a new email, and add the issue key.

      I've noticed that its possible to reply to an issue that's closed (I think this was what you mentioned?), its still possible to comment on it.  Possibly the association should only occur for open issues, not sure how common this is.

      1. Anonymous

        The problem I'm seeing isn't with replys - it's with new emails.

        I'm looking at an example right now - an issue was created by an automated report process via email. The issue was created in July 2012, and closed Aug 2012. Since then, the automated (monthly) report has been sending out new email messages with the same Subject each month, and every time, JIRA associates it as a comment on this old issue. So these are not using any kind of reply-to header to generate the email, and there is no JIRA issue ID in the subject.

        Interestingly, prior to July, when these messages were receives by Jira, they woul always spawn new Issues, but now they aren't.

        I'll keep poking around and see if I can find any other relevant/useful details to help diagnose this. I'm kind of stumped at the moment.

        1. To troubleshoot this kind of an issue, we would need to see the emails themselves, and their headers, as well as general system logs when this occurs. I would recommend asking for help from the community at https://answers.atlassian.com/ or opening a support case at https://support.atlassian.com/

  39. Anonymous

    OK, after a bit more digging, I think this is actually related to headers. Specifically "Message-ID" and "In-Reply-To" headers. It looks like that in some cases, new messages coming in are using an "In-Reply-To" header that matches a previous "Message-ID". Rather than attempting to re-educate every potential requestor in how to send email in a more Jira-friendly way, would it be possible to turn this "In-Reply-To" logic off on the JIRA server?

    1. Anonymous

      Sorry, this reply was meant to be part of the thread above it... :-/

    2. No, this is not possible in stock JIRA. This is totally doable with a custom mail handler.

      1. Yep, I guess if this isn't possible in JIRA its down to a custom mail handler.  I'll add an 'ignore' checkbox option to JEMH to allow the disabling of thread detection if you really want to go there, but the scenario it solves is emails coming into JIRA with others on CC, without threading detection you will get a possible snowstorm of new issues.

        1. Thread checking can be disabled if required via JEMH (1.3.18+ possibly earlier) config option Email > Pre-Processing > Disable Thread Checking.

  40. Anonymous

    The bit in red no longer seems to work in JIRA 5.2, anyone else having this problem ?

     

     

    Default Reporter

    Specify the username of a default reporter, which will be used if the email address in the From: field of any received messages does not match the address associated with that of an existing JIRA user — for example, a JIRA username such as emailed-reporter 

    (info) Note:

    • This option is not available if the Create Users check box is selected.
    • Please ensure that the user specified in this field has the Create I ssues  project permission for the relevantProject (specified above) as well as the Create Comments   project permission for the other relevant projects to which this mail handler should add comments.
    • When an issue is created and this option is specified, the email message's From: field address is appended in a brief message at the end of the issue's Description field, so that the sender can be identified.
  41. I can't seem to figure out how to create a regex that matches my expected delimiting string. The string I want to match is:

    From: Smith, John A (JIRA) JIRA1@ri.gov

    The regex I've tried is:

    /^From: .*JIRA1@ri.gov/

    But it doesn't seem to be matching, because all of the orginal message is getting added into the comment. Is there a way to debug the regex functionality? (I have tested my regex here, and it seems to work fine.) Is the dot star ( .* ) greedy or something?

    1. Ahh, never mind. (Too bad I can't delete my post).

      Turns out the space character in my regex was wrong. Once I looked at the html source of the message, I realized the space character after the colon didn't exist.

      For future reference, this page helps with similar issues. (or this post)

  42. ck

    While creating issue from email, cc'ed users are added as watchers. But they don't get notification from jira. Is it expected behaviours? I have enabled - watchers to get notified in notification scheme for issue created event.

    1. Anonymous

      You may need to change their setting and allow them to be notified for their own changes, that did the trick for me when the system wouldn't send me emails on issue creations.

      1. CK: Did changing that setting work for you? If so, what version were you running?

        Anon: What version were you running?

        I've changed my setting to be notified of my own changes and I'm still not getting the Issue Creation notification for an issue that I'm cc'ed on. 

  43. Anonymous

    When you create an Issue from a mail handler, is it somehow possible to select the component of a project instead of only the project?

    1. No. This feature not available yet. There is a third-party plugin that might be able to suit your requirement https://marketplace.atlassian.com/plugins/com.javahollic.jira.jemh-ui

      You might want to contact the vendor to check if it is suit your usage.

      1. Just to follow up, JEMH can help with this in several ways:

        1. you can use Directives to specify #components=abc,def in the subject or @components=abc,dev in the fist line of the body. (see the full list of supported fields)
        2. you can nominated a default project with a default component (per JEMH Profile, there can be many).
        3. you can create a Project Mapping matching on the sender address, and route the mail to a particular project and optionally component.
        4. you can use the Regexp Field Processor to disect repeatable structure content to extract keywords that can be used as Components, and even, through JEMH Aliases, translate those external values to internal component names.
  44. Anonymous

    Is there a way in which an email can be automatically linked to more than one issue?

    1. If you use the other issue KEYS in the email JIRA will highlight them.  You can also paste text URLS.  If you actually want to link the issues, that's different.  JEMH has the linkto Directive that allow you to drive the linkage from one issue to another through email and define the relationships, only one per email currently supported;

      @linkto=to:ABC-101/duplicate,from:XYZ-123/relates

       

  45. Not 'automatically', as the criteria you want to use to discover those issues isn't defined but JEMH has the capability to link issues through the linkto Directive which needs to be supplied by the user in the email. Example format would be:

    to:ABC-101/duplicate,from:XYZ-123/relates
  46. HI,

    If I am creating a new "Create a new issue or add a comment to an existing issue" handler in the Bulk I see 4 options, but in the above documentation there are only three...

    1. Ignore the email and do nothing.
    2. Forward the email (i.e. to the address set in the Forward Email text field).
    3. Delete the email permanently.

    4. Accept the email for processing

    What is for that that last option "Accept the email for processing"?

    1. Mirek, it means the mail handler should 'accept the email for processing' rather than any other rejection or ignore outcome.

  47. Anonymous

    When replying to a JIRA-initiated email, the subsequently created comment in the ticket is appended with numerous "footnote" lines containing links to tickets, users, etc. With each subsequent reply, the list of links gets longer and longer, making sifting through the comments very difficult.

    These lines look something like this:

    [9] [28]http://www.atlassian.com/software/jira
    [10] [29]http://www.atlassian.com/software/jira

    Has anyone else seen this? Is it something that can be fixed via some configuration setting?

    Thanks.

    1. Yes, this is default behaviour for converting HTML email containing hyperlinks to text, the bracketed numbers indicate references in the content.

      To remove this you will need to write your own mail handler or use something like JEMH that can disable that.

  48. All the setup is to be done from administrators account?

    How as a client or user i can configure it and use it?

    Thanks

    1. Normal users cannot administer email settings.  Mail Handlers are an internal feature, manageable by a JIRA administrator only.

      Using it is just sending email to a nominated address, perhaps clarify the question.

  49. Anonymous

    Hi,

    I have an inbox with a very large volume of input (6GB per week). I can convert all these messages on issues in jira?

    1. That's data volume, what email numbers are you talking about, sizes of attachments? spread over how many mailboxes?  

      JIRA can certainly create issues from mailboxes, and subject to network capacity will probably do that job well enough out of the box if you have a single or limited number of mailboxes, though if you have many (~60 or more) then scalability issues will start showing.  Alternative mailbox configurations can address that (condensing many addressees into a single mailbox), but with your volume, that may be easier said than done (redirecting all mails from many mailbox into one common one).

      You probably have staff managing the inbox, so the idea is to move those staff to managing JIRA issues?  You'd then be collating the customer content in JIRA and re-broadcasting further emails to assignees etc.  6GB/week is about 10K issues per day, is that spread over 24 hours (global users) or condensed in specific time period?  Considering an 8hr day that would be 1250/hour or 20 per minute.  Creating issues is pretty quick, but the loading will be continual.  As an example of JIRA processing in general, a quick test not including network latency, shows JEMH can create 1000 issues in 31Seconds.
      JIRA is currently a single node solution, but clustering is coming in the next few point releases that would help with loading.  How many concurrent JIRA users do you expect to support at the same time?

      Who are the people sending the emails, are they JIRA account holders, or external non-JIRA users?  Do you expect/require any non-JIRA user acknowledgement outbound?  How about ongoing updates, are they to reply to these?

      Of the inbound messages, are you going to want use those emails to create/comment within one JIRA Project 'inbox' or spread out to different Projects/components, do you need different assignees and priorities? What about automated system import, other ticket systems for integration?

      Largely the above is what JEMH does, and it does have customers with very large data volumes.  Happy to discuss your needs if you like, you can always ask a question on answers.atlassian.com or if needed mail direct, andy@thepluginpeople.com

       

  50. Hi,

    I used this configurations to set up an e-mail ticket creation for my JIRA Service Desk. My customers are now able to automatically create issue on my JIRA SD project's queue when they send an e-mail. But this issue created by e-mail  is not being display in their customer portal as the ones they open directly by login the customer portal.

    I appreciate all your support.

    Waiting for an answer, best regards.

    RoseC

    1. This is currently not possible out of the box. The feature request for this is at:  JSD-38 - As an admin I want Service Desk to recognise issues created by Mail Handlers and through the standard Create Issue To Do

      Internally, we are using the https://marketplace.atlassian.com/plugins/com.atlassian.plugin.automation.jira-automation-plugin as a workaround. 

  51. Hi,

    We're using the email handler to automatically add comments to a JIRA ticket. Usually this works well, but our users here all have 2 email addresses configured, while JIRA only handles one. This means that when a user sends a comment through email with a non-recognized email address, it results in an error.

    I understand the limitation, and this is not a request to solve this particular issue. But I'm wondering if there's a possibility to notify the user that his reply didn't make it to a comment in JIRA. The administrators get an email notification, but the end user is left clueless.

    Any way to solve this issue?

    1. The JEMH add-on can send helpful error messages to users when email is not processed as expected.