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

[MM3-users] Re: SPF check fails for lists subdomain

by Jan Eden

On 2023-01-05 11:13, Odhiambo Washington wrote: > On Thu, Jan 5, 2023 at 10:56 AM Jan Eden via Mailman-users < > mailman-users(a)mailman3.org> wrote: > > > On 2023-01-04 15:07, Mark Sapiro wrote: > > > On 1/4/23 14:02, Jan Eden via Mailman-users wrote: > > > > Although I could specify the IP address in my SPF records directly (as > > > > you suggested), I do hope that my understanding of DNS records laid out > > > > above is not entirely misguided. My current setup does work as expected > > > > for eden.one, after all. > > > > > > As I said at < > > https://lists.mailman3.org/archives/list/mailman-users@mailman3.org/message… > > > > > > I was misreading your DNS and now I am as puzzled as you about the > > failure. > > > > It gets even more mysterious. I tried sending messages from both > > lists.eden.one and janeden.net (my other domain) to a gmail account and > > to another mail provider. Both messages passed the SPF checks on both > > services (s. the relevant headers quoted below). Now because I send > > those messages via my SMTP user (smtpuser(a)eden.one) and use SRS, the SPF > > check operates (and succeeds) on e.g. > > > > srs0=jdm+=5c=lists.eden.one=testlist-bounces+gmailuser=googlemail.com(a)eden.one > > (and not on somethingsomething(a)lists.eden.one or > > somethingsomething(a)janeden.net) Could this be the reason for the failed > > SPF checks in Yahoo's and Google's DMARC reports? > > > - Jan > > Might you be willing to use proven tools instead of trying so hard to > understand the myth? > > I use https://easydmarc.com/tools#spf-tools > It allows me to generate, lookup, test SPF, DKIM, DMARC, etc. I did use adequate tools to generate and test my DNS records, and this is why the DMARC reports quoted in my initial message are mysterious to me. Trying hard to solve a mystery might not be productive in every case, but I do not want to stop being curious. - Jan

2 years, 4 months

[MM3-users] Re: user mail not accepted

by Christian Stalberg

