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

[MM3-users] Re: How to upgrade to 3.10

by Paul Tomblin

On Tue, Mar 3, 2026, at 12:30 AM, Mark Sapiro wrote: > > But it looks like here it's trying to install 3.3.10. > >> Requirement already satisfied: postorius in ./venv/lib/python3.13/site-packages (1.3.13) >> ... a bunch of these ... >> INFO: pip is looking at multiple versions of mailman to determine which version is compatible with other requirements. This could take a while. >> Requirement already satisfied: python-dateutil>=2.0 in ./venv/lib/python3.13/site-packages (from mailman) (2.9.0.post0) >> ...a bunch more... > > Is there any conflict reported in this `bunch more` to force 3.3.9? What > if you do `pip install mailman==3.3.10`? All the "...a bunch more..." lines are "Requirement already satisfied". And here's what happens when I try to do as you suggested: (venv) $ pip install mailman==3.3.10 Collecting mailman==3.3.10 Using cached mailman-3.3.10-py3-none-any.whl.metadata (2.4 kB) Requirement already satisfied: aiosmtpd>=1.4.3 in ./venv/lib/python3.13/site-packages (from mailman==3.3.10) (1.4.6) Requirement already satisfied: alembic!=1.7.0,>=1.6.2 in ./venv/lib/python3.13/site-packages (from mailman==3.3.10) (1.18.4) Requirement already satisfied: atpublic in ./venv/lib/python3.13/site-packages (from mailman==3.3.10) (7.0.0) Requirement already satisfied: authheaders>=0.16 in ./venv/lib/python3.13/site-packages (from mailman==3.3.10) (0.16.3) Requirement already satisfied: authres>=1.0.1 in ./venv/lib/python3.13/site-packages (from mailman==3.3.10) (1.2.0) Requirement already satisfied: click>=8.0.0 in ./venv/lib/python3.13/site-packages (from mailman==3.3.10) (8.3.1) Requirement already satisfied: dnspython>=1.14.0 in ./venv/lib/python3.13/site-packages (from mailman==3.3.10) (2.8.0) Requirement already satisfied: falcon>=3.1.3 in ./venv/lib/python3.13/site-packages (from mailman==3.3.10) (4.2.0) Requirement already satisfied: flufl.bounce>=4.0 in ./venv/lib/python3.13/site-packages (from mailman==3.3.10) (4.0) Requirement already satisfied: flufl.i18n>=3.2 in ./venv/lib/python3.13/site-packages (from mailman==3.3.10) (6.0.0) Requirement already satisfied: flufl.lock>=5.1 in ./venv/lib/python3.13/site-packages (from mailman==3.3.10) (9.0.0) Requirement already satisfied: gunicorn in ./venv/lib/python3.13/site-packages (from mailman==3.3.10) (25.1.0) Requirement already satisfied: lazr.config in ./venv/lib/python3.13/site-packages (from mailman==3.3.10) (3.1) INFO: pip is looking at multiple versions of mailman to determine which version is compatible with other requirements. This could take a while. ERROR: Could not find a version that satisfies the requirement nntplib; python_version >= "3.13" (from mailman) (from versions: none) ERROR: No matching distribution found for nntplib; python_version >= "3.13" I guess I need to upgrade my python version? -- Paul Tomblin

4 months, 3 weeks

[MM3-users] Re: Digests not working correctly

by Joel Lord

