How do the “override error handling behavior” options influence the behavior of EGS?

The options to override any errors during email processing are intended to be used as follows:

• MetaDefender Core unreachable: This setting is to cover situations where either the network connection or the Core service are down for any reason and EGS cannot contact Core to send the email for processing.

• MetaDefender Core busy: This setting is to cover situations where too much traffic is reaching Core and the processing queue is full of objects waiting to be scanned.

• MetaDefender Core scan timeout: This setting is to cover situations where a scan process in Core is taking too long and is hitting the timeout limit, which would cause the scan to be seen as failed in Core.

• MetaDefender Core processing failed: This setting is to cover situations where a scan process fails for any reason in Core (engine unavailable, file is corrupt etc.).

• Anti-Spam processing failed: This setting is to cover situations where the anti-spam processing is not functional in EGS, either due to licensing or internal reasons.

• Not scanned result from MetaDefender Core: This setting is to cover situations where Core will return a "not scanned" result, which can be caused by certain workflow configurations that would trigger Core to skip scanning a specific email.

• Email modification failure: This setting is to cover situations where EGS is not capable of modifying the email with the content sanitized through Core, either due to unsupported content in the email or other factors.

The available options will vary from setting to setting, this is how each will influence the behavior of EGS:

• Retry: EGS will keep trying to reprocess the email until receiving a successful response from Core (based on the retry count in Settings -> General) then will fail the email and send an NDR

• Fail immediately: EGS will instantly mark the email as failed to process without any attempts to retry and will send an NDR

• Bypass on first failure: EGS will bypass the email as soon as any component triggers a failure and will send it to the end user

• Bypass if all retry fail: EGS will keep retrying based on the retry count, then will bypass the email and send it to the end user

• Block: will mark the email to be handled as if it were blocked (detected as malware, for example)

• Quarantine on first failure: EGS will quarantine the email as soon as any component triggers a failure

• Quarantine if all retry fail: EGS will keep retrying based on the retry count, then will quarantine the email

• Ignore: only available for anti-spam processing, EGS will ignore any issues with this