No. there was no response received by the user a la "results of your email commands" message. Simply the original email sent to the list. -----Original Message----- From: Mark Sapiro <mark(a)msapiro.net> Sent: Monday, April 26, 2021 5:25 PM To: mailman-users(a)mailman3.org Subject: [MM3-users] Re: user mail not accepted On 4/26/21 5:00 PM, Christian Stalberg via Mailman-users wrote: >>From smtp.log > > Apr 26 00:17:39 2021 (807) ('127.0.0.1', 38370) Data: b'DATA' > Apr 26 00:17:39 2021 (807) ('127.0.0.1', 38370) Data: b'QUIT' > Apr 26 00:17:39 2021 (807) ('127.0.0.1', 38370) connection lost Apr 26 > 00:17:39 2021 (807) Connection lost during _handle_client() Apr 26 > 00:18:11 2021 (809) > <019301d73a31$8e8e54e0$abaafea0$(a)ncboliviapartners.org> smtp to > ncpoa(a)lists.ccalternatives.org for 83 recips, completed in > 29.13376259803772 seconds Apr 26 00:18:11 2021 (809) > <019301d73a31$8e8e54e0$abaafea0$(a)ncboliviapartners.org> post to > ncpoa(a)lists.ccalternatives.org from christian(a)ncboliviapartners.org, > 5811 bytes Apr 26 00:18:11 2021 (809) > <161939626169.810.9530678025639681522(a)zarathustra.ccalternatives.org> > smtp to ncpoa(a)lists.ccalternatives.org for 1 recips, completed in > 0.0420069694519043 seconds > Apr 26 00:18:11 2021 (809) > <161939626169.810.9530678025639681522(a)zarathustra.ccalternatives.org> > post to ncpoa(a)lists.ccalternatives.org from > ncpoa-bounces(a)lists.ccalternatives.org, 869 bytes Apr 26 11:52:22 2021 > (819) > <161943793957.929.15640398646519288095(a)zarathustra.ccalternatives.org> > smtp to ssan(a)lists.ccalternatives.org for 1 recips, completed in > 0.22335004806518555 seconds > Apr 26 11:52:22 2021 (819) > <161943793957.929.15640398646519288095(a)zarathustra.ccalternatives.org> > post to ssan(a)lists.ccalternatives.org from > ssan-bounces(a)lists.ccalternatives.org, > 765 bytes > Apr 26 11:52:22 2021 (819) > <161943793960.929.13309139087156940549(a)zarathustra.ccalternatives.org> > smtp to ssan(a)lists.ccalternatives.org for 2 recips, completed in > 0.05862092971801758 seconds > Apr 26 11:52:22 2021 (819) > <161943793960.929.13309139087156940549(a)zarathustra.ccalternatives.org> > post to ssan(a)lists.ccalternatives.org from > noreply(a)lists.ccalternatives.org, 810 bytes Apr 26 11:55:22 2021 (819) > <161943812108.929.10391982256874011271(a)zarathustra.ccalternatives.org> > smtp to ssan(a)lists.ccalternatives.org for 1 recips, completed in > 0.1459965705871582 seconds > Apr 26 11:55:22 2021 (819) > <161943812108.929.10391982256874011271(a)zarathustra.ccalternatives.org> > post to ssan(a)lists.ccalternatives.org from > ssan-confirm+2144530ad102026077911eac6eb574bcbd04be92(a)lists.ccalternat > ssan-confirm+ives.o > rg, 1526 bytes > Apr 26 12:01:30 2021 (817) Available AUTH mechanisms: LOGIN(builtin) > PLAIN(builtin) > Apr 26 12:01:30 2021 (817) Peer: ('127.0.0.1', 38556) Apr 26 12:01:30 > 2021 (817) ('127.0.0.1', 38556) handling connection Apr 26 12:01:30 > 2021 (817) ('127.0.0.1', 38556) Data: b'LHLO > zarathustra.ccalternatives.org' > Apr 26 12:01:30 2021 (817) ('127.0.0.1', 38556) Data: b'MAIL > FROM:<christian(a)sewagesludgeactionnetwork.com>' > Apr 26 12:01:30 2021 (817) ('127.0.0.1', 38556) sender: > christian(a)sewagesludgeactionnetwork.com > Apr 26 12:01:30 2021 (817) ('127.0.0.1', 38556) Data: b'RCPT > TO:<ssan-confirm+2144530ad102026077911eac6eb574bcbd04be92(a)lists.ccalte > rnativ > es.org>' > Apr 26 12:01:30 2021 (817) ('127.0.0.1', 38556) recip: > ssan-confirm+2144530ad102026077911eac6eb574bcbd04be92(a)lists.ccalternat > ssan-confirm+ives.o > rg > Apr 26 12:01:30 2021 (817) ('127.0.0.1', 38556) Data: b'DATA' > Apr 26 12:01:30 2021 (817) ('127.0.0.1', 38556) Data: b'QUIT' It looks like the above 12:01:30 are the relevant entries, and that message was sent to ssan-confirm+2144530ad102026077911eac6eb574bcbd04be92(a)lists.ccalternativ ssan-confirm+es.org which is not the list, but the list's -confirm address. Was the response received by the user a "results of your email commands" message? > Apr 26 12:01:30 2021 (817) ('127.0.0.1', 38556) connection lost Apr 26 > 12:01:30 2021 (817) Connection lost during _handle_client() Apr 26 > 12:01:34 2021 (819) > <161943849287.814.5890052642238479423(a)zarathustra.ccalternatives.org> > smtp to ssan(a)lists.ccalternatives.org for 2 recips, completed in > 0.06680631637573242 seconds > Apr 26 12:01:34 2021 (819) > <161943849287.814.5890052642238479423(a)zarathustra.ccalternatives.org> > post to ssan(a)lists.ccalternatives.org from > noreply(a)lists.ccalternatives.org, 821 bytes Apr 26 12:01:34 2021 (819) > <161943849292.814.6140111398379700592(a)zarathustra.ccalternatives.org> > smtp to ssan(a)lists.ccalternatives.org for 1 recips, completed in > 0.04269862174987793 seconds > Apr 26 12:01:34 2021 (819) > <161943849292.814.6140111398379700592(a)zarathustra.ccalternatives.org> > post to ssan(a)lists.ccalternatives.org from > ssan-request(a)lists.ccalternatives.org, > 1335 bytes > > > Message sent that only the user receives: What I wanted to see was not the message sent to the list, but the message received by the one user from the list. If you are saying this message is that, it didn't come from any Mailman list. > Return-Path: <christian(a)sewagesludgeactionnetwork.com> > Delivered-To: ces(a)ecovillage.cc > Received: from box.ecovillage.cc ([127.0.0.1]) > by box.ecovillage.cc with LMTP id MDucNBythmCTSwAAMoO61A > for <ces(a)ecovillage.cc>; Mon, 26 Apr 2021 05:07:56 -0700 > X-Spam-Checker-Version: SpamAssassin 3.4.2 (2018-09-13) on > box.ecovillage.cc > X-Spam-Level: > X-Spam-Status: No, score=-1.1 required=5.0 tests=ALL_TRUSTED,DKIM_SIGNED, > DKIM_VALID,DKIM_VALID_AU,HTML_MESSAGE autolearn=ham > autolearn_force=no > version=3.4.2 > X-Spam-Report: > * -1.0 ALL_TRUSTED Passed through trusted hosts only via SMTP > * 0.0 HTML_MESSAGE BODY: HTML included in message > * -0.1 DKIM_VALID Message has at least one valid DKIM or DK signature > * 0.1 DKIM_SIGNED Message has a DKIM or DK signature, not > necessarily > * valid > * -0.1 DKIM_VALID_AU Message has a valid DKIM or DK signature from > * author's domain > X-Spam-Score: -1.1 > Received: from authenticated-user (box.ecovillage.cc [45.79.28.18]) > (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 > bits)) > (No client certificate requested) > by box.ecovillage.cc (Postfix) with ESMTPSA id 6EADF3E8CC > for <ssan(a)lists.naturalintelligence.us>; Mon, 26 Apr 2021 05:07:54 > -0700 (PDT) > DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; > d=sewagesludgeactionnetwork.com; s=mail; t=1619438876; > bh=1M7F/uIS0bNG6cWjecy/a9QjskrHVwJHkjWRv+ffpM4=; > h=From:To:References:In-Reply-To:Subject:Date:From; > b=jXOswVZgFeHBB+sjIDqVkNBQqIbfZCj9ZUfpVwl10NQEkGaoxckPHNOKT6x9zIqsW > BZ7iZqqi2mWprVQ8LrK48Lp7gvCQ/ipqspMeLt3t+uljzTtryHmV6uJFEAU3hqM33Y > nQqX6Z8la8Ko40F9Ayb4h4e/MOfPdA4nadgf5hZzt/DzPFZvzUbG3V8lWcHuyJNA2y > SQkhbNubQ6iNEEB0SyBjoOjl3g3LVxjxY+9kMGGmX+1PFfW90CpDDShRmKkkscEWaA > NiV0fX6U5LENBBnc6Q9ImLgXuaLdCqlBRBumJBk+eUUr007rpXXVAPck2NvUzGyM2v > kNNGlT68hGzEg== > From: <christian(a)sewagesludgeactionnetwork.com> > To: <ssan(a)lists.naturalintelligence.us> > References: > In-Reply-To: > Subject: How US chemical industry lobbying and cash defeated > regulation in Trump era > Date: Mon, 26 Apr 2021 05:07:37 -0700 > Message-ID: > <020501d73a94$cbe17440$63a45cc0$(a)sewagesludgeactionnetwork.com> > MIME-Version: 1.0 > Content-Type: multipart/alternative; > boundary="----=_NextPart_000_0206_01D73A5A.1F831170" > Thread-Index: Adc6h7I/qzBKx1yOT6aPOuipppacoQACatZAAADW1wA= > Content-Language: en-us > > How US chemical industry lobbying and cash defeated regulation in > Trump era Industry's congressional allies defeated nearly all PFAS > legislation while the Trump EPA killed, watered down or slowalked new > rules > > https://www.theguardian.com/environment/2021/apr/26/us-chemical-compan > ies-lo > bbying-donation-defeated-regulation > > -- 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/