On 6/4/2023 9:25 PM, Mark Sapiro wrote: > On 6/4/23 11:45, Joel Lord wrote: Thanks for the explanation on size-triggered digests. >> Periodic is much more complicated, even to explain. I have the cron >> job running nightly at 11:00 PM and it certainly seems to be working, >> except for one really odd thing. The list also definitely has >> periodic digests enabled in the web UI. This is a very bursty list, >> so it will go mad with traffic for a few weeks and then will go mostly >> idle for a month or so. The first digest of a burst is definitely >> size-triggered, but pretty reliably it has the last few messages from >> the previous burst in there. So the one I got today had three >> messages from today and one message from May 4th. But that May 4th >> message should have gone out at 11:00 PM on May 4th with the daily >> digest and then gotten flushed from the pending digest queue, right? > > That's correct. Do you ever get periodic digests sent at 11:00 PM? If > not, there is some issue either with configuration or something. If you > get them sometimes, I don't know what could be wrong. The periodic digests do seem to be coming out. I also now have confirmation that the one message in this morning's digest that was from May 4th was also included in the last digest back on May 4th, so it seems that the one message was left behind in the digest queue when the periodic digest was sent. There was one earlier message to the list back on May 4th, before the one that got duplicated, but I can't tell if that triggered a size-based digest to be sent: the logs aren't clear enough on that detail for me to tell. Just to inform things: (venv) lists@host2:~/mailman/venv/bin$ pip freeze | grep mailman django-mailman3==1.3.9 mailman==3.3.8 mailman-hyperkitty==1.2.1 mailman-web==0.0.6 mailmanclient==3.3.5 (venv) lists@host2:~/mailman/venv/bin$ pip freeze | grep hyper mailman-hyperkitty==1.2.1 (venv) lists@host2:~/mailman/venv/bin$ pip freeze | grep post postorius==1.3.8 -- Joel Lord

3 years, 1 month

[MM3-users] Re: Turn off social logins?

by Stephen J. Turnbull

Mark Sapiro writes: > On 2/14/19 11:10 PM, Stephen J. Turnbull wrote: > > Torge Riedel writes: > > > > > - there is a way to do this now via settings_local.py, but feels > > > a little bit risky if default configuration changes on update of > > > mailman > > > > This should not be true. If it is, we need to fix that. Will check. > > > It is more or less true [...] the only way settings_local.py can > change something like INSTALLED_APPS is to redefine INSTALLED_APPS > in it's entirety which leads to the possibility of INSTALLED_APPS > changing in settings.py and those changes not being picked up in > settings_local.py. That's a different issue from the one I believe Torge is worried about, which is an update overwriting settings_local.py. But it's not good. > The way around this is to remove the import of settings_local from > settings.py and then put > > from settings import * > > at the beginning of settings_local.py and then point Django at > settings_local rather than settings. I don't understand the ramifications of making this change (presumably Barry or somebody had a reason for the change from Mailman 2's method), but at first glance it looks like a big step in the right direction. > Then you can do things like > > try: > INSTALLED_APPS.remove('allauth.socialaccount.providers.google') > except ValueError: > pass > > in settings_local.py except there are still issues because, e.g., > INSTALLED_APPS is defined as a tuple (immutable) and not a list in > settings.py. Given the concerns of privacy advocates, I would say that it would be better to have a separate AUTH_PROVIDERS = ['allauth.socialaccount.providers.google', ...] in settings_local.py, and merge that in to INSTALLED_APPS. Of course removing specific providers would be OK too, but I think that this is a place where "deny all / accept what you want" is appropriate. Steve -- Associate Professor Division of Policy and Planning Science http://turnbull.sk.tsukuba.ac.jp/ Faculty of Systems and Information Email: turnbull(a)sk.tsukuba.ac.jp University of Tsukuba Tel: 029-853-5175 Tennodai 1-1-1, Tsukuba 305-8573 JAPAN

7 years, 5 months

[MM3-users] Re: Filter who can send on mailman3 list?

by Ruth Ivimey-Cook

Marcus, I'm with you in not understanding Mark's instructions -- I think there is a typo somewhere :-) To create a non-member user in Mailman, Go to the List Settings page in Postorius, select Non-members from the User menu, and add a user there. Of course, that does nothing for your email system, which must also be configured. I would very strongly encourage you to have the no-reply address be 'real' in the sense that the email system will agree it is valid and deliverable, or some recipient email servers will refuse to accept email from that address, either. The right thing is for email to that address accepted as normal and then immediately discarded. You could send back a message "this address is not monitored" but there is an issue with spam backscattering which makes that less good than it first seems. Regards, Ruth On 06/04/2021 10:00, marcus.granath(a)gmail.com wrote: > Thank you @Mark Sapiro for you quick reply. > > So by doing the following settings, then ALL the messages sent to the list will be hold for moderation: > > Settings -> Message Acceptance > > "Default action to take when a member posts to the list": "Hold for moderation" > "Default action to take when a non-member posts to thelist": "Hold for moderation" > > Members -> Administration options -> Moderation: "List default" > > BUT I don't really follow you when you say that those 3 allowed users to send on the list should also have set to "Moderation: List default"? > How will they then be able to send messages, or what do I misunderstand here? > > Also, how do I create a "non-member" user "no-reply(a)abc.com"? > Do you mean that I do that under the "Mass operations -> Mass subscriptions" ? Can I add a "fake address" there? > _______________________________________________ > Mailman-users mailing list -- mailman-users(a)mailman3.org > To unsubscribe send an email to mailman-users-leave(a)mailman3.org > https://lists.mailman3.org/mailman3/lists/mailman-users.mailman3.org/ -- Software Manager & Engineer Tel: 01223 414180 Blog: http://www.ivimey.org/blog LinkedIn: http://uk.linkedin.com/in/ruthivimeycook/

