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

[MM3-users] Re: Enable delivery

by Mark Sapiro

On 12/9/24 17:35, Hirayama, Pat wrote: > Greetings, > > I'm finding something a bit odd with our listserv. Please see https://wiki.list.org/DOC/Mailman%20is%20not%20Listserv > Some of the members of some of the lists are reporting that they aren't receiving messages sent to the list. When I review the member options for the person in question, I see that Delivery Status shows nothing selected (i.e. neither radio button is selected for Enabled or Disabled). If you look in the MTA logs is mail being sent to them. As far as the Delivery Status showing nothing, that means the member's delivery_status is None. The ultimate delivery status is determined by checking first the member's delivery_status, then the address's delivery_status, then the user's delivery_status and finally Mailman's global preferences. The first non-None value is what's used. See https://gitlab.com/mailman/mailman/-/blob/master/src/mailman/model/member.p… Also see the various tabs at https://www.example.com/mailman3/accounts/subscriptions/ > If I select Enabled and Save, then delivery starts working for that user. This should only happen if the users address or user based preference or the global preference is Disabled. > There are other members of the list that have neither Enabled or Disabled selected, but they are working. Which also seems to mean that when I run: > > mailman members --nomail any listname@listserv > > Nothing is returned. Because all members ultimately have delivery enabled. > If anyone has any ideas about why this might be the case, or how I might proactively identify other members who aren't receiving mail, that would be appreciated. Alternately, any thoughts on how I might force all members to Delivery Status Enabled, that would also be great. It shouldn't be necessary to do that. For one of these members, e.g. user(a)example.com, that isn't getting mail, do this in mailman shell ``` mailman shell -l list(a)example.com 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. The variable 'm' is the list(a)example.com mailing list >>> from mailman.core.constants import system_preferences >>> mbr = m.members.get_member('user(a)example.com') >>> print(mbr.delivery_status) (this will print the ultimate delivery_status, for the components do) >>> print(mbr.preferences.delivery_status) (output) >>> print(mbr.address.preferences.delivery_status) (output) >>> print(mbr.address.user.preferences.delivery_status) (output) >>> print(system_preferences.delivery_status) (output) >>> ``` The first of the (output) lines which is not None should be the same as the output from print(mbr.delivery_status). -- Mark Sapiro <mark(a)msapiro.net> The highway is for gamblers, San Francisco Bay Area, California better use your sense - B. Dylan

6 months

[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

4 years, 11 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.

10 months, 2 weeks

[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

4 years, 9 months

[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, 3 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

[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, 6 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, 1 month

[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, 8 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, 5 months

Search results for query "sapiro"