I see that there is a way to change the language of mailman3, postorius and hyperkitty
But I don't find how.
I read that you can download the .po files for the chosen language, but I didn't understand how to use these files.
Could anyone show me how to do it?
Thank you in advance.
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.