Search Blue Canoe

Enter at least two characters.

Operating Blue Canoe · 2 of 3

The Other Mail Server Has to Prove It Too

What controlled delivery rehearsals established on Blue Canoe's two mailbox nodes, and what they did not.

Two matching servers with separate blue network cables and inspection clipboards on a workbench.

Two servers with similar configuration are not yet evidence of two servers with the same behaviour.

The distinction matters when one is normally doing the visible work and the other is expected to be ready when needed. A quiet secondary can look reassuring precisely because it is not being asked the same questions.

Our mail work therefore included controlled delivery rehearsals on both mailbox nodes. The useful result was not that the files looked alike. It was that specific delivery paths had been exercised and their outcomes recorded.

Ordinary delivery is the starting point

Mail that arrives normally is important, but it is only one case.

We also needed evidence for plus-addressing, spam handling, permanent rejection, temporary deferral and recovery. Those paths have different meanings. A message deliberately rejected is not the same thing as a message accepted and then lost. A temporary failure should not be described as permanent simply because the first attempt did not finish.

The rehearsals proceeded through the secondary and then the primary. Each result belonged to a particular test, with a defined expected outcome and a controlled return to the ordinary delivery path.

Recovery is part of the result

On 14 September, the completion record brought together the remaining primary-node outcomes, including a controlled temporary deferral and recovery, rollback and the restored LMTP delivery control.

LMTP is the delivery path into the mailbox service. Testing through that restored path mattered because a successful temporary arrangement is not evidence that we have put normal operation back correctly.

The final checks recorded active mail services, empty queues and healthy replication. The temporary-deferral and LMTP control messages each existed once on the primary and once on the replicated secondary. The LMTP control had no unwanted Junk copy.

Those are dated observations from that rehearsal, not a statement about today's queues or every message the platform will ever handle.

The evidence had an untidy edge

One successful temporary-deferral test retained a stale diagnostic label from an earlier case.

The record preserves that discrepancy. Its functional outcome was accepted, and the completed operation was not repeated merely to produce a tidier-looking label.

That is a useful operational discipline. If an explanation is wrong but the underlying outcome is independently established, preserve both facts. Repeating a consequential test solely to improve the presentation can introduce risk without answering a new question.

Know the size of the claim

This work established the recorded delivery behaviours on both nodes. It did not prove every possible failover scenario, every network failure or every future configuration change.

It did give us something more useful than confidence borrowed from matching files: evidence that the other server had faced the same kinds of delivery questions, followed by checks that the test machinery had been removed and the ordinary path restored.

A second server is a component. Knowing what it will do requires work of its own.