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

[MM3-users] Re: Problem upgrading from 2.1 to 3, dockerized

by Mark Sapiro

On 8/8/25 11:43, jesper.holck--- via Mailman-users wrote: > I recently followed the instructions here https://github.com/g4rf/dockerized-mailcow-mailman, and was able to create a new Mailman 3, Debian-based installation. I then followed the instructions here https://docs.mailman3.org/en/latest/migration.html in order to migrate from my old, Centos-based installation, to the new, Debian-based installation. It seemed to work well, but unfortunately a problem showed up. > > Whenever someone posted to one of the lists on the new installation, the messages were rejected by Postfix: > > postfix-mailcow-1 | Aug 5 20:55:48 ef2b760c2e61 postfix/cleanup[8681]: B7B856099EC: message-id=<A8946B8E-2A47-4701-9548-4544981FAC5E(a)gmail.com> > postfix-mailcow-1 | Aug 5 20:55:49 ef2b760c2e61 postfix/cleanup[8681]: B7B856099EC: milter-reject: END-OF-MESSAGE from unknown[172.22.1.1]: 5.7.1 This message does not meet our delivery requirements; from=<mylist-bounces(a)myserver.dk> to=<mylistuser1(a)gmail.com> proto=ESMTP helo=<[172.19.199.4]> > postfix-mailcow-1 | Aug 5 20:55:50 ef2b760c2e61 postfix/cleanup[8681]: 216D36099EC: message-id=<A8946B8E-2A47-4701-9548-4544981FAC5E(a)gmail.com> > postfix-mailcow-1 | Aug 5 20:55:50 ef2b760c2e61 postfix/cleanup[8681]: 216D36099EC: milter-reject: END-OF-MESSAGE from unknown[172.22.1.1]: 5.7.1 This message does not meet our delivery requirements; from=<mylist-bounces(a)myserver.dk> to=<mylistuser2(a)mail.dk> proto=ESMTP helo=<[172.19.199.4]> The above messages are not messages normally seen from Postfix. They apparently come from some mailcow milter. > So, for each of the existing lists, I had to delete the old list and create a new one - with the same name and the same users. After this, everything seems to work as expected. I can think of nothing that `mailman import21` would do that would be different from creating a list, configuring it and adding members. Since you are following a third party how-to, please see https://wiki.list.org/x/12812344 - perhaps reporting this at https://github.com/g4rf/dockerized-mailcow-mailman/issues would be appropriate. -- Mark Sapiro <mark(a)msapiro.net> The highway is for gamblers, San Francisco Bay Area, California better use your sense - B. Dylan

9 months

[MM3-users] Re: Mailman rewrite the Cc header incorrectly

by Mark Sapiro

On 5/26/20 9:10 PM, Alan So wrote: > Thanks again for the work and just notice that the issue has been closed already. Looks like unfolding the header line is a logical way but it seems that >=3.3 email package unfold the header before parsing the header according to the following python issue: > > https://bugs.python.org/issue11050 Yes, the issue is closed because the fix has been merged and will be in Mailman Core 3.3.2. I agree that it appears that there would have been no issue if Mailman created messages using the `SMTP` policy and retrieved the addresses using the `addresses` attribute of the headers. However, for historical reasons, Mailman Core still uses the `compat32` policy (Python 3.2 compatibility) and uses `email.utils.getaddresses()` to get the addresses from the header value, so the "fix" for <https://bugs.python.org/issue11050> doesn't apply. Changing Mailman Core to use email.EmailMessage() objects rather than the legacy email.Message() objects is a worthwhile goal, but would require extensive changes to fix all the things that broke as a result. Anyway, I really appreciate your diligence in following through repeatedly on this issue. Were it not for that, I wouldn't have been motivated to fix it. For a look at why even a trivial change is not trivial, see the commits at <https://gitlab.com/mailman/mailman/-/merge_requests/652/commits>. The first of these is developing good tests for the issue and then fixing the code so the tests pass, and the second, unanticipated one was due to the fact that Python 3.5 didn't maintain the original ordering of the addresses in Cc: so I couldn't compare against a fixed result. This is due to the fact that the underlying code uses dictionaries, and prior to Python 3.6 dictionaries didn't preserve order. -- Mark Sapiro <mark(a)msapiro.net> The highway is for gamblers, San Francisco Bay Area, California better use your sense - B. Dylan

5 years, 11 months

[MM3-users] Re: Improve logging?

by Mark Sapiro

