Search results for "Postorius" - Mailman-users

Re: Mass unverified subscriptions end up as pending user confirmation instead.

by Mark Sapiro

On 2/25/20 2:34 PM, hansen(a)rc.org wrote: > After mass subscribing with these settings: > > Pre confirm: Yes, Pre approved: Yes, Pre Verified (sic): No > > the addresses appeared in the list's 'Pending user confirmation' list. They were pre-confirmed. > The addresses did not appear in the Django Admin's non-verified addresses list. They were not verified. It is actually pending verification, not confirmation. Postorius can't tell the difference. It only knows that it's waiting for some action either by a moderator (pending approval) or the user (pending confirmation or verification, but just called 'confirmation') This verification is for Mailman core to verify it's a valid address that the user wants to use with this mailman installation. Once this address is verified, it can be subscribed to other lists without further verification. This has nothing to do with Django verified addresses which are addresses associated with Django log-in that have been verified to Django. > Also why does Postorius lists just 'Pending Approval' and 'Pending Confirmation' but not 'Pending Verification'? As I said, it doesn't know the difference between 'Pending Confirmation' and 'Pending Verification'. You should note that the user you subscribed in this way received a 'verification' request like > Email Address Registration Confirmation > > Hello, this is the GNU Mailman server at example.com. > > We have received a registration request for the email address > > user(a)example.org > > Before you can start using GNU Mailman at this site, you must first confirm > that this is your email address. You can do this by replying to this message, > keeping the Subject header intact. > > If you do not wish to register this email address, simply disregard this > message. If you think you are being maliciously subscribed to the list, or > have any other questions, you may contact > > listname-owner(a)example.com and not a subscription confirmation request. Also, if any of the addresses had been already verified, they would have been subscribed immediately without confirmation or approval. -- Mark Sapiro <mark(a)msapiro.net> The highway is for gamblers, San Francisco Bay Area, California better use your sense - B. Dylan

5 years, 8 months

Re: remove non members from a list

by Guillermo Hernandez (Oldno7)

On 6/8/21 18:37, Mark Sapiro wrote: > On 8/6/21 9:18 AM, Guillermo Hernandez (Oldno7) via Mailman-users wrote: >> Hi all: >> >> I need to remove all non members from a list. I know I can do it via >> Postorius, but it has to be done one at a time. (you can delete ALL >> suscribers but not all non members...) >> >> Anyone has a python recipe to do this? > > $ /opt/mailman/mm/bin/mailman shell -l list.example.com > 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 list.example.com mailing list > >>> for nonmember in m.members.nonmembers: > ... nonmember.unsubscribe() > ... > >>> commit() > Thanks a lot for the promt response, Mark. It's not functioning. It says: "AttributeError: 'MemberRoster' object has no attribute 'nonmembers'" My system info is: Mailman Core Version GNU Mailman 3.3.3 (Tom Sawyer) Mailman Core API Version 3.1 Mailman Core Python Version 3.7.9 (default, Nov 6 2020, 21:14:59) [Clang 8.0.1 (tags/RELEASE_801/final 366581)] Postorius 1.3.4

4 years, 3 months

Re: List enumeration problem

by Darren Smith

Simon, The thing is that there doesn't appear to be any corresponding entries in the front end logs. There isn't anyone hitting postorius for the lists that are being enumerated. About the three items you mentione: 1) I hope that this can be fixed soon! There are several pages on our mailman instance that we had to write a separate back-end API to query the data, because a single user hitting a single page in postorius was causing a denial of service. 2) What sort of stuff is synced between the front and backends? Any chance you can point me to somewhere in the code where this is happening? We may need to rewrite something to streamline this as well, but it would be nice to know where we need to go poking around. 3) We have some hyperkitty cron jobs set up, but at the moment they have been scaled back somewhat. I do know that when this enumeration is going on our hyperkitty jobs aren't being run. We (I work with Kaleb) are one of those very large Mailman instances you mention, so yep, we're seeing what you're talking about! I think in our case the most likely root cause is your #2 above, so any guidance you can shoot in our direction would be much appreciated. Thanks! -Darren On Fri, May 11, 2018 at 3:53 AM, Simon Hanna <simon.h4nn4(a)gmail.com> wrote: > This appears to be logs from the backend. Do you have corresponding > entries from the frontend? > > I have a couple of explanations for this: > 1. Normal operation: > Most rest calls don't support batch processing, so the frontend needs to > issue multiple calls. > > 2. Synchronization between frontend and backend. > Some stuff is synced between the two, it might be that... > > 3. Hyperkitty cron jobs > Hyperkitty has a couple of cronjobs to do maintenance on the database and > such. > > If you have logs from the frontend, we can know for sure what's causing > this. > 1 is a known issue and is going to get fixed eventually... > (especially since very large Mailman instances are popping up...) > _______________________________________________ > Mailman-users mailing list > mailman-users(a)mailman3.org > https://lists.mailman3.org/mailman3/lists/mailman-users.mailman3.org/ >

