Why Nextlist ?

This project started in 2023 when my cloud server left security support and I had to decide whether to migrate services or abandon hosting these. A service I’ve maintained for family and community groups for years is hosting email lists. These are one of the older forms of social network. You join a list, or are added to one because you said you wanted to know more about its topic, it has a content policy, members communicate by sending to the list address which reflects to all members. Some lists are just used by listowners to send messages to a group. Some lists are private, some public, in the sense members of the public can confirm an email address by having a code sent by list software which they send back to join the list.

After owning a UK academic community list (econ-lets) I started hosting on a program called Majordomo on a home computer to run other lists which modem dialled a network connection 4 times a day in the early nineties. When I migrated to operating my own hosted virtual machine (cloud server) I installed GNU Mailman to do the job. Why not continue with that ? It’s generally not a good idea to reinvent the wheel. But with my long history of hosting email lists, I was reluctant to give up list hosting.

To continue with Mailman on my new server would have needed a massive software installation running many continuing processes on my server, taking much memory and diskspace. Mailman3 had bloated out of all recognition compared to Mailman2. It wasn’t what I wanted. Mailman 2 required Python 2. Both came out of security support years ago, and I didn’t want to do the port to Python 3 of Mailman 2 myself.

More minimalistic options didn’t have web application administration or unsubscription – you had to do everything with emailed command lines, as in the old Majordomo days. I didn’t think many of my users would want to regress that far, and having to struggle to get off a list can be a nuisance, as well as grounds for complaint to an upstream cloud hosting company. So I made unsubscription very easy, for large lists with a single click on a message footer, or a little more secure for family groups requiring a confirmation step.

So I developed Nextlist. A few odd things make this different. The web interface continues to use the CGI web application interface, keeping less code continuously in memory, apart from Apache mod-cgi which loads and executes the application on demand, meaning higher performance for smaller loads. If you have higher loads, you’ll probably want to use Mailman3 which uses the WSGI interface. The web user interface is kept minimal and functional – old school HTML generation, no need for CSS to make it look pretty.

The Nextlist email reflector program doesn’t relay attachments or HTML email which allows formatting and inline graphics. It’s intended for text only, with the ability to help distribute files of kinds which can’t harm recipient computers. A limited range of common standardised file types (e.g. JPG, MP3, PDF) are stored on the server for a time limited period, and a link is added to the plain text message. Those who want to see a file can click and download it. These don’t include executable content, so Nextlist isn’t configured by its author to propagate malware. It only relays plain text. If it gets a multipart input it sends a flat plaintext output. The unsubscribe link is customised per list member and added as a footer to each message. Cc lists on the input side aren’t relayed on the output side. Trying to relay such historically leads to having much madness to fight in both human and software messaging loops. Nextlists doesn’t attempt to archive messages. That can be done for a mailing list needing archives by subscribing an address which automatically archives input messages onto a web page to a list requiring that.