Search results for "sapiro" - lists.mailman3.org

[MM3-users] Re: Splitting hosts: mta&core vs postorius

by Ruth Ivimey-Cook

Thanks Mark, On 20/06/2020 03:53, Mark Sapiro wrote: On 6/19/20 4:34 PM, Ruth Ivimey-Cook wrote: I'm trying to set up mailman3 on two hosts, one of which runs core + exim, the other runs postorius (&possibly hyperkitty). I have I think got core set up correctly, and postorius is sort of usable, but anything in the web ui that talks to core ends up with a white screen. I think what is happening is a postorius URL ends up with the core (or perhaps no) hostname, and as there's nothing there to answer it fails. What are your Django settings for MAILMAN_REST_API_URL, MAILMAN_REST_API_USER and MAILMAN_REST_API_PASS and do these agree with the [webservice] settings for hostname, port, use_https, admin_user and admin_pass in mailman.cfg in core and is the port open to the outside on the core machine? greyarea-post is the mailman-core and exim server. greyarea-web1 is the postorius and hyperkitty server. On greyarea-web1, in django-settings.py, MAILMAN_REST_API_URL = '[1]http://greyarea-post:8870' MAILMAN_REST_API_USER = 'restadmin' MAILMAN_REST_API_PASS = XXXX and both the above-named hosts are also included in ALLOWED_HOSTS along with localhost. On greyarea-post, in mailman.cfg: [webservice] admin_pass: XXXXX admin_user: restadmin api_version: 3.1 hostname: 0.0.0.0 port: 8870 use_https: no The password and username are as on web1. Do you see REST requests from the Postorius machine in core's mailman.log and access.log? Yes, there are lots of requests of the form: [07/Jun/2020:15:00:01 +0000] "GET /3.1/lists?count=10&page=1 HTTP/1.1" 200 470 "-" "GNU Mailman REST client v3.3.1" I made a new list using the core CLI, and as a result of navigating directly to the list archive page I get to see: [06/Jun/2020:23:00:02 +0000] "GET /3.1/lists/chbcdaily(a)ch-bc.org.uk HTTP/1.1" 200 365 "-" "GNU Mailman REST client v3.3.1" ... but in neither case do I get a complete screen on the browser or 'follow-up' requests. I don't have a file access.log on the greyarea-post. On the greyarea-web1 I have mailmansuite.log with the last few lines: File "/opt/mailman3/lib/python3.6/site-packages/mailmanclient/restbase/ba se.py", line 74, in rest_data response, content = self._connection.call(self._url) File "/opt/mailman3/lib/python3.6/site-packages/mailmanclient/restbase/co nnection.py", line 124, in call 'Could not connect to Mailman API: ', repr(e)) mailmanclient.restbase.connection.MailmanConnectionError: ('Could not connect to Mailman API: ', 'ConnectionError(MaxRetryError("HTTPConnectionPool(host=\'0.0.0.0\', port=8870): Max retries exceeded with url: /3.1/domains/ch-bc.org.uk (Caused by NewConnectionError(\'<urllib3.connection.HTTPConnection object at 0x7f5416db8518>: Failed to establish a new connection: [Errno 111] Connection refused\',))",),)') ERROR 2020-06-03 01:02:06,115 29002 django.request Service Unavailable: /postorius/lists/ the uwsgi-error_*.log contains many lines of the form: api: url is [2]http://greyarea-post.cam.ivimey.org:8870/3.1/lists?count=10&page= 1 api: url is [3]http://greyarea-post.cam.ivimey.org:8870/3.1/lists?count=10&page= 1 My reason for thinking, in my original post, that the wrong host address is being used is that the ConnectionError above contains 0.0.0.0 in its url for /3.1/domains/... but 0.0.0.0 is only present as the listen address on the core web service and does not appear in the config for postorius. I hope this helps, Ruth -- -- Software Manager & Engineer Tel: 01223 414180 Blog: [4]http://www.ivimey.org/blog LinkedIn: [5]http://uk.linkedin.com/in/ruthivimeycook/ References 1. http://greyarea-post:8870/ 2. http://greyarea-post.cam.ivimey.org:8870/3.1/lists?count=10&page=1 3. http://greyarea-post.cam.ivimey.org:8870/3.1/lists?count=10&page=1 4. http://www.ivimey.org/blog 5. http://uk.linkedin.com/in/ruthivimeycook/

