HES uses <senderMsgID> to co-relate the records of preMTA, scanner, and postMTA. An email will be judged as "unresolved" if it meets one of the following conditions:
- The same sender Message ID is used for two different emails going through two different MTAs.
- All the records with the same sender Message ID and recipient should have the same MTA ID and MTA generated Message ID. If either the MTA ID or MTA Message ID is different from those records, those records will be considered "unresolved".
This issue happens only to notification mails. It occurs depending on:
- The particular "Action" that the customer set.
Example: The customer set the action to quarantine the bad mail and then send out a notification mail containing the unmodified bad mail as attachment.
- The particular action HES takes on this situation:
When the terminal action (like "quarantine", "delete" and "deliver now") and send notification mail action (such as "attach the bad mail") are both set, HES will scan the notification mail again. As a result, there will be a record for this notification mail on the scanner side.
Since the scanner is not a real MTA, the notification mail will not get a <senderMsgID> . But when the notification mail goes to postMTA, it will get a <senderMsgID>. This means that in the scanner record, the notification mail's is NULL. But in postMTA, its <senderMsgID> is *****. Since it was generated by the scanner, there is no inbound record for the notification mail, so there is no way to co-relate it with the <senderMsgID>.
Trend Micro has decided not to do anything about the issue because it will not have any influence on the customer side. More importantly, the rescan action of the notification mail is important for security.