4 years

[MM3-users] Re: Unable to get Postfix to bounce messages to non-existent lists

by skenny＠scss.tcd.ie

Thanks Mark Sapiro and Stephen J. Turnbull for your responses. Re the output of mailq - this was initially confusing (to me anyway). The diagnostic for the message stuck in the queue was "connection timed out", but the IP listed was the Postfix mail server's not Mailman's. At a guess, Postfix was trying to send the message to Postfix's local domain after it failed to LMTP it over to the Mailman server, and was unable to do that too. Since I posted yesterday, I hit upon a solution that seems to work ... I set relay_recipient_maps to the same value as transport_maps, so that the relevant config lines now look like this: transport_maps = regexp:/var/mailman-data/postfix_lmtp local_recipient_maps = $alias_maps relay_domains = regexp:/var/mailman-data/postfix_domains relay_recipient_maps = regexp:/var/mailman-data/postfix_lmtp This seems to have the desired effect (and, I hope, no unintended consequences). If I fire a message at a non-existent list now, I get an immediate bounce message in my mail client - "Recipient address rejected: User [nonexistent-list(a)lists.scss.tcd.ie] unknown in relay recipient table". No longer is the message loitering in the Postfix queue. The Postfix documentation for relay_recipient_maps says "Optional lookup tables with all valid addresses in the domains that match $relay_domains. [...] Technically, tables listed with $relay_recipient_maps are used as lists: Postfix needs to know only if a lookup string is found or not, but it does not use the result from the table lookup." For transport_maps, it says "Optional lookup tables with mappings from recipient address to (message delivery transport, next-hop destination). " Postfix does what we want now: bounce the message is the list name isn't found in relay_recipient_maps, forward it on to the Mailman server via LMTP (transport_maps setting) if it is. Re Stephen J. Turnbull's comment about the patch allowing Postfix to query Mailman's database and more, I think I'll hold off for the moment, but good to know. We will reconfigure when it makes it into an official release (we're using Maxking's Docker images). As ever I'm really grateful for your taking the time to respond, many thanks. Kind regards.