7 years, 6 months

Re: mailman3 postorius cannot retrieve template

by Stephen J. Turnbull

Andreas Barth writes: > Distribution packages have their own up- and downsides. I'm far from absolutist about distro packaging of Mailman, but historically, the downsides have very much outweighed the upsides for most users who come to us on these lists, unfortunately. It took many iterations of Mailman 2 at Debian to get to the point where I was willing to use the Debian packages at all, and for Mailman 3 I've never used them. Even Brian Carpenter's Install Guide avoids Debian's Mailman packages. > Of course, how they are done is to be discussed with the > distribution, so: if something is wrong with a debian package, > please follow the instructions on bugs.debian.org on reporting > bugs. This certainly is the definition of good citizenship. I hope all distribution users will file packaging bugs with their distros, and take it in good humor when we tell them, "works for me, so you should ask <distro> about it." > They have the disadvantage that they're stable for some time If people have been using Mailman 2, they have had a rather better experience for the last few years, though. Since we only fix security issues in Mailman 2, Mailman itself is stable, and to the extent that I pay attention, I think Debian at least has been prompt about tracking Mailman 2 releases. Not so for Mailman 3, though. > If they have all the features someone wants, But this is precisely the problem for Mailman 3. Mailman 3 is not feature-complete compared to Mailman 2, and even two years ago it wasn't close. (Sorry!) Yes, if all you want is a vanilla mail exploder, maybe with a footer added, Mailman 3 is great. But then there's no need to upgrade to Mailman 3 from Mailman 2, and if you're happy being distro-bound, you'll have a better experience with Mailman 2. I'm sure there are quite a few Mailman 3 admins happy with their distro releases from 2 years or 6 months ago. But to someone who comes to us asking for advice, I am definitely going to recommend the Docker containers or a venv or /usr/local installation, because I expect that kind of user to be back for more advice in the future. Steve

4 years

Re: signup / registration error - permissions and cert chains

by Mark Sapiro

On 12/31/21 5:37 PM, David Newman wrote: > > After stripping this down to the defaults: > > EMAIL_BACKEND = 'django.core.mail.backends.smtp.EmailBackend' > EMAIL_HOST = 'localhost' > EMAIL_PORT = 25 > > and restarting mailman3 (necessary?) No > and mailmanweb, the system emails > me (as alias for root) an error like the one pasted below after I try > creating a new user account. > > After changing EMAIL_HOST to the system's canonical FQDN and again > restarting mailman3 and mailmanweb, the error is the same, and still > from postorius@localhost. localhost is better. If you set it to the system's canonical FQDN you need to ensure that that name or IP is in Postfix mynetworks. ... > Internal Server Error: /accounts/signup/ > > SMTPRecipientsRefused at /accounts/signup/ > {'newuser(a)dom1.tld': (504, b'5.5.2 <postorius@localhost>: Sender address > rejected: need fully-qualified address')} ... > Settings: > Using settings module settings ... > DEFAULT_FROM_EMAIL = 'postorius@localhost' Try setting this to a fully qualified address, e.g., something(a)networktest.com, not @localhost. More info at https://docs.mailman3.org/en/latest/config-web.html#setting-up-email -- Mark Sapiro <mark(a)msapiro.net> The highway is for gamblers, San Francisco Bay Area, California better use your sense - B. Dylan

3 years, 10 months

Re: Message-Footer after migrating to Mailman3

by christopher.claus＠tgcamberg1848.de

