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

6 years, 8 months

New Mailman Releases

by Abhilash Raj

Hi, I am pleased to announce several new releases for GNU Mailman project. 1. Mailman Core 3.3.6 [1] 2. Postorius 1.3.7 [2] 3. Hyperkitty 1.3.6 [3] 4. Mailmanclient 3.3.4 [4] 5. Django-mailman3 1.3.8 [5] All the releases are published to PyPI and you can find links to all the PyPI projects: https://docs.mailman3.org/en/latest/ A full list of changelogs are available below: [1]: https://docs.mailman3.org/projects/mailman/en/latest/src/mailman/docs/NEWS.… [2]: https://docs.mailman3.org/projects/postorius/en/latest/news.html#section-2 -- Something weird is going on with the page missing the bullets. [3]: https://docs.mailman3.org/projects/hyperkitty/en/latest/news.html#news-1-3-6 [4]: https://docs.mailman3.org/projects/mailmanclient/en/latest/src/mailmanclien… [5]: https://gitlab.com/mailman/django-mailman3/-/blob/master/README.rst Finally, the minimum Python version required is 3.7 although, 3.9 is recommended if you are doing a new install for longest support. 3.10 is supported for Django apps, but Mailman Core is missing that due to one of the core dependencies not support 3.10 yet (aiosmtpd). Thanks to all the contributors for making this release possible and apologies on my end for delayed releases. If you find any issues, you can report them at the respective bug tracker for the projects. The links to issue trackers are available here: https://docs.mailman3.org/en/latest/ -- thanks, Abhilash Raj (maxking)

4 years

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

by Claus-Justus Heine

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, 2 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/ >

8 years, 5 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

5 years

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

5 years, 1 month

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

5 years, 3 months

Re: Can disabled users enable themself?

by Flo

On 7/1/26 9:16 PM, Mark Sapiro wrote: > On July 1, 2026 11:20:02 AM PDT, Flo via Mailman-users <mailman-users(a)mailman3.org> wrote: >> Hi, >> >> users can get disabled if there are too many bounces. >> >> Is there an easy possibility for the disabled users to enable themself on their own? I checked the email they get, however, there is no link. Only the owner's email address. > Yes, that's true, however, an account needs to be set up. I see this as unrealistic for a regular user of the list I am thinking of. I was hoping for a links where I can choose immediately after clicking if I want to be enabled or stay disabled. I see an email to the owner as only realistic possibility. Or is there mail command for getting enabled? I can't find any, either ... > > Assuming you have Postorius or another web list management UI, the user can go to the web UI and set their list delivery enabled. > I have Postorius. > You can create a custom list.user.notice.warning template to include instructions in the email. > > That's a good idea, whatever the solution is. Thank you for your help. Flo

4 months

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

4 years, 10 months

Re: Confirmation emails aren't sent to users.

by Ibiam Chihurumnaya

