MLMMJ integration

[runout-at]

MLMMJ is a mailing list manager: http://mlmmj.org/

Its more lightweight than Mailman3.

It was recently discussed in #281

Integration with Exim/Vexim is straight forward (tested on Debian). If this is from interest I could prepare a PR. The following is an example for multiple domains and multiple lists per domain - this is reflected by the file system structure (/var/spool/mlmmj///...).

• /etc/exim4/conf.d/main/00_mlmmj

MLMMJ_ENABLED = yes
MLMMJ_HOME = /var/spool/mlmmj
domainlist mlmmj_domains = lists.example.com : lists.example.net : lists.example.org
delay_warning_condition = ${if match_domain{$domain_data}{+mlmmj_domains}{no}{yes}}

• /etc/exim4/conf.d/router/050_mlmmj

.ifdef MLMMJ_ENABLED
mlmmj_router:
  debug_print = "R: mlmmj_router for ${lc:$local_part}@$domain_data"
  driver = accept
  local_parts = ${lookup {${lc:$local_part}}dsearch{MLMMJ_HOME/$domain_data}}
  domains = +mlmmj_domains
  #require_files = MLMMJ_HOME/$domain_data/${lc:$local_part_data}
  # Use this instead, if you don't want to give Exim rx rights to mlmmj spool.
  # Exim will then spawn a new process running under the UID of "mlmmj".
  require_files = mlmmj:MLMMJ_HOME/$domain_data/$local_part_data
  local_part_suffix = +*
  local_part_suffix_optional
  headers_remove = Delivered-To
  headers_add = Delivered-To: ${lc:$local_part_data}$local_part_suffix@lists.roland.at
  transport = mlmmj_transport
.endif

• /etc/exim4/conf.d/transport/30_mlmmj

  mlmmj_transport:
  debug_print = "R: mlmmj_transport for ${lc:$local_part_data}@$domain_data"
  driver = pipe
  return_path_add
  user = mlmmj
  group = mlmmj
  home_directory = MLMMJ_HOME/$domain_data
  current_directory = MLMMJ_HOME/$domain_data
  command = /usr/bin/mlmmj-amime-receive -F -L MLMMJ_HOME/$domain_data/${lc:$local_part_data}

This transport uses the amime extension from https://codeberg.org/mlmmj/mlmmj/src/branch/master/contrib/amime-receive

• /etc/cron.d/mlmmj

0 */2 * * * root /usr/bin/test -x /usr/bin/mlmmj-maintd && find /var/spool/mlmmj -mindepth 1 -maxdepth 1 -type d -exec /usr/bin/mlmmj-maintd -F -d {} \;

On a system without systemd

[kaluang]

I really hate Mailman3, it is unnecessarily complicated, super buggy and has a lot less features than Mailman2. I would be happy to find an up to date alternative. But MLMMJ seems to be abandoned for many years now or am I wrong about that?

[runout-at]

I did move away from Mailman for the same reasons.

For MLMMJ I'd not say abandoned but not much activity lately but it's actively used by some bigger lists. From my experience it's doing it's job without issues and worth to give it a try.

Since I switched from MM2 to MLMMJ I wrote a small API to manage MLMMJ as I had the need to feed it automatically from a database: https://gitlab.com/runout/mlmmjapi

[kaluang]

It's just that their website doesn't support https, the latest release is from 24 May 2017 and the latest mail on their own mailinglist is also from 2017, that did not reassure me a lot

[runout-at]

I'm sure it will take some time until this new release will get into Debian: https://codeberg.org/mlmmj/mlmmj/releases/tag/RELEASE_1_4_0

See this issue: https://codeberg.org/mlmmj/mlmmj/issues/3 and regarding the mailing list: https://marc.info/?l=mlmmj

Contributions you might want: eg for html-footer,... https://codeberg.org/mlmmj/mlmmj/src/branch/master/contrib

[kaluang]

Ah I see, thanks. Then it looks like they just abanoned the website http://mlmmj.org I will definitely check it out

[runout-at]

Looks like Debian has the new release on the track already: https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=1043037

[rimas-kudelis]

Indeed, mlmmj.org is perhaps among first search results when searching by name, and the status of that website, or the repo pointed to from it, is not reassuring.

It's good to know the work is at least being continued elsewhere. Still too bad they can't become the official MLMMJ yet.

[rimas-kudelis]

@runout-at, what kind of integration are you talking about in this issue?

[runout-at]

For now the integration would just be to provide a router and transport.

Lists would have to managed by other tools or manually and configured in _main/00mlmmj.

Maybe later on we could add mlmmj to the type-field in the users table and use it to query the mlmmj-lists for the config. But this would involve some changes in the vexim-frontend.

[rimas-kudelis]

Actually, I'm not even sure why we have Mailman "integration" in the first place. No SQL queries are performed in either Mailman router or transport that we provide, so I'm not sure why we should provide them in the first place. There's basically no integration whatsoever, except the adminlists.php page which just acts as a redirect page to Mailman2 admin, and these config files which seem to be just provided for convenience (probably because Avleen used Mailman).

Also, the mailman package in Debian has README.Exim4.Debian.gz file, which instructs to add three different routers and two transports for Mailman, while we only provide one of each. Which means we're probably shipping setup that could be considered incomplete.

Not in 2.3.x, but I think I'd rather remove these Mailman-related files altogether, unless I'm convinced not to.

Same goes for MLMMJ, Mailman3 and anything else. I'd say it's out of scope for us, at least in this upcoming version.

I'm also tempted to drop the configure file, since it was written who knows how long ago, we update it to account for changes in Exim only every so often, and it can only be seen as a template anyway, but that's a point for a different discussion.

Thoughts?

[kaluang]

I use Vexim for more than 10 years now and even though I also use Mailman, I never used the Vexim frontend integration for it. It is really just a link that does not provide much benefit. I don't know anything about MLMMJ, maybe there can be benefits with integrating it into the frontend? But I'm strongly for keeping and maintaining the configure file. Exim4 routers and transports are complicated and long. It is not trivial to install Vexim, for every new instance I still use an old step-by-step guide from a website that is only still available via archive.org in addition to my plentyful notes about changes and updates. If we want any new people to be able to use Vexim we should definitely keep the configure file and keep it updated. I think the current version does still work as intended, besides the small changes to the Mailman router I mentioned here. The vexim-acl-check-*.conf-files are outdated though, they need some rework. I'm also strongly for keeping and maintaining the Mailman2 routers and transport. If you don't want it in the configure file maybe we can put them into a seperate file or just as a readme. Same goes for MLMMJ and Mailman3. We should make it as easy as possible to start with Vexim if we want it to have some future.

[runout-at]

Maybe MM2 and MM3 do need different routers/transport. When I tested MM3 some years ago I did that on a separate VM (only MM3+Exim) and it was complicated to get it to work and communicate with the main Exim server properly. I'm not sure if this is easy enough to provide a receipt with Vexim.

At the moment I'd just give a rough idea how to do it so it's easier for people to start off - and maybe only for MLMMJ.

[rimas-kudelis]

@kaluang:

I use Vexim for more than 10 years now and even though I also use Mailman, I never used the Vexim frontend integration for it. It is really just a link that does not provide much benefit. I don't know anything about MLMMJ, maybe there can be benefits with integrating it into the frontend?

I mentioned that frontend page because it's the only other point of integration that we provide (other than the Exim config bits and some text in the README). Though I just noticed that a link to that page is only displayed in the main admin page if $mailmanroot is not empty. Feel free to check it out, but basically, that functionality is very rudimentary and I doubt it would be missed, but also it's the least problematic part of MM2 integration because it's so rudimentary.

@runout-at:

Maybe MM2 and MM3 do need different routers/transport. When I tested MM3 some years ago I did that on a separate VM (only MM3+Exim) and it was complicated to get it to work and communicate with the main Exim server properly. I'm not sure if this is easy enough to provide a receipt with Vexim.

Of course MM3 needs a different router and transport, and that's my point exactly (cont'd below).

