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

[MM3-users] Re: Editing "automatic responses" tab i Postorius does not work

by David Krantz

But this one is already exposed. But I cannot change it anyway as the tab requires URIs for the different templates to allow saving. I do not use those URIs as I have configured the defaults as I like them. I tried once and it failed so I decided to set the defaults instead. cheers. // David On Sun, May 21, 2017 at 3:48 PM, Mark Sapiro <mark(a)msapiro.net> wrote: > On 5/21/17 5:22 AM, David Krantz wrote: >> >> I am trying to change e.g. the value of "notify admin on membership >> changes" through postorius. > > > There are still many settings not yet exposed in Postorius. We are > painfully aware of this and will probably be working on some of this at > the PyCon sprints starting tomorrow. > > Until we get more of these addressed, you will need to use tools like > "mailman withlist" to set these things. > > -- > 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 > https://lists.mailman3.org/mailman3/lists/mailman-users.mailman3.org/

9 years, 1 month

[MM3-users] so many instances of mailman.cfg

by Christian Stalberg

Question: I've five copies of mailman.cfg on my box. How can I tell which one is actually being used please? -----Original Message----- From: Mark Sapiro <mark(a)msapiro.net> Sent: Friday, November 26, 2021 11:06 AM To: mailman-users(a)mailman3.org Subject: [MM3-users] Re: mass subscribers disablement!? On 11/26/21 9:39 AM, Christian Stalberg via Mailman-users wrote: > After the first time where users were unsubscribed automatically, I > added back one at a time all the subscribers who were unsubscribed. > Now they have all been unsubscribed again automatically. They are > valid working email addresses. How can I stop this behavior from occurring please? Do you have the bounce processing notifications `Notify owner on disable` and `Notify owner on removal` set to `Yes`. If not, set them. Then, what's in the notices you receive? You might also consider setting `verp_probes: yes` in the `[mta]` section of mailman.cfg. This will avoid some issues with users being disabled/unsubscribed due to list posts being rejected as spam. -- 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/

4 years, 6 months

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

by Mark Sapiro

On 7/2/25 22:11, Steve Brown via Mailman-users wrote: > I may include more info than you really want to know. Here is the gist of the complaint: > > "For a while now, my e-mail for this list (but not other lists) just shows "To RADG" from "RADG" with a "CC" showing the actual sender's address. > That becomes a PITA when I need to find a post by a particular person, because the e-mail list does not show the CCs in the list, so I need to open each one to see who actually sent it." The user is using T-bird and does not need to scroll through the email list to find a post from a particular user. They should be using quick filter for this. I will send you more detail about this off list as details about the T-bird UI are off topic here. > This subscriber is not very savvy about email, and doesn't seem to understand fully when I tell him how it works, so if I start talking about headers, that's a PITA, too. He claims: > > "RADG is the only list that is afflicted by this, out of 21 that include groups.io, yahoo, google, Lyris, and probably a few I don't recall." > > Because some other members, including me, have had problems with unexpected entries in both From and To lines, I suspect that Mailman 3 does the DMARC enough differently than other lists and forums to cause conflicts with the way the MUAs try to help the user autocomplete an address. Most of those problems go away if they put an association of RADG (Risk Analysis Discussion Group) with radg(a)lists.radg.us in their address book. We chose the "use your own URL" option. The actual server address is deu.mailmanlists.eu; I don't know whether their customization of the MM3 installation might cause some of the problem. > > My understanding is that all of the recent posts are missing the poster's name, after behaving as expected for some time. Something must have changed, but what is baffling me. If you have any further ideas, fine, but don't waste a lot of time on this. Mailman, both 2.1 and 3, have been modifying the From: header for DMARC in exactly the same way for years. If anything changed is this regard it is specific to the deu.mailmanlists.eu installation, but I doubt it was Mailman that changed, particularly because you are still seeing the From: as it always was. It is much more likely that the users T-bird changed. -- Mark Sapiro <mark(a)msapiro.net> The highway is for gamblers, San Francisco Bay Area, California better use your sense - B. Dylan