5 years, 2 months

[MM3-users] Re: Sending a message to a subscription applicant when a subscription request is made

by Allan Hansen

Thank you, Mark. That makes sense. And, as you suggested, this will not work for me, because a lot of people log in and then apply to more lists. I can't exhort them to get the accounts set up and do their subscription maintenance while logged in, and they tell them that if they want to sign up for another list they have to log out first. __ I do need to find another way. I suggested these options: a. That we change the lines in the Python program in our installation that send 'list:admin:action:subscribe' to the list admins to instead send the template to the applying subscriber. b. That we change the lines in the Python program in our installation that send 'list:user:action:subscribe' to the subscriber with an unverified address to always do this, even when the incoming address has already been verified. c. That the current 'list:user:action:subscribe' be changed in published Mailman 3 source to 'list:user:action:confirm' and a new template ''list:user:action:subscribe' be set up to be sent when any subscribe request is made. This is more work, of course, so not likely a good thing to hack locally. It could be useful to other users. Of course, (a.) and (b.) are preferred in the short term, as I'd like to get our procedure simplified. Any idea which file to change for either, and some suggestion as to what to change? Yours, Allan On 3/28/23, 10:18, "Mark Sapiro" <mark(a)msapiro.net <mailto:mark@msapiro.net>> wrote: On 3/28/23 09:19, Allan Hansen wrote: > Mark, > > I tried doing this. > I unsubscribed myself from a list, set the policy as you suggest and re-applied. > I got no confirmation messages but as moderator I got the moderate message. How did you reapply? with the subscribe policy confirm then moderate a new subscriber should get the list:user:action:subscribe message and have to confirm before the request waits moderation? However, see below. > I then tried a bogus email and saw that a message was sent to that and no moderator message to me. > Would the server skip the verification message because I'm a moderator/admin? It's not because you are an admin. It's because you were logged in when you subscribed from the list's info page. You will need to confirm if you subscribe anonymously without logging in or subscribe via email, but if you are logged in to Postorius when you request subscription, that is sufficient confirmation that the request really comes from you, so you don't get an email confirmation. So, depending on your circumstances, this may or may not work for you. -- 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/D4WXXVOHXTDLRDGXV66GV4BAMWBRYEPF/ This message sent to hansen(a)rc.org <mailto:hansen@rc.org>

2 years, 4 months

[MM3-users] mailman.cfg (use_https: yes) fails

by Wolfgang Bock

