I think this conversation is missing the real problem which is actually a usability / affordances issue.
The architecture of mailing lists sucks. It has always sucked. There is no way to implement a push messaging protocol that is not going to suck and a push messaging protocol without ubiquitous authentication is going to suck really bad.
The answer has always been to move to a pull protocol such as NNTP client-server (abandoning the server-server flood fill) or IMAP or the like. Why don't we do that? Well it is just too much effort to configure. I am aware someone has an IMAP service somewhere for IETF lists and there have been NNTP services. But neither of those work with my mail clients. And configuring my clients to be able to post while accessing the mail that way sucks even worse.
Currently, one of the clients that I have to be able to access my IETF messages through is a Web Browser.
I do think we could get to a point where this was fixed. But to do that we have to fix mailman and we also need to persuade people to start writing messaging clients that are built around a new pull protocol.
Now the 'new' protocol might be entirely new or it might just be a layer on IMAP with a small amount of extension work to support a different access mechanism. I am not yet sure.
Since the Mesh gives me the ability to provision every device I use with public keys for authentication, etc. etc. I am going to build off that platform. But I could do it without PKI/TKI if I had to.
Part 1 is to modify MAILMAN to
1) Add an X-header to a URI describing the connection point to the new protocol endpoint.
2) Accept posts from a submissions portal for people using the new protocol even if they are not mailman subscribers
3) Suppress delivery to subscribers using the new portal
4) Write out posts to both an index append only log and a message body append only log.
That is not a vast amount of code (or at least so I guess).
Part 2 is to create a Web subscription portal that allows people to sign up to get messages through the new mechanism
This should provide for email callback authentication of the email address of existing subscribers.
Part 3 is to write a messaging client that supports both the legacy delivery scheme and the new one.
Since I am not aware of an existing client capable of interacting with end-to-end encrypted social media content, I have to write a client anyways.
On Sat, May 21, 2022 at 7:30 AM Michael Richardson <mcr+ietf@xxxxxxxxxxxx> wrote:
John Levine <johnl@xxxxxxxxx> wrote:
> I am no more pleased than anyone else that some large mail systems
> misused DMARC to outsource the support costs of their security failures
> and as an entirely predictable side-effect broke forwarding and mailing
> lists. But given a choice between being the cranky old man yelling at
> the cloud and adjusting my mail so it works, I'll take the latter.
My contention is that we (the ietf) should have done exactly what p=reject
said. They don't want their mail forwarded, we shouldn't forward it.
That sucks for people who are the product (not customers) of these large mail
systems, but surely we shouldn't even waste our cranky-old-man time even
listening to such complaints.
--
Michael Richardson <mcr+IETF@xxxxxxxxxxxx>, Sandelman Software Works
-= IPv6 IoT consulting =-
