...
Related to message data, JEMHC does support inline images in outbound notifications, and attachments, if you enable this, and make regular use, it can impact your data usage.
Mailservers
JEMHC cannot use the mailbox provided by Atlassian, you must host your own.use an external one, when doing so you may need to refer JEMHC public IP address to allow contact to your instance - this allows anyone on JEMHC to attempt this, for finer grained security, you would need to setup dedicated certificates that only your configuration has.
Microsoft office 365 (in:POP/IMAP/EWS, out: SMTP)
Gmail (in: POP/IMAP, out: SMTP)
Your own dedicated Exchange (in:POP/IMAP/EWS, out: SMTP)
New users start on a Starter Plan that is deliberately limited in capacity, this is to fail fast when problem scenarios occur (e.g. processing a POP mailbox where the ‘from now’ checkbox wasn’t set…)
...
What's different?
Data Storage
Inbound mail flow
As JEMHC is remote, the JEMHC app retrieves mail from mailservers you configure over SSL transport for common protocols (POP/IMAP/EWS). By default, JEMHC currently retains a very limited rolling window of the 100 latest mails in full (for mail under 10MB), encrypted (at rest) in our database, residing in the AWS Virginia datacenter. We do this as part of auditing to allow failed mails to be retried. Users can opt out of this (requires support interaction to re-enable), doing this would impact our abiltiy to support you with processing problems.
JEMHC communicates with your Jira instance over SSL transport security.
Part of Auditing > Inbound Messages will retain recipient info, including the Project/Issue Key.
We have no access to your mail held here. You have the option to ‘flag’ mail for support, at which point we are able to see/download that mail and the processing report through our back office support tool, accessed by employees only.
Outbound mail flow
For background, see How Jira events turn into emails and Manipulate Webhook data in a Template
As JEMHC is remote, your instance will send a webhook (JSON payload) for each and every change you make to issues. JEMHC will only retain webhooks for processing where you have configured JEMHC to generate notifications for specific projects, in this way, we retain only the subset required for JEMHC to do what you have configured.
On receipt, webhooks are stored, encrpyted, in a FIFO queue that JEMHC subsequently processes. As JEMHC reads webhook data, we create an Auditing > Events record containing this data, also encrypted at rest. JEMHC then makes calls back to your instance to fill in the blanks about the issue, that data is stored in our DB. JEMHC also stores a ‘Report’ of the webhook Event processing, again, we retain only the most recent 100 for diagnostic purposes. Having the event data is key in you being able to create a custom template and preview what it will really look like.
When JEMHC sends mail, we again retain the most recent 100 messages (and their HTML payload) in Auditing > Outbound Messages , where we track the project/issue source, the sent email subject (typically issue summary) as well as the recipients. A ‘Report’ for the actual sending of the mail is also stored, including recipients, filenames of attachments added etc.
About PII
Whilst JEMHC only retains the most recent 100 webhooks and inbound/outbound mails, we retain the last months worth of ‘audit’ records that something happened, meaning, webhooks, inbound mail and outbound mail. If a user choose to ‘be forgotten’ Atlassian will notify JEMHC and removals of related records will occur.
Profiles
JEMH Server/DC Profile exports are not currently compatible with JEMH Cloud.
...