inbox.sourceware.org experiment

[Mark Wielaard]

Hi Frank,

On Wed, Aug 17, 2022 at 05:33:40PM -0400, Frank Ch. Eigler wrote:
> > [...]
> > > Yes, understood that the extra indexing can do extra searches.  My
> > > question was about utility/need for this.
> > 
> > The use seems obvious to me for anybody using the web based archives
> > to generate tailored message/mbox results, specifically date ranged
> > searches seem pretty mandatory since otherwise you essentially just
> > need to keep clicking, next, next, next.
> 
> I was under the impression that your main interest in p-i was the easy
> addressability and availability of raw emails, for use such as with
> git-am.  Are there other users pining for this kind of thing?

I am not sure that is my main interest in public-inbox, but yes, I do
really like public-inbox because it allows tools like b4 (which I have
already tested against our instance) and piem (not tested yet) to
easily pick up and apply patch emails.
https://git.kernel.org/pub/scm/utils/b4/b4.git/tree/README.rst
https://docs.kyleam.com/piem/

I think others will also use those (or similar) tools. But I primarily
expect users to use the public-inbox archives as a way to access the
mailinglists without having to subscribe, but still be able to easily
get the actual (raw) messages (either through git, atom, mbox, nntp or
imap) to follow the conversations. Which I think is the main
interesting thing public-inbox offers.

> > But also to get specific messages based on author or subject. On
> > specific use case for public-inbox is to not have to be subscribed
> > to a list to read it [...]
> 
> You are expecting people to use the xapian query language for this
> stuff?  Mailman offers that style of click-click browsing already.

Not just users, but also tools, yes. And not for clicking through the
archive, but to generate tailored sets of messages they are interested
in. IMHO the public-inbox archives are a lot more usable than the
mailman style archives.

> > [...]
> > So this is before mailman sees the message, so we do need to do a
> > spam-check.
> 
> No, postfix already spam checks everything upon receipt, before delivery.

OK, but mailman still also blocks some messages which I have to
approve/deny as list admin (this only happens once or twice a month,
so maybe that is just spam we have to tolerate?)

> > And I think postfix sets ORIGINAL_RECIPIENT already, we just need to
> > make sure it is one of the addresses for a list in the config.
> 
> This shouldn't be something that we need to write code to do, if it needs
> to be done at all.

OK. Assuming the process runs as the inbox user it will pick up the
/home/inbox/.public-inbox/config file which should have all
information.

> > But what generates /etc/mailman/aliases itself?  Can we hook into that
> > to trigger generation of this aliases-inbox file? Otherwise if we add
> > a new mailman list it won't work.
> 
> It must be some mailman administrative script.  Just crontab another
> one.

Under which account should this crontab run? mailman doesn't seem to
have any crontabs at the moment.

> > And do we need to update/regenerate
> > /etc/aliases.db and/or /etc/mailman/aliases.db ?
> 
> The proposal is to not touch /etc/aliases* NOR /etc/mailman/aliases*.
> The proposal is to generate a new file like
> /etc/postfix/mailman-inbox-aliases from /etc/mailman/aliases.  That
> new file would be the one postfix would read.  It could be texthash:
> rather than hash: so postmap would not even be necessary for updates.
> That depends on whether the relevant alias-expansion postfix process
> is short- or long-lived.

OK, I see the following in /etc/postfix.main:

# CGF 2020-03-08 12:49
alias_maps = hash:/etc/aliases, hash:/etc/mailman/aliases

# CGF 2020-03-18 14:10 EST - newaliases wasn't affecting /etc/mailman/aliases
alias_database = hash:/etc/aliases, hash:/etc/mailman/aliases

So I assume calling newaliases regenerates the hash/.db files.

I can write a script to generate mailman-inbox-aliases this weekend
when I have stable internet access again. Will post to the list before
installing to make sure I don't accidentially break something.

Cheers,

Mark