Hello, I configuered 3 domains in postorius https://[mydomain]/mailman3/postorius/domains/ ... also shown here: https://[mydomain]/mailman3/admin/sites/site/ (django) I installed mailman3 with debian command apt-get install mailman3-full. The package mailman3-full is described as follows: Paket: mailman3-full (3.2.1-1) (for debian-buster, W.B.) ... Betreuer: * Debian Mailman Team <mailto:pkg-mailman-hackers@lists.alioth.debian.org> (QS-Seite <https://qa.debian.org/developer.php?login=pkg-mailman-hackers%40lists.aliot…>, E-Mail-Archiv <https://lists.alioth.debian.org/pipermail/pkg-mailman-hackers/>) * Pierre-Elliott Bécue <mailto:peb@debian.org> (QS-Seite <https://qa.debian.org/developer.php?login=peb%40debian.org>) * Jonas Meurer <mailto:jonas@freesources.org> (QS-Seite <https://qa.debian.org/developer.php?login=jonas%40freesources.org>) Full Mailman3 mailing list management suite (metapackage) This is GNU Mailman, a mailing list management system. This metapackage depends on all components of the full Mailman3 suite: * mailman3: The core Mailman3 delivery engine * mailman3-web: Django project integrating Mailman3 postorius and hyperkitty * python3-mailman-hyperkitty: Mailman3 server plugin for Hyperkitty archiver ..... That's the output of # mailman info GNU Mailman 3.2.1 (La Villa Strangiato) Python 3.7.3 (default, Apr 3 2019, 05:39:12) [GCC 8.3.0] config file: /etc/mailman3/mailman.cfg db url: mysql+pymysql://[-secret-][mydomain]/mailman3?charset=utf8&use_unicode=1 devmode: DISABLED REST root url: http://localhost:8001/3.1/ REST credentials: restadmin:[-secret-] I dont know what version of mailman client is included in the package. Should I wait until an update includes a higher Version of the mailman-client? In this context I faced a strange behavior: In the database mailman3web in table django_site are listed several domains, either in the django-domain-management site https://[mydomain]/mailman3/admin/sites/site/ id domain name 1 example.com Example.com 2 [mydomain-1] [mydomain_name_1] 3 [mydomain-2] [mydomain_name_2] 4 [mydomain-3] [mydomain_name_3] In case I delete line 1 with the id 1, in the database or in the django-web-site, postorius fails to work. After re-inserting this line, postorius works again. Regards Wolfgang Am 16.11.2019 um 01:02 schrieb Mark Sapiro: > On 11/15/19 3:45 AM, Wolfgang Bock via Mailman-users wrote: >> That doesn't solve the problem. I changed that in mailman-web.py >> (MAILMAN_REST_API_URL = https://localhost:8001) and after that in >> mailman.cfg (use_https: yes). But got the same errormessage on postorius >> website. > > You posted this log excerpt: > > Nov 14 23:20:41 2019 (28590) 127.0.0.1 - - "GET > /3.0/lists?advertised=true&count=0&page=1 HTTP/1.1" 200 90 > Nov 14 23:20:41 2019 (28590) 127.0.0.1 - - "GET > /3.0/lists?advertised=true&count=10&page=1 HTTP/1.1" 200 606 > Nov 14 23:20:41 2019 (28590) 127.0.0.1 - - "GET /3.1/domains HTTP/1.1" > 200 1438 > Nov 14 23:20:41 2019 (28590) 127.0.0.1 - - code 400, message Bad > HTTP/0.9 request type > > > The first 3 GETs are a normal sequence of GETs from Postorius when you > go to the Mailing Lists view. That should be followed by a GET like "GET > /3.1/domains/domain.tld HTTP/1.1" where domain.tld is a configured > domain. Do you have any domains configured?/0.9'? > > I'm not sure what the issue is. You have an older version of > mailmanclient < 3.2.3a1 which uses httplib2 rather than requests. > https://pypi.org/project/httplib2/ says: > > HTTP and HTTPS > HTTPS support is only available if the socket module was compiled > with SSL support. > > but I don't think this can be the issue because the first 3 GETs work. > > You might try upgrading mailmanclient to 3.3.0. I don't know if that > will help, but it may. >

5 years, 9 months

[MM3-users] Re: integrating mm3 with postfix / lmtp

by Thor Atle Rustad

