Mailman 3 October 2020 - Mailman-Users

Migrating Mailman Lists from One Server to Another
by Onyeibo Oku Nov. 15, 2020

Nov. 15, 2020

Greeting, Is there a recommended a stable or reliable approach for migrating Mailman lists from one server to another? I have tried two methods already and, in both cases, the resulting lists were buggy. The source lists are not live (i.e. old server/host is no longer accessible). However, we copied all files/folders from the previous /var/lib/mailman/ to a folder in our new server. I guess the scenario rules out Method-#1 described on https://wiki.list.org/DOC/4.70%20How%20do%20I%20change%20the%20name%20of%20… I also tried the steps illustrated on https://debian-administration.org/article/567/Migrating_mailman_lists. That gave me lots of errors pertaining to permissions despite running 'check_perms -f' (makes me wonder what the recommended permissions/ownership for files in /var/lib/mailman/ would be). In the end, the lists were visible via the web interface but I couldn't log into administration from there (I got an error page ... something about Mailman being buggy). Some other pages wouldn't open too. I got similar results after following https://www.mail-archive.com/mailman-developers@python.org/msg03127.html Method #2 at https://wiki.list.org/DOC/4.70%20How%20do%20I%20change%20the%20name%20of%20… sounds appealing. I tried the script but python2 was looking for a path module. Is that script still supported? In any case, I'd appreciate any help I can get to bring our lists back online. Regards Onyeibo

2 5

Can not find the "msgid" for a specific mail for mailman administrator.
by Masaharu Kawada Oct. 28, 2020

Oct. 28, 2020

