- Based on the current policies in IMSx, manually create the corresponding policies on DDEI. In DDEI, the policy works differently as IMSx, unlike IMSVA, IMSS or HES. For DDEI, if it contains multiple policies, the policy filtering logic are as follows (similar as the firewall rule):
- DDEI will check the from/to addresses (envelope addresses) info of the new incoming message.
- If the message from the from/to addresses matches the first policy’s Senders/Recipients setting, DDEI will use the first policy to check this message and take the final action based on this policy’s rules’ scanning result. If the message cannot trigger any of this policy’s scanning rules, the final action is to deliver. This message will not go through to the next policy.
- If the message for the from/to address does not match with the higher priority policy’s Senders/Recipients setting, this message will go through to the next policy until it matches one of the policy’s Senders/Recipients setting then take the final action based on this policy’s scanning result.
- If the message does not match with all the policies’ Senders/Recipients setting, DDEI will deliver this mail.
- If the message contains multiple recipients and only a part of the recipients can match with one policy’s Senders/Recipients setting, DDEI will split this message into two messages. One message will check by the matching policy, and the other message will keep checking if it will match with the remaining policies.
Only one mail can be checked by, at most, one policy. - Deploy the DDEI in the testing/production environment based on the customer's condition. This step depends on the customer's network architecture. eg. put DDEI as 2nd email gateway by DNS round robin, or Hub GW dispatch certain mail domain to DDEI, or put DDEI behind IMSVA for initial phase.
- Run DDEI for a certain period to see if there is no issue, then remove the IMSx from the environment. A generic health check for the DDEI may be performed:
- Deployment
- Check if the right mode (MTA/BCC/SPAN-TAP) is selected.
- Check if the network settings are correct and can accept emails from upstream MTA.
- Pattern/Engine
- Check if the pattern or engine version is up to date.
- Service: all the necessary/enabled services are running well.
- Check for any received notifications triggered by service down.
- Test the enabled services in the system maintenance page.
- Mail traffic
- Send test messages to make sure that DDEI can process mails successfully.
- Go to the dashboard on web UI to check if emails can be processed well.
- Check if there is large amount of emails being deferred. If there is, check the deferred reasons.
- Check if there is large amount of emails staying in VA analysis time out. If there is, check the time out reasons.
- Check if there is large amount of emails with VA analysis error. If there is, check the reasons.
- Check if average email processing time is very long.
- CTD
- Check if SO can successfully be synchronized from Control Manager (TMCM).
- EUQ
- Check if users report quarantined FA.
- Check if the EUQ digest can successfully be delivered.
- Virtual Analyzer (VA)
- Confirm if VA images have been validated by our VAIPT.
- If they are using the Internal VA, test the VA network connection.
- Check the VA settings and make sure that the dedicated files are submitted to VA successfully and that it can also analyze the files successfully.
- VA tab on the Messages Submitted to VA widget, the engineer will know VA’s working status. It would be a problem if a lot of mails are queued in VA.
- Logs
- Check all kinds of logs to make sure that logs part works as expected.
- System status
- System Status tab contains the hardware status widget.
- Deployment