There was some discussion about this on IRC last night, but I had an
event to attend so we decided to take it to the ML. Here's a summary of
the issue(s) and possible solutions.

As a reminder, the current Alpine mail stack is based on mlmmj[0] for
handling & forwarding incoming mail, and hypermail[1] for web archives.
At some point there seems to have been swish-e for searching the
archives, but both the swish-e project and Alpine's deployment of it
seem to be now defunct.

[0] http://mlmmj.org/
[1] http://www.hypermail-project.org/

The main issues with mlmmj are:

- It strips out In-Reply-To headers when forwarding mail, which breaks
  threading
- It modifies emails a lot in general, which breaks DKIM signatures and
  will trip a lot of spam filters up

Hypermail's main issues are:

- No search functionality
- No way to download original messages or anything else you can feed to
  git am

The last one is addressed to some extent by patchworks, but patchworks
also doesn't have a search et al. I've found it difficult, for example,
to obtain the original message for patches older than a few months.

Solutions:

Many of you know that I have a conflict of interest, as I maintain
lists.sr.ht, an open source mailing list driver, archive, and hosted
service. Take the following with the requisite grain of salt, as it's
basically an ad.

lists.sr.ht is free & open source software[0] (AGPL) and can be hosted
on Alpine infrastructure, though you're welcome to use my hosted service
for experimentation and/or production uses. I have a mirror of the
aports list here[1], though threading is currently broken because of the
issues with mlmmj. Here's[2] a list where threading does work, if you
want to peruse the archives.

[0] https://git.sr.ht/~sircmpwn/lists.sr.ht
[1] https://lists.sr.ht/~sircmpwn/alpine-aports
[2] https://lists.sr.ht/~sircmpwn/sr.ht-dev

Advantages: there's no delay between emails arriving and being available
on the web archives. Emails are already grouped into threads and
organized by the last thread updated, and there's a powerful search tool
that you can use to find emails which are patches, are written by or Cc
certain people, have certain email headers, and so on. There's also an
API:

https://man.sr.ht/lists.sr.ht/api.md

Patches are given special treatment on the archive, with patchworks-like
highlighting, links to specific lines & files, and so on:

https://lists.sr.ht/~sircmpwn/alpine-aports/%3C20190312025245.20168-1-sir%40cmpwn.com%3E

A gerrit-like interface for doing patch review on the web or via email
is planned to be implemented within the next few months, at least in its
basic form - which should provide a nice alternative to patchworks.
Another benefit is planned integration with builds.sr.ht, my CI
platform, which will be available within a few weeks and will allow for
CI across all architectures supported by Alpine for all patches sent to
the mailing list - and to GitHub, too, if you like. A similar
integration with git.sr.ht (which hosts git repositories) will allow you
to keep track of patches which have and have not yet been merged
automatically, as well as getting back to the mailing list discussion
from a commit in the git UI.

I also have first-class Alpine Linux support, as all of the hosted
infrastructure runs on Alpine Linux. I have a CI which automatically
publishes packages for *.sr.ht to my third-party apk repository:

https://mirror.sr.ht/alpine/sr.ht/

I can set up the CI stuff, and to some extent code review, with another
mail driver. GNU mailman would be a common choice. I think that
lists.sr.ht is a compelling option, though, and I would be happy to
answer questions and provide support - even if you don't choose
lists.sr.ht. I depend on Alpine Linux a lot and I'm eager to give back
in any way I can.

--
Drew DeVault

On 2019-03-20 12:05 AM, Drew DeVault wrote:
> The main issues with mlmmj are:
> 
> - It strips out In-Reply-To headers when forwarding mail, which breaks
>   threading

Correction: it does not do this. Broken threading on my mirror must be
caused by something else. However, this is true:

> - It modifies emails a lot in general, which breaks DKIM signatures and
>   will trip a lot of spam filters up

And I also forgot to mention that mlmmj doesn't really pay attention to
RFCs and trips up on, for example, email addresses which include / or ~,
which are valid email addresses.

