Search results for "Postorius" - Mailman-users

Re: domain owner role

by Abhilash Raj

> On Sep 1, 2021, at 7:52 AM, Rainer Herbst <rainer.herbst(a)aip.de> wrote: > > Dear all, > > recently, I have added one account to a domain as domain owner. I did expect the new owner to see all lists in that domain in Postorius, but he sees no list at all. > > Is this the way it should be? How can I add administrators able to perform administrative tasks on all lists in Postorius? > Domain owner role isn’t currently very useful in Postorius, they can so far only edit the domain templates. If you want to grant the user ability to manage lists in Postorius, you’d have to grant the user superuser privileges which will allow them to manage all the domains. I was thinking there is an open issue for it, but apparently there isn’t one so I opened a new one. https://gitlab.com/mailman/postorius/-/issues/533 -- thanks, Abhilash Raj (maxking)

5 years, 2 months

Postorius: Dropdown menus problem

by Thor Atle Rustad

In my latest iteration I installed Maxking docker-mailman by downloading the files (git clone https://github.com/maxking/docker-mailman.git) and building the images myself by modifying docker-compose.yaml like this: services: mailman-core: container_name: mailman-core build: context: ./core dockerfile: Dockerfile-alternate Same thing goes for mailman-web. Only modification was changing the uid/gid in the images to make it equal to the local user on the host. Now a few things are not working. In Postorius <server>/postorius/lists/<listname>) there is a menu row (Subscription requests|Held messages|Members|Settings|Mass operations|Banned addresses etc). The two items Members and Mass operations should normally show a drop-down menu when clicked, but here nothing happens. Same thing for the Admin menu (can't access Logout, amongst other things). In Hyperkitty, messages are not loaded properly. In various places on the page I see spinning discs indicating something is loading, but nothing happens. Any ideas? Thor

8 years, 11 months

Re: Rolling releases for Container Images and Funding Campaign for Mailman

by Abhilash Raj

On Sun, Nov 12, 2017, at 08:06 AM, Simon Hanna wrote: > > >>> These images are built using git-heads *only* if they are passing our > >>> test suite and are re-generated weekly. You should be aware that while > >>> all these components are tested with their individual test suites, their > >>> combination might sometimes not be stable. This will get you > >>> updates/bug-fixes much faster :) > >> This contradicts what you said in my merge request for Postorius > >> https://gitlab.com/mailman/postorius/merge_requests/232#note_43388756 > >> > >> You either use released versions, or make sure that the master branches > >> are always compatible. You can't have both with the current development > >> model. > > Not exactly, I still believe all our git-heads should be compatible with > > released (i.e. stable) versions of dependencies, regardless of the fact > > that we maintain those dependencies. > > > > Also, there is at least one test per-project which tests with git-heads > > of dependencies we maintain, so that we know if we make any incompatible > > changes. > > > > I am not sure what in the current development model prevents us > > to do both? > > > > The story for container images is different than testing with git-heads. > > We need better integration testing for the entire suite to be stable in > > conjunction, rather than independently. In fact, containers might be the > > perfect way to actually do the integration testing. > Scenario: Core changes something about rest that is backwards > incompatible. The change is commited to master. Since your containers > use the master branches, all future builds will fail until mailmanclient > and postorius/hyperkitty. Yes, that is a totally possible scenario. But, given that kind of testing we currently do, this scenario can happen not only to git-heads but also releases. That is what I am trying to build using container images. The fact that I *announced* and *released* these rolling images for public use, is only because people asked for it before. These images come with a fair amount of warning that, right now, they can break! > If you want to always have Postorius (and others) compatible with the > latest release of master, development for Postorius will be a Pain, > because you can't use the master branch of mailman for testing and quick > changes. Also your containers and all integration tests that can be done > with them will always fail. It would most definitely be a pain if we were to break REST API frequently, but that is quite rare. Given that in future API will be consumed by not just us, it is important to keep this assumption true. Another wishful project I have is to be able to "map" the REST API and monitor for changes; it'd also help us with lemme (the authenticating/authorization proxy for Core). And yes, container images will fail, and that's the point! I want them to fail so that releases don't :) Rolling images are meant to bring a faster feedback-loop from users who are OK with rare occasional breaking and want to help test the software, something like public-beta releases. > Until you fix Postorius and the other clients... So why not just have > the master branches always compatible and make life easier for > developers. Incompatible changes are released only with major version upgrades, so it is not going to happen with everyone, unless they choose to use the git-heads and get themselves into it. > I don't see a good reason why you want to do it the other way round... > > Any bug in core that affects Postorius will also just remain there until > you release a new version of core. > > If you really really want to have it your way, there have to be more > frequent releases. Yes, we definitely don't want to say "use new beta-quality container images or stone age stable release". Going forward, we will have more frequent releases too :) > >>> - Improve the container images to work with new micro-services > >>> architecture, > >>> to achieve scaling and redundancy in services. > >> The current bottleneck is the rest api from core. IMO bulk actions, > >> filtering and sorting should be added there before trying to have > >> multiple postorius/hyperkitty instances serving the same core... > > I didn't say they will be served from the same core ;-) > > > > Yes, the Core's API can be further improved to be more efficient. But > > that > > doesn't prevent us from scaling. I understand there are issues around > > multiple > > instances of containers, but I have ideas to get around most of them. > I just don't want that people that have issues with big installations > get the answer: > We know of that issue, please deploy Mailman on X containers/machines as > a workaround Containers are just an easy way to scale, given that we already have them, it'd be fun to see if I can make multiple instances run in parallel. Given that _most_ parts store their data in a data store (database, redis etc), it shouldn't be too difficult. There will be quirks with logging, queues in Core and hence held message views in Postorius, but apart from that, I think everything else can be served using any random instance of Core/Postorius/Hyperkitty. We can most definitely run multiple instances of Hyperkitty, which I feel will be more used than any other part of UI. If we partition the data smartly, we could do the same with Core. Again, these are just theories and needs much more testing and some changes in components themselves! This would most definitely increase the availability and auto-scaling. Making Core's API more efficient would definitely be a good thing and we do intend to do that in future. But, this would still be relevant if we had an efficient REST API, it's not a band-aid to the actual problem :) -- Abhilash Raj maxking(a)asynchronous.in

