From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: X-Spam-Checker-Version: SpamAssassin 3.4.2 (2018-09-13) on dcvr.yhbt.net X-Spam-Level: X-Spam-ASN: X-Spam-Status: No, score=-4.0 required=3.0 tests=ALL_TRUSTED,BAYES_00 shortcircuit=no autolearn=ham autolearn_force=no version=3.4.2 Received: from localhost (dcvr.yhbt.net [127.0.0.1]) by dcvr.yhbt.net (Postfix) with ESMTP id EA3521F619; Wed, 11 Mar 2020 10:33:04 +0000 (UTC) Date: Wed, 11 Mar 2020 10:33:04 +0000 From: Eric Wong To: Luke Kenneth Casson Leighton Cc: meta@public-inbox.org Subject: Re: setting up mailman2 and public-inbox Message-ID: <20200311103304.GA21129@dcvr> References: <20200204205541.GB27797@dcvr> MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Disposition: inline In-Reply-To: List-Id: Luke Kenneth Casson Leighton 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).