Search results for "Postorius" - Mailman-users

Re: Residual signature?

by Paul Tomblin

On Thu, May 28, 2026, at 8:20 AM, Stephen J. Turnbull wrote: > Paul Tomblin via Mailman-users writes: > > > Like I said, there’s no templates listed in the UI. > > Ah, I read that as "no relevant templates". Sorry, I wasn't clearer because I didn't know about the non-UI templates before. > > The migration from Mailman 2 doesn't need a working Postorius, so it > doesn't use the same mechanism as the UI. It should write to a > parallel tree under the $mailman_home/$var/templates directory. The > fallback tree is in site-packages/mailman/templates, and otherwise Turns out there are a lot of files in /opt/mailman/mm/var/templates/lists, but I hadn't noticed them before because most of them where empty. In a few of the ones I don't subscribe to or which don't get a lot of traffic, those templates were "-- \nAdministration:" or sometimes "== \n-- Administration: %(web_page_url)slistinfo/%(_internal_name)s". I suspect that the ones that didn't have the text after Administration: versus the ones that did were some sort of bug in the conversion script, because I'm pretty sure I had the same footer configured for all those lists. But anyway, I had no idea those templates were there, so I'll have to file that away in my memory for next time I wonder why lists have footers that don't show up in the UI. Am I right in thinking that a UI configured template will override the ones in that directory tree? -- Paul Tomblin

3 months, 2 weeks

Re: Column 'starting_email_id' cannot be null

by Odhiambo Washington

