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

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

by Mark Sapiro

On 6/20/20 1:37 PM, Ruth Ivimey-Cook wrote: > Thanks Mark, Ignore bracketed numbers below ([1], [2], etc.) They come from conversion of the HTML only post to plain text. > On 20/06/2020 03:53, Mark Sapiro wrote: > > 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. That all looks good. > 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. Yes, that's actually a gunicorn log so would only be on greyarea-web1, but the mailman.log tells us the requests are getting to the core REST API, so we don't need that info. > 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/ OK. This is telling us that mailmanclient (the REST API Python bindings that Postorius uses to access core) is having trouble establishing a connestion to the core REST server, but it clearly gets there some of the time based on the mailman.log entries. > 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. The ConnectionError above comes from requests.request (docs at <https://requests.readthedocs.io/en/master/>). Client only provides a URL in the call to request and the URL is the baseurl + the path and the baseurl is MAILMAN_REST_API_URL which you have as http://greyarea-post:8870. Entries above have http://greyarea-post.cam.ivimey.org:8870/. Is that the correct FQDN? I suspect a DNS lookup issue. How does greyarea-web1 resolve greyarea-post? You could try a FQDN that greyarea-web1 can lookup in DNS rather than relying on /etc/resolv.conf and/or /etc/hosts. -- Mark Sapiro <mark(a)msapiro.net> The highway is for gamblers, San Francisco Bay Area, California better use your sense - B. Dylan

5 years, 2 months

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

by Roland Giesler

On 2024/07/28 17:06, Mark Sapiro wrote: > On 7/28/24 06:26, Roland Giesler via Mailman-users wrote: >> On 2024/07/28 00:39, Mark Sapiro wrote: >>> >>> What do you see in Mailman's smtp.log and in the mail.log on the >>> mail server? >> >> The smtp log is in syslog... > > The smtp.log I refer to is Mailman's smtp.log which is in Mailman's > var/logs/ directory. There are no entries in the /var/log/mailman3/smtp.log that get created when I try to log in (and authenticate) in Postorius. Jul 28 15:30:18 2024 (516) Available AUTH mechanisms: LOGIN(builtin) PLAIN(builtin) Jul 28 15:30:18 2024 (516) Peer: ('192.168.161.103', 54464) Jul 28 15:30:18 2024 (516) ('192.168.161.103', 54464) handling connection Jul 28 15:30:18 2024 (516) ('192.168.161.103', 54464) EOF received Jul 28 15:30:18 2024 (516) ('192.168.161.103', 54464) Connection lost during _handle_client() Jul 28 15:30:18 2024 (516) ('192.168.161.103', 54464) connection lost Jul 28 15:50:22 2024 (1059) Available AUTH mechanisms: LOGIN(builtin) PLAIN(builtin) Jul 28 15:50:22 2024 (1059) Peer: ('192.168.161.103', 34814) Jul 28 15:50:22 2024 (1059) ('192.168.161.103', 34814) handling connection Jul 28 15:50:22 2024 (1059) ('192.168.161.103', 34814) EOF received Jul 28 15:50:22 2024 (1059) ('192.168.161.103', 34814) Connection lost during _handle_client() The recent attempts I made where after 18:00.

1 year, 1 month

[MM3-users] Re: Messages disappearing into hole??

by Mark Sapiro

On 8/30/20 6:15 AM, Ruth Ivimey-Cook wrote: > > I looked around the interface and decided to set up the sender as a > non-member, as that appeared to permit them to be "special" and outside > of the normal access rules for the list. Before I did that I could send > a message from this sender and that would be sent to me as list owner > for moderation, so both incoming (from my mailserver) and outgoing (to > it) can be completed. > > However, with a non-member who is auto-accepted the message is passed > from my mailserver to mailman and then disappears. I cannot find > anything in the logs to indicate what happened next. I have tried > setting the default non-member policy to both 'hold' and 'default' with > no change in that behaviour. The logs for the mailserver show the > message being sent to mailman; mailman's "smtp.log" shows an LMTP > message being received ok, and then nothing. > > Any ideas how to find out what is going on? I can share config if that > helps but not sure what would be useful. First, this is a bad way to configure an announce list because anyone can post by spoofing the authorized posting address. The better way is to set a list moderator password and post using an Approved: <password> header or pseudo header. See <https://docs.mailman3.org/projects/mailman/en/latest/src/mailman/rules/docs…> for details. As far as the disappearing message is concerned, it's hard to say. What is the non-member's moderation action? Unless it is 'list default' setting the list's default non-member policy has no effect. Also, if the non-member's address or a pattern matching it is in accept_these_nonmembers, that takes precedence over whatever the non-member's moderation action is. One guess about the disappearing message is content filtering may be removing all the message. What is the setting for Filter Action? > As a side-issue, at one point I added a regex matching the sender > address to the acceptable members list, but find that I cannot now > delete it (using postorius): If I delete the field and Save, it returns > on page refresh. There is an issue with Postorius. You can't empty these settings. If you clear the box or or have it contain only whitespace, Postorius won't change the prior setting. In order to remove the only entry in Postorius, you have to replace it with a bogus entry or you can remove it with `mailman shell`. I've just filed <https://gitlab.com/mailman/postorius/-/issues/444> for this. -- Mark Sapiro <mark(a)msapiro.net> The highway is for gamblers, San Francisco Bay Area, California better use your sense - B. Dylan

5 years

[MM3-users] Re: archiving problem & updates

by Mark Sapiro

On 2/19/21 7:19 AM, Christian Stalberg via Mailman-users wrote: > I see two messages waiting to be archived. Below is excerpt from the > logfile: > > Feb 10 13:40:49 2021 (974) held message approved, message-id: > <CAGrL7FsaX8EG9pMUZreJrQt1xkEyR3ySuw2-xn3m443O0N3j1A(a)mail.gmail.com> > [10/Feb/2021:13:40:49 +0000] "POST > /3.1/lists/ncpoa(a)lists.ccalternatives.org/held/5 HTTP/1.1" 204 0 "-" "GNU > Mailman REST client v3.3.1" > [10/Feb/2021:13:40:49 +0000] "GET > /3.1/lists/ncpoa(a)lists.ccalternatives.org/held?count=0&page=1 HTTP/1.1" 200 > 90 "-" "GNU Mailman REST client v3.3.1" > [10/Feb/2021:13:40:49 +0000] "GET > /3.1/lists/ncpoa(a)lists.ccalternatives.org/held?count=10&page=1 HTTP/1.1" 200 > 90 "-" "GNU Mailman REST client v3.3.1" > [10/Feb/2021:13:40:50 +0000] "GET > /3.1/lists/ncpoa(a)lists.ccalternatives.org/requests HTTP/1.1" 200 90 "-" "GNU > Mailman REST client v3.3.1" > [10/Feb/2021:13:40:50 +0000] "GET > /3.1/lists/ncpoa(a)lists.ccalternatives.org/held?count=50&page=1 HTTP/1.1" 200 > 90 "-" "GNU Mailman REST client v3.3.1" > Feb 10 13:40:55 2021 (846) HyperKitty failure on > https://lists.ccalternatives.org/archives/api/mailman/archive: <html>^M > <head><title>413 Request Entity Too Large</title></head>^M > <body bgcolor="white">^M > <center><h1>413 Request Entity Too Large</h1></center>^M > <hr><center>nginx/1.14.2</center>^M > </body>^M > </html>^M > (413) > Feb 10 13:40:55 2021 (846) Exception in the HyperKitty archiver: <html>^M > <head><title>413 Request Entity Too Large</title></head>^M > <body bgcolor="white">^M > <center><h1>413 Request Entity Too Large</h1></center>^M > <hr><center>nginx/1.14.2</center>^M > </body>^M > </html>^M > Feb 10 13:40:55 2021 (846) Traceback (most recent call last): > File > "/opt/mailman/mm/venv/lib/python3.7/site-packages/mailman_hyperkitty/__init_ > _.py", line 154, in _archive_message > url = self._send_message(mlist, msg) > File > "/opt/mailman/mm/venv/lib/python3.7/site-packages/mailman_hyperkitty/__init_ > _.py", line 210, in _send_message > raise ValueError(result.text) > ValueError: <html>^M > <head><title>413 Request Entity Too Large</title></head>^M > <body bgcolor="white">^M > <center><h1>413 Request Entity Too Large</h1></center>^M > <hr><center>nginx/1.14.2</center>^M > </body>^M The issue is that one of the messages in var/archives/hyperkitty/spool/ is throwing this exception and that effectively stops archiving of new messages. I'm not sure what causes Request Entity Too Large, but I suspect it is a very large message body. You can examine the messages in var/archives/hyperkitty/spool/ with Mailman's `bin/mailman qfile` command, but I suspect the problem is caused by the largest of the files. You can just move it aside, and that should allow archiving to resume. -- Mark Sapiro <mark(a)msapiro.net> The highway is for gamblers, San Francisco Bay Area, California better use your sense - B. Dylan

4 years, 6 months

[MM3-users] Re: Editing "automatic responses" tab i Postorius does not work

by David Krantz

But this one is already exposed. But I cannot change it anyway as the tab requires URIs for the different templates to allow saving. I do not use those URIs as I have configured the defaults as I like them. I tried once and it failed so I decided to set the defaults instead. cheers. // David On Sun, May 21, 2017 at 3:48 PM, Mark Sapiro <mark(a)msapiro.net> wrote: > On 5/21/17 5:22 AM, David Krantz wrote: >> >> I am trying to change e.g. the value of "notify admin on membership >> changes" through postorius. > > > There are still many settings not yet exposed in Postorius. We are > painfully aware of this and will probably be working on some of this at > the PyCon sprints starting tomorrow. > > Until we get more of these addressed, you will need to use tools like > "mailman withlist" to set these things. > > -- > 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 > https://lists.mailman3.org/mailman3/lists/mailman-users.mailman3.org/

8 years, 3 months

[MM3-users] so many instances of mailman.cfg

by Christian Stalberg

Question: I've five copies of mailman.cfg on my box. How can I tell which one is actually being used please? -----Original Message----- From: Mark Sapiro <mark(a)msapiro.net> Sent: Friday, November 26, 2021 11:06 AM To: mailman-users(a)mailman3.org Subject: [MM3-users] Re: mass subscribers disablement!? On 11/26/21 9:39 AM, Christian Stalberg via Mailman-users wrote: > After the first time where users were unsubscribed automatically, I > added back one at a time all the subscribers who were unsubscribed. > Now they have all been unsubscribed again automatically. They are > valid working email addresses. How can I stop this behavior from occurring please? Do you have the bounce processing notifications `Notify owner on disable` and `Notify owner on removal` set to `Yes`. If not, set them. Then, what's in the notices you receive? You might also consider setting `verp_probes: yes` in the `[mta]` section of mailman.cfg. This will avoid some issues with users being disabled/unsubscribed due to list posts being rejected as spam. -- 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, 9 months

[MM3-users] Re: Another interesting error...

by Mark Sapiro

On 04/23/2018 01:31 PM, Darren Smith wrote: > So it appears that there was a message sent to one of our mailing lists > that was put into the held message queue. However, when attempting to go to > the message to do the moderation, the web page returns and Error 500. > > Looking in the mailman log, I found this: > > Apr 23 14:21:02 2018 (17878) REST request handler error: > Traceback (most recent call last): > File "/opt/mailman3/conda/lib/python3.6/wsgiref/handlers.py", line 137, > in run > self.result = application(self.environ, self.start_response) > File > "/opt/mailman3/conda/lib/python3.6/site-packages/mailman/database/transac > tion.py", line 50, in wrapper > rtn = function(*args, **kws) > File > "/opt/mailman3/conda/lib/python3.6/site-packages/mailman/rest/wsgiapp.py" > , line 214, in __call__ > return super().__call__(environ, start_response) > File "/opt/mailman3/conda/lib/python3.6/site-packages/falcon/api.py", > line 227 , in __call__ > responder(req, resp, **params) > File > "/opt/mailman3/conda/lib/python3.6/site-packages/mailman/rest/post_modera > tion.py", line 167, in on_get > resource = self._make_collection(request) > File > "/opt/mailman3/conda/lib/python3.6/site-packages/mailman/rest/helpers.py" > , line 159, in _make_collection > for resource in collection] > File > "/opt/mailman3/conda/lib/python3.6/site-packages/mailman/rest/helpers.py" > , line 159, in <listcomp> > for resource in collection] > File > "/opt/mailman3/conda/lib/python3.6/site-packages/mailman/rest/post_modera > tion.py", line 157, in _resource_as_dict > resource = self._make_resource(request.id) > File > "/opt/mailman3/conda/lib/python3.6/site-packages/mailman/rest/post_modera > tion.py", line 100, in _make_resource > make_header(decode_header(resource['subject']))) > File "/opt/mailman3/conda/lib/python3.6/email/header.py", line 174, in > make_he ader > h.append(s, charset) > File "/opt/mailman3/conda/lib/python3.6/email/header.py", line 295, in > append > s = s.decode(input_charset, errors) > UnicodeDecodeError: 'gb2312' codec can't decode byte 0x87 in position 2: > illegal multibyte sequence > > It LOOKS as if there might be a character in the email somewhere - possibly > in the subject or sender fields? - that is somehow unexpected. It appears that the Subject: header is RFC 2047 encoded and there is an encoded word with charset gb2312 that contains an invalid encoding. The message is apparently defective, but this kind of defect shouldn't cause a 500 error. I can't tell for sure from the traceback if this is Postorius or some other application accessing the REST api. Is it Postorius or something else? > I am attempting to find the held message - can someone point me where I can > go to see the message so that I can see what might be causing the problem? It's in Mailman's database in the 'message' table. -- Mark Sapiro <mark(a)msapiro.net> The highway is for gamblers, San Francisco Bay Area, California better use your sense - B. Dylan

