Search results for "Postorius" - Mailman-users

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]

1 year, 11 months

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

by Stephan Krinetzki

Mark Sapiro wrote: > On 1/24/22 15:06, Mark Sapiro wrote: > > On 1/18/22 06:24, Stephan Krinetzki wrote: > > Hello, > > We are using Mailman 3.3.5 with Hyperkitty 1.3.5. Mailman 3 is > > installed in a venv and deployed using Apache and uwsgi. This works > > quite well so far, only withheld messages cause us a problem: 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. We have already adjusted the timeout > > in gunicorn.cfg, but this does not improve the situation. Are there > > any tips on how we can speed up the REST API? Or is it even a > > configuration error? > > There are two steps in handling the POST for a held message. The first > > step is accepting, rejecting or discarding the message. This is > > happening immediately. > > The second step is handling the poster's moderation action based on the > > choice from the Set member moderation dropdown in the view of the held > > message. This is processed by the code at > > https://gitlab.com/mailman/postorius/-/blob/master/src/postorius/views/list…. > > If no selection has been made, the default value POSTed for > > moderation_choice is no-action and that code is skipped. If it is one > > of the choices Hold for moderation, Reject (with notification), > > Discard (no notification), Accept immediately (bypass other rules) > > or Default processing that is processed. So presumably a selection has > > been made and processing is stuck on getting the member or setting the > > member's moderation action. > > Possibly the logs of your database manager will have information. > > Some additional info. > By gunicorn.cfg, do you mean the file at mailman/config/gunicorn.cfg? If > you are using gunicorn as a wsgi server, that is separate from the > gunicorn serving the REST API and its config doesn't affect the REST > API. The relevant config is mailman/config/gunicorn.cfg?. > Also, I doubt the issue is with the REST API per se, but rather it is in > Mailman core's processing of the particular endpoint and if that is > slow, it is most likely some kind of database issue. Hi Mark, yes, we are using a local copy of the gunicorn.cfg. It is in the home directory of our mailman3 instance (like the mailman.cfg, same directory). We will now look into the postgresql database - maybe there is an index missing or something like that. Thank you for help.

3 years, 11 months

Re: Upgrading other python packages than the mailman ones in a venv results in dependency conflicts

by Odhiambo Washington

On Mon, Dec 16, 2024 at 1:39 PM Ulf R. <ulf.rapphahn(a)offis.de> wrote: > Hello, > I know this should be the way to upgrade: > https://docs.mailman3.org/en/latest/upgrade-guide.html > I have 3.3.10 installed. > I saw that some python packages are outdated an tried this which install > all outdated packages in a row: > pip list --outdated --format=json | jq '.[].name' | xargs -n1 pip install > -U > One outdated package was django and this part happened: > ------------------------------- > vDownloading Django-5.1.4-py3-none-any.whl (8.3 MB) > Installing collected packages: Django > Attempting uninstall: Django > Found existing installation: Django 4.2.16 > Uninstalling Django-4.2.16: > Successfully uninstalled Django-4.2.16 > ERROR: pip's dependency resolver does not currently take into account all > the packages that are installed. This behaviour is the source of the > following dependency conflicts. > hyperkitty 1.3.12 requires django<5.1,>=4.2, but you have django 5.1.4 > which is incompatible. > mailman-web 0.0.9 requires django<4.3,>=4.0, but you have django 5.1.4 > which is incompatible. > postorius 1.3.13 requires django<5.1,>=4.2, but you have django 5.1.4 > which is incompatible. > django-mailman3 1.3.15 requires django<5.1,>=4.2, but you have django > 5.1.4 which is incompatible. > Successfully installed Django-5.1.4 > ------------------------------- > > So I made a roll back. > > Is this really the only secure way to update the venv?: > pip install -U mailman postorius django-mailman3 hyperkitty mailman-web > Correct! > May be yes and I have to ignore the rest? ;-) > Yes. Let them pull their own versions of dependencies. -- 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, 1 month

Re: Can't subscribe on new site/domain

by Flo

On 10/11/25 04:45, Mark Sapiro wrote: > On 10/10/25 3:46 PM, Flo via Mailman-users wrote: >> >> /var/lib/mailman3/web# sqlite3 mailman3web.db >> SQLite version 3.46.1 2024-08-13 09:16:08 >> Enter ".help" for usage hints. >> sqlite> SELECT * from django_mailman3_maildomain JOIN django_site ON >> site_id = django_site.id; >> ... >> ... >> 8|lists.example.com|7|7|Lists of Example|lists.example.com >> sqlite> >> > > The fields in order are: > > 1. the id of the django_mailman3_maildomain entry > 2. the mail_domain in the django_mailman3_maildomain entry > 3. the site_id the django_mailman3_maildomain entry > 4. the id of the django-site entry > 5. the domain name in the django-site entry > 6. the display name in the django-site entry > For me it looks like that 5 is the display name and 6 the domain name > The important things are 2. and 5. which are the mail host and the web > host that you see in the Postorius domains view. 3. and 4. are what we > joined on so they will always be the same. They aren't related to 1. > which is just sequentially assigned when entries are created. 1., 3. and > 4. being equal in some cases is a coincidence. > > The question is what are the other 2 entries. In particular are all 3 > values for 2. different and all 3 values for 5. different or are some > the same? > > If 2 of those entries have the same value for 5. and different values > for 2., that explains the issue when accessing Postorius at 5. because > that web host does not have a unique mail host. > For each of the lines mail_domain (field 2) is the same as the domain name (field 6, if I am right). Any domain name (and mail_domain, which has the same value) differs from the ones in any other line. So they are unique. Flo

