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

[MM3-users] Re: Invalid FilterAction: discard. Treating as discard

by Mark Sapiro

On 6/12/19 1:46 AM, Henrik Rasmussen wrote: > > The difference was that list(m.pass_types) is [] > > Now, setting > > m.pass_types = ['multipart', 'message/rfc822', 'text/plain', 'text/html', 'application/pdf', 'application/nappdf', 'application/x-pdf', 'application/rtf', 'application/vnd.oasis.opendocument.spreadsheet', 'application/vnd.openxmlformats-officedocument.spreadsheetml.sheet', 'application/vnd.ms-excel', 'application/vnd.oasis.opendocument.text', 'application/vnd.openxmlformats-officedocument.wordprocessingml.document', 'application/msword'] > > on the new testlist and resending the mail again, the mail still came out intact. > > So I guess the problem must be something complete different. > > Also I wonder why a newly created list accepts the PDF in question, when list(m.pass_types) is []. You need to look at all of pass_types, filter_types, pass_extensions and filter_extensions for both lists. For a newly created list, these are all empty. They work as in Mailmam 2.1 and are imported from the similarly named 2.1 attributes by `mailman import21`. In brief if filter_content is True, processing is: 1. If a part's MIME type is in filter_types it is removed. 2. If pass_types is not empty and a part's MIME type is not in pass_types it is removed. 3. If a part has a file name and the file name extension is in filter_extensions it is removed. 4. If a part has a file name and pass_extensions is not empty and the part's file name extension is not in pass_extensions it is removed. So in your case of the list that doesn't work, possibilities are: 1. The PDF part's MIME type is in filter_types, or 2. The PDF part has a file name whose extension is in filter_extensions, or 3. pass_extensions is non-empty and The PDF part has a file name whose extension is not in pass_extensions. -- 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: Help with fresh debian install

by Mark Sapiro

On 10/5/19 11:30 AM, Mark Dadgar wrote: > > Running the commands as the correct user solved my issues. Specially, I ran the import21 command as the “list” user (created by the debian/ubuntu package) and the hyperkitty import command as the “www-data” user. I had to add login shells to the passwd entries for those users to make it happen as they get installed with nologin. You could just run, e.g., `sudo -u list bin/mailman import21 ...` which will work even if 'list' can't log in. > I imported a 24G archive inbox and something went wrong along the way - the archives for many months consist of just a single identical thread. Re-running the import results in the following in just a few seconds: ... > Any thoughts on how I can re-run the full import to make sure that all the archives are present? As far as reimporting the entire archive, you need the --since option. As it says in hyperkitty_import --help > --since SINCE only import emails later than this date. Defaults to > the date of the newest message in the existing archive > if any. If you run hyperkitty_import --since=1990-01-01, that should do it. As far as "the archives for many months consist of just a single identical thread", were there error messages when you ran the initial import? Were there issues in the imported mbox that you have corrected? Mailman 2.1's bin/cleanarch can help identify unescaped 'From ' lines that cause problems. If unescaped 'From ' lines is the issue and you have fixed them, rerunning the import should import the messages correctly, but it won't delete the bogus threads. You can delete these threads manually in HyperKitty if you are logged in as a Django superuser. -- Mark Sapiro <mark(a)msapiro.net> The highway is for gamblers, San Francisco Bay Area, California better use your sense - B. Dylan

7 years

[MM3-users] Re: Active archivers and archiving and thread question.

by Mark Sapiro

On 3/31/22 04:39, bob B via Mailman-users wrote: > Thanks, that make sense, Also is there any way to turn that off via command line for a bunch of lists or just in the GUi, I looked at "'mailman shell --details:" but could not find a command to turn it off. > > I had archives off on my lists in mailman 2, and when I import they stayed off, but the archiver is enabled. The HyperKitty and Prototype archivers are enabled by default for new and imported lists. To change that, add ``` [archiver.hyperkitty] enable: no [archiver.prototype] enable: no ``` to mailman.cfg. > I have a script that pulls all the list configs > "curl --user *******:******* http://127.0.0.1:##/3.1/lists/"$i"/config | python3 -m json.tool >> ${OUTPUT_DATA_DIR}/listconfigs.txt > > Then I look to see if any list has changed this setting "archive_policy": "never", so I know if any list admin has enabled archives... > > But is there a setting in the config that shows if the archiver got turned on? I want to know if anyone turns it on after I turn it off You can do the following in `mailman shell` ``` $ mm/bin/mailman shell 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. >>>for mlist in getUtility(IListManager): ... print(mlist.display_name) ... print(f' ArchivePolicy was {mlist.archive_policy}') ... if mlist.archive_policy != ArchivePolicy.never: ... mlist.archive_policy = ArchivePolicy.never ... print(' set to ArchivePolicy.never') ... aset = IListArchiverSet(mlist) ... for ar in aset.archivers: ... if ar.is_enabled: ... ar.is_enabled = False ... print(f' Archiver {ar.name} was enabled; set disabled') ... >>> commit() ``` -- Mark Sapiro <mark(a)msapiro.net> The highway is for gamblers, San Francisco Bay Area, California better use your sense - B. Dylan

