Search results for "Postorius" - Mailman-users

How to increase maximum size of the message in mailman

by Stephen J. Turnbull

Shashikanth Komandoor writes: > But the /var/log/maillog says the below error during the above > hand shake. > > *status=bounced (host 0.0.0.0[0.0.0.0] said: 552 Error: Too much mail data* > > I have browsed google for understanding and fixing the issue. > During which I encountered the information given by Mr. Mark Sapio at > https://lists.mailman3.org/archives/list/mailman-users@mailman3.org/thread/…. > But I could not fix the issue as it is mentioned the default size > limit is 33554432. There's no way to configure the LMTP server's message_size_limit in Mailman; this is a bug but I can't say when it will be fixed. In mailman/src/mailman/runners/lmtp.py, class LMTPController, if you edit the line server = LMTP(self.handler) to server = LMTP(self.handler, data_size_limit=100_000_000) it should have the desired effect. (I think that if as suggested by your post you're using Python 3.6, you'll have to remove the underscores from "100_000_000"; that feature was added in 3.7.) Unfortunately, any time you upgrade Mailman you'll have to edit it again (that's why I say this is a bug). I do not understand why the approach you used of editing DATA_SIZE_DEFAULT in aiosmtpd/smtp.py didn't work. The only thing I can imagine is that you have multiple Python installations and the one you edited is not the one that Mailman is currently using, or the same issue for multiple Mailman installations each with their own venvs or whatever. You also will have to configure Mailman. If you haven't done so already, the procedure is 1. Sign into Postorius as owner of the list, 2. click on the tab "Settings" in the middle of the header under the name of the list, 3. click on "Message Acceptance" in the sidebar at the left, and 4. set "Maximum message size" to 100000 (kb; no commas or periods). Unlike the LMTP size setting above, this configuration will persist across Mailman upgrades. > Also, please also let me know if there is any limitation specific > for the attachments so that I can customize that too respectively. No. Steve

4 years, 6 months

Re: Custom templates (was: Re: Re: nginx configuration on a multitasking server)

by Mark Sapiro

On 1/14/22 6:11 PM, David Newman wrote: > On 1/14/22 4:54 PM, Mark Sapiro wrote: >> >> It should work. I suspect you need to go to the list's Settings -> >> Automatic Responses and set `Admin immed notify` to Yes. > > > It's enabled. I think this triggers notifications only for new > subscription requests, not pending ones. Yes. That will send a single notification at the time of the request using the `list:admin:action:subscribe.txt` template. Notices of pending requests are sent by the `mailman notify` command using the `list:admin:notice:pending.txt` template. ... >> You can test `mailman notify` at any time by running it by hand. > > > Thanks. This still isn't working as intended. I took these steps: > > 1. Created the file > '/opt/mailman/mm/var/templates/lists/test.lists.domain.tld/en/list:admin:action:pending.txt' The template name is `list:admin:notice:pending.txt`, not `list:admin:action:pending.txt`. Thats why it didn't work. ... > 2. Restarted the mailman3 and mailmanweb services You only needed to restart Mailman core. ... > What I'm trying to do here is replicate a feature from MM2.1, where > pending notifications had URLs embedded in the message. That's not > available out of the box in MM3, and if there's a place for feature > requests I'd be glad to ask that this be made the default. The place for feature requests for Mailman core (which this is) is https://gitlab.com/mailman/mailman/-/issues, however, this is not straightforward as Mailman core doesn't know if you even have Postorius or some other web management UI installed or what the URL to access it might be. Thus it's not just a simple matter of editing templates. It would also require a configuration setting for the base URL for the web admin UI and changes in logic to provide an appropriate replacement depending on whether or not the base URL was configured. -- Mark Sapiro <mark(a)msapiro.net> The highway is for gamblers, San Francisco Bay Area, California better use your sense - B. Dylan

4 years, 1 month

Re: Notifying owners of membership changes but not moderators

by Perry Kollmorgen

Thanks Mark. So, I have python scripts which do the adding of nonmembers and moderators. For the nonmember script I needed to add something so that the nonmembers can send, i.e the moderaction_action = 'defer' This is my code for nonmembers: mailing_list.add_role('nonmember', nonmember.email, display_name=nonmember.display_name) list_member = mailing_list.get_nonmember(nonmember.email) list_member.moderation_action = 'defer' list_member.save() For the code for moderators it currently only adds them: mailing_list.add_moderator(moderator.email, display_name=moderator.display_name) Would I need to add something similar which sets a delivery_status for the moderator added ? Cheers, Perry ________________________________ From: Mark Sapiro <mark(a)msapiro.net> Sent: Wednesday, 27 November 2024 2:16 PM To: mailman-users(a)mailman3.org <mailman-users(a)mailman3.org> Subject: [MM3-users] Re: Notifying owners of membership changes but not moderators On 11/26/24 4:54 PM, Perry Kollmorgen wrote: > > Is there any way to have these only for Owners ? No. Essentially all admin notices are sent to LISTNAME-owner@DOMAIN and that in turn resends to owners and moderators. There are no controls to restrict this to only owners and not moderators, however it doesn't send to those with delivery disabled, so you could do something like this in `mailman shell` ``` $ mailman shell -l LIST_ID 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_ID mailing list >>> for moderator in m.moderators.members: ... moderator.preferences.delivery_status = DeliveryStatus.by_moderator ... >>> commit() ``` This will not affect the delivery status of the user's role as list member. This is not available in Postorius and also, the moderator can't set the delivery_status for their moderator role either, only for their member role. -- Mark Sapiro <mark(a)msapiro.net> The highway is for gamblers, San Francisco Bay Area, California better use your sense - B. Dylan _______________________________________________ Mailman-users mailing list -- mailman-users(a)mailman3.org To unsubscribe send an email to mailman-users-leave(a)mailman3.org https://lists.mailman3.org/mailman3/lists/mailman-users.mailman3.org/ Archived at: https://lists.mailman3.org/archives/list/mailman-users@mailman3.org/message… This message sent to pcjkollmorgen(a)hotmail.com

1 year, 3 months

Re: Implicit Destination Meaning

by Mark Sapiro

On 2/8/21 6:41 PM, Brian Carpenter wrote: > I just migrated a MM2 list to MM3. The client had no problem sending > posts to his list with MM2. However when he posted to his MM3 list, it > showed up in the moderation queue: > > ============ > Your mail to 'dogs(a)lists.redacted.org' with the subject > > mailing list changes > > Is being held until the list moderator can review it for approval. > > The message is being held because: > > Message has implicit destination > > Either the message will get posted to the list, or you will receive > notification of the moderator's decision. > =========== > > Is there a List Setting somewhere that needs to be adjusted to allow > this sender to post without moderation? There are a few things going on here. First, the list setting is require_explicit_destination. This is in Postorius under Settings -> Message Acceptance. If this is False or No, the implicit destination rule will never hit, but clearly it is Yes/True and should have been imported from the 2.1 list so it was probably True there too. When True, it means the list posting address or an acceptable alias must be explicitly addressed (in To:, Cc:, Resent-To: or Resent-Cc: of the post. An acceptable alias is a literal address or pattern matching addresses. These are also in Settings -> Message Acceptance and should have been imported from MM 2.1. For example, if the list's posting address is list(a)example.com, but you can also post to list(a)lists.example.com, list(a)lists.example.com should be in acceptable aliases. The most likely explanation here is that the post is being sent to a subdomain which is not the list's canonical posting address or vice versa. The reason this worked in MM 2.1 but not in MM 3 is in MM 2.1 if the list name matched, the check passed even if the domains didn't, but that is not the case in MM 3. The solution is to add the 'other' addresses to Acceptable aliases. -- Mark Sapiro <mark(a)msapiro.net> The highway is for gamblers, San Francisco Bay Area, California better use your sense - B. Dylan

5 years, 1 month

Re: Migrating mailman3 to latest ubuntu lts

by Helio Loureiro

Hi, Not a very good response. (venv) mailman@new-server ~ (v3.3.9) [0|1]> mailman-web check postorius Traceback (most recent call last): File "/local/mailman/venv/lib/python3.10/site-packages/django/apps/registry.py", line 158, in get_app_config return self.app_configs[app_label] KeyError: 'postorius' During handling of the above exception, another exception occurred: Traceback (most recent call last): File "/local/mailman/venv/bin/mailman-web", line 8, in <module> sys.exit(main()) File "/local/mailman/venv/lib/python3.10/site-packages/mailman_web/manage.py", line 90, in main execute_from_command_line(sys.argv) File "/local/mailman/venv/lib/python3.10/site-packages/django/core/management/__init__.py", line 446, in execute_from_command_line utility.execute() File "/local/mailman/venv/lib/python3.10/site-packages/django/core/management/__init__.py", line 440, in execute self.fetch_command(subcommand).run_from_argv(self.argv) File "/local/mailman/venv/lib/python3.10/site-packages/django/core/management/base.py", line 402, in run_from_argv self.execute(*args, **cmd_options) File "/local/mailman/venv/lib/python3.10/site-packages/django/core/management/base.py", line 448, in execute output = self.handle(*args, **options) File "/local/mailman/venv/lib/python3.10/site-packages/django/core/management/commands/check.py", line 56, in handle app_configs = [apps.get_app_config(app_label) for app_label in app_labels] File "/local/mailman/venv/lib/python3.10/site-packages/django/core/management/commands/check.py", line 56, in <listcomp> app_configs = [apps.get_app_config(app_label) for app_label in app_labels] File "/local/mailman/venv/lib/python3.10/site-packages/django/apps/registry.py", line 165, in get_app_config raise LookupError(message) LookupError: No installed app with label 'postorius'. (venv) mailman@new-server ~ (v3.3.9) [0|1]> mailman-web check hyperkitty Traceback (most recent call last): File "/local/mailman/venv/lib/python3.10/site-packages/django/apps/registry.py", line 158, in get_app_config return self.app_configs[app_label] KeyError: 'hyperkitty' During handling of the above exception, another exception occurred: Traceback (most recent call last): File "/local/mailman/venv/bin/mailman-web", line 8, in <module> sys.exit(main()) File "/local/mailman/venv/lib/python3.10/site-packages/mailman_web/manage.py", line 90, in main execute_from_command_line(sys.argv) File "/local/mailman/venv/lib/python3.10/site-packages/django/core/management/__init__.py", line 446, in execute_from_command_line utility.execute() File "/local/mailman/venv/lib/python3.10/site-packages/django/core/management/__init__.py", line 440, in execute self.fetch_command(subcommand).run_from_argv(self.argv) File "/local/mailman/venv/lib/python3.10/site-packages/django/core/management/base.py", line 402, in run_from_argv self.execute(*args, **cmd_options) File "/local/mailman/venv/lib/python3.10/site-packages/django/core/management/base.py", line 448, in execute output = self.handle(*args, **options) File "/local/mailman/venv/lib/python3.10/site-packages/django/core/management/commands/check.py", line 56, in handle app_configs = [apps.get_app_config(app_label) for app_label in app_labels] File "/local/mailman/venv/lib/python3.10/site-packages/django/core/management/commands/check.py", line 56, in <listcomp> app_configs = [apps.get_app_config(app_label) for app_label in app_labels] File "/local/mailman/venv/lib/python3.10/site-packages/django/apps/registry.py", line 165, in get_app_config raise LookupError(message) LookupError: No installed app with label 'hyperkitty'. (venv) mailman@new-server ~ (v3.3.9) [0|1]> mailman-web migrate -h usage: mailman-web migrate [-h] [--noinput] [--database DATABASE] [--fake] [--fake-initial] [--plan] [--run-syncdb] [--check] [--prune] [--version] [-v {0,1,2,3}] [--settings SETTINGS] [--pythonpath PYTHONPATH] [--traceback] [--no-color] [--force-color] [--skip-checks] [app_label] [migration_name] Updates database schema. Manages both apps with migrations and those without. positional arguments: app_label App label of an application to synchronize the state. migration_name Database state will be brought to the state after that migration. Use the name "zero" to unapply all migrations. options: -h, --help show this help message and exit --noinput, --no-input Tells Django to NOT prompt the user for input of any kind. --database DATABASE Nominates a database to synchronize. Defaults to the "default" database. --fake Mark migrations as run without actually running them. --fake-initial Detect if tables already exist and fake-apply initial migrations if so. Make sure that the current database schema matches your initial migration before using this flag. Django will only check for an existing table name. --plan Shows a list of the migration actions that will be performed. --run-syncdb Creates tables for apps without migrations. --check Exits with a non-zero status if unapplied migrations exist. --prune Delete nonexistent migrations from the django_migrations table. --version Show program's version number and exit. -v {0,1,2,3}, --verbosity {0,1,2,3} Verbosity level; 0=minimal output, 1=normal output, 2=verbose output, 3=very verbose output --settings SETTINGS The Python path to a settings module, e.g. "myproject.settings.main". If this isn't provided, the DJANGO_SETTINGS_MODULE environment variable will be used. --pythonpath PYTHONPATH A directory to add to the Python path, e.g. "/home/djangoprojects/myproject". --traceback Raise on CommandError exceptions. --no-color Don't colorize the command output. --force-color Force colorization of the command output. --skip-checks Skip system checks. Best Regards, Helio Loureiro https://helio.loureiro.eng.br https://github.com/helioloureiro https://mastodon.social/@helioloureiro On Sun, 17 Dec 2023 at 04:15, Stephen J. Turnbull < turnbull.stephen.fw(a)u.tsukuba.ac.jp> wrote: > Helio Loureiro writes: > > > Well... not that good. Now it is mailman3-web that doesn't work. > > > > (venv) mailman@new-machine ~ (v3.3.9)> mailman-web check > > System check identified no issues (0 silenced). > > (venv) mailman@new-machine ~ (v3.3.9)> mailman-web check migrate > > Traceback (most recent call last): > [omitted] > > LookupError: No installed app with label 'migrate'. > > > > Any idea why migrate isn't working and saying it is installed? > > Management commands aren't applications, so they wouldn't be valid > arguments to "mailman-web check" in any case. > Try "mailman-web check postorius" or "mailman-web check hyperkitty" to > see how the application argument works. You should get the report > "System check identified no issues (0 silenced)." as above. > > Then try "mailman-web migrate -h". > If that returns help output, the migrate command is installed and can > be run (the help string is part of the migrate module, not part of > mailman-web itself). > > Why do you think "mailman-web migrate" isn't working? Most likely > "migrate" is working as designed, but it is doing nothing because > something about the way you transported the database originally caused > mailman-web to think its database schema is up-to-date even though it > is not (as happened with the mailman database). > > Unfortunately this database is managed by Django, not by Alembic, and > I don't know offhand how to discover and tell Django the actual schema > version and then ask it to run any new migrations. > > Steve > > >

2 years, 2 months

Re: How to upgrade to 3.10

by Paul Tomblin

On Tue, Mar 3, 2026, at 12:30 AM, Mark Sapiro wrote: > > But it looks like here it's trying to install 3.3.10. > >> Requirement already satisfied: postorius in ./venv/lib/python3.13/site-packages (1.3.13) >> ... a bunch of these ... >> INFO: pip is looking at multiple versions of mailman to determine which version is compatible with other requirements. This could take a while. >> Requirement already satisfied: python-dateutil>=2.0 in ./venv/lib/python3.13/site-packages (from mailman) (2.9.0.post0) >> ...a bunch more... > > Is there any conflict reported in this `bunch more` to force 3.3.9? What > if you do `pip install mailman==3.3.10`? All the "...a bunch more..." lines are "Requirement already satisfied". And here's what happens when I try to do as you suggested: (venv) $ pip install mailman==3.3.10 Collecting mailman==3.3.10 Using cached mailman-3.3.10-py3-none-any.whl.metadata (2.4 kB) Requirement already satisfied: aiosmtpd>=1.4.3 in ./venv/lib/python3.13/site-packages (from mailman==3.3.10) (1.4.6) Requirement already satisfied: alembic!=1.7.0,>=1.6.2 in ./venv/lib/python3.13/site-packages (from mailman==3.3.10) (1.18.4) Requirement already satisfied: atpublic in ./venv/lib/python3.13/site-packages (from mailman==3.3.10) (7.0.0) Requirement already satisfied: authheaders>=0.16 in ./venv/lib/python3.13/site-packages (from mailman==3.3.10) (0.16.3) Requirement already satisfied: authres>=1.0.1 in ./venv/lib/python3.13/site-packages (from mailman==3.3.10) (1.2.0) Requirement already satisfied: click>=8.0.0 in ./venv/lib/python3.13/site-packages (from mailman==3.3.10) (8.3.1) Requirement already satisfied: dnspython>=1.14.0 in ./venv/lib/python3.13/site-packages (from mailman==3.3.10) (2.8.0) Requirement already satisfied: falcon>=3.1.3 in ./venv/lib/python3.13/site-packages (from mailman==3.3.10) (4.2.0) Requirement already satisfied: flufl.bounce>=4.0 in ./venv/lib/python3.13/site-packages (from mailman==3.3.10) (4.0) Requirement already satisfied: flufl.i18n>=3.2 in ./venv/lib/python3.13/site-packages (from mailman==3.3.10) (6.0.0) Requirement already satisfied: flufl.lock>=5.1 in ./venv/lib/python3.13/site-packages (from mailman==3.3.10) (9.0.0) Requirement already satisfied: gunicorn in ./venv/lib/python3.13/site-packages (from mailman==3.3.10) (25.1.0) Requirement already satisfied: lazr.config in ./venv/lib/python3.13/site-packages (from mailman==3.3.10) (3.1) INFO: pip is looking at multiple versions of mailman to determine which version is compatible with other requirements. This could take a while. ERROR: Could not find a version that satisfies the requirement nntplib; python_version >= "3.13" (from mailman) (from versions: none) ERROR: No matching distribution found for nntplib; python_version >= "3.13" I guess I need to upgrade my python version? -- Paul Tomblin

1 week, 1 day

Re: Hyperkitty performance problem

by Mark Sapiro

On 12/28/24 05:19, monochromec via Mailman-users wrote: > Following the root cause analysis which Tobias started all those weeks ago we (the admin team behind the installation) are still struggling with the following phenomenon: messages on average take more than 24 hours to be processed, more precisely, the average lifetime of a pickled message object in `/var/lib/mailman3/queue/pipeline` clocks in at around 26 hours). This issue is with Mailman core's pipeline runner. See https://docs.mailman3.org/projects/mailman/en/latest/src/mailman/docs/8-mil… for an overview of message handling and queues in Mailman core. It seems that the pipeline runner(s) are taking an inordinately long time to process a message through the pipeline of handlers causing the pipeline queue to become backlogged. > Couple of stats of the installation: standard installation from Bookworm OS repos, Hyperkitty as archiver and Postorius as web frontend as explained above, running Python 3.11.2 from the standard systemd service as packaged with the Bookworm deb file. All backends (Core + Hyperkitty) are supported by Postgres version 15+248. The MTA is a standard Postfix installation, again from OS packages. The primary support for Debian packages is Debian. See https://wiki.list.org/x/12812344 > The underlying VM has 7 cores with just under 24 GB of main memory. This production instance is handling less than 130 mailing list (MLs) with an average of less than 10 postings per day per ML. CPU core utilisation hovers around 50% with the lion share allocated to the four pipeline runners as part of the MM configuration. This is an average of less than 1 message per minute. Processing a message through the pipeline should take nowhere near a minute. Possibly there is an issue in the rfc_2369.py handler. This handler communicates with HyperKitty via mailman_hyperkitty to obtain values for the List-Archive: and Archived-At: headers added to the message. Possibly there is some configuration issue with mailman_hyperkitty that causes these queries to take a long time and possibly eventually time out. Are there any `Connection to HyperKitty failed:`, `HyperKitty failure on ...` or `Invalid response from HyperKitty` type messages in mailman.log? -- Mark Sapiro <mark(a)msapiro.net> The highway is for gamblers, San Francisco Bay Area, California better use your sense - B. Dylan