There is a way around it! I have had two issues with the the maxking docker image. One is that the regexp is not working properly. I reported that, and it has been fixed in newer code. My other problem is that the docker image creates a user, mailman, that receives uid 103. Well, uid 103 on my system is already taken by systemd-bus-proxy (grep 103 /etc/passwd returns "systemd-bus-proxy:x:103:105:systemd Bus Proxy,,,:/run/systemd:/bin/false"). My solution includes downloading the corrected postfix.py, and replacing the Dockerfile. I put the postfix.py in <docker-mailman>/core/assets/. My Dockerfile: FROM maxking/mailman-core RUN grep mailman /etc/passwd && grep mailman /etc/group \ && deluser mailman \ && addgroup -S -g900 mailman \ && adduser -S -u900 mailman mailman \ && grep mailman /etc/passwd && grep mailman /etc/group COPY assets/postfix.py /usr/local/lib/python3.6/site-packages/mailman/mta/postfix.py I then run docker build (with -t parameter, you must look up that yourself). I use a different name for my images, so I end up with (note, there are two tags per image): root@mailer:/home/mailman/docker/docker-mailman_mods/core# docker images REPOSITORY TAG IMAGE ID CREATED SIZE local/mailman_core_900 20171110_2 9649e84767e1 2 days ago 176MB local/mailman_core_900 latest 9649e84767e1 2 days ago 176MB local/mailman_web_900 20171110_2 07a9b3d7ddd6 2 days ago 247MB local/mailman_web_900 latest 07a9b3d7ddd6 2 days ago 247MB I do the same with the web image, as I need to change the user there, too. Then, in docker-compose.yaml, I change the line(s) referring to the image name(s): services: mailman-core: image: local/mailman_core_900 container_name: mailman-core hostname: mailman-core mailman-web: image: local/mailman_web_900 container_name: mailman-web hostname: mailman-web I don't know if this is a good solution, but at least it fixes some serious issues with the 3.1's postfix integration that wouldn't otherwise be fixed until the 3.2 release. The bottom line is that it works for me, but it adds an additional layer of complication. 2017-11-03 19:40 GMT+01:00 Abhilash Raj <maxking(a)asynchronous.in>: > On Fri, Nov 3, 2017, at 08:29 AM, Fabian A. Santiago wrote: > > October 26, 2017 11:07 PM, "Mark Sapiro" <mark(a)msapiro.net> wrote: > > > > > On October 26, 2017 7:30:35 PM PDT, "Fabian A. Santiago" < > fsantiago(a)garbage-juice.com> wrote: > > > > > >> That was it. Perfect. I manually modified my regexp map and it works > > >> now. Excellent and Thank you. You're the man. Does mm3 ever refresh > > >> those maps or only as I add new domains / lists? > > > > > > Only when you make changes to domains or lists. > > > > > > -- > > > Mark Sapiro <mark(a)msapiro.net> > > > Sent from my Not_an_iThing with standards compliant, open source > software. > > > > Mark, > > > > I've noticed that even simply restarting the mm3 components those alias > > maps get rewritten and the problem returns until I can manually edit it. > > Yeah, that is true. Transport maps are re-generated everytime the > container restarts. > > I don't think think there is any way around this right now :( > > > -- > Abhilash Raj > maxking(a)asynchronous.in > _______________________________________________ > Mailman-users mailing list > mailman-users(a)mailman3.org > https://lists.mailman3.org/mailman3/lists/mailman-users.mailman3.org/ >

7 years, 9 months

[MM3-users] Re: using SSH/TLS with external MTA

by Odhiambo Washington