4 years, 6 months

[MM3-users] Re: Error while mass operation, no progress display while mass operation is running

by Mark Sapiro

On 2/6/25 04:53, Markus Grandpré wrote: > > At the University of Konstanz we have mailing list administrators who > frequently add and remove up to 10000 (and sometimes more) list members. > I have therefore tested the “Mass subscription” and “Mass removal” > operations and found that both the “Remove ALL members” operation and > the “Mass subscription” operation report an internal server error on the > website, but continue to run in the background until all new members > have been successfully added or deleted. The internal server error is probably due to the wsgi server timing out waiting for a response. See https://docs.gunicorn.org/en/stable/settings.html#timeout for Gunicorn or https://uwsgi-docs.readthedocs.io/en/latest/Options.html#harakiri for uWSGI > Unfortunately, I have not found > any error message in the log files. If you are using uWSGI, a harakiri timeout should be logged in uWSGI's log. > I also tested that mass operations > “Remove listed users” and “Remove Selected” ran successfully and without > any errors. You may want to increase the appropriate timeout and see if that helps. > Regardless of whether a mass operation process runs without errors or > continues to run despite an error, I find it hard that Postorius does > not display the progress of such a mass operation in order to monitor > the process, as mass operations with more than 1000 members are very > time-consuming. Perhaps this could be changed in a future version of > Postorius? This is a reasonable request. The best place for such a request is https://gitlab.com/mailman/postorius/-/issues/new Requests and suggestions on the mailing list, no matter how reasonable, get lost over time. -- Mark Sapiro <mark(a)msapiro.net> The highway is for gamblers, San Francisco Bay Area, California better use your sense - B. Dylan

1 year, 8 months

[MM3-users] Re: Cannot Run Web Frontend

by Mark Sapiro

On 12/24/25 08:14, dap1--- via Mailman-users wrote: > How do I tell if mailman-web is running? There is no such service. In this case, the mailman-web service is gunicorn. > /etc/mailman3/gunicorn.py (recall I had to use py rather than conf to get it to work under Ubuntu): It should have worked as gunicorn.conf despite the warning (not error) that it didn't have a .py extension. > # /etc/mailman3/gunicorn.conf > # # > bind = ['127.0.0.1:8000'] > proc_name = "mailman-web" > # # If you are having response issues you can tune the number of workers. > # # The suggested starting point is (2 x $num_cores) + 1 > # # See https://docs.gunicorn.org/en/latest/design.html#how-many-workers > workers = 3 > chdir = "/opt/mailman/mm" > pidfile = "/opt/mailman/mm/var/gunicorn.pid" > accesslog = "/opt/mailman/mm/var/logs/access.log" > errorlog = "/opt/mailman/mm/var/logs/error.log" > loglevel = 'debug' > > I did notice one thing in the access.log that is wrong: > > 127.0.0.1 - - [24/Nov/2025:16:02:55 +0000] "GET /archives/api/mailman/urls?mlist=lllllllllll%40dddddd.net&msgid=705caa > ab-afcc-4249-8d1d-cc48050d02d1%40bellsouth.net HTTP/1.1" 200 113 "-" "python-requests/2.32.5" This request came from HyperKitty. > The mlist name is wrong. It should be lllllllllll%40gmail.com. I don't know where that is coming from but I'm sure it is left over from before I changed the list name. To you have a hyperkitty list named lllllllllll%40dddddd.net. What does SELECT name FROM hyperkitty_mailinglist; show? > When I include the port in the URL I get an unable to connect page. So nothing is listening on 127.0.0.1:8000 (localhost:8000 assuming the `localhost` is 127.0.0.1 in /etc/hosts and not an IPv6 fe00::0 address) What if any does `netstat -lntp` show is listening on 127.0.0.1:8000? -- Mark Sapiro <mark(a)msapiro.net> The highway is for gamblers, San Francisco Bay Area, California better use your sense - B. Dylan

9 months, 3 weeks

[MM3-users] Re: Strange issue with bounce processing

by Mark Sapiro

