Incoming Mail Connections
To use mail handlers and process your incoming emails to create or modify issues, incoming Mail Accounts have to be configured first.
Due to security reasons, the Email This Issue add-on cannot access the mail servers in Jira itself, so mail accounts should be configured within Email This Issue's Administration interface.
1. Go to the Administration configuration tab, and choose Incoming Mail Connections under the INCOMING MAILS menu item.
Incoming Mail Connections
2. To create a new Incoming Mail Connection, click on Add.
3. Email This Issue supports login and OAuth authentication mechanisms for Incoming Mail Connections. In the Add Incoming Mail Connection dialog, select the correct protocol:
- POP3, IMAP: log in with username and password
- OAuth for Gmail/Gsuite: OAuth2
- OAuth2 for Microsoft 365
Note: the content of the dialog changes based on the authentication method you select.
Incoming Mail Connections are always added in a disabled state. After editing an enabled Incoming Mail Connection its state will change back to disabled.
In case of an unsuccessful connection in the Incoming Mail Connection, the status becomes red and a protocol log becomes available:
Incoming Mail Connections - Protocol log
The Protocol Log is displayed only when the status is red (indicating a problem with the connection) and it contains information about the errors that occurred during fetching e.g. authentication failed, wrong hostname etc.
Currently Email This Issue does not delete processed emails. Before saving the Incoming Mail Connection, please use the "Test Connection" button to check if Email This Issue is able to connect to your mailbox.
If you’re working on a production account that already has emails in the inbox (read or unread), remove everything you don’t want to be processed. This is needed because at the first processing round we download every email from the target folder. Later on, we only download those that have not been processed yet.
OAuth authentication is currently supported for both Google and Microsoft 365 accounts.
If you want to use OAuth 2.0 authentication, select this option with the appropriate protocol. A new dropdown list and button will appear under the protocol selector.
For OAuth2-based Microsoft365 IMAP connections, the hostname "outlook.office365.com" is used by default, when connecting to the mail server. However, in certain scenarios, the use of a custom hostname might be required. In such cases, there is a possibility to override the default value by enabling the respective "Override default host setting" toggle and selecting the desired host from the "Host" dropdown appearing below.
The dropdown contains a pre-defined set of hostnames, which are globally available. If you have even more specific needs, please contact our support team.
Overriding hostname for an OAuth2-based Microsoft365 IMAP connection
- 1.Select the Client Credentials you created on the credentials page.
- 2.Enter the user name to the SMTP Server you want to use.
- 3.Click on the "Authorize with Google" button to grant access to Email This Issue to send emails from your account.
- 4.In the dialog, select the account which belongs to the email address you use for login:Note: If you have multiple Google accounts select the one with the email that matches the username in the SMTP Server dialog. Emails will be sent from that account.
Result: You can send emails in Email This Issue from Gsuite with OAuth Authentication.
Important. Starting from June 15, 2020 Less Secure Apps is not be supported in GSuite. Read more at: https://gsuiteupdates.googleblog.com/2019/12/less-secure-apps-oauth-google-username-password-incorrect.html
Authentication should be done using OAuth2.
A shared mailbox is a mailbox that multiple users can use to read and send e-mail messages. You can read more about them here: https://docs.microsoft.com/en-us/exchange/collaboration/shared-mailboxes/shared-mailboxes
To use a shared mailbox you just have to enter the username and password (or use OAuth) of the account you want to log in with, then enable the "Use a shared mailbox" option and enter the alias of the shared mailbox in the field that appears:
Shared mailbox settings for Incoming Mail Connection
By default, all new Incoming Mail Connections are created as disabled. To enable a connection, select the "Enable" option from the connection's menu.
From the app's point of view, when initializing a new or re-activating (re-enabling) a previously used ("known") mailbox - provided that there is a matching enabled mail handler for the connection at hand - there is a good chance that a bunch of messages will be subsequently downloaded from the mailbox and processed by the app (by creating or updating issues).
Depending on the contents and the current state of the mailbox, such an action might entail some risks though:
- lots of emails might be processed inadvertently (which may take a while, while also changing messages' state on the mail server by marking them as SEEN or DELETED)
- under certain circumstances (depending on the mail server's and the app's settings), duplicate issues might be created
To avoid the undesired download of a large number of emails upon enabling a connection, the estimated number of 'new' messages within the target mail folder is assessed and an informational dialog is popped up if an acknowledgement is required before acting.
Searching for new messages (in progress):
If there are any new messages to download, the following text is displayed:
Clicking on the Enable button will change the connection's state and trigger other processes as indicated by the appearing flag:
Depending on the selected connection mode (and the underlying protocol) about the mailbox's current state, the exact number of 'new' messages (from the app's point of view) might not be possible to be determined within a reasonable amount of time. Consequently, the accuracy and confidence level of this estimation might vary in different use cases and situations.
The displayed message count may be affected by several factors, including but not restricted to the following:
- whether it is a "brand new" or an "already known" mailbox for the app
- the total number of (unread or all) messages within the mailbox
- the number/ratio of known and new messages (stored message UIDs)
- the number of already processed, but “manually reset” messages (being set unread again)
- various mail server settings (session-level restrictions)
Moreover, it is also hard to verify the outcome in graphical email clients (Gmail/Outlook/etc. browser/app), as they may still keep track of read and deleted messages differently by hiding some details from the end user.
Despite all these considerations, the estimation can be classified as pretty much exact or at least as fair and reliable in most cases.
There is one notable exception though - POP3 connections, where the "mark as read" post-download action is selected. Here, both the accuracy and the confidence level of the estimation result may be extremely low. Nevertheless, we highly discourage you from using this unfortunate option (or rather combination) in real-world (i.e. production/production-like) scenarios, as the performance of the message download will also erode over time (as facing an ever-growing mailbox, where all the messages must be considered and handled as "potentially relevant" by design).