On 1/31/23 00:40, Odhiambo Washington wrote: > Some entries in the log files can be very scary, while in actual sense they > are harmless. > Such inconsequential, but scary entiess can mess up the well-being of a > SysAdmin. > I humbly request for the logs related to posts by non-members to a MM3 list > to be improved a little bit :-) > Here is the example in mailman.log: > > <cut> > Jan 31 10:03:54 2023 (92481) DISCARD: < > 2a1c588a6ccd47abbf57ee5fc61c9946(a)phellineconsultancy.co.ke>; ['The message > is not from a list member'] > [31/Jan/2023:10:04:48 +0300] "GET > /3.1/users/1bad08f703fe4bc0a829f4bdce10fc8f HTTP/1.1" 200 253 "-" "GNU > Mailman REST client v3.3.5" > [31/Jan/2023:10:04:48 +0300] "GET > /3.1/users/1bad08f703fe4bc0a829f4bdce10fc8f/addresses HTTP/1.1" 200 473 "-" > "GNU Mailman REST client v3.3.5" > Jan 31 10:18:09 2023 (92343) deque: do_confirm_verify > Traceback (most recent call last): > File > "/opt/mailman/mm/venv/lib/python3.9/site-packages/mailman/app/workflow.py", > line 69, in __next__ > return step() > File > "/opt/mailman/mm/venv/lib/python3.9/site-packages/mailman/app/subscriptions.py", > line 476, in _step_send_confirmation > raise StopIteration > StopIteration > </cut> > > Is there a possibility to change the logging engine to just *fold* the last > 7 lines into "The message is not from a list member. It was discarded", or > something close? No. This entry Jan 31 10:03:54 2023 (92481) DISCARD: <2a1c588a6ccd47abbf57ee5fc61c9946(a)phellineconsultancy.co.ke>; ['The message is not from a list member'] is a single entry about a discarded message. The next two are logging requests via the REST API that have nothing to do with the discard and are logged by a different module. The last entry with a traceback is yet another separate event. That one could probably be suppressed because raising StopIteration is a normal occurrence in workflow processing. -- Mark Sapiro <mark(a)msapiro.net> The highway is for gamblers, San Francisco Bay Area, California better use your sense - B. Dylan

3 years, 3 months

[MM3-users] Re: Reset bounce count in MM3

by Mark Sapiro

On 3/8/26 20:57, iMark wrote: > =========== > > My thinking was that to reset that member's bounce_count from 4 to 0, I > could just delete the records (resulting from the query) in the > "bounceevent". > > But as the query result only shows 2 bounces, I'm looking for where the > Admin web UI is getting "4" from (ie. the processed bounce events older > than 24 hours). The list member's bounce score is the bounce_score column in the member table, but finding the correct row is dificult because you need the list_id which you'd look up in the mailinglist table and either the address_id from the address table or the user_id from the user table. It's much easier to use mailman shell as in ``` $ mailman shell -l list(a)example.com Welcome to the GNU Mailman shell Use commit() to commit changes. Use abort() to discard changes since the last commit. Exit with ctrl+D does an implicit commit() but exit() does not. The variable 'm' is the list(a)example.com mailing list >>> mbr = m.members.get_member('user(a)example.com') >>> mbr.bounce_score = 0 >>> commit() ``` But what is the point of doing this? If the member is bouncing, the score will continue to increment, and if not the bounces will become stale and a future bounce will set the score to 1. You mentioned reset_bounce.py, but that doesn't reset scores. It sets delivery enabled for users whose delivery is disabled by bounce, but you can do that, albiet one by one, in Postorius just by clicking the user in the membership list and setting Delivery Status to Enabled. In Postorius <=1.3.13, Delivery Status doesn't show in the membership list, but it will in the next release. -- Mark Sapiro <mark(a)msapiro.net> The highway is for gamblers, San Francisco Bay Area, California better use your sense - B. Dylan

2 months

[MM3-users] Re: Disabled by bounce

by Mark Sapiro

On 2/17/23 13:39, denise.mcgeachy--- via Mailman-users wrote: > Hi all - new to this forum but am trying to work out a similar issue raised by a list member's IT department. I'm a bit out of my depth here and hoping you all can help. > > They have recommended: > > - When the mailing list relay an email from a member of the list to other members, the email from address should be the mailing list and not the user sending the original email. For example: list-name(a)mydomain.ca (on behalf of Sally Brown) > - The mailing list should not modify the original email and thus breaking the DKIM signature > > I have clicked the DMARC mitigation unconditionally option which seems to solve the second point but haven't managed to have it sent by the list name but not as suggested in the first point. I either get "my email via list(a)mylist.ca" or list(a)mylist.ca" > Is anyone aware of a setting to do this? Those two points are contradictory. You can't do both. Not modifying the message in ways that break DKIM requires no content filtering, no addition of list headers or footers and no munging of From: or Reply-To: headers. Normally the list will make some modification that will break DKIM signatures. If you set DMARC mitigation action to Replace From: with list address, and set DMARC Mitigate unconditionally, that should address the first point and individual messages from the list will be From the list and that's all you should need. For example, the message to which I'm replying is From: denise.mcgeachy--- via Mailman-users <mailman-users(a)mailman3.org> While this is not identical to the format you quote, the address is the list's address which is the important thing. -- Mark Sapiro <mark(a)msapiro.net> The highway is for gamblers, San Francisco Bay Area, California better use your sense - B. Dylan

