Mailbox reconnect: controlled state checks and recovery study protocol

Observed controlled-test findings — 16 September 2026

A synthetic SMTP reconnect preserved identity and counters; provider outage recovery still needs an owned-mailbox study.

These are database/service checks. They do not open an SMTP or IMAP provider session, exercise OAuth expiry, reset UIDVALIDITY, measure downtime recovery or establish that replies sent during an outage are recovered.

1. TestSMTPReconnectPreservesIdentityAndCounters retained the account ID, total_sent=7 and daily_limit=15 when IMAP settings were supplied during reconnect.
2. The same test kept a mailbox without IMAP settings from being marked configured and rejected a reconnect through the other workspace in its fixture.
3. TestInboundWorkflowCommittedOnce processed the same synthetic inbound message twice: the configured workflow ran once and its unsubscribed status was not overwritten.

Define the decision

A limited controlled software investigation was completed on 16 September 2026 against implementation e77303e. Its observations are reported below. The broader field-study protocol remains unperformed; software fixtures are not campaign or participant data. The decision is: Does reconnecting an owned mailbox recover access without losing or duplicating inbox events? The observation unit is one disconnect/reconnect scenario for a controlled mailbox. Define the population and owner before collecting records; do not substitute an available convenience dataset without documenting the change.

Work through the procedure

1. Record provider, auth mechanism, checkpoint state, known message IDs, expected reply counts and token revocation time.
2. Test expiry, revoked consent and interrupted reconnect separately. Send controlled replies before, during and after the outage.
3. Before collection, write the primary outcome, observation window, exclusion rules and stopping conditions. Preserve excluded observations with a reason rather than quietly removing them.
4. Pilot the procedure with fictional or owned test data, resolve ambiguous fields, and freeze a dated protocol version before the main run.

Worked example

The following is a synthetic example for this procedure, not a customer result or performance benchmark.

known messages M1 before and M2 during outage; after reconnect expect each once; inspect both missing and repeated events
Suggested record fields: observation_id, condition, evidence_reference, outcome, exclusion_reason, reviewer, protocol_version
Status: illustrative record only; this example is not an observed result. See the separate controlled findings above.

Read the result

Report recovery latency and reconciliation completeness per scenario. A successful connection banner does not establish inbox recovery. Keep the numerator, denominator and missing evidence visible. If the available observations cannot answer the registered question, report that limitation rather than selecting a more favorable metric after collection.

Collect the evidence

Observation unit: mailbox-recovery-scenario.

Owned dedicated mailboxes plus message IDs before, during and after a deliberate outage.

Separate token expiry, revocation and interrupted reconnect; keep provider and retention window visible.

Analysis: Recovery completeness and duplicate events per scenario, plus latency where actually observed.

Download the JSON collection template under Source references. Set an owner, eligibility rules, outcome definition, observation window and sample justification before collecting records. Templates contain no participant data or results; keep original private records outside the public website.

Check before moving on

1. Name the person responsible for collection and review.
2. Check that the evidence can be inspected without exposing private messages or credentials.
3. Record deviations from the protocol and analyze their possible effect.
4. Retain a dated, redacted evidence worksheet with the final interpretation.

Limits and next action

Use dedicated test credentials. Provider-specific behavior and retention windows limit how far results generalize. Publish results only after the evidence, method and limitations have been reviewed. This protocol provides no benchmark, expected lift or completed field-study claim.

Source: Method or workflow reference