On 12/25/20 6:36 PM, Brian Carpenter wrote: > Dear List, > > First of all Merry Christmas to those of you that are observing it. > > I have an issue on one of my Mailman 3 servers. The bounce runner is not > running, even after restarting mailman core. All the other runners are > working fine. Here is the problem, after restarting it, a number of > messages show up in queue/bounces from a single list. What happens if instead of restating core, you stop and then start it? > However the bounce > runner is still not running. So I remove these messages from > queue/bounces folder and restart mailman core. The same messages show up > from the same single list again in queue/bounces. In the > var/logs/bounce.log file, addresses from this list are being logged as > being removed after starting mailman core. They correlate with the > messages showing up in queue/bounces. Bounce runner doesn't actually do much with received/queued bounces. It just gets the bounce and stores a bounce event in in the bounceevent table in the database. It then periodically processes the unprocessed events in the bounceevent table. See <https://docs.mailman3.org/projects/mailman/en/latest/src/mailman/model/docs…>. > I assume these "cached" bounces are what is interfering with the running > of the bounce runner. I don't see anything in the mailman or > mailmansuite log that would explain this behavior. How can I fix this? I don't really understand what's going on. The only messages which get queued in queue/bounces/ are messages to the LIST-bounces address delivered from the MTA, unless possibly they are somehow in queue/retry/ and being retried. What do you see in the MTA logs? -- Mark Sapiro <mark(a)msapiro.net> The highway is for gamblers, San Francisco Bay Area, California better use your sense - B. Dylan

5 years, 9 months

[MM3-users] Re: new list not working

by Mark Sapiro

On 3/10/23 05:07, Christian via Mailman-users wrote: > There are no such messages as you describe. > > After turning on debugging I got this from a test message sent to the new > list: > > Mar 10 04:39:51 2023 (1005) Available AUTH mechanisms: LOGIN(builtin) > PLAIN(builtin) > Mar 10 04:39:51 2023 (1005) Peer: ('127.0.0.1', 51982) > Mar 10 04:39:51 2023 (1005) ('127.0.0.1', 51982) handling connection > Mar 10 04:39:51 2023 (1005) ('127.0.0.1', 51982) >> b'LHLO > zarathustra.ccalternatives.org' > Mar 10 04:39:51 2023 (1005) ('127.0.0.1', 51982) >> b'MAIL > FROM:<christian(a)naturalintelligence.us> SIZE=3499' > Mar 10 04:39:51 2023 (1005) ('127.0.0.1', 51982) sender: > christian(a)naturalintelligence.us > Mar 10 04:39:51 2023 (1005) ('127.0.0.1', 51982) >> b'RCPT > TO:<redlatinleg(a)lists.ccalternatives.org>' > Mar 10 04:39:51 2023 (1005) ('127.0.0.1', 51982) recip: > redlatinleg(a)lists.ccalternatives.org > Mar 10 04:39:51 2023 (1005) ('127.0.0.1', 51982) >> b'DATA' > Mar 10 04:39:51 2023 (1005) ('127.0.0.1', 51982) >> b'QUIT' > Mar 10 04:39:51 2023 (1005) ('127.0.0.1', 51982) connection lost > Mar 10 04:39:51 2023 (1005) ('127.0.0.1', 51982) Connection lost during > _handle_client() Again, that's only the post being delivered to Mailman. What comes after that in the log? And have you checked if Mailman's out runner is running? Note that if it died for some reason and wasn't restarted or used up its restarts, restarting Mailman core won't start it. You need to stop Mailman core and then start it. Are there files in mailman's var/queue/out/ or var/queue/shunt/ directories? You say that only the new list and one other have this issue, but I wonder if the issue is not with specific lists, but rather with posts after a certain time. -- Mark Sapiro <mark(a)msapiro.net> The highway is for gamblers, San Francisco Bay Area, California better use your sense - B. Dylan

3 years, 7 months

[MM3-users] Re: What is result of planned MM3 integrated installation at Pycon?

by Mark Sapiro