5 years, 3 months

[MM3-users] Re: slow restart time for mailmanweb

by William Oliver

On Tue, 2021-12-28 at 13:52 -0800, Mark Sapiro wrote: > On 12/28/21 1:28 PM, William Oliver wrote: > > > > > > > These log entries are from restarting mailman, not mailmanweb Damn. Sorry about that. Brain fart. Yep, it's still slow with mailmanweb: Dec 28 17:41:00 emergenus systemd[1]: Stopping GNU Mailman Web UI... Dec 28 17:41:01 emergenus uwsgi[20860]: [uWSGI] getting INI configuration from /etc/mailman3/uwsgi.ini Dec 28 17:41:01 emergenus CRON[44474]: (mailman) CMD (/opt/mailman/venv/bin/mailman-web runjobs minutely) Dec 28 17:41:06 emergenus kernel: [12494.670812] [UFW BLOCK] IN=eth0 Dec 28 17:42:01 emergenus CRON[44755]: (mailman) CMD (/opt/mailman/venv/bin/mailman-web runjobs minutely) Dec 28 17:42:07 emergenus kernel: [12555.550730] [UFW BLOCK] IN=eth0 OUT= MAC=00:16:3e:ef:72:96:00:23:9c:9e:9f:c0:08:00 SRC=92.63.197.112 DST=203.159.80.234 LEN=40 TOS=0x00 PREC=0x00 TTL=253 ID=9540 PROTO=TCP SPT=57024 DPT=25238 WINDOW=1024 RES=0x00 SYN URGP=0 Dec 28 17:42:30 emergenus systemd[1]: mailmanweb.service: State 'stop- sigterm' timed out. Killing. Dec 28 17:42:30 emergenus systemd[1]: mailmanweb.service: Killing process 20860 (uwsgi) with signal SIGKILL. Dec 28 17:42:30 emergenus systemd[1]: mailmanweb.service: Killing process 44476 (uwsgi) with signal SIGKILL. Dec 28 17:42:30 emergenus systemd[1]: mailmanweb.service: Killing process 44477 (uwsgi) with signal SIGKILL. Dec 28 17:42:30 emergenus systemd[1]: mailmanweb.service: Killing process 44478 (sh) with signal SIGKILL. Dec 28 17:42:30 emergenus systemd[1]: mailmanweb.service: Killing process 44480 (mailman-web) with signal SIGKILL. Dec 28 17:42:30 emergenus systemd[1]: mailmanweb.service: Killing process 44483 (mailman-web) with signal SIGKILL. Dec 28 17:42:30 emergenus systemd[1]: mailmanweb.service: Killing process 44484 (mailman-web) with signal SIGKILL. Dec 28 17:42:30 emergenus systemd[1]: mailmanweb.service: Killing process 44485 (mailman-web) with signal SIGKILL. Dec 28 17:42:30 emergenus systemd[1]: mailmanweb.service: Killing process 44486 (mailman-web) with signal SIGKILL. Dec 28 17:42:30 emergenus systemd[1]: mailmanweb.service: Killing process 44487 (mailman-web) with signal SIGKILL. Dec 28 17:42:30 emergenus systemd[1]: mailmanweb.service: Killing process 44479 (uwsgi) with signal SIGKILL. Dec 28 17:42:30 emergenus systemd[1]: mailmanweb.service: Killing process 44481 (uwsgi) with signal SIGKILL. Dec 28 17:42:30 emergenus systemd[1]: mailmanweb.service: Main process exited, code=killed, status=9/KILL Dec 28 17:42:30 emergenus systemd[1]: mailmanweb.service: Failed with result 'timeout'. Dec 28 17:42:30 emergenus systemd[1]: Stopped GNU Mailman Web UI. Dec 28 17:42:30 emergenus systemd[1]: mailmanweb.service: Consumed 2min 27.819s CPU time. >

