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

[MM3-users] Re: Internal Server Error: Reattach this thread

by Mark Sapiro

On 10/25/22 17:08, cold00water(a)gmail.com wrote: > Hey. > > Looking at other code, "subject" is a method. > > I fixed it by correcting the code. > is this a bug? python version issue? > > * /opt/mailman/venv/lib/python3.10/site-packages/hyperkitty/views/thread.py > > 411 @check_mlist_private > 412 def reattach_suggest(request, mlist_fqdn, threadid): > 413 mlist = get_object_or_404(MailingList, name=mlist_fqdn) > 414 thread = get_object_or_404(Thread, mailinglist=mlist, thread_id=threadid) > 415 > 416 default_search_query = stripped_subject( > # change: thread.subject to thread.subject() > 417 mlist, thread.subject()).lower().replace("re:", "") > > * /opt/mailman/venv/lib/python3.10/site-packages/hyperkitty/models/thread.py > > 69 def __str__(self): > # change: thread.subject to thread.subject() > 70 return self.subject() Did you test this?, How? I.e. where you able to produce the error without your change and then verify that your change fixed it? The existing code works in all but rare situations, and I think those are due to the thread object being instantiated with missing arguments. In any case, your changes cause the ReattachTestCase.test_suggestions test in hyperkitty/tests/views/test_thread.py to fail as follows. ``` hyperkitty/tests/views/test_thread.py:66: in test_suggestions response = self.client.get(reverse('hk_thread_reattach_suggest', .tox/py39-django32/lib/python3.9/site-packages/django/test/client.py:742: in get response = super().get(path, data=data, secure=secure, **extra) .tox/py39-django32/lib/python3.9/site-packages/django/test/client.py:396: in get return self.generic('GET', path, secure=secure, **{ .tox/py39-django32/lib/python3.9/site-packages/django/test/client.py:473: in generic return self.request(**r) .tox/py39-django32/lib/python3.9/site-packages/django/test/client.py:719: in request self.check_exception(response) .tox/py39-django32/lib/python3.9/site-packages/django/test/client.py:580: in check_exception raise exc_value .tox/py39-django32/lib/python3.9/site-packages/django/core/handlers/exception.py:47: in inner response = get_response(request) .tox/py39-django32/lib/python3.9/site-packages/django/core/handlers/base.py:181: in _get_response response = wrapped_callback(request, *callback_args, **callback_kwargs) hyperkitty/lib/view_helpers.py:137: in inner return func(request, *args, **kwargs) hyperkitty/views/thread.py:445: in reattach_suggest mlist, thread.subject()).lower().replace("re:", "") E TypeError: 'str' object is not callable ``` -- 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: Digestion debugging

by Mark Sapiro

On 2/20/26 16:35, John Price via Mailman-users wrote: > I'm having trouble getting digests to work. When I try to manually > send one, it does nothing, and then the digest gets deleted (I > guess?). If the `mailman digests` command is run without a --send or --periodic option, it won't send any digests. See `mailman digests --help`. Messages for a list's digest are accumulated in a mailbox at Mailman's var/lists/<list_id>/digest.mmdf. They are sent when the mailbox reaches the size set as the list's digest_size_threshold and if the list's digest_send_periodic is True, when the `mailman digests --periodic` command is run - normally run daily via cron,. See <https://docs.mailman3.org/en/latest/install/virtualenv.html#setup-cron-jobs>. > I would love it if the documentation explained a bit more how the > process works. How are the files gathered? What file can I backup and > later restore if I'm debugging it? One of the handlers run in the posting pipeline is `to_digest` which adds the message to the list's digest.mmdf file and checks if a digest should be sent based on size. > Also, how are the digest issue and volume numbers work? Is there any > way to control that? Since I've been running digests for decades, can > I set the volume and issue to what I want so that the numbering > continues from where the other installation left off? The issue number is incremented with each digest At intervals determined by the list's digest_volume_frequency The issue number is reset and the volume number is incremented. The volume can also be incremented and the issue reset by running `mailman digests` with the `--bump` option ` The current volume number is the list's volume attribute and the next issue number is the list's next_digest_number attribute. These can be manipulated via `mailman shell` or by direct manipulation of the list's entry in the mailinglist table in the database. -- Mark Sapiro <mark(a)msapiro.net> The highway is for gamblers, San Francisco Bay Area, California better use your sense - B. Dylan

3 days, 23 hours

[MM3-users] Re: Auth question

by Mark Sapiro

On 1/3/19 5:33 PM, kelly.close(a)lrewater.com wrote: > Thanks Mark. I keep coming back to this and checking it again and again. The two keys match, and there are no quotes on the api_key. > > This is what I thought the problem was from the start but I just can't see anything wrong with those two settings. I'm going to look again - maybe entirely re-type the lines - what if there is a trailing space or something... I don't think trailing white space on the api_key setting is significant, and whitespace following the trailing quote in the MAILMAN_ARCHIVER_KEY setting is not significant, but embedded whitespace in the key itself could be an issue. Possibly Mailman and/or Hyperkitty aren't getting this info from the files you think they are. The command that you use to start Mailman should have a -C option pointing to Mailman's config. That in turn has a [archiver.hyperkitty] section pointing to the Mailman Hyperkitty config. That in turn contains the api_key. Then whatever process you use to run the wsgi application will set DJANGO_SETTINGS_MODULE in it's environment to point to settings.py or whatever you call it (without the .py extension) and that in turn imports overrides from settings_local.py. You need to understand what the working directory is of the process that imports the DJANGO_SETTINGS_MODULE. If you need more info, you could try modifying hyperkitty/hyperkitty/views/mailman.py at around lines 64 - 68 to: if request.GET.get("key") != settings.MAILMAN_ARCHIVER_KEY: return HttpResponse( """<html><title>Auth required</title><body> <h1>Authorization Required</h1> {} != {}</body></html>""" .format(request.GET.get("key"), settings.MAILMAN_ARCHIVER_KEY), content_type="text/html", status=401) This should display the values that don't match as part of the error response. Note that this is Python and leading whitespace is significant and if you're reading this in HyperKitty, you won't see it unless you "display in fixed font" (the "A" icon), and even then, there may be line wrap. -- 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: mailman 3.x upgrade and downgrade

by C. Souza

Ok, thanks! On Tue, Jul 12, 2022 at 1:44 PM Mark Sapiro <mark(a)msapiro.net> wrote: > On 7/12/22 9:35 AM, C. Souza wrote: > > > > I can't see the mistune package, maybe it wasn't a requirement for that > > version of mm3. > > > > 1 Package Version > > 2 ------------------- ---------- > > ... > > 39 HyperKitty 1.3.3 > > > Correct. It is not a requirement until HyperKitty 1.3.5 > > -- > 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/ >

3 years, 7 months

[MM3-users] Re: user self registration

by Christian Stalberg

Something strange is now going on. Now when a user tries to subscribe themself and they get the ' Please check your inbox for further instructions' no such email arrives in their mailbox. Relatedly, if I as an admin try adding someone to a list via the Mass Subscribe, they are not added to the list, but they do appear in the listing of all Users. Help! -----Original Message----- From: Christian Stalberg via Mailman-users <mailman-users(a)mailman3.org> Sent: Monday, December 8, 2025 6:16 AM To: mailman-users(a)mailman3.org Cc: 'Mark Sapiro' <mark(a)msapiro.net> Subject: [MM3-users] Re: user self registration That worked. Thank you! -----Original Message----- From: Mark Sapiro <mark(a)msapiro.net> Sent: Sunday, December 7, 2025 9:26 AM To: mailman-users(a)mailman3.org Subject: [MM3-users] Re: user self registration On 12/7/25 07:46, Christian Stalberg via Mailman-users wrote: > Spammers have been registering and not subscribing. I want to turn off > the user self registration at https://lists.ccalternatives.org/mailman3/ . > > I edited /etc/mailman3/settings.py adding ACCOUNT_ALLOW_REGISTRATION = > False and restarted the services, but the ' Sign Up' option remains. I > assume /etc/mailman3/settings.py is my active settings file. > > What am I doing wrong? Web searches may find reference to a django-allauth setting ACCOUNT_ALLOW_REGISTRATION, but this setting doesn't exist in current django-allauth The setting you want is ACCOUNT_ADAPTER = ‘django_mailman3.views.user_adapter.DisableSignupAdapter’ See https://docs.mailman3.org/en/latest/faq.html#how-to-disable-signup or https://docs.mailman3.org/projects/mailman-web/en/latest/settings.html#mail… -- 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: https://lists.mailman3.org/archives/list/mailman-users@mailman3.org/message… This message sent to csa(a)web-analysts.net _______________________________________________ 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: https://lists.mailman3.org/archives/list/mailman-users@mailman3.org/message… This message sent to csa(a)web-analysts.net

2 months, 2 weeks

[MM3-users] Re: Converting discussion list to read-only list (settings)

by Mark Sapiro

On 10/14/19 5:40 PM, Paul Arenson wrote: > >> Assuming MUA means a mail application. And if that mail application has no reply list function then the setting doesn't work. MUA means Mail User Agent which is another name for mail application, YES. > Uh-oh: I AM LOST AGAIN. (will all caps give me a larger font?) > >> It is the presence of the >> List-Post: header in the message that allows the MUA to offer/process >> the "reply-list" function. > > Ok, I asked how to make it ANNOUNCE ONLY and you said to use "allow_list_posts is False" which is the same as "Include the list post header". Not exactly. You asked what settings were different between discussion style and announce only style. What I answered was that the only setting that differed as set by the style was what Postorius calls "Include the list post header". What I didn't say explicitly was that this is not sufficient to prevent posting to the list. > So does this mean that for a subset of users I cannot make it ANNOUNCE ONLY? And is it some other setting (send to moderator) that prevents it from being a DISCUSSION list? What exactly do you want? You found some info on configuring an announce only list and I referred you to a FAQ on that subject. Both of these do not directly address Mailman 3, but they do give useful information. I am going to stop guessing at what you want to accomplish, so tell me what you want to happen when someone sends a post to the list either from HyperKitty or by email. What should happen to the message? What if anything should be sent to the user? Should this behavior be the same for all users or just a subset. If a subset, how do you identify that subset and what should happen when others attempt to post? -- Mark Sapiro <mark(a)msapiro.net> The highway is for gamblers, San Francisco Bay Area, California better use your sense - B. Dylan

6 years, 4 months

[MM3-users] Re: moving lists to another server

by Mark Sapiro

On 11/20/23 00:58, Odhiambo Washington wrote: > > What is the command to export the archive as a mbox from the DB? > I can't figure out which option it is by looking at 'mailman-web -h'. Normally you do this on the old server via the HyperKitty web UI which has download buttons which do things like https://example.com/archives/list/list@example.com/export/list@example.com.… or for a partial archive https://example.com/archives/list/list@example.com/export/list@example.com-… However, in your case I don't think you have the old installation working any more so the above won't help. > BTW, how will ' mailman addmembers' treat a file containing: > ``` > Firstname Lastname <email@address> > Onlyname <email2@address> > ``` Correctly. It will import email@address with display name = 'Firstname Lastname' and email2@address with display name = 'Onlyname'. > I have opted for the simple way to do this: > 1. Create the site in Django Admin and create/configure the list in > Postorius > 2. Add the members from the file dump, with delivery set to regular. > 3. Send the members an email informing them that they need to set their > delivery preferences. > > I am stuck on the issue of exporting the archives to mbox file as already > stated above. Perhaps you can export the mbox via the web UI on the old server or maybe temporarily create a second mailman-web on your server with the old mailman-web database and use that web UI. Otherwise, if you have a working mailman-web that can access this database, you could try something like ``` $ mailman-web shell >>> from hyperkitty.lib.compat import get_list_by_name >>> mlist = get_list_by_name('list_name_only', 'list_domain') >>> with open('output.mbox', 'wb') as fp: ... for email in mlist.emails.order_by("archived_date").all(): ... fp.write(email.as_bytes() + b'\n') ... >>> ``` -- Mark Sapiro <mark(a)msapiro.net> The highway is for gamblers, San Francisco Bay Area, California better use your sense - B. Dylan

2 years, 3 months

[MM3-users] Re: Update a member's display_name

by Mark Sapiro

On 1/17/19 8:45 AM, Nick Wynja wrote: >> user_manager = getUtility(IUserManager) >> u = user_manager.get_user('aperson(a)example.com') >> u.addresses[0].display_name = "Anne" >> commit() > > It seems this method updates the display_name for the user across all lists. Is there a way to update just a single instance of "member" of a list rather than the site-wide user? > > I've tried this: > > mailman shell -l test(a)example.com > >>>> mem = m.members.get_member('a(a)example.com') >>>> mem > <Member: a(a)example.com on test(a)example.com as MemberRole.member> >>>> mem.display_name > 'Anne' >>>> mem.display_name = "Anne P" > Traceback (most recent call last): > File "<console>", line 1, in <module> > AttributeError: can't set attribute That's because mem.display_name is a "calculated" attribute. The definition of the IMember class says > display_name = Attribute( > """The best match of the member's display name. > > This will be `subscriber.display_name` if available, which means it > will either be the display name of the address or user that's > subscribed. If unavailable, and the address is the subscriber, then > the linked user's display name is given, if available. When all else > fails, the empty string is returned. > """) and > subscriber = Attribute( > """The object representing how this member is subscribed. > > This will be an ``IAddress`` if the user is subscribed via an explicit > address, otherwise if the the user is subscribed via their preferred > address, it will be an ``IUser``. > """) So there is no member display_name per se. The display_name is the display_name of the associated IUser or IAddress, and these are global. The bottom line is there is not a way to update just a single instance of "member" of a list rather than the site-wide user or address? -- 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: Delete Django profiles not signed up to a list

by Mark Sapiro

On 3/31/23 14:17, Andrew Hodgson wrote: > Hi. > > Has anyone managed to get this script running using the Mailman-Web setup in a venv? It was working when Settings.py was in the /opt/mailman/mm directory but since moving to Mailman-Web has it in /etc/mailman3. I have been trying to import Mailman-Web to get the Django environment running but every time I do this I get a not configured exception raised. First, get the latest version of the script from https://www.msapiro.net/scripts/clean_users.py - not the one in this threat attached to https://lists.mailman3.org/archives/list/mailman-users@mailman3.org/message… Then, you need to change `/opt/mailman/mm` in three places to `/etc/mailman3` as in ``` --- /opt/mailman/mm/bin/clean_users.py 2021-05-08 20:03:31.657565251 -0700 +++ clean_users.py 2023-03-31 15:48:31.772383287 -0700 @@ -2,13 +2,13 @@ import os import sys -sys.path.insert(0, '/opt/mailman/mm') +sys.path.insert(0, '/etc/mailman3') # The above line is required. The next line doesn't hurt, but it doesn't work # because the PYTHONPATH environment setting is processed by Python's setup # and must be in the environment when Python starts to be effective. -os.environ['PYTHONPATH'] = '/opt/mailman/mm' +os.environ['PYTHONPATH'] = '/etc/mailman3' os.environ['DJANGO_SETTINGS_MODULE'] = 'settings' -os.environ['MAILMAN_CONFIG_FILE'] = '/opt/mailman/mm/mailman.cfg' +os.environ['MAILMAN_CONFIG_FILE'] = '/etc/mailman3/mailman.cfg' import django django.setup() ``` Also, look at this ``` # If we delete the Django user and there is a Mailman user with no memberships # shall we delete the Mailman user too. DELETE_MAILMAN_USER = False # Shall we delete the Django user if there is a Mailman user with no # memberships or only if there is no Mailman user. DELETE_DJANGO_IF_MAILMAN = True ``` and consider whether you want to set `DELETE_MAILMAN_USER = True` to also delete the Mailman user if any, and/or set `DELETE_DJANGO_IF_MAILMAN = False` to not delete the django user if there is a Mailman user with no memberships. -- Mark Sapiro <mark(a)msapiro.net> The highway is for gamblers, San Francisco Bay Area, California better use your sense - B. Dylan

2 years, 10 months

[MM3-users] Re: Internal Server Error, Need 2 values to unpack in for loop; got 1

by Mark Sapiro

On 7/26/24 09:21, Elias Rudberg wrote: > > Yes, there are strange-looking long queries there at the times when > these errors happen. > > Here is an example of what such a request URL looks like, where I have > replaced some parts with [...] to avoid including anything sensitive: > > Request URL: > https://[...ip-address...]/mailman3/postorius/lists/?widget=[...]svg[...]onload=confirm[...]xss-widget[...]&height=[...]svg[...]onload=confirm[...]xss-height[...]&screen=[...]svg[...]onload=confirm[...]xss-screen[...]&pass2=[...]svg[...]onload=confirm[...]xss-pass2[...]&redirect_to=[...]svg[...]onload=confirm[...]xss-redirect_to[...]&items=[...]svg[...]onload=confirm[...]xss-items[...]&string=[...]svg[...]onload=confirm[...]xss-string[...]&hidden=[...]svg[...]onload=confirm[...]xss-hidden[...]&f=[...]svg[...]onload=confirm[...]xss-f[...]&step=[...]svg[...]onload=confirm[...]xss-step[...]&role=[...]svg[...]onload=confirm[...]xss-role[...]&preview_nonce=[...]svg[...]onload=confirm[...]xss-preview_nonce[...]&date=[...]svg[...]onload=confirm[...]xss-date[...]&event=[...]svg[...]onload=confirm[...]xss-event[...] I see similar ones from time to time. > I looked up the IP address that those requests come from (all seem to > come from the same IP address) and that corresponds to a hostname called > something with "scanner" that looks like it belongs to some > cybersecurity company. There are also many other requests from that same > IP address, including things like "GET /file://etc/passwd" and similar, > so it looks like someone is bombarding us with various weird requests as > a form of "scanning" where they are trying to find vulnerabilities. That > could also explain why we see those "Internal Server Error" errors > recurring every day, if they run that vulnerability scan daily. Yes, I think these are attempts to find vulnerabilities. > So maybe those strange request URLs that lead to the error messages > "[Django] ERROR (EXTERNAL IP): Internal Server Error" that we are > seeing, are constructed by someone who is actively trying to trigger bugs. I don't think this is a DOS attack or an attempt to trigger bugs. I think they are attempts to find and then exploit vulnerabilities. > But anyway, no matter what strange request URL comes in, I guess the > "Internal Server Error" indicates something going wrong in Mailman or in > Django, a bug in how the request is processed? I'm not certain, but I think it's a Django issue rather than a Mailman issue. In my case, I don't get that many and I just ignore them. -- Mark Sapiro <mark(a)msapiro.net> The highway is for gamblers, San Francisco Bay Area, California better use your sense - B. Dylan

1 year, 6 months

Search results for query "sapiro"