Hi Abhilash, excuse my delay, i was out-of-order in the last weeks. > You want the URL at which Postorius (postorius) is available from Core (mailman-core container). The default for that in the container images is set to http://mailman-web:8000. Does that not work for you? I changed the container-names (but not the hostnames) an probably i set the POSTORIUS_TEMPLATE_BASE_URL to the container-name and not to the hostname. > If you want to verify, you want to exec into the Core’s container (docker exec -it mailman-core bash) and see if you can curl the URL from inside there. If you are using the default docker-compose-postorius.yaml then there is a /etc/hosts entry created by docker for the mailman-web container, hence http://mailman-web:8000 works there (but it won’t work on the host, since docker doesn’t modify the host’s /etc/hosts). I modified the compose-file since i have a separate container for a database and i use a seperate network for all my other container. The consequence was, that i do not have a fix subnet. I tried to change all occurences of ip-adresses to hostnames. Therefore i stripped these parts in the compose-file. Currently, there is not entry for mailman-web in the hosts file of mailman-core. I did not find any place in your config and scripts, were this file is written. At which place, this should be done? An interesting point: mailman_core has an entry to itself (with own ip) in /etc/hosts and mailman_web also. I think, this is not correct, isnt it? But nevertheless a curl of the URL from core to web works without error message. > There might also be a bug in play here which would cause such connection refused errors when subscribing/unsubscribing when there was a template configured for the list. Is that the case for you or are you seeing always when trying to send the email (which would imply that the Web container simply isn’t reachable from Core). I thought about the situation, that all my lists where migrated from mailman 2. Many of the have footer- and header-messages, automatic replies which are not shown in the template section of the list. Is a recreation in mailman3 a good option in this situation? Best regards, chrclaus

4 years, 1 month

Re: very few moderation capabilities for moderators

by Mark Sapiro

