Re: problems installing mailman3 under gentoo and upgrading mailman2 to mailman3
by John Covici
On Sat, 13 Mar 2021 22:51:46 -0500,
Mark Sapiro wrote:
>
> On 3/13/21 7:08 PM, John Covici wrote:
> > On Sat, 13 Mar 2021 16:22:59 -0500,
> > Abhilash Raj wrote:
> >>
> >> My guess is that you updated the database (perhaps, by invoking the mailman
> >> command form 3.3.3) and then tried to start 3.3.2. In this case, Mailman comes
> >> up and sees a new revision for the database migration added from 3.3.3 but
> >> can’t find the same migration in its source (because it is 3.3.2).
> >
> > That is sort of what happened, except in the opposite direction, it
> > was from 3.3.3 to 3.3.2. My question is therefore, do I have to
> > update this alembic_version when I upgrade mailman to a newer version?
> > That is what I was getting at.
>
>
> Abhilash's conjecture is that the error was due to a Mailman version
> accessing a database that had been previously accessed by a newer
> version so that the version_num in the alembic_version table didn't
> exist in mailman/database/alembic/versions/. This normally would not
> occur on an upgrade of Mailman, but if you went from a gentoo Mailman
> core to a version obtained by pip, it's possible that the gentoo Mailman
> had an alembic version that wasn't known to the pip Mailman even though
> the pip Mailman was newer.
>
OK, thanks.
--
Your life is like a penny. You're going to lose it. The question is:
How do
you spend it?
John Covici wb2una
covici(a)ccs.covici.com
4 years, 3 months
Re: Edit archived email? Is it possible?
by Prasanth Nair
Hi Mark,
As you know, we can edit the individual messages using the message_id_hash.
Is there any possibility that we can edit the original message
which then updates all of the threads it has (for example, if someone
already replied to the original message)? Or do we need to edit each
message manually?
Kind regards,
Prasanth
On Wed, 29 Sept 2021 at 15:46, Prasanth Nair <prasanth.nair(a)linaro.org>
wrote:
> Hi Mark,
>
> Many thanks for your help. I have managed to modify some of the messages
> after following your instructions.
>
> Kind regards,
> Prasanth
>
> On Wed, 29 Sept 2021 at 08:08, Prasanth Nair <prasanth.nair(a)linaro.org>
> wrote:
>
>> Hi Mark,
>>
>> Thank you for your help. Let me try this.
>>
>> Kind regards,
>> Prasanth
>>
>> On Tue, 28 Sept 2021 at 18:03, Mark Sapiro <mark(a)msapiro.net> wrote:
>>
>>> On 9/28/21 6:02 AM, Prasanth Nair wrote:
>>> > Hello,
>>> >
>>> > Does anyone know how to edit an archived email in Mailman3? It is
>>> possible
>>> > in Mailman2 (
>>> >
>>> https://wiki.list.org/DOC/How%20do%20I%20edit%20the%20archives%20of%20a%20M…
>>> ).
>>> > Is there any option similar to this in Mailman3?
>>>
>>>
>>> In some sense the process is the same but possibly even simpler in
>>> Mailman 3. You need to modify the underlying data which requires
>>> appropriate access to the server.
>>>
>>> In Mailman 3, the data are in the hyperkitty_email table in Mailman's
>>> database. You can get the Message-ID hash from the URL to the archived
>>> message, e.g. for the message to which I'm replying, the URL is
>>>
>>> https://lists.mailman3.org/archives/list/mailman-users@mailman3.org/message…
>>> and the hash is 7PVJL23DLSWMXXL44ALQUO6VSYBRZ4OA. Then if you have
>>> access, you can do database queries like
>>> ```
>>> SELECT subject, content FROM hyperkitty_email WHERE message_id_hash =
>>> '7PVJL23DLSWMXXL44ALQUO6VSYBRZ4OA';
>>> ```
>>> and
>>> ```
>>> UPDATE hyperkitty_email SET content = '<new content>' WHERE
>>> message_id_hash = '7PVJL23DLSWMXXL44ALQUO6VSYBRZ4OA';
>>> UPDATE hyperkitty_email SET subject = '<new subject>' WHERE
>>> message_id_hash = '7PVJL23DLSWMXXL44ALQUO6VSYBRZ4OA';
>>> ```
>>> If the message has attachments, they are in the hyperkitty_attachment
>>> table and can be referenced by `email_id` which is the corresponding
>>> `id` from the hyperkitty_email entry.
>>>
>>> You can also do similar things via `django-admin shell`. E.g.
>>> ```
>>> $ django-admin shell
>>> Python ...
>>> (InteractiveConsole)
>>> >>> from hyperkitty.models.email import Email
>>> >>> x =
>>> Email.objects.filter(message_id_hash='7PVJL23DLSWMXXL44ALQUO6VSYBRZ4OA')
>>> >>> print(x[0].content)
>>> ```
>>> but this requires some knowledge of HyperKitty's models and Django's ORM.
>>>
>>> --
>>> 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/
>>>
>>
3 years, 8 months
Re: Core, Hyperkitty and Postorius releases
by Odhiambo Washington
On Sat, May 15, 2021 at 12:24 AM Abhilash Raj <maxking(a)asynchronous.in>
wrote:
>
>
> On Fri, May 14, 2021, at 2:16 PM, Odhiambo Washington wrote:
> > On Sat, May 15, 2021 at 12:01 AM Mark Sapiro <mark(a)msapiro.net> wrote:
> >
> > > On 5/14/21 1:54 PM, Odhiambo Washington wrote:
> > > >
> > > > /usr/local/include/sass
> > > >
> > > > That is the only thing found that is in the base system.
> > >
> > > And that's the one you want. What is it's mode?
> > >
> >
> > root@gw:/usr/home/wash # ls -al /usr/local/include/sass
> > total 104
> > drwxr-xr-x 2 root wheel 512 Apr 16 16:49 .
> > drwxr-xr-x 176 root wheel 10240 Apr 19 18:05 ..
> > -rw-r--r-- 1 root wheel 2369 Apr 8 11:08 base.h
> > -rw-r--r-- 1 root wheel 10742 Apr 8 11:08 context.h
> > -rw-r--r-- 1 root wheel 6632 Apr 8 11:08 functions.h
> > -rw-r--r-- 1 root wheel 6489 Apr 8 11:08 values.h
> > -rw-r--r-- 1 root wheel 198 Apr 8 11:08 version.h
> >
> > I imagined I needed an executable.
>
> This sounds like a result of you running `pip3 install sass`, probably
> with sudo
> which failed mid-way due to the exception you posted above.
>
Closer to the truth! It failed. I was running this from within the
virtualenv.
> Which OS are you using?
FreeBSD.
> On debian/ubuntu, you can install:
>
> sudo apt install sassc
>
Do I need to install sassc in the base OS or in the virtualenv?
> I am not exactly sure how it got removed during your upgrade
> to the new version of Mailman since it shouldn't affect your system
> packages.
>
The funny part is my MM3 used to run. Mark took so much hand-holding for me
to get it running.
Then one day I used the update process and things got hosed.
The happy part is that I had not put any production lists on MM3 as I
hadn't developed the confidence of managing it.
Did you install Mailman initially using system packages or instructions
> provided at [1]?
>
> [1]:
> https://docs.mailman3.org/en/latest/install/virtualenv.html#virtualenv-inst…
No. I relied on
https://wiki.list.org/DOC/Mailman%203%20installation%20experience. This is
way back!
Your new link is recent, no?
--
Best regards,
Odhiambo WASHINGTON,
Nairobi,KE
+254 7 3200 0004/+254 7 2274 3223
"Oh, the cruft.", egrep -v "^$|^.*#" :-)
4 years, 1 month
Re: The MAILMAN_ARCHIVER_KEY was not sent as the Authorization HTTP header.
by Mark Sapiro
On 10/23/21 12:43 AM, Marco Marinello wrote:
> Dear Mark,
>
> I upgraded the pypi packages as you suggested but the problem remains the same.
> Tried also installing from git heads but always get
>
> ==> /opt/hyperkitty_django/hyperkitty.log <==
> ERROR 2021-10-23 09:42:42,523 30765 hyperkitty.views.mailman The MAILMAN_ARCHIVER_KEY was not sent as the Authorization HTTP header.
> WARNING 2021-10-23 09:42:42,523 30765 django.request Unauthorized: /hyperkitty/api/mailman/urls
> WARNING 2021-10-23 09:42:42,523 30765 django.request Unauthorized: /hyperkitty/api/mailman/urls
>
> ==> /var/log/mailman/mailman.log <==
> Oct 23 07:42:42 2021 (30888) HyperKitty failure on http://127.0.0.1:8080/hyperkitty/api/mailman/urls: <html><title>Auth required</title><body>
> <h1>Authorization Required</h1><p>The archiver key must be
> sent over the Authorization HTTP header.
> </p></body></html> (401)
Those messages look correct for HyperKitty 1.3.5, if mailman-hyperkitty
is not sending the key as expected. The particular condition causing
those messages is there is no "Authorization" header in the headers of
the request from mailman-hyperkitty and there is also no "key" parameter
in the request as there would have been with mailman-hyperkitty 1.1.0
This would seem to say that both HyperKitty 1.3.5 and mailman-hyperkitty
1.2.0 are doing the right thing, but somehow the request headers are not
getting through in the http request from mailman-hyperkitty to HyperKitty.
What is your setting for base_url in mailman-hyperkitty.cfg? Is there
some redirect or other situation going on in serving the request to
HyperKitty that could cause headers to get lost?
> For information, how does your release cycle work? I prefer installing from a source rather than pypi. Is the master normally stable? When a packages lands on pypi?
We are a small, all volunteer project and we don't have a fixed release
schedule. We make releases when we feel enough change has been
accumulated to warrant on or when there is a serious issue to fix.
The heads of the gitlab branches are generally usable. There was
actually a situation briefly where the mailman-hyperkitty changes for
this issue were merged before the HyperKitty changes. See
https://gitlab.com/mailman/hyperkitty/-/merge_requests/354#note_693162778 but
situations like this are rare. The servers at lists.mailman3.org and
mail.python.org run the heads of the gitlab branches (I update them
regularly) so you can generally be confident that they work.
> I'll stick on 1.3.4 / 1.1.0 for the moment.
There are several changes in HyperKitty 1.3.5. See
https://docs.mailman3.org/projects/hyperkitty/en/latest/news.html#news-1-3-5
--
Mark Sapiro <mark(a)msapiro.net> The highway is for gamblers,
San Francisco Bay Area, California better use your sense - B. Dylan
3 years, 8 months
Re: Trying basic install of mailman3 in docker, but how do you set allowed hosts?
by Abhilash Raj
On Thu, Jul 8, 2021, at 12:23 PM, bob B wrote:
> I am starting small, My goal is just to get mailman3 running in docker
> and test the website access via curl from the host, then I will move
> on from there
>
> In the docker instructions it says
>
> SERVE_FROM_DOMAIN: The domain name from which Django will be served. To
> be added to ALLOWED_HOSTS in django settings. Default value is not set.
> This also replaces Django's default example.com SITE and becomes the
> default SITE (with SITE_ID=1).
Perhaps that is my English there, but what it really meant to say was you should
set "SERVE_FROM_DOMAIN" in your "environment" section of the docker-compose.yaml
file and it will add the value of that variable to Django's ALLOWED_HOSTS settings
for you [1].
If you think it could be re-worded for clarity, please feel free to let me know or
open a PR in the Github repo.
[1]: https://github.com/maxking/docker-mailman/blob/main/web/mailman-web/setting…
Also, "localhost" is already added to the list of ALLOWED_HOSTS, so if you are able
to point to the container using that, it should work without setting the SERVE_FROM_DOMAIN.
Abhilash
> But where do I set the ALLOWED_HOSTS I added this to the yaml file
> - ALLOWED_HOSTS=127.0.0.1 under environments
>
>
> mailman-web:
> image: maxking/mailman-web:0.3
> container_name: mailman-web
> hostname: mailman-web
> depends_on:
> - database
> links:
> - mailman-core:mailman-core
> - database:database
> volumes:
> - /opt/mailman/web:/opt/mailman-web-data
> environment:
> - UWSGI_STATIC_MAP=/static=/opt/mailman-web-data/static
> - ALLOWED_HOSTS=127.0.0.1
> - DATABASE_TYPE=postgres
> - DATABASE_URL=postgres://mailman:mailmanpass@database/mailmandb
> - SECRET_KEY=333blah-blah-secret
> - HYPERKITTY_API_KEY=333someapikey
> ports:
> - "127.0.0.1:8000:8000" # HTTP
> - "127.0.0.1:8080:8080" # uwsgi
> networks:
> mailman:
>
>
>
> But when I try:
> [docker-mailman]# curl 127.0.0.1:8000
> <h1>Bad Request (400)</h1>[root@bmimailmandr1 docker-mailman]#
> [root@bmimailmandr1 docker-mailman]#
>
>
>
> I see this in the logs
>
> [docker-mailman]# cat /opt/mailman/web/logs/mailmanweb.log
> WARNING 2021-07-08 17:40:46,979 1642 django.request Bad Request: /
> ERROR 2021-07-08 19:20:58,416 1641 django.security.DisallowedHost
> Invalid HTTP_HOST header: '127.0.0.1:8000'. You may need to add
> '127.0.0.1' to ALLOWED_HOSTS.
> WARNING 2021-07-08 19:20:59,032 1641 django.request Bad Request: /
> WARNING 2021-07-08 19:20:59,032 1641 django.request Bad Request: /
> _______________________________________________
> 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)
3 years, 11 months
Re: ModuleNotFoundError: No module named 'settings'
by Michela
Hi. Thank you for your replies, everyone!
Perhaps I should first mention that I checked uwsgi.ini and it is set to /etc/mailman3/, which is where my configuration files actually are. I had a typo in my message to the list about that (but not on the server), where I accidentally omitted the "3" in the directory path. So everything was actually in order there. Good catch in any case! :)
The start of the uwsgi.ini file is as follows:
> *** Starting uWSGI 2.0.19.1 (64bit) on [Mon May 10 11:11:01 2021] ***
> compiled with version: 8.3.1 20191121 (Red Hat 8.3.1-5.0.2) on 10 May 2021 00:42:28
> os: Linux-5.4.17-2102.200.13.el8uek.x86_64 #2 SMP Sun Mar 28 14:48:36 PDT 2021
> nodename: hostname
> machine: x86_64
> clock source: unix
> detected number of CPU cores: 2
> current working directory: /
> detected binary path: /opt/mailman/venv/bin/uwsgi
> !!! no internal routing support, rebuild with pcre support !!!
> your processes number limit is 6642
> your memory page size is 4096 bytes
> detected max file descriptor number: 1024
> lock engine: pthread robust mutexes
> thunder lock: disabled (you can enable it with --thunder-lock)
> uwsgi socket 0 bound to TCP address 0.0.0.0:8000 fd 10
> Python version: 3.6.8 (default, Mar 9 2021, 15:28:46) [GCC 8.3.1 20191121 (Red Hat 8.3.1-5.0.1)]
> PEP 405 virtualenv detected: /opt/mailman/venv/
> Set PythonHome to /opt/mailman/venv/
> Python main interpreter initialized at 0x10ccf30
> python threads support enabled
> your server socket listen backlog is limited to 100 connections
> your mercy for graceful operations on workers is 60 seconds
> mapped 250032 bytes (244 KB) for 4 cores
> *** Operational MODE: preforking+threaded ***
> added /etc/mailman3/ to pythonpath.
> Traceback (most recent call last):
> File "/opt/mailman/venv/lib64/python3.6/site-packages/mailman_web/wsgi.py", line 16, in <module>
> application = get_wsgi_application()
> File "/opt/mailman/venv/lib64/python3.6/site-packages/django/core/wsgi.py", line 12, in get_wsgi_application
> django.setup(set_prefix=False)
> File "/opt/mailman/venv/lib64/python3.6/site-packages/django/__init__.py", line 19, in setup
> configure_logging(settings.LOGGING_CONFIG, settings.LOGGING)
> File "/opt/mailman/venv/lib64/python3.6/site-packages/django/conf/__init__.py", line 76, in __getattr__
> self._setup(name)
> File "/opt/mailman/venv/lib64/python3.6/site-packages/django/conf/__init__.py", line 63, in _setup
> self._wrapped = Settings(settings_module)
> File "/opt/mailman/venv/lib64/python3.6/site-packages/django/conf/__init__.py", line 142, in __init__
> mod = importlib.import_module(self.SETTINGS_MODULE)
> File "/usr/lib64/python3.6/importlib/__init__.py", line 126, in import_module
> return _bootstrap._gcd_import(name[level:], package, level)
> ModuleNotFoundError: No module named 'settings'
> unable to load app 0 (mountpoint='') (callable not found or import error)
> *** no app loaded. going in full dynamic mode ***
> *** uWSGI is running in multiple interpreter mode ***
> spawned uWSGI master process (pid: 38878)
> spawned uWSGI worker 1 (pid: 38882, cores: 2)
> spawned uWSGI worker 2 (pid: 38883, cores: 2)
> [uwsgi-daemons] spawning "/opt/mailman/venv/bin/mailman-web qcluster" (uid: 1002 gid: 1002)
> Traceback (most recent call last):
> File "/opt/mailman/venv/lib64/python3.6/site-packages/django/core/management/__init__.py", line 224, in fetch_command
> app_name = commands[subcommand]
> KeyError: 'qcluster'
Running qcluster interactively does appear to work properly:
> (venv) [mailman@hostname ~]$ /opt/mailman/venv/bin/mailman-web qcluster
> /opt/mailman/venv/lib64/python3.6/site-packages/django_q/conf.py:138: 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.
> See https://django-q.readthedocs.io/en/latest/configure.html#retry for details.""")
> 20:16:21 [Q] INFO Q Cluster berlin-angel-south-california starting.
> 20:16:21 [Q] INFO Process-1:1 ready for work at 57948
> 20:16:21 [Q] INFO Process-1:2 ready for work at 57949
> 20:16:21 [Q] INFO Process-1:3 monitoring at 57950
> 20:16:21 [Q] INFO Process-1 guarding cluster berlin-angel-south-california
> 20:16:21 [Q] INFO Q Cluster berlin-angel-south-california running.
> 20:16:21 [Q] INFO Process-1:4 pushing tasks at 57951
My uwsgi.ini file:
> # /etc/mailman3/uwsgi.ini
> #
> [uwsgi]
> # Port on which uwsgi will be listening.
> uwsgi-socket = 0.0.0.0:8000
> # If running uwsgi from the virtual environment ...
> virtualenv = /opt/mailman/venv/
>
> module=mailman_web.wsgi:application
> # Add to python import path.
> pythonpath = /etc/mailman3/
> # The default settings module.
> env = DJANGO_SETTINGS_MODULE=settings
>
> # Setup default number of processes and threads per process.
> master = true
> processes = 2
> threads = 2
>
> # Setup the django_q related worker processes.
> attach-daemon = /opt/mailman/venv/bin/mailman-web qcluster
>
> # Setup the request log.
> req-logger = file:/opt/mailman/web/logs/uwsgi.log
>
> # Log qcluster commands separately.
> logger = qcluster file:/opt/mailman/web/logs/uwsgi-qcluster.log
> log-route = qcluster uwsgi-daemons
>
> # Last log and it logs the rest of the stuff.
> logger = file:/opt/mailman/web/logs/uwsgi-error.log
Files in /etc/mailman3/
> (venv) [mailman@hostname ~]$ ls /etc/mailman3/
> mailman.cfg __pycache__/ settings.py uwsgi.ini
Regarding Steve's comment on WSGI vs. Gunicorn, we used WSGI as the application server for Mailman 3 because that's what the Mailman 3 venv instructions say to use -- I did my best to follow them exactly (the only difference is in the way I installed PostgreSQL -- I used the official EL PostgreSQL repository for that). So, hopefully, the developers consider it okay for us to use UWSGI (at least for now). :D
Thank you for your help!!
Michela
‐‐‐‐‐‐‐ Original Message ‐‐‐‐‐‐‐
On Monday, May 10, 2021 10:08 PM, Abhilash Raj <maxking(a)asynchronous.in> wrote:
>
>
> > On May 10, 2021, at 8:11 PM, Stephen J. Turnbull turnbull.stephen.fw(a)u.tsukuba.ac.jp wrote:
> > Michela via Mailman-users writes:
> >
> > > The log file, /opt/mailman/web/logs/uwsgi-error.log, contains the
> > > following stack trace, however. Note the bit toward the bottom:
> > > "ModuleNotFoundError: No module named 'settings'"
> >
> > Given that you can run the applications from the command line as
> > systemd services, this almost certainly localizes the problem to uwsgi
> > itself. Note that uwsgi has been problematic lately. I don't recall
> > the details. I think there's a preference for gunicorn as the SGI
> > provider among the Mailman 3 developers (and it's what core uses
> > internally to provide the REST interface) so uwsgi may not get "beta"
> > testing in production from us.
> > Specifically, is this line
> > pythonpath = /etc/mailman3/
> > present, correct, and not commented out in uswgi.ini?
> >
> > > My configuration files outside of the Mailman virtual environment
> > > are in /etc/mailman/:
> >
> > Is it possible you have /etc/mailman/ instead of /etc/mailman3/ in
> > uwsgi.ini as in the above quote? (I am pretty sure that's a typo in
> > the post, but gotta check everything.) On the other hand, maybe we
> > did a typo, and there should be no trailing slash on /etc/mailman3 in
> > this statement. (Usually trailing slashes aren't a problem,
> > applications mostly ignore them, but there is no trailing slash on any
> > directory in my sys.path, so it's worth a try.)
>
> Yeah, it would be good to share the full contents of /etc/mailman3/uwsgi.ini,
> for some reason what is listed in the docs[1] is working on one of my test
> servers. Although, given that there are more than one reports of the same
> error, it is possible something is wrong or missing in the docs.
>
> The trailing slashes in this case isn’t really a problem I think.
>
> If you can share some initial parts of your uwsgi-error.log part where uwsgi
> initializes that would be useful too. I am looking something that looks like
> this:
>
> *** Starting uWSGI 2.0.19.1 (64bit) on [Thu Jan 21 08:49:16 2021] ***
> compiled with version: 9.3.0 on 21 January 2021 08:40:15
> os: Linux-5.4.0-1036-azure #38-Ubuntu SMP Wed Jan 6 18:26:25 UTC 2021
> nodename: mailman
> machine: x86_64
> clock source: unix
> detected number of CPU cores: 2
> current working directory: /opt/mailman3
> detected binary path: /opt/mailman3/venv/bin/uwsgi
> !!! no internal routing support, rebuild with pcre support !!!
> your processes number limit is 15571
> your memory page size is 4096 bytes
> detected max file descriptor number: 1024
> lock engine: pthread robust mutexes
> thunder lock: disabled (you can enable it with --thunder-lock)
> uwsgi socket 0 bound to TCP address 127.0.0.1:8000 fd 8
> Python version: 3.8.5 (default, Jul 28 2020, 12:59:40) [GCC 9.3.0]
> PEP 405 virtualenv detected: /opt/mailman3/venv/
> Set PythonHome to /opt/mailman3/venv/
> Python main interpreter initialized at 0x56002ba3aed0
> python threads support enabled
> your server socket listen backlog is limited to 100 connections
> your mercy for graceful operations on workers is 60 seconds
> mapped 166688 bytes (162 KB) for 2 cores
> *** Operational MODE: threaded ***
> added /etc/mailman3/ to pythonpath.
> WSGI app 0 (mountpoint='') ready in 1 seconds on interpreter 0x56002ba3aed0 pid: 715893 (default app)
> *** uWSGI is running in multiple interpreter mode ***
> spawned uWSGI master process (pid: 715893)
> spawned uWSGI worker 1 (pid: 715897, cores: 2)
> [uwsgi-daemons] spawning "mailman-web qcluster" (uid: 1001 gid: 1001)
> 08:49:18 [Q] INFO Q Cluster december-nebraska-helium-montana starting.
> 08:49:18 [Q] INFO Process-1:1 ready for work at 715904
> 08:49:18 [Q] INFO Process-1:2 ready for work at 715905
>
>
> Please ignore that the paths in my logs are`/opt/mailman3/*`, I have
> multiple installations on my test server, the docs say it should be `/opt/mailman/*`. It
> doesn’t really matter as long as they are consistent in all places.
>
> Also, what happens if you run the command "/opt/mailman/venv/bin/mailman-web qcluster” as
> a “mailman” user on your machine? Do you see the traceback like above or does it start a
> process like this?
>
> mailman@mailman:~$ /opt/mailman3/venv/bin/mailman-web qcluster
> 05:05:29 [Q] INFO Q Cluster april-east-hot-potato starting.
> 05:05:29 [Q] INFO Process-1:1 ready for work at 3364005
> 05:05:29 [Q] INFO Process-1:2 ready for work at 3364006
> 05:05:29 [Q] INFO Process-1 guarding cluster april-east-hot-potato
> 05:05:29 [Q] INFO Process-1:3 monitoring at 3364007
> 05:05:29 [Q] INFO Q Cluster april-east-hot-potato running.
> 05:05:29 [Q] INFO Process-1:4 pushing tasks at 3364008
>
>
> [1]:https://docs.mailman3.org/en/latest/install/virtualenv.html#setting-up-a…
>
> > If it's none of the above, I'm out of ideas. Maybe Mark or Abhilash
> > has more experience.
> > Steve
> >
> > 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)
4 years, 1 month
Re: docker-mailman Release Schedule
by matthew＠alberti.us
Thank you so much!
-----Original Message-----
From: Abhilash Raj <maxking(a)asynchronous.in>
Sent: Thursday, February 25, 2021 1:49 AM
To: Mailman users <mailman-users(a)mailman3.org>
Subject: [MM3-users] Re: docker-mailman Release Schedule
On Wed, Feb 24, 2021, at 3:20 PM, matthew(a)alberti.us wrote:
> Hi,
>
> Is there an estimated date that a new docker-mailman
> release will be issued? I think .3.10 is still the latest, which
> doesn't include the latest releases of core, web, etc.
Thanks for the reminder, I just released 0.3.11.
https://github.com/maxking/docker-mailman/releases/tag/v0.3.11
>
>
>
> Thanks.
>
> _______________________________________________
> 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/
4 years, 4 months
postfix malformed address with confirm replies
by Stephen Willey Mats Mats
I’m getting bounces back from postfix (553 5.1.3 Error: malformed address) for my confirm replies.
I found a similar issue in this lists’ archives back in 2017 but that issue was supposedly fixed in version 3.2
I’m running the current docker containers.
I’m pretty sure I have all of the mailman settings in postix:
"
# Support the default VERP delimiter.
recipient_delimiter = +
unknown_local_recipient_reject_code = 550
owner_request_special = no
transport_maps =
regexp:/opt/mailman/core/var/data/postfix_lmtp
local_recipient_maps =
regexp:/opt/mailman/core/var/data/postfix_lmtp
relay_domains =
regexp:/opt/mailman/core/var/data/postfix_domains
"
the entries in /opt/mailman/core/var/data/postfix_lmtp look like they should match
/^matsmats-mm3-test1(a)mm3\.aca-aws\.s\.uw\.edu$/ lmtp:[172.19.199.2]:8024
/^matsmats-mm3-test1-bounces(\+.*)?(a)mm3\.aca-aws\.s\.uw\.edu$/ lmtp:[172.19.199.2]:8024
/^matsmats-mm3-test1-confirm(\+.*)?(a)mm3\.aca-aws\.s\.uw\.edu$/ lmtp:[172.19.199.2]:8024
/^matsmats-mm3-test1-join(a)mm3\.aca-aws\.s\.uw\.edu$/ lmtp:[172.19.199.2]:8024
/^matsmats-mm3-test1-leave(a)mm3\.aca-aws\.s\.uw\.edu$/ lmtp:[172.19.199.2]:8024
/^matsmats-mm3-test1-owner(a)mm3\.aca-aws\.s\.uw\.edu$/ lmtp:[172.19.199.2]:8024
/^matsmats-mm3-test1-request(a)mm3\.aca-aws\.s\.uw\.edu$/ lmtp:[172.19.199.2]:8024
/^matsmats-mm3-test1-subscribe(a)mm3\.aca-aws\.s\.uw\.edu$/ lmtp:[172.19.199.2]:8024
/^matsmats-mm3-test1-unsubscribe(a)mm3\.aca-aws\.s\.uw\.edu$/ lmtp:[172.19.199.2]:8024
thanks,
steve
> On Feb 26, 2021, at 14:08:54 PST, Mail Delivery System <MAILER-DAEMON(a)ip-172-31-18-222.us-west-2.compute.internal> wrote:
>
> This is the mail system at host ip-172-31-18-222.us-west-2.compute.internal.
>
> I'm sorry to have to inform you that your message could not
> be delivered to one or more recipients. It's attached below.
>
> For further assistance, please send mail to postmaster.
>
> If you do so, please include this problem report. You can
> delete your own text from the attached returned message.
>
> The mail system
>
> <matsmats-mm3-test1-confirm+d6f77a2572ef55a8b2c4ca0d77de8493fbb55856(a)mm3.aca-aws.s.uw.edu>:
> host 172.19.199.2[172.19.199.2] said: 553 5.1.3 Error: malformed address
> (in reply to RCPT TO command)
> Reporting-MTA: dns; ip-172-31-18-222.us-west-2.compute.internal
> X-Postfix-Queue-ID: E144B8BC3C5
> X-Postfix-Sender: rfc822; stephen.s.w.matsmats(a)gmail.com
> Arrival-Date: Fri, 26 Feb 2021 14:08:54 -0800 (PST)
>
> Final-Recipient: rfc822; matsmats-mm3-test1-confirm+d6f77a2572ef55a8b2c4ca0d77de8493fbb55856(a)mm3.aca-aws.s.uw.edu
> Original-Recipient: rfc822;matsmats-mm3-test1-confirm+d6f77a2572ef55a8b2c4ca0d77de8493fbb55856(a)mm3.aca-aws.s.uw.edu
> Action: failed
> Status: 5.1.3
> Remote-MTA: dns; 172.19.199.2
> Diagnostic-Code: smtp; 553 5.1.3 Error: malformed address
>
> From: Steve Mats Mats <willey(a)selby.com>
> Subject: Re: Your confirmation is needed to join the matsmats-mm3-test1(a)mm3.aca-aws.s.uw.edu mailing list.
> Date: February 26, 2021 at 2:08:52 PM PST
> To: matsmats-mm3-test1-confirm+d6f77a2572ef55a8b2c4ca0d77de8493fbb55856(a)mm3.aca-aws.s.uw.edu
>
>
>
>
>> On Feb 26, 2021, at 11:41:54 PST, matsmats-mm3-test1-confirm+d6f77a2572ef55a8b2c4ca0d77de8493fbb55856(a)mm3.aca-aws.s.uw.edu wrote:
>>
>> Email Address Registration Confirmation
>>
>> Hello, this is the GNU Mailman server at mm3.aca-aws.s.uw.edu.
>>
>> We have received a registration request for the email address
>>
>> willey(a)teamd.org
>>
>> Before you can start using GNU Mailman at this site, you must first confirm
>> that this is your email address. You can do this by replying to this message.
>>
>> Or you should include the following line -- and only the following
>> line -- in a message to matsmats-mm3-test1-request(a)mm3.aca-aws.s.uw.edu:
>>
>> confirm d6f77a2572ef55a8b2c4ca0d77de8493fbb55856
>>
>> Note that simply sending a `reply' to this message should work from
>> most mail readers.
>>
>> If you do not wish to register this email address, simply disregard this
>> message. If you think you are being maliciously subscribed to the list, or
>> have any other questions, you may contact
>>
>> matsmats-mm3-test1-owner(a)mm3.aca-aws.s.uw.edu
>
>
>
4 years, 4 months
Re: ModuleNotFoundError: No module named 'settings'
by Michela
Oh! I just noticed Jeff and Mark's posts about the solution for this issue.
I just adjusted my systemd unit file and, of course, that worked for me as well.
Thank you so much for your help on this, everyone!
Best,
Michela
‐‐‐‐‐‐‐ Original Message ‐‐‐‐‐‐‐
On Tuesday, May 11, 2021 1:37 PM, Michela via Mailman-users <mailman-users(a)mailman3.org> wrote:
> Hi. Thank you for your replies, everyone!
>
> Perhaps I should first mention that I checked uwsgi.ini and it is set to /etc/mailman3/, which is where my configuration files actually are. I had a typo in my message to the list about that (but not on the server), where I accidentally omitted the "3" in the directory path. So everything was actually in order there. Good catch in any case! :)
>
> The start of the uwsgi.ini file is as follows:
>
> > *** Starting uWSGI 2.0.19.1 (64bit) on [Mon May 10 11:11:01 2021] ***
> > compiled with version: 8.3.1 20191121 (Red Hat 8.3.1-5.0.2) on 10 May 2021 00:42:28
> > os: Linux-5.4.17-2102.200.13.el8uek.x86_64 #2 SMP Sun Mar 28 14:48:36 PDT 2021
> > nodename: hostname
> > machine: x86_64
> > clock source: unix
> > detected number of CPU cores: 2
> > current working directory: /
> > detected binary path: /opt/mailman/venv/bin/uwsgi
> > !!! no internal routing support, rebuild with pcre support !!!
> > your processes number limit is 6642
> > your memory page size is 4096 bytes
> > detected max file descriptor number: 1024
> > lock engine: pthread robust mutexes
> > thunder lock: disabled (you can enable it with --thunder-lock)
> > uwsgi socket 0 bound to TCP address 0.0.0.0:8000 fd 10
> > Python version: 3.6.8 (default, Mar 9 2021, 15:28:46) [GCC 8.3.1 20191121 (Red Hat 8.3.1-5.0.1)]
> > PEP 405 virtualenv detected: /opt/mailman/venv/
> > Set PythonHome to /opt/mailman/venv/
> > Python main interpreter initialized at 0x10ccf30
> > python threads support enabled
> > your server socket listen backlog is limited to 100 connections
> > your mercy for graceful operations on workers is 60 seconds
> > mapped 250032 bytes (244 KB) for 4 cores
> > *** Operational MODE: preforking+threaded ***
> > added /etc/mailman3/ to pythonpath.
> > Traceback (most recent call last):
> > File "/opt/mailman/venv/lib64/python3.6/site-packages/mailman_web/wsgi.py", line 16, in <module>
> > application = get_wsgi_application()
> > File "/opt/mailman/venv/lib64/python3.6/site-packages/django/core/wsgi.py", line 12, in get_wsgi_application
> > django.setup(set_prefix=False)
> > File "/opt/mailman/venv/lib64/python3.6/site-packages/django/init.py", line 19, in setup
> > configure_logging(settings.LOGGING_CONFIG, settings.LOGGING)
> > File "/opt/mailman/venv/lib64/python3.6/site-packages/django/conf/init.py", line 76, in getattr
> > self._setup(name)
> > File "/opt/mailman/venv/lib64/python3.6/site-packages/django/conf/init.py", line 63, in _setup
> > self._wrapped = Settings(settings_module)
> > File "/opt/mailman/venv/lib64/python3.6/site-packages/django/conf/init.py", line 142, in init
> > mod = importlib.import_module(self.SETTINGS_MODULE)
> > File "/usr/lib64/python3.6/importlib/init.py", line 126, in import_module
> > return _bootstrap._gcd_import(name[level:], package, level)
> > ModuleNotFoundError: No module named 'settings'
> > unable to load app 0 (mountpoint='') (callable not found or import error)
> > *** no app loaded. going in full dynamic mode ***
> > *** uWSGI is running in multiple interpreter mode ***
> > spawned uWSGI master process (pid: 38878)
> > spawned uWSGI worker 1 (pid: 38882, cores: 2)
> > spawned uWSGI worker 2 (pid: 38883, cores: 2)
> > [uwsgi-daemons] spawning "/opt/mailman/venv/bin/mailman-web qcluster" (uid: 1002 gid: 1002)
> > Traceback (most recent call last):
> > File "/opt/mailman/venv/lib64/python3.6/site-packages/django/core/management/init.py", line 224, in fetch_command
> > app_name = commands[subcommand]
> > KeyError: 'qcluster'
>
> Running qcluster interactively does appear to work properly:
>
> > (venv) [mailman@hostname ~]$ /opt/mailman/venv/bin/mailman-web qcluster
> > /opt/mailman/venv/lib64/python3.6/site-packages/django_q/conf.py:138: 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.
> > See https://django-q.readthedocs.io/en/latest/configure.html#retry for details.""")
> > 20:16:21 [Q] INFO Q Cluster berlin-angel-south-california starting.
> > 20:16:21 [Q] INFO Process-1:1 ready for work at 57948
> > 20:16:21 [Q] INFO Process-1:2 ready for work at 57949
> > 20:16:21 [Q] INFO Process-1:3 monitoring at 57950
> > 20:16:21 [Q] INFO Process-1 guarding cluster berlin-angel-south-california
> > 20:16:21 [Q] INFO Q Cluster berlin-angel-south-california running.
> > 20:16:21 [Q] INFO Process-1:4 pushing tasks at 57951
>
> My uwsgi.ini file:
>
> > /etc/mailman3/uwsgi.ini
> >
> > ========================
> >
> > ==
> >
> > [uwsgi]
> >
> > Port on which uwsgi will be listening.
> >
> > =======================================
> >
> > uwsgi-socket = 0.0.0.0:8000
> >
> > If running uwsgi from the virtual environment ...
> >
> > ==================================================
> >
> > virtualenv = /opt/mailman/venv/
> > module=mailman_web.wsgi:application
> >
> > Add to python import path.
> >
> > ===========================
> >
> > pythonpath = /etc/mailman3/
> >
> > The default settings module.
> >
> > =============================
> >
> > env = DJANGO_SETTINGS_MODULE=settings
> >
> > Setup default number of processes and threads per process.
> >
> > ===========================================================
> >
> > master = true
> > processes = 2
> > threads = 2
> >
> > Setup the django_q related worker processes.
> >
> > =============================================
> >
> > attach-daemon = /opt/mailman/venv/bin/mailman-web qcluster
> >
> > Setup the request log.
> >
> > =======================
> >
> > req-logger = file:/opt/mailman/web/logs/uwsgi.log
> >
> > Log qcluster commands separately.
> >
> > ==================================
> >
> > logger = qcluster file:/opt/mailman/web/logs/uwsgi-qcluster.log
> > log-route = qcluster uwsgi-daemons
> >
> > Last log and it logs the rest of the stuff.
> >
> > ============================================
> >
> > logger = file:/opt/mailman/web/logs/uwsgi-error.log
>
> Files in /etc/mailman3/
>
> > (venv) [mailman@hostname ~]$ ls /etc/mailman3/
> > mailman.cfg pycache/ settings.py uwsgi.ini
>
> Regarding Steve's comment on WSGI vs. Gunicorn, we used WSGI as the application server for Mailman 3 because that's what the Mailman 3 venv instructions say to use -- I did my best to follow them exactly (the only difference is in the way I installed PostgreSQL -- I used the official EL PostgreSQL repository for that). So, hopefully, the developers consider it okay for us to use UWSGI (at least for now). :D
>
> Thank you for your help!!
> Michela
>
> ‐‐‐‐‐‐‐ Original Message ‐‐‐‐‐‐‐
> On Monday, May 10, 2021 10:08 PM, Abhilash Raj maxking(a)asynchronous.in wrote:
>
> > > On May 10, 2021, at 8:11 PM, Stephen J. Turnbull turnbull.stephen.fw(a)u.tsukuba.ac.jp wrote:
> > > Michela via Mailman-users writes:
> > >
> > > > The log file, /opt/mailman/web/logs/uwsgi-error.log, contains the
> > > > following stack trace, however. Note the bit toward the bottom:
> > > > "ModuleNotFoundError: No module named 'settings'"
> > >
> > > Given that you can run the applications from the command line as
> > > systemd services, this almost certainly localizes the problem to uwsgi
> > > itself. Note that uwsgi has been problematic lately. I don't recall
> > > the details. I think there's a preference for gunicorn as the SGI
> > > provider among the Mailman 3 developers (and it's what core uses
> > > internally to provide the REST interface) so uwsgi may not get "beta"
> > > testing in production from us.
> > > Specifically, is this line
> > > pythonpath = /etc/mailman3/
> > > present, correct, and not commented out in uswgi.ini?
> > >
> > > > My configuration files outside of the Mailman virtual environment
> > > > are in /etc/mailman/:
> > >
> > > Is it possible you have /etc/mailman/ instead of /etc/mailman3/ in
> > > uwsgi.ini as in the above quote? (I am pretty sure that's a typo in
> > > the post, but gotta check everything.) On the other hand, maybe we
> > > did a typo, and there should be no trailing slash on /etc/mailman3 in
> > > this statement. (Usually trailing slashes aren't a problem,
> > > applications mostly ignore them, but there is no trailing slash on any
> > > directory in my sys.path, so it's worth a try.)
> >
> > Yeah, it would be good to share the full contents of /etc/mailman3/uwsgi.ini,
> > for some reason what is listed in the docs1 is working on one of my test
> > servers. Although, given that there are more than one reports of the same
> > error, it is possible something is wrong or missing in the docs.
> > The trailing slashes in this case isn’t really a problem I think.
> > If you can share some initial parts of your uwsgi-error.log part where uwsgi
> > initializes that would be useful too. I am looking something that looks like
> > this:
> >
> > *** Starting uWSGI 2.0.19.1 (64bit) on [Thu Jan 21 08:49:16 2021] ***
> > compiled with version: 9.3.0 on 21 January 2021 08:40:15
> > os: Linux-5.4.0-1036-azure #38-Ubuntu SMP Wed Jan 6 18:26:25 UTC 2021
> > nodename: mailman
> > machine: x86_64
> > clock source: unix
> > detected number of CPU cores: 2
> > current working directory: /opt/mailman3
> > detected binary path: /opt/mailman3/venv/bin/uwsgi
> > !!! no internal routing support, rebuild with pcre support !!!
> > your processes number limit is 15571
> > your memory page size is 4096 bytes
> > detected max file descriptor number: 1024
> > lock engine: pthread robust mutexes
> > thunder lock: disabled (you can enable it with --thunder-lock)
> > uwsgi socket 0 bound to TCP address 127.0.0.1:8000 fd 8
> > Python version: 3.8.5 (default, Jul 28 2020, 12:59:40) [GCC 9.3.0]
> > PEP 405 virtualenv detected: /opt/mailman3/venv/
> > Set PythonHome to /opt/mailman3/venv/
> > Python main interpreter initialized at 0x56002ba3aed0
> > python threads support enabled
> > your server socket listen backlog is limited to 100 connections
> > your mercy for graceful operations on workers is 60 seconds
> > mapped 166688 bytes (162 KB) for 2 cores
> > *** Operational MODE: threaded ***
> > added /etc/mailman3/ to pythonpath.
> > WSGI app 0 (mountpoint='') ready in 1 seconds on interpreter 0x56002ba3aed0 pid: 715893 (default app)
> > *** uWSGI is running in multiple interpreter mode ***
> > spawned uWSGI master process (pid: 715893)
> > spawned uWSGI worker 1 (pid: 715897, cores: 2)
> > [uwsgi-daemons] spawning "mailman-web qcluster" (uid: 1001 gid: 1001)
> > 08:49:18 [Q] INFO Q Cluster december-nebraska-helium-montana starting.
> > 08:49:18 [Q] INFO Process-1:1 ready for work at 715904
> > 08:49:18 [Q] INFO Process-1:2 ready for work at 715905
> >
> >
> > Please ignore that the paths in my logs are`/opt/mailman3/*`, I have
> > multiple installations on my test server, the docs say it should be `/opt/mailman/*`. It
> > doesn’t really matter as long as they are consistent in all places.
> > Also, what happens if you run the command "/opt/mailman/venv/bin/mailman-web qcluster” as
> > a “mailman” user on your machine? Do you see the traceback like above or does it start a
> > process like this?
> >
> > mailman@mailman:~$ /opt/mailman3/venv/bin/mailman-web qcluster
> > 05:05:29 [Q] INFO Q Cluster april-east-hot-potato starting.
> > 05:05:29 [Q] INFO Process-1:1 ready for work at 3364005
> > 05:05:29 [Q] INFO Process-1:2 ready for work at 3364006
> > 05:05:29 [Q] INFO Process-1 guarding cluster april-east-hot-potato
> > 05:05:29 [Q] INFO Process-1:3 monitoring at 3364007
> > 05:05:29 [Q] INFO Q Cluster april-east-hot-potato running.
> > 05:05:29 [Q] INFO Process-1:4 pushing tasks at 3364008
> >
> >
> > > If it's none of the above, I'm out of ideas. Maybe Mark or Abhilash
> > > has more experience.
> > > Steve
> > > 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/
4 years, 1 month
Re: Newbie question 2: Rewriting issue for bounced emails
by William Oliver
On Sun, 2021-12-26 at 18:23 -0800, Mark Sapiro wrote:
> On 12/26/21 6:19 PM, Mark Sapiro wrote:
> >
> > Otherwise, you can do this in mailman shell, e.g.
> > ```
> > $ mailman shell
> >
> > Welcome to the GNU Mailman shell
> > Use commit() to commit changes.
> > Use abort() to discard changes since the last commit.
> > Exit with ctrl+D does an implicit commit() but exit() does not.
> >
> > >>> dm = getUtility(IDomainManager)
> > >>> d = dm.get('example.com')
> > >>> d.alias_domain = x.example.com
> > >>> commit()
> > ```
>
>
> Ooops. That should be
>
> d.alias_domain = 'x.example.com'
>
> I.e., quoted
>
>
Thanks. I am *almost* there. Adding the vmap in mailman fixed *almost*
everything. Now I can add users, get receive mails to the list, archive
messages correctly, and send emails. Except...
The list sends emails to local recipients fine. I have three users on
my test list:
fp145(a)libertyfp.org (local)
billo(a)billoblog.com (not local)
oliver(a)billoblog.com (not local)
When I send a message to the list from *any* of these three, the
mailman3 accepts it and attempts to broadcast it out. It is delivered
sucessfully to the local email address, but it looks like there's a
relaying problem with external addresses.
In the syslog snippet below, note that the fp145(a)libertyfp.org mail is
delivered, but the mail to the recipients at billoblog.com get an
"Access denied"
Dec 27 15:33:25 libertyfp postfix/smtpd[419593]: connect from
mail.libertyfp.org[2.56.57.28]
Dec 27 15:33:25 libertyfp postfix/smtpd[419593]: DC203421BE:
client=mail.libertyfp.org[2.56.57.28]
Dec 27 15:33:25 libertyfp postfix/cleanup[420001]: DC203421BE: message-
id=<9785b5a56581104fe079221bb947eb3a03813d97.camel(a)billoblog.com>
Here it is getting delivered locally:
Dec 27 15:33:25 libertyfp postfix/cleanup[420001]: DC203421BE: warning:
header Subject: [Testlist] bbbbb from mail.libertyfp.org[2.56.57.28];
from=<testlist-bounces+fp145=libertyfp.org(a)libertyfp.org>
to=<fp145(a)libertyfp.org> proto=ESMTP helo=<mail.libertyfp.org>
Dec 27 15:33:25 libertyfp postfix/qmgr[418758]: DC203421BE:
from=<testlist-bounces+fp145=libertyfp.org(a)libertyfp.org>, size=2651,
nrcpt=1 (queue active)
Dec 27 15:33:25 libertyfp postfix/virtual[420016]: DC203421BE:
to=<fp145(a)libertyfp.org>, relay=virtual, delay=0.03,
delays=0.01/0.01/0/0.01, dsn=2.0.0, status=sent (delivered to maildir)
Dec 27 15:33:25 libertyfp postfix/qmgr[418758]: DC203421BE: removed
Here it is getting bounced for billo(a)billoblog.com and
oliver(a)billoblog.com:
Dec 27 15:33:26 libertyfp postfix/smtpd[419593]: NOQUEUE: reject: RCPT
from mail.libertyfp.org[2.56.57.28]: 554 5.7.1 <billo(a)billoblog.com>:
Recipient address rejected: Access denied;
from=<testlist-bounces+billo=billoblog.com(a)libertyfp.org>
to=<billo(a)billoblog.com> proto=ESMTP helo=<mail.libertyfp.org>
Dec 27 15:33:26 libertyfp postfix/smtpd[419593]: disconnect from
mail.libertyfp.org[2.56.57.28] ehlo=1 mail=2 rcpt=1/2 data=1 rset=1
quit=1 commands=7/8
Dec 27 15:33:26 libertyfp postfix/smtpd[419593]: connect from
mail.libertyfp.org[2.56.57.28]
Dec 27 15:33:26 libertyfp postfix/smtpd[419593]: NOQUEUE: reject: RCPT
from mail.libertyfp.org[2.56.57.28]: 554 5.7.1 <oliver(a)billoblog.com>:
Recipient address rejected: Access denied;
from=<testlist-bounces+oliver=billoblog.com(a)libertyfp.org>
to=<oliver(a)billoblog.com> proto=ESMTP helo=<mail.libertyfp.org>
This error occurs whether the account posting to the list is in the
libertyfp.org domain or billoblog.com domain. Note that "regular" mail
from libertyfp.org does get delivered to outside addresses just fine,
originating from inside the domain or through an email client outside
the domain.
I tried changing the smtp port in mailman.cfg to 587, but that didn't
change anything.
In my reading, there seems to be differing discussions about what
should be in the mydestinations value, but I don't know what it should
be. Here's the current last bit of my main.cf, along with the
mydestinations setting:
mydestination = localhost.org, localhost
# add to the end (add virtual users)
# if specify multiple domains, specify comma or space separated
virtual_mailbox_domains = libertyfp.org
virtual_mailbox_base = /home/vmail
virtual_mailbox_maps = hash:/etc/postfix/virtual-mailbox
virtual_uid_maps = static:20000
virtual_gid_maps = static:20000
# mailman3 changes
owner_request_special = no
always_add_missing_headers = yes
transport_maps = hash:/opt/mailman/mm/var/data/postfix_lmtp
local_recipient_maps = hash:/opt/mailman/mm/var/data/postfix_lmtp
relay_domains = hash:/opt/mailman/mm/var/data/postfix_domains
default_destination_recipient_limit = 30
default_destination_concurrency_limit = 15
virtual_alias_maps = hash:/opt/mailman/mm/var/data/postfix_vmap
header_checks = regexp:/etc/postfix/header_checks
Here's the current values in /opt/mailman/mm/var/data/postfix_domains:
# AUTOMATICALLY GENERATED BY MAILMAN ON 2021-12-27 21:10:32
#
# This file is generated by Mailman, and is kept in sync with the
binary hash
# file. YOU SHOULD NOT MANUALLY EDIT THIS FILE unless you know what
you're
# doing, and can keep the two files properly in sync. If you screw it
up,
# you're on your own.
x.libertyfp.org libertyfp.org
here's postfix_lmtp:
# AUTOMATICALLY GENERATED BY MAILMAN ON 2021-12-27 21:10:32
#
# This file is generated by Mailman, and is kept in sync with the
binary hash
# file. YOU SHOULD NOT MANUALLY EDIT THIS FILE unless you know what
you're
# doing, and can keep the two files properly in sync. If you screw it
up,
# you're on your own.
# Aliases which are visible only in the @x.libertyfp.org domain.
testlist(a)x.libertyfp.org
lmtp:[mail.libertyfp.org]:8024
testlist-bounces(a)x.libertyfp.org
lmtp:[mail.libertyfp.org]:8024
testlist-confirm(a)x.libertyfp.org
lmtp:[mail.libertyfp.org]:8024
testlist-join(a)x.libertyfp.org
lmtp:[mail.libertyfp.org]:8024
testlist-leave(a)x.libertyfp.org
lmtp:[mail.libertyfp.org]:8024
testlist-owner(a)x.libertyfp.org
lmtp:[mail.libertyfp.org]:8024
testlist-request(a)x.libertyfp.org
lmtp:[mail.libertyfp.org]:8024
testlist-subscribe(a)x.libertyfp.org
lmtp:[mail.libertyfp.org]:8024
testlist-unsubscribe(a)x.libertyfp.org
lmtp:[mail.libertyfp.org]:8024
Heres the postfix_vmap that was (finally) successfully created:
# AUTOMATICALLY GENERATED BY MAILMAN ON 2021-12-27 21:10:32
#
# This file is generated by Mailman, and is kept in sync with the
binary hash
# file. YOU SHOULD NOT MANUALLY EDIT THIS FILE unless you know what
you're
# doing, and can keep the two files properly in sync. If you screw it
up,
# you're on your own.
# Virtual mappings for the @libertyfp.org domain.
testlist(a)libertyfp.org
testlist(a)x.libertyfp.org
testlist-bounces(a)libertyfp.org
testlist-bounces(a)x.libertyfp.org
testlist-confirm(a)libertyfp.org
testlist-confirm(a)x.libertyfp.org
testlist-join(a)libertyfp.org
testlist-join(a)x.libertyfp.org
testlist-leave(a)libertyfp.org
testlist-leave(a)x.libertyfp.org
testlist-owner(a)libertyfp.org
testlist-owner(a)x.libertyfp.org
testlist-request(a)libertyfp.org
testlist-request(a)x.libertyfp.org
testlist-subscribe(a)libertyfp.org
testlist-subscribe(a)x.libertyfp.org
testlist-unsubscribe(a)libertyfp.org
testlist-unsubscribe(a)x.libertyfp.org
For what it's worth, here's the extended header info for the mail that
*was* delivered:
Return-Path: <testlist-bounces+fp145=libertyfp.org(a)libertyfp.org>
X-Original-To: fp145(a)libertyfp.org
Delivered-To: fp145(a)libertyfp.org
Received: from mail.libertyfp.org (mail.libertyfp.org [2.56.57.28])
by mail.libertyfp.org (Postfix) with ESMTP id 226F6421BA
for <fp145(a)libertyfp.org>; Mon, 27 Dec 2021 16:27:17 -0500
(EST)
Received: from [10.112.157.251] (unknown [92.60.40.252])
by mail.libertyfp.org (Postfix) with ESMTPSA id F3608421BA
for <testlist(a)libertyfp.org>; Mon, 27 Dec 2021 16:27:11 -0500
(EST)
Message-Id:
<562c2f8aaeb3c9e2ccf198aff197dbd299fc002a.camel(a)libertyfp.org>
From: fp145(a)libertyfp.org <fp145(a)libertyfp.org>
To: testlist(a)libertyfp.org
Date: Mon, 27 Dec 2021 16:27:07 -0500
In-Reply-To:
<eb3380eecc734e240f65ddf974d81ee7dac6ca20.camel(a)libertyfp.org>
References:
<eb3380eecc734e240f65ddf974d81ee7dac6ca20.camel(a)libertyfp.org>
User-Agent: Evolution 3.40.0-1
Mime-Version: 1.0
Message-Id-Hash: FKEDFEFMXBD6YUDWKL235PQRIMUYYPEQ
X-Message-Id-Hash: FKEDFEFMXBD6YUDWKL235PQRIMUYYPEQ
X-Mailfrom: fp145(a)libertyfp.org
X-Mailman-Rule-Misses: dmarc-mitigation; no-senders; approved;
emergency; loop; banned-address; member-moderation; nonmember-
moderation; administrivia; implicit-dest; max-recipients; max-size;
news-moderation; no-subject; digests; suspicious-header
X-Mailman-Version: 3.3.5
Precedence: list
Subject: [Testlist] Re: test from fp145
List-Id: Test list <testlist.libertyfp.org>
Archived-At:
<https://libertyfp.org/archives/list/testlist@libertyfp.org/message/FKEDFEFM…
>
List-Archive:
<https://libertyfp.org/archives/list/testlist@libertyfp.org/>
List-Help: <mailto:testlist-request@libertyfp.org?subject=help>
List-Owner: <mailto:testlist-owner@libertyfp.org>
List-Post: <mailto:testlist@libertyfp.org>
List-Subscribe: <mailto:testlist-join@libertyfp.org>
List-Unsubscribe: <mailto:testlist-leave@libertyfp.org>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
X-Evolution-Source: 14004b3d9af2d67c898fd6d6c16b487f796088f5
I'm beginning to hate postfix.
billo
3 years, 6 months