Search results for "Postorius" - Mailman-users

Re: Internal Server Error: /mailman3/accounts/fedora/login/

by Stephen J. Turnbull

Bernie, Thanks for the heads-up! Some sites may prefer a /robots.txt with User-agent: * Disallow: /mailman3/ Disallow: /archives/ Disallow: /accounts/ Disallow: /user-profile/ and if these paths are enabled Disallow: /postorius/ Disallow: /hyperkitty/ Disallow: /admin/ Note that the latter disallows indexing of /admin/docs/ if that URL is enabled. Presumably that's not a problem, since the general public should be going to djangoproject.com for documentation anyway. Bernie Hoeneisen writes: > Not sure though, how they harvested the URL that is triggering the > error. Maybe that URL is exposed somewhere, e.g. in Postorius or > Hyperkitty. I would imagine that somebody naive (eg, no robots.txt at all) has the top page with a sign-in or sign-up button exposed, which will lead to a page with social login buttons, including the fedora/login button. -- GNU Mailman consultant (installation, migration, customization) Sirius Open Source https://www.siriusopensource.com/ Software systems consulting in Europe, North America, and Japan

10 months

Re: Moderator e-mails only going out once a day

by Stephen J. Turnbull

jkoral(a)luc.edu writes: > -Mailman was installed using the virtual environment. > -Mailman info: > -I use systemd to stop and start the services. OK, this is all about as close to the environment most of the Mailman devs run as you can get. On the one hand, it's easiest for us to understand, but it also makes it more mysterious when something doesn't work ... "works for me", you know. > REST credentials: restadmin:restpass You should change this. It just makes it a little more annoying for someone unauthorized who gets access to port 8001, but it's very low cost to change. > -Virgin is running: > Note: Not sure how to check the queue, but when I run mailman3 > notify, the moderator e-mails get sent. Good. The queues are implemented with Python pickle files in the "queue" subtree, probably /opt/mailman/var/queue in your case, or maybe /opt/mailman/mm/var/queue if you use Mark's preferred setup. You're looking for .pck files in subdirectories of that directory which are older than about 5 minutes. I don't have a suggestion why the "notify immediately" option isn't working. Both the 'mailman notify' command and the 'notify immediately' option work the same way, by composing the notification and dropping it in the virgin queue. This should tell you the same thing that Postorius does, but you could try "su - mailman" followed by activating the virtual environment, then type mailman withlist -l list.with.problem and then m.admin_immed_notify expecting the response True according to your setting. If it comes up False, there's your problem but we need to figure out why that's different from what Postorius is telling you. You should be able to change it as well by typing m.admin_immed_notify = True commit() and exiting. Steve

1 year, 5 months

Re: Held messages: Long time waiating for response of the Mailman API

by Stephen J. Turnbull

Krinetzki, Stephan writes: > Hi everyone, > > any news here? We are running with Pyton 3.6 - maybe a Python > Upgrade can speed Mailman up? It would help if you provide the original description. I see you're running Apache + uswgi. uwsgi has been pretty finicky, and most of the developers use gunicorn as the WSGI host. I suggest you ask on the uswgi channels as well. (I don't think that's a *better* place to ask, just a relevant place.) You wrote: > If we try to approve them via Postorius, the message is delivered > to the list immediately, but the success message in Postorius takes > a long time - on average the process hangs for three minutes until > the message is no longer displayed. You jump to the conclusion that the REST API is slow, but there's zero evidence to localize to the REST API. If your browser isn't running on the same host as the webserver it could even be some kind of network timeout (reverse DNS?) completely unrelated to Mailman (unlikely, but can't be ruled out with the information provided). 1. What is in the various logs? Mailman core, Django, your backend database, the webserver, the WSGI hosts all may be writing to logs, especially if there's some kind of time out or other error condition. 2. Are all the relevant components running on the same host? Are there other web services running under Apache and/or WSGI? 3. What are the relevant configurations (Apache, uswgi, gunicorn, Mailman, Postorius, Django, database, DNS A/AAAA/CNAME)? This would be anything like port numbers and host names or IP addresses, user names and passwords (we don't need to know these, but you should provide obfuscated versions so we can check syntax, and of course you should check for typos). Steve

4 years, 7 months

Re: Template - "You can use these variables in the templates" - The variable for "leave" is missing

by Mark Sapiro

