Search results for "Postorius" - Mailman-users

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, 2 months

Re: Template path

by Seth Seeger

> On Sep 17, 2020, at 12:54 PM, Mark Sapiro <mark(a)msapiro.net> wrote: > >> I followed previous emails on this list which told me to set POSTORIUS_TEMPLATE_BASE_URL in /opt/mailman/web/settings_local.py, but that doesn’t seem to make any difference. (I set it to a different value and the error message didn’t change. I also tried setting it in /opt/mailman/core/settings_local.py to no effect. After each change, I restarted mailman-web and mailman-core containers.) > > > How did you create the template? In Postorius or by manually creating a > file somewhere? If by creating a file, POSTORIUS_TEMPLATE_BASE_URL is > not relevant, but ensure that the file is findable and readable by Mailman. I created the template in Postorius. >> From within mailman-web and mailman-core containers, I can reach “mailman-web:8000”. >> >> In the webpage, I see: Mailman REST API not available. Please start Mailman core. > > > The REST APT is normally exposed on port 8001, not 8000 (See `port` in > `mailman conf -s webservice`. Yes, it’s 8001: [webservice] hostname: 172.19.199.2 [webservice] port: 8001 > What is your setting for MAILMAN_REST_API_URL? does the port match? I’m not overriding it: ./postorius/mailman-web/settings.py:MAILMAN_REST_API_URL = os.environ.get('MAILMAN_REST_URL', 'http://mailman-core:8001') > >> In /opt/mailman/core/var/logs/mailman.log, I get: >> >> [17/Sep/2020:16:23:29 +0000] "GET /3.1/lists/xxx.example.com HTTP/1.1" 200 416 "-" "GNU Mailman REST client v3.3.1" > > It appears you are connecting to the REST API, but ... > ... >> urllib3.exceptions.ReadTimeoutError: HTTPConnectionPool(host='mailman-web', port=8000): Read timed out. (read timeout=5) > > > Something appears to be trying to connect to REST on port 8000 Is this a red herring? Is something else wrong? Setting POSTORIUS_TEMPLATE_BASE_URL in settings_local.py doesn’t seem to make any difference. Having set the POSTORIUS_TEMPLATE_BASE_URL, I deleted the template and recreated it. Now, when I approve a pending subscription it goes through, but the welcome email is blank. Seth

5 years, 7 months

Re: Footer from templates not working - DB issue?

by Mark Sapiro

On 9/25/22 05:26, mailman--- via Mailman-users wrote: > Dear All, > I have a similar issue. Also on Debian 11. Also installed as Debian PKG. It's version GNU Mailman 3.3.3 (Tom Sawyer) > I am using sqlite3. When I do the SQL-query I get an URI which is in multiple reasons wrong > http://localhost/mailman3/postorius/api/templates/list/....../list:member:r… The initial part of that URL is set from the Django setting `POSTORIUS_TEMPLATE_BASE_URL`. If that is set to `http://localhost/mailman3/`, it should probably be just `http://localhost/`. > OK - the hostname could be changed but the path is not existing at all. > There is no file "list:member:regular:footer" on the complete filesystem. It's not a file. It refers to an entry in the postorius_emailtemplate table in the database which is retrieved via the Postorius API. -- Mark Sapiro <mark(a)msapiro.net> The highway is for gamblers, San Francisco Bay Area, California better use your sense - B. Dylan

3 years, 7 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, 3 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.

4 years, 3 months

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, 1 month

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, 4 months

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

6 months, 3 weeks

Re: Mailman backend maintenance task

by Eugenio Jordan (external)

Dear Steve: I really appreciate you also took your time to provide more insights on how Mailman works, and how their different components interact each other. There are two "minor" tasks and one major task that we would need to accomplish within PostGRESQL, namely rebuilding the index related to hyperkitty_email table primary key, rebuilding also another index on the very same table supporting an uniqueness constraint (these would be the minor); and running vacuum full on the whole database to effectively reduce the size of precisely hyperkitty_email table, which is the largest table in this database, and if possible retrieve back to the SAN the extra space we had to add to cope with that very table size increasing. The way vacuum full locks the tables are, among all the locking mechanisms provided by PostGRESQL to guarantee the transactional integrity, one of the strongest, if not the strongest one (as far as I know, the tables are more ore less recreated when running vacuum full). The idea we were considering was more or less stopping all of the components, then starting up only PostGRESQL, and then performing each one of the mentioned tasks. Actually our PG release allow "online" indices rebuild (drop + rebuild concurrently), but we did not want to assume the risk if, for whatever reason, new records were added to the table breaking the uniqueness of both constraints (fixing this cases turns out to be a real pain in most cases). Alternatively, we could lock the table ourselves to get more or less the same effect, true, although, after all, the final impact on potential connections willing to run DML would be the same. In other words, rather than having lots of transactions coming from whether core component processes or web component processes fail, we prefer to stop everything. But it's got of course the worst downside: we would receive Let me please now go back to your kind explanation to see if I did get things correctly. You mention that regardless the connectivity that Mailman's core processes might have with the database, the emails will be received by and queued until the connection is back again and they can be delivered to the distribution lists' members. Could you please confirm whether this task would be actually delegated to Postfix (or any MTA integrated with Mailman)? If so, this is actually what we need: we could afford delaying the reception a couple of days, whilst we are sure that no mail will be lost. Once more, thanks a lot for your kind help. Best regards. -----"Stephen J. Turnbull" <[1]stephenjturnbull(a)gmail.com> wrote: ----- To: [2]eugenio.jordan(a)esa.int From: "Stephen J. Turnbull" <[3]stephenjturnbull(a)gmail.com> Date: 08/24/2021 05:33PM Cc: [4]mailman-users(a)mailman3.org Subject: [MM3-users] Mailman backend maintenance task Hi, Eugenio, I wrote this earlier but am in the middle of moving my office so my mail has been intermittent. I have been following your discussion with Abhilash, and he's definitely the expert, especially if you are using the containers he creates and distributes. But there's some information here he hasn't mentioned yet. Please consider the following discussion to be background that allows you to understand some of the considerations. I've only run the Mailman 3 suite with all three running constantly on the same host, so I have no experience with this kind of issue. [5]eugenio.jordan(a)esa.int writes: > Our customer is currently using PostGRESQL as backend, and we would > like to perform some maintenance tasks, namely running vacuum full, > or at least trying to rebuild hyperkitty_email primary key related > index. We have been asked on the real impact of putting in place > such initiative. Though the latter is related to archiving, I > haven't found a way to stop just Hyperkitty or Django related > processes other than stopping Mailman's core, hence preventing > mails addressed to distribution lists from being delivered, could > you please confirm if I am correct? Mailman core can certainly run without either Postorius or HyperKitty. Controlling Mailman core (moderation, helping users) without Postorius is annoying, but it can be done. If you stop the HyperKitty process, what should happen, I believe, is that posts for archiving will accumulate in the 'archive' queue until HyperKitty is available again. It's been a while since I studied this so I could be completely wrong, but as I understand it HyperKitty and Postorius are not daemon processes. Rather, they are WSGI applications, which means they are subprocesses spawned by your webserver, and controlled by it. In order to keep them from running, you would reconfigure the webserver to not call those WSGI applications. How that is done is specific to the webserver and the WSGI module. If you are running from Docker containers, most likely, you can just stop their containers. The larger problem is that Mailman core uses a RDBMS. Normally both Django and Mailman are referring to the same RDBMS, PostgreSQL in your case. I'm not familiar with the vaccuum operation; if it requires taking the whole RDBMS down, and Mailman is running on that RDBMS, you're out of luck. Mailman can accept posts and queue them, but it can't deliver them to subscribers without access to the RDBMS tables. If it's just a matter of locking some tables while other are available, then it should work because the tables used by core and HyperKitty are disjoint as far as I know. (I think Postorius and HyperKitty both use Django's user tables for authorization, so at least for those tables both Postorius and HyperKitty will have to be down, but core can continue running because its database is completely separate.) > Regarding the former, as far as I have read, the "mappings" lists > -> addresses are stored just in the database, so if we run some > kind of procedure or task like vacuum which will lock exclusively > tables, or want anyway to have the database stopped for a cold > backup or whatever, Mailman willl not work, that is, again the > mails addressed to the distribution lists will not be > delivered. Will you please confirm this point, too? That depends on how "vacuum" works. If you can tell the RDBMS not to lock Mailman core's tables, it can continue to run. Definitely if the database is not running, Mailman will continue to receive and store the posts, but it won't be able to distribute mail to subscribers until its tables are available again. At that point the queued posts will be processed normally, except that if there's a large backlog, they won't go out in a quick burst, it may take a while. One possible worry, depending on how you are connected to the Internet, is that your provider may interpret the sudden burst of outgoing mail when Mailman comes back on line as spam or some other sort of mischief. Mailman has no way to throttle this: it feeds messages to the MTA until the MTA says "stop". Then it waits until the MTA is ready again. Regards, Steve This message is intended only for the recipient(s) named above. It may contain p roprietary information and/or protected content. Any unauthorised disclosure, use, retention or dissemination is prohibited. If you have received this e-mail in error, please notify the sender immediately. ESA applies appropri ate organisational measures to protect personal data, in case of data privacy queries, please contact the ESA Data Prot ection Officer (dpo(a)esa.int) References 1. mailto:stephenjturnbull@gmail.com 2. mailto:eugenio.jordan@esa.int 3. mailto:stephenjturnbull@gmail.com 4. mailto:mailman-users@mailman3.org 5. mailto:eugenio.jordan@esa.int

4 years, 8 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, 7 months

Mailman-users search results for query "Postorius"