Re: Complaint v2 to IESG regarding censorship of dissent

"D. J. Bernstein" <djb@cr.yp.to> Tue, 25 November 2025 07:27 UTC

Return-Path: <djb-dsn2-1406711340.7506@cr.yp.to>
X-Original-To: ietf@mail2.ietf.org
Delivered-To: ietf@mail2.ietf.org
Received: from localhost (localhost [127.0.0.1]) by mail2.ietf.org (Postfix) with ESMTP id E368E900A54C for <ietf@mail2.ietf.org>; Mon, 24 Nov 2025 23:27:45 -0800 (PST)
X-Virus-Scanned: amavisd-new at ietf.org
X-Spam-Flag: NO
X-Spam-Score: -4.197
X-Spam-Level:
X-Spam-Status: No, score=-4.197 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, RCVD_IN_VALIDITY_RPBL_BLOCKED=0.001, RCVD_IN_VALIDITY_SAFE_BLOCKED=0.001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, UNPARSEABLE_RELAY=0.001] autolearn=ham autolearn_force=no
Received: from mail2.ietf.org ([166.84.6.31]) by localhost (mail2.ietf.org [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 7lDpoiKn80mq for <ietf@mail2.ietf.org>; Mon, 24 Nov 2025 23:27:45 -0800 (PST)
Received: from salsa.cs.uic.edu (salsa.cs.uic.edu [131.193.32.108]) by mail2.ietf.org (Postfix) with SMTP id 47F12900A538 for <ietf@ietf.org>; Mon, 24 Nov 2025 23:27:45 -0800 (PST)
Received: (qmail 3763884 invoked by uid 1010); 25 Nov 2025 07:27:44 -0000
Received: from unknown (unknown) by unknown with QMTP; 25 Nov 2025 07:27:44 -0000
Received: (qmail 271170 invoked by uid 1000); 25 Nov 2025 07:27:32 -0000
Date: Tue, 25 Nov 2025 07:27:32 -0000
Message-ID: <20251125072732.271168.qmail@cr.yp.to>
From: "D. J. Bernstein" <djb@cr.yp.to>
To: iesg@ietf.org, ietf@ietf.org, postmaster@ietf.org
Mail-Followup-To: iesg@ietf.org, ietf@ietf.org, postmaster@ietf.org
Subject: Re: Complaint v2 to IESG regarding censorship of dissent
In-Reply-To: <m23462iqje.fsf@ja.int.chopps.org>
Message-ID-Hash: GDNLBXYIKQKQECGPEFSODE7SYTIM35UN
X-Message-ID-Hash: GDNLBXYIKQKQECGPEFSODE7SYTIM35UN
X-MailFrom: djb-dsn2-1406711340.7506@cr.yp.to
X-Mailman-Rule-Misses: dmarc-mitigation; no-senders; approved; emergency; loop; banned-address; member-moderation; header-match-ietf.ietf.org-0; nonmember-moderation; administrivia; implicit-dest; max-recipients; max-size; news-moderation; no-subject; digests; suspicious-header
X-Mailman-Version: 3.3.9rc6
Precedence: list
List-Id: "IETF-Discussion. This is the most general IETF mailing list, intended for discussion of technical, procedural, operational, and other topics for which no dedicated mailing lists exist." <ietf.ietf.org>
Archived-At: <https://mailarchive.ietf.org/arch/msg/ietf/-A_JFfSXVGUk7uPEpXlDF_m5GuI>
List-Archive: <https://mailarchive.ietf.org/arch/browse/ietf>
List-Help: <mailto:ietf-request@ietf.org?subject=help>
List-Owner: <mailto:ietf-owner@ietf.org>
List-Post: <mailto:ietf@ietf.org>
List-Subscribe: <mailto:ietf-join@ietf.org>
List-Unsubscribe: <mailto:ietf-leave@ietf.org>

Christian Hopps writes:
> mail from people that aren't subscribed to any list

No. Contrary to what the AD evidently led various people to believe, I
used the same return path djb-dsn2-1406711340.7506@cr.yp.to (registered
in July 2014) that I've been consistently using for all of my postings
to IETF mailing lists.

Before filing a complaint, I checked that my outgoing mail logs showed
messages from that return path being accepted by the ietf.org mail
server, including a message that appeared promptly on the SAAG list
(ietf.org receipt: "queued as 88E368E7E2F4") and a message some hours
later that _didn't_ appear on the TLS list (ietf.org receipt: "queued as
BE0138FB0858"). I also checked that I was receiving other TLS messages,
so it's not as if there was some sort of general delivery problem.

The TLS chairs were already on record screwing around with the delivery
of my postings before that. The chairs issued a "Notice of Moderation"
overtly coordinated with the AD, and tried to justify this by claiming
that some unspecified aspect of my email was "disruptive".

Of course, establishing means, motive, and opportunity isn't as good as
having an authenticated videotape showing exactly what happened. Here's
what we know so far:

    * My registered return path djb-dsn2-1406711340.7506@cr.yp.to worked
      for postings to IETF mailing lists for many years, including, as
      noted above, a posting to SAAG early on 22 November 2025.

    * Exactly the same return path _didn't_ work for my posting to the
      TLS list later on 22 November 2025 (which was my first message to
      the TLS list after the "Notice of Moderation" on 17 October 2025).

    * Why didn't it work? AD's answer: "your message was held by mailman
      for 'posting by a non-list member' " meaning that "the email
      address you attempted to use is not subscribed to ANY ietf mailing
      list".

    * But, wait, the address was working for SAAG earlier the same day.
      Why wasn't it working for TLS later that day? AD's first answer:
      the address "got unsubscribed" (along with a variety of easily
      debunked speculations about how). AD's second answer:
      "complication ... moderation flags needing to be set in various
      places ... not sure ... not sure ... complicated".

    * After the initial block of this message, the AD extended the block
      ("I have instructed the TLS WG Chairs not to approve the pending
      email"). The AD later released the block.

I'm looking forward to the AD or postmaster replacing the "moderation
flags needing to be set in various places" statement with a clear
statement along the lines of "At time X, person Y clicked on button Z,
which disabled list access by djb-dsn2-1406711340.7506@cr.yp.to".

> Where's the censorship?

Did you read the complaint that you're replying to? I highlighted an
explicit censorship action and five ways that it violates IETF policy.

---D. J. Bernstein


===== NOTICES =====

This document may not be modified, and derivative works of it may not be
created, and it may not be published except as an Internet-Draft. (That
sentence is the official language from IETF's "Legend Instructions" for
the situation that "the Contributor does not wish to allow modifications
nor to allow publication as an RFC". I'm fine with redistribution of
copies of this document; the issue is with modification. Legend language
also appears in, e.g., RFC 5831. For further background on the relevant
IETF rules, see https://cr.yp.to/2025/20251024-rules.pdf.)