PROBLEM
What happens to ATP configurations when upgrading to ESG 5.6, and how do I rebuild the setup I had in 5.5?
SOLUTION
What changed, and why a migration is needed
In 5.5 every outbound limit was written by hand, policy by policy. In 5.6 the appliance also classifies senders on its own, based on the traffic they actually produce, and assigns them to a quota level. The rules you write yourself did not disappear: they moved to the Quotas Override section, where they keep precedence over anything the engine decides.
Because the two models describe limits in different ways, the custom message quotas of 5.5 cannot be converted automatically. Everything else is carried over. During the upgrade access control policies, groups and their members are migrated, and a migration report is generated. The report is accessible to admins, holds the legacy ATP configuration and is the reference you rebuild the rest from.
After the upgrade the state of the ATP module depends on what you had before. It stays enabled if access control policies were already configured, and stays disabled if none were set up. In both cases the administrator should go through the module and configure it.
Cloud appliances
On cloud appliances the migration is handled by our team. We go through the existing configuration, decide together with you which policies are still needed and which ones can be replaced by the automatic engine, and rebuild them after the upgrade. You do not have to recreate anything by hand, and we contact you whenever a policy needs a decision on your side.
On premise appliances
On premise the upgrade procedure carries over groups, members and access control policies only. The quota policies have to be recreated by the administrator, following the steps below and using the migration report as the reference.
Before starting, take a snapshot of the appliance, or of every node if you run a cluster, and keep a copy of the current Policies, Policy Groups and Message Quotas pages. If the upgrade is already done and you cannot find the migration report, open a ticket on the support portal with the appliance details and we will extract it for you.
Migrating from the report
Outbound policies
The upgrade introduces an automated system for outgoing mail, which classifies members into quota levels based on their traffic volume. Quota levels are configurable in the Quota tab and are relay based.
- Default configuration Senders are automatically assigned to the appropriate quota level, and their quotas follow their traffic over time.
- Exception configuration Senders such as newsletters, informational mail or manual exceptions require manual migration. These must be associated with a quota level in the Quotas Member section.
For example, a company sends a weekly newsletter to 10,000 recipients. This is a custom traffic pattern with a high volume, so it needs an exception. The administrator can set the massive quota level to 10,000 messages and assign the sender address of the newsletter in the Quotas Member tab.
Other policies
Policies that the automatic system does not cover, such as inbound policies or custom ones, are migrated through the Quotas Override section, using the legacy configuration from the migration report as the reference. There you can:
- define a quota with a priority value, where a lower value takes precedence;
- set a tracker, the time period and the limits, such as message count or message size;
- specify the verdict, for example defer, reject or delete;
- mark the rule as last, so that no further policy is applied after it.
Source and destination decide which traffic the rule applies to, and groups can be used on both sides.
For example, a department receives high volumes of large attachments. A quota override is created to allow 50MB per hour during business hours for all recipients.
Final steps
Once everything is migrated, enable the Policy Quota Module if it was disabled, enable Automatic Quotas and apply all pending changes. The system then generates configurations for all previously unmanaged members.
The Automatic Quota feature needs at least 14 days of message history to populate members accurately, so it does not populate quota members on newly created appliances.
Getting back to the behaviour you had in 5.5
The steps above lead to a setup where the automatic engine handles everyone except the exceptions you defined. If instead you want your own limits to be the only ones that apply, exactly as in 5.5, there is one more thing to do.
Quota decisions are taken by four levels, evaluated in order of priority, where each level is only reached when the one above it did not match.
The automatic quota levels are the base layer of this chain. The Automatic Quotas flag decides whether senders are promoted and demoted between levels, but it does not remove that base layer, so traffic that matches none of your Quotas Override rules still reaches it and is evaluated there. Recreating your policies is therefore not enough on its own.
The way to close the chain is a final rule under Quotas Override that matches everything left and carries a limit that can never be reached. The rule blocks nothing. Its only job is to stop traffic from falling through to the automatic levels.
| Field | Value |
| Name | a name that says what the rule is for, for example CatchAll |
| Priority | 99, so the rule is last and no further policy is applied after it |
| Tracker | Sender user@domain |
| Period | 60 minutes |
| Message count | 999999 |
| Verdict | Defer |
| Source | default |
| Destination | default |
Source and destination set to default are what make the rule match every message. The message count is deliberately out of reach, so pick a value no sender can hit in the period you set, and raise it if your traffic grows by a large factor. Remember to apply pending changes.
Afterwards, check the Quota Tracking page: traffic should match your real rules first, and only what you meant to leave alone should appear against the catch all rule. If a sender you wanted to limit shows up there, the rule that was supposed to catch it is not matching, and its source and destination need to be reviewed.
If you later decide to use the automatic quota levels, delete the rule. Your manual rules keep their precedence and everything else goes back to the engine.
An improvement is planned that will make the Automatic Quotas flag effective on its own. Once it is released this rule will no longer be needed.
For the settings of the automatic quota engine, see Automatic Quota in the Policy article.