Dear mailman-users list, I have a question on how to modify the content of mail sent out to mailman administrator. Looking into /usr/lib/mailman/messages/ja/LC_MESSAGES/mailman.po, the following two lines can be found. 1. msgid "%(realname)s moderator request check result" 2. msgid "" "Notice: %(discarded)d old request(s) automatically expired.\n" The first line looks to be the mail title and the second line looks to be the content of the mail titled with the "%(realname)s moderator request check result" as the first line. However, I can not find the "msgid" in the second line in anywhere like /etc/mailman/templates/en/* where I think the "msgid(s)" used for mail content are supposed to be filed under /etc/mailman/templates/en/ directory such as /etc/mailman/templates/en/checkdbs.txt. To modify the "msgid" in the second line from "Notice: %(discarded)d old request(s) automatically expired.\n" to something other than that, I need to find out where the "msgid" is. Could anyone in the list give me a help on this? Thanks, Masaharu

2 2

Group Mismatch Error
by Dennis Putnam Oct. 25, 2020

Oct. 25, 2020

I am getting this error: <cufsalumni(a)localhost.localdomain> (expanded from <cufsalumni@localhost>): Command died with status 2: "/usr/lib/mailman/mail/mailman post cufsalumni". Command output: Group mismatch error. Mailman expected the mail wrapper script to be executed as group "nobody", but the system's mail server executed the mail script as group "mailman". Try tweaking the mail server to run the script as group "nobody", or re-run configure, providing the command line option `--with-mail-gid=mailman'. When I upgraded to this version of Mailman (2.1.34) I specified the configure options per the article (https://wiki.list.org/x/17892071) for RHEL. The group for '/usr/lib/mailman/mail/mailman' is indeed 'nobody'. What is this error trying to tell me. It is not clear what wrapper it is talking about since the group on the indicated script is correct.

2 4

Re: Settings for "monthly password reminders", etc.
by H Ian Zhang Oct. 23, 2020

Oct. 23, 2020

Thank you for the explanations, Mark. We'll be able to live with the settings as they are, no problem. :) Regards: Ian Zhang

1 0

Settings for "monthly password reminders", etc.
by H Ian Zhang Oct. 23, 2020

Oct. 23, 2020

Hello Mark, we are testing a new mailing list (our provider currently makes Mailman 2.1.33 available). On the "General Options" page for the list, there is the setting "Send monthly password reminders?" We set this to "No" when we configured the list (before we had any subscribers). Now we have a few test subscribers. When they log in to their respective subscription pages, they will find the setting "Get password reminder email for this list?" And in all observed cases this is set to "Yes". Similarly, on the "Digest Options" page there is the setting "When receiving digests, which format is default?" And regardless of whether this is set to "Plain" or "Mime", subscribers logging in to their respective subscription pages will see there the same parameter invariably set to "Mime". In terms of logic, this is an unsatisfactory situation: either, if the general settings overrule individual setting, then subscribers are being misled, because they think they have choices when they actually don't, or, if the individual settings have precedence, then list managers are being misled, because they are given the impression that they are controlling certain paramaters when they actually don't. What are we overlooking here? Thank you in advance for your assistance! Regards: Ian Zhang --

2 1

Settings for "monthly password reminders"
by H Ian Zhang Oct. 23, 2020

Oct. 23, 2020

Hello Mark, we are testing a new mailing list (our provider currently makes Mailman 2.1.33 available). On the "General Options" page for the list, there is the setting "Send monthly password reminders?" We set this to "No" when we configured the list (before we had any subscribers). Now we have a few test subscribers. When they log in to their respective subscription pages, they will find the setting "Get password reminder email for this list?" And in all observed cases this is set to "Yes". Similarly, on the "Digest Options" page there is the setting "When receiving digests, which format is default?" And regardless of whether this is set to "Plain" or "Mime", subscribers logging in to their respective subscription pages will see there the same parameter invariably set to "Mime". In terms of logic, this is an unsatisfactory situation: either, if the general settings overrule individual setting, then subscribers are being misled, because they think they have choices when they actually don't, or, if the individual settings have precedence, then list managers are being misled, because they are given the impression that they are controlling certain paramaters when they actually don't. What are we overlooking here? Thank you in advance for your assistance! Regards: Ian Zhang --

1 0

Re: 7bit vs. 8bit settings / http vs https
by H Ian Zhang Oct. 22, 2020

Oct. 22, 2020

Thank you for the specifics on both questions, Mark! I'll follow up accordingly. > If you as list admin set the list's preferred language to French, > the charset will be iso-8859-1. The list will only carry messages in English and French, so this looks like a good option. If you don't see follow-up questions here it means we fixed the problems. :) Regards: Ian Zhang

1 0

http vs https
by H Ian Zhang Oct. 22, 2020

Oct. 22, 2020

Hi again, we also noticed that subscribed users receive a descriptive message with such entries as General information about the mailing list is available at: [URL1] and If you want to change your options (eg, switch to or from digest mode, temporarily stop delivery of list message to your address, etc.), please visit your subscription page at: [URL2] There is a problem, howevdr, since [URL#] starts with 'http', while the domain of the new list has the certificate for secure connections, and URLs starting with 'https' therefore work - and the use of 'https' is very much desired. As I mentioned, we have no control over the server, but is there a way for our provider to have all relevant URLs start with 'https'? Thanks again and regards: Ian Zhang

2 1

7bit vs. 8bit settings
by H Ian Zhang Oct. 22, 2020

Oct. 22, 2020

Hi, when setting up a new mailing list on a rented (shared) server, we noticed that French accented letters are dropped. The "hidden" headers tell us the following: Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Mailman 2.1.33 Can this setup be changed (technoically speaking) to "UTF-8" and 8bit encoding? We have no control over the serverm, but the provider's support team is responsive and helpful - how would I best ask them to make the change to UTF-8 happen? Thanks in advance! Regards: Ian Zhang

2 1

Re: How to prevent moderation queue from rewriting From:-field?
by Thomas Gramstad Oct. 19, 2020

Oct. 19, 2020

On Sun, 18 Oct 2020, Mark Sapiro wrote: > On 10/18/20 2:12 PM, Thomas Gramstad wrote: >> When a message to one of my unmoderated lists for some reason ends up in >> the moderation queue and I approve it, somehow the From:-field is >> rewritten like this: >> >> >> ---------- Forwarded message ---------- >> From: Helge Høivik via Biblioteknorge >> <biblioteknorge(a)mailman.kunnskapsallmenning.no> >> >> >> How can I prevent this from happening, so that the original From: field >> is preserved unchanged, as if the message went straight through to the >> list? > > This appears to be DMARC mitigation. What are your settings for General > Options -> from_is_list x No > and Privacy options... -> Sender filters -> dmarc_*moderation_action ? x Munge From Yeah, that's it. I suppose I could change that to Accept? But I found out that this is not a problem, because Reply-To: still works the way it should. The via thing does not degrade Reply-To: (unlike something similar-looking in Eudora some years ago). > Note that if this From: munging only occurs on messages which are held for > moderation and approved and does not happen for messages From: the same > address which are not held for moderation then I don't understand what could > be the cause. (No, the original sample size was too small.) Thanks, Thomas Gramstad

2 1