Re: portable e-mail, now Trying to do too much (was Re: the introduction problem, etc.)

[Phillip Hallam-Baker <[e-mail]>]

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 <[e-mail]>
wrote:

>
> John Levine <[e-mail]> 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 <[e-mail]>, Sandelman Software Works
>  -= IPv6 IoT consulting =-
>
>
>
>