Re: setting up mailman2 and public-inbox

[Eric Wong <e@yhbt.net>]

Luke Kenneth Casson Leighton <lkcl@lkcl.net> wrote:
> eric, hi,
> 
> we're having difficulty understanding how to deploy public-inbox in a
> way that very simply and as a top and only priority records email in a
> public inbox, for the purposes of having it in a git repository, when
> that email is coming in via exim4 and going into mailman2.
> 
> this really cannot be difficult.

Add a regular subscriber that receives mail via normal Mailman
methods.

Then setup public-inbox-watch to watch a Maildir that normal
subscriber receives mail in.  The top of public-inbox-watch(1)
manpage should give a reasonably complete example.

I use offlineimap for IMAP <-> Maildir sync, but mbsync works
just as well.  There's other methods, of course.

> we do not want to replace mailman2: its front-end, the subscription
> capabilities, the user management are perfect and protect against
> spammers, keeping the list clean.
> 
> we do not want to replace the pipermail archives at this point,
> although that may be something we could consider at a later date.
> 
> the *only* thing that we want public-inbox for - right now - is its
> ability to store the list email - *after* processing and acceptance by
> mailman - in a git-backed repository, so that people in offline
> situations have full and complete access to the archives.

Totally understood.

There's absolutely no requirement for public-inbox to even run
on the same machine as mailman|exim.  I run https://public-inbox.org/git/
and do so using public-inbox-watch just as a regular subscriber
with no special access to kernel.org whatsoever.

> how *exactly* do we do that one thing and one thing only?
> 
> (basically, if public-inbox accepted mbox format we could do what we
> need, straight away.  the conversion process and the extra CPU time is
> not a problem, because we already have to accept that overhead on
> conversion, and the lists each month are not that big: 700 messages or
> so).

mbox is really only useful for one-shot imports and the
scripts/import_vger_from_mbox example script was recently
updated in git master to be more flexible.

For incremental updates, mbox is terrible since the mbox can be
rewritten/reordered and we'd constantly have to rescan +
deduplicate instead of being able to use inotify to only see
changes.

> are we missing something really simple?
> 
> if we subscribe a local user on the server (inbox@libre-riscv.org) to
> the actual list, then configure that local account to have mail
> delivered Maildir format, would that do the trick?

Exactly :)

I also suggest something to cleanup old messages, something
like:

	find /path/to/maildir -type f -ctime +14 -print0 | xargs -0 rm -f

To delete all messages older than 14 days

I'd like to eventually have an auto-deleter which verifies the
message is successfully imported into an inbox (and not rejected
as spam or triggered some other error).