Summary

  • During the IETF’s September 2026 email migration, a global moderation allowlist left out confirmed addresses that were not subscribed to any list. Their posts were held for moderation.
  • The failure joined two separate states: a sender had confirmed an address for posting; a subscriber had asked to receive a particular list. The IETF says it fixed the allowlist to include every confirmed address.

The IETF’s mail gate had a guest list. It rebuilt that list from the seating chart.

On 25 September, IETF Executive Director Jay Daley described a migration defect with an unusually tidy explanation. The global allowlist used for mailing-list moderation did not include email addresses that had already been confirmed but were not subscribed to any mailing list. Send a post from one of those addresses and the list held it for moderation. The fix was to build the allowlist from all confirmed addresses again.

The mistake sits in a small but consequential distinction. Confirmation says an address passed the challenge sent to its owner. Subscription says that address wants to receive one list’s traffic. A person can confirm an address for posting without signing up to receive hundreds of messages from the list. One is an identity check at the mail gate; the other is an inbox preference. The migration made the second field stand in for the first.

That is why this was more than a fussy Mailman setting. IETF says it operates more than 500 mailing lists and that most of its work happens on them. Its own mailing-list guidance says a new address must complete challenge-response when subscribing or posting for the first time. The transition announcement spells out why: that first challenge is how a participant confirms agreement to the Note Well policies and procedures. A system that forgets the result has forgotten the evidence that opened the door.

How a confirmed address got sent to moderation

Before the migration, the mail system had a global record of addresses that had answered a challenge. In the new architecture, a component checked whether a sender was already approved. If a new address needed confirmation, the system stored the original message while it waited for the sender’s response; after a valid response, it released the message and recorded approval for later posts.

The failure happened while reconstructing the global moderation allowlist. Confirmed addresses that did not appear as subscribers to any list fell out of the set. A list then saw a sender missing from its expected moderation table and held the message. The official update describes the symptom and the repair.

The system-level defect is plain: a mailing-list subscription is a poor proxy for proof that an address passed the posting challenge.

A migration with more than one bad assumption

Daley’s update listed eight issues fixed by 25 September and two still being worked on. The allowlist was one. Messages marked Precedence: Bulk had been discarded without notice, primarily affecting IANA mail. Some BATV-tagged posts appeared to come from an IETF relay address. Confirmed addresses containing uppercase letters were asked to verify again. Compatibility rules for unusual sender formats could not run because their expressions were unreachable. A parsing error affected some Outlook-style addresses. Postorius notifications used a blank site-owner field. DMARC rewriting also failed for some recipient-count conditions, preventing delivery to recipients.

The two open items concerned bounce handling and spam. A backlog of dead addresses remained subscribed to lists; new bounce processing began disabling accounts, and some of its results looked wrong. The operator paused that processing and re-enabled the disabled addresses while the logic was investigated. Variable Envelope Return Path (VERP), a standard Mailman technique for identifying which subscriber’s message bounced, had made mail processing four to five orders of magnitude slower in this setup, so it too was disabled during investigation. Rspamd was still being tuned after excess spam got through.

The chronology points to a release-control failure with a specific handoff. The email platform had been commissioned three years earlier. After repeated problems, a new contractor was asked to finish it. Daley said the new work left a core component from the earlier project untouched, and that its defects escaped detection before launch. “That was our mistake,” he wrote. It is unusually useful incident reporting: the operator named the inherited component, the missed pre-launch check and the work still open.

The list is part of the standards process

IETF mailing lists are infrastructure for deliberation. RFC 2418 says working groups conduct much of their business through email distribution lists. It calls email a route to wider participation than in-person meetings and says a working group must keep its process open to email-only contributors. The list archive is public by design. RFC 6778 sets requirements for archiving and web-based browsing and search.

That arrangement makes the difference between receiving a list and posting to it important. The first affects what arrives in an inbox. The second determines whether a contribution enters the discussion channel. IETF’s mailing-list page says most lists permit anyone to subscribe and post, while some lists have additional controls. Its system still needs anti-spam checks and address verification; open participation does not ask the mail server to accept every forged sender. It asks the server to remember the result when a legitimate sender completes the check.

The incident record is concrete: confirmed senders’ posts went to moderation and needed an operator to release them. The notice gives no sender or message count and no moderation-delay duration; those records would show whether the disruption was a handful of posts or a wider interruption. The gate confused an inbox choice with a posting record, and the sender waited for a human to unwind the mix-up.

What a clean fix needs to preserve

Daley says the allowlist is again built from every confirmed address. That restores the missing relationship in the mail system. The migration notice says archive and IMAP access remained available during the planned cutover. The repair returns each confirmed address to the state the list gate consults.

The wider lesson is about migration evidence. A mail service can have separate records for address confirmation, list subscription, moderation, bounce status, sender rewriting, and archive delivery. Each answers a different question. Combining them simplifies a database job and lets an incomplete export undo the state held by another.

For IETF, the check should be concrete: preserve the set of confirmed posting addresses independently from list membership; test a confirmed non-subscriber posting to an open list; test one restricted list separately; and reconcile moderation, delivery and archive records after cutover. Those tests would have caught the exact row that disappeared. Testing only active subscribers would have reproduced the blind spot with great efficiency.

The email migration did not make mailing lists less central to IETF work. It made their plumbing visible. More than 500 lists carry technical debate, process announcements and records that outlast a meeting. A challenge-response gate can protect that system from forged senders while still letting a confirmed participant speak. The distinction fits in one row of data. The IETF had the row; its new mailroom temporarily lost the filing cabinet.

Sources