Search results for "Postorius" - Mailman-users

Re: Link another address

by Quanah Gibson-Mount

--On Tuesday, May 19, 2020 1:13 AM +0000 Brian Carpenter <brian_carpenter(a)emwd.com> wrote: > I am thinking about incorporating the following Postorius/Django account > feature into Affinity: > > Other emails: (no other email) Link another address > > However I cannot think of a serious real-world need for this. What are > the developers' reasoning behind this? Was this feature highly demanded > by Mailman 3 users? Just trying to find out what I am missing here. Here's one use case: I've worked on an open source project for nearly 20 years. Over the course of those years, I've had a variety of different email addresses. The nice thing about being able to link all of them together under my single user ID is that I can find every email I've ever sent to the project lists, regardless of what my address was at the time. Regards, Quanah -- Quanah Gibson-Mount Product Architect Symas Corporation Packaged, certified, and supported LDAP solutions powered by OpenLDAP: <http://www.symas.com>

5 years, 7 months

Re: Error downloading CSV for 1,300 members

by Odhiambo Washington

An alternative is to just use the CLI to get the list. Afterall, all you need is the addresses, or no? On Thu, Feb 23, 2023, 21:46 Jose Bernal <jbernal.web.dev(a)gmail.com> wrote: > Any suggestions on troubleshooting downloading a modest-size CSV file for a > list with 1,300 members? Clicking "CSV Export" on smaller lists works > fine, but on this larger list I get this error in mailman-web.log: > > Thu Feb 23 10:03:32 2023 - uwsgi_response_write_body_do(): Broken pipe > [core/writer.c line 429] during GET /mailman3/postorius/lists/ > members.list.ocdla.org/csv_view/ (172.31.54.89) > OSError: write error > > > --------------------- > José Bernal > Web/Application Engineer > Cell 541-228-8481 > jbernal.web.dev(a)gmail.com > _______________________________________________ > 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 odhiambo(a)gmail.com >

2 years, 10 months

Re: Held messages showing a reason not in English on the Postorious

by Mark Sapiro

On 6/25/24 20:13, Alan KT So (ITSC) wrote: > We just notice a held message from a user's list showing the held reason in Ukrainian, but the interface is in US English and the list's preferred language is English (USA). We could not repeat the issue. What can be the reason behind? > > [cid:image001.png@01DAC7B9.AF2B0400] I'm assuming the image that content filtering removed was a screen shot of the held message view in Postorius. was the sender of the message a list member with preferred language Ukranian? There may be an issue here. The line at https://gitlab.com/mailman/mailman/-/blob/master/src/mailman/chains/hold.py… calls format_reasons which will translate the reasons in whatever the current language context is. It should probably explicitly specify the list's preferred language. -- Mark Sapiro <mark(a)msapiro.net> The highway is for gamblers, San Francisco Bay Area, California better use your sense - B. Dylan

1 year, 6 months

Re: Header settings and Gmail

by Mark Sapiro

On 7/29/24 12:25, erik(a)dante.de wrote: > > As a preventive measure, it helps to use DMARC mitigation action with “Replace From: with list address” and “ DMARC Mitigate unconditionally ”. But now some users are unhappy with the From header " Username via Test-liste <test(a)test-liste.org>". They would rather have their email address in it. If your Mailman core version is >=3.3.9 you can add `^.*(a)gmail\.com` to dmarc_addresses (DMARC addresses in Postorius) to apply the mitigation to gmail.com addresses instead of unconditionally, but this won't help your gmail users. > Is there a solution with which Google delivers the mailing list messages without complaining, but the sender email address is also in the “From:”? No. This is just one example of Google/gmail behaving oddly. gmail.com publishes a DMARC policy of none, yet they require incoming email From: the gmail.com domain to pass DMARC -- Mark Sapiro <mark(a)msapiro.net> The highway is for gamblers, San Francisco Bay Area, California better use your sense - B. Dylan

1 year, 5 months

Re: Mailman 3 localization

by Barry Warsaw

