List sunsetting

People who never open your mail are the single biggest reason good mail lands in spam. Mailbox providers watch how recipients react far more closely than they watch your content, so a list with a long tail of silent addresses drags down delivery for everyone else on it — including the people who do want to hear from you. Worse, addresses that have been silent for a year are exactly the ones that get recycled into spam traps.

Owlat handles this for you. It is on out of the box at conservative thresholds, because a hygiene feature nobody switches on protects nobody.

What happens, and when

The clock starts from the last time a contact did something. Two thresholds:

Both numbers are configurable. Neither one deletes anything.

What counts as "not quiet"

Anything that shows a person is still there resets the clock:

• opening or clicking one of your emails
• replying to you, or writing to you unprompted
• subscribing to a topic, confirming a double opt-in, or being marked as confirmed by an import

A contact who ignored a year of newsletters and then fills in your signup form today is not quiet. The clock restarts that day.

What it will never do

These are guarantees, not defaults:

• It never deletes anything. A suppression is a reversible state with a reason and a timestamp. The contact, their history and their topic memberships are untouched.
• It never suppresses a contact who has no history. A contact you have never actually mailed cannot be "unengaged" — there was no chance to engage. Absence of history is absence of measurement, not evidence.
• It never suppresses a new contact. A contact must have existed, and have been receiving mail, for longer than the window being applied.
• It never acts on a bad clock. If the server's clock disagrees with what Owlat has recorded, the sweep holds rather than guessing — and the hold does not clear itself. Nothing is suppressed until a person confirms the clock. See When the sweep holds on the clock.
• It never runs away. One sweep can auto-suppress at most a bounded number of contacts. If something systemic ever went wrong, it stops, records what it refused to do, and waits for the next pass.
• It never blocks transactional mail. See below — this one matters.

Transactional mail keeps flowing

A sunset suppression is a decision about marketing mail only. Receipts, password resets, and double-opt-in confirmations are unaffected: a customer who ignores your newsletter has not asked to stop receiving the receipt for the thing they just bought.

Suppressions from a hard bounce or a spam complaint are different — those are evidence about the mailbox itself, and they block everything.

Tuning it per topic

The policy is stored per topic, plus one deployment-wide row.

• The deployment-wide setting applies to every contact.
• Each topic can override the windows, or turn sunsetting off entirely for its members.

When a contact belongs to several topics, the most lenient policy wins: the longest window applies, and if any applicable topic has sunsetting switched off, the contact is not sunset. Two conflicting operator intentions resolve towards "don't suppress".

Turning it off deployment-wide turns it off everywhere, whatever the topics say. Clearing a topic override returns that topic to the deployment-wide value.

The shortest window you can configure is 30 days, and the suppression window must be at least as long as the re-engagement window.

Exempting one contact

If you know something Owlat does not — a contact who buys every year by phone, an address that matters for a reason no click will ever show — set the per-contact exemption. An exempt contact is never sunset, at any age, until you clear the exemption.

Putting a contact back

There are two ways back, and they differ in one important respect.

Audience > Suppressions > Remove deletes the suppression row and nothing else. It works for every reason, including a bounce or a complaint. Because it does not set the exemption, a contact who is still quiet can be sunset again by a later sweep.

The Restore action in Audience > Suppressions calls contacts/sunset:restoreSunsetContact (contacts:manage). It is the sunset engine's own restore, and it is the one that sticks. In one action it:

1. removes the suppression — but only if the engine wrote it, so bounce and complaint evidence is never erased,
2. puts the contact back on the normal track, and
3. sets the per-contact exemption, so the next sweep does not immediately suppress them again.

It is recorded as contact.sunset_restored.

When the sweep holds on the clock

A clock cannot check itself, so before each pass the sweep compares the server's current time against the timestamps Owlat wrote on earlier passes. If "now" is implausibly far ahead of them — more than 30 days — the sweep evaluates nothing and records why.

This hold does not clear itself. The sweep is the only thing that writes those timestamps, so a deployment that was switched off for longer than a month looks exactly like a clock that jumped forward, and no later pass can tell the difference on its own. Sunsetting stays off until a person says the clock is fine. That is deliberate: pausing is always safe, and quietly suppressing a year's worth of contacts because a VM was restored from a snapshot is not.

You will see it two ways. On Audience > Suppressions a banner reading "Automatic sunsetting is paused" appears for as long as the hold lasts, and it is the only time that banner is shown — a healthy deployment sees nothing. It is also written to the audit log as a contact.sunset_sweep_summary entry that suppressed nothing and explains the hold, at most once a day for as long as the condition lasts, so a permanent stall cannot bury the rest of the log.

To start it again: check the machine's system clock first (NTP). Once you are satisfied it is correct — including in the ordinary case where the clock was never wrong and the deployment was simply paused — press Confirm clock on that banner. Anyone with the contacts:manage permission can do this; the underlying mutation is contacts/sunset:confirmSunsetClock if you would rather run it directly. The confirmation is recorded as contact.sunset_clock_confirmed, and becomes the second observation the next pass compares against, so sweeps resume on the following hourly tick.

The audit trail

Every automatic move is recorded in Settings > Audit log, including the ones that only flag a contact:

Every suppression entry names the reason and carries the numbers the decision was made from, so "why did this address stop receiving mail" always has an answer.