11 months, 3 weeks

[MM3-users] Re: My Server is unable to connect to Mailman REST API few times

by Mark Sapiro

On 9/23/20 6:32 AM, Shashikanth Komandoor wrote: > Dear Mark, > > As I already said, your suggestion worked well on one list. > > But when I tried to implement the same trick on another list, I > found the below error messages in the mailman.log. > > >> * Sep 23 18:31:31 2020 (22951) Uncaught runner exception: [Errno >> 2] No such file or directory: >> '/var/lib/mailman/mailman/var/lists/press.dpr-pb.lsmgr.nic.in/digest.mmdf >> <http://press.dpr-pb.lsmgr.nic.in/digest.mmdf>'* >> >> >> *Sep 23 18:31:31 2020 (22951) Traceback (most recent call last):* >> * File "/usr/lib64/python3.6/mailbox.py", line 581, in __init__* >> * f = open(self._path, 'rb+')* >> *FileNotFoundError: [Errno 2] No such file or directory: >> '/var/lib/mailman/mailman/var/lists/press.dpr-pb.lsmgr.nic.in/digest.mmdf >> <http://press.dpr-pb.lsmgr.nic.in/digest.mmdf>'* >> *During handling of the above exception, another exception occurred:* >> *Traceback (most recent call last):* >> * File "/var/lib/mailman/mailman/src/mailman/core/runner.py", line 173, >> in _one_iteration* >> * self._process_one_file(msg, msgdata)* >> * File "/var/lib/mailman/mailman/src/mailman/core/runner.py", line 266, >> in _process_one_file* >> * keepqueued = self._dispose(mlist, msg, msgdata)* >> * File "/var/lib/mailman/mailman/src/mailman/runners/pipeline.py", line >> 37, in _dispose* >> * process(mlist, msg, msgdata, pipeline)* >> * File "/var/lib/mailman/mailman/src/mailman/core/pipelines.py", line 50, >> in process* >> * handler.process(mlist, msg, msgdata)* >> * File "/var/lib/mailman/mailman/src/mailman/handlers/to_digest.py", line >> 47, in process* >> * with Mailbox(mailbox_path, create=True) as mbox:* >> * File "/usr/lib64/python3.6/mailbox.py", line 893, in __init__* >> * _mboxMMDF.__init__(self, path, factory, create)* >> * File "/usr/lib64/python3.6/mailbox.py", line 585, in __init__* >> * f = open(self._path, 'wb+')**FileNotFoundError: [Errno 2] No such >> file or directory: >> '/var/lib/mailman/mailman/var/lists/press.dpr-pb.lsmgr.nic.in/digest.mmdf >> <http://press.dpr-pb.lsmgr.nic.in/digest.mmdf>'* >> >> I ran in both the ways you suggested i.e. through "mailman shell" > and "mailman remove". But no luck. > > Could you please suggest me at this point ? Mailman is trying to add a message to the digest of the press.dpr-pb.lsmgr.nic.in list, but the /var/lib/mailman/mailman/var/lists/press.dpr-pb.lsmgr.nic.in/ directory doesn't exist, presumably because the list has been removed. The question is why is Mailman trying to write to this list's digest.mmdf? Did the above result from unshunting something from before the list was removed? -- 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: Debian upgrade Hyperkitty not archiving

by Mark Sapiro

