Search results for "Postorius" - Mailman-users

mailman import21 passwords

by Sam Darwin

Hi, On https://docs.mailman3.org/en/latest/faq-migration.html it says "Mailman 3 has a completely new account management system, none of the passwords from Mailman 2 will work with Mailman 3. Each user needs to sign up in Postorius for a new account to manage their memberships on all lists on a single instance." "Each user needs to sign up in Postorius for a new account" I am (personally) satisfied with this answer. However others at the company are asking for a detailed explanation. Consider that - - Mailman2 has access to password information. - Import scripts such as "import21" are able to import list information. - It seems that scripts such as "import21" could also generate new user accounts and passwords based on the previous ones. Why can't passwords be imported from mailman2 to mailman3? How difficult would it be to do? (is there a link to where this is already explained? ) Thanks

1 year, 9 months

Re: Hiding the "subscribe without creating an account"

by Matthew Blissett

On 13/07/2024 07:17, Mark Sapiro wrote: > On 7/10/24 7:36 PM, Ben Sturmfels via Mailman-users wrote: >> >> Is there a configuration option that does this, or was it a custom >> change made in >> the templates? Was the change made to reduce fake registrations? Did >> it work? > > > It was added in Postorius 1.3.9. See the UI section at > https://docs.mailman3.org/projects/postorius/en/latest/news.html#news-1-3-9 > > Yes, the change was made in an attempt to reduce fake registrations. > > We haven't really studied it's effectiveness. It seems to help > somewhat, but it also seems that bots may already have a template to > POST so removing it from the UI is not a complete solution. They would be missing the CSRF token (a hidden field on the anonymous signup form) so this ought to fail. > There is also a lot of email to innocent third parties and > non-existent addresses from attempts to register them for an account. There are patches to integrate a Captcha system here: https://gitlab.com/mailman/django-mailman3/-/issues/33 I think it's needed, as less than 24 hours after migrating to Mailman 3 I already see bots retrieving the signup form to get the CSRF token (GET /accounts/signup/?next=/postorius/lists/) then POSTing the request for a new user account (POST /accounts/signup/). There's also the setting ACCOUNT_EMAIL_UNKNOWN_ACCOUNTS = False, which prevents spam from the "forgot password" address, see https://gitlab.com/mailman/postorius/-/issues/591 -- Matt

1 year, 11 months

Re: Timeout in Postorius when trying to approve or reject moderated messages

by Mark Sapiro

On 8/27/20 8:07 AM, Sebastian Hagedorn wrote: > > Right now everything is running as root (except for Apache). I realized > too late that I should've used a mailman user. Could that be the reason > for the issue? Since you have determined it was a browser issue, that probably isn't the reason, but running Mailman as root is a bad idea in general for security reasons. I don't know if it's relevant or not, but I have just recently had issues with Firefox not working properly on two different (not mailman) web sites, and these issues were fixed by clearing cookies and cached data from the affected sites and restarting Firefox. -- 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

Re: Struggle on upgrading mailman3-web to new version - Not Found: /mailman//

by Stefan Bauer