1 year, 2 months

[MM3-users] Re: Problem with digests not being sent daily

by Mark

On 2024-06-22 00:04, Mark Sapiro wrote: >>>> ...The mmdf files don't exist in the list's directory although there >>>> have been many posts to the list throughout the day. > If you look at some point prior to 22:30, are there > /opt/mailman/mm/var/lists/<list_id>/digests.mmdf files at that time? > and if so, what happins if you run `mailman digests --periodic` > manually at that point? I changed the digest and notify crons to 05:00. 0 5 * * * @daily /opt/mailman/venv/bin/mailman digests --periodic 0 5 * * * @daily /opt/mailman/venv/bin/mailman notify At ~04:50 I posted an email to the list. The message was delivered to members and archived. Nothing showed up in /opt/mailman/mm/var/lists/<LISTID> # cd /opt/mailman/mm/var/lists/<LISTID> # ls -la total 8 drwxr-xr-x 2 mailman mailman 4096 Jun 22 04:52 . drwxr-xr-x 6 mailman mailman 4096 Mar 25 21:32 .. Then, as "mailman", I ran "mailman digests --periodic" manually and got the same error (as expected since there is nothing there) ... $ /opt/mailman/venv/bin/mailman digests --periodic Traceback (most recent call last): File "/opt/mailman/venv/bin/mailman", line 8, in <module> sys.exit(main()) ^^^^^^ File "/opt/mailman/venv/lib/python3.11/site-packages/click/core.py", line 1157, in __call__ return self.main(*args, **kwargs) ^^^^^^^^^^^^^^^^^^^^^^^^^^ File "/opt/mailman/venv/lib/python3.11/site-packages/click/core.py", line 1078, in main rv = self.invoke(ctx) ^^^^^^^^^^^^^^^^ File "/opt/mailman/venv/lib/python3.11/site-packages/mailman/bin/mailman.py", line 69, in invoke return super().invoke(ctx) ^^^^^^^^^^^^^^^^^^^ File "/opt/mailman/venv/lib/python3.11/site-packages/click/core.py", line 1688, in invoke return _process_result(sub_ctx.command.invoke(sub_ctx)) ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ File "/opt/mailman/venv/lib/python3.11/site-packages/click/core.py", line 1434, in invoke return ctx.invoke(self.callback, **ctx.params) ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ File "/opt/mailman/venv/lib/python3.11/site-packages/click/core.py", line 783, in invoke return __callback(*args, **kwargs) ^^^^^^^^^^^^^^^^^^^^^^^^^^^ File "/opt/mailman/venv/lib/python3.11/site-packages/click/decorators.py", line 33, in new_func return f(get_current_context(), *args, **kwargs) ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ File "/opt/mailman/venv/lib/python3.11/site-packages/mailman/commands/cli_digests.py", line 126, in digests maybe_send_digest_now(mlist, force=True) File "/opt/mailman/venv/lib/python3.11/site-packages/mailman/app/digests.py", line 106, in maybe_send_digest_now os.rename(mailbox_path, mailbox_dest) FileNotFoundError: [Errno 2] No such file or directory: '/opt/mailman/mm/var/lists/<LISTID>/digest.mmdf' -> '/opt/mailman/mm/var/lists/<LISTID>/digest.6.3.mmdf'