On 2/27/26 13:23, Phil Steel-Wilson via Mailman-users wrote: > > I'm working at a volunteer organization with around a dozen mailing > lists that were previously on mm2 that have been upgraded to mm3 with > the upgrade to debian trixie. Mailman is running and the lists all work > ok but i found 1800 mails in the shunt queue. Hyperkitty also shows all > the old archives pre 2020 the same as in the django console. When i > tried to unshunt the mails they moved to the bad queue. How do i find > whats wrong here? If this is the Debian package, you should be working with Debian. See <https://wiki.list.org/x/12812344>. > Mailman Core Version GNU Mailman 3.3.10 (Tom Sawyer) > Mailman Core API Version 3.1 > Mailman Core Python Version 3.13.5 (main, Jun 25 2025, 18:55:22) [GCC > 14.2.0] There is a compatibility issue between Mailman 3.3.10 from PyPI and Python 3.13, but this is apparently fixed in the Debian package. See <https://lists.mailman3.org/archives/list/mailman-users@mailman3.org/message…> and near the end of <https://lists.mailman3.org/archives/list/mailman-users@mailman3.org/message…> Mails are shunted because of some uncaught exception in processing. See <https://lists.mailman3.org/archives/list/mailman-users@mailman3.org/message…> for more info on dealing with shunted messages. Messages can end up in the bad queue in multiple ways. One way is content filtering ends up with an empty message and the list's content filtering Filter Action is Preserve. This requires ``` filtered_messages_are_preservable: yes ``` in the [mailman] section of mailman.cfg. The only other way messages end up in the bad queue is in reprocessing messages. When a message is picked up for processing by a queue runner it's extension is changed from .pck to .bak. Then if that runner crashes for some reason without finishing processing of that message, the .bak file remains and when the runner restarts, the entry is reprocessed. If unpickling the .bak throws an exception or if reprocessing the same message is tried 3 times without success, the message is placed in the bad queue. The following errors have nothing to do with messages in the shunt or bad queues. They are the result of trying to log in to the web UI with the fedora oAuth login method which is apparently misconfigured. > Traceback (most recent call last): ... > TypeError: OpenIDProvider.get_server_settings() missing 1 required > positional argument: 'endpoint' > ERROR 2026-02-27 20:50:19,995 1769748 django.request Internal Server > Error: /mailman3/accounts/fedora/login/ > Traceback (most recent call last): ... > TypeError: OpenIDProvider.get_server_settings() missing 1 required > positional argument: 'endpoint' ... > ERROR 2026-02-27 20:51:20,841 1769748 django.request Internal Server > Error: /mailman3/accounts/fedora/login/ -- Mark Sapiro <mark(a)msapiro.net> The highway is for gamblers, San Francisco Bay Area, California better use your sense - B. Dylan

3 months, 4 weeks

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

by David Newman

On 12/28/21 7:52 PM, Mark Sapiro wrote: > On 12/28/21 3:51 PM, David Newman wrote: >> On 12/28/21 1:20 PM, Mark Sapiro wrote: >> >> > If so, try adding >> > >> > KillSignal=SIGQUIT >> > >> > to the Service section and see if that fixes it. >> >> root@myhost:/etc/mailman3# time systemctl restart mailmanweb >> >> real 0m1.026s >> user 0m0.008s >> sys 0m0.004s >> >> My limited understanding of SIGQUIT is that it dumps core, but 'find / >> -type f -name '*.core' did not return any core dumps from this event. > > > Actually, SIGINT is probably better, SIGINT does fine: root@myhost:/etc/systemd/system# time systemctl restart mailmanweb real 0m1.024s user 0m0.009s sys 0m0.006s > but they should be equivalent. See > https://uwsgi-docs.readthedocs.io/en/latest/Management.html#signals-for-con… > and > https://uwsgi-docs.readthedocs.io/en/latest/Management.html#stopping-the-se… > > > I'll update the doc. Thank you! > >> Still unsure why the service hung on stop, but thanks! > > It hung on stop because systemd wasn't told how to stop uwsgi so it sent > a SIGTERM which doesn't stop it. Got it. Again, many thanks. dn

4 years, 5 months

[MM3-users] Re: Weird response to postings after subscriptions and accounts

by Mark Sapiro

