Our company is evaluating mailman3 as an option for company internal list serving.
One of the requirements is that anyone with access to the list server be allowed to create and manage lists.
Is this possible? If so, how? Is there a "create list" role that can be added for all registered users?
I'm in an odd situation where I need to rename a bunch of lists. They
were all created on mailman2 originally and migrated to mailman3 (very
successfully, TYVM) but the names were all originally
discuss-<foo>@domain and it's very confusing to be sure you're always
sending to the correct <foo>. We want to completely rename the lists to
These lists do not keep archives, so if I have to resort to extracting
the subscriber lists and the configs and building new lists, I'm
completely fine with that. Problem is, I'm really used to MM2 and
config_list and could do this without thinking using those tools... that
I don't have.
Running MM3 3.2.2 trying to make this happen. Any assistance I could
get will be greatly appreciated.
Web Administrator, Alpha Psi Omega Grand Cast
etc... etc... etc...
I am trying to download a complete list mbox by going to all threads view and using the download option. I have tried a couple of tools (Gunzip and Winrar) and both are giving me an unexpected end of file when trying to decompress the gz file.
Here is the list URL I am using: https://email@example.com…
A new user tried to subscribe to a mailinglist, received the confirmation
mail, and replied to it.
The subscriber is however not subscribed and remains listed in the "pending
The following exception appears in the error.log.
Does anyone knows how to resolve this? In the past we didn't experience any
issues and no changes but security updates have been installed.
Apr 29 16:15:55 2021 (1581) deque: do_confirm_verify
Traceback (most recent call last):
line 69, in __next__
y", line 356, in _step_send_confirmation
Apr 29 16:16:28 2021 (1490) Uncaught runner exception: Expecting ':'
delimiter: line 1 column 256 (char 255)
Apr 29 16:16:28 2021 (1490) Traceback (most recent call last):
line 173, in _one_iteration
line 266, in _process_one_file
keepqueued = self._dispose(mlist, msg, msgdata)
, line 208, in _dispose
mlist, msg, msgdata, parts, results)
m.py", line 54, in process
y", line 578, in confirm
line 146, in restore
data = json.loads(state.data)
File "/usr/lib64/python3.6/json/__init__.py", line 354, in loads
File "/usr/lib64/python3.6/json/decoder.py", line 339, in decode
obj, end = self.raw_decode(s, idx=_w(s, 0).end())
File "/usr/lib64/python3.6/json/decoder.py", line 355, in raw_decode
obj, end = self.scan_once(s, idx)
json.decoder.JSONDecodeError: Expecting ':' delimiter: line 1 column 256
Apr 29 16:16:28 2021 (1490) SHUNTING:
Thanks in advance,
I'm hoping someone can shine a light on character encoding issue I've encountered.
A plain-text email with non-ascii characters in the body gets posted to the list.
As per Mark Sapiro's guide I've captured the incoming message to file.
The message is received by Mailman with the non-ascii characters displaying correctly.
The header of that message has:
User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:78.0) Gecko/20100101
Content-Type: text/plain; charset=utf-8
In the list's mbox file and archive webpage, the message displays the non-ascii characters correctly.
In the archive's downloaded .txt (and also .gz) file, the non-ascii characters are missing and displayed as "?".
I've copied the message text in below, from both the correct one from the email and the erroneous .txt file. Hopefully they won't get scrambled up when I send this.
Any advice on getting the non-ascii characters written into the archive .txt file would be gratefully received.
=== Message text as okay in mbox and as shown on the archive webpage ===
If one goes by the definition of veḷippaṭai as given in the Tamil Lexicon that the meaning of an ambiguous word should be disambiguated by a qualifying word, then aruvi āmpal does not conform to that definition since in the case of aruvi āmpal in Patiṟṟuppattu 63, aruvi is really made up of aru+vi, a compound. Moreover, the expression aṭai aṭuppu aṟiyā is already there to clarify that āmpal is a number and not a flower. Thus, aruvi simply provides information in addition to aṭai aṭuppu aṟiyā that āmpal is not a flower. The modern commentator Aruḷampalavaṉār also does not call it veḷippaṭai.
=== Message text with missing characters in te archive's txt and gz downloads ==
If one goes by the definition of ve?ippa?ai as given in the Tamil Lexicon that the meaning of an ambiguous word should be disambiguated by a qualifying word, then aruvi ?mpal does not conform to that definition since in the case of aruvi ?mpal in Pati??uppattu 63, aruvi is really made up of aru+vi, a compound. Moreover, the expression a?ai a?uppu a?iy? is already there to clarify that ?mpal is a number and not a flower. Thus, aruvi simply provides information in addition to a?ai a?uppu a?iy? that ?mpal is not a flower. The modern commentator Aru?ampalava??r also does not call it ve?ippa?ai.
[I prefer discussion be directed to mailman-developers, so Reply-To is
set. But if you're not subscribed to -developers, following up here
is OK, and I'll eventually summarize to -developers. Just don't
followup to both.]
I just noticed that among the agents that send non-conformant long
lines is HyperKitty. Nowadays violating the 80 octet
limit is common and MUAs mostly handle it, but the 1000 octet limit is
enforced by many MTAs
I think that HyperKitty should format mail per RFC 3676 format=flowed
https://tools.ietf.org/html/rfc3676#section-4. However, I don't use
"modern" (aka crappy HTML-oriented) clients, so I don't know whether
they handle format=flowed properly.
Discussion greatly desired.
 RFC 5321: MTAs MAY impose a limit >= 1000 octets including