To comment my own text, as my typo let it look rude. I meant: I solved it by myself, just by thinking about it for a while again. Stefan Am Mo., 25. Okt. 2021 um 18:06 Uhr schrieb Stefan Bauer <cubewerk(a)gmail.com >: > So i fixed it by myself, just think about it again. > ProxyPass /mailman3 unix:/run/mailman3-web/uwsgi.sock|uwsgi://localhost/ > > Note the trailing slash at the end. > After removing it, the webinterface is up again. > But i have no idea, why this is NOW a problem and was not in the past. > Maybe something has changed in the way, apache is handling this now. > > Anyway, problem solved for me. > > Am Mo., 25. Okt. 2021 um 10:45 Uhr schrieb Stefan Bauer < > cubewerk(a)gmail.com>: > >> Dear Users, >> >> I recently upraded mailman3 from Ubuntu 18 to 20. After accessing the >> web-interface via >> >> https://my.mailinglistserver.local/mailman3/postorius/lists/ >> >> I receive >> >> Not Found: /mailman//postorius/lists/ >> [pid: 1346851|app: 0|req: 4/4] 10.254.253.12 () {70 vars in 1369 bytes} >> [Mon Oct 25 10:39:59 2021] GET /mailman3/postorius/lists/ => generated 2821 >> bytes in 12 msecs (HTTP/1.1 404) 5 headers in 155 bytes (1 switches on core >> 1) >> >> Where does the wrong path come from (mailman vs. mailman3) >> >> After enabling Debug, i see in the browser the following: >> >> >> Page not found (404) >> Request Method: GET >> Request URL: https://my.mailinglistserver.local/mailman//postorius/lists/ >> >> Using the URLconf defined in urls, Django tried these URL patterns, in >> this order: >> >> ^$ >> ^postorius/ >> ^hyperkitty/ >> ^user-profile/delete$ [name='mm_user_account_delete'] >> ^user-profile/$ [name='mm_user_profile'] >> ^accounts/ >> ^admin/ >> >> The current path, /postorius/lists/, didn't match any of these. >> >> You're seeing this error because you have DEBUG = True in your Django >> settings file. Change that to False, and Django will display a standard 404 >> page. >> >> My apache configuration is very simply: >> >> # more /etc/apache2/conf-enabled/mailman3.conf >> Alias /mailman3/favicon.ico >> /var/lib/mailman3/web/static/postorius/img/favicon.ico >> Alias /mailman3/static /var/lib/mailman3/web/static >> >> <Directory "/var/lib/mailman3/web/static"> >> Require all granted >> </Directory> >> >> <IfModule mod_proxy_uwsgi.c> >> ProxyPass /mailman3/favicon.ico ! >> ProxyPass /mailman3/static ! >> ProxyPass /mailman3 unix:/run/mailman3-web/uwsgi.sock|uwsgi://localhost/ >> </IfModule> >> >> I dont see where the path gets traversed in the wrong way. Any help is >> greatly appreciated. >> >> thank you. >> >> Stefan >> >

4 years, 7 months

Re: Error when click on mailing list: An error occurred while processing your request.

by Mark Sapiro

On 7/9/24 6:11 PM, adam.heathcote(a)utas.edu.au wrote: > > mailman members -R owner your_list(a)your.domain > > Shows myself as an owner as well as the imported owners from the previous list. You originally wrote: "but now when clicking on the list, Postorius shows: An error occurred while processing your request." I'm guessing you are clicking the list in the Postorius `Mailing Lists` view, i.e. something like https://example.com/mailman3/ or https://example.com/mailman3/lists, and you are logged in, and the link is to https://example.com/mailman3/lists/listname.example.com. What if you go to that page without being logged in, or logged in as a different user? -- Mark Sapiro <mark(a)msapiro.net> The highway is for gamblers, San Francisco Bay Area, California better use your sense - B. Dylan

1 year, 11 months

Re: Upgrading other python packages than the mailman ones in a venv results in dependency conflicts

by Andreas Vetter