On 9/16/21 2:39 AM, Guillermo Hernandez (Oldno7) via Mailman-users wrote: > Hi all: > > I need to provide the list moderators a way to change the moderation > flag for users from whichever it is (normally "list default processing") > to "hold for moderation" and viceversa (to "list default" or to "accept") > > I understand that it could be done via console script (That's the way I > did on mailman2: I made two commands using "withlist", one to hold, > moderar.py, and other one to accept, desmoderar.py. I show you below) Are you asking what the equivalent MM 3 scripts would be? > But I think I'm not the only one that could use as an improvement a way > to do this on postorius/web. Postorius allows a list owner or site admin to set Moderation for list members and non members at e.g. https://www.example.com/mailman3/lists/list.example.com/members/(non)member/. Currently, a list moderator who is not an owner cannot do this, but a moderator can set Moderation for the sender of a held post when handling the post. -- Mark Sapiro <mark(a)msapiro.net> The highway is for gamblers, San Francisco Bay Area, California better use your sense - B. Dylan

4 years, 2 months

Re: including a template failed

by Mark Sapiro

On 9/19/20 2:47 PM, Wolfgang Bock via Mailman-users wrote: > Hi, > > I created a new mailinglist and got during the test-process the following > errormessage in my mailman.log after: > ... > Sep 19 22:55:08 2020 (1433) ACCEPT: > <000001d68ec7$2553e6e0$6ffbb4a0$(a)domain-01.de> > > Errors: > > Sep 19 22:55:09 2020 (1436) Cannot connect to SMTP server localhost on port > 25 > HTTPSConnectionPool(host='webmail.domain-02.de', port=443): Max retries > exceeded with url: > /mailman3/postorius/api/templates/list/mylist.lists.domain-03.de/list:member > :regular:footer (Caused by NewConnectionError('<urllib3.connec > tion.VerifiedHTTPSConnection object at 0x7fc8380f1748>: Failed to establish > a new connection: [Errno -2] Name or service not known')) > ... This is wierd. It looks like we are trying to establish a connection to host='webmail.domain-02.de', port=443 in order to GET /mailman3/postorius/api/templates/list/mylist.lists.domain-03.de/list:member:regular:footer, but the error says "Cannot connect to SMTP server localhost on port 25". I have no idea how port 25 is coming into it. Can you get https://webmail.domain-02.de/mailman3/postorius/api/templates/list/mylist.l… on the Mailman machine? What is your setting for POSTORIUS_TEMPLATE_BASE_URL? -- 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

Re: Can't subscribe on new site/domain

by Flo

On 10/10/25 04:13, Mark Sapiro wrote: > >> 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. > The url of the Django view is lists.example.com/mailman3/admin. The 'VIEW SITE' is in the header on the right side. It's a link to lists.example.com/mailman3 which apparently gets redirected to lists.example.com/mailman3/postorius/lists. The difference I am talking about is that lists.example1.com/postorius/lists shows only its mailing lists while lists.example2.com/postorius/lists shows all mailing lists on the server (ie. also mailing lists of example1.com) Flo

1 month, 1 week

500 Internal Server Error on specific list pages

by Johnny Cison

I have a new Mailman 3 server set up and am having a strange issue with just one particular list. Accessing the list's Info page URL or it's Archiving Settings page URL returns a 500 Internal Server Error, but its other pages work correctly. Also, the Info and Archiving pages on the other lists are working correctly. When I access the info page for the problem list, I get these errors in the log: Traceback (most recent call last): File "/usr/lib/python2.7/dist-packages/django/core/handlers/exception.py", line 41, in inner response = get_response(request) File "/usr/lib/python2.7/dist-packages/django/core/handlers/base.py", line 249, in _legacy_get_response response = self._get_response(request) File "/usr/lib/python2.7/dist-packages/django/core/handlers/base.py", line 187, in _get_response response = self.process_exception_by_middleware(e, request) File "/usr/lib/python2.7/dist-packages/django/core/handlers/base.py", line 185, in _get_response response = wrapped_callback(request, *callback_args, **callback_kwargs) File "/usr/lib/python2.7/dist-packages/django/views/generic/base.py", line 68, in view return self.dispatch(request, *args, **kwargs) File "/usr/lib/python2.7/dist-packages/postorius/views/generic.py", line 59, in dispatch return super(MailingListView, self).dispatch(request, *args, **kwargs) File "/usr/lib/python2.7/dist-packages/django/views/generic/base.py", line 88, in dispatch return handler(request, *args, **kwargs) File "/usr/lib/python2.7/dist-packages/postorius/views/list.py", line 216, in get 'hyperkitty' in self.mailing_list.archivers and File "/usr/lib/python2.7/_abcoll.py", line 388, in __contains__ self[key] File "/usr/lib/python2.7/dist-packages/mailmanclient/restbase/base.py", line 151, in __getitem__ return self._get(key) File "/usr/lib/python2.7/dist-packages/mailmanclient/restbase/base.py", line 90, in _get return self.rest_data[key] File "/usr/lib/python2.7/dist-packages/mailmanclient/restbase/base.py", line 76, in rest_data response, content = self._connection.call(self._url) File "/usr/lib/python2.7/dist-packages/mailmanclient/restbase/connection.py", line 103, in call raise HTTPError(url, response.status, content, response, None) HTTPError: HTTP Error 500: A server error occurred. Please contact the administrator. When I access the Archiving page in Settings, I get these: Traceback (most recent call last): File "/usr/lib/python2.7/dist-packages/django/core/handlers/exception.py", line 41, in inner response = get_response(request) File "/usr/lib/python2.7/dist-packages/django/core/handlers/base.py", line 249, in _legacy_get_response response = self._get_response(request) File "/usr/lib/python2.7/dist-packages/django/core/handlers/base.py", line 187, in _get_response response = self.process_exception_by_middleware(e, request) File "/usr/lib/python2.7/dist-packages/django/core/handlers/base.py", line 185, in _get_response response = wrapped_callback(request, *callback_args, **callback_kwargs) File "/usr/lib/python2.7/dist-packages/django/contrib/auth/decorators.py", line 23, in _wrapped_view return view_func(request, *args, **kwargs) File "/usr/lib/python2.7/dist-packages/postorius/auth/decorators.py", line 39, in wrapper return fn(*args, **kwargs) File "/usr/lib/python2.7/dist-packages/postorius/views/list.py", line 719, in list_settings form = form_class(initial=initial_data, mlist=m_list) File "/usr/lib/python2.7/dist-packages/postorius/forms.py", line 303, in __init__ [(key, key) for key in sorted(self._mlist.archivers.keys())]) File "/usr/lib/python2.7/dist-packages/mailmanclient/restbase/base.py", line 172, in keys return list(self) File "/usr/lib/python2.7/dist-packages/mailmanclient/restbase/base.py", line 166, in __len__ return len(self.rest_data) File "/usr/lib/python2.7/dist-packages/mailmanclient/restbase/base.py", line 76, in rest_data response, content = self._connection.call(self._url) File "/usr/lib/python2.7/dist-packages/mailmanclient/restbase/connection.py", line 103, in call raise HTTPError(url, response.status, content, response, None) HTTPError: HTTP Error 500: A server error occurred. Please contact the administrator. Not a python developer, which makes debugging based on the above more difficult. I've seen some other errors posted to this list that highlight specific setting or config issues, but I'm not seeing that in these. Any ideas?

5 years, 3 months

Mailman-users search results for query "Postorius"