10 months, 3 weeks

[MM3-users] Re: moving list from mm3 -> mm3

by Jens Günther

Thanks Mark for our answers, I already got a bit further. Am 09.12.23 um 00:27 schrieb Mark Sapiro: >> But it returns {"title": "405 Method Not Allowed"} and I don't know >> where to look in the docs, since it shows almost always a way through >> mailman shell. > You need a PUT command, not POST. Try the above with `-X PUT`. With the `-X PUT`-command, there is the following error: {"title": "400 Bad Request", "description": "Unexpected parameters: bounces_address, created_at, digest_last_sent_at, fqdn_listname, http_etag, join_address, last_post_at, leave_address, list_name, mail_host, next_digest_number, no_reply_address, owner_address, post_id, posting_address, request_address, usenet_watermark, volume"} -> I don't know why, since I tried it with the exact same example-list from where I got all these parameters (ex- and then import) ... do I still miss something? Or does it only work on "fresh" lists? > You can use Postorius -> Mass operations -> Mass subscribe to add the > members, but you can't do that for owners and moderators. Also you lose > information about the members such as Delivery status, Delivery mode and > other user settings. Is there another way to preserve these information about the members? (in general I don't think a lot of people put in effort to customize there memeberships ... and furthermore they would need to register, right?) >> ## registered users > > That is not the answer. Those are Mailman core users, not Django (web > login) users. You need to get the relevant entries from the auth_users > and account_emailaddress tables and add them to the new DB. Ok, that would be fine. Are there any more relations to other tables/columns that need to be set? (I just realised, that there are 2 different id in each table ... the one in auth_users is the user_id in account_emailaddress :-) scary). Do you have any suggestions on how to add them correctly? Thank you in advance for now and another big one in general to all of you on this list that try to help continouisly with all these problems. It's a great pleasure to be able to ask for help on a list like that. Thank you! Have a good rest of the year. Regards, Jens.

1 year, 4 months

[MM3-users] Re: config incoming email in my domain cpanel

by Rafael Mora

El jue., 3 ago. 2017 a las 14:09, Simon HANNA (<simon.hanna(a)serve-me.info>) escribió: > > > On August 3, 2017 8:50:41 PM GMT+02:00, Rafael Mora < > rafael.mora.guti(a)gmail.com> wrote: > >El jue., 3 ago. 2017 a las 13:21, Mark Sapiro (<mark(a)msapiro.net>) > >escribió: > > > >> On 08/03/2017 10:42 AM, Rafael Mora wrote: > >> > > >> > I've found the MX records on my cpanel but how do I redirect the > >emails > >> > going to my list to my private server? > >> > >> > >> You have to configure the MTA that is the MX for the domain to relay > >the > >> mail to the Mailman server. > >> > > > >Our domain is: LABBRANDS.COM We have that domain config in a Hosgator > >hosting. The emails sent to labbrands.com go to our hosting, so how do > >I > >tell cpanel in hostgator hosting that the mails sent to the list ( > >mailing(a)labbrands.com) are redirect to the MTA (postfix) in my private > >server (we have static public IP address) ?? > > > You can't redirect one email address using DNS! > If you don't want to host an entire domain on your own server, I suggest > using a subdomain (lists.example.con) instead. > Should I configure my private Centos7 server with subdomain lists.labbrands.com? Doing so how do I redirect the email to the private Centos where postfix and MM3 are installed? > You could probably also redirect one email in cpanel to the subdomain, but > I'm not sure how mailman and clients like emails with different domains... > In theory postfix can send emails using any domain. You just have to make > sure spf, dkim and PTR records are properly set. Otherwise you'll most > likely get issues with rejected mail... > -- > Sent from my Android device with K-9 Mail. Please excuse my brevity. > _______________________________________________ > Mailman-users mailing list > mailman-users(a)mailman3.org > https://lists.mailman3.org/mailman3/lists/mailman-users.mailman3.org/ > -- Atentamente / Best Regards Ing. Rafael Mora