3 years, 2 months

[MM3-users] Re: Five Year Old Issue

by Brian Carpenter

On 3/14/21 8:10 PM, Mark Sapiro wrote: > On 3/14/21 5:07 PM, Mark Sapiro wrote: >> It turns out Abhilash had done all the heavy lifting on this [1] but I didn't realize it because [2] hadn't been done. Since the rest was easy, [3] now fixes it. >> >> [1] https://gitlab.com/mailman/mailman/-/merge_requests/779 >> [2] https://gitlab.com/mailman/mailman/-/merge_requests/796 >> [3] https://gitlab.com/mailman/mailman/-/merge_requests/795 >> > > Ooops, [2] and [3] are reversed > > [2] https://gitlab.com/mailman/mailman/-/merge_requests/795 > [3] https://gitlab.com/mailman/mailman/-/merge_requests/796 > So this means the fix will show up in the next stable release? -- Brian Carpenter Harmonylists.com Emwd.com

5 years, 1 month

[MM3-users] Re: list footer questions

by Mark Sapiro

On 5/14/20 2:49 PM, Mohsen Masoudfar wrote: > > It is on Ubuntu18.04 and has been installed with Ubuntu package Mailman-full. There is no update available yet. So it looks like I cannot use the easy way of modifying the templates. > Question: Is there a way to achieve the same by updating the code? You don't have to modify code. You can set a footer in Mailman's file hierarchy. There is a var/templates directory, maybe somewhere like /var/lib/mailman/templates in the Ubuntu package. This directory can contain subdirectories lists, domains and site. These may or may not existb but the layout is the site directory contains subdirectories for language codes, i.e. 'en', 'fr', 'de', etc. The domains directory contains subdirectories for domains like 'example.com', example.net, etc. and those contain the language subdirectories. The lists directory contains subdirectories for lists like list.example.com and those contain the language subdirectories. Now when mailman is looking for a template, it looks in this hierarchy first, e.g. when looking for an English language footer for the list(a)example.com list for regular members it will look in this order: templates/lists/list.example.com/en/list:member:regular:footer.txt templates/domains/example.com/en/list:member:regular:footer.txt templates/site/en/list:member:regular:footer.txt before falling back to a default. The name for a digest footer is list:member:digest:footer.txt, or there can be a list:member:generic:footer.txt file which is for both regular and digest deliveries. There is documentation at <https://docs.mailman3.org/projects/mailman/en/latest/src/mailman/rest/docs/…>, but it can be difficult to follow. <https://docs.mailman3.org/projects/mailman/en/latest/src/mailman/rest/docs/…> describes the various templates and the substitutions available. Note that the name of a file in the above hierarchy is the template name with `.txt` appended. -- Mark Sapiro <mark(a)msapiro.net> The highway is for gamblers, San Francisco Bay Area, California better use your sense - B. Dylan

5 years, 11 months

[MM3-users] Re: LTMP to Postfix problem

by Mark Sapiro

On 6/18/20 5:38 PM, Brian Carpenter wrote: > > Then there was this little bit of info: > > Jun 18 00:00:12 mm4 kernel: [19548549.442555] Out of memory: Kill > process 29676 (python3) score 37 or sacrifice child > Jun 18 00:00:12 mm4 kernel: [19548549.444508] Killed process 29676 > (python3) total-vm:192224kB, anon-rss:93084kB, file-rss:0kB, shmem-rss:0kB > Jun 18 00:00:12 mm4 kernel: [19548549.464907] oom_reaper: reaped process > 29676 (python3), now anon-rss:0kB, file-rss:0kB, shmem-rss:0kB > > I suspect the above process was ltmp. > > So the server has 2 gig of ram with about a dozen MM3 lists on it. Is > this an issue with tuning performance of the Postgresql server or do I > need to add more memory. I am curious how much ram your server is > running and if you had run into any OOM of problems. I haven't seen any OOM issues on the servers I manage. Those include mail.python.org 16 GB RAM 261 MM2.1 lists, 139 MM 3 lists lists.mailman3.org 4 GB RAM and other than tests and demos, only this list www.grizz.org 8 GB RAM This is my bicycling club's server. 7 MM 2.1 lists, only 2 of which are really active, 7 MM 3 lists including 2 test/demo - MySQL for the club database and Postgres for Mailman 3. It also supports some non Mailman club email and the club's web site including a MoinMoin wiki. The grizz.org domain was recently migrated from from a larger server in a colo that supported multiple domains to a DigitalOcean droplet which initially had only 4 GB RAM, but that seemed marginally enough at best, so I upgraded it to 8 GB. So the bottom line is I haven't run Mailman 3 on a server with only 2 GB and that may well not be enough. -- Mark Sapiro <mark(a)msapiro.net> The highway is for gamblers, San Francisco Bay Area, California better use your sense - B. Dylan