1 year, 2 months

Re: Mailmanweb RAM Usage

by Odhiambo Washington

On Sun, Oct 12, 2025 at 9:48 AM Stephen J. Turnbull <steve(a)turnbull.jp> wrote: > Odhiambo Washington via Mailman-users writes: > > On Sat, Oct 11, 2025 at 5:10?PM Stephen J. Turnbull <steve(a)turnbull.jp> > > wrote: > > > > Do you mean only HyperKitty + Postorius? That seems like a lot. > > > Yes, just Hyperkitty+Postorius: Please see > > https://imgur.com/a/LPAY69N It represents what I see daily when I > > run btop. It's always around 2GB, but rarely do I see above. I > > only have 1 major active mailing list on this server. There are > > other inactive ones. > > I'm not sure what's going on. I'm pretty sure you would save up to > 1.5GB by switching to gunicorn vs the uwsgi configuration you have. > > But the uswgi project has acquired functionality the way systemd has > over the last few years. It seems likely that you could configure it > to save a lot of memory by removing functionality you don't use. Not > sure whether than involves recompiling or just disabling unused > plugins, I'm not really familiar with uwsgi, since even for the > largest instances I've seen gunicorn is sufficiently performant and > secure. > I will switch to gunicorn and see how that goes. > The MySQL footprint also seems a bit high. but not insane, my > PostgreSQL weighs in at about 1.2GB-1.5GB. > My MariaDB is running some WordPress websites. Mailman is just one other application using it. Last week, I tried to migrate the MM3 DB to PostgreSQL, but didn't quite succeed at the last minute. It's an exercise for another day. Overall, you don't have an insane configuration, but it depends on > what you're optimizing for. > Thank you for looking into this. I will update once I have made the changes. -- 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]