On Sun, Jul 28, 2024 at 8:35 PM Mark Sapiro <mark(a)msapiro.net> wrote: > On 7/28/24 09:54, Roland Giesler via Mailman-users wrote: > > > > These settings from the Django docs look like the ones in mailman.cfg. > > Do I have to set them somewhere else too? > > > Yes. The settings in mailman.cfg only affect mail from Mailman. For mail > from Django, you have to set things like > > EMAIL_HOST = 'box2.gtahardware.co.za' > EMAIL_PORT = 465 > EMAIL_HOST_USER = 'roland(a)giesler.za.net' > EMAIL_HOST_PASSWORD = '...' > > and possibly others as desired, See the links to the Django docs for these. > > > > * |use_tls|:|EMAIL_USE_TLS| > > > > < > https://docs.djangoproject.com/en/5.0/ref/settings/#std-setting-EMAIL_USE_T… > > > > * |use_ssl|:|EMAIL_USE_SSL| > > > > < > https://docs.djangoproject.com/en/5.0/ref/settings/#std-setting-EMAIL_USE_S… > > > > * |timeout|:|EMAIL_TIMEOUT| > > > > < > https://docs.djangoproject.com/en/5.0/ref/settings/#std-setting-EMAIL_TIMEO… > > > > * |ssl_keyfile|:|EMAIL_SSL_KEYFILE| > > > > < > https://docs.djangoproject.com/en/5.0/ref/settings/#std-setting-EMAIL_SSL_K… > > > > * |ssl_certfile|:|EMAIL_SSL_CERTFILE| > > > > < > https://docs.djangoproject.com/en/5.0/ref/settings/#std-setting-EMAIL_SSL_C… > > > > This all goes in your Django settings which from other posts I gather is > /etc/mailman3/mailman3-web.py. I'm guessing you are using the Debian > packages and that's where the package puts the Django settings. > I am following this thread out of curiosity. So I added the same lines to my /opt/mailman3/settings.py - on a virtualenv install of the latest MM3 code.It's my test VM. After adding the lines and restarting mailmanweb, I then entered the virtualenv and did 'mailman-web createsuperuser' which completed successfully, but NO MAIL! As matter of fact, there isn't even anything in the logs of the MTA running at w.kictanet.or.ke. ``` root@ubuntu24:/home/wash# su mailman (venv) mailman@ubuntu24:~$ tail -n 5 /etc/mailman3/settings.py EMAIL_HOST = 'gw.kictanet.or.ke' EMAIL_PORT = 587 EMAIL_HOST_USER = 'mailman(a)gw.kictanet.or.ke' EMAIL_HOST_PASSWORD = 'XXXXXXYYYYYYYZZZZ' (venv) mailman@ubuntu24:~$ mailman-web createsuperuser Username (leave blank to use 'mailman'): mm3admin1 Email address: odhiambo(a)outlook.com Password: Password (again): Superuser created successfully. (venv) mailman@ubuntu24:~$ tail -n 5 /opt/mailman/web/logs/mailmanweb.log [Nothing in that file] (venv) mailman@ubuntu24:~$ tail -n 10 /opt/mailman/mm/var/logs/mailman.log [2024-07-29 13:41:22 +0300] [301491] [INFO] Starting gunicorn 22.0.0 [2024-07-29 13:41:22 +0300] [301491] [INFO] Listening at: http://127.0.0.1:8001 (301491) [2024-07-29 13:41:22 +0300] [301491] [INFO] Using worker: sync [2024-07-29 13:41:22 +0300] [301537] [INFO] Booting worker with pid: 301537 [2024-07-29 13:41:22 +0300] [301538] [INFO] Booting worker with pid: 301538 Jul 29 13:41:23 2024 (301485) bounces runner started. [29/Jul/2024:13:45:52 +0300] "GET /3.1/domains HTTP/1.1" 200 333 "-" "GNU Mailman REST client v3.3.5" [29/Jul/2024:13:45:52 +0300] "GET /3.1/domains/lists.wash.lan HTTP/1.1" 200 228 "-" "GNU Mailman REST client v3.3.5" [29/Jul/2024:13:45:52 +0300] "GET /3.1/users/odhiambo(a)gmail.com HTTP/1.1" 200 395 "-" "GNU Mailman REST client v3.3.5" [29/Jul/2024:13:45:52 +0300] "POST /3.1/lists/find HTTP/1.1" 200 503 "-" "GNU Mailman REST client v3.3.5" -- Best regards, Odhiambo WASHINGTON, Nairobi,KE +254 7 3200 0004/+254 7 2274 3223 In an Internet failure case, the #1 suspect is a constant: DNS. "Oh, the cruft.", egrep -v '^$|^.*#' ¯\_(ツ)_/¯ :-) [How to ask smart questions: http://www.catb.org/~esr/faqs/smart-questions.html]

1 year

[MM3-users] Re: nginx configuration on a multitasking server

by David Newman