Hi!

Sorry for late response.

On Wed, 20 Mar 2019 00:05:51 -0400
Drew DeVault <sir@cmpwn.com> wrote:

> There was some discussion about this on IRC last night, but I had an
> event to attend so we decided to take it to the ML. Here's a summary of
> the issue(s) and possible solutions.
...
> Solutions:
> 
> Many of you know that I have a conflict of interest, as I maintain
> lists.sr.ht, an open source mailing list driver, archive, and hosted
> service. Take the following with the requisite grain of salt, as it's
> basically an ad.
> 
> lists.sr.ht is free & open source software[0] (AGPL) and can be hosted
> on Alpine infrastructure, 

The AGPL is not my favorite license due to it may scare off companies.

> though you're welcome to use my hosted service
> for experimentation and/or production uses. I have a mirror of the
> aports list here[1], though threading is currently broken because of the
> issues with mlmmj. Here's[2] a list where threading does work, if you
> want to peruse the archives.

What is the strategy for dealing with spam? If a spam message gets
through, can it be deleted from the archive? (I believe some spam is to
get higher search engine ranking).

Can you send to the mailing list without being subscribed, and have
those messages moderated? We currently moderate messages from
non-subscribers.

Does this require subscribers to have yet another user account/password?

...
 
> Patches are given special treatment on the archive, with patchworks-like
> highlighting, links to specific lines & files, and so on:
> 
> https://lists.sr.ht/~sircmpwn/alpine-aports/%3C20190312025245.20168-1-sir%40cmpwn.com%3E
> 
> A gerrit-like interface for doing patch review on the web or via email
> is planned to be implemented within the next few months, at least in its
> basic form - which should provide a nice alternative to patchworks.

Can this be integrated with gitlab?

> I I depend on Alpine Linux a lot and I'm eager to give back in any
> way I can.

This is very appreciated. I don't have any objection to replace the
mailing list software, but I want the infra team to decide.

-nc

Was going to respond to this yesterday, but got distracted with
packaging concerns.

On 2019-04-03 12:07 PM, Natanael Copa wrote:
> > lists.sr.ht is free & open source software[0] (AGPL) and can be hosted
> > on Alpine infrastructure, 
> 
> The AGPL is not my favorite license due to it may scare off companies.

So? Alpine isn't a company...

> What is the strategy for dealing with spam? If a spam message gets
> through, can it be deleted from the archive? (I believe some spam is to
> get higher search engine ranking).
>
> Can you send to the mailing list without being subscribed, and have
> those messages moderated? We currently moderate messages from
> non-subscribers.

Yes, but this is currently a manual process. I'm working on better
moderation controls now, I just added ACLs for banning users or having
restricted-posting lists. Up next is removing emails from the archive
and automatic moderation for non-subscribers. I'm also working on more
spam mitigation techniques, like rejecting emails with invalid DKIM
signatures and other validation checks, expecting the poster to have a
well behaved mail server.

> Does this require subscribers to have yet another user account/password?

No, you just need an email address to participate on the list. You need
an account to create and manage lists, but not to post.

> > Patches are given special treatment on the archive, with patchworks-like
> > highlighting, links to specific lines & files, and so on:
> > 
> > https://lists.sr.ht/~sircmpwn/alpine-aports/%3C20190312025245.20168-1-sir%40cmpwn.com%3E
> > 
> > A gerrit-like interface for doing patch review on the web or via email
> > is planned to be implemented within the next few months, at least in its
> > basic form - which should provide a nice alternative to patchworks.
> 
> Can this be integrated with gitlab?

No. I have some ideas about how to do this, but they're somewhat
complicated and will take time. If Alpine moves to lists.sr.ht, I'll
make this a priority.

> This is very appreciated. I don't have any objection to replace the
> mailing list software, but I want the infra team to decide.

Aye, ultimately it's the infra team's decision, and I'm happy to answer
any questions about lists.sr.ht or mailing list maintenance in general
from them.