9 years

Re: Postorius 1.2.3 and MailmanClient 3.2.1 is now out

by Jonas Meurer

Abhilash Raj: > On Sat, Jan 26, 2019, at 5:10 AM, Jonas Meurer wrote: >> Hey Abhilash, >> >> Thanks a lot for your work on mailman3! >> >> Abhilash Raj: >>> I am very pleased to announce (a bit late) that Postorius 1.2.3 and MailmanClient 3.2.1 is now out. >>> >>> The full set of changelog can be found in the documentation[1][2]. The most notable feature that >>> I can think of is non-member management in Postorius. >>> >>> New releases are available on PyPI[3][4]. >> >> For earlier releases, you provided GnuPG signature files to >> cryptographically verify that the release files were not tampered with. >> >> I couldn't find such signature files for the two latest releases. Would >> you mind adding them? When packaging for Debian, I prefer to check the >> GnuPG signatures before uploading new releases. Also, the signature >> files get uploaded to the Debian archive as well so they can be checked >> by everybody. That way we can cryptographically proof that the Debian >> package is based on the original tarball that got packaged and signed by >> upstream. > > > Ah, sorry about that. I completely forgot about that. > > I am not sure if I can upload signatures after uploading the tarballs, I'll try to find out if that is possible. Thanks a lot, that would be awesome. I'll wait for it before doing the Debian package uploads. Just to let you know: we're close to soft freeze in Debian, so in order to get those uploads into the next stable release (Buster), they'll have to be uploaded rather soon. The same holds for other pending releases of Mailman3 components: Just in case you plan to do new upstream releases anytime soon, it's still possible to upload them to Debian in time for Buster. Cheers jonas

7 years, 9 months

Issue with Held Messages

by Jean-Luc Wasmer

