Search results for "Postorius" - Mailman-users

Hyperkitty on Debian 12

by Markus Grandpre

Dear list members, when following the instructions to migrate list archives from Mailman21 to Mailman3 (see [1]), I face the following problem: # python3 manage.py hyperkitty_import -l mailman21-migration-test-04 /var/mailman21/testlist.mbox python3: can't open file '/var/mailman21/manage.py': [Errno 2] No such file or directory and have no clue, where to find the right <manage.py> file. The command dpkg returns: # dpkg -l | grep hyperkitty ii python3-django-hyperkitty 1.3.7-1 all Web user interface to access GNU Mailman3 archives In </etc/mailman3/mailman-web.py> I find: INSTALLED_APPS = ( 'hyperkitty', 'postorius', 'django_mailman3', ... Can you please help me? Thank you in advance? Best, Markus [1] <https://docs.mailman3.org/en/latest/migration.html> -- Markus Grandpré Universität Konstanz Kommunikations-, Informations-, Medienzentrum (KIM) Abteilung IT-Dienste Forschung, Lehre und Infrastruktur, Tel: ++49 7531 88 4342

2 years, 2 months

Re: Sending a message to a subscription applicant when a subscription request is made

by Allan Hansen

Thank you, Mark. That makes sense. And, as you suggested, this will not work for me, because a lot of people log in and then apply to more lists. I can't exhort them to get the accounts set up and do their subscription maintenance while logged in, and they tell them that if they want to sign up for another list they have to log out first. __ I do need to find another way. I suggested these options: a. That we change the lines in the Python program in our installation that send 'list:admin:action:subscribe' to the list admins to instead send the template to the applying subscriber. b. That we change the lines in the Python program in our installation that send 'list:user:action:subscribe' to the subscriber with an unverified address to always do this, even when the incoming address has already been verified. c. That the current 'list:user:action:subscribe' be changed in published Mailman 3 source to 'list:user:action:confirm' and a new template ''list:user:action:subscribe' be set up to be sent when any subscribe request is made. This is more work, of course, so not likely a good thing to hack locally. It could be useful to other users. Of course, (a.) and (b.) are preferred in the short term, as I'd like to get our procedure simplified. Any idea which file to change for either, and some suggestion as to what to change? Yours, Allan On 3/28/23, 10:18, "Mark Sapiro" <mark(a)msapiro.net <mailto:mark@msapiro.net>> wrote: On 3/28/23 09:19, Allan Hansen wrote: > Mark, > > I tried doing this. > I unsubscribed myself from a list, set the policy as you suggest and re-applied. > I got no confirmation messages but as moderator I got the moderate message. How did you reapply? with the subscribe policy confirm then moderate a new subscriber should get the list:user:action:subscribe message and have to confirm before the request waits moderation? However, see below. > I then tried a bogus email and saw that a message was sent to that and no moderator message to me. > Would the server skip the verification message because I'm a moderator/admin? It's not because you are an admin. It's because you were logged in when you subscribed from the list's info page. You will need to confirm if you subscribe anonymously without logging in or subscribe via email, but if you are logged in to Postorius when you request subscription, that is sufficient confirmation that the request really comes from you, so you don't get an email confirmation. So, depending on your circumstances, this may or may not work for you. -- Mark Sapiro <mark(a)msapiro.net <mailto:mark@msapiro.net>> The highway is for gamblers, San Francisco Bay Area, California better use your sense - B. Dylan _______________________________________________ Mailman-users mailing list -- mailman-users(a)mailman3.org <mailto:mailman-users@mailman3.org> To unsubscribe send an email to mailman-users-leave(a)mailman3.org <mailto:mailman-users-leave@mailman3.org> https://lists.mailman3.org/mailman3/lists/mailman-users.mailman3.org/ <https://lists.mailman3.org/mailman3/lists/mailman-users.mailman3.org/> Archived at: https://lists.mailman3.org/archives/list/mailman-users@mailman3.org <mailto:mailman-users@mailman3.org>/message/D4WXXVOHXTDLRDGXV66GV4BAMWBRYEPF/ This message sent to hansen(a)rc.org <mailto:hansen@rc.org>