On 9/18/19 11:13 PM, Paul Arenson wrote: > Thank you Mark. I appreciate the response. Let me respond in two messages. The first is to confirm the rules for signing off for both types of used: > > The second is to clarify my problems with the signup procedure and how I might deal with it. (Mostly a very small change on your part and an explanation on my website for my users) > > 1) So, for both subscribers vi postorius only and hyperkitty users: > email to discuss-leave(a)list.tokyoprogressive.org (or > discuss-unsubscribe(a)list.tokyoprogressive.org) Yes, but you seem to have some confusion about how things work. Mailman 3 consists of several pieces. See <https://mailman.readthedocs.io/en/latest/src/mailman/docs/introduction.html…>. As it says there, Postorius and HyperKitty are separate, web based applications for list management and archiving respectively. Both of these are Django projects - Django is a Python web framework. What you refer to as hyperkitty users are actually Django Users. When you create and account and/or log in at Postorius or HyperKitty, you are creating/logging in to a Django account. When you are logged in, Django, and thus Postorius and HyperKitty know who you are. If you aren't logged in, they don't. > 2) Only for hyperkitty users, you can login, go to > https://list.tokyoprogressive.org/postorius/lists/discuss.list.tokyoprogres… > and click the big red unsubscribe button. You need to be logged in for this so Postorius knows who to unsubscribe. > 3) Also only for hyperkitty users, log in and click the dropdown at the upper right, select Account and click the Delete Account tab or go directly to > https://list.tokyoprogressive.org/user-profile/ and click the Delete > Account tab or go directly to > https://list.tokyoprogressive.org/user-profile/delete This deletes your Django account, but does not affect your list memberships. > (Guessing that #3 will not unsubscribe the person and--if they have already done 1 or 2, failing to do number 3 is not going to be a big problem. Am I right?) That's right. The important thing is Postorius itself knows nothing about lists or list settings or list members. It gets and/or sets this information by communicating with Mailman core. You saw an example of this when you changed an archive from public to private. Postorius told Core to make it private and Postorius would then tell you it was private because it would get that information from Core. But, it required a daily cron job to propagate that setting to HyperKitty, so HyperKitty didn't get the memo until later. I hope this helps rather than adding confusion. -- Mark Sapiro <mark(a)msapiro.net> The highway is for gamblers, San Francisco Bay Area, California better use your sense - B. Dylan

6 years, 9 months

[MM3-users] Re: Apache+mod_wsgi issue

by Mark Sapiro