Hi, No matter what action I set for member posts (Hold for moderator, Reject) they are always delivered. When I tried from a non-member email address, the message got held but when I try to see it I get a Server Error (500) page. The log files shows: ERROR 2016-08-18 01:04:30,231 base 21026 34722993152 Internal Server Error: /mailman3/lists/test.mydomain.com/held_messages Traceback (most recent call last): File "/usr/local/mailman/mailman-bundler/eggs/Django-1.8.14-py2.7.egg/django/core/handlers/base.py", line 132, in get_response response = wrapped_callback(request, *callback_args, **callback_kwargs) File "/usr/local/mailman/mailman-bundler/eggs/Django-1.8.14-py2.7.egg/django/views/generic/base.py", line 71, in view return self.dispatch(request, *args, **kwargs) File "/usr/local/mailman/mailman-bundler/eggs/postorius-1.0.3-py2.7.egg/postorius/views/generic.py", line 67, in dispatch return super(MailingListView, self).dispatch(request, *args, **kwargs) File "/usr/local/mailman/mailman-bundler/eggs/Django-1.8.14-py2.7.egg/django/views/generic/base.py", line 89, in dispatch return handler(request, *args, **kwargs) File "/usr/local/mailman/mailman-bundler/eggs/Django-1.8.14-py2.7.egg/django/utils/decorators.py", line 34, in _wrapper return bound_func(*args, **kwargs) File "/usr/local/mailman/mailman-bundler/eggs/postorius-1.0.3-py2.7.egg/postorius/auth/decorators.py", line 81, in wrapper return fn(*args, **kwargs) File "/usr/local/mailman/mailman-bundler/eggs/Django-1.8.14-py2.7.egg/django/utils/decorators.py", line 30, in bound_func return func.__get__(self, type(self))(*args2, **kwargs2) File "/usr/local/mailman/mailman-bundler/eggs/postorius-1.0.3-py2.7.egg/postorius/views/list.py", line 387, in get held_messages = utils.paginate(request, self.mailing_list.held, 20) File "/usr/local/mailman/mailman-bundler/eggs/mailmanclient-1.0.1-py2.7.egg/mailmanclient/_client.py", line 443, in held moderation_reasons=entry['moderation_reasons'], KeyError: u'moderation_reasons' Cheers, Jean-Luc

10 years, 2 months

Re: After server upgrade debian 11→12 and reinstalling everything in (venv), I got this error when accessing → mailman3/lists

by Mark Sapiro

On September 21, 2025 12:18:56 PM PDT, Wikinaut <mail(a)tgries.de> wrote: > >What's is going wrong here? >Are the templates in the database but were not read from the filesystem? >What steps do I have to perform to make the new site-templates become effective? When you set a template in Postorius, the template is stored in the database and an entry is made in Mailman core's template table with a uri to the Postorius API to get the template. As long as this entry is there, that's the template you get. Delete the template from Postorius and you will get the template from the file system. -- Mark Sapiro <mark(a)msapiro.net> Sent from my Not_an_iThing with standards compliant, open source software.

1 year, 1 month

Re: Postorius & multi domain

by Gelpi Andrea

Thank You so much for your quickly answer and explanation. I understand that the web server name must be equal to the email domain. I read the issue. I'm not a python programmer so I ask you if it'd be long to implement a workaround like this. If the web server is a.example.com and the email domain is example.com It'd be possible to drop the "a" and send the email domain only in the query? It's a workaround. Can you help me in this? Regards, -- AG Il 22/04/20 18:22, Mark Sapiro ha scritto: > On 4/22/20 8:14 AM, Gelpi Andrea wrote: >> >> I search internet for a while and I discovered that using >> FILTER_VHOST = True >> seems to solve the problem. >> >> >From posotrius config page: >> >> FILTER_VHOST >> Filter the list of available lists in Postorius and Hyperkitty >> depending on the domain they are being currently served from. Mailman 3 >> supports multiple domains in a single installation. >> >> But it doesn't work. I got err 500 form apache. > > > FILTER_VHOST is currently broken unless each domain has the same value > for the web and email domains. See the thread at > <https://lists.mailman3.org/archives/list/mailman-users@mailman3.org/thread/…> > and the issue at <https://gitlab.com/mailman/postorius/-/issues/394>. > > >> Were can I find an explanation or a how to configure the system to have >> 2 webserver with different domains working on the some server as it was >> with mailman 2? > > > If each domain has the same value for the web and email hosts, > FILTER_VHOST will work. > > Currently though if you have domains like web host = lists.example.com > and email host = example.com, FILTER_VHOST is broken. > -- Gelpi ing. Andrea ************************************************** I documenti vitali dimostreranno la loro vitalitˆ spostandosi spontaneamente da dove li avevate lasciati a dove non riuscirete a trovarli. **************************************************

