Summary

  • The IETF's 25 September update lists eight post-cutover defects it said were fixed, from confirmed senders sent to moderation to dropped bulk mail and DMARC delivery failures.
  • The still-open bounce problem exposed an old backlog. When new processing began disabling subscribers on possibly incorrect bounces, IETF turned it off and re-enabled disabled addresses pending a fix.

The congratulatory post came first. On 11 September, the IETF said its transition to new email infrastructure was complete. It described separate containerized functions for mail filtering and rewriting, Kubernetes scheduling, new spam software, improved certificate handling and better bounce processing. A page heading and introduction were updated to say “completed”; most technical detail beneath them remained the material published on 28 August.

That is a cutover record. It is not an operating report.

The operating report arrived on 25 September. IETF Executive Director Jay Daley said most transition problems had been resolved, then named eight that were fixed and two still being worked. He also disclosed that the project had been commissioned three years earlier, had suffered repeated issues, and was handed to a new contractor to finish. A core component from the earlier work remained; problems in it escaped detection before launch. “That was our mistake,” Daley wrote.

The defects were not one spectacular outage. They were small rules at the seams where mailing lists meet real senders. A confirmed address that posted to a list without subscribing was missing from the global allowlist, so the message went to moderation. Precedence: Bulk mail was discarded without notice, primarily affecting messages from IANA. BATV tags were mishandled. Uppercase addresses already confirmed were asked to confirm again. A set of rules for unusual senders had become unreachable. Some Outlook From names were parsed into two parts. Postorius notifications used a placeholder sender because the site-owner field was blank. DMARC rewriting failed for some deliveries when recipient count was involved.

The executive director reported those eight items fixed. The list is a useful count of named defects, not a measure of every failed message or affected participant. The update supplies no denominator for either.

The sharper problem sat in bounce processing. Under the old infrastructure's structural limitations, bounces had not reached the lists for processing. Addresses were therefore not disabled. That left a backlog of addresses described as no longer reachable but still subscribed. The new processing started working through it. List owners then received many notices that subscribers were being disabled for excess bounces.

At that point the machine had a queue and a verdict. It did not yet have a trustworthy verdict. IETF said there was evidence that some bounces were incorrect. Its response was to disable bounce processing and re-enable all addresses disabled by it until the issue was fixed. That temporarily gave delivery preference to a possibly dead address over an automation that might wrongly remove a live one. It was a concrete safety decision, not a claim that the backlog had disappeared.

The same update reports a second performance surprise: Mailman's default VERP mode reduced mail-processing times by four to five orders of magnitude, so VERP was disabled while it was investigated. The announcement does not give baseline times, a workload or an absolute delay. The new Rspamd filter was also still being tuned because excess spam was getting through.

The sequence matters. The September 11 launch note described improved bounce handling and fewer spam opportunities as intended results. The September 25 record shows why intention is cheap and operational evidence is expensive: bounce handling surfaced old work and dubious signals; spam assessment still needed tuning. New modular infrastructure did not erase old data debt or make its first verdicts reliable by declaration.

There is a useful lesson for any group whose work depends on shared lists. A completed migration is a dated event. Reliable posting is a repeated outcome across sender identity, moderation, list expansion, rewriting, authentication, bounce interpretation and recipient delivery. Each boundary can pass its own test while the message fails somewhere downstream.

The public account gives enough to see the control choice and not enough to quantify its cost. It does not say how many addresses were re-enabled, how many bounces proved false, how long bounce processing stayed disabled, what the VERP timing baseline was or when Rspamd tuning ended. Those figures would change the assessment of service recovery. Until then, the firm finding is narrower: IETF stopped subscriber removal when its bounce evidence was not dependable, and made the correction visible.

Sources