7 years, 4 months

[MM3-users] Re: Displaying addresses in emails from a Mailman 3 installation

by Mark Sapiro

On 7/2/25 22:11, Steve Brown via Mailman-users wrote: > I may include more info than you really want to know. Here is the gist of the complaint: > > "For a while now, my e-mail for this list (but not other lists) just shows "To RADG" from "RADG" with a "CC" showing the actual sender's address. > That becomes a PITA when I need to find a post by a particular person, because the e-mail list does not show the CCs in the list, so I need to open each one to see who actually sent it." The user is using T-bird and does not need to scroll through the email list to find a post from a particular user. They should be using quick filter for this. I will send you more detail about this off list as details about the T-bird UI are off topic here. > This subscriber is not very savvy about email, and doesn't seem to understand fully when I tell him how it works, so if I start talking about headers, that's a PITA, too. He claims: > > "RADG is the only list that is afflicted by this, out of 21 that include groups.io, yahoo, google, Lyris, and probably a few I don't recall." > > Because some other members, including me, have had problems with unexpected entries in both From and To lines, I suspect that Mailman 3 does the DMARC enough differently than other lists and forums to cause conflicts with the way the MUAs try to help the user autocomplete an address. Most of those problems go away if they put an association of RADG (Risk Analysis Discussion Group) with radg(a)lists.radg.us in their address book. We chose the "use your own URL" option. The actual server address is deu.mailmanlists.eu; I don't know whether their customization of the MM3 installation might cause some of the problem. > > My understanding is that all of the recent posts are missing the poster's name, after behaving as expected for some time. Something must have changed, but what is baffling me. If you have any further ideas, fine, but don't waste a lot of time on this. Mailman, both 2.1 and 3, have been modifying the From: header for DMARC in exactly the same way for years. If anything changed is this regard it is specific to the deu.mailmanlists.eu installation, but I doubt it was Mailman that changed, particularly because you are still seeing the From: as it always was. It is much more likely that the users T-bird changed. -- Mark Sapiro <mark(a)msapiro.net> The highway is for gamblers, San Francisco Bay Area, California better use your sense - B. Dylan

