Search results for query "sapiro"
- 6360 messages
[MM3-users] Re: Message is received but is not sent out. Another, similar message, is processed fine.
by Allan Hansen
Thank you, Mark.
I see this in mailman.log. I had looked there for her email address, but it does not appear, so I moved on to the smtp.log.
In
Jun 26 17:18:11 2023 (1243315) ACCEPT: ^M
<CH3PR12MB82593801A1DF2E329E977046BE27A(a)CH3PR12MB8259.namprd12.prod.outlook.com>
Jun 26 17:18:11 2023 (1243319) Uncaught runner exception: unknown encoding: iso-8859-8-i
Jun 26 17:18:11 2023 (1243319) Traceback (most recent call last):
File "/opt/mailman/mm/venv/lib/python3.9/site-packages/mailman/core/runner.py", line 179, in _one_iteration
self._process_one_file(msg, msgdata)
File "/opt/mailman/mm/venv/lib/python3.9/site-packages/mailman/core/runner.py", line 272, in _process_one_file
keepqueued = self._dispose(mlist, msg, msgdata)
File "/opt/mailman/mm/venv/lib/python3.9/site-packages/mailman/runners/pipeline.py", line 37, in _dispose
process(mlist, msg, msgdata, pipeline)
File "/opt/mailman/mm/venv/lib/python3.9/site-packages/mailman/core/pipelines.py", line 53, in process
handler.process(mlist, msg, msgdata)
File "/opt/mailman/mm/venv/lib/python3.9/site-packages/mailman/handlers/mime_delete.py", line 382, in process
process(mlist, msg, msgdata)
File "/opt/mailman/mm/venv/lib/python3.9/site-packages/mailman/handlers/mime_delete.py", line 151, in process
reset_payload(msg, firstalt)
File "/opt/mailman/mm/venv/lib/python3.9/site-packages/mailman/handlers/mime_delete.py", line 202, in reset_payload
msg.set_payload(subpart.get_payload(decode=True).decode(
LookupError: unknown encoding: iso-8859-8-i
Jun 26 17:18:11 2023 (1243319) SHUNTING: 1687825091.8457294+478565324778f2eb6f0fecaeccbd29596edaef53
I also see this in queue/shunt:
mailman@list:~/var/queue/shunt$ ls -ltr
total 88
-rw-rw---- 1 mailman mailman 7168 Feb 17 23:03 1676703781.903885+fdcba88c680f50a0799c672cd0abe82e4bfe19b3.pck
-rw-rw---- 1 mailman mailman 19821 Apr 2 07:08 1680444501.0831451+e110b8c5c20ba3f87c1cea1c5f38e74a6cf8f1c5.pck
-rw-rw---- 1 mailman mailman 19489 Jun 18 11:52 1687114364.41209+1684717da96ff76d1ce773a0cf39c5f8b63e9078.pck
-rw-rw---- 1 mailman mailman 20274 Jun 18 19:01 1687140067.64057+7f77c1ebca490831f58ef9cfde06109081a4e7d6.pck
-rw-rw---- 1 mailman mailman 20085 Jun 26 17:18 1687825091.8457294+478565324778f2eb6f0fecaeccbd29596edaef53.pck
The three last entries coincide with the captured messages.
Finally, in the captured message source (the last which was Cc'd to me) I do see this:
Content-Type: text/plain; charset="iso-8859-8-i"
Which matches the complaint in the mailman log.
In the message that did get accepted, I see this:
Content-Type: text/plain; charset="utf-8"
Another difference:
The posted message shows
Content-Transfer-Encoding: base64
The shunted message shows
Content-Transfer-Encoding: quoted-printable
It appears that the two messages are, indeed, different, despite the similar looks when rendered.
My question thus changes to:
a. Should she be doing something special when sending to the lists?
b. If not, is my setup in need of change?
Yours,
Allan
On 6/26/23, 20:44, "Mark Sapiro" <mark(a)msapiro.net <mailto:mark@msapiro.net>> wrote:
On 6/26/23 8:09 PM, Allan Hansen wrote:
> Hi all,
>
> One of my subscribers is trying to send a message to a list, but it is not being posted.
> The smtp.log shows that her first message was posted, but a second message (with 2 retries) was not:
>
> mailman@list:~/logs$ grep herName smtp.log
> Jun 18 11:22:05 2023 (1243316) ('127.0.0.1', 56686) >> b'MAIL FROM:<herName(a)hotmail.com <mailto:herName@hotmail.com>> SIZE=40109'
> Jun 18 11:22:05 2023 (1243316) ('127.0.0.1', 56686) sender: herName(a)hotmail.com <mailto:herName@hotmail.com>
> Jun 18 11:25:01 2023 (1243318) <CH3PR12MB82593510B90D8F05177C606BBE5EA(a)CH3PR12MB8259.namprd12.prod.outlook.com <mailto:CH3PR12MB82593510B90D8F05177C606BBE5EA@CH3PR12MB8259.namprd12.prod.outlook.com>> post to theList(a)domain.tlc <mailto:theList@domain.tlc> from herName(a)hotmail.com <mailto:herName@hotmail.com>, 40061 bytes
> Jun 18 11:52:42 2023 (1243316) ('127.0.0.1', 48448) >> b'MAIL FROM:<herName(a)hotmail.com <mailto:herName@hotmail.com>> SIZE=18343'
> Jun 18 11:52:42 2023 (1243316) ('127.0.0.1', 48448) sender: herName(a)hotmail.com <mailto:herName@hotmail.com>
> Jun 18 19:01:04 2023 (1243316) ('127.0.0.1', 59550) >> b'MAIL FROM:<herName(a)hotmail.com <mailto:herName@hotmail.com>> SIZE=19123'
> Jun 18 19:01:04 2023 (1243316) ('127.0.0.1', 59550) sender: herName(a)hotmail.com <mailto:herName@hotmail.com>
> Jun 26 17:18:11 2023 (1243316) ('127.0.0.1', 44732) >> b'MAIL FROM:<herName(a)hotmail.com <mailto:herName@hotmail.com>> SIZE=18930'
> Jun 26 17:18:11 2023 (1243316) ('127.0.0.1', 44732) sender: herName(a)hotmail.com <mailto:herName@hotmail.com>
>
> At the second retry she copied me and I saw nothing untowards in her message.
> She's not getting any error return messages and her subscription is OK.
> Both messages were multipart/alternative and both contained Hebrew text.
>
> I told her I'd look at this, but I'm at a loss.
smtp.log is not very useful for diagnosing things like this. It only
says a message was received, not why it didn't result in a post from the
list as in the first case. What's in mailman.log with those timestamps?
--
Mark Sapiro <mark(a)msapiro.net <mailto:mark@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 <mailto:mailman-users@mailman3.org>
To unsubscribe send an email to mailman-users-leave(a)mailman3.org <mailto:mailman-users-leave@mailman3.org>
https://lists.mailman3.org/mailman3/lists/mailman-users.mailman3.org/ <https://lists.mailman3.org/mailman3/lists/mailman-users.mailman3.org/>
Archived at: https://lists.mailman3.org/archives/list/mailman-users@mailman3.org <mailto:mailman-users@mailman3.org>/message/F4K7HYUYSWEKF6LT35UCT3KBJX6GHY4I/
This message sent to hansen(a)rc.org <mailto:hansen@rc.org>
3 years, 1 month
[MM3-users] Re: old usernames appearing in mailman.log
by Ken Alker
--On Monday, June 26, 2023 5:03 PM -0700 Mark Sapiro <mark(a)msapiro.net>
wrote:
> On 6/25/23 10:57 PM, Ken Alker wrote:
>>
>> I have studied the output, looked at the code lines referenced in the
>> Traceback, and I can't figure out the problem (I feel like the sad guy
>> on the side of the street with his hood up staring into the engine bay
>> with stream pouring out and not knowing what to do next). I did some
>> analyses on the log file and determined that there are 71 messages it is
>> having problems processing and there are 71 messages "stuck" in
>> /opt/mailman/mm/var/archives/hyperkitty/spool/ (and that it has tried to
>> process each message about 20 times).
>
>
> Each time there is a new post, it retries all the messages in the spool/
> directory.
>
>
>> Since upgrading to V3.3.8 I've
>> not seen new messages get stuck like this (although it's only been
>> running smoothly for 24 hours now and there hasn't been much activity).
>> But I'm suspecting there was something awry between the conversion from
>> V2 to V3 in February and me installing V3.3.8 that caused this (based on
>> message time stamps). It is HIGHLY likely these messages are in the
>> archiving spool as a result of me unshunting the shunt queue and that
>> they are copies of the messages that got delivered to the subscribers
>> when I did that... but are now hung up in the archiving process.
>
>
> Are new messages being archived OK. If so, that is a real mystery. It
> says mailman-hyperkitty can talk to hyperkitty and archive new messages,
> but it can't talk to hyperkitty when attempting to process a queued
> message.
Ahhh! I had convinced myself that new messages were being archived, but
now that you ask, they ARE NOT. I may have said they were at some point,
and I apologize if I did. Now I feel less confused.
It appears that archiving stopped when I did the migration from "Debian
package layout" to "source layout" and upgraded to V3.3.8. I'll bet I
munged a config file or two. I was struggling with what to keep from
Debian layout and what to bring over from the source install instructions
and I haven't gone back through to clean them up. I had previously figured
it could not be a configuration issue since some messages were making it
into the archive and some were not, but now that I see NONE are making it,
this makes the problem less daunting.
>> Following is an excerpt from mailman.log. Note that the "first
>> section" (from DOCTYPE at top to 404 at bottom) is repeated four times
>> (maybe not identical; but similar) (so I did not include it to save
>> room) before the Traceback appears.
>>
>> Jun 25 00:13:04 2023 (386086) No cached copy of the public suffix list
>> found
>> Jun 25 00:13:04 2023 (386086) ACCEPT:
>> <7500f0e2-1ae1-309d-60d7-6e592c7abf7a(a)west.net>
>> Jun 25 00:13:04 2023 (386090) HyperKitty failure on
>> https://lists.netlojix.com/hyperkitty/api/mailman/urls:
>
> I just went to that URL and got a 404. This is a serious problem.
> https://lists.netlojix.com/hyperkitty/api/ also returns a 404. It should
> return some documentation of the API.
>
> https://lists.netlojix.com/archives/api/ does work and returns the
> expected information.
>
> Your urls.py file probably contains in its urlpatterns list
> ```
> re_path(r'^mailman3/', include('postorius.urls')),
> re_path(r'^archives/', include('hyperkitty.urls')),
> ```
> The simplest fix is to add
> ```
> re_path(r'^postorius/', include('postorius.urls')),
> re_path(r'^hyperkitty/', include('hyperkitty.urls')),
> ```
> to that list.
I see many ursl.py files all over the system, but none that appear to be
where I'd expect them to be for processing by any executables. Is this a
file I should have copied over and edited, or created from scratch and
somehow missed? I don't see anything about it in the instructions at
<https://docs.mailman3.org/en/latest/install/virtualenv.html> (although I
do see a post from last July from someone stating it got missed in the
instructions back then).
> Another way to fix this is in your mailman-hyperkitty.cfg, you have
> ```
> base_url: https://lists.netlojix.com/hyperkitty
> ```
> Change that to
> ```
> base_url: https://lists.netlojix.com/archives
> ```
Done, and restarted both services, but I'm not seeing a difference when I
go to <https://lists.netlojix.com/hyperkitty/api/> (I was getting a "Page
not found", and still get that).
> but it wouldn't hurt to add the `^postorius/` and `^hyperkitty/` patterns
> to urls.py anyway.
3 years, 1 month
[MM3-users] Re: Postorius no connection to REST API
by Richard Rosner
Mark Sapiro wrote:
> > You are in a better position to answer that than am I.
> What does sudo netstat -lntp show?
A lot. But since most of that isn't relevant here:
Proto Recv-Q Send-Q Local Address Foreign Address State PID/Program name
tcp 0 0 0.0.0.0:465 0.0.0.0:* LISTEN 20241/master
tcp 0 0 127.0.0.1:8024 0.0.0.0:* LISTEN 14076/python3
tcp 0 0 0.0.0.0:25 0.0.0.0:* LISTEN 20241/master
tcp 0 0 127.0.0.1:8001 0.0.0.0:* LISTEN 14080/python3
tcp 0 0 0.0.0.0:587 0.0.0.0:* LISTEN 20241/master
tcp6 0 0 :::80 :::* LISTEN 13882/apache2
tcp6 0 0 :::465 :::* LISTEN 20241/master
tcp6 0 0 :::25 :::* LISTEN 20241/master
tcp6 0 0 :::443 :::* LISTEN 13882/apache2
tcp6 0 0 :::587 :::* LISTEN 20241/master
> What does ps -fwwa|grep rest show?
root 15055 14843 0 12:58 pts/1 00:00:00 grep rest
So whatever it's supposed to find, it's not there
> > mailman3-web.service must also run as list.
I changed that. It didn't like it.
systemctl status mailman3-web.service
● mailman3-web.service - Mailman3-web uWSGI service
Loaded: loaded (/lib/systemd/system/mailman3-web.service; enabled; vendor preset: enabled)
Active: failed (Result: exit-code) since Wed 2021-08-11 13:05:39 CEST; 32s ago
Docs: file:///usr/share/doc/mailman3-web/README.rst
Process: 15570 ExecStart=/usr/bin/uwsgi --plugin python3 --ini /etc/mailman3/uwsgi.ini (code=exited, status=1/FAILURE)
Main PID: 15570 (code=exited, status=1/FAILURE)
Status: "initializing uWSGI"
Aug 11 13:05:39 mail systemd[1]: Starting Mailman3-web uWSGI service...
Aug 11 13:05:39 mail systemd[1]: mailman3-web.service: Main process exited, code=exited, status=1/FAILURE
Aug 11 13:05:39 mail systemd[1]: mailman3-web.service: Failed with result 'exit-code'.
Aug 11 13:05:39 mail systemd[1]: Failed to start Mailman3-web uWSGI service.
Aug 11 13:05:39 mail systemd[1]: mailman3-web.service: Service RestartSec=100ms expired, scheduling restart.
Aug 11 13:05:39 mail systemd[1]: mailman3-web.service: Scheduled restart job, restart counter is at 5.
Aug 11 13:05:39 mail systemd[1]: Stopped Mailman3-web uWSGI service.
Aug 11 13:05:39 mail systemd[1]: mailman3-web.service: Start request repeated too quickly.
Aug 11 13:05:39 mail systemd[1]: mailman3-web.service: Failed with result 'exit-code'.
Aug 11 13:05:39 mail systemd[1]: Failed to start Mailman3-web uWSGI service.
> > So, what do you have in your apache config for proxying to uwsgi and
> what's your uwsgi configuration.
lists-ssl.conf:
<VirtualHost *:443>
ServerAdmin admin(a)domain.de
ServerName lists.domain.de
Alias /mailman3/favicon.ico /var/lib/mailman3/web/static/postorius/img/favicon.ico
Alias /mailman3/static /var/lib/mailman3/web/static
<Directory "/var/lib/mailman3/web/static">
Require all granted
</Directory>
<IfModule mod_proxy_uwsgi.c>
ProxyPass /mailman3/favicon.ico !
ProxyPass /mailman3/static !
ProxyPass "/mailman3" "unix:/run/mailman3-web/uwsgi.sock|uwsgi://localhost:8001/"
</IfModule>
# SSL Engine Switch:
# Enable/Disable SSL for this virtual host.
SSLEngine on
SSLCertificateFile /etc/ssl/certs/lists.domain.de.cert.pem
SSLCertificateKeyFile /etc/ssl/private/lists.domain.de.private.pem
SSLCertificateChainFile /etc/ssl/certs/dfnca.pem
SSLCACertificateFile /etc/ssl/certs/rwthcert.pem
SSLProtocol all -SSLv3 -TLSv1 -TLSv1.1
Protocols h2 http/1.1
SSLCipherSuite ECDHE-ECDSA-CHACHA20-POLY1305:ECDHE-RSA-CHACHA20-POLY1305:ECDHE-ECDSA-AES256-GCM-SHA384:ECDHE-RSA-AES256-GCM-SHA384:ECDHE-ECDSA-AES128-GCM-SHA256:ECDHE-RSA-AES128-GCM-SHA256:DHE-RSA-AES256-GCM-SHA384:DHE-RSA-AES128-GCM-SHA256
SSLHonorCipherOrder off
#RewriteEngine on
#RewriteRule ^/$ https://lists.domain.de/listinfo
Header always set Strict-Transport-Security "max-age=15768000; includeSubDomains; preload"
Header always set X-Frame-Options: "SAMEORIGIN"
Header always set X-Xss-Protection "1; mode=block"
Header always set X-Content-Type-Options "nosniff"
Header always set Content-Security-Policy "default-src 'self' *.domain.de; script-src 'self' *.domain.de; connect-src 'self' *.domain.de; img-src 'self' *.domain.de; style-src 'self' 'unsafe-inline' *.domain.de; object-src 'self' *.domain.de; frame-src 'self' *.domain.de;"
Header always set Referrer-Policy "no-referrer-when-downgrade"
</VirtualHost>
<VirtualHost *:80>
RewriteEngine On
RewriteRule ^(.*)$ https://%{HTTP_HOST}$1 [R=301,L]
</VirtualHost>
I guess with uwsgi config you mean the /etc/mailman3/uwsgi.ini file?
[uwsgi]
# Port on which uwsgi will be listening.
uwsgi-socket = /run/mailman3-web/uwsgi.sock
#Enable threading for python
enable-threads = true
# Move to the directory wher the django files are.
chdir = /usr/share/mailman3-web
# Use the wsgi file provided with the django project.
wsgi-file = wsgi.py
# Setup default number of processes and threads per process.
master = true
process = 2
threads = 2
# Drop privielges and don't run as root.
uid = www-data
gid = www-data
plugins = python3
# Setup the django_q related worker processes.
attach-daemon = python3 manage.py qcluster
# Setup hyperkitty's cron jobs.
#unique-cron = -1 -1 -1 -1 -1 ./manage.py runjobs minutely
#unique-cron = -15 -1 -1 -1 -1 ./manage.py runjobs quarter_hourly
#unique-cron = 0 -1 -1 -1 -1 ./manage.py runjobs hourly
#unique-cron = 0 0 -1 -1 -1 ./manage.py runjobs daily
#unique-cron = 0 0 1 -1 -1 ./manage.py runjobs monthly
#unique-cron = 0 0 -1 -1 0 ./manage.py runjobs weekly
#unique-cron = 0 0 1 1 -1 ./manage.py runjobs yearly
# Setup the request log.
#req-logger = file:/var/log/mailman3/web/mailman-web.log
# Log cron seperately.
#logger = cron file:/var/log/mailman3/web/mailman-web-cron.log
#log-route = cron uwsgi-cron
# Log qcluster commands seperately.
#logger = qcluster file:/var/log/mailman3/web/mailman-web-qcluster.log
#log-route = qcluster uwsgi-daemons
# Last log and it logs the rest of the stuff.
#logger = file:/var/log/mailman3/web/mailman-web-error.log
logto = /var/log/mailman3/web/mailman-web.log
5 years
[MM3-users] Re: LTMP to Postfix problem
by Brian Carpenter
On 6/18/20 7:36 PM, Mark Sapiro wrote:
> Check your system logs to see if there's anything about the OS killing
> the process. Also check the Postfix log for deliveries to mailman just
> before it died. Just stabbing in the dark, but maybe some huge message
> caused it to grow beyond some memory limit and get killed by the OS.
I am replying off list at this point. It is definitely a OOM issue. Here
are the log entries right before ltmp crashed:
Jun 18 00:00:12 mm4 kernel: [19548549.158382] postgres invoked
oom-killer: gfp_mask=0x6200ca(GFP_HIGHUSER_MOVABLE), nodemask=(null),
order=0, oom_score_adj=0
Jun 18 00:00:12 mm4 kernel: [19548549.160719] postgres cpuset=/
mems_allowed=0
Jun 18 00:00:12 mm4 kernel: [19548549.161524] CPU: 0 PID: 7243 Comm:
postgres Not tainted 4.19.0-6-amd64 #1 Debian 4.19.67-2
Jun 18 00:00:12 mm4 kernel: [19548549.163047] Hardware name: QEMU
Standard PC (Q35 + ICH9, 2009), BIOS
rel-1.12.0-0-ga698c8995f-prebuilt.qemu.org 04/01/2014
Jun 18 00:00:12 mm4 kernel: [19548549.164885] Call Trace:
Jun 18 00:00:12 mm4 kernel: [19548549.165402] dump_stack+0x5c/0x80
Jun 18 00:00:12 mm4 kernel: [19548549.166097] dump_header+0x6b/0x283
Jun 18 00:00:12 mm4 kernel: [19548549.167019] ?
do_try_to_free_pages+0x2ec/0x370
Jun 18 00:00:12 mm4 kernel: [19548549.167864]
oom_kill_process.cold.30+0xb/0x1cf
Jun 18 00:00:12 mm4 kernel: [19548549.168760] ? oom_badness+0x23/0x140
Jun 18 00:00:12 mm4 kernel: [19548549.169534] out_of_memory+0x1a5/0x430
Jun 18 00:00:12 mm4 kernel: [19548549.170174]
__alloc_pages_slowpath+0xbd8/0xcb0
Jun 18 00:00:12 mm4 kernel: [19548549.171060]
__alloc_pages_nodemask+0x28b/0x2b0
Jun 18 00:00:12 mm4 kernel: [19548549.171973] filemap_fault+0x3bd/0x780
Jun 18 00:00:12 mm4 kernel: [19548549.172643] ? alloc_set_pte+0xf2/0x560
Jun 18 00:00:12 mm4 kernel: [19548549.173369] ?
filemap_map_pages+0x1ed/0x3a0
Jun 18 00:00:12 mm4 kernel: [19548549.174404]
ext4_filemap_fault+0x2c/0x40 [ext4]
Jun 18 00:00:12 mm4 kernel: [19548549.175259] __do_fault+0x36/0x130
Jun 18 00:00:12 mm4 kernel: [19548549.175930] __handle_mm_fault+0xe6c/0x1270
Jun 18 00:00:12 mm4 kernel: [19548549.176765] handle_mm_fault+0xd6/0x200
Jun 18 00:00:12 mm4 kernel: [19548549.177644] __do_page_fault+0x249/0x4f0
Jun 18 00:00:12 mm4 kernel: [19548549.178407] ? async_page_fault+0x8/0x30
Jun 18 00:00:12 mm4 kernel: [19548549.179156] async_page_fault+0x1e/0x30
Jun 18 00:00:12 mm4 kernel: [19548549.179915] RIP: 0033:0x55d875a3fe10
Jun 18 00:00:12 mm4 kernel: [19548549.180569] Code: Bad RIP value.
Jun 18 00:00:12 mm4 kernel: [19548549.181181] RSP: 002b:00007ffcad32f248
EFLAGS: 00010206
Jun 18 00:00:12 mm4 kernel: [19548549.182132] RAX: 000055d877d512b0 RBX:
000055d877d60b93 RCX: 00007ffcad32f2c0
Jun 18 00:00:12 mm4 kernel: [19548549.183365] RDX: 0000000000000005 RSI:
000055d877d60b93 RDI: 000055d877d512b0
Jun 18 00:00:12 mm4 kernel: [19548549.184712] RBP: 00007ffcad32f270 R08:
0000000000000001 R09: 00007ffcad32f388
Jun 18 00:00:12 mm4 kernel: [19548549.186338] R10: 00007f2585002d40 R11:
0000000000000000 R12: 0000000000000005
Jun 18 00:00:12 mm4 kernel: [19548549.187583] R13: 000055d877d4b3a0 R14:
00007f2581ad05b8 R15: 0000000000000000
Jun 18 00:00:12 mm4 kernel: [19548549.188952] Mem-Info:
Jun 18 00:00:12 mm4 kernel: [19548549.189468] active_anon:197899
inactive_anon:206498 isolated_anon:0
Jun 18 00:00:12 mm4 kernel: [19548549.189468] active_file:253
inactive_file:278 isolated_file:23
Jun 18 00:00:12 mm4 kernel: [19548549.189468] unevictable:0 dirty:0
writeback:0 unstable:0
Jun 18 00:00:12 mm4 kernel: [19548549.189468] slab_reclaimable:21867
slab_unreclaimable:55017
Jun 18 00:00:12 mm4 kernel: [19548549.189468] mapped:17008 shmem:24450
pagetables:4890 bounce:0
Jun 18 00:00:12 mm4 kernel: [19548549.189468] free:13184 free_pcp:340
free_cma:0
Jun 18 00:00:12 mm4 kernel: [19548549.195739] Node 0
active_anon:791596kB inactive_anon:825992kB active_file:1012kB
inactive_file:1112kB unevictable:0kB isolated(anon):0kB
isolated(file):92kB mapped:68032kB dirty$
Jun 18 00:00:12 mm4 kernel: [19548549.200559] Node 0 DMA free:8152kB
min:352kB low:440kB high:528kB active_anon:1056kB inactive_anon:5048kB
active_file:0kB inactive_file:0kB unevictable:0kB writepending:0kB prese$
Jun 18 00:00:12 mm4 kernel: [19548549.204993] lowmem_reserve[]: 0 1950
1950 1950 1950
Jun 18 00:00:12 mm4 kernel: [19548549.205877] Node 0 DMA32 free:44584kB
min:44700kB low:55872kB high:67044kB active_anon:790540kB
inactive_anon:820944kB active_file:1012kB inactive_file:1112kB
unevictable:0kB wri$
Jun 18 00:00:12 mm4 kernel: [19548549.211109] lowmem_reserve[]: 0 0 0 0 0
Jun 18 00:00:12 mm4 kernel: [19548549.211826] Node 0 DMA: 8*4kB (UE)
31*8kB (UME) 20*16kB (UME) 22*32kB (UME) 13*64kB (UME) 5*128kB (UME)
5*256kB (UM) 4*512kB (UM) 2*1024kB (UM) 0*2048kB 0*4096kB = 8152kB
Jun 18 00:00:12 mm4 kernel: [19548549.214414] Node 0 DMA32: 378*4kB
(UMEH) 472*8kB (UEH) 412*16kB (UEH) 196*32kB (UMEH) 63*64kB (UMEH)
63*128kB (UE) 16*256kB (UE) 4*512kB (ME) 0*1024kB 2*2048kB (M) 1*4096kB
(M) =$
Jun 18 00:00:12 mm4 kernel: [19548549.217336] Node 0 hugepages_total=0
hugepages_free=0 hugepages_surp=0 hugepages_size=1048576kB
Jun 18 00:00:12 mm4 kernel: [19548549.218937] Node 0 hugepages_total=0
hugepages_free=0 hugepages_surp=0 hugepages_size=2048kB
Jun 18 00:00:12 mm4 kernel: [19548549.220513] 39729 total pagecache pages
Jun 18 00:00:12 mm4 kernel: [19548549.221286] 14715 pages in swap cache
Jun 18 00:00:12 mm4 kernel: [19548549.222022] Swap cache stats: add
10809560, delete 10794845, find 18524127383/18527544787
Jun 18 00:00:12 mm4 kernel: [19548549.223482] Free swap = 0kB
Jun 18 00:00:12 mm4 kernel: [19548549.224081] Total swap = 524284kB
Jun 18 00:00:12 mm4 kernel: [19548549.224712] 524154 pages RAM
Jun 18 00:00:12 mm4 kernel: [19548549.225222] 0 pages HighMem/MovableOnly
Jun 18 00:00:12 mm4 kernel: [19548549.225894] 13385 pages reserved
Then there was this little bit of info:
Jun 18 00:00:12 mm4 kernel: [19548549.442555] Out of memory: Kill
process 29676 (python3) score 37 or sacrifice child
Jun 18 00:00:12 mm4 kernel: [19548549.444508] Killed process 29676
(python3) total-vm:192224kB, anon-rss:93084kB, file-rss:0kB, shmem-rss:0kB
Jun 18 00:00:12 mm4 kernel: [19548549.464907] oom_reaper: reaped process
29676 (python3), now anon-rss:0kB, file-rss:0kB, shmem-rss:0kB
I suspect the above process was ltmp.
So the server has 2 gig of ram with about a dozen MM3 lists on it. Is
this an issue with tuning performance of the Postgresql server or do I
need to add more memory. I am curious how much ram your server is
running and if you had run into any OOM of problems.
If you want me to post this to the list, I will.
--
Please let me know if you need further assistance.
Thank you for your business. We appreciate our clients.
Brian Carpenter
EMWD.com
--
EMWD's Knowledgebase:
https://clientarea.emwd.com/index.php/knowledgebase
EMWD's Community Forums
http://discourse.emwd.com/
6 years, 2 months
[MM3-users] Re: search this list searches more then just this list
by Marco van Tol
Op 26 jan 2024, om 22:55 heeft Mark Sapiro <mark(a)msapiro.net> het volgende geschreven:
> On 1/26/24 02:44, Marco van Tol wrote:
>> Op 25 jan 2024, om 14:16 heeft Marco van Tol <mvantol(a)ripe.net> het volgende geschreven:
>>>
>>> Okay, so, I got a bit further, but something still gets stuck.
>>>
>>> Here’s what I did.
>>> Keep in mind I’m using containers that are built from some CI/CD pipeline, so I updated the pipeline to apply the patch attached to this email to `/usr/lib/python3.11/site-packages/xapian_backend.py`.
>>>
>>> Before I had 2 list servers with the “Term too long” issue, 1 got resolved by this, and the other did not.
>>> I opened a shell in the newly deployed container to confirm the patch was applied in it.
>>>
>>> The other attachment to this email is a copy/paste from the full error from `./manage.py rebuild_index`.
>>>
>>> Is there something else special in the email that makes it choke that evades the xapian patch?
>>>
>>> Thank you very much in advance!
>
> The message above with the attached "full error" never got to the list. What is the error report?
Hm, I see. Not sure why. The reply I got from mail.mailman3.org <http://mail.mailman3.org/> at 2024-01-25 13:16:25.486 UTC was:
"250 2.0.0 Ok: 12772 bytes queued as 55AFD105C02”
I’m pasting it at the bottom of this email. Sorry it didn’t come through.
>> I tried to change to ‘hash’, but the code in that bit of the function has not been tested enough.
>> For example `hole = sha224(hole.encode('utf8')).hexdigest()` comes back with that the bytes object hole does not have an encode() method.
>> When I change it to `hole = sha224(hole).hexdigest()`, the following error is:
>
> That's only part of it. You need
>
> hole = sha224(hole).hexdigest().encode('utf8')
I ended up changing it to this, which fixed that bit, and led to the next issue. :)
>> text = text[:match.start()] + hole + text[match.end():]
>> TypeError: can't concat str to bytes
>> The ‘hash’ part of that function needs some debugging.
>
>
> Yes, presumably because no one sets `XAPIAN_LONG_TERM_METHOD=hash` in the environment. Do you have a reason for this?
I wanted to check and see if I could avoid the “Term too long (>245)" issue this way, but I haven’t gotten to the point where xapian is successful.
Right now I’m back at the original issue as I see no other solution than to go back to whoosh.
Thanks!
Marco van Tol
Paste:
----
Indexing 194620 emails
[ERROR/MainProcess] Failed indexing 156001 - 157000 (retry 5/5): Term too long (> 245): XSUBJECThttp://www.google.com/url?q=%68%74%74%70%73%3a%2f%2f%68%64%72%65%64… (pid 32): Term too long (> 245): XSUBJECThttp://www.google.com/url?q=%68%74%74%70%73%3a%2f%2f%68%64%72%65%64…
Traceback (most recent call last):
File "/usr/lib/python3.11/site-packages/haystack/management/commands/update_index.py", line 119, in do_update
backend.update(index, current_qs, commit=commit)
File "/usr/lib/python3.11/site-packages/xapian_backend.py", line 98, in wrapper
func(self, *args, **kwargs)
File "/usr/lib/python3.11/site-packages/xapian_backend.py", line 505, in update
database.replace_document(document_id, document)
xapian.InvalidArgumentError: Term too long (> 245): XSUBJECThttp://www.google.com/url?q=%68%74%74%70%73%3a%2f%2f%68%64%72%65%64…
[ERROR/MainProcess] Error updating hyperkitty using default
Traceback (most recent call last):
File "/usr/lib/python3.11/site-packages/haystack/management/commands/update_index.py", line 297, in handle
self.update_backend(label, using)
File "/usr/lib/python3.11/site-packages/haystack/management/commands/update_index.py", line 342, in update_backend
max_pk = do_update(
^^^^^^^^^^
File "/usr/lib/python3.11/site-packages/haystack/management/commands/update_index.py", line 119, in do_update
backend.update(index, current_qs, commit=commit)
File "/usr/lib/python3.11/site-packages/xapian_backend.py", line 98, in wrapper
func(self, *args, **kwargs)
File "/usr/lib/python3.11/site-packages/xapian_backend.py", line 505, in update
database.replace_document(document_id, document)
xapian.InvalidArgumentError: Term too long (> 245): XSUBJECThttp://www.google.com/url?q=%68%74%74%70%73%3a%2f%2f%68%64%72%65%64…
Traceback (most recent call last):
File "/opt/mailman-web/./manage.py", line 10, in <module>
execute_from_command_line(sys.argv)
File "/usr/lib/python3.11/site-packages/django/core/management/__init__.py", line 446, in execute_from_command_line
utility.execute()
File "/usr/lib/python3.11/site-packages/django/core/management/__init__.py", line 440, in execute
self.fetch_command(subcommand).run_from_argv(self.argv)
File "/usr/lib/python3.11/site-packages/django/core/management/base.py", line 402, in run_from_argv
self.execute(*args, **cmd_options)
File "/usr/lib/python3.11/site-packages/django/core/management/base.py", line 448, in execute
output = self.handle(*args, **options)
^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
File "/usr/lib/python3.11/site-packages/haystack/management/commands/rebuild_index.py", line 65, in handle
call_command("update_index", **update_options)
File "/usr/lib/python3.11/site-packages/django/core/management/__init__.py", line 198, in call_command
return command.execute(*args, **defaults)
^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
File "/usr/lib/python3.11/site-packages/django/core/management/base.py", line 448, in execute
output = self.handle(*args, **options)
^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
File "/usr/lib/python3.11/site-packages/haystack/management/commands/update_index.py", line 297, in handle
self.update_backend(label, using)
File "/usr/lib/python3.11/site-packages/haystack/management/commands/update_index.py", line 342, in update_backend
max_pk = do_update(
^^^^^^^^^^
File "/usr/lib/python3.11/site-packages/haystack/management/commands/update_index.py", line 119, in do_update
backend.update(index, current_qs, commit=commit)
File "/usr/lib/python3.11/site-packages/xapian_backend.py", line 98, in wrapper
func(self, *args, **kwargs)
File "/usr/lib/python3.11/site-packages/xapian_backend.py", line 505, in update
database.replace_document(document_id, document)
xapian.InvalidArgumentError: Term too long (> 245): XSUBJECThttp://www.google.com/url?q=%68%74%74%70%73%3a%2f%2f%68%64%72%65%64…
----
2 years, 6 months
[MM3-users] Re: External MTA incoming mail: configuration
by Odhiambo Washington
On Tue, Aug 6, 2024 at 10:46 AM Roland Giesler via Mailman-users <
mailman-users(a)mailman3.org> wrote:
> On 2024/08/05 19:59, Mark Sapiro wrote:
> > I see this reply is now moot as you have now configured list mail to
> > go directly to the Mailman server, but ...
> >
> > On 8/5/24 03:44, Roland Giesler via Mailman-users wrote:
> >>
> >> In the logs of the MTA I see this however: warning: do not list
> >> domain fast.za.net in BOTH virtual_mailbox_domains and relay_domains
> >>
> >> Mailman creates these entries, but postfix doesn't like it. I don't
> >> see any mail delivered to the mailman yet. Is this the problem?
> >
> > Probably not. It is telling you that mail to the fast.za.net domain
> > cannot both be delivered to local mailboxes (virtual_mailbox_domains)
> > and relayed to foreign hosts (relay_domains)
> >
> Thanks, yes, I have since assumed that to be the case.
> >
> >> In the MTA postfix main.cf:
> >>
> >> relay_domains = hash:/etc/mailman3/data/postfix_domains
> > >
> >> cat /etc/mailman3/data/postfix_domains
> >> ...
> >>
> >> and also
> >>
> >> local_recipient_maps=$virtual_mailbox_maps,
> >> hash:/etc/mailman3/data/postfix_lmtp
> >>
> >> cat /etc/mailman3/data/postfix_lmtp
> >> ...
> >
> > How about
> >
> > transport_maps = hash:/etc/mailman3/data/postfix_lmtp
> I can't remove the $virtual_mailbox_maps entry, since Power-mailinbox
> (PMiaB) uses that. It may make Mailman3 work, but break PMiaB).
> >
> >
> >>
> >> Then there's:
> >> virtual_mailbox_domains=sqlite:/etc/postfix/virtual-mailbox-domains.cf
> >>
> >> cat /etc/postfix/virtual-mailbox-domains.cf
> >> dbpath=/home/user-data/mail/users.sqlite
> >> query = SELECT 1 FROM users WHERE email LIKE '%%@%s' UNION SELECT 1
> >> FROM aliases WHERE source LIKE '%%@%s' UNION SELECT 1 FROM
> >> auto_aliases WHERE source LIKE '%%@%s'
> >>
> >> When I run that query in sqlite3, it returns no records, so I'm not
> >> sure how this is supposed to work. %s to me means that first
> >> argument, so is this used in python and then %s is the argument sent
> >> to this query?
> >
> >
> > See https://www.postfix.org/sqlite_table.5.html
> >
> > `%%` is replaced with `%` which is a SQL wildcard matching anything
> > and `%s` is replaced by the key postfix is looking for, i.e. the
> > domain that it is asking about.
> >
> > So, that query becomes
> >
> > SELECT 1 FROM users WHERE email LIKE '%(a)fast.za.net' UNION SELECT 1
> > FROM aliases WHERE source LIKE '%(a)fast.za.net' UNION SELECT 1 FROM
> > auto_aliases WHERE source LIKE '%(a)fast.za.net'
> >
> > I.e, it returns true if any user or alias or auto_alias has an address
> > ending in '@fast.za.net' and if that's true the mail to any
> > '@fast.za.net' address including list mail will be stored locally.
>
> Ah, thank you! I created a ticket at MiaB about this, so I'll post your
> response there. The %s had be stumped at first, but now it's clear.
>
>
> >
> > If you really have local users on box2.gtahardware.co.za with
> > addresses '@fast.za.net' and you want to relay list mail to lists
> > '@fast.za.net', you need to see
> >
> https://docs.mailman3.org/projects/mailman/en/latest/src/mailman/docs/mta.h…
> .
>
> Thank you for that! From that it seems it may still be possible to use
> PMiaB as my MTA after, but I'll work through that reference and test it
> and report back.
>
I think that ALL MTAs have the concept of local domains (for which mails
are delivered to 'local mailboxes') and remote domains (aka relay domains)
for which mail is relayed to another host which has the mailboxes.
So in your case box2.gtahardware.co.za (this is FQDN) could be handling
local emails, e.g roland(a)gtahardware.co.za, johndoe(a)gtahardware.co.za, etc.
Those are local, and so gtahardware.co.za is a local domain. However,
fast.za.net is a relay domain and all mail to XXX(a)fast.za.net should be
relayed to the MM3 server.
If your MTA does not have this concept, then it's either not ready for
prime time or it wasn't intended to have such ability.
--
Best regards,
Odhiambo WASHINGTON,
Nairobi,KE
+254 7 3200 0004/+254 7 2274 3223
In an Internet failure case, the #1 suspect is a constant: DNS.
"Oh, the cruft.", egrep -v '^$|^.*#' ¯\_(ツ)_/¯ :-)
[How to ask smart questions:
http://www.catb.org/~esr/faqs/smart-questions.html]
2 years
[MM3-users] Re: Subscription Request asking for Confirmation instead of Moderation
by Henry Hartley
> -----Original Message-----
> From: Mark Sapiro <mark(a)msapiro.net>
> Sent: Wednesday, August 27, 2025 21:10
>
> On 8/27/25 09:22, Henry Hartley via Mailman-users wrote:
> >
> > 1. Are there particular headers that are causing the email to go to the
> Confirmation page instead of the Approval page? Or are there particular
> headers we can add that will help with this?
> > 2. Is there any way for us to move an address from the Confirmation
> Pending page to confirmed on the backend (preferably through the web
> interface, but on the server itself, if necessary)?
> >
> > Here are the headers sent with the subscriber's email address changed to
> FirstLast(a)SCHOOL.edu and our BCC mailbox domain changed to COMPANY.com.
> >
> > MIME-Version: 1.0
> > Content-Type: text/plain; charset=UTF-8; format=flowed; delsp=yes
> > Content-Transfer-Encoding: 8Bit
> > X-Mailer: Drupal
> > Return-Path: FirstLast(a)SCHOOL.edu
> > Sender: FirstLast(a)SCHOOL.edu
> > From: FirstLast(a)SCHOOL.edu
> > Bcc: mailman-noreply(a)COMPANY.com
>
> Are these all the headers? If so, you need a To: header. sending the envelope to
> the list-join address is not sufficient. The message must either have a To: to the
> list-join address or a To: to the list-request address with a Subject: or body of
> `join`
That's what I was given and I didn't look at it carefully enough. My apologies. There was indeed a To: header, so it wasn't that. I got a copy of the actual email and was able to see all the headers, which I've pasted below (with the exception of two X-Microsoft-Antispam-xxx headers, which are fairly long). I've anonymized it similarly to the above as well as changing the IP address to 192.169.0.0, which is not what's really there. Note also that the mailto: links above (and below, if applicable) are not in the text I'm pasting but have been added somewhere along the line.
Received: from CO1PR05MB8586.namprd05.prod.outlook.com (2603:10b6:303:ed::5)
by LV8PR05MB10549.namprd05.prod.outlook.com with HTTPS; Fri, 8 Aug 2025
16:57:54 +0000
Received: from DM6PR02CA0123.namprd02.prod.outlook.com (2603:10b6:5:1b4::25)
by CO1PR05MB8586.namprd05.prod.outlook.com (2603:10b6:303:ed::5) with
Microsoft SMTP Server (version=TLS1_2,
cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.9009.18; Fri, 8 Aug
2025 16:57:52 +0000
Received: from DS3PEPF0000C37A.namprd04.prod.outlook.com
(2603:10b6:5:1b4:cafe::9e) by DM6PR02CA0123.outlook.office365.com
(2603:10b6:5:1b4::25) with Microsoft SMTP Server (version=TLS1_3,
cipher=TLS_AES_256_GCM_SHA384) id 15.20.9009.15 via Frontend Transport; Fri,
8 Aug 2025 16:57:52 +0000
Authentication-Results: spf=fail (sender IP is 192.168.0.0)
smtp.mailfrom=SCHOOL.edu; dkim=none (message not signed)
header.d=none;dmarc=fail action=oreject
header.from=SCHOOL.edu;compauth=fail reason=000
Received-SPF: Fail (protection.outlook.com: domain of SCHOOL.edu does not
designate 192.168.0.0 as permitted sender)
receiver=protection.outlook.com; client-ip=192.168.0.0;
helo=esa2.COMPANY.iphmx.com;
Received: from esa2.COMPANY.iphmx.com (192.168.0.0) by
DS3PEPF0000C37A.mail.protection.outlook.com (10.167.23.4) with Microsoft SMTP
Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id
15.20.9009.8 via Frontend Transport; Fri, 8 Aug 2025 16:57:52 +0000
X-CSE-ConnectionGUID: 6gzl16giR+OI2R+uEItzYA==
X-CSE-MsgGUID: N0dF+IkxQxqpO1VcWOCK3A==
X-IronPort-AV: E=Sophos;i="6.17,274,1747713600";
d="scan'208";a="40347776"
Received: from ex2019-3.COMPANY.com ([74.119.60.23])
by esa2.COMPANY.iphmx.com with ESMTP/TLS/ECDHE-RSA-AES128-GCM-SHA256; 08 Aug 2025 12:57:50 -0400
Received: from EX2019-1.COMPANY.com (10.1.146.19) by EX2019-3.COMPANY.com
(10.1.146.21) with Microsoft SMTP Server (version=TLS1_2,
cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.2.1748.26; Fri, 8 Aug
2025 12:57:50 -0400
Received: from COmailout.COMPANY.com (10.1.146.69) by EX2019-1.COMPANY.com
(10.1.146.19) with Microsoft SMTP Server id 15.2.1748.26 via Frontend
Transport; Fri, 8 Aug 2025 12:57:50 -0400
Received: from WEBSERVER.COMPANY.com ([10.115.9.208]) by COmailout.COMPANY.com over TLS secured channel with Microsoft SMTPSVC(10.0.17763.1697);
Fri, 8 Aug 2025 12:57:50 -0400
Received: by WEBSERVER.COMPANY.com (Postfix, from userid 33)
id 998892A0BDB; Fri, 8 Aug 2025 12:57:48 -0400 (EDT)
To: <MAILINGLIST-join(a)DOMAIN.org>
Subject: Subscribe
MIME-Version: 1.0
Content-Type: text/plain; charset="UTF-8"; format=flowed; delsp=yes
Content-Transfer-Encoding: quoted-printable
X-Mailer: Drupal
Sender: <FIRSTLAST(a)SCHOOL.edu>
From: <FIRSTLAST(a)SCHOOL.edu>
Message-ID: <20250808165748.998892A0BDB(a)WEBSERVER.COMPANY.com>
Date: Fri, 8 Aug 2025 12:57:48 -0400
Return-Path: FIRSTLAST(a)SCHOOL.edu
X-OriginalArrivalTime: 08 Aug 2025 16:57:50.0067 (UTC) FILETIME=[92CA3430:01DC0885]
X-MS-Exchange-Organization-ExpirationStartTime: 08 Aug 2025 16:57:52.4416
(UTC)
X-MS-Exchange-Organization-ExpirationStartTimeReason: OriginalSubmit
X-MS-Exchange-Organization-ExpirationInterval: 1:00:00:00.0000000
X-MS-Exchange-Organization-ExpirationIntervalReason: OriginalSubmit
X-MS-Exchange-Organization-Network-Message-Id:
ba671e8c-86f5-429d-8c2d-08ddd69cb6ab
X-EOPAttributedMessage: 0
X-EOPTenantAttributedMessage: a066de23-9711-4de4-8725-431a39ebcafb:0
X-MS-Exchange-Organization-MessageDirectionality: Incoming
X-MS-PublicTrafficType: Email
X-MS-TrafficTypeDiagnostic:
DS3PEPF0000C37A:EE_|CO1PR05MB8586:EE_|LV8PR05MB10549:EE_
X-MS-Exchange-Organization-AuthSource:
DS3PEPF0000C37A.namprd04.prod.outlook.com
X-MS-Exchange-Organization-AuthAs: Anonymous
X-MS-Office365-Filtering-Correlation-Id: ba671e8c-86f5-429d-8c2d-08ddd69cb6ab
X-MS-Exchange-Organization-ExpirationInterval: 0:12:30:00.0000000
X-MS-Exchange-Organization-ExpirationIntervalReason: TenantCustomized
X-MS-Exchange-AtpMessageProperties: SA|SL
X-MS-Exchange-Organization-SCL: -1
X-Microsoft-Antispam: BCL:0;ARA:13230040;
X-Forefront-Antispam-Report:
CIP:192.168.0.0;CTRY:US;LANG:en;SCL:-1;SRV:;IPV:CAL;SFV:SKN;H:esa2.COMPANY.iphmx.com;PTR:esa2.COMPANY.iphmx.com;CAT:NONE;SFS:(13230040);DIR:INB;
X-MS-Exchange-CrossTenant-OriginalArrivalTime: 08 Aug 2025 16:57:52.2718
(UTC)
X-MS-Exchange-CrossTenant-Network-Message-Id: ba671e8c-86f5-429d-8c2d-08ddd69cb6ab
X-MS-Exchange-CrossTenant-Id: a066de23-9711-4de4-8725-431a39ebcafb
X-MS-Exchange-CrossTenant-AuthSource:
DS3PEPF0000C37A.namprd04.prod.outlook.com
X-MS-Exchange-CrossTenant-AuthAs: Anonymous
X-MS-Exchange-CrossTenant-FromEntityHeader: Internet
X-MS-Exchange-Transport-CrossTenantHeadersStamped: CO1PR05MB8586
X-MS-Exchange-Transport-EndToEndLatency: 00:00:02.2435910
X-MS-Exchange-Processed-By-BccFoldering: 15.20.8989.011
--
Henry Hartley
Westat
RB 2151
11 months, 3 weeks
[MM3-users] Re: Custom templates (was: Re: Re: nginx configuration on a multitasking server)
by David Newman
On 1/14/22 4:54 PM, Mark Sapiro wrote:
> On 1/14/22 11:56 AM, David Newman wrote:
>>
>> I created a pending subscription request on a test list. Here is the
>> text I'm using in a file called 'list:admin:action:subscribe.txt'
>> (minus the rows of hypens):
>>
>> ----------
>>
>>
>> As list administrator, your authorization is required for a mailing
>> list subscription request approval:
>>
>> For: $member
>> List: $listname
>>
>> At your convenience, visit:
>>
>> https://${domain}/mailman/admindb/lists/${short_listname}.${domain}/
>
> This looks like a Mailman 2.1 URL. Are you sure you don't want something
> like
>
> https://${domain}/mailman3/lists/${short_listname}.${domain}/
Yes. The server redirects MM3-style requests to MM2.1 URLs. I need to
determine why, but that may be a different issue than the templates one.
There's nothing obvious in this vhost's nginx config that would generate
the redirect. Will check, if I can't resolve this I'll open a different
thread.
>
>>
>> to approve or deny the request.
>>
>> ----------
>>
>> Instead the message that goes out at midnight daily reads like this:
>
>
> That's a different message. It is sent from the `mailman notify` command
> run by cron. It's built from the list:admin:notice:pending template.
OK, wrong template then.
>
>>
>> On successive nights I have placed copies of the
>> 'list:admin:action:subscribe.txt' file above in these locations:
>>
>> mm/var/templates/lists/test.lists.domain.tld/en
>
> I hope you mean
>
> /opt/mailman/mm/var/templates/lists/test.lists.domain.tld/en
Yes
>
>> /opt/mailman/mm/var/templates/site/en
>
>
> Either of those should work. The lists one will take priority over the
> site one for that list.
>
>
>> and then in Postorius, with the same contents as above.
>
> If you set a template in Postorius, it takes priority. If you later
> decide you want to use one in /opt/mailman/mm/var/templates/ you have to
> delete the postorius one.
>
>
>> The file versions are owned by the mailman user, and have 0644
>> permissions. Not sure this is necessary but I've restarted the
>> mailman3 and mailmanweb services each time after a change.
>>
>> There is no sign of trouble in the MM3 or web logs. The only thing I
>> see is in the Postfix log, where the shorter and less helpful message
>> goes out each night. I don't see anything in the template docs about
>> this.
>>
>> Questions:
>>
>> 1. What to do to get the custom message working?
>
>
> It should work. I suspect you need to go to the list's Settings ->
> Automatic Responses and set `Admin immed notify` to Yes.
It's enabled. I think this triggers notifications only for new
subscription requests, not pending ones.
>
>
>> 2. Is there a way to trigger a subscribe reminder for one list only?
>
>
> If by subscribe reminder you mean the `list:admin:action:subscribe.txt`
> message, yes that's the above list setting. If you mean the one sent
> from the `mailman notify` command, see `mailman notify --help` for the
> options. You can specify one or more lists (default is all lists) via
> options and put them in your cron.
>
>
>> Asking because there are other lists on this server with other
>> requests pending, and I don't want to bother other moderators with
>> multiple reminders per day. Not a big deal, but it would be nice to
>> test this with one list rather than waiting up to 24 hours after each
>> change.
>
>
> You can test `mailman notify` at any time by running it by hand.
Thanks. This still isn't working as intended. I took these steps:
1. Created the file
'/opt/mailman/mm/var/templates/lists/test.lists.domain.tld/en/list:admin:action:pending.txt'
with these contents (minus the hyphens top and bottom):
----------
The $listname list has $count moderation requests waiting.
$data
At your convenience, visit:
https://${domain}/mailman3/lists/${short_listname}.${domain}/
to approve or deny the request.
----------
2. Restarted the mailman3 and mailmanweb services
3. As the mailman user, ran the command 'mailman notify -l
test.lists.domain.tld -v'
This generated an email message but its contents were the same as in my
previous post:
----------
The test(a)lists.domain.tld list has 1 moderation requests waiting.
Held Subscriptions:
User: letmein(a)domain.tld
Please attend to this at your earliest convenience.
----------
What I'm trying to do here is replicate a feature from MM2.1, where
pending notifications had URLs embedded in the message. That's not
available out of the box in MM3, and if there's a place for feature
requests I'd be glad to ask that this be made the default.
For now, though, I'm looking to get this customization working.
Thanks.
dn
4 years, 7 months
[MM3-users] Re: messages stuck in the bad queue
by Ken Alker
--On Sunday, June 25, 2023 9:18 AM -0700 Mark Sapiro <mark(a)msapiro.net>
wrote:
> On 6/24/23 9:54 PM, Ken Alker wrote:
>> I am working on a mail server that was migrated from mailman V2 to
>> mailman V3 in February. I just noticed that there are over 1000
>> messages in the bad queue. All of the messages in the bad queue are
>> dated 2/2/23 and all have a timestamp within a one-hour window of each
>> other.
>>
>> I used mailman qfile to inspect five random emails in the bad queue and
>> so far they are all "successfully subscribed" emails,
>
> This is a bit strange. See below.
>
>> but I presume
>> there are no guarantees there aren't others mixed in there that might be
>> legitimate emails (ie. I just unshunted 140 emails in the shunt queue
>> and they were all good emails and all got processed).
>
>
> Presumably these were shunted due to some issue that was subsequently
fixed.
That is my assumption. I didn't unshunt them until I had V3.3.8 completed,
figuring the previous version/install had some bug/mistake. Fortunately,
they all got processed (with one problem, which I brought up in another
thread).
>> I figure that the easiest way to inspect these 1000 emails is just to
>> have them re-delivered. I tried moving one from the bad queue to the
>> shunt queue and I ran "mailman unshunt" but nothing happened.
>
> What does nothing happened mean? "mailman unshunt" should move the
> message to the original queue which was stored in the 'whichq' attribute
> in the msgdata when the message was shunted. Since this wasn't a shunted
> message, there's no 'whichq' attribute so it goes to the 'in' queue.
> I.e., "mailman unshunt" would have moved the message from the 'shunt'
> queue to the 'in' queue. If the message wound up back in the shunt queue,
> there should be messages in mailman.log indicating why.
I moved the .psv file from the bad queue into the shunt queue. I then ran
"mailman unshunt" (as user 'mailman' while in the virtual environment). I
tailed mailman.log during this process and no logs were spit out. The date
stamp on the .psv file never changed (maybe it does not when being moved
between queues?) and, AFAICT, the file never moved from the shunt queue. I
waited maybe five minutes, tops.
>> Is there a way to reprocess the bad queue?
>
> You could just move the messages to the 'in' queue.
I just now tried moving the same message into the 'in' queue but, again,
nothing happened. I left it in there for five minutes. Do I have to run a
program to get it to act on the 'in' queue (I presume that there is a
"runner" that is always looking and taking care of this already as I
presume this is the queue where all 'normal' traffic is handled).
Here are the (obfusacted) results of "mailman qfile
/opt/mailman/mm/var/queue/shunt/1675389793.6945386+2aeaf0015558c9d8380c96142c3fa9d03a8142bc.psv"
(the message I was experimenting with):
[----- start pickle -----]
<----- start object 1 ----->
MIME-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Subject: THE-list subscription notification
From: email(a)obfuscated.com
To: the-list-owner(a)lists.obfuscated.com
Message-ID: <167538979369.2390432.521344217673230839(a)obfuscated.net>
Date: Thu, 02 Feb 2023 18:03:13 -0800
Precedence: bulk
user(a)domain.tld has been successfully subscribed to THE-list.
<----- start object 2 ----->
{ '_parsemsg': False,
'envsender': 'email(a)obfuscated.com',
'listid': 'the-list.obfusacted.com',
'nodecorate': True,
'recipients': {'person(a)domain.tld'},
'reduced_list_headers': True,
'version': 3}
[----- end pickle -----]
>> Also, what exactly is the bad queue?
>
> If Mailman's content filtering is enabled and Filter Action is Preserve,
> messages which have no remaining content after content filtering are put
> in the 'bad' queue. These are the only messages put there. When this
> happens there should a log message like
>
> <message-id> preserved in file base <queue_file>
>
> It is unclear to me how these 1000+ messages wound up in the 'bad' queue.
> If you have logs from Feb 2, they might help. My guess is there was some
> MTA misrouting that caused these list welcome messages (from some mass
> subscribe?) to be rerouted to the list posting address combined with some
> bad content filtering settings that removed all the content, but that
> seems pretty far fetched.
Unfortunately, I don't have logs going that far back. I don't think your
concept is far fetched. I'm 99% sure this was the day that the migration
from V2 to V3 took place so this was certainly the result of some type of
mass-subscription-import into V3. The V3 that was installed or the install
itself definitely had problems, which is why I just did an upgrade/overhaul
to V3.3.8 this past week. Many/most of the strange issues that were
occurring seem to be cleared up.
3 years, 1 month
[MM3-users] Time Stand Still
by Barry Warsaw
Somewhen in the dark recesses of intarweb history, I found myself as the project leader for both Jython (née JPython) and GNU Mailman. I'd been involved with Jython since it was invented by Jim Hugunin around the time he came to work with us at Pythonlabs. I'd been contributing to Mailman since we inherited John Viega's Python-based Dave Matthews Band list server, and put it to use replacing python.org's Majordomo installation.
I'd enjoyed both projects, but knew I could not lead both, so I had to make a choice. I chose to turn over Jython to a team that's done a much better job over the years than I ever could have. Something about email, and especially the communication and collaboration patterns that it facilitates, really fascinated me. I know, I know, but we all have our lapses of sanity. Mine has lasted almost 20 years, a bit more than "momentary" perhaps.
I've rarely gotten paid to work on Mailman, but it did provide me some great opportunities. Most notably it led to my 10 year stint at Canonical. I was originally hired on there to integrate mailing lists with Launchpad, and Mailman was the obvious choice. I learned a ton doing that project, and working within the constraints of integrating the two Python-based systems, especially since Launchpad was originally not free software and Mailman was GPL'd. Later, the Zope-based Launchpad source code was released under the AGPL, making much of the monkeypatching unnecessary, but by then the system was solid and reliable, and you don't fix what's not broken.
Except, I guess I did. I took a lot of the lessons from that work, along with a good hard look at all the problems with Mailman 2, and began to break another cardinal rule of software development: second system syndrome. The result is Mailman 3. It took forever, and we're still not at complete feature parity with Mailman 2, but at least it's Real Enough to be used at many Real Sites, including python.org and lists.fedoraprojects.org.
It would be ridiculous for me to take significant credit for this. I have to acknowledge the amazing user community -- you! -- for all the support, patches, suggestions, feedback, patience, criticism, donations, and contributions that you've given to the project, and to me personally over the years. And my deepest gratitude goes to all the core developers that have stayed or come and gone, but most especially the current Cabal: Abhilash Raj, Aurelien Bompard, Florian Fuchs, Mark Sapiro, Stephen J. Turnbull, Terri Oda. You should know that each and every one of them is truly awesome, both in what they contribute technically, and in their amazing friendships. Mailman is infinitely better because of their involvement, and I've loved spending time with them over the years at the Pycon sprints, making releases and sharing teas and meals.
My blog is called We Fear Change, and that's humorously taken from a 90's bit in Mike Myer's excellent Wayne's World movie (a phrase actually uttered by the brilliant Dana Carvey as Garth). The irony of course is that while we all may fear change, it's the one constant thing we can count on. And in fact, we *require* change to thrive, because if you aren't changing, you aren't alive. Time, and being engaged with life's vagaries, means there's no alternative to change; it must be embraced.
And so, with a vague reference to the many (good!) changes in my personal and professional life, I'm announcing that I'm stepping down from the project leadership role of GNU Mailman, effective... nowish! And it's with unanimous agreement among the GNU Mailman Steering Committee (a.k.a. the Mailman Cabal), that we are announcing Abhilash Raj as the new project leader.
If you don't recognize Abhilash's name, you probably aren't paying attention, at least to Mailman 3. Abhilash came to us in 2013 as a Google Summer of Code student, and he's become one of the project's most valuable contributors. His list of accomplishments is long, and it includes everything from redesigning the website, to integrating CI with our GitLab build system, porting our code to the SQLAlchemy ORM, adding MySQL support, revving up adoption through his Docker images, along with his great coding work on Core, Postorius, HyperKitty, and mailmanclient.
This transition is good for the project too. Email, its defining protocols and standards, and its role in our daily lives, has changed profoundly since the early days of Mailman. A fresh perspective and enthusiasm will help keep Mailman relevant to the changing ways we -- especially the FLOSS and tech communities -- communicate.
Please join me in supporting Abhilash in every way possible as he takes over in this new role as project leader. I'll be here when and if needed, even as I create space in my "spare" time for... Something Else. I look forward to the vision that Abhilash will bring to the project, and I know that he will do a great job. To me, Mailman has always been about collaboration, and the best
way for it to succeed is for you to continue to contribute your insights, experiences, opinions, and skills with positive intention.
-Barry
https://www.wefearchange.org/
8 years, 8 months