5 months

Re: Welcome Message

by Abhilash Raj

On Wed, Apr 17, 2019, at 1:41 PM, brian(a)emwd.com wrote: > Abhilash Raj wrote: > > If the URL for template is wrong, or Postorius is down for whatever reason, > > the subscription will fail with the error that you saw before. > > Explain URL for template. You mean "POSTORIUS_TEMPLATE_BASE_URL"? That > is not wrong. I am confident of that. It is back to > "http://mailman-web:8000". I can successfully ping mailman-web:8000 > from bash. POSTORIUS_TEMPLATE_BASE_URL is used to create the template urls, yes. > > > > I logged out of Postorious and subscribed using the > > > subscribe form on > > > the info page and the change to the welcome template showed up. So it > > > looks like being logged in as admin while trying to subscribe someone > > > was what was causing the problem. Is that a bug I discovered? > > I suspect stopping-restarting and re-creating the template (idk, if you > > really did that) might have something to do with it. I am not sure if this > > is a bug unless you can reliably reproduce this. > > This error is absolutely reproducible. It even impacts other list > admins who are trying to use a custom welcome message and subscribing a > member while logged into Postorious. Everything else is working fine on > this server and I followed your directions precisely when I set this > server up. Please help. Can you reply here with the output of this query on your server: $ curl --user restadmin:restpass -L http://172.19.199.2:8001/3.1/lists/mailman-users.mailman3.org/uris Please replace "restadmin:restpass" with the username password of the rest api, if you have customized it. It not leave it as it because that it the default. Also, replace "mailman-users.mailman3.org" with the the List-ID of your mailing list. (replace @ with .) in your posting address. If you don't have curl, choose whatever http client you have. > > Thanks, > Brian > _______________________________________________ > 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

