Summary

  • On 25 September the IETF Executive Director said bounce processing had been disabled and all addresses disabled during the mail transition had been re-enabled pending a fix.
  • The same notice identifies both an older backlog of unreachable subscribed addresses and evidence that some new bounce notifications are incorrect. Neither condition cancels the other.
  • The IETF has not published an affected-address count, a date for restarting bounce processing or a finding that every restored address is reachable.

List owners had been seeing notices that subscribers were disabled for excessive bounces. In the Executive Director's 25 September account, those notices became a reason to stop the mechanism itself. Bounce processing was disabled, and every address that had been disabled was enabled again while the problem is investigated. This is a change to a participant's delivery status, not simply another item on a mail-system defect list.

The decision sits between two real errors. Under the previous infrastructure, bounces did not reach list processing, the IETF says, leaving addresses subscribed even though they were no longer reachable. Processing that backlog is legitimate housekeeping. But the new path produced some apparently incorrect bounce notifications. If those signals cause automatic suspension, a working address can lose list mail. Restoring all disabled addresses avoids continuing that particular decision on disputed evidence; it does not establish that every restored mailbox works, or that no legitimate bounce remains to resolve.

The chronology matters. An IETF post marked the new modular infrastructure complete on 11 September and described improved bounce handling as an intended result. The later incident notice takes precedence for present status: bounce processing is off while two issues remain under work, the other being excess spam. The Executive Director also listed eight fixed problems, including silent dropping of some Precedence: Bulk messages and defects affecting sender treatment. Those are distinct symptoms, not proof that a particular subscriber missed a particular message. The notice describes VERP as disabled too; its sentence about processing-time magnitude is ambiguous, so it cannot support a confident performance claim.

The IETF says most of its work takes place on more than 500 mailing lists. A delivery-disablement decision therefore has an institutional consequence even when it begins as an operational hygiene rule. A list owner can receive a notice; a participant may retain a subscription record while delivery is off. GNU Mailman's upstream documentation describes this general distinction between bounce events, suspended delivery and later warnings. It does not reveal the IETF's actual thresholds or prove what happened to any address here.

Before the automatic control resumes, the useful public question is narrower than “is email fixed?” Which class of bounce is trustworthy enough to change delivery status, how are suspect notices separated from an old backlog, and how can an affected subscriber or list owner seek correction? A bounded decision record could describe classes, timing, review and reversal without publishing addresses, bounce traces or security controls. That is Daniel Kade's proposed accountability test, not an IETF-announced remedy. The IETF may hold internal evidence not visible in its notice; this report does not infer that it lacks one.

Sources