On Montag, 16. Dezember 2024 11:52:25 CET Odhiambo Washington via Mailman- users wrote: > On Mon, Dec 16, 2024 at 1:39 PM Ulf R. <ulf.rapphahn(a)offis.de> wrote: > > > > Hello, > > I know this should be the way to upgrade: > > https://docs.mailman3.org/en/latest/upgrade-guide.html > > I have 3.3.10 installed. > > I saw that some python packages are outdated an tried this which install > > all outdated packages in a row: > > pip list --outdated --format=json | jq '.[].name' | xargs -n1 pip install > > -U > > One outdated package was django and this part happened: > > ------------------------------- > > vDownloading Django-5.1.4-py3-none-any.whl (8.3 MB) > > Installing collected packages: Django > > > > Attempting uninstall: Django > > > > Found existing installation: Django 4.2.16 > > Uninstalling Django-4.2.16: > > > > Successfully uninstalled Django-4.2.16 > > > > ERROR: pip's dependency resolver does not currently take into account all > > the packages that are installed. This behaviour is the source of the > > following dependency conflicts. > > hyperkitty 1.3.12 requires django<5.1,>=4.2, but you have django 5.1.4 > > which is incompatible. > > mailman-web 0.0.9 requires django<4.3,>=4.0, but you have django 5.1.4 > > which is incompatible. > > postorius 1.3.13 requires django<5.1,>=4.2, but you have django 5.1.4 > > which is incompatible. > > django-mailman3 1.3.15 requires django<5.1,>=4.2, but you have django > > 5.1.4 which is incompatible. > > Successfully installed Django-5.1.4 > > ------------------------------- > > > > So I made a roll back. > > > > Is this really the only secure way to update the venv?: > > pip install -U mailman postorius django-mailman3 hyperkitty mailman-web > > Correct! > > > May be yes and I have to ignore the rest? ;-) > > Yes. Let them pull their own versions of dependencies. OK. So what about --upgrade-strategy eager: pip install -U --upgrade-strategy eager mailman postorius django-mailman3 hyperkitty mailman-web Is that allowed/supported? > -- > Best regards, > Odhiambo WASHINGTON, -- Mit freundlichen Gruessen, Andreas Vetter

1 year, 6 months

Re: More Mailman releases!

by Mark Sapiro

On 10/24/23 6:12 AM, Wikinaut wrote: > After installing the last program to be updated (mailman-web), the archives become unavailable due to (again) some glitches with the urls. > I did not(!) change the /etc/mailman3/ configuration files. > > before upgrade, example.com/mailman3/lists/mylist.mydomain (=> worked) > after upgrade, example.com/postorius/lists/mylist.mydomain failed Did example.com/postorius/lists/mylist.mydomain work before the upgrade? Does example.com/mailman3/lists/mylist.mydomain work after upgrade? > Why and who changed my settings? The latest mailman-web upgrade added entries to urls.py. mailman-web<0.0.8 would recognize only the /mailman3/ and /archives/ urls. mailman-web=0.0.8 still recognizes those and now also recognizes /postorius/ and /hyperkitty/ urls. If /postorius/ and /hyperkitty/ urls are not working for you now, the issue is probably in your web server configuration. -- Mark Sapiro <mark(a)msapiro.net> The highway is for gamblers, San Francisco Bay Area, California better use your sense - B. Dylan

2 years, 7 months

Postorius Suggestion: Give owner a view of all users of all owned lists

by Stephen J. Turnbull