On 12/10/21 12:57 PM, Mark Sapiro wrote: > On 12/10/21 10:22 AM, David Newman wrote: >> >> 1. At least on my system, the proxy_pass statement will only run >> without errors if I change this to a fully formed URL, e.g., >> 'proxy_pass http://127.0.0.1:8000'. Is this a typo in the docs? > > > I changed it at > https://docs.mailman3.org/en/latest/install/virtualenv.html#nginx-configura… > but I wonder if we shouldn't be using `uwsgi_pass` instead of proxy_pass. > > See https://nginx.org/en/docs/http/ngx_http_uwsgi_module.html#uwsgi_pass > > Are you using uwsgi or some other wsgi server. uwsgi, per the venv and PDF docs. Thanks for the fix. Regarding the uwsgi_pass docs, would 'uwsgi_pass_header' directives replace the 'proxy_set_header' ones in the venv doc? Looking at the uwsgi doc, it seems they might do different things. >> 2. What document root(s) and alias(es) to use for Postorius and >> Hyperkitty and the Django admin on a server that also runs other >> services (e.g., Postfix for non-list mail and Roundcubemail)? > > > If you can separate Mailman from other services by subdomain Alas, I can do that for all but one of the subdomains I have in production. For the past 15 or so years, users of that subdomain have used mail.domain.tld for MM2, roundcubemail, and an admin web UI that manages regular mail. The "/" has gone to roundcubemail, and users to go other directories for the other services. For example, MM2 users currently go to /mailman. , you can > configure them separately and for Mailman, root is irrelevant as > everything is proxied or aliased in a location directive. For example, > Mailman on the server that supports this list uses the > lists.mailman3.org domain and we have (excerpted) > ``` > server { > listen 443 default_server; > root /usr/share/nginx/html; > index index.html index.htm; > # root and index are probably irrelevant as we never go there > server_name lists.mailman3.org; > ssl on; > #ssl stuff > location / { > proxy_pass http://127.0.0.1:8000/; > # other proxy stuff In this example, / goes to MM3. The assumption here and in the MM3 docs is that we're standing up a dedicated server where MM3 pages should be served as the default. That's a totally valid design decision, and one could argue it's superior to running a bunch of other services on one machine. It's not the situation I have to deal with, though. Short of changing a long-standing URL, what I'm looking to do is have "/" continue to default to roundcubemail, and have users type in longer URLs for MM3 and other services. You're right that the root and index directives above are irrelevant since / goes to MM3 via proxy. What I'm asking is what root(s) and location(s) to use with nginx where MM3 isn't the default. Thanks again! dn > } > location /static/ { > alias /var/spool/mailman-web/static/; > } > location /robots.txt { > alias /usr/share/nginx/html/robots.txt; > } > location /favicon.ico { > alias /var/www/listorg/images/favicon.ico; > } > } > ``` > And for the other stuff we have > ``` > server { > listen 443; > server_name .list.org mirror.list.org mirror.mailman3.org; > root /var/www/listorg; > ssl on; > # ssl stuff > } > >

3 years, 8 months

[MM3-users] Re: Mailman sends Welcome emails, but does not send [List] postings emails

by Nelson Strother

Neither .../logs/mailman.log nor /var/log/syslog contain any recording of "Master detected ..." nor process exits other than at the time of `mailman stop` commands. Watching during these transitions with `vmstat` shows a decrease in free pages and an increase in swapping, but no definitive hint of the OOM reaper running. I did not intend to imply that `mailman start` (predictably) consumes more time than `mailman restart`. Both are lengthy and variable; I think one cause for `mailman stop` consuming more time than usual is when mailman receives a message as it is trying to stop, which is understandable. Interestingly if I use `systemctl start mailman` thus far the results are: - the wall clock duration is shorter than when `mailman start` is issued from the command line, and -- either that all of the runners remain present once they are started, -- or I can see in syslog a traceback from each missing runner process starting from .../mailman/.local/bin/runner and ending with "flufl.lock._lockfile.NotLockedError: Already unlocked". I do not yet understand how to make use of these clues, but at least one can see an epitaph from each deceased process. On 6/6/23 14:47, Mark Sapiro wrote: > On 6/6/23 07:58, Nelson Strother wrote: >> >> No errors are being recorded in the mailman log files. This is GNU >> Mailman 3.3.8 via `pip install mailman` on Debian 5.10.179-1 >> (2023-05-12) running on a shared system where VMware gives this >> server enough cycles that `mailman start` and `mailman stop` each >> consume from 20 minutes to an hour of wall clock time, so I do not >> issue those commands recreationally, attempting to keep the system >> available for users. What should I do to help understand the cause >> for these failures? > > > If a runner has died, its death and a reason should be logged in > Mailman's var/logs/mailman.log with a message similar to > > Master detected subprocess exit (pid: 8617, why: SIGNAL 15, class: in, > slice: 1/1) > > This may not be the case if the runner is killed by the OS for an out > of memory or similar reason. For this, look in syslog. > > `mailman stop` can take a long time because it is waiting for a runner > to stop. See https://gitlab.com/mailman/mailman/-/issues/255 but that > issue was fixed long ago. I don't understand why `mailman start` would > take more time than `mailman restart`. In fact, `mailman restart` > effectively does `stop` and `start`, but only for those runners which > are running. > > Since you seem to frequently have missing runners, I suspect something > like an OOM condition is causing the OS to kill them. Although, I > wonder if you are correctly interpreting the logs. While the absence > of the `retry`, `task`, `nntp` and `archive` runners might not be > noticed except for messages not being archived, if either the `in` or > `pipeline` runner is not running, no list posts will be processed. > > >> Would not it be helpful for this limitation of restart to be included >> in: >> mailman restart --help >> with a suggestion to use `mailman stop` and `mailman start` instead? > > > I have just filed https://gitlab.com/mailman/mailman/-/issues/1082 for > this. >