3 years, 2 months

Importing Mailman 2 Lists apart from Django

by Brian Carpenter

Hello Mailman Users, Are there instructions on importing a Mailman 2 list into a Mailman 3 core installation only? Does the import21 script not need Django/Postorius/Hyperkitty? It seems Django is required to import archives I guess because of the use of Hyperkitty. How about importing archives without having a Django installation? Is that what the prototype archiver for? We are getting ready to start working on a custom forum application for Mailman 3 (called Empathy) and I am would like to import some mailman 2 archives into the development server to work with. Thanks. -- Please let me know if you need further assistance. Thank you for your business. We appreciate our clients. Brian Carpenter EMWD.com -- EMWD's Knowledgebase: https://clientarea.emwd.com/index.php/knowledgebase EMWD's Community Forums http://discourse.emwd.com/

6 years, 1 month

Re: Mailman REST API not available. Please start Mailman core.

by Mark Sapiro

On 7/26/20 12:00 AM, joseverde(a)gmail.com wrote: > Okay, so I got the webservice of Mailman3 up and running, but when I go to mailman3/postorius/lists/, I get the following error: > > Something went wrong > Mailman REST API not available. Please start Mailman core. Do your settings in the webservice section of mailman.cfg for things like: admin_pass: restpass admin_user: restadmin hostname: localhost port: 8001 (Defaults shoun) match your Django settings MAILMAN_REST_API_USER = 'restadmin' MAILMAN_REST_API_PASS = 'restpass' MAILMAN_REST_API_URL = 'http://localhost:8001' Also, is Mailman's `rest` runner running ps -fwwA|grep runner=rest should show 3 processes. The runner and 2 workers. -- Mark Sapiro <mark(a)msapiro.net> The highway is for gamblers, San Francisco Bay Area, California better use your sense - B. Dylan

5 years, 10 months

changing default preferred language of list

by Paul Paulchen

Hi MM community, need a little advise. We're running mailman in a Docker Container (maxking) Mailman Core Version GNU Mailman 3.3.5 (Tom Sawyer) Mailman Core API Version 3.1 Mailman Core Python Version 3.8.10 (default, May 6 2021, 06:30:44) [GCC 9.3.0] As far as I understood, it should be pretty easy. My wish: every new list we create has a default value for the preferred language: de (instead of us) Like described here: https://lists.mailman3.org/archives/list/mailman-users@mailman3.org/message… We put the values in: [mailman] default_language: de "/etc/mailman.cfg" and "/opt/mailman/mailman-extra.cfg" Nothing changes. When I create a new list via Postorius, is see the preferred language is US. Am I missing something? Is the default always US? And I have to change it manually? Cheers in advance! Paul

4 years, 2 months

Re: Join a Mailman 3 list?

by Stephen J. Turnbull