4 years, 6 months

[MM3-users] Re: All addresses in a bounced list posting seem to be considered as bouncing

by Andy Smith

On Mon, Jul 11, 2022 at 02:44:59AM +0000, Andy Smith wrote: > Hi Mark, > > On Sat, Jul 09, 2022 at 12:05:32PM -0700, Mark Sapiro wrote: > > If the original post was the message delivered to > > users-bounces(a)mailman.bitfolk.com, it is possible that simplematch or > > another recognizer parsed those addresses from the message body. > > For now I've configured a copy of all mails to -bounces addresses, > so if/when it happens again I can inspect the actual email that > triggered it. This just happened again. As a refresher, the issue I'm seeing is that Mailman registers a bounce against addresses that aren't subscribed, including addresses for the list itself and for the -leave address that is in some footer text. Here's the bounce.log: Sep 30 17:12:25 2022 (8428) Member [elided1](a)[elided1].force9.co.uk on list users.mailman.bitfolk.com, bounce score = 1. Sep 30 17:12:25 2022 (8428) Bounce message for a non subscriber: Email users(a)mailman.bitfolk.com is not a subcriber of users.mailman.bitfolk.com Sep 30 17:12:25 2022 (8428) Bounce message for a non subscriber: Email mailto:[elided2]@gmail.com is not a subcriber of users.mailman.bitfolk.com Sep 30 17:12:25 2022 (8428) Member [elided2](a)gmail.com on list users.mailman.bitfolk.com, bounce score = 1. Sep 30 17:12:25 2022 (8428) Bounce message for a non subscriber: Email users-leave(a)mailman.bitfolk.com is not a subcriber of users.mailman.bitfolk.com Sep 30 17:12:25 2022 (8428) Member [elided3](a)[elided3].org.uk on list users.mailman.bitfolk.com, bounce score = 1. I have elided parts of the email addresses of real subscribers. Attached is the actual non-delivery report from the MTA that triggered this. In it I have done my best to elide the names and addresses of real people, but nothing else. They match the same elisions from the bounce log. Any ideas why Mailman is interpreting this NDR so over-zealously? It seems like a pretty standard one. [elided1].force9.co.uk is the subscriber who rejected the mail, yet also users(a)mailman.bitfolk.com, [elided2](a)gmail.com, users-leave(a)mailman.bitfolk.com and [elided3](a)[elided3].org.uk (sender) were punished. Thanks, Andy

3 years, 9 months

[MM3-users] Re: Does hyperkitty show JPEGs in line and what about attachments?

by Jason Glazer