2 years, 2 months

[MM3-users] Re: File "/usr/lib/python2.7/httplib.py", line 1148, in getresponse raise ResponseNotReady()

by Alex Schuilenburg

On Fri, 2020-10-02 at 20:28 -0700, Mark Sapiro wrote: > [...]Part of what's going on is some MM 2.1 archives has email > addressesobfuscated by replacing `@` with ` at ` so the import > process reversesthis and changes the From: toheader is```From: > Firstname Surname@example-UK <user(a)example.com>```which now contains > two email addresses albeit not separated by a commaand picks the > first. The message then gets properly archived withsender `Firstname > Surname@example-UK` which is a syntactically validemail address and > doesn't cause the ResponseNotReady() exception insync_mailman so I > don't see that issue. I saw the message archived also, but in the sync_mailman I did pick up something. I'm a bit old school so my first goto is normally a strace. From that I saw the sync connect to the rest qrunner, querying each email address for their mailman id. However, when it came to querying the dodgy email, it did not get that far. The connection was made and closed. Initially I thought the rest closed its connection before the sync could even get it's query out (i.e. GET /3.0/users/Firstname Surname@example-UK) but an strace on the rest and the sync shows the connection made and closed immediately afterwards at both ends. Twice in fact (IPv4 and IPv6). Previous calls were as you would expected with the GET and HTTP/1.0 response. The traceback ResponseNotReady() exception within the client.get_user(self.address) call of Sender.set_mailman_id in hyperkitty/models/sender.py only makes sense if sync was attempting to talk on a closed socket. So I didn't get it - I still dont. Why did the sync not get as for as the rest "GET /3.0/users/Firstname Surname@example-UK" and "HTTP/1.0 404 Not Found" exchange, as it had with the previous (valid) email? Why was the rest socket closed without a query made? My only thought last night was that the rest connection was established by the sync, when then decided to close the connection because the email was invalid, but it continued attempting to get the mailman_id hence the exception. Anyway, you then stepped up with your suggestion, I added the correct email to hyperkitty_sender, updated the faulty email record in hyperkitty_email to point to the correct hyperkitty_sender record and deleted the dodgy hyperkitty_sender record, and the sync passed. All good for me anyway. > The difference is either the fact that my test runs with the HEAD of > theGitLab branch which may not have the issue or the difference > between thereal From: header and the sanitized one is significant. If the sync works for you in the trunk now, there seems little point figuring out why this does not work in the current debian package. Hopefully there will be an update by debain soon, and for now I can carry on my import and fix the issue if it happens again. However, it would be interesting to know what ends up in your archive? I suspect it will have the dodgy "Firstname Surname@example- UK" address as the sender. If that is the case then certainly as you mention in https://gitlab.com/mailman/hyperkitty/-/issues/320#note_423030205, HyperKitty's wrapper should be smarter and call email.utils.parseaddr() first and only try replacing at if the returned address doesn't contain @. Otherwise you end up with a bad import and dodgy email in your archives. Thanks -- Alex

4 years, 10 months

[MM3-users] [SOLVED] Re: Re: multiple sites on a mailman3 server question

by William Oliver