5 years, 10 months

[MM3-users] Re: Moderate mails from owner

by Mark Sapiro

On 3/21/19 3:02 AM, Malcolm Austen wrote: > > My only experience of MM3 is with Ancestry's 'RootsWeb' installation. > From the emails I can see a header "X-Mailman-Version: 3.1.0" but I > can't find anything to identify Postorius which is the only interface I > have to the system. Isn't there a footer at the bottom of wach page with something like: Postorius Documentation • GNU Mailman • Postorius Version 1.2.5 > From symptoms seen and described by others, I have deduced that the > Postorius admin-per-user moderation options of "Default processing" and > "List default" mean that a user may be set (by default on the rootsweb > system!) to use the system default moderation settings rather than the > list default settings. New (non-)members always have Moderation set to List default. This means their posts are governed by the applicable Settings -> Message Acceptance settings. Setting a user's Moderation to Default Processing means that users posts will not be held/rejected/discarded/accepted immediately based on "Default action to take when a (non-)member posts to the list", but additional checks will not be bypassed. See <https://mailman.readthedocs.io/en/latest/src/mailman/rules/docs/rules.html>. > Are my deductions correct? And if so, could this be the explanation of > the issue detailed in this thread? Setting a user's Moderation to Default Processing (or Accept) would bypass the list defaults and could be the explanation of this issue. When the non-member owner first posts to the list that address becomes a non-member of the list. I.e. it is in the roster of known non-members of the list and that non-member record could have had its Moderation set to Accept or Default Processing at some point which would explain why the posts are accepted. -- Mark Sapiro <mark(a)msapiro.net> The highway is for gamblers, San Francisco Bay Area, California better use your sense - B. Dylan

7 years, 1 month

[MM3-users] Re: Postorius endless loading on Sign in / Register then "Internal Server Error"

by Mark Sapiro

On 6/9/20 12:16 PM, Jacob Bargery wrote: > Pre-cursor, I am in a new position to learn on the go and new to Linux but have been tasked with setting up a List Serv and they wanted Mailman 3 with Postorius and HyperKitty. Running on Ubuntu 20.04 LTS using Postfix and MySQL. I can open up the initial pages. With no Lists created yet. I can open up Register, Login, and Forgot Password but when I submit anything it spins the loading icon for a long time then reads" > > "Internal Server Error > The server encountered an internal error or misconfiguration and was unable to complete your request. Apache/2.4.41 (Ubuntu) Server at groups.smccme.edu Port 80" ... > This is a traceback I could find from another attempt: > > Traceback (most recent call last): ... > File "/usr/lib/python3/dist-packages/mailmanclient/restbase/connection.py", line 109, in call > raise MailmanConnectionError('Could not connect to Mailman API') > mailmanclient.restbase.connection.MailmanConnectionError: Could not connect to Mailman API What are your Django settings for MAILMAN_REST_API_URL = 'http://localhost:8001' MAILMAN_REST_API_USER = 'restadmin' MAILMAN_REST_API_PASS = 'restpass' Those match the defaults defined in mailman/config/schema.cfg [webservice] # The hostname at which admin web service resources are exposed. hostname: localhost # The port at which the admin web service resources are exposed. port: 8001 # Whether or not requests to the web service are secured through SSL. use_https: no # The administrative username. admin_user: restadmin # The administrative password. admin_pass: restpass If all that seems to match, what happens if you try telnet localhost 8001 If that doesn't work, but telnet 127.0.0.1 8001 works, there is some issue with `localhost` involving /etc/resolv.conf or /etc/hosts, most likely an ipv6 definition like ::1 localhost in the latter. -- Mark Sapiro <mark(a)msapiro.net> The highway is for gamblers, San Francisco Bay Area, California better use your sense - B. Dylan

5 years, 11 months

Search results for query "sapiro"