Search results for "Postorius" - Mailman-users

Re: Log Owner/Moderator actions ban address matching.

by Odhiambo Washington

On Thu, May 1, 2025 at 1:13 PM Stephen J. Turnbull <steve(a)turnbull.jp> wrote: > Hitashi mancho writes: > > > *May 01 13:11:43 2025 (673989) list1(a)example.com <list1(a)example.com>: > > Discarded posting: From: user1(a)example.com <user1(a)example.com> > > Subject: subject 2025 - Reg.* > > > > In this log, it is unclear which moderator discarded this message. Is > there > > any way we can add that to the log? > > Not easily. That log comes from Mailman core (the list database/post > distribution component). The authority core sees to act on that is > "you know the REST access user and password", but that's known by > Postorius, not by moderators. Weirdly, Postorius doesn't seem to keep > a log of user logins at all. > > If you *need* to know, you can trace back through the logs like this: > > mailman/vette: <DATE> (<PID>) <LIST>: Discarded posting: > From: <EMAIL ADDRESS> > Subject: <TEXT> > mailman/mailman: [DATE] "POST /3.1/lists/<LIST>/held/8 HTTP/1.1" 204 0 "-" > "GNU Mailman REST client v3.3.5" > postorius/access: 127.0.0.1 - - [<DATE>] "POST > /mailman3/lists/<LIST>/held_messages HTTP/1.0" 200 15228 "<REFERRER>" > "<USER AGENT>" > nginx/access: <MODERATOR IP> - - [<DATE>] "POST > /mailman3/lists/LIST/held_messages HTTP/1.1" 200 3080 "<REFERRER>" "<USER > AGENT>" > > where the DATE should match within a few seconds across the logs and > you can probably ID the moderator from the IP address. > So this issue can be addressed by making Postorius to log user logins, right? However, I don't have the patch :) -- Best regards, Odhiambo WASHINGTON, Nairobi,KE +254 7 3200 0004/+254 7 2274 3223 In an Internet failure case, the #1 suspect is a constant: DNS. "Oh, the cruft.", egrep -v '^$|^.*#' ¯\_(ツ)_/¯ :-) [How to ask smart questions: http://www.catb.org/~esr/faqs/smart-questions.html]

1 year, 4 months

Re: Help request, almost got it going, but ....

by Claus-Justus Heine

I have fixed the bug on forks of mailman-core, postorius and mailman-client. C Am 02.09.2017 um 14:36 schrieb Claus-Justus Heine via Mailman-users: > I think I found the bug; I have posted a comment to the issue mentioned > by Mark > > https://gitlab.com/mailman/postorius/issues/58 > > Regards > > Claus > > Am 02.09.2017 um 01:20 schrieb Claus-Justus Heine via Mailman-users: >> Oh well. >> >> Am 01.09.2017 um 23:44 schrieb Mark Sapiro: >>> On 09/01/2017 02:33 PM, Claus-Justus Heine via Mailman-users wrote: >>>> >>>> Seemingly, at some point in the deep dungeons of the source code the >>>> "Acceptable aliases" Text-Box is not interpreted correctly. >>>> >>>> Specifically, at the start it contains the string >>>> >>>> [] >>> >>> >>> See <https://gitlab.com/mailman/postorius/issues/58>. >> >> there they talk about fancy "uni-code thinks" (email addresses?) where >> the task is to convert a new-line separated text-field into an array. Oops. >> >> Kind thanks anyway. >> >>> >>> In order to set things on this page, you need to clear the Acceptable >>> aliases box before submitting changes. You can't actually set Acceptable >>> aliases via Postorius until this is fixed. >> >> The issue seems not to be overly active. I thought -- coming from >> Mailman v2 -- that the configuration of acceptable submitters to an >> email list (e.g. keep everyone moderated?) would be a central and >> prominent and important configuration issue. Seems not to be a central >> point. Mmmh. >> >> Thanks >> >> Claus >> >> > -- Claus-Justus Heine himself(a)claus-justus-heine.de http://www.claus-justus-heine.de/ Schatzmeister der Camerata Academica Freiburg e.V. --- www.cafev.de

9 years

Re: Postorius custom web forms?

by Stephen J. Turnbull