On 11/4/23 06:28, Stephen J. Turnbull wrote: > Wikinaut writes: > > > fxied in merge request > > https://gitlab.com/mailman/postorius/-/merge_requests/852 > > I wish you wouldn't. It's just bloat in the code and in the > docstring. Better to document that the administrative addresses can > be constructed using ${short_listname}. I believe Mailman still > supports both "list-leave" and "list-unsubscribe", as well. Actually, https://gitlab.com/mailman/postorius/-/merge_requests/852 only added documentation of the existing $description replacement which is appropriate, but it duplicates part of https://gitlab.com/mailman/postorius/-/merge_requests/851 which does that and adds a bit more documentation. Also see https://gitlab.com/mailman/mailman/-/issues/1108 and https://gitlab.com/mailman/mailman/-/merge_requests/1153 -- Mark Sapiro <mark(a)msapiro.net> The highway is for gamblers, San Francisco Bay Area, California better use your sense - B. Dylan

2 years, 10 months

Re: Moderate mails from owner

by Malcolm Austen

On Thu, 21 Mar 2019 16:58:45 -0000, Abhilash Raj <maxking(a)asynchronous.in> wrote: > On Thu, Mar 21, 2019, at 8:47 AM, Malcolm Austen wrote: >> On Wed, 20 Mar 2019 18:42:10 -0000, Mark Sapiro <mark(a)msapiro.net> >> wrote: >> >> > However, this is apparently not relevant because both the Member and >> > Non-Member actions are Hold. Thus, the post should be held unless it >> has >> > an Approved: header with the list's moderator_password attribute if >> > there is one, or it matches a Header filter rule with an accept >> action. >> >> At the risk of getting this really wrong - I have only limited MM3 >> knowledge - I will ask what is, I fancy, a closely related question ... >> >> My only experience of MM3 is with Ancestry's 'RootsWeb' installation. >> From >> the emails I can see a header "X-Mailman-Version: 3.1.0" but I can't >> find >> anything to identify Postorius which is the only interface I have to the >> system. >> >> From symptoms seen and described by others, I have deduced that the >> Postorius admin-per-user moderation options of "Default processing" and >> "List default" mean that a user may be set (by default on the rootsweb >> system!) to use the system default moderation settings rather than the >> list default settings. > > "Default Processing" means the default pipeline defined in Thanks, I will do some (more!) reading. > List > Settings > Alter Messages > 'Pipeline' ( in the bottom). This > pipeline is > system wide and is defined in source code, so it can't be customized by > site administrator. Unfortunately, that is not available to list-owners on the system concerned. Ancestry must have removed it. Malcolm. -- Malcolm Austen <malcolm.austen(a)weald.org.uk>

7 years, 6 months

Re: Mailman, etc. upgrade woes and persistent bugs

by Stephen J. Turnbull