On 6/9/18 5:11 PM, Tom Browder wrote: > > Thanks, Mark. Will the release be pretty much a one-step affair for us > older folks without much energy? Probably not, but it depends at least in part on what you are currently running. There is a major change in that everything is now Python 3. This means that you now must run Django under Python 3 which probably entails changes to how the web server runs wsgi apps to support Python 3. Also, You can run Django versions 1.11.x, or 2.0.x, but Django 2.0.x requires you make changes to the Django config as in this diff. > --- a/mailman-suite_project/settings.py > +++ b/mailman-suite_project/settings.py > @@ -94,13 +94,12 @@ INSTALLED_APPS = ( > ) > > > -MIDDLEWARE_CLASSES = ( > +MIDDLEWARE = ( > 'django.contrib.sessions.middleware.SessionMiddleware', > 'django.middleware.common.CommonMiddleware', > 'django.middleware.csrf.CsrfViewMiddleware', > 'django.middleware.locale.LocaleMiddleware', > 'django.contrib.auth.middleware.AuthenticationMiddleware', > - 'django.contrib.auth.middleware.SessionAuthenticationMiddleware', > 'django.contrib.messages.middleware.MessageMiddleware', > 'django.middleware.clickjacking.XFrameOptionsMiddleware', > 'django.middleware.security.SecurityMiddleware', > --- a/mailman-suite_project/urls.py> +++ b/mailman-suite_project/urls.py > @@ -19,7 +19,7 @@ > > from django.conf.urls import include, url > from django.contrib import admin > -from django.core.urlresolvers import reverse_lazy > +from django.urls import reverse_lazy > from django.views.generic import RedirectView > > urlpatterns = [ > @@ -31,5 +31,5 @@ urlpatterns = [ > url(r'', include('django_mailman3.urls')), > url(r'^accounts/', include('allauth.urls')), > # Django admin > - url(r'^admin/', include(admin.site.urls)), > + url(r'^admin/', admin.site.urls), > ] I.e., the name MIDDLEWARE_CLASSES is changed to MIDDLEWARE and the obsolete django.contrib.auth.middleware.SessionAuthenticationMiddleware has to be removed; the reverse_lazy import is changed and include(admin.site.urls) becomes just admin.site.urls -- Mark Sapiro <mark(a)msapiro.net> The highway is for gamblers, San Francisco Bay Area, California better use your sense - B. Dylan

8 years, 4 months

[MM3-users] Re: non-members issue with held email

by Mark Sapiro

On 7/20/21 2:09 AM, Lars Schimmer wrote: > > We created a new mailinglist, added 3 owner and several members. > Now we want some email addresses to post to that list but not receive > mails from the list. So I added those to the "non-member" area of the > mailinglist and checked every non-member to "acceppt at once". > > But on a test, a email address, which is owner AND non-member, cannot > send to mailinglist, always get a "HOLD: ...... The message is not from > a list member" See https://gitlab.com/mailman/mailman/-/issues/659 If you read through the comment thread, you'll see that the issue is when setting moderation action for an address which is both an owner and a nonmember, it is the owner's action that actually gets set, so that the nonmember's action remains set to list default. You need to set the moderation action for the nonmember via `mailman shell`. If all the non-members are the ones you added, you can do ``` $ mailman shell -l your.list.id 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 ... mailing list >>> for nonmember in m.nonmembers.members: ... nonmember.moderation_action = Action.accept ... >>> commit() ``` If there are other nonmembers whose action you don't want to set to accept, you need to do something like ``` >>> emails = ['first(a)example.com', 'second(a)example.com', <more emails>, ] >>> for nonmember in m.nonmembers.members: ... if nonmember.address.email in emails: ... nonmember.moderation_action = Action.accept ... >>> commit() ``` to only do the ones you want. -- Mark Sapiro <mark(a)msapiro.net> The highway is for gamblers, San Francisco Bay Area, California better use your sense - B. Dylan

5 years, 2 months

[MM3-users] Re: Can't subscribe on new site/domain

by Mark Sapiro

On 10/10/25 3:46 PM, Flo via Mailman-users wrote: > > I found it, it's in a different directory: > > /var/lib/mailman3/web# sqlite3 mailman3web.db > SQLite version 3.46.1 2024-08-13 09:16:08 > Enter ".help" for usage hints. > sqlite> SELECT * from django_mailman3_maildomain JOIN django_site ON > site_id = django_site.id; > ... > ... > 8|lists.example.com|7|7|Lists of Example|lists.example.com > sqlite> > > The two working domains are first (...) . The problematic domain > (renamed to lists.example.com) appears when I create it in Postorius. > > For me the only conspicuous is that the numbers are 8|.|7|7 while at the > other two entries they are the same for the whole line: 2|.|2|2 and 4|.| > 4|4 . The fields in order are: 1. the id of the django_mailman3_maildomain entry 2. the mail_domain in the django_mailman3_maildomain entry 3. the site_id the django_mailman3_maildomain entry 4. the id of the django-site entry 5. the domain name in the django-site entry 6. the display name in the django-site entry The important things are 2. and 5. which are the mail host and the web host that you see in the Postorius domains view. 3. and 4. are what we joined on so they will always be the same. They aren't related to 1. which is just sequentially assigned when entries are created. 1., 3. and 4. being equal in some cases is a coincidence. The question is what are the other 2 entries. In particular are all 3 values for 2. different and all 3 values for 5. different or are some the same? If 2 of those entries have the same value for 5. and different values for 2., that explains the issue when accessing Postorius at 5. because that web host does not have a unique mail host. -- Mark Sapiro <mark(a)msapiro.net> The highway is for gamblers, San Francisco Bay Area, California better use your sense - B. Dylan

1 year

Search results for query "sapiro"