On Jun 16, 2017, at 11:04 PM, Danil Smirnov wrote: >Could you please be more specific - can I switch Mailman 3 installation to >Spanish? Unfortunately no. We've never gotten much traction for fully translating Mailman 3. We've had some interest but what we really need is a champion to drive the initiative. One of our biggest blockers is choosing a translation platform that's compatible with our free software constraints, but also requiring a minimal amount of ongoing infrastructure support from us. From there, we need help in bootstrapping the catalog templates, and defining the workflow for both developers and translators. This also has to support both source strings and templates in core, and integrate well with all the source text in the Django applications (HyperKitty and Postorius). It's a lot of work, but fame and fortune (or at least one of those <wink>) awaits those who persevere ;). Fortunately, much of the framework exists in core to extract source strings (marked by _() function wrappers), and to support translated templates. Cheers, -Barry

8 years, 7 months

Re: starting gunicorn per mailman.log yet gunicorn not installed

by Stephen J. Turnbull

Ken Alker writes: > I should have mentioned that I was installing "from source" in the > virtual environment (although it still seems to be package > management but just Python based instead of OS based as I'm not > compiling anything). Would your answer still apply in this > situation? Yes, it does. The list of dependent packages is in mailman/setup.py. Instead of downloading from a distro package repository, the packages are downloaded in the form of "wheels" from pypi.org (the Python Package Index). In mailmanweb, Postorius, HyperKitty, and django_mailman3 I believe the list is in requirements.txt. Distros almost never mess with these dependencies, with the single exception of gunicorn for the mailmanweb WSGI server. Distro-defined dependencies are primarily the external webserver (eg. Apache, nginx), the MTA (eg, Postfix, Exim4, Sendmail, qmail), and the relational database management system (eg, PostgreSQL, MySQL). Alternatives to gunicorn include uwsgi for nginx and Apache, and mod_wsgi for Apache. Steve

2 years, 6 months

Re: Spam from non list members

by Odhiambo Washington

On Tue, Aug 19, 2025 at 6:50 PM Sam Darwin via Mailman-users < mailman-users(a)mailman3.org> wrote: > You configured postfix/exim directly to do rspamd filtering, or you > configured mailman to do it? Exim does int in conjunction with rspamd. > If the latter case (mailman), is it possible that affects acceptance > logic? I have the settings almost matched between MM3 and rspamd. I made rspamd do a lot more checks and bump up scores. > What if you remove rspamd and spam detection from the pipeline? [ that is > mere speculation though ] > I believe I need to strengthen my rspamd to reject spam at SMTP time. > Have you installed the latest versions of mm3, postorius, hyperkitty? > Yes. Latest in virtualenv. -- 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]

4 months, 4 weeks

Re: Source Installation Assistance

by Brian Carpenter

