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

[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, 6 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

5 months, 1 week

[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, 6 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, 5 months

[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

6 years, 3 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

6 years, 2 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, 4 months

[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

6 years, 2 months

[MM3-users] Re: Displaying addresses in emails from a Mailman 3 installation

by Mark Sapiro

On 7/2/25 19:50, Steve Brown via Mailman-users wrote: > Thanks, Mark. As usual, your reply was rapid and helpful. I infer that you don't see the instability that my subscriber does. I'm pretty sure I don't, but I'm not completely certain I would notice. > Do (can?) email providers passing the posts to the subscriber alter the headers in ways that might lead to that unstable behavior? It is possible, but I don't think likely that the final mail delivery agent would do this. It's also almost certain that no intermediate MTA is doing it. > Or can it occur because of the way T-bird tries to help the user associate display names with email addresses--autofill and address book automation? That seems unlikely since those things would be tied to the email address which is always the same list posting address. > Do you have those kind of features turned off in your T-bird? Or is it more likely that the subscriber makes some mistakes that get interpreted as needing a change in From displays? Because only one of my subscribers is complaining regularly, it's not very important for me to do anything, but I'm still curious about the origin of this behavior. I don't think I have any non-default settings in my T-bird, and I do have address book entries for various lists and I don't see T-bird showing messages From the display names in my address book. I am curious as to what the complaint is. Does the user feel that something important is missing or is the concern just the inconsistency? Also, is there any correlation between the inconsistent behavior and what the poster's name is? -- Mark Sapiro <mark(a)msapiro.net> The highway is for gamblers, San Francisco Bay Area, California better use your sense - B. Dylan

1 year, 1 month

[MM3-users] Re: required cron entries?

by Mark Sapiro

On 12/31/20 2:49 AM, Andreas Barth wrote: > Hi together, > > as I found some mails in queue/shunt, I thought who should be running > them. See below. > On my (standard debian) reference system, there are no cron entries > for mailman3 but only for mailman3-web. The crons for Mailman core are discussed at <https://docs.mailman3.org/en/latest/config-core.html#configuring-cron-jobs>. > Looking in the source code, there is a ./cron/crontab.in.in however > references to scripts in port_me/ directory. That's all old Mailman 2.1 stuff. ignore it. > Should I (still) install (parts of) the crontab? Or > are these functions handled elsewhere? Again, see <https://docs.mailman3.org/en/latest/config-core.html#configuring-cron-jobs>. > Also, who picks up mails in queue/shunt? Or are they lost somehow? When processing of a message in Core throws an uncaught exception, the error is logged with a traceback in var/logs/mailman.log and the message's queue entry is saved in the /var/queue/shunt/ queue. These messages can be retried via the `mailman unshunt` command, but unless the underlying cause has been fixed, they will throw the same exception and be shunted again. Each shunted message requires manual inspection of the var/logs/mailman.log entry and possibly examination of the message via `mailman qfile /var/queue/shunt/....pck`. Some of these are spam messages which are somehow defective causing the exception, and these can just be manually removed from the shunt queue. I've seen a couple that are transient errors[1] that can just be successfully unshunted. The rest require some underlying issue to be fixed before they can be successfully unshunted. [1] In particular, I've seen an apparent race condition in building the list of recipients where we try to determine the delivery status for a member that is no longer a member. -- Mark Sapiro <mark(a)msapiro.net> The highway is for gamblers, San Francisco Bay Area, California better use your sense - B. Dylan

5 years, 7 months

Search results for query "sapiro"