Hi, Although I'm replying to Thomas, I'm going to address this message to Cathy. Thomas Ward via Mailman-users writes: > You'll have to talk to EMWD to see if your archives will be kept > with the migration. They have a completely custom web interface for > archival. When I talked with Brian several years ago he emphasized that moving to Mailman 3 at EMWD would be seamless. Presumably that would include moving the archives, which is quite straightforward if you're starting from a stock Mailman 2.[1] > EMWD uses their **own custom UI** for management and archiving. > This means that we can't give you any real guidance on EMWD and > such for how it relates to user management, etc. This isn't really a problem though. Either way, the new UI will be new to your administrators, and EMWD has historically had an extremely good reputation for working with administrators on such things.[2] But your *subscribers* are *not* using the web interface. Perhaps that will change, but you aren't worried about that, rather that Mailman 3 will enforce use of a web UI. It won't -- if your users don't personalize their profiles in Mailman 2, there's no need for them to start in Mailman 3. The intermediate case is the moderators, but I bet you are doing little or no moderation, and again, EMWD is probably happy to help their clients with that level of education. Also, you did mention the archives. If users are using the archives, the UI will change (either EMWD or HyperKitty). I would expect that could be an issue. As far as that going, EMWD probably has client- focused lists that use their web UIs that you could subscribe to, or perhaps are already subscribed to! I haven't looked at the mockups of Affinity etc that Brian published in years, but at the time they seemed streamlined compared to Postorius and HyperKitty. Between the fact that the "email-only" day-to-day operation you have with Mailman 2 will continue without a hitch with either stock Mailman 3 web UIs or EMWD web UIs, and Brian's pride in his work, I think that you should run, not walk, to EMWD and ask them the same questions. Of course all of my estimates of what EMWD would or would not be happy to do should be confirmed by asking them! Moving to a different hosting service or setting up your own server would be another matter, but as long as you're continuing to work with EMWD whom you find trustworthy, the sooner you move the better. Steve Footnotes: [1] There were enough differences between the Mailman 2 and 3 web UIs that he wasn't going to force anyone to upgrade. Organizations that depend on using the web UIs for their daily workflow could have their efficiency degraded while people learned the new system. This is especially true for the new EMWD web UIs for configuration and archives. But he was confident that the transition would not cause long interruptions in service or changes in the way you send, receive, and work with mail. [2] Working with even dozens of users is another matter, and I can imagine that EMWD would draw the line there. -- GNU Mailman consultant (installation, migration, customization) Sirius Open Source https://www.siriusopensource.com/ Software systems consulting in Europe, North America, and Japan

1 year

Re: nginx configuration on a multitasking server

by David Newman

On 12/10/21 12:57 PM, Mark Sapiro wrote: > On 12/10/21 10:22 AM, David Newman wrote: >> >> 1. At least on my system, the proxy_pass statement will only run >> without errors if I change this to a fully formed URL, e.g., >> 'proxy_pass http://127.0.0.1:8000'. Is this a typo in the docs? > > > I changed it at > https://docs.mailman3.org/en/latest/install/virtualenv.html#nginx-configura… > but I wonder if we shouldn't be using `uwsgi_pass` instead of proxy_pass. > > See https://nginx.org/en/docs/http/ngx_http_uwsgi_module.html#uwsgi_pass > > Are you using uwsgi or some other wsgi server. uwsgi, per the venv and PDF docs. Thanks for the fix. Regarding the uwsgi_pass docs, would 'uwsgi_pass_header' directives replace the 'proxy_set_header' ones in the venv doc? Looking at the uwsgi doc, it seems they might do different things. >> 2. What document root(s) and alias(es) to use for Postorius and >> Hyperkitty and the Django admin on a server that also runs other >> services (e.g., Postfix for non-list mail and Roundcubemail)? > > > If you can separate Mailman from other services by subdomain Alas, I can do that for all but one of the subdomains I have in production. For the past 15 or so years, users of that subdomain have used mail.domain.tld for MM2, roundcubemail, and an admin web UI that manages regular mail. The "/" has gone to roundcubemail, and users to go other directories for the other services. For example, MM2 users currently go to /mailman. , you can > configure them separately and for Mailman, root is irrelevant as > everything is proxied or aliased in a location directive. For example, > Mailman on the server that supports this list uses the > lists.mailman3.org domain and we have (excerpted) > ``` > server { > listen 443 default_server; > root /usr/share/nginx/html; > index index.html index.htm; > # root and index are probably irrelevant as we never go there > server_name lists.mailman3.org; > ssl on; > #ssl stuff > location / { > proxy_pass http://127.0.0.1:8000/; > # other proxy stuff In this example, / goes to MM3. The assumption here and in the MM3 docs is that we're standing up a dedicated server where MM3 pages should be served as the default. That's a totally valid design decision, and one could argue it's superior to running a bunch of other services on one machine. It's not the situation I have to deal with, though. Short of changing a long-standing URL, what I'm looking to do is have "/" continue to default to roundcubemail, and have users type in longer URLs for MM3 and other services. You're right that the root and index directives above are irrelevant since / goes to MM3 via proxy. What I'm asking is what root(s) and location(s) to use with nginx where MM3 isn't the default. Thanks again! dn > } > location /static/ { > alias /var/spool/mailman-web/static/; > } > location /robots.txt { > alias /usr/share/nginx/html/robots.txt; > } > location /favicon.ico { > alias /var/www/listorg/images/favicon.ico; > } > } > ``` > And for the other stuff we have > ``` > server { > listen 443; > server_name .list.org mirror.list.org mirror.mailman3.org; > root /var/www/listorg; > ssl on; > # ssl stuff > } > >