Andreas Vetter writes: > A list of all addresses subscribed to all lists owned by the logged > in person. This is starting to take a better form. It's still very specialized, so I'm starting to wonder if trying to add it to Postorius is a great idea. Of course if people are coming in over the network, you don't want to reproduce all the authentication and authorization logic implemented in Django and Postorius. That may as well be done in Django, and if you're doing Django it may as well be Postorius too. But if you're in a single sign-on environment so presence in the network implies strong authentication, you will get more flexibility from local scripts using mailmanclient, or if you're confident in security access to the REST API directly. Just putting that out for your consideration, since implementing what is taking shape here would take quite some time as the folks skilled with Postorius are not so active these days. > Owner is the primary target group for that. But since it should be > a tool for managing subscriptions in a simple way, it might also be > of interest for superusers. For me as a superuser it would make > life easier. [...] > Ah, I see the problem and agree: So, the presentation should have a > sorted and searchable list of addresses and a Button next to each > address, maybe labeled "Subscriptions". Looking at your description above, for superusers that is basically the Users tab, though. Users are identified by primary address, and you'd not see alternate addresses in the list. But presumably your internal users use their @your.org addresses as primary. Can you make clear what could be more streamlined for your use cases as superuser? I give one example below, maybe that's what you're mostly interested in. The caveats about access to User objects still apply for owners, so even if they look the same (which is a good UX idea if owner functionality is a subset of superuser functionality, also they might even be able to share the basic page templates), the implementation is going to be rather different. I suspect you superusers would be quite frustrated if using the "subscribe all these lists" functionality meant you couldn't get at the User object without going to a different page. I do see one weird thing: you can't manipulate subscription itself from the User page as seen by the superuser from that list, only toggle moderation and delivery mode. I guess that's reasonable for a lot of use cases, though. I've never wanted to do a subscribe or unsubscribe from there. I always have a long list of users to subscribe to specific lists, never a list of lists a specific user should belong to, > The presentation given when above "Subscriptions" Button is clicked > should contain the address as kind of Headline. Then a table of > all lists of the logged in owner and next to each mailing list an > indication, if the address is subscribed or not and a Button to > toggle subscription/unsubscription. May be a single Toggle Button > or (maybe better) two buttons, a suscribe and a unsubscribe button, > where one is greyed out. This would not work with the current User page as presented to a superuser, that's true. The current presentation is quite suited to its purpose, with sections for Addresses, Subscriptions, Ownership, and Delete User in that order. But especially for superusers, there are plenty of sites with thousands, even tens of thousands of lists, and even a paged or scrollable presentation would be awful UI, and the potential for a disastrous mistake using "do all" is high. > In addition my owners would like to have a "unsubscribe from all my > lists" button. And a "subscribe to all my lists" button. This might > be visually nicer, when having the two-button approach above. I wonder if your owners really want "subscribe all". "Unsubscribe all" does make sense for separations, of course, and they wouldn't necessarily be terminations. It would be useful in an internal transfer where "delete user" is not a solution. But in my experience specialized channels tend to proliferate but the same people are likely to be running them as run the department-wide lisst. > In our case we would want to (un-)subscribe the address in a "do > it, don't ask anyone" fashion, but maybe this is not a good idea in > general. What do you think? I think we would implement it similarly to the mass subscribe for multiple addresses case, where the list owner can decide how much bureaucracy to require of the subscriber. You'd want to be careful to make sure address verification is done at most once (for your use case, probably not at all). And there would be some things that could be done to arrange that most lists would have sensible defaults. > Yes, I agree, but policy here is to get rid of subdomains, and that > falls on our feet now. Well, once we figure out how to implement domain ownership, it wouldn't be hard to adapt that technology to "departments" that are administratively distinct but share mail and/or web domains. The main problem would be deciding whether and how to nest them. Superuser > domain owner > list owner > moderator is pretty obvious, but how "department owner" would fit in is less so.

1 year, 3 months

Re: User settings triggers error

by Mark Sapiro

On 6/16/20 10:34 AM, Mark Dadgar wrote: > If one of my users (including admin) goes to their user drop-down in the upper-right of Postorius and clicks Mailman Settings, it triggers an error: > > > > Here’s the error log: > > Internal Server Error: /mailman3/postorius/accounts/subscriptions/ > > KeyError at /postorius/accounts/subscriptions/ > 'file' The KeyError is bogus. It is an error that occurs in Django's logging when trying to log the real error. > Request Method: GET > Request URL: https://mail.pdc-racing.net/mailman3/postorius/accounts/subscriptions/ ... > Traceback: > > File "/usr/lib/python3/dist-packages/django/core/handlers/exception.py" in inner > 34. response = get_response(request) > > File "/usr/lib/python3/dist-packages/django/core/handlers/base.py" in _get_response > 115. response = self.process_exception_by_middleware(e, request) > > File "/usr/lib/python3/dist-packages/django/core/handlers/base.py" in _get_response > 113. response = wrapped_callback(request, *callback_args, **callback_kwargs) > > File "/usr/lib/python3/dist-packages/django/contrib/auth/decorators.py" in _wrapped_view > 21. return view_func(request, *args, **kwargs) > > File "/usr/lib/python3/dist-packages/postorius/views/user.py" in user_subscriptions > 307. memberships = [m for m in mm_user.subscriptions] Here we're trying to grt all the user's subscriptions. Se we call mailmanclient for that. > File "/usr/lib/python3/dist-packages/mailmanclient/restobjects/user.py" in subscriptions > 62. for address in self.addresses: client is getting all the user's addresses > File "/usr/lib/python3/dist-packages/mailmanclient/restbase/base.py" in __iter__ > 221. for entry in self.rest_data: It got the addresses and is now iterating over them. > File "/usr/lib/python3/dist-packages/mailmanclient/restbase/base.py" in rest_data > 197. response, content = self._connection.call(self._url) Which calls the REST API > File "/usr/lib/python3/dist-packages/mailmanclient/restbase/connection.py" in call > 99. raise HTTPError(url, response.status, content, response, None) And gets a 500 from core. > During handling of the above exception (HTTP Error 500: b'A server error occurred. Please contact the administrator.'), another exception occurred: Which we aren't interested in. The next step is to look in core's mailman.log to see what the rest call was and the exception and hopefully traceback the caused the 500 response. -- Mark Sapiro <mark(a)msapiro.net> The highway is for gamblers, San Francisco Bay Area, California better use your sense - B. Dylan