2 months, 1 week

[MM3-users] Re: My Server is unable to connect to Mailman REST API few times

by Mark Sapiro

On 9/23/20 6:32 AM, Shashikanth Komandoor wrote: > Dear Mark, > > As I already said, your suggestion worked well on one list. > > But when I tried to implement the same trick on another list, I > found the below error messages in the mailman.log. > > >> * Sep 23 18:31:31 2020 (22951) Uncaught runner exception: [Errno >> 2] No such file or directory: >> '/var/lib/mailman/mailman/var/lists/press.dpr-pb.lsmgr.nic.in/digest.mmdf >> <http://press.dpr-pb.lsmgr.nic.in/digest.mmdf>'* >> >> >> *Sep 23 18:31:31 2020 (22951) Traceback (most recent call last):* >> * File "/usr/lib64/python3.6/mailbox.py", line 581, in __init__* >> * f = open(self._path, 'rb+')* >> *FileNotFoundError: [Errno 2] No such file or directory: >> '/var/lib/mailman/mailman/var/lists/press.dpr-pb.lsmgr.nic.in/digest.mmdf >> <http://press.dpr-pb.lsmgr.nic.in/digest.mmdf>'* >> *During handling of the above exception, another exception occurred:* >> *Traceback (most recent call last):* >> * File "/var/lib/mailman/mailman/src/mailman/core/runner.py", line 173, >> in _one_iteration* >> * self._process_one_file(msg, msgdata)* >> * File "/var/lib/mailman/mailman/src/mailman/core/runner.py", line 266, >> in _process_one_file* >> * keepqueued = self._dispose(mlist, msg, msgdata)* >> * File "/var/lib/mailman/mailman/src/mailman/runners/pipeline.py", line >> 37, in _dispose* >> * process(mlist, msg, msgdata, pipeline)* >> * File "/var/lib/mailman/mailman/src/mailman/core/pipelines.py", line 50, >> in process* >> * handler.process(mlist, msg, msgdata)* >> * File "/var/lib/mailman/mailman/src/mailman/handlers/to_digest.py", line >> 47, in process* >> * with Mailbox(mailbox_path, create=True) as mbox:* >> * File "/usr/lib64/python3.6/mailbox.py", line 893, in __init__* >> * _mboxMMDF.__init__(self, path, factory, create)* >> * File "/usr/lib64/python3.6/mailbox.py", line 585, in __init__* >> * f = open(self._path, 'wb+')**FileNotFoundError: [Errno 2] No such >> file or directory: >> '/var/lib/mailman/mailman/var/lists/press.dpr-pb.lsmgr.nic.in/digest.mmdf >> <http://press.dpr-pb.lsmgr.nic.in/digest.mmdf>'* >> >> I ran in both the ways you suggested i.e. through "mailman shell" > and "mailman remove". But no luck. > > Could you please suggest me at this point ? Mailman is trying to add a message to the digest of the press.dpr-pb.lsmgr.nic.in list, but the /var/lib/mailman/mailman/var/lists/press.dpr-pb.lsmgr.nic.in/ directory doesn't exist, presumably because the list has been removed. The question is why is Mailman trying to write to this list's digest.mmdf? Did the above result from unshunting something from before the list was removed? -- Mark Sapiro <mark(a)msapiro.net> The highway is for gamblers, San Francisco Bay Area, California better use your sense - B. Dylan