The first thing is my server environment: Debian 10 Postgres for the database Nginx for the webserver I was able to create the virtual environment, install Mailman core and I have the Django installed and the project setup. I have Postorius and Hyperkitty setup. Everything is looking good. The problem I am having is when I am trying to migrate the data into the Postgres database. The migration process worked fine with SQLite but I decided to go with Postgres. Here is what I have in the settings.py for the database: DATABASES = { 'default': { 'ENGINE': 'django.db.backends.postgresql_psycopg2', 'NAME': '*************', 'USER': '**********', 'PASSWORD': '************', 'HOST': 'localhost', 'PORT': '', } When I run python manage.py migrate, I get the following exception: Applying hyperkitty.0007_allauth_20160808_1604...Traceback (most recent call last): File "/opt/mailman/mailman-web/mailman_venv/lib/python3.7/site-packages/django/db/backends/utils.py", line 82, in _execute return self.cursor.execute(sql) psycopg2.errors.InFailedSqlTransaction: current transaction is aborted, commands ignored until end of transaction block The above exception was the direct cause of the following exception: Traceback (most recent call last): File "manage.py", line 10, in <module> execute_from_command_line(sys.argv) File "/opt/mailman/mailman-web/mailman_venv/lib/python3.7/site-packages/django/core/management/__init__.py", line 381, in execute_from_command_line utility.execute() File "/opt/mailman/mailman-web/mailman_venv/lib/python3.7/site-packages/django/core/management/__init__.py", line 375, in execute self.fetch_command(subcommand).run_from_argv(self.argv) File "/opt/mailman/mailman-web/mailman_venv/lib/python3.7/site-packages/django/core/management/base.py", line 323, in run_from_argv self.execute(*args, **cmd_options) File "/opt/mailman/mailman-web/mailman_venv/lib/python3.7/site-packages/django/core/management/base.py", line 364, in execute output = self.handle(*args, **options) File "/opt/mailman/mailman-web/mailman_venv/lib/python3.7/site-packages/django/core/management/base.py", line 83, in wrapped res = handle_func(*args, **kwargs) File "/opt/mailman/mailman-web/mailman_venv/lib/python3.7/site-packages/django/core/management/commands/migrate.py", line 234, in handle fake_initial=fake_initial, File "/opt/mailman/mailman-web/mailman_venv/lib/python3.7/site-packages/django/db/migrations/executor.py", line 117, in migrate state = self._migrate_all_forwards(state, plan, full_plan, fake=fake, fake_initial=fake_initial) File "/opt/mailman/mailman-web/mailman_venv/lib/python3.7/site-packages/django/db/migrations/executor.py", line 147, in _migrate_all_forwards state = self.apply_migration(state, migration, fake=fake, fake_initial=fake_initial) File "/opt/mailman/mailman-web/mailman_venv/lib/python3.7/site-packages/django/db/migrations/executor.py", line 246, in apply_migration self.record_migration(migration) File "/opt/mailman/mailman-web/mailman_venv/lib/python3.7/site-packages/django/db/migrations/executor.py", line 261, in record_migration self.recorder.record_applied(migration.app_label, migration.name) File "/opt/mailman/mailman-web/mailman_venv/lib/python3.7/site-packages/django/db/migrations/recorder.py", line 82, in record_applied self.ensure_schema() File "/opt/mailman/mailman-web/mailman_venv/lib/python3.7/site-packages/django/db/migrations/recorder.py", line 62, in ensure_schema if self.has_table(): File "/opt/mailman/mailman-web/mailman_venv/lib/python3.7/site-packages/django/db/migrations/recorder.py", line 56, in has_table return self.Migration._meta.db_table in self.connection.introspection.table_names(self.connection.cursor()) File "/opt/mailman/mailman-web/mailman_venv/lib/python3.7/site-packages/django/db/backends/base/introspection.py", line 48, in table_names return get_names(cursor) File "/opt/mailman/mailman-web/mailman_venv/lib/python3.7/site-packages/django/db/backends/base/introspection.py", line 43, in get_names return sorted(ti.name for ti in self.get_table_list(cursor) File "/opt/mailman/mailman-web/mailman_venv/lib/python3.7/site-packages/django/db/backends/postgresql/introspection.py", line 52, in get_table_list """.format('c.relispartition' if self.connection.features.supports_table_partitions else 'FALSE')) File "/opt/mailman/mailman-web/mailman_venv/lib/python3.7/site-packages/django/db/backends/utils.py", line 99, in execute return super().execute(sql, params) File "/opt/mailman/mailman-web/mailman_venv/lib/python3.7/site-packages/django/db/backends/utils.py", line 67, in execute return self._execute_with_wrappers(sql, params, many=False, executor=self._execute) File "/opt/mailman/mailman-web/mailman_venv/lib/python3.7/site-packages/django/db/backends/utils.py", line 76, in _execute_with_wrappers return executor(sql, params, many, context) File "/opt/mailman/mailman-web/mailman_venv/lib/python3.7/site-packages/django/db/backends/utils.py", line 84, in _execute return self.cursor.execute(sql, params) File "/opt/mailman/mailman-web/mailman_venv/lib/python3.7/site-packages/django/db/utils.py", line 89, in __exit__ raise dj_exc_value.with_traceback(traceback) from exc_value File "/opt/mailman/mailman-web/mailman_venv/lib/python3.7/site-packages/django/db/backends/utils.py", line 82, in _execute return self.cursor.execute(sql) django.db.utils.InternalError: current transaction is aborted, commands ignored until end of transaction block So at this point I am stuck. Brian

6 years, 2 months

Re: Upgrading packages

by Eggert Ehmke

Am Donnerstag, 13. Oktober 2022, 19:09:20 CEST schrieb Mark Sapiro: > On 10/13/22 03:49, Eggert Ehmke wrote: > > pip install --upgrade git+https://gitlab.com/mailman/hyperkitty@master > > > > I noticed that mistune-2.0.0rc1 was upgraded to mistune-2.0.4. > > > > All packages were upgraded fine. I applied the patch to > > venv/lib/python3.9/site-packages/hyperkitty/lib/renderer.py > > It shouldn't have been necessary to apply any patch. The head of the > GitLab hyperkitty master branch is already compatible with mistune 2.0.4 strange, I still had the line with the (not working) from mistune.scanner import escape_html, escape_url maybe because the migration step was not working at that time? > I'm guessing at some point you installed something which required you to > manually make this migration and that produced this conflict. Do you > have both 0017_alter_emailtemplate_language.py and > 0017_auto_20220628_1132 in your postorius/migrations/ directory? If so, > probably just removing 0017_auto_20220628_1132 will fix this? That's what I did in the meantime, and it works now! Thank you.

3 years, 3 months

SOLVED (was: compress failed...)

by Guillermo Hernandez (Oldno7)

El 30/10/22 a las 12:22, Guillermo Hernandez (Oldno7) via Mailman-users escribió: > > El 28/10/22 a las 9:18, Guillermo Hernandez (Oldno7) via Mailman-users > escribió: >> >> El 27/10/22 a las 21:39, Mark Sapiro escribió: >>>> After that the compress part showed errors... but the postorius web >>>> maintenance was working well except for the CSRF error >>>> verification. I will trace the compress errors and will try to find >>>> the problem later. >>> >>> >>> Do you have `COMPRESS_ENABLED = True` in your settings? If that's >>> not the issue, it may be in the settings for COMPRESS_PRECOMPILERS >> >> While I'm tracing the problem out, this is the configuration I had >> working and the error it shows after upgrade: >> >> <------- snip of settings.py> >> >> # >> COMPRESS_PRECOMPILERS = ( >> ('text/less', 'lessc {infile} {outfile}'), >> ('text/x-scss', 'sassc -t compressed {infile} {outfile}'), >> ('text/x-sass', 'sassc -t compressed {infile} {outfile}'), >> ) >> # On a production setup, setting COMPRESS_OFFLINE to True will bring a >> # significant performance improvement, as CSS files will not need to be >> # recompiled on each requests. It means running an additional "compress" >> # management command after each code upgrade. >> # >> http://django-compressor.readthedocs.io/en/latest/usage/#offline-compression >> #### activo compresion 18/12/20 >> COMPRESS_OFFLINE = True >> ###COMPRESS_OFFLINE = False >> <---------- end snip> >> >> And below is the error it shows: >> >> /usr/local/mailman3 # su -m mailman3 -c "python3 manage.py compress" >> Traceback (most recent call last): >> File "/usr/local/mailman3/manage.py", line 10, in <module> >> execute_from_command_line(sys.argv) >> File >> "/usr/local/lib/python3.9/site-packages/django/core/management/__init__.py", >> line 446, in execute_from_command_line >> utility.execute() >> File >> "/usr/local/lib/python3.9/site-packages/django/core/management/__init__.py", >> line 440, in execute >> self.fetch_command(subcommand).run_from_argv(self.argv) >> File >> "/usr/local/lib/python3.9/site-packages/django/core/management/__init__.py", >> line 279, in fetch_command >> klass = load_command_class(app_name, subcommand) >> File >> "/usr/local/lib/python3.9/site-packages/django/core/management/__init__.py", >> line 49, in load_command_class >> return module.Command() >> File >> "/usr/local/lib/python3.9/site-packages/django/core/management/base.py", >> line 274, in __init__ >> raise TypeError("requires_system_checks must be a list or tuple.") >> TypeError: requires_system_checks must be a list or tuple. >> >> > After searching around, I've got a hint of what can be happening. It > seems a variable has changed in Django 4.1 its nature from boolean to > a tuple > > https://github.com/painless-software/django-probes/issues/24 > > I've upgraded another server with mailman3 lists, with the same config > listed above, and it shows the same error in the "compress" part. I'm > not sure where to set the requires_system_checks variable as in one of > the comments of the link, and as it doesn't seems to break anything > more, I will wait for more info before trying to avoid it. I'm sure it > will have some repercusion on the performance, but I'll have to live > with it. > > > Thanks again for your supporting advices. I did a pip install --upgrade --force-reinstall Django==4.0.8 downgrading Django from 4.1 and now a su -m mailman3 -c "python3 manage.py compress" worked without pain. > >> >> >> >> >> -- ___________________________________________ Mailman's content filtering has removed the following MIME parts from this message. Content-Type: image/png Name: firma-GHP-emails.png Replaced multipart/alternative part with first alternative.

3 years, 2 months

Mailman-users search results for query "Postorius"