On Wed, 2021-12-29 at 09:21 -0800, Mark Sapiro wrote: > On 12/29/21 8:48 AM, William Oliver wrote: > > > > [snip] > If you are following > https://docs.mailman3.org/en/latest/install/virtualenv.html you have > ``` > location / { > proxy_pass http://127.0.0.1:8000; > proxy_set_header Host $host; > proxy_set_header X-Forwarded-For $remote_addr; > > } > ``` > in your nginx config and everything goes to uwsgi. What you want is to > put those proxy directives in only the mailman locations as at > https://lists.mailman3.org/archives/list/mailman-users@mailman3.org/message… > > and then configure your document root so other locations are served > from > there. > The problem was more stupid than one might imagine. My browser was caching so no matter what changes I made, it loaded domain/mailman/lists because that was what was cached. When I tinkered with things, I only changed whether or not mailman was loaded after that. I changed machines and used a different browser, and it started working fine. And it worked fine on my regular box once I cleared my browser's cache. It turns out that nginx works like it's supposed to work. Go figure. So, just to make things clear. Here was my goal: www.domain.com <-- go to welcome page lists.domain.com <-- go to mailman later, I'll install roundcube for mail.domain.com This gives me two primary entries in nginx. I'll send www.domain.com to /var/www/html2 and lists.domain.com to /var/www/html (though mailmanweb will kick in before that). Here's the /etc/nginx/sites-enabled file that works. The entry for location/ for the mailman section is different from the one you pointed to, but it is cut and pasted from one of the examples on that site. I can't find it right now, though -- but it works fine, and life is short. Anyway, this works if you clear your browser's cache: **************************************************** ##### paths for www.exampledomain.com ##### #### just goes to /var/www/html2 ##### server { root /var/www/html2; index index.html index.htm index.nginx-debian.html; server_name exampledomain.com, mail.exampledomain.com, www.exampledomain.com; location /{ # try_files $uri $uri/ =404; } ##### added 12/19 listen 443 ssl default_server; listen [::]:443 ssl default_server; ########## ssl_certificate /etc/letsencrypt/live/exampledomain.com/fullchain.pem; # managed by Certbot ssl_certificate_key /etc/letsencrypt/live/exampledomain.com/privkey.pem; # managed by Certbot include /etc/letsencrypt/options-ssl-nginx.conf; # managed by Certbot ssl_dhparam /etc/letsencrypt/ssl-dhparams.pem; # managed by Certbot } ##### this for lists.exampledomain, that turns on mailman server { root /var/www/html; index index.html index.htm index.nginx-debian.html; server_name lists.exampledomain.com; location /{ proxy_pass http://127.0.0.1:8000; proxy_set_header Host $host; proxy_set_header X-Forwarded-For $remote_addr; #proxy_set_header X-Forwarded-For $proxy_add_x_forwarded_for; proxy_set_header X-Forwarded-Host $host; proxy_set_header X-Forwarded-Server $host; proxy_set_header X-Forwarded-Proto $scheme; proxy_redirect off; } location /static/ { alias /opt/mailman/web/static/; } ##### added 12/19 listen 443 ssl ; listen [::]:443 ssl ; ########## ssl_certificate /etc/letsencrypt/live/exampledomain.com/fullchain.pem; # managed by Certbot ssl_certificate_key /etc/letsencrypt/live/exampledomain.com/privkey.pem; # managed by Certbot include /etc/letsencrypt/options-ssl-nginx.conf; # managed by Certbot ssl_dhparam /etc/letsencrypt/ssl-dhparams.pem; # managed by Certbot } ###### Certbot stuff to force things to 443 server { if ($host = mail.exampledomain.com) { return 301 https://$host$request_uri; } # managed by Certbot if ($host = www.exampledomain.com) { return 301 https://$host$request_uri; } # managed by Certbot if ($host = lists.exampledomain.com) { return 301 https://$host$request_uri; } # managed by Certbot listen 80 ; listen [::]:80 ; server_name www.exampledomain.com lists.exampledomain.com mail.exampledomain.com exampledomain.com; return 404; # managed by Certbot } ********************************************************

3 years, 7 months

[MM3-users] Re: External MTA incoming mail: configuration

by Roland Giesler

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.

1 year

Search results for query "sapiro"