*Abstract:* Modern email system security measures make it practically impossible for mailing lists to work – many subscribers don't get all emails. This not only hinders communication, but blocks an inclusive one. *Shall we, as Logging Services, experiment with alternatives?*
*Motivation #1: mailing lists technically don't work* Several widely-used email providers (GMail, Yahoo, iCloud, etc.) have in the last couple of years enabled new measures (DMARC, SPF, DKIM, etc.) to verify the authenticity of emails. In short, these measures enrich email content with checksums and signatures capturing its authenticity. When a mailing list system (e.g., ezmlm, mailman) receives such an email, it performs several changes on its content (adds information about the mailing list, etc.), and delivers it to all subscribers. When the mail server of a subscriber receives such tampered mail, and if that mail server happens to have earlier shared authenticity checks enabled, it discards the email, or at best, marks it as spam. Ralph, Matt, Piotr stated many times that they don't receive all emails. Ralph actually stated many ASF mailing list emails end up in his spam box <https://the-asf.slack.com/archives/CBX4TSBQ8/p1728032221080189?thread_ts=1727958807.348019&cid=CBX4TSBQ8>. Recently we witnessed even Brian Proffitt (VP, Marketing & Publicity) suffer from the same problem <https://lists.apache.org/thread/yfmrpjslcbo5jmsqqpvtok1o6lht11rb>. INFRA is crawling with related tickets: INFRA-24574 <https://issues.apache.org/jira/browse/INFRA-24574>, INFRA-24790 <https://issues.apache.org/jira/browse/INFRA-24790>, INFRA-24845 <https://issues.apache.org/jira/browse/INFRA-24845>, INFRA-24850 <https://issues.apache.org/jira/browse/INFRA-24850>, INFRA-24872 <https://issues.apache.org/jira/browse/INFRA-24872>, INFRA-25947 <https://issues.apache.org/jira/browse/INFRA-25947>, INFRA-26171 <https://issues.apache.org/jira/browse/INFRA-26171> – there are dozens more. This technical difficulty is not only known to us. AFAIK, this is one of the main reasons PSF (Python Software Foundation) decided to switch from mailing lists to Discourse. Mailman documents several DMARC mitigations <https://docs.mailman3.org/projects/mailman/en/latest/src/mailman/handlers/docs/dmarc-mitigations.html>, but I think these are workarounds/hacks rather than well-established solutions. *Motivation #2: ezmlm is dead* ezmlm, the mailing list software ASF uses, is dead – it is neither developed, nor maintained anymore. (Last official release was in 1997, there is the `ezmlm-idx` add-on, which later on became a successor <https://untroubled.org/ezmlm/faq/What-is-the-difference-between-ezmlm-and-ezmlm_002didx_003f.html>, which last produced a release in 2014, and so on. Long, dead story.) INFRA maintains a very big, sophisticated set of Perl rules for running ASF ezmlm instances. If you look closely at the INFRA tickets I cited above, some suggest INFRA to fork ezmlm and fix some long standing bugs, etc. We can discuss the possibility of migrating from ezmlm to mailman (yet another mailing list software, but one that is still maintained), whether such a migration should be practiced ASF-wide or only for Logging Services, etc. But eventually, we will still be using a mailing list, and as I tried to explain above, IMO, they just don't work good. *Proposal #1: Experimenting with GitHub Discussions* GitHub is our development bread and butter. We use its tickets, PRs, reviews, discussions, CI, security & code quality checks, etc. It works perfectly and components are integrated well, i.e., you can link issues, comments, PRs, CI runs, etc. Users like it too – we all witnessed the sudden increase in user interactions after migrating to GitHub Issues and Discussions. We can configure sections & categories in Discussions <https://docs.github.com/en/discussions/managing-discussions-for-your-community/managing-categories-for-discussions> to make it serve as our main communication medium. It also provides mail notifications and the possibility to respond to them for those who still prefer their email client over a browser. In short, we can quickly configure Discussions, update our support policy page, and start experimenting with it. One can raise the argument that what if Discussions disappear? We can mirror communication there to a mailing list to be on the safe side. Yet, we need to evaluate the necessity of this. *Proposal #2: Experimenting with Discourse* We can get a VM from INFRA and manage our Discourse instance. Though, AFAIC, this will result in a "GitHub Discussions"-like setup with all the integration goodies missing and added server maintenance burden. *F.A.Q.* *What if GitHub Discussions disappear?* In such a case, I presume they will allow us to download the existing archives. In the worst case, we can decide to mirror the communication there to a mailing list. Yet, we need to evaluate the necessity of this. In particular, how big of a problem is this at the experimentation stage? *How will private communication work with GitHub Discussions?* We can create private repositories for internal/private communication. For users/researchers wanting to submit & discuss security issues, they can get in touch with us (either via email to `security@logging` or some other ASF/INFRA mailing list), we can grant them permissions to collaborate privately on a repository security advisory <https://docs.github.com/en/code-security/security-advisories/working-with-repository-security-advisories/about-repository-security-advisories> . *Don't the ASF legals require mailing lists?* I am aware that several ASF policies require mailing list communication, e.g., for voting and such. I first want to establish a consensus among us, and then pitch to the board for exemption as a pilot. *Shouldn't this proposal be practiced ASF-wide?* This will be a very (very very very, actually!) daunting route to pursue. I'd rather start small, solve our problem first (if we can), and then think about widening the scope.
