Mailing lists as the main collaboration centre at SME
Hello all, I own and run a small company (lanao.org).
I am looking for companies which have put mailing lists not only as a form of general announcement but especially as the main way to collaborate. I am thinking of moving my team to a model like that and would love to read about some best practices or strong opposition to the idea. I am hopeful that out there there are companies which have resisted the Microsoft Teams virus.
If your company uses mailing lists to run, please reach out. We are currently using Gitlab issues to collaborate which has been quite successful. I would be very interested to trade tips.
Best wishes, Rodrigo
On 8/30/25 18:13, Rodrigo Camacho wrote:
Hello all, I own and run a small company (lanao.org).
I am looking for companies which have put mailing lists not only as a form of general announcement but especially as the main way to collaborate. I am thinking of moving my team to a model like that and would love to read about some best practices or strong opposition to the idea. I am hopeful that out there there are companies which have resisted the Microsoft Teams virus.
If your company uses mailing lists to run, please reach out. We are currently using Gitlab issues to collaborate which has been quite successful. I would be very interested to trade tips.
I run a public museum; our team uses (MM3-based) mailing lists for collaboration and coordination. It works well, though I've found that everyone under the age of about 40 says "Hey we should do this on Discord!" ...to which I flatly reply "NO." (it is good to be the boss)
But the fact remains that it works very well, and it's very good (for our use case) to have the history.
-Dave-- Dave McGuire, AK4HZ New Kensington, PA
On 31 Aug 2025, at 00:31, Dave McGuire <mcguire@neurotica.com> wrote:
I run a public museum; our team uses (MM3-based) mailing lists for collaboration and coordination. It works well, though I've found that everyone under the age of about 40 says "Hey we should do this on Discord!" ...to which I flatly reply "NO." (it is good to be the boss)
Hey Dave, thanks a lot for the response.
Glad you are there to guide the way away from Discord!
Do you host and manage MM3 yourself or do you buy the service? If so, do you mind sharing the name of the service? I’m looking for service providers to avoid hosting and managing ourselves.
Do you have a set of rules to help make communication in your mailing lists more effective (tags/mentions/other)? For now, I have found that the kernel mailing list has a good etiquette guide ^1.
But the fact remains that it works very well, and it's very good (for our use case) to have the history.
100% agree; all these services which use databases (discord, m teams, slack, discourse etc.) have proven to have very short lives.
Rodrigo 
Rodrigo Camacho writes:
If your company uses mailing lists to run, please reach out. We are currently using Gitlab issues to collaborate which has been quite successful. I would be very interested to trade tips.
While (obviously :-) I support the use of mailing lists for collaboration and have used them successfully in multiple contexts for decades, you should pay careful attention to the user experience.
Mail user agents vary widely in their capabilities and user interfaces. Sometimes that means quality. For example, Gmail's customizable filters seem to be ordinary Sieve filters, that's fine, but the user interface is terrible. In other cases, they're just different (think Emacs-based MUAs vs Gmail). You should consider providing support to users of various MUAs, and lean to "more" resources for that rather than "less". Make sure that users have access to good threading in their MUAs. Gmail "conversations" aren't a great model; that's about the minimum capability. For corporate mail, both internal and incoming from suppliers and customers, etc, you should provide an IMAP server. This allows you to deal with document retention policy and privacy requests centrally. But you need to remember that users may be keeping local copies. You may also want to provide a corporate webmail server. I can't recommend a good one; we just decommissioned ours in favor of IMAP access because everybody has a personal MUA with a better UI. (I think we're using Cyrus imapd suite.)
Avoid the temptation to create many precisely defined lists. In my experience, it's more important that it be easy to choose the lists to post to and to subscribe to, than they be closely focused on specific interests. Focus is better served by an MUA that allows collapsing and suppressing individual threads and subthreads.
More important than wiping out top-posting is that everyone agree on style. I've seen a few lists where people absolutely could not get the concept of "appropriate amount of context" where switching to top-posting improved the flow. In general for technical content interlinear responses are best. However for managerial content ("Do this" -> "Done" -> "What about" -> "That too" conversations) top-posting is often fine because it's so linear. "Bottom posting" of course is right out.
The HyperKitty archiver was designed with the "we demand Discord" crowd in mind. As an archive, it provides the obvious features, including integration with various full-text indexers for search. But the authors also added a bunch of forum-like features, including the ability to post from the HyperKitty web ui and likes. There are alternatives, such as the IETF's MailArchive, which uses a maildir message store, which makes it easy to add an IMAP server to the archive, one feature that HyperKitty doesn't provide. This allows seamless access to the archive via the MUA (personally I don't like switching back and forth between the MUA and the browser). I think it's also possible to configure IMAP servers like Cyrus to function as list archives, but I'm not sure about how to configure MUAs for that architecture. (Note that IETF is the kind of place where people are always experimenting and don't hesistate to rewrite applications to test it. But I thought the idea was cool.)
Choice of full-text indexing backend is important. We default to Whoosh because it's pure Python and just a pip away. We recommend Xapian for production, but I don't think we thought terribly carefully about it. The Django-Haystack project appears to recommend Solr or ElasticSearch for Haystack 2.0.0 (and these are "included" in Haystack 2.0,0, not sure what that means, while Xapian is a separate download). I don't think we support Haystack 2 yet, but surely we will.
Colleagues who are new to mailing lists will need training and encouragement in netiquette. Reply style (top vs interlinear) is mentioned above. Mailing lists are prone to branching threads. Members need to learn to (1) change the subject when mutating the topic so that subthreads can be distinguished and (2) use new posts to start a new topic (ie, "don't hijack threads"). You write that GitLab collaboration has been successful for you, so it may be that your discussions are usually quite linear, and (1) may not be so important for you.
Some people (like me :-) may take naturally to "long form", which is enabled by mailing lists. Others may find long, discursive posts annoying. Be sensitive to people who have different preferences.
Some posters will tend to combine several somewhat related issues in one post, which naturally leads to many branches into subthreads. This likely will work itself out, but it can be a point of irritation for some users. Just remember that mailing lists afford that style of posting more so than forums or tracker issues do.
Remember that email is not adapted to modern affordances such as live editing. Nor is it suitable for realtime interactions such as incident response. Often it will be obvious, but sometimes it will take some time to work out which channels are well-served by mailing lists and which need an alternative medium.
In general, just remember that people will respond to the change in different ways, and the goal is to improve communication, not to get people to adapt to a particular notion of "how it *should* work".
Steve
-- GNU Mailman consultant (installation, migration, customization) Sirius Open Source https://www.siriusopensource.com/ Software systems consulting in Europe, North America, and Japan
On 31 Aug 2025, at 10:54, Stephen J. Turnbull <steve@turnbull.jp> wrote:
Thank you Stephen for your response; lots of great tips/recommendations!
While (obviously :-) I support the use of mailing lists for collaboration and have used them successfully in multiple contexts for decades, you should pay careful attention to the user experience.
Absolutely, I’m currently gathering information to ensure that the transition goes as smoothly as possible.
- Make sure that users have access to good threading in their MUAs. Gmail "conversations" aren't a great model; that's about the minimum capability. You may also want to provide a corporate webmail server. I can't recommend a good one; we just decommissioned ours in favor of IMAP access because everybody has a personal MUA with a better UI. (I think we're using Cyrus imapd suite.)
Currently I’m recommending mail.app for our mac users and thunderbird for windows. Our teams are not particularly technical. It’s truly rare to find GUI email clients which show threads properly (who answered to what message precisely). Going through the options here (https://useplaintext.email/) for non technical users, it’s hard to find good solutions.
- More important than wiping out top-posting is that everyone agree on style.
For now, I have settled on the practices suggested by the LKML. We will modify these to fit our specific needs as we notice they are lacking.
- The HyperKitty archiver was designed with the "we demand Discord" crowd in mind.
I find that HyperKitty is difficult to read - the indentation on threads is not clear enough to understand complicated threads. I find it very useful to see a graph which shows the precise hierarchy of a thread. From an archive I’m looking only for ease of navigation, robust search and easily being able to send a link to a particular message, I find that https://lkml.org/lkml/2008/7/4/174 has a super clear archive.
The idea of IETF's MailArchive is really cool. Although I don’t find it the easiest to navigate, it’s easy to add that server to your MUA to navigate however you like.
- Colleagues who are new to mailing lists will need training and encouragement in netiquette. Reply style (top vs interlinear) is mentioned above. Mailing lists are prone to branching threads. Members need to learn to (1) change the subject when mutating the topic so that subthreads can be distinguished and (2) use new posts to start a new topic (ie, "don't hijack threads"). You write that GitLab collaboration has been successful for you, so it may be that your discussions are usually quite linear, and (1) may not be so important for you.
These are some really great points. Especially when it comes to best practices for subject lines. If you know of any good netiquette practices which have been documented (à la https://subspace.kernel.org/etiquette.html) please let me know!
- Some posters will tend to combine several somewhat related issues in one post, which naturally leads to many branches into subthreads. This likely will work itself out, but it can be a point of irritation for some users. Just remember that mailing lists afford that style of posting more so than forums or tracker issues do.
For sure! That is why having an archive which makes it easy to understand the hierarchy of the subthreads is critical.
GNU Mailman consultant (installation, migration, customization) Sirius Open Source https://www.siriusopensource.com/ Software systems consulting in Europe, North America, and Japan
We are looking for a service which would host and manage our mailing list setup (like mailmanlists.net). If you own or run such a service, we are interested in being a client! Please let me know!
Rodrigo
Rodrigo Camacho writes:
Currently I’m recommending mail.app for our mac users and thunderbird for windows.
Mail.app has a very annoying bug and a minor lacking feature. They probably won't affect you at all, but just in case:
Mail.app can produce "MUST NOT" mail, specifically it will specify Content-Transfer-Encoding: quoted-printable on multipart messages and parts. Mailman (2.1 as well as 3) will reject that. Since it is implemented in the Python stdlib, it's a wontfix for us. It's rare, so just be aware that if somebody's mail gets occasionally rejected at the SMTP level (not Mailman moderation), that might be the cause. I don't have a work around for users.
Mail.app cannot handle encapsulated message/rfc822 parts, at least on handheld devices like iPhone and iPad. This annoys me NO END :-) because I originated the "wrapped" option for DMARC mitigation. But in practice nobody uses it, so ... don't you either. ;-)
It’s truly rare to find GUI email clients which show threads properly (who answered to what message precisely).
It's weird: JWZ threading (https://www.jwz.org/doc/threading.html) was standardized for IMAP (RFC 5256) and I believe both Cyrus and Dovecot implement that extension. But I'm an Emacs person, so I rarely have a clue what developers of "popular" user clients think is good UI. I just know they pretty much invariably do something else.
For now, I have settled on the practices suggested by the LKML. We will modify these to fit our specific needs as we notice they are lacking.
Seems reasonable.
- The HyperKitty archiver was designed with the "we demand Discord" crowd in mind.
I find that HyperKitty is difficult to read - the indentation on threads is not clear enough to understand complicated threads.
I'll keep that in mind. I don't know if any of the active devs deeply understand HyperKitty (it was a contribution by Red Hat, once they had it where they wanted, the devs became much less active). But it might be as simple as new CSS, or maybe new templates and a little CSS.
I find it very useful to see a graph which shows the precise hierarchy of a thread. From an archive I’m looking only for ease of navigation, robust search and easily being able to send a link to a particular message, I find that https://lkml.org/lkml/2008/7/4/174 has a super clear archive.
That *is* *very* nice. Perhaps that archiver is open source, If not, it might not be hard to substitute similar page templates in HyperKitty.
Not clear if you've already visited, so; Mailarchive (git@github.com:ietf-tools/mailarchive.git) is available from the IETF. You can check it out: https://mailarchive.ietf.org/. If you don't know what else to search for, there's a list named "ietf" to see the list-level interface.
If you know of any good netiquette practices which have been documented (à la https://subspace.kernel.org/etiquette.html) please let me know!
Well, there's always ESR's how to ask questions: https://www.catb.org/~esr/faqs/smart-questions.html, but I think of that more as a threat than advice. There are a lot of netiquette posts out there. I love Brad Templeton's "Emily Postnews Answers Your Questions About Netiquette" (https://www.templetons.com/brad/emily.html), but it might be a little too tongue in cheek for the young'uns.
We are looking for a service which would host and manage our mailing list setup (like mailmanlists.net). If you own or run such a service, we are interested in being a client! Please let me know!
First look at https://wiki.list.org/COM/Mailman%20hosting%20services, On that list EMWD was the odds-on recommendation, as the previous proprietor Brian was a frequent contributor to the lists and had a lot of support from their users. They were early adopters of Mailman 3 among hosting services and Brian went to the extent of creating alternative (simplified, proprietary) web UIs for archiving and administration. They also support Postorius and HyperKitty, I think.
The principal of the mailman3.com and mailman4.com services (same dude) also regularly contributes on the lists, but I don't have direct knowledge of their services.
I have nothing good or bad to say about the other services, I assume most are competent. Most use something like cPanel, and many are not Mailman specialists. Make sure they provide Mailman 3; not all do because cPanel decided to port Mailman 2.1 to Python 3 rather than make all their users migrate to Mailman 3.
For custom and managed services, see https://wiki.list.org/COM/Mailman%20consulting%20services. Can't really be specific, because it's not clear at this point what you might want from a managed service that a list hosting service wouldn't provide. If you're not clear about yourself and want to explore what a managed service might do, we can discuss that here to the extent it would be of general interest.
As for Sirius, yes, we're open for business, and I'm happy to talk about how Sirius Open Source can work with you offlist. See also https://www.siriusopensource.com/en-us/opensource/mailman.
Steve
-- GNU Mailman consultant (installation, migration, customization) Sirius Open Source https://www.siriusopensource.com/ Software systems consulting in Europe, North America, and Japan
participants (3)
-
Dave McGuire -
Rodrigo Camacho -
Stephen J. Turnbull