7 years, 9 months

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

by Stephen J. Turnbull

Ruth Ivimey-Cook writes: > On 21/06/2020 04:52, Mark Sapiro wrote: > > Change that to greyarea-post > Problem is, if I do that (which I did in the beginning), the core rest > service listens on localhost / 127.0.0.1 I don't understand. I'm not in a position to test with Mailman itself right now, but the standalone gunicorn[1] does the right thing (takes an IP address and binds to the corresponding interface, or takes a domain name, resolves it to the IP address, and binds that to the corresponding interface). It does not substitute localhost. It could be a Mailman bug (Mailman 3 is usually configured with all components running on the same host, and that's how it's tested), but first, does greyarea-post resolve to a routable address on the relevant network when queried from that host? > IMO, the hostname parameter needs to be split up into a "what address > should the rest of the world use to address me" and separately "what > address(es) should I listen on". Multiple listen addresses enable > multihomed hosts to get the right connectivity, too. I'm not clear on what you're saying. An address is a rendezvous point; if you're not listening on the address that others are using, you won't meet. What good does it do to split them up? It's not clear to me why you think Mailman might want to be multihomed (which is different from the host wanting to be multihomed). I don't object to the work to make it so. But my paranoia says it's best if Mailman is cordoned off into the DMZ with webservers and other hazmat. By design, Mailman core doesn't need to talk to the Internet or to the secure internal network -- Internet functions are delegated to the MTA and the webapps, and local configuration is via shell access which in principle could be console. I'd rather not enable the complexity of a multihomed application unless there's an important use case. (I don't make the final decision, but I am listened to by Those Who Do.) Footnotes: [1] gunicorn is the Python module that manages web services for the REST interface.

4 years, 10 months

[MM3-users] Re: MM3 Docker

by Odhiambo Washington

On Sun, 6 Jan 2019 at 23:39, Mark Sapiro <mark(a)msapiro.net> wrote: > On 1/6/19 8:47 AM, Odhiambo Washington wrote: > > > > If you could include the missing steps that you left out then I could > > possibly be able to follow the steps :-) > > > Please help me understand what steps are missing and I will try to > provide the information. Okay. At the installation stage, you say the following: "I already had some things set up in /opt/mailman including a git subdirectory containing clones of the GitLab mailman, mailmanclient, mailman-hyperkitty, hyperkitty, django-mailman3 and postorius projects. On the third server I have added mailman-suite because I use the settings.py from that project as the basis for mine." Please assume that the reader is a newbie to python3 virtualenv and give the details of the commands they need to execute to (a) clone all the projects needed and (b) create the virtualenv. The next steps are: mkdir /opt/mailman/mm Then you say "I then created a /opt/mailman/mm directory and within that a Python 3.6 virtualenv" What happens here is something that needs clarification, because you are specific about "python3.6". I have googled and realized that one has to be specific about the python version they want to use in their virtualenv as shown here -> https://stackoverflow.com/questions/45293436/how-to-specify-python-version-… exact command to execute to create the /opt/mailman/mm/venv exact command to execute to activate virtualenv From there, I think the newbie can follow and fumble till they come up with a working MM3 site. Come to think of it, your steps kind of look clearer than most that I have encountered. I do understand that there are only a few people working on the MM3 development, which I think is the reason there still isn't a document similar to the ones included with MM2.1x source under doc/ However, if your steps here are polished a little, they can possibly become one such doc. I think MM3 docs would come with three options - virtualenv option, docker option and package option. Installing from source seems like something not easily doable. -- Best regards, Odhiambo WASHINGTON, Nairobi,KE +254 7 3200 0004/+254 7 2274 3223 "Oh, the cruft.", grep ^[^#] :-)

6 years, 4 months

[MM3-users] Re: Dealing with confirmation requests for unsubscribes

by Brian Carpenter

