Comment on page
Email Receipt & Deduplication
Details regarding email deduplication - common Email Server behaviour with how they can create duplicate emails, and subsequent behaviour in Enate
As part of day-to-day processing in Email systems and integration with other systems, it is possible for errors to result in duplicate emails. To combat this Enate provides built-in capabilities to deduplicate received emails. Let’s take a look at the details for this.
As a core principle, Enate will generate or update 1 work item per recipient per received Email after deduplication. A recipient is either an existing work item or an address defined by an email route.
To guard against accidental creation of multiple work items caused by duplicate incoming emails, Enate checks for such duplicates and deduplicates them so that only one work item is created.
Enate looks for duplicates in 3 ways:
- The first method considers the entire content of the email, including not just the user-visible content such as Subject, Body, Senders, Recipient, Attachments, etc but also the underlying email information such as the email headers.
- The second method considers a subset of the user visible content, but does not consider most of the underlying email headers.
- The third method only considers a subset of user visible content (excluding the body of the email) and the hidden unique identifier of the message (if available).
If any of the above methods determines that the email is a duplicate, then the email is considered to be a duplicate.
In a scenario where a sender includes multiple addresses in the recipient list (To and CC) which are picked up by Enate, the system would normally receive 2 (or more) copies of the email, and the Email routing outside of Enate would determine whether it is caught as a duplicate or not. However, the duplication taking place in the Email Server infrastructure cannot be guaranteed.
Multiple copies of the email must be generated by the Email Server infrastructure otherwise the core principle stated above results in just a single Work Item.
Whether multiple emails are created or not in this scenario is outside the control of Enate and should be investigated with your Email Server provider or Email administration team. In our experience factors which may affect this include (but are not limited to):
- If the email is sent by internal or external senders
- If the recipients are real mailboxes or aliases
- If transport rules are used (Exchange/Office 365)
- If 3rd party antispam/antivirus products are involved in email delivery.
Due to the variability in behavior of external systems with regards to multiple emails and duplicates, we strongly advise business processes and email scenarios are tested thoroughly to ensure the desired behavior in Enate is achieved.
A work item will be created following the applicable configured routing within that mailbox - these may obviously be different, resulting in the created Work Items potentially being in different contexts (and Ticket Categories for Tickets).
Enate does not support processing of emails where it is received because it has been BCC’d to the email address of the mailbox, or one of its aliases, configured in Enate, the system may not be able to route the email. This is because the BCC (Blind Carbon Copy) details are intentionally hidden from all recipients as part of standard Email behaviour. The result of this is that Enate receives an Email that does not identify itself as being destined for any configured Email address.
In this scenario the email will become available in unprocessed view.
Imagine an email sent to [email protected], [email protected] and [email protected] and BCCd to [email protected]. Here [email protected] is an alias for [email protected].
If the email is sent by a colleague (an internal email) then it is likely, depending on Email Infrastructure, that Joe would receive 1 email, Tom would receive 1 email and Kevin would receive 1 email.
If the email is sent by an external contact (an external email) then it is likely, depending on Email Infrastructure, that Joe would receive 2 emails, Tom would receive 1 email and Kevin would receive 1 email. Joe would see 2 identical emails in his Inbox with no discernible differences; only when viewing the Email headers would differences be identified and even then it is unlikely either email could be attributed to [email protected] vs [email protected].
In both examples Kevin would receive the email but wouldn’t really know why – he would not be able to identify himself as a recipient in the To or CC fields and the BCC field is not shown.
The impact of these 2 examples if received by Enate is that for the first example (sent from internal):
- 1 email would be received in the mailbox [email protected] which would follow the configured routing rules resulting in 1 Work Item.
- 1 email would be received in the mailbox [email protected] which would follow the configured routing rules resulting in 1 Work Item.
- 1 email would be received in the mailbox [email protected] but routing rules on this Email Connector wouldn’t match any of the To or CC addresses, so it will be made available in unprocessed view.
In the second example (sent from external):
- 2 emails would be received in the mailbox [email protected], one would follow the routing rules for [email protected]. The one addressed to [email protected] would likely be detected as a duplicate by the 3rd rule above and so no work item would be created.
- 1 email would be received in the mailbox [email protected]. Same as for Internal, behaviour would be as above would result in 1 work item.
- 1 email would be received in the mailbox [email protected]. Same as for Internal behaviour as above - it will be made available in unprocessed view.
