[ih] The Decline and Fall of Internet Email?

[Bill Woodcock]

> On Feb 11, 2024, at 20:23, John Levine via Internet-history <internet-history at elists.isoc.org> wrote:
> It appears that Bill Woodcock via Internet-history <woody at pch.net> said:
>> So, what to do about it?  
>> One approach would be using an end-to-end overlay, and (for instance) not send or accept any email which wasn’t PGP-encrypted. ...
> This is unfortunately another one of those Well Known Bad Ideas.

Yes, that was one of my points, however I figured it should be addressed because it seems to be most people's default first resort.

For the reasons you and I both stated, it doesn’t scale, and it doesn’t actually solve the problem, it just layers more work on top.

> I don't think there is a general solution to the spam problem

Micropayment bonds.  Yes, retrofitting that onto the current system of email would be very difficult.  Building it into a new communications medium would in fact entirely deal with spam, provided it were implemented securely and wasn’t easily bypassed.  No system is perfect.  But we’ve gotten well beyond the point in the history of the Internet where we can make the very large investment of developing a new open protocol without assuming bad-faith abuse from the outset, and addressing it.  I think the SKS keyserver network demonstrated that: a relatively obscure service, built by and for its user community, which was solving a real problem, and replaced a much more naive design which also had no built-in resistance to attack.  Lasted just long enough for people to invest heavily in deployment, and then someone destroyed it out of spite, or to make the point that it didn’t prevent abuse, or something.  If we can’t ignore abuse when we’re that far outside the public view, we definitely can’t ignore it on anything public-facing.  And that means structurally-aligned incentives, built in from the get-go.  Want to send a message?  Be prepared to pay to do so.

I pay for stamps, I pay FedEx and DHL, I pay LinkedIn for the privilege of sending “in-mail,” and I pay for Signal, despite its faults. I’ll happily pay a bit to support a functional electronic messaging system.

> The entire mailing list problem would be solved if lists could wrap messages sort of like single-message digests. The wrapping is easy, MIME rfc822 attachments were defined in the 1990s. But hardly any user mail programs and no web mail display them well and even fewer treat the wrapped messsages as messages and let you reply to them. So we're stuck.

The installed-base-drag problem that new tiny walled gardens don’t have to deal with.  I’m just not convinced that we’re ever going to get past the dilemma of backward-compatibility and fixing things…  If we fix things but maintain full backward compatibility, people who don’t feel like doing the work can continue right on doing things the old way, and the fix doesn’t get implemented.

Hypothetically, there could be things that would get fixed for the people who do the work, and don’t get fixed for the people who laze about, but I think that’s a small subset of problems that have sweet-spot solutions with that effect.

Which brings us back to: if we really want to solve these problems, we may have to apply the lessons learned and implement them in a new protocol, which isn’t backwards-compatible with email, except through application-layer gateways, which would have to obey the new rules on their new side.  And that’s the heavy lift: if it’s not done as an open protocol, you get a ton of little half-assed walled gardens, as we see with text and video chat, post-XMPP.  And if it is done as an open protocol, all the walled-garden idiots come out of the woodwork to try to sabotage it, and you wind up with IPv6: all the features you really want stripped out, because consensus can’t be reached.

                                -Bill

-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 833 bytes
Desc: Message signed with OpenPGP
URL: <http://elists.isoc.org/pipermail/internet-history/attachments/20240213/497fa5f6/attachment.asc>