4 years, 11 months

[MM3-users] Re: slow restart time for mailmanweb

by David Newman

On 12/28/21 7:52 PM, Mark Sapiro wrote: > On 12/28/21 3:51 PM, David Newman wrote: >> On 12/28/21 1:20 PM, Mark Sapiro wrote: >> >> > If so, try adding >> > >> > KillSignal=SIGQUIT >> > >> > to the Service section and see if that fixes it. >> >> root@myhost:/etc/mailman3# time systemctl restart mailmanweb >> >> real 0m1.026s >> user 0m0.008s >> sys 0m0.004s >> >> My limited understanding of SIGQUIT is that it dumps core, but 'find / >> -type f -name '*.core' did not return any core dumps from this event. > > > Actually, SIGINT is probably better, SIGINT does fine: root@myhost:/etc/systemd/system# time systemctl restart mailmanweb real 0m1.024s user 0m0.009s sys 0m0.006s > but they should be equivalent. See > https://uwsgi-docs.readthedocs.io/en/latest/Management.html#signals-for-con… > and > https://uwsgi-docs.readthedocs.io/en/latest/Management.html#stopping-the-se… > > > I'll update the doc. Thank you! > >> Still unsure why the service hung on stop, but thanks! > > It hung on stop because systemd wasn't told how to stop uwsgi so it sent > a SIGTERM which doesn't stop it. Got it. Again, many thanks. dn

3 years, 8 months

Search results for query "sapiro"