Brian Carpenter writes: > I think treating all disabled options the same is short-sighted. They > are all not the same. > > -- Some list members will disable their subscription for good reasons > and will be really upset if a List Owner renables it through ignorance. > So it is important to know a disable member is done by the member > itself. This is true in principle, but (1) I don't think that the user cares; if they're looking at it, they know whether they want enabled or disabled, how it got that way doesn't matter to them, and (2) I can't see why an admin would disable delivery except on request from a user, so I can't see why an admin would reenable except on request from a user. The only case I can see would be a mass reenabling, but that's not going to happen in the future (I hope). > -- Some mailing lists will have multiple list owners managing them. So > it is important for one List Owner to know when a subscription has been > disabled by the actions of another List Owner. I don't see why, see above. > -- A List Owner may not know that some of his List Members are bouncing > messages for various reasons, so reviewing their Membership roster, they > see that they have some list members disabled due to bounces and can > then address those particular problematic members. This query is an important use case. But it's the only one, I think, unless you really have List Owners arbitrarily disabling members' subscriptions. And if you're thinking about reenabling from that page, I think you need a lot more information. For example, if the admin disabled, you need to know if that was a user request or something else (what?). If bounce disabled, you want to know what the bounce was ("no such mailbox"? probably not a good candidate for reenabling), and when (5 minutes ago? ditto). I guess you could just reenable and see what happens, but that could be risky (eg, sending mail to non-existent users is frowned upon by some providers). > @Abhilash, I highly recommend that you contact me off list about getting > access to Affinity so you can see what I am talking about. I would love > to show you what I have done for Member Management. I offered the same > to Steve but he never was interested in taking a look. It's not that I lack interest, it's that life got in the way. Unfortunately, until I get enough time (man-weeks, I've never worked on Postorius and very little in Django) to work on Postorius, or somebody else starts to do it, a look at Affinity is low priority. Also, it's pretty clear that a quick look isn't going to be very helpful. The Mailman developers know what Mailman 2 looks like. I think the benefits to a hands-on admin are pretty obvious vs the current Postorius, as are Web 2.0 improvments like sorting on the options. The more subtle improvements you've made are going to require a guided tour and/or some study to identify and understand. Aside: I have to assume that Postorius is aimed at the kind of subscriber that most of us are, and that list administration was something of an afterthought, and assumed to be mostly hands-off. That's the only rationale I can come up with for the design where list admins need to go to the individual pages to see user options -- it was easier to reuse the user option page and just give the admin permission to access and change it, than to provide a (sortable) list with user details. Steve

5 years, 7 months

Re: Reset bounce count in MM3

by Mark Sapiro

On 3/8/26 20:57, iMark wrote: > =========== > > My thinking was that to reset that member's bounce_count from 4 to 0, I > could just delete the records (resulting from the query) in the > "bounceevent". > > But as the query result only shows 2 bounces, I'm looking for where the > Admin web UI is getting "4" from (ie. the processed bounce events older > than 24 hours). The list member's bounce score is the bounce_score column in the member table, but finding the correct row is dificult because you need the list_id which you'd look up in the mailinglist table and either the address_id from the address table or the user_id from the user table. It's much easier to use mailman shell as in ``` $ mailman shell -l list(a)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(a)example.com mailing list >>> mbr = m.members.get_member('user(a)example.com') >>> mbr.bounce_score = 0 >>> commit() ``` But what is the point of doing this? If the member is bouncing, the score will continue to increment, and if not the bounces will become stale and a future bounce will set the score to 1. You mentioned reset_bounce.py, but that doesn't reset scores. It sets delivery enabled for users whose delivery is disabled by bounce, but you can do that, albiet one by one, in Postorius just by clicking the user in the membership list and setting Delivery Status to Enabled. In Postorius <=1.3.13, Delivery Status doesn't show in the membership list, but it will in the next release. -- Mark Sapiro <mark(a)msapiro.net> The highway is for gamblers, San Francisco Bay Area, California better use your sense - B. Dylan

6 months, 2 weeks

Re: Changing subscription address

by Abhilash Raj

> On Mar 18, 2021, at 8:29 PM, Stephen J. Turnbull <turnbull.stephen.fw(a)u.tsukuba.ac.jp> wrote: > > Thank you for your comments, Allan! > > Allan Hansen writes: > >> On 3/15/21, 21:28 , "Stephen J. Turnbull" <turnbull.stephen.fw(a)u.tsukuba.ac.jp> wrote: > >>> In the 'Mailman Settings' screen, List-based Preferences' tab, > >> You may mean the 'Subscriptions' tab. > > I did mean the 'List-Based Preferences' tab. The 'Subscriptions' tab > is non-functional. It's in some sense aesthetically more pleasing > than 'List-Based Preferences', but you have to do extra, unnecessary > work to get anything done from the 'Subscriptions' tab. It may make > sense to just get rid of the current 'Subscriptions' tab and rename > 'List-based Preferences' to 'Subscriptions'. +1 We can do that. I don’t think I’ve ever used the subscriptions tab myself to do anything. > > The only functionality of 'Subscriptions' over 'List-based > Preferences' is that it lists you once for each role and address > (member, non-member, moderator, owner) that you have for that list. > This is possibly more confusing than helpful for non-owners. > Moderators get informed of their role every time they need to do > something. And it's possible to be both a member and a non-member of > a list, which is pretty confusing. Yeah, technically you can be subscribed to a list with all possible roles at the same time. > >> Under 'User profile for <name>', under the 'E-mail Addresses', add >> button to ensure that 'Primary E-mail' is used for all lists. > > If you define "ensure" strictly, this would be a fair amount of work > because it would require overriding the normal "cascade" of > preferences, and incidentally a way to turn off that override. I'd > rather not make the implementation so complicated. > > 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. > It should be normally unnecessary to use the 'Preferences' interface, > because the default subscription should be "use primary address". For > people using the current versions of Mailman 3, who are already have a > bunch of subscriptions with the same *explicit* address, I think it is > good enough. But if there's demand for a "revert all to use primary > address" button, that would be easy enough to add. 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. > Here's why I think such a button would be unnecessary in future > versions of Mailman. What should happen if you subscribe by an > address not already known to Mailman without creating an account in > Postorius is > > 1. Mailman registers the address. > 2. Mailman creates a User object to "own" that address, and makes > that address the primary address for the User. > 3. Mailman creates a subscription which links the User (not the > address) to the mailing list so that the primary address is used. > > For addresses already known to Mailman, Mailman should look up the > User registered to that address, and if the subscription address is > the primary address, set "use primary address" for the subscription. 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. 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. 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. [1]: https://gitlab.com/mailman/mailman/-/blob/master/src/mailman/commands/eml_m… > > In this scheme, as far as I can see, your user doesn't need to do > anything with the account until she wants to change the address. At > that point she needs to activate the account: > > - visit her personal options page in Postorius > - request a password reset (she doesn't have one yet, so she can't log > in) > - click the special link > - set a password or link a social media account, and > - finally change the address. > > Note that this is the bare minimum of work for her. She has to prove > she can read mail at that address. Anything less, and *anybody* can > change her subscriptions. We could omit requiring a new password, > but it's not a lot of work once you've got to this point, while the > "request, wait for email, click link, do work" dance is pretty > annoying. Why make someone do it again next time? > > This is problematic if she's already lost access to the old address, > of course, but in that case you're probably going to have to intervene > anyway. > > I don't think Postorius requires her to do anything else, but if she > wants to she can update her profile at that point. > > I have to check the code, and probably also ask Barry and the other > folks who designed the current subscription mechanism in case there's > some fatal flaw in the scheme above. But I think that should do what > almost all "one address" users want, and it's probably what the > majority of people who have multiple addresses and use different ones > for different purposes want most of the time, too. 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. > > Note to self of possible problems: (1) The primary address is where > you would send administrative mail to the account holder and that > might not be an appropriate address for the default subscription. > (2) This is a pretty radical change from the current situation, so it > might need to be an option for the list or domain owner. > >> And, indeed, new subscriptions should default to 'Use Primary.' > > I agree. I'm astonished that there are situations where they don't, > to be quite honest. That's the whole point of having accounts in the > first place -- having *one* source of information about the user > rather than spreading it out over a bunch of lists. > >> Is that possible now? > > It is already the default for someone who subscribes by logging in to > Postorius. I assume that it is *not* the default for someone who > subscribes by email or mass subscription, otherwise you wouldn't have > the problem. > >> Does a member have to have an account for me to set it up thus for >> them? > > Yes. The primary address is an attribute of the account. > Subscriptions can't know anything about a primary address unless there > is an account. However, it should be possible to make this default > for an account that hasn't been activated yet, such as in a mass > subscription. 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. I have started working on designing a User management page[2] in Core which should make it easy for superuser to manage several things about a User, including the ones that don’t have an account in Postorius to manage their own. The list os “tasks” an admin can do isn’t decided, but please feel free to write comments there about things you’d like to be able to do as a server admin. [2]: https://gitlab.com/mailman/postorius/-/merge_requests/605 > > Regards, > Steve > > _______________________________________________ > Mailman-users mailing list -- mailman-users(a)mailman3.org > To unsubscribe send an email to mailman-users-leave(a)mailman3.org > https://lists.mailman3.org/mailman3/lists/mailman-users.mailman3.org/ -- thanks, Abhilash Raj (maxking)

5 years, 6 months

Re: Error -- postorius Un-handled exception

by Odhiambo Washington

On Sat, Jan 27, 2024 at 8:17 AM Mark <imark(a)posteo.net> wrote: > > ----------------------- > > > > > > "/opt/mailman/venv/lib/python3.11/site-packages/mailmanclient/restbase/connection.py", > > > line 160, in call > > > raise HTTPError(params.get('url'), response.status_code, > > > urllib.error.HTTPError: HTTP Error 500: {"title": "500 Internal > > Server > > > Error"} > > > ERROR 2024-01-24 05:41:46,333 51799 django.request Internal Server > > > Error: /postorius/lists/testing.example.com/ > > --------------------------- > > > Try running all the system initializations with "mailman info" and > > "mailman conf". This often will elicit errors if the system is messed > > up. More likely to get this error would be "mailman withlist $LIST" > > (maybe you need an '-l' option to specify the list, I forget). If > > that doesn't elicit the error, then check that Mailman's runners are > > running with ps. Since it's Debian, I guess they should be running as > > the 'list' user. Are Mailman's files and directories owned by 'list' > > or sometimes 'www-data' for log files? > > Debian yes, but venv/pip installation so running as "mailman". > > > > > The log is saying that when Postorius tried to look up that list, it > > tried to call out to Mailman core via HTTP to the API to get the > > information and that access failed with HTTP status 500. I think the > > actual error is likely to be reported in mailman.log (or it might be > > in error.log, "grep '05:41:46' *.log" in Mailman's log directory will > > probably find it). I'm pretty sure there will be relevant log > > entries, probably a matching traceback. > > ---------------------------- > > Hi, > > Thank you Steve, Mark, Odhiambo for your responses. > > After working my way through your suggestions with no joy I discovered > to my embarrassment that I hadn't created the "mailman-hyperkitty.cfg" > file. Once created all was well. > > This was of course after I had begun the installation process again from > scratch. My apologies for the waste of bandwidth and your time. > > Regarding my installation, (following the docs at > https://docs.mailman3.org/en/latest/install/virtualenv.html) I found a > couple of issues that others might also stumble over: > > 1. Installing Xapian needed clang. It didn't like gcc > 2. Being a fresh Debian 12 OS, I needed to also install make, > build-essential > 3. For the user "mailman" to access the databases I needed to change the > owner to mailman (even though all privileges has been granted) ... postgres=# create database mailman; > CREATE DATABASE > postgres=# create database mailmanweb; > CREATE DATABASE > postgres=# create user mailman with encrypted password '<PASSWORD>'; > CREATE ROLE > postgres=# grant all privileges on database mailman to mailman; > GRANT > postgres=# grant all privileges on database mailmanweb to mailman; > GRANT > > psql -d mailman -U mailman -W > $ psql -d mailman -U mailman -W > Password: > > psql: error: connection to server on socket > "/var/run/postgresql/.s.PGSQL.5432" failed: FATAL: Peer authentication > failed for user "mailman" > > sudo -u postgres psql > ALTER DATABASE mailman OWNER TO mailman; > \q > > $ psql -h localhost -d mailman -U mailman -W > Password: > > psql (15.5 (Debian 15.5-0+deb12u1)) > SSL connection (protocol: TLSv1.3, cipher: TLS_AES_256_GCM_SHA384, > compression: off) > Type "help" for help. > > ... and same for mailmanweb > > So far, so good. > > Thanks and apologies once again, > Mark > The issue you're dealing with in that case is this change in PostgreSQL-15 discussed in this blog: https://www.cybertec-postgresql.com/en/error-permission-denied-schema-publi… I have never needed to do `psql -d mailman -U mailman -W`. I used the steps documented above to enable mailman user to write to the database. postgres=# \c mailmanweb postgres You are now connected to database "mailmanweb" as user "postgres". mailmanweb=# GRANT ALL ON SCHEMA public TO mailman; GRANT mailmanweb=# \c mailman postgres You are now connected to database "mailman" as user "postgres". mailmanweb=# GRANT ALL ON SCHEMA public TO mailman; GRANT TBH, I am not sure which method is the best although I think this option is :) -- 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, 7 months

Mailman 3 Web Application Startup Time or Availability - 502 Bad Gateway and Postorius

by summersan＠nclack.k12.or.us

Hello, I've been setting up a new Mailman 3 installation earlier this year, and I think things have been going okay so far. I've noticed, however, that after a long amount of time passes (for example, a weekend), when I try to visit the local Mailman 3 web application (e.g., example.mailman.site/mailman3/lists/, where it says "Postorius" at the top left corner of the page and shows a list of mailing lists in the body of the page), I sometimes get a 502 Bad Gateway type of error (referenced from my notes). As far as I can tell, this looks like a normal web server (nginx?) error. If I try visiting the Mailman 3 server location again in a web browser shortly thereafter, I still might get a 502 Bad Gateway error. If I wait a while longer (maybe a minute or more?), the Mailman 3 web application appears to load as expected. I've tried looking at the gunicorn documentation (https://docs.gunicorn.org/en/stable/index.html) and searching online (including in this Mailman3 mailing list) to see if there's something that can be done to fix this issue. The closest thing I can find for now is advice for something that, while possibly being technologically unrelated, includes the idea of "warmup requests", which makes me think of simply setting up some sort of script to periodically load a page on the Mailman 3 web application in order to keep it more available for visitors (https://stackoverflow.com/a/57056170) Is there a setting or something in any of the Mailman 3 related programs that could help with keeping the Mailman 3 web application up and running more often without having to resort to making an ongoing, automated request to the Mailman 3 web application? Thank you. * Note: "Mailman 3" terminology is referenced from this page: https://lists.mailman3.org/archives/

5 years, 4 months

Mailman-users search results for query "Postorius"