On 4/1/23 09:39, pknowles@tpnsolutions.com wrote:

I'm playing around with installing Mailman Core, and want to have messages on a "per-list" basis sent to a special "archiver" address which I intend to make archives available at via a custom built "read-only" IMAP client.

How would I go about having messages sent to this external address, short of adding the address as a subscriber?

See https://gitlab.com/mailman/mailman/-/blob/master/src/mailman/archiving/proto... for an example of an archiver that implements Mailman's IArchiver interface.

You could make something similar with an archive_message() method that sends the message to your IMAP server, or possibly you could just implement your IMAP client to serve messages from the existing var/archives/prototype/ hierarchy. Messages for lists with the prototype archiver enabled are stored there in maildir format by list name. To enable the prototype archiver, you may need to put

[archiver.prototype] enable: yes

in your mailman.cfg.

To make your own archiver, create a python module, say my_archive.py, that defines a My_Archive class implementing the IArchiver interface.

Put that module somewhere where mailman can import it and put something like

[archiver.my_archiver] class: import.path.my_archive.My_Archive enable: yes

where import.path.my_archive.My_Archive is the actual path that is imported. For example if Mailman is installed in a venv, you could put my_archiver.py in the venv's site-packages directory and then the class would be just

class: my_archive.My_Archive

-- Mark Sapiro <mark@msapiro.net> The highway is for gamblers, San Francisco Bay Area, California better use your sense - B. Dylan

On 4/1/23 16:33, Peter Knowles wrote:

Mark,

The whole reason I'm developing my own "frontend" for both "list management" and "archive" access is because Python isn't really the language I speak... I'm a PHP guy, and so I'm working to build with the language I know and love, while utilizing Mailman for what it does best... In addition to implementing the frontend the way I want it (expose/hide feature that are useful/unuseful to our users), I want to fully customize the visual appearance to represent the SaaS offering properly.

This is exactly the reason why Mailman core was decoupled from archiving and the web UI. HyperKitty and Postorius were developed because we knew that almost no one would use Mailman core without archiving and a web management UI, but we always hoped that others might develop and contribute other web based archiving and management interfaces.

Brian Carpenter of EMWD who tragically died of COVID did exactly that with his Affinity and Empathy PHP applications that interface with Mailman core via the REST API. EMWD hosts lists that use those interfaces, and had Brian not died, some version of those might be open sourced, but his initial thrust was to keep them proprietary for his business reasons. There is an early description of Brian's concept for Affinity at https://gitlab.com/mailman/affinity.

*** we're not try to hide that Mailman is in the equation, just how the overall interface is visually represented ***

That all being said, on a slight segway... Aside from using the REST API, is it practical or possible to manipulate the database directly? That is, in doing so would it just work or are there extra moving parts when an API request is issued?

It probably is possible, but I would definitely discourage it. The REST API should provide everything you need without your having to reimplement everything it does.

-- Mark Sapiro <mark@msapiro.net> The highway is for gamblers, San Francisco Bay Area, California better use your sense - B. Dylan