Proxy event history with the author of every decision
An address dropped out of sending — why? The log answers with one column on the right: who decided — the MTA, a rule, a person or the Hub itself.
Everything else that changes the fleet is here too: import and acceptance, blacklists, quarantine, gate table writes, rent, DNS.
01 / The record’s author
If an address dropped out of sending, the key thing is to understand who decided it. That determines whether the address comes back on its own, through a rule’s action, or only by hand. That’s why every record in the proxy log has its author on the right: the MTA, a rule, a person or the system.
An address dropped out of sending — the column on the right says who decided and how the address comes back
Once an hour the Hub asks PowerMTA which addresses it has pulled and records the pull in the MTA’s name. When the MTA lets the address through again, a return record appears.
From there everything follows the rule’s action: an address in quarantine is brought back by a check after the term — into the pool’s reserve — while one retired for good doesn’t come back. An address pulled by a person waits until someone brings it back by hand.
02 / The week’s events
Besides pulls, the log keeps everything that changes your proxy fleet: rule firings, blacklists, grade changes, gate table writes, import and acceptance. Here’s the week from the example — one record per card.
px-05: one day of rent left — notification only.
The check round found px-06 on SpamCop, Barracuda and PSBL.
“Delivery rate dropped” sent px-06 to quarantine at 82.02%.
The Hub rewrote the gate table on mta-02 right away — two addresses are left in it.
A recheck found port 25 closed on px-06.
A person imported px-09, and acceptance rejected it at the “port 25” step.
Repeats fold into one row: if the MTA keeps an address pulled for hours, the log shows the pull as one row with a counter — “repeats: 2 · since 01:40”.
03 / Filters
You filter the proxy log by author, event group, address and pool, and the period follows the panel’s calendar. The export repeats what’s on screen.
All, person, rule, MTA, system — and you see in advance how many rows will remain.
Pulls and swaps, quarantine, checks, collection and import, blacklists, DNS, gates, rent.
“1 day” is since midnight in the panel’s time, “7 days” is seven days including today.
The same filters and columns plus a server column; times are in your profile’s time zone.
“Only what changed the state” hides informational records, and the search looks at the address, the proxy name and the event text.
04 / How records are written
Log records are created by the Hub itself — exactly when something happens. That’s why you can trust the log: there’s no after-the-fact retelling in it.
For a rule — when it fires; for a check — when it changes the grade or finds the address on blacklists; for the MTA — during the hourly poll; for a person — when they click a button.
A record’s text isn’t stored as a ready-made phrase — it’s assembled in the language of whoever reads it. When an address is deleted, its records go with it — one remains, about the deletion itself.
05 / The interface in detail
All the proxy log screens: filters, the week’s events, the MTA’s decisions and a month of blacklists. Above each screenshot: why the screen matters. Below it: what it shows.
At the top is everything you filter the proxy log by: period, search, author buttons with record counts, event kind, proxy, pool and “only what changed the state”. The filters help you quickly find the history of one address or all the decisions of one author. The CSV export repeats what’s on screen.
The proxy log filter panel: this is where you start when you need to find out what happened to a specific address. At the top are the module tabs and the period: 1 day, 7 or 30 days. Below them — a search by address, proxy name and event text, and author buttons with the number of records for the period. Further down — event kind, proxy, pool and the “only what changed the state” tick box; “Reset” clears all filters at once. The numbers on the buttons show in advance how many rows will remain. For example, the “MTA” button leaves only pulls and returns from the sending server, and the “blacklists” group leaves records about getting listed; both selections are shown below.
EnlargeThe numbers on the author buttons take the other filters into account — you see in advance how many rows will remain.
Below are the events themselves, by day, newest first. On the right of each record are the pool, the proxy with its external address, and the author. The author’s label tells you right away whether the address will come back on its own or has to be brought back by hand. Three screens show the whole week, the decisions of one MTA, and a month of blacklists.
A week of proxy event history: ten records by day, newest first. On the right of each — the pool, the proxy with its external address, and the author. The screen lets you trace an address’s story: for example, yesterday px-06 landed on blacklists, a rule sent it to quarantine, the gate on mta-02 got a new table right away, and in the evening the grade dropped from C to D. At the top is the “Export CSV” button; at the bottom — how many records are shown and how many rows are on screen. Repeats fold into one row: the MTA’s two records about pulling px-04 sit in a single row, so there are 10 records but 9 rows on screen. The CSV exports the same as on screen, plus a server column.
Enlarge“Showing 10 of 10 · 9 rows on screen: repeats folded” — the MTA’s two pull records sit in a single row.
The proxy log with the “MTA” button on — only the decisions of the sending server itself. Three records remain: the pull of px-04 for gmail.com, its repeat and the return. The repeat is folded with the pull into one row — “repeats: 2 · since 01:40” — so a long pull doesn’t clog the log. By the 04:40 poll the address was no longer in the report, and the pull closed by itself. The takeaway: an address pulled by the MTA needs no intervention — it comes back on the MTA’s timer. PowerMTA 6.0 doesn’t give the reason in its report — and the log says exactly that rather than making one up. The “Ramping up new addresses” pool has no “pulled by the MTA” rule, so the address stayed in sending.
EnlargeThe “Ramping up new addresses” pool has no “pulled by the MTA” rule, so the address stayed in sending.
The proxy log filtered by the “blacklists” group over 30 days. Two system records: px-06 yesterday and px-05 on Oct 16, both on SpamCop, Barracuda and PSBL. Blacklists are checked once a day, during the check round, which is why both records are at 04:10. Such a record is informational, with no color: what matters is its consequence — the address’s grade drops to C, and that shows up in “Needs attention”. The author buttons count with the same filter. For px-05 the B → C drop is listed there with the reason “listed on blacklists”, while px-06 was already at C. What to do next with such addresses is decided by the pool’s rules, for example “Blacklisted”.
EnlargeSuch a record is informational, with no color: what matters is its consequence. Getting listed lowers the grade to C, and for px-05 the B → C drop is listed in “Needs attention”.
06 / Questions about the log
In short: how to use the log to understand why an address dropped out of sending and whether it will come back.
EnlargeThe “MTA” button: the pull of px-04 for gmail.com, its repeat in one row, and the return.
Find it in the log and look at the column on the right: the MTA, a rule, a person or the system. How the address comes back depends on the author.
Yes, on the MTA’s timer. Once an hour the Hub asks PowerMTA about pulled addresses, and when an address is let through again, a return record appears in the log.
PowerMTA 6.0 doesn’t give the reason for a pull in its report. The log says exactly that rather than making up a reason.
While the MTA keeps an address pulled, each poll records the pull again. The log folds such records into one row with a counter and the time of the first record.
Yes: after the term a check brings it back — into the pool’s reserve. One retired for good won’t come back, and one pulled by a person waits until someone brings it back by hand.
It’s informational; what matters is its consequence: getting listed lowers the grade to C, and that drop is listed in “Needs attention”.
The same as on screen: the same filters and columns plus a server column. Times are in your profile’s time zone, and the zone is named in the column header.
They’re deleted together with the address. One record remains — about the deletion itself.
07 / Next step
The log tells you who decided what. To make fewer decisions by hand, set up pool rules — then the log will show that an address was pulled by a rule, not by a person.
The module overview shows the whole route — from the MTA through the gate to the recipient — and leads to any Proxy Gate tab.