6 years, 6 months

Re: Another interesting error...

by Mark Sapiro

On 04/23/2018 02:59 PM, Darren Smith wrote: > Well, using the mailman shell we were able to find the request that was > causing the problem - it was apparently a spam message that had some > chinese characters in it. I am trying to duplicate this issue in a test environment. I can create a message with an invalid RFC 2047 encoded subject, i.e., Subject: =?gb2312?Q?=ff=fe=de=21=a2?= and send it to a list where it gets held, but I don't get a 500 in postorius and I see the held message with a raw (not decoded) header. I think there were some recent changes that affect this. I'll look some more. > We used the shell to delete the held request... > > And postorius is still giving me an error 500. > > If I'm not mistaken the held messages are kept in .pck files - do you know > if when postorius asks for held messages through the API, does mailman go > to the database or to the .pck? I would actually suspect the latter, or > removing the request should have fixed the problem. They were held in .pck files in Mailman 2.1, but not in Mailman 3. They should just be in the database and deleting them via mailman shell should delete them as long as you quit the shell or commit(). -- Mark Sapiro <mark(a)msapiro.net> The highway is for gamblers, San Francisco Bay Area, California better use your sense - B. Dylan

8 years, 6 months

New subscribed (by invitation) user: no password received in invitation/welcome e-mail. Postorius sign up / password reset broken

by Stephen J. Turnbull