4 years, 5 months

lists.mailman3.org web site.

by Mark Sapiro

I have just upgraded the lists.mailman3.org Mailman 3 installation to the heads of the GitLab mailman* branches. A major change is the switch from Persona to Django Allauth. This requires some configuration which isn't yet complete. Hopefully it will all be working very soon. In the mean time if you want to log in to Hyperkitty/Postorius you should be able to log in with your email address. The first time you do this, Mailman probably won't even know your password so you'll have to request a reset. Once you have reset your password, you should be able to log in. I hope to have several social auth choices working very soon. -- Mark Sapiro <mark(a)msapiro.net> The highway is for gamblers, San Francisco Bay Area, California better use your sense - B. Dylan

9 years, 9 months

Re: Hiding an ML from a site

by Odhiambo Washington

On Thu, Feb 8, 2024 at 4:57 PM Jeremy Stanley <fungi(a)yuggoth.org> wrote: > On 2024-02-08 10:43:37 +0300 (+0300), Odhiambo Washington wrote: > [...] > > Looking at Postorius, they do have different mail hosts. > [...] > > Are you using the magic SITE_ID=0 in your settings file? For our > deployments, that was necessary to get it to auto-detect which > filter to apply based on the domain name used by the browser. > -- > Jeremy Stanley > Yes, I do have that in settings_local.py -- 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]

2 years, 3 months

Re: Changing subscription address

by Abhilash Raj

