Automatically switching off bad proxies
The delivered share fell, soft failures piled up, the address is on a blacklist, the rent is running out — every hour the Hub calculates each address’s metrics and applies the first matching rule.
The action is to replace from the reserve, send to quarantine, recheck, retire or just notify. Every firing is written to the log.
01 / Who pulls an address
The MTA on the server sees the recipient’s answer right during sending and pulls the address itself — within seconds. Every hour the Hub’s rules look at the address’s messages over a period and decide what to do with it next. They don’t get in each other’s way: the MTA reacts to a single message, while the proxy rules react to how the address behaves over a day, a week or a month.
Reads the recipient’s answer right in the conversation, pulls the address from sending itself and lets it back on a timer. Nothing can react faster than the MTA, and the Hub doesn’t compete with it.
They decide what an address’s poor performance means: wait, replace from the reserve, recheck or retire. They look at messages over a period — from a day to a month — not at a single message.
Better not use hard bounces to retire an address for good: the MTA puts both “we were not let in” (that’s about the address) and “no such mailbox” (that’s about your list) into them. For this metric you need a high threshold on the number of messages.
02 / Rule order
Every hour the Hub checks the rules from top to bottom and applies the first one that matches. Pool rules come first, then common ones, and you change the order within a pool with the arrows right in the row.
A pool rule always goes before a common one; the other rules leave the address alone this time
Delivered share below 92% over a day — but only once 200 messages have gone out. This threshold keeps an address from being pulled over a couple of random failures.
The address is replaced with a spare from the pool’s reserve. The “Blacklisted” and “Pulled by the MTA” rules work the same way, and with soft failures above 12% the address goes to quarantine.
Delivered share below 88% over a day, from 500 messages. Over the week this rule fired once — it pulled px-06 on Oct 20.
The address goes to quarantine. Also in the pool: a breaking tunnel — recheck; less than 2 days of rent left — notify only; this rule warned about px-05 on Oct 21.
03 / Presets
You don’t have to set up automatic proxy switch-off from scratch: the “Careful”, “Normal” and “Hard” rule presets are turned on with one button. The block shows right away whether a pool’s rules actually match its label.
Quarantine at the first doubt, replace immediately. For live campaigns, where the domain matters more than any single address.
Default thresholds, quarantine for a cooling period. Good while you don’t yet know how the addresses behave.
Tolerate until the recipient clearly refuses. For expensive addresses and where there’s nothing to replace them with.
“Apply to the pool” rewrites the rules that came from presets and keeps your own — the confirmation dialog says so plainly. The pool’s label on the “Pools” page doesn’t change the rules.
04 / Test before switching on
You can run a rule against current data before you even save it. The form shows which addresses it would fire on — with the metric and the number of messages. And the safeguards against chance keep the rule from yanking an address back and forth.
The share is only counted once enough messages have gone out: without a threshold, two failures out of three messages would throw out a good address. After firing, the rule leaves the address alone for a while.
Over a week the rule would fire on px-05: 78.98% delivered of 2,250 messages. Over a day px-05 doesn’t reach 500 messages, and the current rule leaves it alone — you see this before you change anything.
An action is named for what it does: “Mark: metrics slipped”, not “slow down” — the Hub doesn’t change the sending speed on the fly, and the form says so.
05 / The interface in detail
All the proxy rules screens: who reacts to what, the list of rules, presets, the rule dialog and testing against history. Above each screenshot: why the screen matters. Below it: what it shows.
The page starts with who reacts to a bad address and how fast — the MTA on the server or the Hub’s rules. Below are the rules themselves, by pool and in the order the Hub applies them. Each row shows the condition, the action and when the rule last fired. So it’s clear which proxy was switched off automatically and why.
The tab’s first block explains who pulls a bad proxy and how fast. The MTA on the server sees the recipient’s answer right in the conversation and pulls the address itself — within seconds — and then lets it back on a timer. Every hour the Hub’s rules look at the address’s messages over a period — from a day to a month — and decide what to do next: wait, replace from the reserve, recheck or retire. At the bottom, in red, is why an address isn’t retired for good over hard bounces: the MTA puts both “we were not let in” and “no such mailbox” into them. At the top — the “Add a rule” button and a choice of which pool’s rules to show.
EnlargeThe Hub doesn’t compete with the MTA on speed: the MTA reacts to a single message, the rules to the address’s behavior over a period.
The rule list is the section’s main screen: eight rules of two pools, grouped and in the order the Hub applies them. The first matching rule from the top fires, and pool rules always come before common ones. A row shows the condition, the action and how many times the rule has fired, so it’s easy to see why a particular proxy was switched off. Over the week the rules fired twice: “Delivery rate dropped” pulled px-06 on Oct 20, and “Rental is running out” warned about px-05 on the 21st. You change the order within a pool with the arrows right in the row, and every firing goes both to the proxy’s card and to the shared log.
EnlargeThe log shows that the decision was made by the system, not by a person: “Delivery rate dropped” pulled px-06 on Oct 20, and “Rental is running out” warned about px-05 on the 21st.
Ready-made rule presets are turned on with one button — the fastest way to set up switching off bad proxies. The block shows which preset is selected now and says honestly whether the pool’s rules match its label. Your own rules stay in place when you apply a preset.
Three ready-made rule presets — “Careful”, “Normal” and “Hard” — with short descriptions of which kind of sending each one suits. The selected “Sending · marketing” pool has the “currently selected” tag: all four of its rules essentially match “Careful”. The “Apply to the pool” button replaces the rules in one click, but only those that came from presets — your own stay. The screen is handy for quickly choosing how strictly to pull proxies. A pool’s label can also be changed on the “Pools” page, but that doesn’t change the rules — which is why you check here whether the label and the rules match.
EnlargeA pool’s label can also be changed on the “Pools” page, but that doesn’t change the rules — here you see whether they actually match.
Each rule opens in a dialog: on the left — when it fires, on the right — what it does. Here you can also test the rule against history without saving anything. A new rule only notifies by default — a strong action is chosen deliberately.
The dialog of the “Delivery rate dropped” rule of the “Ramping up new addresses” pool — this is where you set when a proxy is pulled automatically. On the left — when the rule fires: delivered share below 88% over a day, but not before 500 messages have gone out. On the right — what it does: sends the address to quarantine, no more than once every 6 hours per address. Hints under the fields explain how messages are counted, why the threshold is needed and how cooling works. The rule list flags a message threshold that’s too low right in the row. Before saving changes, you run the rule with the “Test against history” button — the result is shown on the next screen.
EnlargeThe rule list flags a message threshold that’s too low right in the row.
The same rule, but with the period set to “a week” and after clicking “Test against history”. The test lets you see the consequences of a change before the rule starts pulling addresses. An answer appeared under the form: the rule would fire on one address of two — px-05, which has 78.98% delivered of 2,250 messages. It also shows why the current rule leaves it alone: over a day px-05 doesn’t reach 500 messages. The “Save” button wasn’t clicked. The test doesn’t take the order or cooling into account: a rule placed higher could have taken the address. If you’re happy with the result, save the rule; if not, change the threshold or period and test again.
EnlargeThe test doesn’t take the order or cooling into account: a rule placed higher could have taken the address.
The “Add a rule” dialog — this is what a new rule looks like before any edits. By default: delivered share below 90% over a day at 300 messages, no more than once every 6 hours per address. The default action is “notify only”: a new rule pulls nothing until you choose a strong action yourself. The pool is filled in from the selection at the top of the page, and you set the name. Before saving, it’s worth running the rule with the “Test against history” button. On the left — when the rule fires, on the right — what it does, just like in the dialog of an existing rule. Hints under the fields remind you about the volume threshold and the cooling period.
EnlargeThe “Name” field is empty — you set it yourself.
06 / Questions about rules
In short: how the Hub picks a rule, why it needs a threshold, and what happens after a rule fires.
EnlargeOn the left — when the rule fires, on the right — what it does. Hints under the fields explain the threshold and cooling.
The Hub checks the rules from top to bottom and runs the first matching one. Pool rules come before common ones, and you change the order within a pool with the arrows in the row.
The MTA pulls an address within seconds based on the answer to a single message and lets it back on a timer. The rules look at messages over a period every hour and decide what to do with the address next.
Without one, two failures out of three messages would throw out a good address — and that happens on any new proxy in its first hour. The share is only counted once enough messages have gone out.
After firing, the rule leaves the same address alone for a while, for example 6 hours. This protects against seesawing — even if a person brought the address back by hand.
Better not: the MTA puts both “we were not let in” and “no such mailbox” into them. If you need a rule on them, set a high threshold on the number of messages.
It rewrites the rules that came from presets and keeps your own. The confirmation dialog says so plainly.
No. That’s why the action is called “Mark: metrics slipped”, not “slow down” — and the form says so.
In the rule’s row, on the proxy’s card and in the module’s log. You can see that the decision was made by the system, not by a person.
07 / Next step
Rules decide what to do with an address. The mail itself is routed through the proxies by the gate — a service on the sending server — and its status is the next thing worth checking.
Where the rules apply is set in pools, and the whole route — from the MTA through the gate to the recipient — is shown in the module overview.