^m'e via Mailman-users writes: > I migrated form MM2.1 to MM3.3.10 on Debian Trixie (mariadb > backend) -- I know that's a bit unorthodox to ask here for help on > a non venv-based installation, We appreciate your courtesy, but this is inaccurate. If you install a distro-packaged Mailman and it doesn't do the basic stuff such as "start" or "respond to web requests" out of the box, that's a distro problem. (That includes any features missing because of the inevitable lag in distro packaging.) On the other hand, if you have a misconception (see Issue #1) or if Mailman is basically working but doing a particular weird thing (in your opinion, and that's Issue #2), asking here is the right thing to do. Distro maintainers are frequently experts in packaging but ordinary users of their package without expertise in troubleshooting the package, and usually zero interest in educating users. That is what we are here for! And, obviously, "real" bugs may manifest first in a distro package. > but hopefully I'll first gain a bit of insight of MM3 in order to > formulate a more precise request to Debian maintainers. I don't think these are Mailman issues, and quite likely they're not Debian issues. > ## Issue #1. > > A newly invited (from Postorius mass subscription page) and > confirmed user doesn't get any password in their invitation/welcome > e-mail. The invitation/welcome emails usually don't know if the user is verified, and they are otherwise not personalized, so sending a one-time password (OTP) at that time would be a lot more complicated than it's worth. Also, many users may prefer to NOT set a password at all. For example, if you configure the Gmail socialauth plugin, a Gmail user can log in without doing the OTP dance. (I think we still require the dance to verify the address, because socialauth is hard and the burden is small. And if 'confirm' is set in the list preferences, you have to either log in to Postorius to subscribe, or do the dance for an email subscription.) Because Mailman 3 has a model of a user with multiple addresses and subscriptions, the burden of using the reset password dance for the initial setting of a password is considered very small (it usually is done once during the user's association with the Mailman instance, if at all). So that's the way we do it. > ## Issue #2 > > Anyway, if that new user asks for a password reset on Postorius they get > > "Server error > An error occurred while processing your request." This appears to be an MTA misconfiguration, either in Mailman or possibly in the MTA: > File "/usr/lib/python3.13/smtplib.py", line 861, in sendmail > self.ehlo_or_helo_if_needed() Mailman tried to connect to a mail server. > File "/usr/lib/python3.13/smtplib.py", line 365, in send > raise SMTPServerDisconnected('please run connect() first') > smtplib.SMTPServerDisconnected: please run connect() first It failed. Twp possibilities off hand: (1) The server expects authenticated and/or encrypted email (SASL and TLS), but Mailman is not configured to do that. (2) A typo in the server IP or hostname. There are all sorts of other reasons why a server might refuse a connection, but we'd need a lot more information to diagnose. Steve -- GNU Mailman consultant (installation, migration, customization) Sirius Open Source https://www.siriusopensource.com/ Software systems consulting in Europe, North America, and Japan

1 year, 2 months

Re: New subscribed (by invitation) user: no password received in invitation/welcome e-mail. Postorius sign up / password reset broken

by Marco Emilio Poleggi

Thanks Steve. Yeah, indeed, it was a stupid configuration error. So, while investigating malformed-url errors (https://lists.mailman3.org/archives/list/mailman-users@mailman3.org/thread/…, I had set mistakenly in `/etc/mailman3/mailman-web.py`: EMAIL_HOST = '' Of course, then how can Postorius contact my SMTP!? Bah, tweaking stuff uncritically is always Bad Thing (TM), dumb me. Everything looks OK now. The workflow is clear: the new user can get their password via the reset page and then go through with e-mail verification, etc. [*] I had meanwhile disabled unused apps to reduce attack surface and noise. Cheers, -- Marco On 2025-08-29 19:42, Stephen J. Turnbull wrote: > ^m'e via Mailman-users writes: > > > I migrated form MM2.1 to MM3.3.10 on Debian Trixie (mariadb > > backend) -- I know that's a bit unorthodox to ask here for help on > > a non venv-based installation, > > We appreciate your courtesy, but this is inaccurate. If you install > a distro-packaged Mailman and it doesn't do the basic stuff such as > "start" or "respond to web requests" out of the box, that's a distro > problem. (That includes any features missing because of the > inevitable lag in distro packaging.) > > On the other hand, if you have a misconception (see Issue #1) or if > Mailman is basically working but doing a particular weird thing (in > your opinion, and that's Issue #2), asking here is the right thing to > do. Distro maintainers are frequently experts in packaging but > ordinary users of their package without expertise in troubleshooting > the package, and usually zero interest in educating users. That is > what we are here for! > > And, obviously, "real" bugs may manifest first in a distro package. > > > but hopefully I'll first gain a bit of insight of MM3 in order to > > formulate a more precise request to Debian maintainers. > > I don't think these are Mailman issues, and quite likely they're not > Debian issues. > > > ## Issue #1. > > > > A newly invited (from Postorius mass subscription page) and > > confirmed user doesn't get any password in their invitation/welcome > > e-mail. > > The invitation/welcome emails usually don't know if the user is > verified, and they are otherwise not personalized, so sending a > one-time password (OTP) at that time would be a lot more complicated > than it's worth. Also, many users may prefer to NOT set a password at > all. For example, if you configure the Gmail socialauth plugin, a > Gmail user can log in without doing the OTP dance. (I think we still > require the dance to verify the address, because socialauth is hard > and the burden is small. And if 'confirm' is set in the list > preferences, you have to either log in to Postorius to subscribe, or > do the dance for an email subscription.) > > Because Mailman 3 has a model of a user with multiple addresses and > subscriptions, the burden of using the reset password dance for the > initial setting of a password is considered very small (it usually is > done once during the user's association with the Mailman instance, if > at all). So that's the way we do it. > > > ## Issue #2 > > > > Anyway, if that new user asks for a password reset on Postorius they get > > > > "Server error > > An error occurred while processing your request." > > This appears to be an MTA misconfiguration, either in Mailman or > possibly in the MTA: > > > File "/usr/lib/python3.13/smtplib.py", line 861, in sendmail > > self.ehlo_or_helo_if_needed() > > Mailman tried to connect to a mail server. > > > File "/usr/lib/python3.13/smtplib.py", line 365, in send > > raise SMTPServerDisconnected('please run connect() first') > > smtplib.SMTPServerDisconnected: please run connect() first > > It failed. > > Twp possibilities off hand: (1) The server expects authenticated > and/or encrypted email (SASL and TLS), but Mailman is not configured > to do that. (2) A typo in the server IP or hostname. > > There are all sorts of other reasons why a server might refuse a > connection, but we'd need a lot more information to diagnose. > > Steve > ___________________________________________ Mailman's content filtering has removed the following MIME parts from this message. Content-Type: application/pgp-keys Name: OpenPGP_0xC366FCF67CDBD9F9.asc

1 year, 2 months

Mailman-users search results for query "Postorius"