Re: Hyperkitty using wrong email address in archive view
by Stephen J Turnbull
2023-05-16 17:42 に peter(a)chubb.wattle.id.au さんは書きました:
> I notice that for people with multiple email addresses, the email
> address that appears as the 'FROM' address in the hyperkitty
> archive is not the primary address, nor is it the address that the
> email actually came from, but the address that was created first.
> (Hyperkitty version 1.3.7)
I can't help with this. I don't understand why that would happen, maybe
Mark or Abhilash does. I would think that the address that would be
shown is the address in the email's From field.
> When I click on that from address in the archive view, I see all
> the email addresses for the user -- these do not match up with the
> ones in the django admin screen from .../admin/account/emailaddress/
They shouldn't, necessarily. The user's active emails will be
maintained by the user in Postorius, which what I believe appears in the
Django admin screen. However, HyperKitty needs to know *more*: in
general, it needs to know every address by which that user was
identified in the archives. This is valuable to the users of the
archives -- if they try to mail an author at a defunct address, they can
return to the profile to find an active one.
> How can I as administrator get rid of bogus addresses? Or do I
> have to ask each user to do this?
I believe Mark has a script for getting rid of garbage addresses that
have no root in user-visible data, but these are not garbage in that
sense: they do appear in the archives. However, since that script
refers only to the database, it would probably work for HyperKitty's
addresses too. But it might require code modifications, inasmuch as
there would be database errors if either the Address object doesn't
exist or the User link in the Address object is null.
> and how can I ensure that the email address displayed in the
> archive is the primary address, not some address that no longer
> works?
That's not necessarily your choice (I'm not speaking to your
installation, I'm talking about design principles). Remember that users
can associate specific addresses with specific lists, and you would be
overriding that preference ex post. (I have no problem with you
announcing a "real address only" rule in advance, of course.) Also,
there may be a reason why that address is defunct: stalkers, termination
of employment, etc. In those cases, the user may have a strong desire
not to contacted about the post in question. If you are in a
jurisdication that is under GDPR or other strong privacy legislation,
there may be legal implications you should consider. In general you
should consider whether possibly violating users' expectations in these
ways are appropriate to your site.
In general, Mailman 3's design philosophy is to give users fine control
of their user profiles and addresses and of their subscriptions'
configurations, while list owners get the traditional features for their
list configurations: control over access and default profiles, etc. So
I suspect there is no way to impose the restrictions you want without
writing new code. I don't have a particular objection to such features
as long as the policies are transparently documented (users don't have
to use those sites), but I'm not available to work on them for some
time.
--
University of Tsukuba Faculty of Policy and Planning
Sciences
Tennodai 1-1-1, Tsukuba 305-8573 JAPAN tel/fax:
+81-29-853-5091
turnbull(a)sk.tsukuba.ac.jp
https://turnbull.sk.tsukuba.ac.jp/
3 years, 5 months
E-mail every minute: "Cron <www-data@sharky5> ..."
by Robert Heller
What am I missing? I *think* I have mailman3 *mostly* setup, but there are
still some configuration things that are missing, but I am not sure how to fix
them (the docs are NOT clear). I am getting an e-mail *every* minute that
looks like:
From www-data(a)deepsoft.com Sat Jul 6 17:38:03 2024
Return-Path: <www-data(a)deepsoft.com>
X-Spam-Checker-Version: SpamAssassin 4.0.0 (2022-12-13) on sharky5.deepsoft.com
X-Spam-Level:
X-Spam-Status: No, score=-850.0 required=5.0 tests�YES_00,DKIM_SIGNED,
DKIM_VALID,DKIM_VALID_AU,DKIM_VALID_EF,NO_RELAYS,URIBL_BLOCKED,
USER_IN_WELCOMELIST autolearn=ham autolearn_force=no version=4.0.0
X-Original-To: www-data
Delivered-To: www-data(a)deepsoft.com
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d�epsoft.com;
s�epsoft.com; t20301883;
bh=qGrVTBfV1NiqgxCIzSaXwoKZ0lKxKvaK56k31yXU2Sk=;
h=From:To:Subject:Date:From;
b=jTml1ZF+qGkmS2tcz5kgZHjOyPxeaWIQiX1mzAF3ZfZWb0ziVLxutkcej5mGapUOq
PpH6ExYM1TEipMTYQ/JRY/74vz2dEpebDrZqjyY3KakxLWiyFFEb5glmQYZGvz9wr2
e5ljD0Shku4fbRoaxO7XMQCn/fmx3+D8tI/ZPbMQReceived: by sharky5.deepsoft.com (Postfix, from userid 33)
id 5257D4C1296; Sat, 6 Jul 2024 17:38:03 -0400 (EDT)
From: root(a)deepsoft.com (Cron Daemon)
To: www-data(a)deepsoft.com
Subject: Cron <www-data@sharky5> [ -f /usr/bin/django-admin ] && flock -n /var/run/mailman3-web/cron.minutely /usr/share/mailman3-web/manage.py runjobs minutely
MIME-Version: 1.0
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: 8bit
X-Cron-Env: <SHELL=/bin/sh>
X-Cron-Env: <HOME=/var/www>
X-Cron-Env: <PATH=/usr/bin:/bin>
X-Cron-Env: <LOGNAME=www-data>
Message-Id: <20240706213803.5257D4C1296(a)sharky5.deepsoft.com>
Date: Sat, 6 Jul 2024 17:38:03 -0400 (EDT)
X-Scanned-By: MIMEDefang 3.3 on 108.161.129.198
Status: R
/usr/lib/python3/dist-packages/django_q/conf.py:139: UserWarning: Retry and timeout are misconfigured. Set retry larger than timeout,
failure to do so will cause the tasks to be retriggered before completion.
See https://django-q.readthedocs.io/en/latest/configure.html#retry for details.
warn(
System check identified some issues:
WARNINGS:
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'.
django_mailman3.Profile: (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'.
hyperkitty.Attachment: (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 HyperKittyConfig.default_auto_field attribute to point to a subclass of AutoField, e.g. 'django.db.models.BigAutoField'.
hyperkitty.Email: (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 HyperKittyConfig.default_auto_field attribute to point to a subclass of AutoField, e.g. 'django.db.models.BigAutoField'.
hyperkitty.Favorite: (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 HyperKittyConfig.default_auto_field attribute to point to a subclass of AutoField, e.g. 'django.db.models.BigAutoField'.
hyperkitty.LastView: (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 HyperKittyConfig.default_auto_field attribute to point to a subclass of AutoField, e.g. 'django.db.models.BigAutoField'.
hyperkitty.MailingList: (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 HyperKittyConfig.default_auto_field attribute to point to a subclass of AutoField, e.g. 'django.db.models.BigAutoField'.
hyperkitty.Profile: (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 HyperKittyConfig.default_auto_field attribute to point to a subclass of AutoField, e.g. 'django.db.models.BigAutoField'.
hyperkitty.Tag: (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 HyperKittyConfig.default_auto_field attribute to point to a subclass of AutoField, e.g. 'django.db.models.BigAutoField'.
hyperkitty.Tagging: (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 HyperKittyConfig.default_auto_field attribute to point to a subclass of AutoField, e.g. 'django.db.models.BigAutoField'.
hyperkitty.Thread: (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 HyperKittyConfig.default_auto_field attribute to point to a subclass of AutoField, e.g. 'django.db.models.BigAutoField'.
hyperkitty.ThreadCategory: (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 HyperKittyConfig.default_auto_field attribute to point to a subclass of AutoField, e.g. 'django.db.models.BigAutoField'.
hyperkitty.Vote: (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 HyperKittyConfig.default_auto_field attribute to point to a subclass of AutoField, e.g. 'django.db.models.BigAutoField'.
postorius.EmailTemplate: (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 PostoriusConfig.default_auto_field attribute to point to a subclass of AutoField, e.g. 'django.db.models.BigAutoField'.
And I get this output from sudo mailman-web check --no-color :
System check identified some issues:
WARNINGS:
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'.
django_mailman3.Profile: (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'.
hyperkitty.Attachment: (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 HyperKittyConfig.default_auto_field attribute to point to a subclass of AutoField, e.g. 'django.db.models.BigAutoField'.
hyperkitty.Email: (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 HyperKittyConfig.default_auto_field attribute to point to a subclass of AutoField, e.g. 'django.db.models.BigAutoField'.
hyperkitty.Favorite: (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 HyperKittyConfig.default_auto_field attribute to point to a subclass of AutoField, e.g. 'django.db.models.BigAutoField'.
hyperkitty.LastView: (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 HyperKittyConfig.default_auto_field attribute to point to a subclass of AutoField, e.g. 'django.db.models.BigAutoField'.
hyperkitty.MailingList: (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 HyperKittyConfig.default_auto_field attribute to point to a subclass of AutoField, e.g. 'django.db.models.BigAutoField'.
hyperkitty.Profile: (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 HyperKittyConfig.default_auto_field attribute to point to a subclass of AutoField, e.g. 'django.db.models.BigAutoField'.
hyperkitty.Tag: (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 HyperKittyConfig.default_auto_field attribute to point to a subclass of AutoField, e.g. 'django.db.models.BigAutoField'.
hyperkitty.Tagging: (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 HyperKittyConfig.default_auto_field attribute to point to a subclass of AutoField, e.g. 'django.db.models.BigAutoField'.
hyperkitty.Thread: (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 HyperKittyConfig.default_auto_field attribute to point to a subclass of AutoField, e.g. 'django.db.models.BigAutoField'.
hyperkitty.ThreadCategory: (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 HyperKittyConfig.default_auto_field attribute to point to a subclass of AutoField, e.g. 'django.db.models.BigAutoField'.
hyperkitty.Vote: (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 HyperKittyConfig.default_auto_field attribute to point to a subclass of AutoField, e.g. 'django.db.models.BigAutoField'.
postorius.EmailTemplate: (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 PostoriusConfig.default_auto_field attribute to point to a subclass of AutoField, e.g. 'django.db.models.BigAutoField'.
System check identified 14 issues (0 silenced).
Again, the docs are not helpful (at least not to me).
--
Robert Heller -- Cell: 413-658-7953 GV: 978-633-5364
Deepwoods Software -- Custom Software Services
http://www.deepsoft.com/ -- Linux Administration Services
heller(a)deepsoft.com -- Webhosting Services
2 years, 3 months
Re: New year releases!
by Dan Caballero
Thanks Mark. The migration completes after I updated the curls.py file.
I do see some warnings...
"WARNINGS:
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'.
django_mailman3.Profile: (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'.
hyperkitty.Attachment: (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 HyperKittyConfig.default_auto_field attribute to point to a subclass of AutoField, e.g. 'django.db.models.BigAutoField'.
hyperkitty.Email: (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 HyperKittyConfig.default_auto_field attribute to point to a subclass of AutoField, e.g. 'django.db.models.BigAutoField'.
hyperkitty.Favorite: (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 HyperKittyConfig.default_auto_field attribute to point to a subclass of AutoField, e.g. 'django.db.models.BigAutoField'.
hyperkitty.LastView: (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 HyperKittyConfig.default_auto_field attribute to point to a subclass of AutoField, e.g. 'django.db.models.BigAutoField'.
hyperkitty.MailingList: (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 HyperKittyConfig.default_auto_field attribute to point to a subclass of AutoField, e.g. 'django.db.models.BigAutoField'.
hyperkitty.Profile: (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 HyperKittyConfig.default_auto_field attribute to point to a subclass of AutoField, e.g. 'django.db.models.BigAutoField'.
hyperkitty.Tag: (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 HyperKittyConfig.default_auto_field attribute to point to a subclass of AutoField, e.g. 'django.db.models.BigAutoField'.
hyperkitty.Tagging: (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 HyperKittyConfig.default_auto_field attribute to point to a subclass of AutoField, e.g. 'django.db.models.BigAutoField'.
hyperkitty.Thread: (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 HyperKittyConfig.default_auto_field attribute to point to a subclass of AutoField, e.g. 'django.db.models.BigAutoField'.
hyperkitty.ThreadCategory: (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 HyperKittyConfig.default_auto_field attribute to point to a subclass of AutoField, e.g. 'django.db.models.BigAutoField'.
hyperkitty.Vote: (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 HyperKittyConfig.default_auto_field attribute to point to a subclass of AutoField, e.g. 'django.db.models.BigAutoField'.
postorius.EmailTemplate: (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 PostoriusConfig.default_auto_field attribute to point to a subclass of AutoField, e.g. 'django.db.models.BigAutoField'."
3 years, 9 months
Re: Archiving error
by Enrique Terrazas
Excellent! Thanks again for your guidance.
I have a follow up question, I tried setting the base_url to https but received SSL errors in the mailman.log. The nginx.conf is using a valid certificate from a CA and the sites(Django admin, Postorius, Hyperkitty) all load with https in the browser, they are redirected from http as well. But it seems that internal communication is failing when I try to specify https in the base_url
Is this something that I should be concerned about and can be configured?
Thank you,
Enrique
On Oct 5, 2018, at 11:25 AM, Abhilash Raj <maxking(a)asynchronous.in<mailto:maxking@asynchronous.in>> wrote:
On Fri, Oct 5, 2018, at 8:25 AM, Enrique Terrazas wrote:
Thank you Abhilash,
The port was in fact the problem. Django is listening on a different port as specified in my uwsgi.ini file
To be sure I understand this correctly:
In uwsgi.ini I am specifying:
http-socket = my.host.name:8000
And in hyperkitty.cfg:
base_url: http://my.host.name:8000/hyperkitty/<https://na01.safelinks.protection.outlook.com/?url=http%3A%2F%2Fmy.host.nam…>
That is the correct thing to do!
thanks,
Abhilash
Hyperkitty is now archiving messages as expected.
Best regards,
Enrique
On Oct 5, 2018, at 9:57 AM, Abhilash Raj <maxking(a)asynchronous.in<mailto:maxking@asynchronous.in>> wrote:
On Fri, Oct 5, 2018, at 12:06 AM, Enrique Terrazas wrote:
Hello,
I'm hoping someone can help me configure hyperkitty correctly. I've got
mailman3 installed and working. I created a test list and can send/
receive, moderate message. However, archiving does not seem to be
working. Below is a copy of my (sanitized) hyperkitty.cfg file and
settings.py file(edited) along with the errors being logged to
mailman.log
hyperkitty.cfg
-----
# Mailman-Hyperkitty Archiver plugin
[general]
base_url: http://localhost:8002/
Which PORT is your Django listening on? This seems like pointing to 8002 port, are you actually listening on that port?
The error below seems to suggest that either the Django isn't running or you are using wrong address.
api_key:
-----
settings.py
# Mailman API credentials
MAILMAN_REST_API_URL = 'http://localhost:8001<http://localhost:8001/>'
MAILMAN_REST_API_USER = ''
MAILMAN_REST_API_PASS = ''
MAILMAN_ARCHIVER_KEY = ''
MAILMAN_ARCHIVER_FROM = ('my.host.name', 'myIPaddress', '127.0.0.1', '::
1')
------
This is the error being sent to maillog.log
------
Oct 05 01:54:59 2018 (15127) Exception in "hyperkitty" archiver
Traceback (most recent call last):
File "/opt/mailman/mailman/lib64/python3.6/site-packages/urllib3/
connection.py", line 171, in _new_
conn
(self._dns_host, self.port), self.timeout, **extra_kw)
File "/opt/mailman/mailman/lib64/python3.6/site-packages/urllib3/util/
connection.py", line 79, in c
reate_connection
raise err
File "/opt/mailman/mailman/lib64/python3.6/site-packages/urllib3/util/
connection.py", line 69, in c
reate_connection
sock.connect(sa)
ConnectionRefusedError: [Errno 111] Connection refused
During handling of the above exception, another exception occurred:
Traceback (most recent call last):
File "/opt/mailman/mailman/lib64/python3.6/site-packages/urllib3/
connectionpool.py", line 600, in urlopen
chunked=chunked)
File "/opt/mailman/mailman/lib64/python3.6/site-packages/urllib3/
connectionpool.py", line 354, in _make_request
conn.request(method, url, **httplib_request_kw)
File "/opt/rh/rh-python36/root/usr/lib64/python3.6/http/client.py",
line 1239, in request
self._send_request(method, url, body, headers, encode_chunked)
File "/opt/rh/rh-python36/root/usr/lib64/python3.6/http/client.py",
line 1285, in _send_request
self.endheaders(body, encode_chunked=encode_chunked)
File "/opt/rh/rh-python36/root/usr/lib64/python3.6/http/client.py",
line 1234, in endheaders
self._send_output(message_body, encode_chunked=encode_chunked)
File "/opt/rh/rh-python36/root/usr/lib64/python3.6/http/client.py",
line 1026, in _send_output
self.send(msg)
File "/opt/rh/rh-python36/root/usr/lib64/python3.6/http/client.py",
line 964, in send
self.connect()
File "/opt/mailman/mailman/lib64/python3.6/site-packages/urllib3/
connection.py", line 196, in connect
conn = self._new_conn()
File "/opt/mailman/mailman/lib64/python3.6/site-packages/urllib3/
connection.py", line 180, in _new_conn
self, "Failed to establish a new connection: %s" % e)
urllib3.exceptions.NewConnectionError:
<urllib3.connection.HTTPConnection object at 0x7f0ba1c22048>: Failed to
establish a new connection: [Errno 111] Connection refused
During handling of the above exception, another exception occurred:
------
Thanks in advance,
Enrique J. Terrazas
_______________________________________________
Mailman-users mailing list -- mailman-users(a)mailman3.org<mailto:mailman-users@mailman3.org>
To unsubscribe send an email to mailman-users-leave(a)mailman3.org<mailto:mailman-users-leave@mailman3.org>
https://na01.safelinks.protection.outlook.com/?url=https%3A%2F%2Flists.mail…<https://na01.safelinks.protection.outlook.com/?url=https%3A%2F%2Flists.mail…>
--
thanks,
Abhilash Raj (maxking)
--
thanks,
Abhilash Raj (maxking)
8 years
Re: Weird response to postings after subscriptions and accounts
by Mark Sapiro
On 9/16/19 9:22 PM, Paul Arenson wrote:
> In my test of the two forms of signup, I am getting these unexpected results. Is it my settings or is something weird within the program itself?
>
> 1) https://list.tokyoprogressive.org/postorius/lists/discuss.list.tokyoprogres…
>
> 2) Choose "You can also subscribe without creating an account. If you wish to do so, please use the form below"
>
> 3) Then I have to approve it. They get "Welcome to the "Discuss" mailing list! To post to this list, send your email to: discuss(a)list.tokyoprogressive.org
You have to approve it or the user has to confirm her email address?
Maybe you have to approve it because the lists Subscription Policy is
Moderate.
> 4) But I have to approve it.I assume this is because they do not yet have a real account. And they should be listed as a NON MEMBER?
No. They will be a member, they just will not have a Django account that
they can log in to.
> 5) But even when they sign up here: https://list.tokyoprogressive.org/accounts/signup/?next=%2Fpostorius%2Flist… they get an email from my provider (NOT MY LIST????) as follows:
>
> "Hello from mailman3.emwd.com! You're receiving this e-mail because user iCloud has given yours as an e-mail address to connect their account.
> To confirm this is correct, go to https://list.tokyoprogressive.org/accounts/confirm-email/MTE3:1iA44k:E7w7xh… Thank you from mailman3.emwd.com! mailman3.emwd.com"
Because when you create a Django account, you have to confirm your email
address.
> 6) And this is where it gets weird. If they send from their email program and get the welcome (Welcome to the "Discuss" mailing list!
> To post to this list, send your email to: discuss(a)list.tokyoprogressive.org You can unsubscribe or make adjustments to your options via email by
> sending a message to....... I then get a notice:
>
> "Your mail to 'discuss(a)list.tokyoprogressive.org' with the subject test notice Is being held until the list moderator can review it for approval. The message is being held because: The message is not from a list member"
What is Message Acceptance -> Default action to take when a member posts
to the list ?
You get the notice or the user gets the notice?
> 7) While if they send FROM THE interface it goes through.
>
> 8) What I am confused about.
>
> Signing up for an account should make them a member, right? Subscribing should make them a non member, no?
Signing up for an account is just signing up for a Django account. You
can sign up for an account and log in and then subscribe to the list.
Subscribing makes one a member whether or not you subscribe from a
logged in account or subscribe without creating an account.
> But here it seems that both make them a non member.
If an address which is not a member posts to the list, that address
becomes a non-member. This is the only way other than being explicitly
added by an admin that an address becomes a non-member.
> And worse, someone with an account sending from the Interface has their message get through while the same person sending from an email program has me get a notice that a non member is trying to post.
If by sending from the interface, you mean posting via hyperkitty, the
user must have an account and be logged in to do that.
Your "same person" may have multiple entities within Mailman, possibly
subtly different email addresses, one of which is a member and one of
which isn't.
--
Mark Sapiro <mark(a)msapiro.net> The highway is for gamblers,
San Francisco Bay Area, California better use your sense - B. Dylan
7 years, 1 month
Re: Bulk changes to delivery mode and moderation action
by David Newman
On 1/7/22 12:06 PM, Mark Sapiro wrote:
> On 1/7/22 11:06 AM, David Newman wrote:
>>
>> 1. In Users/Members, moderation action for the newly resubscribed
>> users shows as "None". Is there a method, either in the UI or the
>> command line, to change this to "Default processing" for all users?
>
>
> I assume you don't want to set `Default action to take when a member
> posts to the list` to Default Processing because you want new member
> posts to be held. This is a good practice. To set all members to default
> processing in mailman shell
..
OK, thanks
>> 2. Although Delivery Mode shows as "Regular" for all users in
>> Users/Members list, clicking on a member's name shows all options such
>> as delivery status, delivery mode, etc., as undefined.
>
>
> They show as undefined, but if you look at your own settings by
> selecting `Mailman settings` from the dropdown under your username at
> the upper right in Postorius, you will see you have Global Mailman
> preferences, Address-based preferences and List-based preferences. If a
> list based preference is unset for a list, it falls back to the address
> based preference for the address and if that's unset, to the global
> preference.
>
> When you as an admin look at a user, you only see the user's list based
> preferences.
Thanks. This makes sense, but something's wrong with this particular list.
I was able to change preferences using the shell commands you kindly
provided. All list member now have regular delivery and default moderation.
However, there's no evidence test messages to the list are going out.
(Nondelivery was the reason I was mucking around in the admin panel in
the first place.)
The Postfix log shows delivery to the list address.
MM3's smtp.log shows the usual handshake.
However, I do not then see messages going out to subscribers in the
Postfix log, and as one of those subscribers I do not receive a copy
even though my preferences are set to receive my own posts.
The admin panel shows 0 messages held for moderation.
Another mailing list in the same domain on the same server delivers mail
to all subscribers OK.
This is surely config problem on my end, but which log(s) and/or admin
panel setting(s) to check?
Thanks again.
dn
>
>> Similar question: How to set subscriber options for all members in one
>> go?
>
>
> Per the above, you only need to set the user's preferences if they don't
> have address based preferences and the preference differs from the
> global (default) preferences.
>
> However, if you want to set the member's list preferences, you could add
> to the beginning of the above:
> ```
> >>> from mailman.interfaces.member import DeliveryMode, DeliveryStatus
> >>> english = getUtility(ILanguageManager).get('en')
> ```
> and to the `for` loop in the above:
> ```
> ... mbr.preferences.acknowledge_posts = False
> ... mbr.preferences.delivery_mode = DeliveryMode.regular
> ... mbr.preferences.delivery_status = DeliveryStatus.enabled
> ... mbr.preferences.hide_address = False
> ... mbr.preferences.preferred_language = english
> ... mbr.preferences.receive_list_copy = False
> ... mbr.preferences.receive_own_postings = True
> ```
> Or whatever you think these settings should be.
>
>> 3. As a subscriber to this list, I received email notification that
>> I'd been unsubscribed. Where is the control for enabling/disabling
>> subscription notifications?
>
>
> Settings -> Automatic Responses
>
>
>> Settings/Member Policy/Un-subscription Policy is set to Confirm, but I
>> don't think that's relevant here since I unsubscribed users as the
>> Django superuser.
>
>
> Correct.
>
4 years, 9 months
Re: Mass operations on large list - Internal Server Error
by Liam Reilly
Liam Reilly wrote:
> Stephen J. Turnbull wrote:
> > Here is an example error from the log for unsubscribe all
> > operation.
> > Which log is this? I would guess it's the mailmanweb.log.
> > [2025-12-15 15:41:02 +0000] [1022464] [ERROR] Error handling request /mailman3/lists/uclucu-members.ucl.ac.uk/unsubscribe_all
> > Traceback (most recent call last):
> > File "/data/mailman/venv/lib64/python3.12/site-packages/gunicorn/workers/sync.py", line 134, in handle
> > self.handle_request(listener, req, client, addr)
> > This is the front-end gunicorn WSGI server, handling a request for
> > Postorius.
> > File "/data/mailman/venv/lib64/python3.12/site-packages/mailmanclient/restobjects/mailinglist.py", line 519, in unsubscribe
> > response, json = self._connection.call(path, data, method='DELETE')
> > ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
> > This is mailman client translating to the REST API.
> > File "/usr/lib64/python3.12/socket.py", line 720, in readinto
> > return self._sock.recv_into(b)
> > ^^^^^^^^^^^^^^^^^^^^^^^
> > This is the Python socket library actually talking to the REST API of
> > Mailman core. An unspecified error occurs in the C code. It is not
> > handled.
> > File "/data/mailman/venv/lib64/python3.12/site-packages/gunicorn/workers/base.py", line 204, in handle_abort
> > sys.exit(1)
> > SystemExit: 1
> > This is the "Something's wrong, hope you have a clue 'cause I don't"
> > last line of defense error handler.
> > My guess is that it's a timeout on a socket.
> > I think you should also see log messages and a traceback in the
> > mailman.log.
> > The timeout for the mailmanweb gunicorn is configured in the gunicorn
> > conf file, usually in /etc/mailman3. This is relatively short (I
> > Reilly, Liam writes:
> > think my installation is default at 120 seconds).
> > The timeout for the REST API gunicorn is in
> > site-packages/mailman/config/gunicorn.cfg. This is long (360 seconds)
> > so if my conjecture about timeout is correct it's the mailmanweb
> > gunicorn that's timing out. If you need to change this one, you may
> > be able to simply put "timeout: 360" in the [webservice] section of
> > your mailman.cfg file, but if that doesn't work you can copy
> > gunicorn.cfg to /etc/mailman3/rest-wsgi.cfg, change the timeout in it,
> > and add "configuration: /etc/mailman3/rest-wsgi.cfg" to the
> > [webservice] section of mailman.cfg.
> > GNU Mailman consultant (installation, migration, customization)
> > Sirius Open Source https://www.siriusopensource.com/
> > Software systems consulting in Europe, North America, and Japan
> > As always, thank you for your prompt replies Stephen.
> The entries are from error.log and are all I could find when grepping for the list name. I'll check the other logs for anything else and also try increasing the timeout config as you've suggested to see if it helps.
After some experimentation, I think I've got a working configuration.
Setting the timeout in /etc/mailman3/rest-wsgi.cfg did not seem to work properly. In the end I had to modify the systemd unit file for mailmanweb, adding a --timeout to the ExecStart line:
ExecStart=/opt/mailman/venv/bin/gunicorn -c /opt/mailman/mm/gunicorn.conf.py --timeout 360 mailman_web.wsgi:application
Mass operations now failed with a different "proxy error" after 60s instead of "internal server error" after 30s.
I then added "ProxyTimeout 300" to /etc/httpd/conf.d/mailman3.conf to increase that timeout.
Testing this I can now mass subscribe 4500 members in ~100s and mass remove them again in ~150s without any errors.
I wonder if there's any way to reduce the time it takes to process such operations? More workers? I have been testing with 4 webservice workers.
10 months
Re: New releases
by brylon＠oit.rutgers.edu
Hi all --
I'm stuck on this "compress" issue after upgrading and not sure how to remedy?
After upgrading the Mailman components (core, postorius, hyperkitty) on my test server to the latest available in my venv I ran the following:
$ ./bin/django-admin collectstatic --clear --noinput --verbosity 0
and then
$ ./bin/django-admin compress --trace
Compressing... Traceback (most recent call last):
File "/opt/mailman/mm/venv/lib/python3.6/site-packages/compressor/base.py", line 282, in precompile
mod = import_module(mod_name)
File "/opt/mailman/mm/venv/lib64/python3.6/importlib/__init__.py", line 126, in import_module
return _bootstrap._gcd_import(name[level:], package, level)
File "<frozen importlib._bootstrap>", line 994, in _gcd_import
File "<frozen importlib._bootstrap>", line 971, in _find_and_load
File "<frozen importlib._bootstrap>", line 953, in _find_and_load_unlocked
ModuleNotFoundError: No module named 'sass -t compressed {infile} {outfile}'
During handling of the above exception, another exception occurred:
Traceback (most recent call last):
File "/opt/mailman/mm/venv/lib/python3.6/site-packages/compressor/management/commands/compress.py", line 232, in compress
result = parser.render_node(template, context, node)
File "/opt/mailman/mm/venv/lib/python3.6/site-packages/compressor/offline/django.py", line 117, in render_node
return node.render(context, forced=True)
File "/opt/mailman/mm/venv/lib/python3.6/site-packages/compressor/templatetags/compress.py", line 143, in render
return self.render_compressed(context, self.kind, self.mode, forced=forced)
File "/opt/mailman/mm/venv/lib/python3.6/site-packages/compressor/templatetags/compress.py", line 119, in render_compressed
rendered_output = compressor.output(mode, forced=forced, basename=file_basename)
File "/opt/mailman/mm/venv/lib/python3.6/site-packages/compressor/css.py", line 46, in output
ret.append(subnode.output(*args, **kwargs))
File "/opt/mailman/mm/venv/lib/python3.6/site-packages/compressor/css.py", line 48, in output
return super(CssCompressor, self).output(*args, **kwargs)
File "/opt/mailman/mm/venv/lib/python3.6/site-packages/compressor/base.py", line 314, in output
output = '\n'.join(self.filter_input(forced))
File "/opt/mailman/mm/venv/lib/python3.6/site-packages/compressor/base.py", line 254, in filter_input
for hunk in self.hunks(forced):
File "/opt/mailman/mm/venv/lib/python3.6/site-packages/compressor/base.py", line 228, in hunks
precompiled, value = self.precompile(value, **options)
File "/opt/mailman/mm/venv/lib/python3.6/site-packages/compressor/base.py", line 287, in precompile
return True, filter.input(**kwargs)
File "/opt/mailman/mm/venv/lib/python3.6/site-packages/compressor/filters/base.py", line 239, in input
return super(CachedCompilerFilter, self).input(**kwargs)
File "/opt/mailman/mm/venv/lib/python3.6/site-packages/compressor/filters/base.py", line 206, in input
raise FilterError(err)
compressor.exceptions.FilterError: Error: Invalid CSS after "...lor}: #{$value}": expected "{", was ";"
on line 4 of /opt/mailman/mm/venv/lib/python3.6/site-packages/hyperkitty/static/hyperkitty/libs/bootstrap/stylesheets/_root.scss
from line 11 of /opt/mailman/mm/venv/lib/python3.6/site-packages/hyperkitty/static/hyperkitty/libs/bootstrap/stylesheets/bootstrap.scss
from line 4 of /opt/mailman/mm/venv/lib/python3.6/site-packages/hyperkitty/static/hyperkitty/sass/hyperkitty.scss
Use --trace for backtrace.
During handling of the above exception, another exception occurred:
Traceback (most recent call last):
File "/opt/mailman/mm/venv/bin/django-admin", line 8, in <module>
sys.exit(execute_from_command_line())
File "/opt/mailman/mm/venv/lib/python3.6/site-packages/django/core/management/__init__.py", line 381, in execute_from_command_line
utility.execute()
File "/opt/mailman/mm/venv/lib/python3.6/site-packages/django/core/management/__init__.py", line 375, in execute
self.fetch_command(subcommand).run_from_argv(self.argv)
File "/opt/mailman/mm/venv/lib/python3.6/site-packages/django/core/management/base.py", line 323, in run_from_argv
self.execute(*args, **cmd_options)
File "/opt/mailman/mm/venv/lib/python3.6/site-packages/django/core/management/base.py", line 364, in execute
output = self.handle(*args, **options)
File "/opt/mailman/mm/venv/lib/python3.6/site-packages/compressor/management/commands/compress.py", line 277, in handle
self.handle_inner(**options)
File "/opt/mailman/mm/venv/lib/python3.6/site-packages/compressor/management/commands/compress.py", line 300, in handle_inner
offline_manifest, block_count, results = self.compress(engine, extensions, verbosity, follow_links, log)
File "/opt/mailman/mm/venv/lib/python3.6/site-packages/compressor/management/commands/compress.py", line 235, in compress
"%s" % (template.template_name, smart_text(e)))
django.core.management.base.CommandError: An error occurred during rendering /opt/mailman/mm/venv/lib/python3.6/site-packages/django_mailman3/templates/socialaccount/connections.html: Error: Invalid CSS after "...lor}: #{$value}": expected "{", was ";"
on line 4 of /opt/mailman/mm/venv/lib/python3.6/site-packages/hyperkitty/static/hyperkitty/libs/bootstrap/stylesheets/_root.scss
from line 11 of /opt/mailman/mm/venv/lib/python3.6/site-packages/hyperkitty/static/hyperkitty/libs/bootstrap/stylesheets/bootstrap.scss
from line 4 of /opt/mailman/mm/venv/lib/python3.6/site-packages/hyperkitty/static/hyperkitty/sass/hyperkitty.scss
Use --trace for backtrace.
Any suggestions? The fixes described in this thread don't seem to be working for my case?
6 years, 1 month
Re: Migrating mailman3 to latest ubuntu lts
by Helio Loureiro
Hi,
Indeed it was the configuration. It was placed into
/etc/mailman3/mailman-web.py. After a I changed to
/etc/mailman3/settings.py a few things advanced a little bit more.
I had to figure out how to fix mysqlclient installation since there isn't a
mention about it and the simple "pip install mysqclient" was breaking with
pkg-config issues. But it did work at the end.
Now I can see further messages on mailman3-web than before.
(venv) mailman@new-server ~ (v3.3.9)> mailman-web migrate
System check identified some issues:
WARNINGS:
account.EmailAddress: (models.W036) MariaDB does not support unique
constraints with conditions.
HINT: A constraint won't be created. Silence this warning if you don't care
about it.
account.EmailAddress: (models.W043) MariaDB does not support indexes on
expressions.
HINT: An index won't be created. Silence this warning if you don't care
about it.
Operations to perform:
Apply all migrations: account, admin, auth, contenttypes,
django_mailman3, django_q, hyperkitty, postorius, sessions, sites,
socialaccount
Running migrations:
Applying account.0004_alter_emailaddress_drop_unique_email...Traceback
(most recent call last):
File
"/local/mailman/venv/lib/python3.10/site-packages/django/db/backends/utils.py",
line 89, in _execute
return self.cursor.execute(sql, params)
File
"/local/mailman/venv/lib/python3.10/site-packages/django/db/backends/mysql/base.py",
line 75, in execute
return self.cursor.execute(query, args)
File
"/local/mailman/venv/lib/python3.10/site-packages/MySQLdb/cursors.py", line
179, in execute
res = self._query(mogrified_query)
File
"/local/mailman/venv/lib/python3.10/site-packages/MySQLdb/cursors.py", line
330, in _query
db.query(q)
File
"/local/mailman/venv/lib/python3.10/site-packages/MySQLdb/connections.py",
line 257, in query
_mysql.connection.query(self, query)
MySQLdb.OperationalError: (2013, 'Lost connection to MySQL server during
query')
The above exception was the direct cause of the following exception:
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/base.py",
line 96, in wrapped
res = handle_func(*args, **kwargs)
File
"/local/mailman/venv/lib/python3.10/site-packages/django/core/management/commands/migrate.py",
line 349, in handle
post_migrate_state = executor.migrate(
File
"/local/mailman/venv/lib/python3.10/site-packages/django/db/migrations/executor.py",
line 135, in migrate
state = self._migrate_all_forwards(
File
"/local/mailman/venv/lib/python3.10/site-packages/django/db/migrations/executor.py",
line 167, in _migrate_all_forwards
state = self.apply_migration(
File
"/local/mailman/venv/lib/python3.10/site-packages/django/db/migrations/executor.py",
line 252, in apply_migration
state = migration.apply(state, schema_editor)
File
"/local/mailman/venv/lib/python3.10/site-packages/django/db/migrations/migration.py",
line 130, in apply
operation.database_forwards(
File
"/local/mailman/venv/lib/python3.10/site-packages/django/db/migrations/operations/fields.py",
line 235, in database_forwards
schema_editor.alter_field(from_model, from_field, to_field)
File
"/local/mailman/venv/lib/python3.10/site-packages/django/db/backends/base/schema.py",
line 788, in alter_field
self._alter_field(
File
"/local/mailman/venv/lib/python3.10/site-packages/django/db/backends/base/schema.py",
line 858, in _alter_field
self.execute(self._delete_unique_sql(model, constraint_name))
File
"/local/mailman/venv/lib/python3.10/site-packages/django/db/backends/base/schema.py",
line 199, in execute
cursor.execute(sql, params)
File
"/local/mailman/venv/lib/python3.10/site-packages/django/db/backends/utils.py",
line 67, in execute
return self._execute_with_wrappers(
File
"/local/mailman/venv/lib/python3.10/site-packages/django/db/backends/utils.py",
line 80, in _execute_with_wrappers
return executor(sql, params, many, context)
File
"/local/mailman/venv/lib/python3.10/site-packages/django/db/backends/utils.py",
line 84, in _execute
with self.db.wrap_database_errors:
File
"/local/mailman/venv/lib/python3.10/site-packages/django/db/utils.py", line
91, in __exit__
raise dj_exc_value.with_traceback(traceback) from exc_value
File
"/local/mailman/venv/lib/python3.10/site-packages/django/db/backends/utils.py",
line 89, in _execute
return self.cursor.execute(sql, params)
File
"/local/mailman/venv/lib/python3.10/site-packages/django/db/backends/mysql/base.py",
line 75, in execute
return self.cursor.execute(query, args)
File
"/local/mailman/venv/lib/python3.10/site-packages/MySQLdb/cursors.py", line
179, in execute
res = self._query(mogrified_query)
File
"/local/mailman/venv/lib/python3.10/site-packages/MySQLdb/cursors.py", line
330, in _query
db.query(q)
File
"/local/mailman/venv/lib/python3.10/site-packages/MySQLdb/connections.py",
line 257, in query
_mysql.connection.query(self, query)
django.db.utils.OperationalError: (2013, 'Lost connection to MySQL server
during query')
Which seems to be complaining with DB credentials. But they're properly
set and it works via mysql command line.
(venv) mailman@new-server ~ (v3.3.9)> mysql -umailman3web -p mailman3web
Enter password:
Reading table information for completion of table and column names
You can turn off this feature to get a quicker startup with -A
Welcome to the MariaDB monitor. Commands end with ; or \g.
Your MariaDB connection id is 32
Server version: 10.6.12-MariaDB-0ubuntu0.22.04.1 Ubuntu 22.04
Copyright (c) 2000, 2018, Oracle, MariaDB Corporation Ab and others.
Type 'help;' or '\h' for help. Type '\c' to clear the current input
statement.
MariaDB [mailman3web]> show tables;
+-------------------------------+
| Tables_in_mailman3web |
+-------------------------------+
| account_emailaddress |
| account_emailconfirmation |
| auth_group |
| auth_group_permissions |
| auth_permission |
| auth_user |
| auth_user_groups |
| auth_user_user_permissions |
| django_admin_log |
| django_content_type |
| django_mailman3_maildomain |
| django_mailman3_profile |
| django_migrations |
| django_q_ormq |
| django_q_schedule |
| django_q_task |
| django_session |
| django_site |
| hyperkitty_attachment |
| hyperkitty_email |
| hyperkitty_favorite |
| hyperkitty_lastview |
| hyperkitty_mailinglist |
| hyperkitty_profile |
| hyperkitty_sender |
| hyperkitty_tag |
| hyperkitty_tagging |
| hyperkitty_thread |
| hyperkitty_threadcategory |
| hyperkitty_vote |
| socialaccount_socialaccount |
| socialaccount_socialapp |
| socialaccount_socialapp_sites |
| socialaccount_socialtoken |
+-------------------------------+
34 rows in set (0.000 sec)
On the /etc/mailman3/settings.py:
(venv) mailman@seliius26224 ~ (v3.3.9)> cat /etc/mailman3/settings.py |
grep -v "#" | grep -v '^$'
from mailman_web.settings.base import *
from mailman_web.settings.mailman import *
ADMINS = (
('Mailman Suite Admin', 'root@localhost'),
)
DATABASES = {
'default': {
'ENGINE': 'django.db.backends.mysql',
'NAME': 'mailman3web',
'USER': 'mailman3web',
'PASSWORD': '*******************',
'HOST': 'localhost',
'PORT': '3306',
}
}
STATIC_ROOT = '/local/mailman/web/static'
COMPRESS_ENABLED = True
LOGGING['handlers']['file']['filename'] =
'/local/mailman/web/logs/mailmanweb.log'
ALLOWED_HOSTS = [
"127.0.0.1",
"*"
]
CSRF_TRUSTED_ORIGINS = [
]
SITE_ID = 1
SECRET_KEY = '****************************************'
DEFAULT_FROM_EMAIL = 'admin(a)mailman.domain.com'
SERVER_EMAIL = 'admin(a)mailman.domain.com'
MAILMAN_REST_API_URL = 'http://localhost:8001'
MAILMAN_REST_API_USER = 'restadmin'
MAILMAN_REST_API_PASS = '***************************'
MAILMAN_ARCHIVER_KEY = '****************************'
MAILMAN_ARCHIVER_FROM = ('127.0.0.1', '::1', '1.2.3.4')
HAYSTACK_CONNECTIONS = {
'default': {
'PATH': "/opt/mailman/web/xapian_index",
'ENGINE': 'xapian_backend.XapianEngine'
},
}
And /local/mailman/web/logs/mailmanweb.log is empty.
Best Regards,
Helio Loureiro
https://helio.loureiro.eng.br
https://github.com/helioloureiro
https://mastodon.social/@helioloureiro
On Sun, 17 Dec 2023 at 16:35, Mark Sapiro <mark(a)msapiro.net> wrote:
> On 12/16/23 10:12 AM, Helio Loureiro wrote:
> > Hi,
> >
> > Well... not that good. Now it is mailman3-web that doesn't work.
> >
> > mailman@new-machine ~ (v3.3.9)> source venv/bin/activate.fish
> > (venv) mailman@new-machine ~ (v3.3.9)> mailman-web
> >
> > Type 'mailman-web help <subcommand>' for help on a specific subcommand.
> >
> > Available subcommands:
> >
> > [django]
> > check
> > compilemessages
> > createcachetable
> > dbshell
> > diffsettings
> > dumpdata
> > flush
> > inspectdb
> > loaddata
> > makemessages
> > makemigrations
> > migrate
> > optimizemigration
> > runserver
> > sendtestemail
> > shell
> > showmigrations
> > sqlflush
> > sqlmigrate
> > sqlsequencereset
> > squashmigrations
> > startapp
> > startproject
> > test
> > testserver
>
> This response indicates that `mailman-web` is not getting settings.py.
> Have you configured /etc/mailman3/settings.py? See
> <
> https://docs.mailman3.org/en/latest/install/virtualenv.html#initial-configu…
> >.
>
> > (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
>
> You should run `mailman-web migrate` not `mailman-web check migrate`
> plus others. See
> <
> https://docs.mailman3.org/en/latest/install/virtualenv.html#run-database-mi…>
>
> et.seq. but first you need the appropriate settings so `mailman-web`
> returns something like
> ```
> $ mailman-web
>
> Type 'mailman-web help <subcommand>' for help on a specific subcommand.
>
> Available subcommands:
>
> [account]
> account_unsetmultipleprimaryemails
>
> [auth]
> changepassword
> createsuperuser
>
> [compressor]
> compress
> mtime_cache
>
> [contenttypes]
> remove_stale_contenttypes
>
> [django]
> check
> compilemessages
> createcachetable
> dbshell
> diffsettings
> dumpdata
> flush
> inspectdb
> loaddata
> makemessages
> makemigrations
> migrate
> optimizemigration
> sendtestemail
> shell
> showmigrations
> sqlflush
> sqlmigrate
> sqlsequencereset
> squashmigrations
> startapp
> startproject
> test
> testserver
>
> [django_extensions]
> admin_generator
> clean_pyc
> clear_cache
> compile_pyc
> create_command
> create_jobs
> create_template_tags
> delete_squashed_migrations
> describe_form
> drop_test_database
> dumpscript
> export_emails
> find_template
> generate_password
> generate_secret_key
> graph_models
> list_model_info
> list_signals
> mail_debug
> managestate
> merge_model_instances
> notes
> pipchecker
> print_settings
> print_user_for_session
> raise_test_exception
> reset_db
> reset_schema
> runjob
> runjobs
> runprofileserver
> runscript
> runserver_plus
> set_default_site
> set_fake_emails
> set_fake_passwords
> shell_plus
> show_template_tags
> show_urls
> sqlcreate
> sqldiff
> sqldsn
> sync_s3
> syncdata
> unreferenced_files
> update_permissions
> validate_templates
>
> [django_q]
> qcluster
> qinfo
> qmemory
> qmonitor
>
> [haystack]
> build_solr_schema
> clear_index
> haystack_info
> rebuild_index
> update_index
>
> [hyperkitty]
> attachments_to_file
> hyperkitty_import
> hyperkitty_warm_up_cache
> mailman_sync
> update_index_one_list
>
> [postorius]
> mmclient
> reset_passwords
>
> [rest_framework]
> generateschema
>
> [sessions]
> clearsessions
>
> [staticfiles]
> collectstatic
> findstatic
> runserver
> ```
>
>
> --
> 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 helio(a)loureiro.eng.br
>
2 years, 10 months
Re: Issues with Mail delivery after Mailman 3 installation
by Stephen J. Turnbull
Chihurumnaya Ibiam via Mailman-users writes:
> On Wed, Feb 4, 2026 at 9:06 PM Stephen J. Turnbull <steve(a)turnbull.jp>
> wrote:
>
> > Chihurumnaya Ibiam via Mailman-users writes:
> > > systemctl shows the service is still active,
> > The fact that there is a systemd service implies that dovecot
> > will be running by default unless it is disabled.
> There's no service file for dovecot, I didn't create one.
As far as I know, if systemd knows about a service, there's a control
file somewhere. systemd will create a unit from an rc file in
/etc/rcN.d if there is one. (I was perfectly happy with SysV init,
but I guess systemd makes hyperscalars happy.) I don't know if
"systemctl disable" works on those.
> I configured mailbox transport because that was how I was able to get lmtp
> to run on port 24,
Something like that would be necessary for Dovecot, which I believe
can be configured to automatically create a mailbox for any address.
It is not necessary for Mailman, which tells Postfix how to deliver to
Mailman lists in the postfix_lmtp table. You can find that in
/opt/mailman/mm/var/data, if you followed the virtualenv installation
to the letter.
It's problematic for Mailman because that means that *all* local mail
will be delivered to Mailman, which will reject it if it's not
list-related.
I'm not sure this is why the confirmation mails are getting rejected,
but at a guess, for some classes of mail Postfix will first try the
whole address, and if that fails to route, it will remove the
extension (starting with "+"), and try again. Perhaps it does NOT do
that for the mailbox_transport.
> there wasn't any service before that and the documentation
> <https://docs.mailman3.org/projects/mailman/en/latest/src/mailman/docs/mta.h…>
> for setting up a mail server mentions postfix delivering
> by default over port 24.
What it says is this:
Postfix will deliver via LMTP over port 24 by default, however if
you are not running Mailman as root, you’ll need to change this to
a higher port number, as shown above.
Are you running Mailman as root? If so, stop it, change lmtp_port
back to 8024 in mailman.cfg, and stop and start Mailman to regenerate
the postfix_lmtp.db. There's no need for running as root unless you
have an MTA that is hard-coded to think that 24 is the one and only
lmtp port handed down from Mount Olympus. Postfix knows better.
Furthermore, you should NOT run mailman as root if there's any
alternative. Mailman occasionally crashes for various reasons (I've
never seen it take Python down, but then, if there were an exploit, I
wouldn't), and is not securely authenticated (I mean, it's reasonably
secure, but it is just a password, and once you get in to Mailman
core, you're the superuser for Mailman) and if there *is* an exploit
and Mailman is running as root, you've got system root, too.
Don't run Mailman as root. Please.
> Disabling this means there's no lmtp to be used by postfix, except I'm
> missing something.
Yes, you're missing something. Postfix is always able to speak LMTP,
and is very flexible about when to do so. If you followed the virtualenv
installation to the letter, you have
transport_maps = hash:/opt/mailman/mm/var/data/postfix_lmtp
in main.cf (perhaps there's other maps there), and in that file you
have lines that end in "lmtp:[127.0.0.1]:24", which tell Postfix
"connect to IP address 127.0.0.1, port 24, and speak LMTP to that
connection." If you change lmtp_port to 8024 and restart Mailman as
suggested, all those lines will change to "lmtp:[127.0.0.1]:8024" and
Postfix will be happy to deliver to Mailman that way without being root.
> I set the port number for lmtp to be 24, and that's what I used, I'm not
> sure if Mailman sets up lmtp itself,
> if it does then I'll have to remove the config for that.
>
> I've stopped dovecot after our conversation so it's no longer running, the
> only way the port is open is through the
> config I set in postfix for mailbox_transport.
That should get it working, except that with mailbox_transport set
there's a good chance that Mailman functions that use "+" extensions
will mess up as described above. Those functions are confirmations
and I think VERP probes.
> There's just one active user, which is me, and I also have root access.
> I setup authentication for postfix because I'm used to setting it up that
> way, this was a force of habit.
> I assumed postfix would run just fine if I set postfix up the way I usually
> set it up.
It might. But "Internet Mail" is another name for Dante's Third Circle
of Hell. (You must have committed a horrible felony to be sentenced
to administer an Internet mail host. :-D That's just a joke, it
sounds to me like your "usual setup" is quite solid and secure.)
Anyway, any deviation from the setup described in virtualenv.html is a
chance for everything to go wrong. "What I usually do" is just not
deep enough knowledge if you're working with a new mail application
with complex routing needs.
> > What does "lsof -i @127.0.0.1 -i '@[::1]' | grep 24" output?
> python3 1592922 mailman 27u IPv4 177685024 0t0 TCP localhost:8001 (LISTEN)
> python3 1592949 mailman 27u IPv4 177685024 0t0 TCP localhost:8001 (LISTEN)
> python3 1592950 mailman 27u IPv4 177685024 0t0 TCP localhost:8001 (LISTEN)
The above are Mailman (actually, a gunicorn application) listening for
connections to its REST API. These are HTTP listeners used by
Postorius and HyperKitty (I guess those aren't running?), not for email.
> postgres 3568035 postgres 5u IPv6 160224851 0t0 TCP localhost:postgresql (LISTEN)
> postgres 3568035 postgres 6u IPv4 160224852 0t0 TCP localhost:postgresql (LISTEN)
These are PostgreSQL listening for database connections.
> python3 1592924 mailman 22u IPv6 177685051 0t0 TCP localhost:48638->localhost:postgresql (ESTABLISHED)
This is Mailman talking to Postfix.
> postgres 1592954 postgres 9u IPv6 177686124 0t0 TCP localhost:postgresql->localhost:48498 (ESTABLISHED)
> postgres 1592912 postgres 8u IPv6 160224857 0t0 UDP localhost:36787->localhost:36787
+ 21 more copies of the above, differing only in the PID. Don't know
what's going on with those, not a PostgreSQL wizard. I probably
should have specified TCP in the lsof command, UDP applications are
either trivial or they are black magic.
It appears that *nothing* is listening on or connected to port 24.
I'm not sure how that works. I'm guessing that when mail was getting
to Mailman, Mailman had opened port 24 and Dovecot was cut out of the
loop (maybe check logs for Dovecot complaining it couldn't bind to
port 24?)
> > > [mta] lmtp_host: *.*.*.*
> >
> > That should be 127.0.0.1. Mailman should not be listening on network
> > interfaces other than the loopback (localhost).
>
> Yes, it is.
OK
> > > [mta] lmtp_port: 24
> >
> > This can't work if Dovecot is configured to use the same port, as is
> > Dovecot's default.
> I've stopped the service.
OK
> > > [mta] outgoing: mailman.mta.deliver.deliver
> > > [mta] smtp_host: 127.0.0.1
> > > [mta] smtp_port: 25
> >
> > Those are normal.
> >
> > > [mta] smtp_pass: **************
> > > [mta] smtp_user: mailman
> >
> > This is going to cause Mailman to try to authenticate to Postfix.
> > That's OK if it's what you want and Postfix / saslauthd has been
> > properly configured to accept Mailman's credentials. Otherwise,
> > they must be left empty to disable authentication.
> Okay.
> > > The Message-ID being the way it is doesn't seem like a
> > > configuration issue, if it is then how do I look into it?
> >
> > Probably you don't have the full hostname in Postfix's myorigin or
> > myhostname parameter.
>
> I do have the full hostname there, I also have it in /etc/mailname.
I don't understand it then. Perhaps the mail composition client is
providing the Message-ID.
> > If not, I would guess that's a spammer who is somehow spoofing
> > the PTR record.
> The log entry before that warned of the same, they're definitely a spammer.
> Relay access is denied though, so no mails are going through.
OK.
> No, I mean smtps.
Same problem except the port that Mailman is *not* using is 465.
> > I don't think permit_auth_destination does what you think it does.
> > Here's the Postfix doc:
> >
> > permit_auth_destination
> > Permit the request when one of the following is true:
> >
> > - Postfix is a mail forwarder: the resolved RCPT TO domain
> > matches $relay_domains or a subdomain thereof, and the address
> > contains no sender-specified routing (user@elsewhere@domain),
> > - Postfix is the final destination: the resolved RCPT TO domain
> > matches $mydestination, $inet_interfaces, $proxy_interfaces,
> > $virtual_alias_domains, or $virtual_mailbox_domains, and the
> > address contains no sender-specified routing
> > (user@elsewhere@domain).
> >
>
> I did read the documentation before adding it, I definitely misunderstood
> what it meant, and after looking at the old
> documentation, it makes sense not to add it.
>
> Could you help me understand what the above means?
I gotta run now, I'll come back to it later. You're probably asleep,
anyway. :-)
--
GNU Mailman consultant (installation, migration, customization)
Sirius Open Source https://www.siriusopensource.com/
Software systems consulting in Europe, North America, and Japan
8 months, 2 weeks