Mark Thanks for the link to the test archive. That and your information has clarified things a lot. Jason On 7/12/2017 11:39 AM, Mark Sapiro wrote: > On 07/12/2017 04:47 AM, Jason Glazer wrote: >> Does anyone know if Hyperkitty can be configured to allow for inline >> images to be maintained so that an HTML file looks like a normal HTML >> message? >> >> Also, can attachments to a message under Hyperkitty preserve their name >> rather than being "scrubbed" into "attachment-*.*" files? > > The answer to some of this is at > <https://lists.mailman3.org/archives/list/test@mailman3.org/message/N3XVN3DC…>. > > One question unanswered by that post is what happens with an inline > image in an HTML message body. In the original message, the image is > referenced by an IMG tag with "src=" pointing to the image MIME part. > Since this structure is not maintained in HyperKitty, inline images > probably don't work. > > Also, with respect to Mailman 2.1, if you want the scrubber to preserve > file names and extensions, set the following in mm_cfg.py > > SCRUBBER_DONT_USE_ATTACHMENT_FILENAME = False > SCRUBBER_USE_ATTACHMENT_FILENAME_EXTENSION = True > > and if you want scrubbed HTML to not be HTML escaped so it renders > rather than looking like raw html, set > > ARCHIVE_HTML_SANITIZER = 3 > > but note this comment from Defaults.py > >> # 3 - Remove text/html as attachments but don't HTML-escape them. Note: this >> # is very dangerous because it essentially means anybody can send an HTML >> # email to your site containing evil JavaScript or web bugs, or other >> # nasty things, and folks viewing your archives will be susceptible. You >> # should only consider this option if you do heavy moderation of your list >> # postings. > > This is an issue with HyperKitty as it appears this is what HyperKitty > does and there's no way to turn it off. > -- Jason Glazer, P.E., BEMP, GARD Analytics, 90.1 ECB chair, 209 chair Admin for onebuilding.org building performance mailing lists

9 years

[MM3-users] Re: Disabled by bounce

by Allan Hansen

One more, sorry: Looking in the mailman-users archive, I'm not sure if I understand the bounce settings. Is it the case that if I set the 'Bounce info stale after' to 3d then in 3 days the bounces will be reset to 0 if no further bounces have arrived? I saw a post that made me doubt this. Yours, Allan On 2/1/23, 09:59, "Mark Sapiro" <mark(a)msapiro.net> wrote: On 1/31/23 22:32, Allan Hansen wrote: > Hi all, > > Apparently Google just started to get very aggressive about DKIM settings. Some hundreds of my subscribers have had their subscriptions disabled because of Google's bounces. > > I tried to 'Enable' some of them, expecting that their bounce scores would be reset, but when I list the users, the bounce scores are still 5. > > Please advise. Will enabling them without the bounce score being reset just cause the server to disable them again. Yes, Google has started enforcing a policy which is effectively DMARC p=reject even for senders whose domains don't publish DMARC p=reject or quarantine. To avoid this issue, you may need to set DMARC Mitigate unconditionally to Yes as well as DMARC mitigation action to Replace From: with list address if it isn't already. As far as enabling without resetting the bounce score is concerned, I think you are correct that they will just be disabled again on the next bounce. This is a bug and should be fixed. However, all of the above can be avoided without any DMARC changes by enabling bounce probes. in the [mta] section of mailman.cfg, set ``` verp_probes: yes ``` Since the probe is sent From: the list's domain, it should pass googles SPF and DKIM checks and not bounce. -- Mark Sapiro <mark(a)msapiro.net> The highway is for gamblers, San Francisco Bay Area, California better use your sense - B. Dylan _______________________________________________ Mailman-users mailing list -- mailman-users(a)mailman3.org To unsubscribe send an email to mailman-users-leave(a)mailman3.org https://lists.mailman3.org/mailman3/lists/mailman-users.mailman3.org/ Archived at: mailman-users(a)mailman3.org <https://lists.mailman3.org/archives/list/<a href=>/message/56WVO6NIOGOBAOOS2B4YCIDJN7VCIXTF/">https://lists.mailman3.org/archives/list/mailman-users@mailman3.org/message… This message sent to hansen(a)rc.org

3 years, 5 months

[MM3-users] Re: Hyperkitty on Debian 12

by Michael Oberrauch