Stephen J. Turnbull wrote: > Ibiam Chihurumnaya via Mailman-users writes: > > Confirmation emails aren't being sent to users and there's nothing > > in the logs that make it obvious what's happening. > > As I explained earlier, this backtrace > > 233830 File "/opt/mailman/venv/lib/python3.10/site-packages/hyperkitty/lib/view_helpers.py", line 137, in inner > > [...] > > 233908 File "/opt/mailman/venv/lib/python3.10/site-packages/mistune/core.py", line 214, in parse_method > > 233909 assert lastgroup > > 233910 AssertionError > > is a known issue with mistune, which used by HyperKitty to display > messages from the archives. > Whatever is happening with the confirmation messages, it's unrelated > to this. > Yes, the traceback tells me that. I'd shared as Mark had asked for the log from mailmanweb. > What confirmation messages are missing? Mailman may ask for > confirmation if a user adds an email address via Postorius, if the > user asks for a password reset from Postorius, if a user who is not > logged in subscribes to a list (either by email or by Postorius), > and there may be other cases. Please describe all that apply. I created an admin user and when I try to sign in with that user, I get a page that tells me that a confirmation email has been sent and I should confirm the user. I created another user with a different email, and I got the same thing, didn't receive the confirmation emails in my inbox. > What makes you think that they are missing? Sometimes users or sites > have filters that throw them away, or they may be swallowed by MTAs > because of misconfigurations. I looked at mailman smtp logs, and didn't see any event related to the confirmation emails. The uwsgi logs show the events though. > Is your "virgin" runner and "out" runner running? (Usually "ps aux > | grep mailman" will list only the processes running under mailman. > The full command at the end of the line will tell you the names of > the runners each process is handling.) Yes, the virgin and out runners are running, output from ps; mailman 1983940 0.0 1.3 117980 82720 ? Ss Feb05 0:00 /opt/mailman/venv/bin/python3 /opt/mailman/venv/bin/master -C /etc/mailman3/mailman.cfg mailman 1983951 0.0 1.4 120184 85832 ? S Feb05 2:05 \_ /opt/mailman/venv/bin/python3 /opt/mailman/venv/bin/runner -C /etc/mailman3/mailman.cfg --runner=archive:0:1 mailman 1983952 0.0 1.4 121268 86564 ? S Feb05 0:44 \_ /opt/mailman/venv/bin/python3 /opt/mailman/venv/bin/runner -C /etc/mailman3/mailman.cfg --runner=bounces:0:1 mailman 1983953 0.0 1.4 121052 86164 ? S Feb05 2:04 \_ /opt/mailman/venv/bin/python3 /opt/mailman/venv/bin/runner -C /etc/mailman3/mailman.cfg --runner=command:0:1 mailman 1983954 0.0 1.5 126908 93096 ? S Feb05 5:02 \_ /opt/mailman/venv/bin/python3 /opt/mailman/venv/bin/runner -C /etc/mailman3/mailman.cfg --runner=in:0:1 mailman 1983955 0.0 1.6 194792 98128 ? Sl Feb05 1:03 \_ /opt/mailman/venv/bin/python3 /opt/mailman/venv/bin/runner -C /etc/mailman3/mailman.cfg --runner=lmtp:0:1 mailman 1983956 0.0 1.4 124092 90144 ? S Feb05 2:40 \_ /opt/mailman/venv/bin/python3 /opt/mailman/venv/bin/runner -C /etc/mailman3/mailman.cfg --runner=out:0:1 mailman 1983957 0.0 1.4 122000 87164 ? S Feb05 2:11 \_ /opt/mailman/venv/bin/python3 /opt/mailman/venv/bin/runner -C /etc/mailman3/mailman.cfg --runner=pipeline:0:1 mailman 1983958 0.0 1.4 122392 87964 ? S Feb05 2:06 \_ /opt/mailman/venv/bin/python3 /opt/mailman/venv/bin/runner -C /etc/mailman3/mailman.cfg --runner=rest:0:1 mailman 1983988 0.1 1.5 138368 95736 ? S Feb05 13:10 | \_ /opt/mailman/venv/bin/python3 /opt/mailman/venv/bin/runner -C /etc/mailman3/mailman.cfg --runner=rest:0:1 mailman 1983989 0.1 1.4 132692 90420 ? S Feb05 13:03 | \_ /opt/mailman/venv/bin/python3 /opt/mailman/venv/bin/runner -C /etc/mailman3/mailman.cfg --runner=rest:0:1 mailman 1983959 0.0 1.3 117984 82764 ? S Feb05 0:01 \_ /opt/mailman/venv/bin/python3 /opt/mailman/venv/bin/runner -C /etc/mailman3/mailman.cfg --runner=retry:0:1 mailman 1983960 0.0 1.5 126932 91712 ? S Feb05 1:17 \_ /opt/mailman/venv/bin/python3 /opt/mailman/venv/bin/runner -C /etc/mailman3/mailman.cfg --runner=task:0:1 mailman 1983961 0.0 1.4 120932 86232 ? S Feb05 2:10 \_ /opt/mailman/venv/bin/python3 /opt/mailman/venv/bin/runner -C /etc/mailman3/mailman.cfg --runner=virgin:0:1 mailman 1983962 0.0 1.4 120948 86440 ? S Feb05 2:04 \_ /opt/mailman/venv/bin/python3 /opt/mailman/venv/bin/runner -C /etc/mailman3/mailman.cfg --runner=digest:0:1 > Are there messages collecting in the "virgin" or "out" queues? How can I check both queues? > Are there messages collecting in the MTA queue (the mailq utility > will usually tell you about those)? mailq doesn't show anything pertaining to the confirmation email. > Normally you would see log messages for outgoing confirmations in > /opt/mailman/mm/var/logs/smtp.log. You might see errors in > mailman.log if Mailman core is requesting the confirmations. If > Postorius is requesting the confirmations, I think it would probably > be in mailmanweb.log (Django has its own mail-sending facility, > those don't go through Mailman core). I assume Postorius is requesting the confirmations as this happens when I try to login to mailmanweb, the smtp logs don't show anything about the confirmation email being sent. The only place I see something about it is in uwsgi; 3050415 [pid: 1985548|app: 0|req: 518823/979759] 127.0.0.1 () {54 vars in 1197 bytes} [Thu Feb 12 21:52:32 2026] GET /accounts/confirm-email/ => generated 1556 bytes in 48 msecs (HTTP/1.0 200) 9 headers in 359 bytes (1 switches on core 0) > > -- > GNU Mailman consultant (installation, migration, customization) > Sirius Open Source https://www.siriusopensource.com/ > Software systems consulting in Europe, North America, and Japan

8 months, 3 weeks

Mailman-users search results for query "Postorius"