3 months, 1 week

Re: Listing/Exporting member list error: Mailman REST API not available. Please start Mailman core.

by Daniel Armengod

Can confirm the problem is reproducible on mailman 3.3.0 installed via PIP. Postorius hangs on exporting CSV subscribers [1] (~6k in this case), with error "Mailman REST API not available. Please start Mailman core" (which is otherwise running fine). mailman3.log also shows WORKER TIMEOUT log entry, exactly the same as OP's message. > You can add a new |gunicorn.cfg| next to your |mailman.cfg| and add > the additional options. For further reference if anyone reads this thread, see [2]. I had to look that up to figure out where the file name "gunicorn.cfg" came from. It's not immediately obvious to the reader why a file named "guincorn.cfg" should be specially interpreted by mailman3. The suggested fix - increasing timeout of worker process - did work perfectly for me. Thanks :) Regards, Daniel [1] http://www.<redacted>.org/postorius/lists/<redacted>/csv_view/ [2] https://mailman.readthedocs.io/en/latest/src/mailman/runners/docs/rest.html…

5 years, 11 months

Re: How to store additional information about lists?

by Stephen J. Turnbull

Andreas Barth writes: > Not sure if this is the right approach, or if it wouldn't be more > appropriate to "just" replace the dependency on allauth in postorius, > and do all the magic in the frontend only (because that's where people > actually subscribe). If it's purely a matter of managing subscriptions by individual users, that's the path of least resistance, I think. I would not be surprised if there are things you don't actually need, but you'd need to implement so that Postorius doesn't blow up if some IMember feature you haven't implemented gets accessed. If in the future you might have an external personnel database with other stuff in it, and you want Mailman automatically synced to that, then IMember now might make sense to avoid technical debt in the future. But I don't know enough about IMember or your use case at the moment to make a useful recommendation. Steve

4 years, 7 months

Re: Template's encoding setup

by Mark Sapiro

On 9/15/19 3:33 AM, Ugnius S wrote: > > This noticed only on HTML text messages. If message comes in HTML the > header does not add extra <enter> new line, new paragraph > and footer as well. For example if message body has no additional, list's > decorated message looks next: > > TEST HEADER > _____________________Hello, > > text text text, pictures, text > > regards > Ugnius____________________ > TEST FOOTER > > I have tried to add more empty lines in "The footer for a regular > (non-digest) message.", but mailman removes these empty lines. > Work around is put dot "." and then several empty lines. The stripping of leading whitespace from templates created in Postorius is <https://gitlab.com/mailman/postorius/issues/301> to be fixed by <https://gitlab.com/mailman/postorius/merge_requests/434> > Mark, I have found Your post about HTML headers and footers: > https://lists.mailman3.org/archives/list/mailman-users@mailman3.org/thread/… > YES, that works good, I have tested it, but only in cases if message comes > in HTML. If sender sends plain text message, > mailman adds footer with all HTML code: > > <BR>__________________<BR> > <B> LIST NAME </B> > > Could it be possible that decorate.py would recognise message and if it > has HTML text body, then just would add header/footer and if not (if > message body is plain text) , then would strip header/footer "html to plain > text" may removing html code from it? As it says in the post you reference: message and digest footers and headers are always added either to a MIME text/plain message body or as separate MIME text/plain parts. HTML tags will just be displayed as plain text and will not be rendered as HTML. Also see <https://wiki.list.org/x/4030707>. -- Mark Sapiro <mark(a)msapiro.net> The highway is for gamblers, San Francisco Bay Area, California better use your sense - B. Dylan

6 years, 4 months

Postorius Suggestion: Give owner a view of all users of all owned lists

by Stephen J. Turnbull

Andreas Vetter writes: > it would be real great if owners that own several lists, but are > not superusers, can see all users of all *their* lists and manage > them. A down-"selected" version of the superusers view. > Would that be possible? Possible, yes. I don't know how to do it well enough to add to our distribution. Note that owners can't actually manage users -- that really does need to be a superuser. Owners can manage subscriptions to the lists they own. So first we'd want to create a new "Subscriptions" item for the top menu; the "Users" item isn't appropriate. I'm not sure who that item should be visible to. Most likely only owners, because individuals already have ways to see all their subscriptions, and it's not obvious they would want the same presentation as your superowners. Then you'd iterate over the logged-in owner's lists and collect all of the subscriptions. I guess you'd want them to be organized by address rather than by list. By User is out, I think -- owners can't normally see Users, and I'm unhappy abou the privacy implications of being able to correlate nole(a)alset.com with head(a)dodgy.gov in general, although I realize it's not a problem in your setting. Without a more complete specification of what your users need, and the presentation they'd want to see, I personally am unwilling to go farther than those comments. Maybe one of the other devs feels differently. Also, "domain owner" is way under-implemented currently. For the hierarchical situation you outline, all the problems go away for domain owners. Of course then you'd need to split out lists by domain, but to me that's a small cost to preserve sanity in the structure. Steve

10 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)

4 years, 10 months

Re: Moderate mails from owner

by Abhilash Raj

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 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. > > Are my deductions correct? And if so, could this be the explanation of the > issue detailed in this thread? > > Apologies if I'm barking up entirely the wrong tree, Malcolm. > > -- > Malcolm Austen <malcolm.austen(a)weald.org.uk> > _______________________________________________ > 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)

6 years, 10 months

Mailman-users search results for query "Postorius"