On Mon, Aug 18, 2025 at 11:32 AM kroerig--- via Mailman-users < mailman-users(a)mailman3.org> wrote: > Hello, > > after upgrading from Debian 11 to Debian 12 achiving incoming mails always > fails with > > Traceback (most recent call last): > File "/usr/lib/python3/dist-packages/django/db/models/query.py", line > 581, in get_or_create > return self.get(**kwargs), False > File "/usr/lib/python3/dist-packages/django/db/models/query.py", line > 435, in get > raise self.model.DoesNotExist( > > During handling of the above exception (Thread matching query does not > exist.), another exception occurred: > File "/usr/lib/python3/dist-packages/django/db/backends/mysql/base.py", > line 73, in execute > return self.cursor.execute(query, args) > File "/usr/lib/python3/dist-packages/MySQLdb/cursors.py", line 209, in > execute > res = self._query(query) > File "/usr/lib/python3/dist-packages/MySQLdb/cursors.py", line 316, in > _query > self._do_get_result(db) > File "/usr/lib/python3/dist-packages/MySQLdb/cursors.py", line 147, in > _do_get_result > self._result = result = self._get_result() > File "/usr/lib/python3/dist-packages/MySQLdb/cursors.py", line 349, in > _get_result > return self._get_db().store_result() > > During handling of the above exception ((1048, "Column 'starting_email_id' > cannot be null")), another exception occurred: > File "/usr/lib/python3/dist-packages/django/core/handlers/exception.py", > line 47, in inner > response = get_response(request) > File "/usr/lib/python3/dist-packages/django/core/handlers/base.py", line > 181, in _get_response > response = wrapped_callback(request, *callback_args, **callback_kwargs) > File "/usr/lib/python3/dist-packages/django/views/decorators/http.py", > line 40, in inner > return func(request, *args, **kwargs) > File "/usr/lib/python3/dist-packages/hyperkitty/views/mailman.py", line > 117, in _decorator > return func(request, *args, **kwargs) > File "/usr/lib/python3/dist-packages/django/views/decorators/csrf.py", > line 54, in wrapped_view > return view_func(*args, **kwargs) > File "/usr/lib/python3/dist-packages/hyperkitty/views/mailman.py", line > 163, in archive > add_to_list(mlist_fqdn, msg) > File "/usr/lib/python3/dist-packages/hyperkitty/lib/incoming.py", line > 153, in add_to_list > email.save() > File "/usr/lib/python3/dist-packages/django/db/models/base.py", line > 739, in save > self.save_base(using=using, force_insert=force_insert, > File "/usr/lib/python3/dist-packages/django/db/models/base.py", line > 763, in save_base > pre_save.send( > File "/usr/lib/python3/dist-packages/django/dispatch/dispatcher.py", > line 180, in send > return [ > File "/usr/lib/python3/dist-packages/django/dispatch/dispatcher.py", > line 181, in <listcomp> > (receiver, receiver(signal=self, sender=sender, **named)) > File "/usr/lib/python3/dist-packages/hyperkitty/signals.py", line 48, in > Email_on_pre_save > kwargs["instance"].on_pre_save() > File "/usr/lib/python3/dist-packages/hyperkitty/models/email.py", line > 239, in on_pre_save > thread, _thread_created = Thread.objects.get_or_create( > File "/usr/lib/python3/dist-packages/django/db/models/manager.py", line > 85, in manager_method > return getattr(self.get_queryset(), name)(*args, **kwargs) > File "/usr/lib/python3/dist-packages/django/db/models/query.py", line > 588, in get_or_create > return self.create(**params), True > File "/usr/lib/python3/dist-packages/django/db/models/query.py", line > 453, in create > obj.save(force_insert=True, using=self.db) > File "/usr/lib/python3/dist-packages/django/db/models/base.py", line > 739, in save > self.save_base(using=using, force_insert=force_insert, > File "/usr/lib/python3/dist-packages/django/db/models/base.py", line > 776, in save_base > updated = self._save_table( > File "/usr/lib/python3/dist-packages/django/db/models/base.py", line > 881, in _save_table > results = self._do_insert(cls._base_manager, using, fields, > returning_fields, raw) > File "/usr/lib/python3/dist-packages/django/db/models/base.py", line > 919, in _do_insert > return manager._insert( > File "/usr/lib/python3/dist-packages/django/db/models/manager.py", line > 85, in manager_method > return getattr(self.get_queryset(), name)(*args, **kwargs) > File "/usr/lib/python3/dist-packages/django/db/models/query.py", line > 1270, in _insert > return query.get_compiler(using=using).execute_sql(returning_fields) > File "/usr/lib/python3/dist-packages/django/db/models/sql/compiler.py", > line 1416, in execute_sql > cursor.execute(sql, params) > File "/usr/lib/python3/dist-packages/django/db/backends/utils.py", line > 66, in execute > return self._execute_with_wrappers(sql, params, many=False, > executor=self._execute) > File "/usr/lib/python3/dist-packages/django/db/backends/utils.py", line > 75, in _execute_with_wrappers > return executor(sql, params, many, context) > File "/usr/lib/python3/dist-packages/django/db/backends/utils.py", line > 84, in _execute > return self.cursor.execute(sql, params) > File "/usr/lib/python3/dist-packages/django/db/backends/mysql/base.py", > line 78, in execute > raise IntegrityError(*tuple(e.args)) > > Exception Type: IntegrityError at /hyperkitty/api/mailman/archive > Exception Value: (1048, "Column 'starting_email_id' cannot be null") > > Postorius Version 1.3.8 > HyperKitty Version 1.3.7 > > Any ideas how to fix this? > > Klauas It looks like you did not run some migrations. However, because this is packaged Mailman3, I am not sure I know how to do that. -- Best regards, Odhiambo WASHINGTON, Nairobi,KE +254 7 3200 0004/+254 7 2274 3223 In an Internet failure case, the #1 suspect is a constant: DNS. "Oh, the cruft.", egrep -v '^$|^.*#' ¯\_(ツ)_/¯ :-) [How to ask smart questions: http://www.catb.org/~esr/faqs/smart-questions.html]

1 year

Re: nginx configuration on a multitasking server

by Mark Sapiro

On 12/22/21 9:22 PM, David Newman wrote: > > On my system that file lives here: > > /opt/mailman/venv/lib/python3.9/site-packages/mailman_web/urls.py It appears that you have installed following https://docs.mailman3.org/en/latest/install/virtualenv.html#virtualenv-inst… and in that case, this is the file. > But the error persists after this addition and restarting MM3 and > mailmanweb and nginx: > > url(r'^mailman/', include('postorius.urls')), > > There is this 404 error in uwsgi.log: > > [pid: 73356|app: 0|req: 3/3] 127.0.0.1 () {48 vars in 1544 bytes} [Wed > Dec 22 21:13:48 2021] GET /mailman/admindb/listname => generated 5328 > bytes in 14 msecs (HTTP/1.0 404) 6 headers in 197 bytes (1 switches on > core 0) However, that's not the issue. You originally reported and I didn't look closely enough: > Update: The above worked fine until MM3 informed a list owner of pending > subscription requests, with a URL like this: > > https://lists.example.com/mailman/admindb/listname > > and that URL returned a 404 error. That URL is from a Mailman 2.1 installation. Are you still running Mailman 2.1? If so, you need to support Mailman 2.1's CGIs. In Apache, this would be something like ScriptAlias /mailman/ /parh/to/mailman/cgi-bin/ but nginx doesn't do that. You would need something like location /mailman/ { proxy_pass <something that can serve Mailman 2.1's CGIs.> } The something could be apache or ?? -- Mark Sapiro <mark(a)msapiro.net> The highway is for gamblers, San Francisco Bay Area, California better use your sense - B. Dylan

4 years, 8 months

Re: MM3 templates

by Mark Sapiro

On 2/16/23 11:14, Odhiambo Washington wrote: > On Thu, Feb 16, 2023 at 9:32 PM Mark Sapiro <mark(a)msapiro.net> wrote: >> >> I don't know why? What's the content of the template table in the database? >> ``` >> SELECT * FROM template; >> ``` >> > > root@localhost [mailmansuite]> SELECT * FROM template; > Empty set (0.03 sec) Well, that eliminates one possibility. I still don't know why. Mailman should be using all the list: templates from /opt/mailman/mm/var/templates/lists/kictanet.lists.kictanet.or.ke/en/ for messages from the kictanet(a)lists.kictanet.or.ke where the target language is English. Is the list's preferred language English and is the recipient's preferred language English? >> That's just wasting space. If you're putting the exact same templates in >> site/, domains/ and lists/, you might just as well delete the ones in >> domains/ and lists/ and Mailman will use the ones from site/. >> > > Well, space is cheap these days. More importantly, it could lead you to edit a template that isn't used because one of the other places is searched first. I would like to figure out what the issue is, but I don't know how to proceed. Have you checked /opt/mailman/mm/var/logs/mailman.log for anything relevant? If all else fails and we can't figure this out, you could always set the template(s) in Postorius. -- Mark Sapiro <mark(a)msapiro.net> The highway is for gamblers, San Francisco Bay Area, California better use your sense - B. Dylan

3 years, 6 months

Re: Missing Base64 encoding from control message reply

by Mark Sapiro

On 9/22/23 09:32, Stephen J. Turnbull wrote: > > To diagnose, we really need to see that in context of the raw message > as received by the user. It was posted. The issue is the message declares Content-Transfer-Encoding: base64 but the body is not base64 encoded so the MUA tries to base64 decode it and even though that's invalid, produces the garbled output. > The only other thing I can think of is it might have something to do > with your internationalization settings. What is the default language > of the list? (This is available in Postorius.) Have you changed the > default encoding for English on your site? (I think you need to look > in mailman.cfg for this.) What is the default language of the site? I note that the message also declares Content-Type: text/plain; charset="utf-8" and Python's email package will base64 encode utf-8 message bodies. I also note that the messages Subject: is RFC 2047 encoded as utf-8. These tell me that the user's preferred_language if set or the list's preferred_language is not English or the charset for English is changed to utf-8. I tried to duplicate this in a test installation with the charset for English set to utf-8, but I get a similar response but with Subject: =?utf-8?q?The_results_of_your_email_commands?= and Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit -- Mark Sapiro <mark(a)msapiro.net> The highway is for gamblers, San Francisco Bay Area, California better use your sense - B. Dylan

2 years, 11 months

Re: 404 on fresh install (Debian11)

by Mark Sapiro

On 3/22/23 03:42, thomas--- via Mailman-users wrote: > Hello, > very new to mailman3, I used to manage mailman2 on a Debian 10 server. > The server has been upgraded to Debian 11 and mailman2 disappear… > > I try fresh install of mailman3, prerequisite to data migration, but without success. > If some can help, I would be really greatful. > > <VirtualHost *:80> > ServerName newsletter.mydomain.tld > > Alias /static /var/lib/mailman3/web/static > Alias /favicon.ico /var/lib/mailman3/web/static/postorius/img/favicon.ico > > DocumentRoot /var/lib/mailman3/web/static > <Directory "/var/lib/mailman3/web/static"> > Require all granted You can probably fix the below error by adding options +Indexes here, but see below. > And now I have a 404 answer when consulting my http page. > > When trying to access `/static` sub-path, I get `Cannot serve directory /var/lib/mailman3/web/static/admin/: No matching DirectoryIndex found`. It is unclear to me what is doing a GET of /static/admin/ and why. GETs should by of actual files, e.g., things like /static/admin/css/base.css > I am a bit lost with that. So are we. Questions about the Debian package are better asked of Debian. See https://wiki.list.org/x/12812344 and https://mail.python.org/archives/list/mailman-users@python.org/message/T6LB… We can provide much better help and support if you install via the resources mentioned in the reply at https://lists.mailman3.org/archives/list/mailman-users@mailman3.org/message… -- Mark Sapiro <mark(a)msapiro.net> The highway is for gamblers, San Francisco Bay Area, California better use your sense - B. Dylan

3 years, 5 months

Re: Rejecting held emails

by Mark Sapiro

On 04/26/2018 08:43 AM, Darren Smith wrote: > > We recently had a phishing message make it through our spam filters and > arrive at a mailing list. The good news is that since it was not from a > list member it was in the held message queue. > > I was able to find the message in the var/messages directory by searching > for a keyword in the subject. However, after rejecting the message from > Postorius, the message doesn't seem to be removed from the var/messages > directory. Do you mean Reject and not Discard? Phishing/Spam should never be "rejected" for backscatter reasons. Reject should only be used for somehow inappropriate posts from known people. > Is this expected behavior? I know that infosec people won't be too happy > about a phishing email sitting around on our disk. (Infosec guys are > notoriously paranoid. :) ) > > Is there some sort of cleanup process that would remove these messages? If > not, does this pose an issue where over time disk usage will creep up? This > could be a pretty significant problem if that is the case. It's not the behavior I would "expect", but it is the way it currently works, and yes, all your concerns are valid. This is <https://gitlab.com/mailman/mailman/issues/257> which I just edited to note that in addition to not removing the pending db entry, the message isn't removed either. -- Mark Sapiro <mark(a)msapiro.net> The highway is for gamblers, San Francisco Bay Area, California better use your sense - B. Dylan

8 years, 4 months

Re: Confusing mailman user model

by Mark Sapiro

On 7/19/20 8:10 AM, Gilles Filippini wrote: > Hi, > > I'm trying to understand the Mailman user model, and I'm confused about > the respective roles of tables 'auth_user' and 'user'. auth_user is a Django auth table. These are the users listed in the Django admin web UI. user is Mailman core's users. > Both have an 'id' column referred to as 'user_id' when used as a foreign > key. But there seems to be no relation at all between them as they use > different ids for the same user. Right, they are unrelated. > Our mailman server was migrated from mailman2 to mailman3 about 1.5 year > ago, and there is an inconsistency I'd like to fix: > 2 of our users have a registered Mailman account with their respective > email addresses in table 'auth_user', but these very same addresses in > the 'address' table are linked to another old admin account in the > 'user' table. Their Mailman account is the 'old' one. the auth_user account is a Django account > > Then if add one of these addresses as a domain owner, it it the old > admin address which is selected instead. How could I fix that? That's because domain owner in a Mailman thing and involvs the Mailman user. You could delete the Django users via the Django admin UI and then re-register them via Postorius. That *might* work. -- Mark Sapiro <mark(a)msapiro.net> The highway is for gamblers, San Francisco Bay Area, California better use your sense - B. Dylan

6 years, 1 month

Re: mailman-web migrate fails with sqlite3.IntegrityError: UNIQUE constraint failed: account_emailaddress.email

by Mark Sapiro

On 3/3/25 07:52, Stefan Bauer via Mailman-users wrote: > > trying to update mailman3 to lastest version, we fail during > > mailman-web migrate with: > > Operations to perform: > Apply all migrations: account, admin, auth, contenttypes, django_mailman3, > django_q, hyperkitty, postorius, sessions, sites, socialaccount > Running migrations: > Applying account.0006_emailaddress_lower...Traceback (most recent call > last): > File > "/opt/mailman/venv/lib/python3.10/site-packages/django/db/backends/utils.py", > line 89, in _execute > return self.cursor.execute(sql, params) > File > "/opt/mailman/venv/lib/python3.10/site-packages/django/db/backends/sqlite3/base.py", > line 328, in execute > return super().execute(query, params) > sqlite3.IntegrityError: UNIQUE constraint failed: account_emailaddress.email This issue is due to changes in Django allauth to prevent creating multiple addresses differing only in case. The problem is if you have such multiple addresses in your account_emailaddress table, this migration fails. There is a script at https://www.msapiro.net/scripts/UC_fix that will fix this. You may need to adjust the shebang and replace psycopg2 with sqlite3. See https://github.com/pennersr/django-allauth/issues/3019 perhaps starting at https://github.com/pennersr/django-allauth/issues/3019#issuecomment-1748028… > We found a workaround to fake the migration with > > migrate --fake You should fix the issue with the DB and run the migrations. > Could this be some duplicate users with same mail-address? This is not related to Mailman users. It is Django users. -- 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: Database deadlock when trying to delete a member.

by Simon Coggins

> On 18 Mar 2021, at 5:05 pm, Abhilash Raj <maxking(a)asynchronous.in> wrote: > > Hi Simon, > > > On Mar 17, 2021, at 10:16 PM, Simon Coggins <s.coggins(a)cqu.edu.au> wrote: > > > > Hi, > > > > I’ve got a strange error. I migrated from mailman 2.1 to 3 using the migration guide on the website and things have been working fine. But I’m in the process of testing the new syncmembers command to replace some inhouse mailman API code we wrote. I’ve tracked my problem down to what appears to be a deadlock in the postgresql database. When trying to delete certain users the SQL query hangs and never returns. > > > > After doing some tracing and tracking it down to the database, I enabled DB logging of all queries and saw that the following query was never returning: > > > > DELETE FROM member WHERE member.id = 166814 > > > > If I try to run it manually I get the same issue, in psql it never returns. > > mailman=# explain analyze DELETE FROM member WHERE member.id = 166814; > > [… 60 seconds passes…] > > ^CCancel request sent > > ERROR: canceling statement due to user request > > CONTEXT: while deleting tuple (2998,72) in relation "member" > > I’m just wondering if there are any commands or scripts I can run to verify the database and it’s constraints to see if there is some error in the database data? Or where you’d recommend I go from here? It only impacts the user on this specific list. If I add this user to another list and remove them, everything works fine. > > Are you able to retrieve that Member object using API? > > This[1] the Python code which would try to delete a Member object and I > am assuming is being called from syncmembers command. I am not entire > sure about what would cause the database to hang, if there was some database > constraint that failed, I would imagine some error to be returned. > > [1]: https://gitlab.com/mailman/mailman/-/blob/master/src/mailman/model/member.p… > Ok I think I’m getting closer. It appears to be an open transaction that is locking the database record. While mailman is running, if I try to execute "DELETE FROM member WHERE member.id = 166507;” on the mailman table in psql the query hangs and never returned. But if I shutdown mailman and try to run the query again, it executed immediately. So I’m pretty sure there is an open transaction that is causing the entry to be locked. > One thing you can try is see if you can unsubscribe the user using the API or > `mailman shell` command. > > You can unsubscribe from API by calling a `DELETE` method at > > http://localhost:9001/3.1/members/<member_id> > > This would give us some indication about whether there is some bug > in the implementation of syncmembers command or if there is something > else going on. > Trying via shell or via API to delete the user all fail and hang. I’m able to receive the user/membership/list data without any issue both via mailman command and via the API. > > > > This is on a test system so I can do various testing. I’m trying to find the root cause so that I can verify my production system isn’t impacted by the same thing. > > > > > > Setup Details: > > OS: Oracle Linux 7 (Redhat) > > Installed using pip via virtualenv talking to a local pgsql database on the same box. > > Data was migrated from a mailman 2.1 install into mailman3 using migration instructions on the website. > > > > PIP Modules versions: > > django-mailman3 1.3.5 > > mailman 3.3.3 > > mailman-hyperkitty 1.1.0 > > mailmanclient 3.3.2 > > postorius 1.3.4 > > psycopg2-binary 2.8.5 > > What is the version of sqlalchemy package? There is a new 1.4.0 version that came out recently > and is incompatible with Core right now. There are backwards incompatible changes which might > need some changes in Core to add support. > SQLAlchemy 1.3.19 > > > > RPM packages: > > postgresql12-12.6-1PGDG.rhel7.x86_64 > > postgresql12-server-12.6-1PGDG.rhel7.x86_64 > > postgresql12-libs-12.6-1PGDG.rhel7.x86_64 > > postgresql12-devel-12.6-1PGDG.rhel7.x86_64 > > > > > > -Simon > > > > > > _______________________________________________ > > 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) > > > _______________________________________________ > 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/ --- Simon Coggins, Principal Systems Engineer Digital Services Directorate CQUniversity, Lvl 6.14, 160 Ann Street Brisbane, QLD, 4000 Email: s.coggins(a)cqu.edu.au Web: http://www.cqu.edu.au/

5 years, 5 months

Mailman-users search results for query "Postorius"