Search results for "sapiro" - lists.mailman3.org

[MM3-users] Re: Server 500 error for just one list, just one page

by Mark Sapiro

On 6/28/20 4:05 PM, kelly.close(a)lrewater.com wrote: > I am having a curious problem with just ONE list management page for ONE list on my server. Every other list I've checked, and every other management page for this affected list, seem fine. But when I go to the Subscribers page for this one list I get a Server 500 error, and I can't find anything in the apache or mailman logs to give me a clue (granted I'm not sure I know for sure where all the different logs are). Neither do I, but you want to look in Mailman core's mailman.log and Django's log. mailman.log is in a directory with others including smtp.log and subscribe.log. If you don't know where to find that, look in the output from `mailman conf`. The first thing to look for is [mailman] layout: which will have a value like `fhs`, `dev`, `here` or `local`. then look at [paths.xxx] log_dir: where xxx is the layout value, and if that includes $var_dir, look at [paths.xxx] var_dir: For the Django log look in settings_local.py and settings.py or whatever they're called in your case for LOGGING['handlers']['file']['filename'] > So specifically this page: https://udfcd-lists.org/mailman3/postorius/lists/alarms-all.udfcd-lists.org… That page should be the same as <https://udfcd-lists.org/mailman3/postorius/lists/alarms-all.udfcd-lists.org…>. Can you go there? Where are you finding that link? What postorius version is this? -- Mark Sapiro <mark(a)msapiro.net> The highway is for gamblers, San Francisco Bay Area, California better use your sense - B. Dylan

6 years, 3 months

[MM3-users] Re: Block members from sending cc's and bcc's

by Mark Sapiro

On 11/6/25 16:21, Cathryn McGuire wrote: > Many of them say: > > 1. The message is being held because: > > Message has more than 1 recipients I don't know where in affinity you find this setting, but there is a setting for Maximum number of recipients which is set to one and that is exceeded. This setting may be intentional on your part. > Post to a moderated newsgroup gateway There are also settings for a newsgroup gateway. These settings should be Gateway to mail No Gateway to news No Linked Newsgroup empty Newsgroup moderation not moderated It appears in your case that Gateway to news is Yes and Newsgroup moderation is Moderated. > But there's no cc showing. Could be a bcc, but we wouldn't be able to tell. We don't think so, though. > > 2. The following are new today (makes us wonder if EMWD is working on something): > > The message is being held because: > > Header "neighbours > <neighbours(a)mailist.dunbar-vancouver.org>" matched a > header rule > > Saw the cc when we opened the message. Was the Cc: to <neighbours(a)mailist.dunbar-vancouver.org>? If so this is a match to your Cc: header filter, and the reason should be Header "cc: <neighbours(a)mailist.dunbar-vancouver.org>" matched a header rule. If the reason was actually what is posted above with 'neighbors' rather than 'cc:', that's a problem with EMWD's Mailman core. -- Mark Sapiro <mark(a)msapiro.net> The highway is for gamblers, San Francisco Bay Area, California better use your sense - B. Dylan

11 months, 1 week

[MM3-users] Re: Upgrade Mailmam Core from

by Mark Sapiro

On 9/28/22 23:18, sascha.rissel(a)gmail.com wrote: > > After this, I deleted the venv again and startet anew, again. > But this time, I explicitly did (as Stephen suggested above) >> pip install wheel > prior to >> pip install wheel mailman psycopg2-binary\<2.9 > > This time, it ran through without errors, although "wheel" is also contained in the latter command. > Can you explain that? Apparently, if you run `pip install wheel mailman psycopg2-binary\<2.9` pip attempts to build `lazr.delegates` which is a `mailman` dependency before it fully installs `wheel`. Thus the need to `pip install wheel` first. However, with both `virtualenv 20.0.17/python 3.8.10` and `virtualenv 20.4.2/python 3.9.10` `virtualenv venv` installs `wheel` in site-packages in the venv as does `python3 -m virtualenv venv`, but `python3 -m venv venv` does not. But, at least in my case, with venv built with `python3 -m venv venv` and not containing `wheel` in `site-packages` `pip install wheel mailman psycopg2-binary\<2.9` runs without error. > Second question: > There is still no directory "/etc/mailman3" created, where I can create mailman.cfg in. > Does this maybe result from the fact that in first instance, I tried to install mailman3-full via "apt-get install" and removed it again via "apt-get remove"; with manually deleting /etc/mailman3 afterwards. > > Shall I create /etc/mailman3 manually and adding "mailman" system user permissions? Yes, as the doc says at https://docs.mailman3.org/en/latest/install/virtualenv.html#installing-mail…, "After this, create a configuration file at /etc/mailman3/mailman.cfg for Mailman Core:" -- Mark Sapiro <mark(a)msapiro.net> The highway is for gamblers, San Francisco Bay Area, California better use your sense - B. Dylan

4 years

[MM3-users] Re: Mailman and Postfix Conflicting Information

by Mark Sapiro

On 2/6/26 10:49, dap1--- via Mailman-users wrote: > mailman.log > > Feb 06 10:33:50 2026 (137333) ACCEPT: <ed25cdc2-81ea-4e9a-a9f3-03e5aab685ff(a)myisp.net> Mailman Accepted the message. > Feb 06 10:33:53 2026 (137328) HyperKitty archived message <ed25cdc2-81ea-4e9a-a9f3-03e5aab685ff(a)myisp.net> to https: > //gmail.com/archives/list/llllllllll(a)gmail.com/message/DVXWCJVGONYAXYHWSYKVZJABR3OG5SDT/ And HyperKitty archived it. > smtp.log > > Feb 06 10:33:49 2026 (137334) Available AUTH mechanisms: LOGIN(builtin) PLAIN(builtin) > Feb 06 10:33:49 2026 (137334) Peer: ('127.0.0.1', 34218) > Feb 06 10:33:49 2026 (137334) ('127.0.0.1', 34218) handling connection > Feb 06 10:33:49 2026 (137334) ('127.0.0.1', 34218) >> b'LHLO dap002.localdomain' > Feb 06 10:33:49 2026 (137334) ('127.0.0.1', 34218) >> b'MAIL FROM:<uuuu(a)myisp.net> SIZE=10502' > Feb 06 10:33:49 2026 (137334) ('127.0.0.1', 34218) sender: uuuu(a)myisp.net > Feb 06 10:33:49 2026 (137334) ('127.0.0.1', 34218) >> b'RCPT TO:<lllllllll(a)gmail.com>' > Feb 06 10:33:49 2026 (137334) ('127.0.0.1', 34218) recip: clllllllll(a)gmail.com > Feb 06 10:33:49 2026 (137334) ('127.0.0.1', 34218) >> b'DATA' > Feb 06 10:33:49 2026 (137334) ('127.0.0.1', 34218) >> b'QUIT' > Feb 06 10:33:49 2026 (137334) ('127.0.0.1', 34218) connection lost > Feb 06 10:33:49 2026 (137334) ('127.0.0.1', 34218) Connection lost during _handle_client() > > Hmmmm. Connection lost? Those Connection lost messages are normal and expected as a result of the QUIT command. However, missing are messages like smtp to lllllllll(a)gmail.com for nn recips, completed in nn.nn seconds post to lllllllll(a)gmail.com from uuuu(a)myisp.net, nnn bytes Is Mailman's out runner running? Are messages queued in Mailman's var/queue/out/ directory? -- Mark Sapiro <mark(a)msapiro.net> The highway is for gamblers, San Francisco Bay Area, California better use your sense - B. Dylan

8 months, 1 week

[MM3-users] Re: Moderation Action Changed After Import

by Mark Sapiro

> > I can't confirm what was set on the old MM2 list as it is no longer > accessible. I am just going on the word of the List Owner. My opinion is > that the moderation for those list members were set to Reject on the > previous MM2 list. I am mainly interested to see if you know of this > happening to anyone else and/or perhaps there is an existing bug that > could impact the moderation settings of imported MM2 lists. If you have the config.pck and any MM 2.1 installation, you can get all the info from the config.pck. For example > /path/tp/mm2.1/bin/dumpdb /path/to/config.pck|grep member_moderation_action will show the setting with 0 = Hold, 1 = Reject and 2= Discard. Finding which members are moderated is more difficult as there is a dictionary named user_options with keys = to email addresses and integer values and the integer is a bit field defined as follows (from Defaults.py) > # Bitfield for user options. See DEFAULT_NEW_MEMBER_OPTIONS above to set > # defaults for all new lists. > Digests = 0 # handled by other mechanism, doesn't need a flag. > DisableDelivery = 1 # Obsolete; use set/getDeliveryStatus() > DontReceiveOwnPosts = 2 # Non-digesters only > AcknowledgePosts = 4 > DisableMime = 8 # Digesters only > ConcealSubscription = 16 > SuppressPasswordReminder = 32 > ReceiveNonmatchingTopics = 64 > Moderate = 128 > DontReceiveDuplicates = 256 However, to address your concern, As far as I know, import21 is doing the right thing. If you want to send me the config.pck you imported, I can try to verify that. -- Mark Sapiro <mark(a)msapiro.net> The highway is for gamblers, San Francisco Bay Area, California better use your sense - B. Dylan

5 years, 8 months

[MM3-users] Re: REST API authorization failed

by Mark Sapiro

On 1/9/22 5:57 AM, Axel Rau wrote: >> >> Does the `mailman info` command report what you think for REST credentials? > yes. ... > I used curl: > - - - > (mailman_33) [root@lists5 /usr/local/mailman3]# curl -v -u restadmin:??? http://localhost:8001/3.1/lists > * Trying 127.0.0.1:8001... > * Connected to localhost (91.216.35.42) port 8001 (#0) > * Server auth using Basic with user 'restadmin' >> GET /3.1/lists HTTP/1.1 >> Host: localhost:8001 >> Authorization: Basic cmVzdGFkbWluOnc2cmtuQXpJZmVRc1o4WnlkMFpBcmNjcm55OA== >> User-Agent: curl/7.80.0 >> Accept: */* >> > * Mark bundle as not supporting multiuse > < HTTP/1.1 401 Unauthorized > < Server: gunicorn > < Date: Sun, 09 Jan 2022 13:51:43 GMT > < Connection: close > * Authentication problem. Ignoring this. > < www-authenticate: Basic realm="mailman3-rest",charset="utf-8" > < content-type: application/json > < vary: Accept > < content-length: 77 > < > * Closing connection 0 > {"title": "401 Unauthorized", "description": "REST API authorization failed“} > - - - > I see "Server: gunicorn“, does this mean, I must install gunicorn? As you later reported, gunicorn is installed. It is installed as a dependency of Mailman core to serve as the REST server which is what's going on here. It also may or may not be used as the wsgi server for Django depending on how you configured that, but this is independent. Anyway, the above is saying that restadmin:??? doesn't match what's configured in Mailman core and reported by `mailman info`. Please check carefully that these are the same in both mailman.cfg admin_pass and settings MAILMAN_REST_API_PASS. -- Mark Sapiro <mark(a)msapiro.net> The highway is for gamblers, San Francisco Bay Area, California better use your sense - B. Dylan

4 years, 9 months

[MM3-users] Re: Postfix Hooks and Fetchmail

by Mark Sapiro

On 11/13/25 10:25, dap1--- via Mailman-users wrote: > I am not understanding the documentation. I already have this in my main.cf: > > transport_maps = hash:/opt/mailman/var/data/postfix_lmtp > local_recipient_maps = hash:/opt/mailman/var/data/postfix_lmtp > relay_domains = hash:/opt/mailman/var/data/postfix_domains > > What is not explained is where/how to add the alias_domain parameter. Does it go in /opt/mailman/var/data/postfix_domains? Is it added as a new domain or as an append to the existing domain line? The doc says in part "In order to enable this configuration, Mailman domains have an alias_domain attribute." In that sentence, `domains` is a link. did you follow it? In any case, the alias_domain is added to the existing ddddddddd.net entry at https://localhost/mailman3/domains/ or if you can't do that it is added to the domain table in the mailman database, e.g. UPDATE domain SET alias_domain = 'localhost' WHERE mail_host = 'ddddddddd.net'; After doing that, run `mailman aliases` to update the postfix files in /opt/mailman/mm/var/data including generating a new postfix_vmap file As far as Postfix is concerned, I don't know what's unclear about https://docs.mailman3.org/projects/mailman/en/latest/src/mailman/docs/mta.h… but what you need to do is leave the current transport_maps and relay_domains as is, but add virtual_alias_maps = hash:/opt/mailman/var/data/postfix_vmap and as long as your list domain is only ddddddddd.net you can remove the local_recipient_maps setting, but see the note at the end of the https://docs.mailman3.org/projects/mailman/en/latest/src/mailman/docs/mta.h… section. -- Mark Sapiro <mark(a)msapiro.net> The highway is for gamblers, San Francisco Bay Area, California better use your sense - B. Dylan

11 months

[MM3-users] Re: Held messages not delivered after approval

by Mark Sapiro

On 8/4/25 00:21, Krinetzki, Stephan wrote: >> >> And for every one of those shunted messages there should be an exception with traceback logged in mailman.log. Those tracebacks should be helpful. > > If there were any. Maybe the "debug" level should be "info". But for which logs? The standard logging levels from lowest to highest are debug info warning error critical Whatever level is set for a log results in all messages of that level or higher being logged. I.e. if the log's level is debug, all messages for that log of any level should be logged. For every shunted message, a message like `SHUNTING: <file name without the .pck extention>` preceded by the exception and traceback is logged to error.log with level error. See https://gitlab.com/mailman/mailman/-/blob/master/src/mailman/core/runner.py… > Maybe the restart at night after the lograte maybe the issue. As I said before, blindly restarting Mailman is a bad idea. On servers that I maintain, I always verify that all queues are empty before stopping or restarting Mailman. If necessary, I'll kill the incoming runner and wait for the out queue to empty and then stop mailman. If you want to do this daily, you could automate that., e.g. ``` if queues empty: restart Mailman else: when in queue is empty, sigterm incoming runner when out queue is empty, stop Mailman when Mailman stopped, start Mailman ``` The stop/start is needed because a simple restart at that point won't start the sigtermed incoming runner. -- Mark Sapiro <mark(a)msapiro.net> The highway is for gamblers, San Francisco Bay Area, California better use your sense - B. Dylan

1 year, 2 months

[MM3-users] Re: Outgoing messages fro Mailman fails DMARC

by Mark Sapiro

On 04/10/2018 02:18 AM, Henrik Rasmussen wrote: > I have set up Postfix to DKIM sign outgoing mails from GNU Mailman 3.2.0a1 which validates nicely ("dkim=pass (signature was verified)"), but DMARC fails ("dmarc=fail action=none") on the recipient end, probably because the "header.from=gmail.com;" (or similar) which means that DKIM d= will not match. Right. DMARC deals with the From: domain. For DMARC to pass, either a valid DKIM sig or SPF with domain 'aligned' with the From: domain must be true. I.e., your DKIM sig and/or SPF won't do if the From: domain is not your domain. > According to dmarc.org*) "Mailing lists usually do not take authorship of the emails they relay" so I should "consider to apply specific rules for emails coming from mailing lists". Also according to dmarc.org*) Mailman (Mailman 2 that is, and I presume Mailman 3 does too) "include features to interoperate with DMARC senders". > > I assume that the dmarc mitigations list settings in Mailman is for incoming messages, but how do I set Mailman to cope with this on outgoing messages? I'm not sure I understand what you are saying. Mailman's (both 2 and 3) DMARC mitigations allow modifying the outgoing message in some or all cases so the From: domain is the list's domain so the message won't be dealt with by the recipient MTA according to the original From: domain's DMARC policy. See <https://wiki.list.org/DEV/DMARC>. Also, <https://wiki.list.org/x/17891458> may be of interest. -- Mark Sapiro <mark(a)msapiro.net> The highway is for gamblers, San Francisco Bay Area, California better use your sense - B. Dylan

8 years, 6 months

[MM3-users] Re: Importing Mailman 2 Lists apart from Django

by Mark Sapiro

On 4/30/20 7:59 AM, Brian Carpenter wrote: > Hello Mailman Users, > > Are there instructions on importing a Mailman 2 list into a Mailman 3 > core installation only? Does the import21 script not need > Django/Postorius/Hyperkitty? import21 requires only Mailman core. > It seems Django is required to import archives I guess because of the > use of Hyperkitty. How about importing archives without having a Django > installation? Is that what the prototype archiver for? The only current archive import we support is `django-admin hyperkitty_import` which imports archive .mbox files into HyperKitty. The prototype archiver is just a maildir format collection of messages. Converting an mbox file to a maildir is trivial. from mailbox import Maildir, mbox mb = mbox('/path/to/mbox', create=False) md = Maildir('/path/to/maildir', create=True) for msg in mb: md.add(msg) > We are getting ready to start working on a custom forum application for > Mailman 3 (called Empathy) and I am would like to import some mailman 2 > archives into the development server to work with. First you have to decide how Empathy will store messages. Look at <https://gitlab.com/mailman/hyperkitty/-/blob/master/hyperkitty/management/c…>. This is how HyperKitty gets messages from a mbox and adds them to its database. It's actually fairly simple - a lot of the code is handling exceptions due to defective messages. Presumably Empathy will have a method for adding a message to the archive, so importing is just getting messages from the mbox and using Empathy's method to add it. -- Mark Sapiro <mark(a)msapiro.net> The highway is for gamblers, San Francisco Bay Area, California better use your sense - B. Dylan

6 years, 5 months

Search results for query "sapiro"