Re: Hyperkitty on Debian 12

by Michael Oberrauch

On Tue, 2024-03-26 at 08:06 +0100, Markus Grandpré wrote: > Dear Mr Sapiro, > > thank you very much for your help. The required command is: > > # mailman-web hyperkitty_import \ > -l mailman21-migration-test-04(a)mailman.uni-konstanz.de \ > /var/mailman21/testlist.mbox > > Due to the following warnings, I still have to customize Hyperkitty: > > django_mailman3.MailDomain: (models.W042) Auto-created primary key > used > when not defining a primary key type, by default > 'django.db.models.AutoField'. > HINT: Configure the DEFAULT_AUTO_FIELD setting or the > DjangoMailman3Config.default_auto_field attribute to point to a > subclass > of AutoField, e.g. 'django.db.models.BigAutoField'. > ... > > Can you give me another hint? As Linux admin I installed the packages > mailman and mailman-web that were offered to me under Debian 12. > Although during the installation of the packages user "list" was > created, I cannot use it: > > # su - list > This account is currently not available > > As with Mailman 2.1, I will probably have to continue working with > Mailman3 as root. Too bad that there is no documentation for Debian > admins like me, who don't want to dive too deep into the python > framework. Or have I overlooked something? > > Best regards, > Markus > > Hi Markus, we are also running MM3 on Debian 12 from Package Repositories. First of all, you should not try to directly switch user (su) to the lists user, it's generally intended to executes commands as that user, if necessary; either using `runuser`, `sudo`, or `su -c`. However, the prepackaged scripts `mailman-wrapper` and `mailman-web` already do this and therefore you ca run those as root without permission problems. On Debian there are two relevant users for MM3: the list user runs mailman core, whereas the www-data user runs Postorius and Hyperkitty. So you have to make shure, that the www-data user can access the .mbox files while importing. Hope that helps. Cheers, Michael -- Michael Oberrauch (er/ihm) Computerreferent Fachschaft Mathematik/Physik/Informatik/Chemie Studentische Vertretung Technische Universität München Boltzmannstraße 3 85748 Garching eMail: oberrauch(a)fs.tum.de Tel: (+49) 089 289 18545 Fax: (+49) 089 289 18546 https://mpic.fs.tum.de

1 year, 11 months

Mailman-users search results for query "Postorius"