On 11/18/20 6:17 PM, Mark Sapiro wrote: > On 11/18/20 7:41 AM, Brian Carpenter wrote: >> Hello List, >> >> I ran into the following issue for some mailman 3 lists that I am hosting: >> >> https://gitlab.com/mailman/mailman/-/issues/768 >> >> Since there is no way for a list owner to deal with a moderation request >> for an unsubscription task, I assume I need to do something via the >> command line. This is where I need some help with. How do I deal with >> these moderation requests that are unable to be reviewed in an admin gui >> (Postorius/Affinity)? > > 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 test.msapiro.net mailing list > > This > >>>> list(getUtility(IPendings).find(mlist=m, pend_type='unsubscription', > token_owner=TokenOwner.moderator)) > > will return something like > > [('a8df55f557b5718505280d2613937e25a3109252', {'type': 'unsubscription', > 'list_id': 'list.example.com', 'email': 'user(a)example.com', > 'display_name': 'Mark S', 'when': '2020-11-18T22:56:53', 'token_owner': > 'moderator'})] > > What you want is the token, in this case > 'a8df55f557b5718505280d2613937e25a3109252' > > Then do > > ISubscriptionManager(m).confirm('a8df55f557b5718505280d2613937e25a3109252') > > which will return > > (None, <TokenOwner.no_one: 0>, None) > > and finally: > >>>> commit() > > >> I do recommend removing such choices for Postorius for Member policy. I >> will be doing this for Affinity until issue 768 is resolved. > The correct thing to do is fix > <https://gitlab.com/mailman/mailman/-/issues/768>. We almost certainly > will do that rather than remove the moderate and confirm then moderate > unsubscription policies. > > Worked like a charm Mark. Thank you! I forget you guys have a slower process than I when it comes to implementing gui changes. For me, once you have fixed that issue (768), it will be easy for me to reintroduce those two policies for unsubscribing. -- Brian Carpenter Harmonylists.com Emwd.com

4 years, 5 months

[MM3-users] Re: Postorius fails to show list because of a large message being held

by Brian Carpenter

On 7/14/20 1:06 PM, Mark Sapiro wrote: > It's confusing, but after adjusting that setting, you need to restart > Mailman core, not gunicorn. > > If you are running a gunicorn service, that is what is providing WSGI > support for Django (Postorius and/or HyperKitty). You may be using > gunicorn for this or uWSGI or Apache mod_wsgi, but is any case, that is > not the gunicorn we are considering here. > > Regardless of what you use to provide WSGI support for Django, Mailman > core uses gunicorn to support the REST API, and that is the gunicorn > affected by the settings in the gunicorn.cfg pointed to by > > [webservice] > configuration: /opt/mailman/mm/gunicorn.cfg > > If, with the above configuration, you do `ps -fwwA|grep runner=rest` you > will see something like: > > mailman 20582 20561 0 01:21 ? 00:00:16 > /opt/mailman/mm/venv/bin/python /opt/mailman/mm/venv/bin/runner -C > /opt/mailman/mm/deployment/mailman.cfg --runner=rest:0:1 > mailman 20722 20582 0 01:21 ? 00:01:19 > /opt/mailman/mm/venv/bin/python /opt/mailman/mm/venv/bin/runner -C > /opt/mailman/mm/deployment/mailman.cfg --runner=rest:0:1 > mailman 20725 20582 0 01:21 ? 00:01:18 > /opt/mailman/mm/venv/bin/python /opt/mailman/mm/venv/bin/runner -C > /opt/mailman/mm/deployment/mailman.cfg --runner=rest:0:1 > mailman 20726 20582 0 01:21 ? 00:01:18 > /opt/mailman/mm/venv/bin/python /opt/mailman/mm/venv/bin/runner -C > /opt/mailman/mm/deployment/mailman.cfg --runner=rest:0:1 > mailman 20727 20582 0 01:21 ? 00:01:50 > /opt/mailman/mm/venv/bin/python /opt/mailman/mm/venv/bin/runner -C > /opt/mailman/mm/deployment/mailman.cfg --runner=rest:0:1 > > The first of these, pid 20582, is Mailman's actual REST runner. The > other 4 with parent pid 20582 are the 4 gunicorn worker processes forked > from the REST runner. > > It's the REST runner or Mailman core that needs to be restarted to pick > up that change. Thanks Mark. I knew that once but forgot it. -- Please let me know if you need further assistance. Thank you for your business. We appreciate our clients. Brian Carpenter EMWD.com -- EMWD's Knowledgebase: https://clientarea.emwd.com/index.php/knowledgebase EMWD's Community Forums http://discourse.emwd.com/

4 years, 10 months

Search results for query "sapiro"