On 12/24/22 00:00, Odhiambo Washington wrote: > > These are my files: > 1. urls.py > <CUT > > from django.conf.urls import include > from django.urls import re_path > from django.contrib import admin > from django.urls import reverse_lazy > from django.views.generic import RedirectView > > urlpatterns = [ > re_path(r'^$', RedirectView.as_view( > url=reverse_lazy('list_index'), > permanent=True)), > re_path(r'^postorius/', include('postorius.urls')), > re_path(r'^hyperkitty/', include('hyperkitty.urls')), > re_path(r'', include('django_mailman3.urls')), > re_path(r'^accounts/', include('allauth.urls')), > # Django admin > re_path(r'^admin/', admin.site.urls), > re_path(r'^mailman3/', include('postorius.urls')), > re_path(r'^archives/', include('hyperkitty.urls')), > ] > </CUT> You don't need all of those. ^postorius/ and ^mailman3/ are two different ways to access Postorius, and ^hyperkitty/ and ^archives/ are two different ways to access HypereKitty. You only need one of each, but having both is OK. > 2. apache.conf > <CUT> > ... > Alias /static "/opt/mailman/mm/static" > <Directory "/opt/mailman/mm/static"> > Require all granted > </Directory> > # WSGIScriptAlias /mailman3 /opt/mailman/mm/wsgi.py > # WSGIScriptAlias /accounts /opt/mailman/mm/wsgi.py > # WSGIScriptAlias /admin /opt/mailman/mm/wsgi.py > # WSGIScriptAlias /archives /opt/mailman/mm/wsgi.py > # WSGIScriptAlias /user-profile /opt/mailman/mm/wsgi.py > # WSGIScriptAlias /hyperkitty /opt/mailman/mm/wsgi.py > # WSGIScriptAlias /postorius /opt/mailman/mm/wsgi.py > WSGIScriptAlias / /opt/mailman/mm/wsgi.py This will send every http request to mod_wsgi except for requests to /static. This is OK if there are no other web sites on this server and the only http requests are for Django related things. ... > I have tested with creating all those commented out aliases and that ended > up still giving me /mailman3/mailman3/* which I did not > like, although everything appeared to work. > I then ended up with only "WSGIScriptAlias / /opt/mailman/mm/wsgi.py" > and now when I type https://mm3-lists.kictanet.or.ke I end > up at https://mm3-lists.kictanet.or.ke/mailman3/lists/. Of course something > has appended "/mailman3" > So this has resulted in all URLs having /mailman3/ appended, except for the > /archives link. How about https://mm3-lists.kictanet.or.ke/user_profile/ ? > Now my question is about what could be adding the /mailman3. Is it possible > that I installed something out of the ordinary? It's a mod_wsgi thing. I haven't used mod_wsgi for Mailman for some time (I now use gunicorn on all the sites I manage), but when I did I think I had WSGIScriptAlias /mm3 /opt/mailman/mm/wsgi.py and all the URLs were like https://example.com/mm3/mailman3/..., https://example.com/mm3/archives/..., etc. -- 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: (Custom) Plugins: Proper file path(s) for adding a handler?

by Thomas Ward

On 10/24/23 18:53, Mark Sapiro wrote: > On October 24, 2023 3:47:10 PM PDT, Thomas Ward via Mailman-users <mailman-users(a)mailman3.org> wrote: >> On 10/24/23 18:29, Mark Sapiro wrote: >>> What if you try this with `mailman-web shell`? >>> >> Doesn't error on load, but can't access configs in order to see if my custom handler is present. Which Abhilash said has to be done in the mailman shell - as does the documentation. Mailman can't even start with this added. Which is a problem. > > I was confused. I should have said ` mailman shell`, not `mailman-web shell`. Insert "circular problem" here. When I DO NOT have the module loaded in the configuration, `mailman shell` works. Since that was functional, I went into the shell and executed this: > from mailman_customizations.hooks import MailmanCustomizations This worked fine, but obviously importing the class doesn't necessarily *activate* the class. So something is up with how I'm *supposed* to activate the plugin in the config, and we know that it's visible to Mailman in its shell, but it can't autoload it. So, again, not sure where to look next for debugging. Thomas

2 years, 8 months

[MM3-users] Re: Fwd: [Django] ERROR (EXTERNAL IP): Internal Server Error: /archives/search

by Johannes Rohr

Am 24.01.2023 um 01:26 schrieb Mark Sapiro: > On 1/23/23 14:00, Johannes Rohr wrote: >> >> Am 23.01.23 um 21:08 schrieb Mark Sapiro: >>> e.g. >>> ``` >>> HAYSTACK_CONNECTIONS['default']['PATH'] = >>> '/opt/mailman/mm/var/fulltext_index' >> >> Thanks! Indeed. Including this line helps. It makes the error go >> away. So I guess the instructions should be amended. >> >> After that, for some reason, I have to re-index all lists, because >> initially, empty results were returned for any query, only after >> re-indexing to I get results. > > Did you adjust the path to point to your existing fulltext_index? yes, I did. > If not and if you had, I don't thing you would have needed to reindex. That's precisely, why I was surprised. > > The question is what changed so that the relative "fulltext_index" no > longer pointed to where the actual directory was. I don't think that anything had changed, I just don't think I never checked whether the fulltext search actually works and so I spotted this error rather late in the game. Thanks, Johannes > >

3 years, 5 months

Search results for query "sapiro"