> On Mar 20, 2021, at 4:36 AM, Stephen J. Turnbull <turnbull.stephen.fw(a)u.tsukuba.ac.jp> wrote: > > Abhilash Raj writes: > >>> There does need to be a way to revert each option to inherit, and >>> there currently doesn't seem to be one. The 'Preferences' interface I >>> described in the previous post doesn't provide it either. I will >>> think about that. >> >> The implementation of this isn’t very difficult, but the UX of this is >> something I don’t know how to implement in that page to be very >> honest. > > Oh, I can play Liz Warren on that one! :-) "I have a plan for that." > >> We do already have ability to switch from an explicit address to Primary >> Address subscription. I would imagine it would be more than just a >> button, but more like a dropdown to choose an email or primary address >> and switch all subscriptions to that. > > Allan's situation is that for some reason he has a lot of users (or at > least suspects he does) who would be happy to have only one address > that there's only one place to change, but for some reason that > address is copied to (not inherited by) each of several subscriptions. This is a common situation actually, given that Postorius until recently only allowed subscribing individual addresses. Also, any subscriptions imported from Mailman 2.1 are also subscribed as address. > > We should address that, because I'm pretty sure his suspicion is > correct. For example, until I changed one of them -- and got two > emails about it for my discard pile :-) -- all of my python.org > Mailman 3 subscriptions were explicit. I still have about 8 to > go. :-) +1 >> This is how Core actually does work[1] if you subscribe via Email >> and you already have a primary address. It will lookup a user using >> the address and if the address is the primary address of the user, >> it will subscribe the primary address. > > If you say so, I guess it's true. Nevertheless, both Allan and I have > observed users with only one address, with that address subscribed > literally each time to several (~10) lists. Well a couple of stars have to align for it to work unfortunately. I realized that Core will use the primary address if you *already* have one set during email -join command processing. Add to that you can’t set an address as primary using just email commands, you end up with what you are seeing. Also, like I mentioned above, imported subscriptions are always address based. Another thing I thought I should clarify is that when I said subscribed via Primary Address in this or previous emails, I really meant that the User was subscribed and subscription inherits whatever the primary address of the user is. As opposed to explicit address itself (which could also be the email address currently set as primary address). > >> However, if it isn’t the primary address, and this is a new address, it will >> subscribe the address instead of user because the address isn’t >> verified at this point and hence can’t be a primary address. We could >> extend the subscription workflow to add an additional step to set this >> address as primary and subscribe the primary address. > > Yes, please, I think. Users who don't want this for subscriptions to > the primary address are going to be (rare) edge cases. If we need an > additional attribute on the user to handle the case of an unverified > primary address, I think that's an acceptable cost. Note that to > "claim" this User as her own, she has to verify that address. And if > she *can* verify that address, we can't stop her from doing so, we can > just make it more annoying. We don’t necessarily need the flag on user to set an unverified primary address, we might be able to get away without that. We could set the address as primary *after* we verify it. We always verify addresses regardless of the choice of the subscription mode (user or address). > >> Postorius has the full ability to define its own workflow because >> REST API provides full expression capability and doesn’t enforce >> anything. Previous versions didn’t had support for subscribing as >> Primary Address, but that has since changed and is the default one >> in the dropdown. >> >> This is for authenticated subscription, the anonymous subscribe works >> similar to email -join command. Mass-subscribe is probably working the >> same way. > > All of these should unify all subscriptions-by-this-address to one > User, in my opinion. +1 > >> Like mentioned above, it should be possible to do what you suggest. I >> am getting into the implementation details here, but the Subscription >> workflow would need an additional flag that would verify an address >> and use the flag to determine if it should subscribe the address or >> addresses’s user if an address is provided to the workflow. > > I don't think so. Just do the lookup, if it succeeds and matches > primary address, use inherit. If it doesn't succeed, create a User > and use inherit. If it does succeed, and doesn't match, use the > explicit address. Right now, P is explicit about it. You can choose if you want Primary Address or one of the explicit addresses added to your account. The primary address is the pre-selected choice, so if you go and just click on subscribe button, you get the primary address being subscribed. If you choose the explicit address then we subscribe the explicit address. Is that something you think needs modifying? The email join command does the first part you suggested, (if the lookup succeed and matches primary address, use inherit) but doesn’t do the second part (it will create a user, add the address to it and then use the address to subscribe). We can and should fix that. > It seems to me that this flag would be impractical for email > subscriptions (email commands with parameters are generally beyond the > kind of user this is most important for) or mass subscriptions (how > does the list owner know what the user wants?) anyway. If somebody > really wants all their subscriptions via primary address to be copies > of the primary address rather than user, I'm sorry, but they'll have > to deal with that. I can't imagine that it's the usual case, and > there's an easy workaround: make your primary address something other > than your usual subscription address! The flag I was talking was not really a user visible one but just thinking code flow. It might have to be a flag in API though to differentiate between the “verify this address and subscribe it” vs “verify this address, set it to primary and subscribe the User” cases. I agree that in situations where we just have an address to subscribe and no user exists, we create a user, add the address and verify and set it to primary and then use inherit. This should apply to, mass subscribe, anonymous subscribe and -join command. > If you disagree with me about the relative burden, then maybe we > shouldn't do this at all, but I'm pretty sure this is something we > should either do for all subscriptions, or for none. No, I think it shouldn’t be a big burden. > >> Primary Address is also an attribute of the Mailman User, so it >> should be possible for an admin to set that for a user if the user >> doesn’t have an account. When they sign up, they’d be able to >> manage and update accordingly. > > True, but AIUI Allan has a *lot* of users and on average they're > relatively needy compared to, say, my user population. The point of > his request is to smooth workflows for admins with user populations > where the admin *wants* to do many things for their users, or to have > smooth user workflows when they teach their users to do it for > themselves. That's why I'm focusing on the "I have one address and if > it changes I want to change it once" case. Makes sense. -- thanks, Abhilash Raj (maxking)

5 years, 2 months

Mailman-users search results for query "Postorius"