Odhiambo Washington via Mailman-users writes: > You can read this thread: > https://lists.mailman3.org/archives/list/mailman-users@mailman3.org/thread/… Good call, Odhiambo! Also, the Django documents are voluminous. I think they're quite good but YMMV on that. I recommend taking a look, if they suit your brain they'll be really useful. https://docs.djangoproject.com/en/5.1/ is the current release, I think we only support up to 4.2. You can choose the docs that correspond to the version installed in your Mailman environment. There's a small pop-up menu floating in the lower corner of the right-hand side bar where you can switch to the appropriate version. You can also select language there. Steve

1 year, 6 months

Mailman, etc. upgrade woes and persistent bugs

by Stephen J. Turnbull

hansen(a)rc.org writes: > I just had my Mailman suite upgraded. When it got started, I > starting receiving messages that hundreds of subscribers to the > lists had been disables, including several of the list > moderators. I'm sorry to hear about this. > This version started supporting bounce processing, but > how in the world was this upgrade allowed to act on bounces that > were being collected PRIOR to enabling bounce processing?? Well, if bounce processing were occurring as designed, there would be very few bounces in the queue. So it's a difficult thing to anticipate until it happens. And curiously I haven't heard of this before. I mean, if it were going to happen, I would expect that it would have happened at the very busy lists at python.org. So maybe you have an unusually large number of bounces? Not saying it couldn't have been anticipated that *somebody* would have that situation, but we'd have to be extremely lucky, or have a dedicated "red team" looking for ways the feature can break, to find it before installing it. I'm sorry it happened, but AFAICS it's "one of those things". Technically, it appears that the model for bounce information is initialized based on the time of processing, rather than the (alleged) time of injection or the (presumably trustworthy) time of receipt by the local MTA. I don't have time to check further on if that's modified later, but "not modified" explains what you saw very well. I guess you must have had many hundreds of bounce messages in the queue. Probably the simplest way to deal with this is to clear the bounce queue while upgrading, or at least offer the option. Losing a few hours' worth of bounce messages (if they're being processed normally) isn't going to hurt anything. It would also be simple to provide a report of who bounced and the most recent bounce, if desired. > I then looked at several of the disabled accounts, but the > subscription info page in Postorius had no information about > whether an account was enabled or disabled. Why is this not > displayed???. It is for me when I've authenticated, both for lists where I'm owner and for lists where I'm just a subscriber. (However, the lists where I'm subscriber are on python.org where Mark is the site admin, and may be a little ahead of released versions.) > The members can't see if their account is enabled. I guess they are email-only members, and have not authenticated to Postorius? I don't think we will allow unauthenticated access to user info in Postorius in a distributed version. If you really need it, the fastest route would be to find a contractor to customize Mailman for that -- custom versions are not a priority for us. > Is this another example of the disconnect between Mailman and > Postorius? Hard to say. If it's not the users' failure to authenticate, I would guess this is most likely due to a skew in the upgrade process where the versions of Mailman core and Postorius were mismatched, but as I wrote above, I can see this in the user's setting page for both my "owned" lists and for my "just a subscriber lists". It would be inconvenient in your situation because list admins have to visit the user's options page to see and modify it, but I *can* see it. > Further, even after the upgrade, the moderators still cannot access > the list memberships even though all the lists are set to allow > that. This is a known bug being worked on. I'm sorry it was not fixed in time for your upgrade. > As a result of these bugs, after consulting with Brian, who helped > with the upgrade, I spent many hours re-enabling the several > hundred accounts that had been disabled. I had to go through each > email notification to find the address of a disabled account, then > find the list, then the member, in Postorius, and finally enable > the account (at which time Postorius DID show the enabled status). I'm quite sure that this situation could have been addressed quickly and efficiently with a Python script, or in an interactive session with mailmanclient. That doesn't help you now, but in the future feel free to ask us to help with that. We generally are able to respond within a few hours. It's probably not as fast as doing it by hand, but there's the consideration of your time spent. Or if there are Python programmers hanging around, a little fiddling with the mailmanclient command line will probably allow them to figure out what's what, enough to do this. > Please, can the next upgrade include these very basic > fixes/enhancements, which I requested a long time ago: > a. The ability of moderators to see the list membership (a bug). It's in the queue. I can't say when it will be released. > b. The ability of members to change their addresses for all lists > they are subscribed to. What exactly do you want here? I can think of a number of ways to implement that, depending on whether the old address is to be deactivated from the lists, unsubscribed from the lists, or deleted from the Mailman and/or Postorius Users. There may be other variables to consider, as well; I haven't thought about this. AFAICS this is not a trivial feature, and I'd really like to hear from people who want "something like" this about exactly what they want and their use cases. Or we'll release an insufficiently designed feature that causes somebody hundreds of problems.... > c. That when members go to look at their subscription info, they > can actually see the settings. As far as I know, they already can if they have authenticated. If that's not true in your installation(s), we'll need to find out why, because it works for me. Enabling access without authentication is a potentially dangerous change that I currently believe shouldn't happen at all in a Mailman distribution, and will certainly take time to design. If your requirements include unauthenticated access, I would not hold my breath, let alone expect it in the near future. Regards, Steve

