Search results for "Postorius" - Mailman-users

Re: FW: You have been invited to join the ssan@lists.ccalternatives.org mailing list.

by Odhiambo Washington

On Mon, Jun 9, 2025 at 4:37 PM Christian via Mailman-users < mailman-users(a)mailman3.org> wrote: > Thank you. When I as an admin invite someone to join a list through the web > interface, this is the email the invitee receives. Note that it doesn't > even > have the Description from List Settings > List Identity. What's going on > here? > > > -----Original Message----- > From: > > ssan-confirm+40d4507f7198e14bfd6ad89565461f782e099d60(a)lists.ccalternatives.o > rg > > <ssan-confirm+40d4507f7198e14bfd6ad89565461f782e099d60(a)lists.ccalternatives. > org> > Sent: Friday, June 6, 2025 4:48 AM > To: jack(a)safecomputing.org > Subject: You have been invited to join the ssan(a)lists.ccalternatives.org > mailing list. > > Your address "jack(a)safecomputing.org" has been invited to join the ssan > mailing list at lists.ccalternatives.org by the ssan mailing list owner. > You may accept the invitation by simply replying to this message. > > Or you should include the following line -- and only the following line -- > in a message to ssan-request(a)lists.ccalternatives.org: > > confirm 40d4507f7198e14bfd6ad89565461f782e099d60 > > Note that simply sending a `reply' to this message should work from most > mail readers. > > If you want to decline this invitation, please simply disregard this > message. If you have any questions, please send them to > ssan-owner(a)lists.ccalternatives.org. > [snip] Those are the contents of the default template - found in /opt/mailman/mm/venv/lib/pythonVERSION/site-packages/mailman/templates/en/list:user:action:invite.txt If you need to customize the contents of what is sent out, you need to create a template for the list. The template is named list:user:action:invite. You can create it either from Postorius or on the filesystem at /opt/mailman/mm/var/templates/lists/LISTNAME/en/list:user:action:invite.txt The variables you can use are visible on Postorius when you select the template. -- 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]

9 months, 1 week

Re: Member Issue Discovered

by Stephen J. Turnbull

Brian Carpenter writes: > I reported a serious problem. Inability to change display name is an annoying problem that probably *will* affect quite a few users, and if they can't do it themselves, it will affect list admins and then site admins who are asked to do it for them. Nobody has said we won't work on that, but it's not like we've had 1000 reports in the several years that Mailman 3 has been in production use. Nor is it all that big a deal: the user retains control of the display name in each post (modulo the DMARC mitigation). As far as I know the stored display name is only used cosmetically (in the UIs for user configuration of Postorius and HyperKitty and in administrative mail to the user). > The reply was to bring up assumptions that should not be made such > as a list member is actually a registered user. I'm not sure what you think is going on here. Users (registered) are the locus of authentication in Mailman, and as such they are more or less equivalent to Mailman's raison d'être, namely giving (human) users control of their own subscriptions. The difference between Mailman 2 and Mailman 3 is that in the former a user *is* an address, in the latter a user *has* an address (and maybe several). The original "user == subscription" model of Mailman 2 is plausible, but it wasn't sustainable. The users and admins we hear from most are "heavy users": the users subscribe to dozens of lists, typically several on a single host. They *really* wanted a single user that could provide a dashboard with one authentication, convenient default settings for new subscriptions, and access to information about all subscriptions and the user profile in the dashboard. And that's why Mailman 3 has a model with users (the core concept corresponding to human beings), addresses, and subscriptions (memberships), where most addresses are backed by users. > As you said they [list members] are not [registered users]. I'm pretty sure I didn't say that, but if I did, it's *still false*. Users are the core concept. It's *possible* to have addresses (and maybe subscriptions?) without users, but the normal case is a user which has one or more addresses, which are subscribed to one or more lists. > Regardless of whether they are just a list member or a list member > that is also a registered user, there is NO MECHANISM in place > where you can change their associated display name Ie, you agree. The *issue as originally reported* is that the display name cannot be changed in Mailman's database. > AND their data is not entirely removed when a reasonable assumption > is being made that it has, It's not reasonable for Mailman 3, as Mark and I have explained. > such as list unsubscribing. If a user unsubscribes from a list, that unlinks *one* of the user's addresses from *one* list. Assuming that that has anything to do with existence of user data is unwarranted in Mailman 3, and it was extremely weak in Mailman 2 as well, since unsubscribing fron one list doesn't change the fact that the address may be subscribed to other lists on the same server, likely with the same metadata (really the password was the only important thing, but that confirms the principle). If you want to automatically delete any associated user any time a list is unsubscribed in Affinity, you *can* do that. I don't think it's a good idea, not at all, but you *could*. I deal with the case where the user has exactly *one* subscription below. But that is not the general case. > Sorry but I can't see how this behavior can be justified Then you need to cool down, and think about how this actually could work, not how somebody who makes incorrect assumptions would like it to work. > and also not being made a high priority to fix. Offer me 25,000 yen/hr and I'll do the display name change next week. Priorities differ. > Some may think that retaining data when there is a reasonable > assumption that it is being removed It's not a reasonable assumption in Mailman 3, though, as Mark and I have explained. > is immoral and not just a violation of GDPR. I don't disagree for reasonable assumptions. I'm well-aware of the ethical and legal issues here. We may want to add a facility so that users can delete themselves. But that's a *hard* problem if it's going to be "right to be forgotten" compatible because you can't keep backups -- we need to be sure that the user knows what they're doing (and if they've assumed that the data "should" be removed, we already know they don't know what they're doing!) I don't think we keep Bitcoin wallets in the Mailman metadata (yet ;-), so deleting your user won't bankrupt you. But you will lose all your *other subscriptions* and your default settings, etc. The latter is a PITA until we build up a nice suite of templates (and I don't think we have user templates yet anyway). And once we do add that feature, it probably makes sense to offer to do so (after explaining the consequences) if the user deletes their last subscription. But I just don't see this as a major issue, except maybe for corporate users under GDPR and friends. And I doubt *they* will even blink at my consulting rates. :-) > As I said in my reply to Mark, it is a big deal for list owners > (admins) because they are the ones that are going to be interacting > with Postorius/Affinity the most. Technical question: Why do you include Affinity? As far as I know, Mark is correct, you can both change display names and delete users with mailmanclient, and therefore with the REST API (mailmanclient is just a wrapper around the REST API, it has no superpowers). In Affinity, this behavior is under *your* exclusive control. I also don't agree with your claim about admins interacting most. Yes, they will interact more often, but in my experience most interactions are conducted by ordinary users, not admins. That may not be true for your hosted lists, since they're aimed at a very different population from my software devs and economics professors and university students, but there are large populations of users out here who are perfectly happy to manage their own subscriptions, thank you very much. In any case, there's very little difference between users and admins for this kind of feature, *except* the scope of resources they can view and modify. If Postorius gives the feature to users, it will be trivial to enable it listwide for list admins, and vice versa. But deleting users is an even harder problem with respect to list admins: what if the user is subscribed to a list on a different virtual host that the list admin can't know about and the user may not realize is the same Mailman user? *Probably* it's good enough to refuse to delete the user in that case, but it's not obvious to me that users who make wrong assumptions will see it that way. > Most list members, especially those migrating from MM2, will not be > registering with Postorius/Affinity. I'm not sure what you mean. If you mean "the migration script will register them", OK, but they're still registered and still subject to the user-address-member model. But Postorius is just a UI. Postorius does have its own database, which is often confusing, but the user-address-member model is in core. It's core where the important registrations for subscribers take place. You can have a user-less address in the database, but for the address's owner to do anything with it, such as subscribe to a list or set a list to vacation mode, they have to authenticate (that includes implicit authentication with the OTK used to confirm a new user), and to authenticate they have to have a registered user, not just an address. Most addresses will be associated with users.

5 years, 4 months

Re: Postorius no connection to REST API

by Richard Rosner

Mark Sapiro wrote: > On 8/12/21 12:01 AM, Richard Rosner wrote: > > All the mailman processes should run as list and all mailman related > things should be readable and writable by list. I have set both /usr/bin/uwsgi-core and /usr/share/mailman3-web to be owned by lists, no changes yet. But at least mailman3-web now can actually be started without throwing an error. > > Yes, I meant if you want those URLs to work, you have to pass them to > uwsgi. You don't need all of them. mailman2 and postorius are > synonyms as are archives and hyperkitty > However, you could try using TCP to communicate with uwsgi rather than a > Unix socket. > This means replacing > uwsgi-socket = /run/mailman3-web/uwsgi.sock > with > uwsgi-socket = 0.0.0.0:8000 > in your uwsgi.ini file and using directives like > ProxyPass "/postorius" "http://127.0.0.1:8000/postorius" > ProxyPass "/hyperkitty" "http://127.0.0.1:8000/hyperkitty" > ProxyPass "/accounts" "http://127.0.0.1:8000/accounts" > ProxyPass "/django" "http://127.0.0.1:8000/django" > ProxyPass "/user-profile" "http://127.0.0.1:8000/user-profile" > ProxyPass "/mailman3" "http://127.0.0.1:8000/mailman3" > ProxyPass "/archives" "http://127.0.0.1:8000/archives" > > > in apache. I tried that switch and got ERR_HTTP2_PROTOCOL_ERROR. From the apache log: [Fri Aug 13 16:08:38.871462 2021] [mpm_event:notice] [pid 27808:tid 140008999584896] AH00489: Apache/2.4.48 (Debian) OpenSSL/1.1.1d mod_wsgi/4.6.5 \ Python/3.7 configured -- resuming normal operations [Fri Aug 13 16:08:38.871603 2021] [core:notice] [pid 27808:tid 140008999584896] AH00094: Command line: '/usr/sbin/apache2' [Fri Aug 13 16:08:42.881615 2021] [proxy_http:error] [pid 27809:tid 140008751261440] (20014)Internal error (specific information not available): [c\ lient 134.61.99.193:36563] AH01102: error reading status line from remote server 127.0.0.1:8000 [Fri Aug 13 16:08:44.072665 2021] [proxy_http:error] [pid 27809:tid 140008751261440] (20014)Internal error (specific information not available): [c\ lient 134.61.99.193:36563] AH01102: error reading status line from remote server 127.0.0.1:8000 [Fri Aug 13 16:08:49.277000 2021] [proxy_http:error] [pid 27810:tid 140008709297920] (20014)Internal error (specific information not available): [c\ lient 134.61.99.193:36696] AH01102: error reading status line from remote server 127.0.0.1:8000 I set them all to https. which solved the https error. But I still get Error 500. From apache log: [Fri Aug 13 15:47:58.833305 2021] [mpm_event:notice] [pid 26720:tid 139986206332032] AH00489: Apache/2.4.48 (Debian) OpenSSL/1.1.1d mod_wsgi/4.6.5 \ Python/3.7 configured -- resuming normal operations [Fri Aug 13 15:47:58.833436 2021] [core:notice] [pid 26720:tid 139986206332032] AH00094: Command line: '/usr/sbin/apache2' [Fri Aug 13 15:49:41.673108 2021] [ssl:error] [pid 26722:tid 139985899259648] [remote 127.0.0.1:8000] AH01961: SSL Proxy requested for lists.fsmuw.\ rwth-aachen.de:443 but not enabled [Hint: SSLProxyEngine] [Fri Aug 13 15:49:41.905868 2021] [proxy:error] [pid 26722:tid 139985899259648] AH00961: https: failed to enable ssl support for 127.0.0.1:8000 (12\ 7.0.0.1) [Fri Aug 13 15:59:25.049708 2021] [ssl:error] [pid 26722:tid 139985899259648] [remote 127.0.0.1:8000] AH01961: SSL Proxy requested for lists.fsmuw.\ rwth-aachen.de:443 but not enabled [Hint: SSLProxyEngine] [Fri Aug 13 15:59:25.059217 2021] [proxy:error] [pid 26722:tid 139985899259648] AH00961: https: failed to enable ssl support for 127.0.0.1:8000 (12\ 7.0.0.1) From the mailman-web log: uwsgi socket 0 bound to TCP address 0.0.0.0:8000 fd 4 Python version: 3.7.3 (default, Jan 22 2021, 20:04:44) [GCC 8.3.0] Python main interpreter initialized at 0x561db180adf0 python threads support enabled your server socket listen backlog is limited to 100 connections your mercy for graceful operations on workers is 60 seconds mapped 166752 bytes (162 KB) for 2 cores *** Operational MODE: threaded *** WSGI app 0 (mountpoint='') ready in 3 seconds on interpreter 0x561db180adf0 pid: 26851 (default app) *** uWSGI is running in multiple interpreter mode *** spawned uWSGI master process (pid: 26851) spawned uWSGI worker 1 (pid: 26861, cores: 2) [uwsgi-daemons] spawning "python3 manage.py qcluster" (uid: 38 gid: 38) 13:48:04 [Q] INFO Q Cluster-26864 starting. 13:48:04 [Q] INFO Process-1:1 ready for work at 26866 13:48:04 [Q] INFO Process-1:2 ready for work at 26867 13:48:04 [Q] INFO Process-1:3 monitoring at 26868 13:48:04 [Q] INFO Process-1 guarding cluster at 26865 13:48:04 [Q] INFO Q Cluster-26864 running. 13:48:04 [Q] INFO Process-1:4 pushing tasks at 26869 So at least that seems to be fine now > I am not familiar enough with apache/uwsgi configuration to be of more > help. Have you seen https://wiki.list.org/x/12812344 and have you asked > Debian for help with their package. They are the ones who should be > supporting it https://www.debian.org/support. I'll open an error report on mailman3-web. Maybe they have some input to that.

4 years, 7 months

Re: Postorius: Show only own lists

by Terri Oda

On January 23, 2018 6:26:51 AM PST, Thor Atle Rustad <thor.rustad(a)gmail.com> wrote: >2018-01-23 14:37 GMT+01:00 Simon Hanna <simon(a)hannaweb.eu>: > >> On 01/23/2018 12:10 PM, Thor Atle Rustad wrote: >> >>> Imagine an installation with 500+ mailing lists and almost as many >local >>> admins that are supposed to maintain their own local lists with a >few >>> local >>> members. As site admin, I see all 500+ lists, but I was expecting >*local* >>> admins to see only the lists they maintain. I have set all lists to >>> "advertised = False", so they are hidden from ordinary view. Is >there a >>> way >>> to show only relevant lists to local admins? >I believe I wrote Postorius in the subject line, but it may not be so >obvious. So yes, in Posterius I would like to hide the lists from email >harvesters, while relatively "untrusted" admins should have access to >basic >operations on the one list he/she "owns" (and without having to browse >through 50 pages of mailing lists). Somehow I don't think 500 >superusers in >our system is a good idea! What do you mean by local admins? Is this 1. Giantsite.example.com hosts lists for a bunch of domains, and you want the logged in admins of mydomain.com to see their list admin pages but not otherdomain.org's lists 2. You want each logged in admin to have their own personal dashboard of list admin pages for lists they administrate, even though they're all under one big domain. (Neither of those scenarios talks about archives, since you say you're only talking about postorious) I think #2 is something we should be doing, and the old "todo" section of the interface kind of was made with that in mind. Probably worth mocking up some screenshots and opening a feature request to keep the idea in mind, but it should be more a matter of prioritizing how things are displayed than any huge change. I'm not sure if we have a "local admin" concept in the system that lines up with #1, though.

8 years, 1 month

Re: Assistance Needed for Ubuntu 22.04 Mailman3 Installation and Configuration

by Odhiambo Washington

On Sat, Aug 31, 2024 at 9:12 AM smiithjohn90--- via Mailman-users < mailman-users(a)mailman3.org> wrote: > Hello Everyone, > > I'm trying to install Mailman3 on an Ubuntu 22.04 server right now, and > I've run across a few obstacles that I'd like help with. I've followed the > installation instructions, but I'm having trouble in a couple places, so I > was hoping an experienced someone might help me out. > > This is what I have completed thus far: > > - I used the apt-get package manager to install Mailman3. > Installing Mailman3 using the steps outlined at https://docs.mailman3.org/en/latest/install/virtualenv.html is highly recommended. However.... - PostgreSQL was configured as the database backend. > - Postfix was installed and set up to function as the Mail Transfer Agent > (MTA). > - Assemble Postorius, Hyperkitty, and the Mailman3 core. > > Problems I'm Having: > > Postorius and Hyperkitty Connectivity: I'm having problems making sure > that the Mailman core is correctly connected to Postorius and Hyperkitty. I > get a 502 Bad Gateway error when I try to access the web interfaces. > Despite checking my specifications, I am unable to identify the problem. > Check to see that "mailman-web" is running and listening on the port you have specified in your webserver config. lsof -i -P -n | grep :NNNN > Problems with Email Delivery: I'm also having trouble with email delivery. > Although Mailman appears to be receiving emails, it is not appearing to be > sending any out. I think there might be a Postfix problem, but I'm not sure > how to solve it. > You can check Postfix logs for clues. Generally Suggested Practices: Are there any particular security best > practices I should be aware of when it comes to Mailman3 installations? I > want to confirm that my configuration is both performance- and > security-optimized. > > > https://lists.mailman3.org/archives/list/mailman-users@mailman3.org/thread/… > https://www.igmguru.com/salesforce/salesforce-developer-training > > https://lists.mailman3.org/archives/list/mailman-users@mailman3.org/thread/… > > I would be grateful for any advice or resources! It would be really > beneficial if someone with a similar setup could share their settings or > troubleshooting procedures. > Our settings are as documented in this HOWTO: https://docs.mailman3.org/en/latest/install/virtualenv.html We do NOT use Distro packages for Mailman3. Regarding "performance- and security-optimized", I can say that for Nginx/Apache/Postfix, the usual security/optimization rules apply, which I think might be somehow beyond the scope of the MM3 discussion. PS: There are others who use the distro packages to install MM3 and they have previously posted the details in this list. You could search the list archives for that. There is some old documentation that I believe can work for you too: https://docs.google.com/document/d/1xIcSsoNFp2nHi7r4eQys00s9a0k2sHhu1V5Plan… It's detailed enough. -- 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, 6 months

Re: Weird response to postings after subscriptions and accounts

by Paul Arenson

Thank you Mark. I appreciate the response. Let me respond in two messages. The first is to confirm the rules for signing off for both types of used: The second is to clarify my problems with the signup procedure and how I might deal with it. (Mostly a very small change on your part and an explanation on my website for my users) 1) So, for both subscribers vi postorius only and hyperkitty users: email to discuss-leave(a)list.tokyoprogressive.org (or discuss-unsubscribe(a)list.tokyoprogressive.org) 2) Only for hyperkitty users, you can login, go to https://list.tokyoprogressive.org/postorius/lists/discuss.list.tokyoprogres… and click the big red unsubscribe button. 3) Also only for hyperkitty users, log in and click the dropdown at the upper right, select Account and click the Delete Account tab or go directly to https://list.tokyoprogressive.org/user-profile/ and click the Delete Account tab or go directly to https://list.tokyoprogressive.org/user-profile/delete (Guessing that #3 will not unsubscribe the person and--if they have already done 1 or 2, failing to do number 3 is not going to be a big problem. Am I right?) Now in the next message my thoughts on the signup procedure and tentative conclusion.

6 years, 5 months

Re: Delete Django profiles not signed up to a list

by Brian Carpenter

On 1/1/21 7:41 PM, Andrew Hodgson wrote: > I have noticed recently I have around 2000 bogus sign-ups that have created accounts in Django. Looking through the logs these have come from the Postorius sign-up pages. I checked and email confirmation is required before the accounts are created and the email addresses that have been used do seem like they could respond to these requests. > > I don't want to add captchas to the form right now but is there any way to clean out these users from the database perhaps periodically based on whether the accounts are subscribed to any list? I can't help with this but I want to say a bogus sign up will usually have a first/last name filled with randomly generated upper/lowercase letters eg. HiedfURW FHIUEYde. That was what we saw. I also implemented a server wide block against Russia and that cut bogus signups by 75%! What we did with our Affinity system is to auto-remove all unverified user accounts after 36 hours. You can perhaps put in a feature request for something similar with Postorius/Django on their Gitlab page. -- Brian Carpenter Harmonylists.com Emwd.com

5 years, 2 months

Re: Mailman, etc. upgrade woes and persistent bugs

by Brian Carpenter

On 2/13/21 10:37 AM, Jim Popovitch via Mailman-users wrote: > On Sat, 2021-02-13 at 08:01 -0500, Brian Carpenter wrote: >> Features are not the only thing about a modern UI, UX design plays a >> MAJOR role in the modern UI. Postorius should have at least matched MM2 >> in features in regards to something as important as Member management >> but instead it took a step back into the dark ages. > I'm gonna be a dick and remind you that less than 1 year ago you were > trying to convince me that MM3 was a gift from god and that it was time > for me to jump from MM2 to MM3 because it was sooo easy and such a time > saver.. or something like that. The point being, you yourself just > still aren't happy with MM3. Welcome to the club. I am very happy with MM3 just not with Postorius. MM3 allowed me to come up with my own admin interface. Mailman 2 would never allowed me to do that. So please leave your Mailman 2 bondage and come over to Mailman 3. We have cookies! -- Brian Carpenter Harmonylists.com Emwd.com

5 years, 1 month

Re: Splitting hosts: mta&core vs postorius

by Ruth Ivimey-Cook

Stephen J. Turnbull wrote: > I don't understand. I'm not in a position to test with Mailman itself > right now, but the standalone gunicorn[1] does the right thing (takes > an IP address and binds to the corresponding interface, or takes a > domain name, resolves it to the IP address, and binds that to the > corresponding interface). It does not substitute localhost. The localhost address is coming in via the hosts file, which is a relatively standard practice IMO. I could change it, but then perhaps other things would not work. I would prefer to be able to specify what I need. There are also things like systemd-resolvd which will do the localhost-substitution for you even if /etc/hosts doesn't. I did try with the gunicorn patch Mark mentioned (host = "0.0.0.0") and changing the cfg file hostname back to the full name of the host, and that now works!! -- in that the problem I showed earlier is gone. However I then get another issue. From the mailman.log file I now see in the last few lines. For clarity I've numbered them like this "{1}": {1} [22/Jun/2020:00:58:24 +0000] "GET /3.1/domains HTTP/1.1" 200 320 "-" "GNU Mailman REST client v3.3.1" {2} [22/Jun/2020:00:58:24 +0000] "GET /3.1/domains/ch-bc.org.uk HTTP/1.1" 200 215 "-" "GNU Mailman REST client v3.3.1" {3} [22/Jun/2020:00:58:24 +0000] "GET /3.1/domains/greyarea-web1.cam.ivimey.org/lists?advertised=true&count=0&page=1 HTTP/1.1" 404 26 "-" "GNU Mailman REST client v3.3.1" At this point the browser screen reports "Something went wrong" and the message "HTTP Error 404: {"title": "404 Not Found"}" Previously, the process stopped at line {1}. Now that and line {2} is executed (AFAIK) correctly, but then line {3} is isssued. I have no idea why something is looking for "domains/greyarea-web1": - Only the "ch-bc.org.uk" domain is listed in the reply to line {1}, as expected; - "greyarea-web1" doesn't appear in any lists I can show with the "mailman" cli command (and I think I tried them all); - "greyarea-web1" doesn't appear anywhere in the source or config other than as the name of the host its running on or as an ALLOWED_HOST; - I tried using "curl -X DELETE" (from the api docs) to delete a domain called that and it says no such list exists. My only possible clue is that I think, at some point in the journey of configuring mailman, I might have created a list called that on the host. However since then I have wiped the install files and reinstalled. I cannot make sense of this being the answer given the checks just listed. I went looking through the python source and can see that the get() function does indeed throw a 404 exception if the domain isn't found, but I cannot see which code is parsing the reply from the first line So I have two questions: 1) How can I fix this problem? 2) why does getting an 404 reply here cause the postorius web page to produce a "something went wrong" /404 and nothing else, when it could have simply reported that something had gone wrong with one specific domain; > I'd rather not enable the complexity of a multihomed application > unless there's an important use case. (I don't make the final > decision, but I am listened to by Those Who Do.) You wonder about multihome hosts, but should a host have more than one interface (as several of my VMs and physical hosts do), being able to specify which of the possible addresses to listen on could be very useful in the case that "all of them" is the wrong answer. There is no complexity for the developers beyond what is already supported and working. The only point I can see wrong here is the mailman3-core is using one hostname value for two distinct purposes, and IMO it shouldn't. Ideally, and this is icing on the cake, a listen address specification should allow multiple IPs to be passed in, in which case the server listens on all of them. I expect the python libraries already support this. Thanks to all for the help so far, Ruth

5 years, 8 months

Re: Splitting hosts: mta&core vs postorius

by Stephen J. Turnbull

Ruth Ivimey-Cook writes: > On 21/06/2020 04:52, Mark Sapiro wrote: > > Change that to greyarea-post > Problem is, if I do that (which I did in the beginning), the core rest > service listens on localhost / 127.0.0.1 I don't understand. I'm not in a position to test with Mailman itself right now, but the standalone gunicorn[1] does the right thing (takes an IP address and binds to the corresponding interface, or takes a domain name, resolves it to the IP address, and binds that to the corresponding interface). It does not substitute localhost. It could be a Mailman bug (Mailman 3 is usually configured with all components running on the same host, and that's how it's tested), but first, does greyarea-post resolve to a routable address on the relevant network when queried from that host? > IMO, the hostname parameter needs to be split up into a "what address > should the rest of the world use to address me" and separately "what > address(es) should I listen on". Multiple listen addresses enable > multihomed hosts to get the right connectivity, too. I'm not clear on what you're saying. An address is a rendezvous point; if you're not listening on the address that others are using, you won't meet. What good does it do to split them up? It's not clear to me why you think Mailman might want to be multihomed (which is different from the host wanting to be multihomed). I don't object to the work to make it so. But my paranoia says it's best if Mailman is cordoned off into the DMZ with webservers and other hazmat. By design, Mailman core doesn't need to talk to the Internet or to the secure internal network -- Internet functions are delegated to the MTA and the webapps, and local configuration is via shell access which in principle could be console. I'd rather not enable the complexity of a multihomed application unless there's an important use case. (I don't make the final decision, but I am listened to by Those Who Do.) Footnotes: [1] gunicorn is the Python module that manages web services for the REST interface.

5 years, 8 months

Mailman-users search results for query "Postorius"