@kaluang:

I think the current version does still work as intended, besides the small changes to the Mailman router I mentioned here. The vexim-acl-check-*.conf-files are outdated though, they need some rework. I'm also strongly for keeping and maintaining the Mailman2 routers and transport. If you don't want it in the configure file maybe we can put them into a seperate file or just as a readme. Same goes for MLMMJ and Mailman3. We should make it as easy as possible to start with Vexim if we want it to have some future.

MM2, MM3, MLMMJ and most other projects usually have their own README files or instructions provided by other means. Sometimes this is even down to blog posts by people who had to sit down and figure out the integration details themselves.

So my point is: why should we take the burden upon ourselves to maintain documentation and integration hooks between Exim and numerous third-party products, which our users may or may not use and which, at least in some cases, can only have very basic/no integration with Vexim (like in case of MM2)? In my opinion, everything is already complicated enough as it is.

I mean, if even a project as strong as Debian resorts to README files with instructions for manual actions for each integration with Exim, do you really think we can do better? Right now? I doubt it.

Of course, we can strive to provide every possible integration with every possible software, but I'm afraid that we'll just crumble under our own weight if we do so. Considering the overall lack of time we dedicate to this project, I'd rather focus on virtual mail only for now, and maybe think about a way to provide some wizard-like or pre-packaged solution later. BTW, I believe these goals also closely overlap with those of Exim4u.

Some of these points are also closely related to #284.

[runout-at]

Exim4U is too monolithic for me. I try to split components to several VMs.

An integration in Vexim would only make sense if there is something to configure we can provide a frontend for.

Maybe we could create a contrib directory somwhere in the docs and add scripts, routers, transports, configs we come around and believe it to be useful.

I'm not up to write or maintain an Exim Cook Book.

[runout-at]

I'd like to open the type-field in the users and domains tables to add more types. These additional types would be enough to eg filter domains for mailing lists and other use cases.

The list of _types_could be static in the config file. Not sure if it's really necessary to have the list of types in the SQL-create statements.

[runout-at]

I 'd just throw this in the wiki and close the issue.

https://github.com/vexim/vexim2/wiki/Server-configuration:-MLMMJ-(Mailing-Lists)