6 years

Re: broken route to accounts

by Thomas Krichel

Stephen J. Turnbull writes > (Note: I usually copy that file to /etc/mailman3/urls.py in case I > make changes. In particular I usually comment out the ^postorius and > ^hyperkitty routes.) But in your case, I don't know what's in > > > | Using the URLconf defined in <code>mailman_web.urls</code>, > > You have to tell us what's in that file. I only now understand that this file is in fact root@darni:/usr/local/mailman/venv/lib/python3.13/site-packages/mailman_web/urls.py root@darni ~ # ls -l /usr/local/mailman/venv/lib/python3.13/site-packages/mailman_web/urls.py -rw-rw-r-- 1 mailman mailman 1559 Mar 18 08:25 /usr/local/mailman/venv/lib/python3.13/site-packages/mailman_web/urls.py root@darni ~ # md5sum /usr/local/mailman/venv/lib/python3.13/site-packages/mailman_web/urls.py f382f0bc9cea1277c70226b45cf86def /usr/local/mailman/venv/lib/python3.13/site-packages/mailman_web/urls.py I strongly suspect the file is the original file I got from pipping the package. root@darni ~ # cat /usr/local/mailman/venv/lib/python3.13/site-packages/mailman_web/urls.py | grep -v ^# from django.conf.urls import include from django.contrib import admin from django.urls import path, reverse_lazy from django.views.generic import RedirectView urlpatterns = [ path( '', RedirectView.as_view(url=reverse_lazy('list_index'), permanent=True), ), # Include alternate Postorius and HyperKitty URLs. path('postorius/', include('postorius.urls')), path('hyperkitty/', include('hyperkitty.urls')), # Order counts for various links. Put the above first and the following # after so the suggested Apache config still works. path('mailman3/', include('postorius.urls')), path('archives/', include('hyperkitty.urls')), path('', include('django_mailman3.urls')), path('accounts/', include('allauth.urls')), path('admin/', admin.site.urls), ] ok, I tested your approach, even though I don't know what the ... I am doing, Copying not mailman@darni:~/venv/lib/python3.13/site-packages/postorius/urls.py but mailman@darni:~/venv/lib/python3.13/site-packages/mailman_web/urls.py following guidance of Mark gleaned from https://lists.mailman3.org/archives/list/mailman-users@mailman3.org/thread/… and added ROOT_URLCONF='urls' to /etc/mailman3/settings.py I can test. The obvious way is to add a route for acocunts. This can be done as an additional line path('accounts', include('allauth.urls')), There are two cases. If I place that line *after* the line path('accounts/', include('allauth.urls')), then on clicking the sign-in button, I get a redirect to https://lists.repec.info/accountslogin/?next=/mailman3/lists/ which 404s. This may give the experts an addition hint where the problem is coming from. Placing path('accounts', include('allauth.urls')), *before* path('accounts/', include('allauth.urls')), seems to finally work, I can login! On the command line mailman@darni:~$ GET http://localhost:4386/accounts/ works and mailman@darni:~$ GET http://localhost:4386/accounts fails. My problem seems to be that I have to customize the installation, even though I have tried as much as I can not to, because the files as pipped seem not to work for me, for reason none of us seems to understand. Cheers to all! -- Written by Thomas Krichel http://openlib.org/home/krichel on his 22210th day.

2 months, 4 weeks

Mailman-users search results for query "Postorius"