On Tue, 2024-03-26 at 08:06 +0100, Markus Grandpré wrote: > Dear Mr Sapiro, > > thank you very much for your help. The required command is: > > # mailman-web hyperkitty_import \ > -l mailman21-migration-test-04(a)mailman.uni-konstanz.de \ > /var/mailman21/testlist.mbox > > Due to the following warnings, I still have to customize Hyperkitty: > > django_mailman3.MailDomain: (models.W042) Auto-created primary key > used > when not defining a primary key type, by default > 'django.db.models.AutoField'. > HINT: Configure the DEFAULT_AUTO_FIELD setting or the > DjangoMailman3Config.default_auto_field attribute to point to a > subclass > of AutoField, e.g. 'django.db.models.BigAutoField'. > ... > > Can you give me another hint? As Linux admin I installed the packages > mailman and mailman-web that were offered to me under Debian 12. > Although during the installation of the packages user "list" was > created, I cannot use it: > > # su - list > This account is currently not available > > As with Mailman 2.1, I will probably have to continue working with > Mailman3 as root. Too bad that there is no documentation for Debian > admins like me, who don't want to dive too deep into the python > framework. Or have I overlooked something? > > Best regards, > Markus > > Hi Markus, we are also running MM3 on Debian 12 from Package Repositories. First of all, you should not try to directly switch user (su) to the lists user, it's generally intended to executes commands as that user, if necessary; either using `runuser`, `sudo`, or `su -c`. However, the prepackaged scripts `mailman-wrapper` and `mailman-web` already do this and therefore you ca run those as root without permission problems. On Debian there are two relevant users for MM3: the list user runs mailman core, whereas the www-data user runs Postorius and Hyperkitty. So you have to make shure, that the www-data user can access the .mbox files while importing. Hope that helps. Cheers, Michael -- Michael Oberrauch (er/ihm) Computerreferent Fachschaft Mathematik/Physik/Informatik/Chemie Studentische Vertretung Technische Universität München Boltzmannstraße 3 85748 Garching eMail: oberrauch(a)fs.tum.de Tel: (+49) 089 289 18545 Fax: (+49) 089 289 18546 https://mpic.fs.tum.de

2 years, 4 months

[MM3-users] Re: Timeout error on anonymous subscribe

by vogt＠spamcop.net

Mark Sapiro wrote: > On 10/23/24 13:23, Gerald Vogt wrote: > > I don't quite understand the relevance of the user accessing the > > localhost tcp port. Any local user can do that. > I am trying to duplicate what Mailman does in an attempt to find the issue. > > I can access the template content with > > curl > > http://localhost:8000/mailman3/api/templates/list/community.lists.example.co... > > as well as > > curl > > http://lists.example.org/mailman3/api/templates/list/community.lists.example... > > as any user on the mailman server. > > How about > curl -A 'python-requests/2.32.3' > http://lists.example.org/mailman3/api/templates/list/community.lists.exampl… > > as the Mailman user? I have tried anything I could think of but I cannot reproduce the issue using curl as user mailman (or any other for that matter) Going directly for localhost:8000, using some or all of the headers I can capture with tcpdump: ``` $ curl -v -H 'Accept-Encoding: gzip, deflate' -H 'Connection: Keep-Alive' -H 'Host: lists.example.org' -A 'python-requests/2.32.3' http://localhost:8000/mailman3/api/templates/list/community.lists.example.c… ``` as well as going through the local httpd: ``` $ curl -v --http1.1 -H 'Accept-Encoding: gzip, deflate' -H 'Connection: Keep-Alive' -H 'Host: lists.example.org' -A 'python-requests/2.32.3' https://lists.example.org/mailman3/api/templates/list/community.lists.examp… ``` Running tcpdump during those runs shows me it's sending the same headers as mailman does. Thus on http protocol level it's the same, but still the server returns immediately. What I have just noticed is that the Date header in the delayed response is the "late" time. I have even compared tcp headers from either capture. They look identical down to the frame sizes. The only difference the last times is that with curl, the server side sends the ACK for the request and milliseconds later a PSH,ACK with the response headers. When it comes internally from mailman it sends the ACK for the request and then 5 seconds later it sends the PSH,ACK with the response headers. Thanks, Gerald

1 year, 9 months

Search results for query "sapiro"