5 years, 7 months

Re: Can't subscribe on new site/domain

by Mark Sapiro

On 10/9/25 2:29 PM, Flo via Mailman-users wrote: > > I can see it in Postorius. If the Postorius domains view shows a domain with `lists.example.com` as the email host, the KeyError: 'lists.example.com' exception should not occur. > I have created the a simialar site before and deleted the site and then > again created this one. Maybe the database is messed up? Probably not. The Postorius domains view shows you what's in the database. > I have deleted site - group - list now. And created the site again. If I > go to 'view site' I see all mailing lists on the server and not only > from this site/domain. This is the first thing where it shows > irregularities. I'm not sure what you mean by `view site` but if you mean the VIEW SITE link at the top of the Django admin UI, that is just a link to the host site. I.e., if the Django admin page is https://www.example.com/admin/site/, its VIEW SITE link just goes to https://www.example.com/ and it's always the same link regardless of what Django admin page you are on. -- Mark Sapiro <mark(a)msapiro.net> The highway is for gamblers, San Francisco Bay Area, California better use your sense - B. Dylan

11 months, 2 weeks

problem with postorius initial setup

by John Covici

Hi. I am trying to setup postorius, but I have run into a problem. I am using the example project, except I am using postgresql instead of sqlite3. I ran python manage.py migrate which was successful. On running the development server I get: Exception in thread django-main-thread: Traceback (most recent call last): File "/usr/lib/python3.8/site-packages/django/utils/module_loading.py", line 20, in import_string return getattr(module, class_name) AttributeError: module 'postorius.middleware' has no attribute 'APICountingMiddleware' The above exception was the direct cause of the following exception: Traceback (most recent call last): File "/usr/lib/python3.8/site-packages/django/core/servers/basehttp.py", line 45, in get_internal_wsgi_application return import_string(app_path) File "/usr/lib/python3.8/site-packages/django/utils/module_loading.py", line 17, in import_string module = import_module(module_path) File "/usr/lib/python3.8/importlib/__init__.py", line 127, in import_module return _bootstrap._gcd_import(name[level:], package, level) File "<frozen importlib._bootstrap>", line 1014, in _gcd_import File "<frozen importlib._bootstrap>", line 991, in _find_and_load File "<frozen importlib._bootstrap>", line 975, in _find_and_load_unlocked File "<frozen importlib._bootstrap>", line 671, in _load_unlocked File "<frozen importlib._bootstrap_external>", line 783, in exec_module File "<frozen importlib._bootstrap>", line 219, in _call_with_frames_removed File "/home/covici/mailman_django/example_project/wsgi.py", line 17, in <module> application = get_wsgi_application() File "/usr/lib/python3.8/site-packages/django/core/wsgi.py", line 13, in get_wsgi_application return WSGIHandler() File "/usr/lib/python3.8/site-packages/django/core/handlers/wsgi.py", line 127, in __init__ self.load_middleware() File "/usr/lib/python3.8/site-packages/django/core/handlers/base.py", line 40, in load_middleware middleware = import_string(middleware_path) File "/usr/lib/python3.8/site-packages/django/utils/module_loading.py", line 22, in import_string raise ImportError('Module "%s" does not define a "%s" attribute/class' % ( ImportError: Module "postorius.middleware" does not define a "APICountingMiddleware" attribute/class The above exception was the direct cause of the following exception: Traceback (most recent call last): File "/usr/lib/python3.8/threading.py", line 932, in _bootstrap_inner self.run() File "/usr/lib/python3.8/threading.py", line 870, in run self._target(*self._args, **self._kwargs) File "/usr/lib/python3.8/site-packages/django/utils/autoreload.py", line 53, in wrapper fn(*args, **kwargs) File "/usr/lib/python3.8/site-packages/django/core/management/commands/runserver.py", line 138, in inner_run handler = self.get_handler(*args, **options) File "/usr/lib/python3.8/site-packages/django/contrib/staticfiles/management/commands/runserver.py", line 27, in get_handler handler = super().get_handler(*args, **options) File "/usr/lib/python3.8/site-packages/django/core/management/commands/runserver.py", line 65, in get_handler return get_internal_wsgi_application() File "/usr/lib/python3.8/site-packages/django/core/servers/basehttp.py", line 47, in get_internal_wsgi_application raise ImproperlyConfigured( django.core.exceptions.ImproperlyConfigured: WSGI application 'wsgi.application' could not be loaded; Error importing module. Thanks in advance for any suggestions. -- Your life is like a penny. You're going to lose it. The question is: How do you spend it? John Covici wb2una covici(a)ccs.covici.com

5 years, 6 months

Re: add custom styles to postorius list creation menu

by Mark Sapiro

On 5/2/22 06:39, Michael Hazan wrote: > Hello, > > When creating a list via postorius, i can see 3 style appear (announce, discussion, private). Is it possible to either create a new style and add it to that list or modify one of those style ? See this thread https://lists.mailman3.org/archives/list/mailman-users@mailman3.org/thread/… > Also, coming from mailman2, you could directly set the members post moderation action when subscribing, now you can only do it via the user menu, is there a way to automate this in mm3 ? I don't understand what you mean here. In MM 2.1 a member had only one setting - moderated yes or no and if moderated there was a list setting for the moderation action. There was also a list setting for whether new members were moderated by default. How were you setting the new member's moderation when subscribing? You are correct that when subscribing a new member, the member gets the default action for members and different action has to be set in a separate operation. I don't think this is significantly different from MM 2.1. Also, can you describe what you mean by "automate this". -- Mark Sapiro <mark(a)msapiro.net> The highway is for gamblers, San Francisco Bay Area, California better use your sense - B. Dylan

4 years, 4 months

Re: Timeout error on anonymous subscribe

by Gerald Vogt

On 23.10.24 00:09, Mark Sapiro wrote: > How are you creating the template? If you are creating it via Postorius, Yes, via Postorius created using the url https://lists.example.org/mailman3/lists/community.lists.example.com/templa… > what is your setting for POSTORIUS_TEMPLATE_BASE_URL and what does the I did not set POSTORIUS_TEMPLATE_BASE_URL in settings.py. > entry in the template table in the database look like? in mailman.template: mailman=# select * from template where id = 6; 6|list:user:action:subscribe|community.lists.example.com|http://localhost:8… in mailmanweb.template: mailmanweb=# select * from postorius_emailtemplate where id = 6; 6|list:user:action:subscribe|test1234||2024-09-09 13:52:22.377792+02|2024-10-14 15:11:43.029873+02|list|community.lists.example.com > POSTORIUS_TEMPLATE_BASE_URL should be the same URL you use to access > Postorius up to but not including the `/postorius/` or `/mailman3/` > part. I.e, for this list whose info page is at https:// > lists.mailman3.org/mailman3/lists/mailman-users.mailman3.org/, the > setting is > ``` > POSTORIUS_TEMPLATE_BASE_URL = 'https://lists.mailman3.org' > ``` For testing I have set POSTORIUS_TEMPLATE_BASE_URL = 'https://lists.example.org' to the URL of our main domain, however, if I test an anonymous subscribe through the list info page I still get the timeout error ``` HTTPConnectionPool(host='localhost', port=8000): Read timed out. (read timeout=5) ``` Logs still show the same behaviour: the request for the template comes into the server but is finished and logged after 5 seconds: 127.0.0.1 - - [23/Oct/2024:05:51:38 +0000] "GET /mailman3/api/templates/list/community.lists.example.com/list:user:action:subscribe HTTP/1.1" 200 8 "-" "python-requests/2.32.3" The tcpdump of the tcp conection also looks the same: the response is pushed with the termination of the connection. I can access http://localhost:8000/mailman3/api/templates/list/community.lists.example.c… with curl and immediately get the response. So it still looks to me as if the response is stuck in the tcp buffers of the connection and not pushed immediately, but only once the requestor times out after 5 seconds and closes the connection. Thanks, Gerald

1 year, 11 months

Re: Default values for lists in Mailman 3

by Mark Sapiro

On 9/19/24 05:46, Markus Grandpré wrote: > Dear list, > > I would like to activate the invitation setting for all lists as > default. In Mailman 2.1 I have done this in the file > </etc/mailman/mm_cfg.py>: > > > DEFAULT_SUBSCRIBE_OR_INVITE = Yes > > > How can I do this in Mailman 3? There is a draft merge request at https://gitlab.com/mailman/postorius/-/merge_requests/930 which implements a framework for setting Postorius defaults and creates a setting to set the default for pre-verified on the mass subscription page. Once merged, this can easily be extended to provide a default for Invitation. In the mean time, you can only do this by patching src/postorius/forms/list_forms.py like ``` --- a/src/postorius/forms/list_forms.py +++ b/src/postorius/forms/list_forms.py @@ -1283,7 +1283,7 @@ class ListMassSubscription(forms.Form): invitation = forms.BooleanField( label=_('Invitation'), - initial=False, + initial=True, required=False, help_text=_( 'If checked, the other checkboxes are ignored and the users will ' ``` > Can I also transfer other default values > like: > > ... > DEFAULT_SERVER_LANGUAGE = 'en' > DEFAULT_SEND_REMINDERS = 1 > DEFAULT_SUBSCRIBE_OR_INVITE = Yes > DEFAULT_PRIVATE_ROSTER = 2 > DEFAULT_ARCHIVE = Off > DEFAULT_ARCHIVE_PRIVATE = 1 > ... > > from the very same configuration file to Mailman 3? Is there a > documentation of the default values for lists in Mailman 3? This is done by creating a list style with the desired defaults. See https://docs.mailman3.org/projects/mailman/en/latest/src/mailman/styles/doc… for documentation of styles and see https://gitlab.com/mailman/example-mailman-plugin for an example of creating a plugin in Mailman core to make a persistent style. There is no specific doc for the list settings. You need to look at https://gitlab.com/mailman/mailman/-/blob/master/src/mailman/styles/base.py for the various settings and https://gitlab.com/mailman/mailman/-/blob/master/src/mailman/styles/default… to see which default classes are applied for various styles. -- Mark Sapiro <mark(a)msapiro.net> The highway is for gamblers, San Francisco Bay Area, California better use your sense - B. Dylan

2 years

Mailman Core 3.3.1 release

by Abhilash Raj

Hey Everyone, I am pleased to announce Mailman Core 3.3.1 is now out. This release includes support for bounce processing, which had been lacking in Mailman 3 until now. So, after upgrading to this release, you will notice bounce related notifications from Mailman 3 being sent out to list owners if the list has bounce processing enabled (which, most list do by default). Postorius changes for new bounce processing options are coming out soon, I would like the current head to bake in a little longer since it went through bootstrap 4 upgrade recently. Expect it to be out in about a month. If your users would really care about bounce processing being enabled and not being able to tune threshold and notification parameters in the web interface, you might want to wait for Postorius's next release before upgrading. It also exposes all the remaining attributes of MailingList via REST API, so Postorius can expose them in the Web Interface. This should finally make all attributes of a MailingList manageable via Web Interface, without having to access command line interface. There has also been a whole lot of bug fixes. A full list of changes can be found at: https://mailman.readthedocs.io/en/latest/src/mailman/docs/NEWS.html#id1 The release is available via PyPI: https://pypi.org/project/mailman/3.3.1/ To install this release via pip, you can run: $ pip install --upgrade mailman -- thanks, Abhilash Raj (maxking)

6 years, 5 months

Mailman-users search results for query "Postorius"