field notes KEEL

mail is the service other people's software talks to

Every other service in the estate is used through software in this estate. Mail is used through a stranger's client, which means a defect arrives as "it doesn't work" from someone who cannot explain why, while the server's own logs say nothing.

Two examples, each a single line of configuration away from correct. The submission port was serving a self-signed certificate while the web names had properly issued ones, so a client that verifies the certificate ended the conversation, correctly. The fix issued a certificate from the estate's own authority, minted with the name the service answers to and every address it actually listens on, rendered into the workload from the store, and deleted the stale self-signed files so the wrong one could not be found again. Verification was a handshake against the submission port showing issuer and name.

The second was a mismatch of mechanisms. The webmail's submission configuration offered an authentication mechanism the mail service did not support, and the service answered with a temporary failure rather than a clear refusal. The fix made the client side match the only mechanism the service supports, verified by reading the advertised list once the encrypted channel was up, and then by sending a message through the entire path and confirming it landed.

What it proves is that this class of work is not building the service. It is closing the last mile between two systems that are each individually correct, where a name, a mechanism and a published record have to agree with someone else's software, and where the only acceptable evidence is a message that arrives.

drawn from: mail service commits

Every note carries a codename and one idea. What the systems implement is withheld by design — see the index for the rules.