CRLF. RFC 5322: MUST be <= 1000 octets including CRLF, SHOULD be
<= 80 octets including CRLF.
 In practice, most (?) MTAs just break the line at 998 octets and
insert CRLF rather than reject the message. I assume they would break
happily in the middle of a multi-byte character, i.e., any non-ASCII
in a UTF-8 text.
To the Mailman community,
The GNU Mailman Steering Committee condemns the reinstatement of
Richard M. Stallman (RMS) to the Board of the Free Software Foundation
(FSF), and has taken the following actions:
1. On behalf of the GNU Mailman project, signed the letter on
GitHub calling for the removal of the entire FSF Board, as well
as RMS himself.
2. Started exploring ways to move our financial assets, for decades
managed by the FSF, to new management. The management fees are
small, but this is an important symbolic protest.
3. Started exploring how to leave the GNU Project. On the one hand,
if we leave but GNU wants to maintain a "GNU Mailman" project, we
cannot stop them, confusing users. On the other hand, RMS is
leader of the GNU Project, and has intervened in Mailman affairs
on many occasions. We should forestall this in the future.
We wish to explain our actions to the community.
Although free exchange of software among users is a practice that goes
back to days of the earliest general purpose computers, RMS was the
first to propose a complete free software distribution, and is the
acknowledged founder of the Free Software movement. Even leaders of
the Berkeley Software Distribution (BSD) acknowledge this. We all owe
him a debt for this.
Nevertheless, the movement has matured and thrived, spawning the
competitive open source movement, with whose philosophy Mailman is
more closely aligned. While we acknowledge our debt to RMS, we don't
need him any longer. And unfortunately, he has become both a symbol
and a source of the toxicity in tech communities. The FSF Board did
the right thing by accepting RMS's resignation. They did the wrong
thing by reinstating him.
RMS has a long history of abusive behavior and toxic political
positions. A small part of it is described in the open letter on
GitHub and its references, and several members of the Steering
Committee have observed it directly. All of us have heard stories
directly from those who were abused or observed it directly. His
political positions are public, for example his support of pedophiles.
He claims that he in no way supports abusive relationships with
children, yet refuses to acknowledge that children are generally in
no position to provide consent, an evasive and highly toxic position.
There is no question: RMS is toxic.
We came for mailing list management, but we stayed for the community.
We have a right to protect our community by dissociating it from toxic
We do not want our project associated with such a person, nor to
provide economic resources to organizations that promote him to
leadership positions. We are taking these actions to protect our
community, both the narrow community of Mailman developers and users,
and the broader open source community, from his toxic behavior and
from the reputational damage that will come from helping to enable
While we have no information suggesting that other members of the FSF
Board are similarly toxic as individuals, as a group they enabled RMS
for decades, and now have taken an explicit step in enabling him
again. If they want to regain their position of respect and
acceptance in our community, they must acknowledge their error, and we
don't see -- given their reinstatement of RMS himself -- how they can
do so convincingly while maintaining their positions on the Board.
They must resign, and a new Board composed, to demonstrate their
sincerity. What they do is up to them, of course, but if they do not
take radical steps, we will continue to consider association with the
FSF a threat to our community.
For the Mailman community,
Abhilash Raj (project leader)
Stephen J. Turnbull
John Viega (founder)
 Text and signatures: https://rms-open-letter.github.io
 Appendix to the letter: https://rms-open-letter.github.io/appendix
Related statements: https://rms-open-letter.github.io/statements