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

[MM3-users] Re: Issues with cross posted emails after upgrading to mailman 3.3.6

by Simon Coggins

On 7 Nov 2021, at 10:54 am, Mark Sapiro <mark(a)msapiro.net<mailto:mark@msapiro.net>> wrote: I wound up taking a different approach. I check for other references to the message in the message store and only delete the message if there are none. The fix is at https://gitlab.com/mailman/mailman/-/merge_requests/932/diffs<https://gitlab.com/mailman/mailman/-/merge_requests/932/diffs> Oh nice. That seems like a sensible solution. Thanks for tackling so quickly. I’ll do some testing today and roll it out once testing is complete. -- 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> --- [https://www.cqu.edu.au/] Mr Simon Coggins Principal Systems Engineer | Digital Services Directorate CQUniversity Australia, Level 6.14, 160 Ann Street, Brisbane, QLD 4000 P +61 7 3295 1182 | X 51182 | M +61 408 115 861 | E s.coggins(a)cqu.edu.au<mailto:s.coggins@cqu.edu.au> [https://www.cqu.edu.au/social-media] I respectfully acknowledge the Traditional Owners of the land on which we work and learn, and pay respect to the First Nations Peoples and their Elders, past, present and future. This communication may contain privileged or confidential information. If you have received this in error, please return to sender and delete. CRICOS: 00219C | RTO Code 40939 ___________________________________________ Mailman's content filtering has removed the following MIME parts from this message. Content-Type: image/png Name: attachment.png Content-Type: image/png Name: attachment.png Replaced multipart/alternative part with first alternative.

3 years, 10 months

[MM3-users] Re: Exception with processing subscription confirmation email

by Mark Sapiro

On 4/29/21 7:56 AM, Eric Broens wrote: > Hi, > > A new user tried to subscribe to a mailinglist, received the confirmation > mail, and replied to it. > > The subscriber is however not subscribed and remains listed in the "pending > confirmation" list. > > The following exception appears in the error.log. > > Does anyone knows how to resolve this? In the past we didn't experience any > issues and no changes but security updates have been installed. > > Apr 29 16:15:55 2021 (1581) deque: do_confirm_verify > > Traceback (most recent call last): > > File > "/opt/mailman/venv/lib64/python3.6/site-packages/mailman/app/workflow.py", > line 69, in __next__ > > return step() > > File > "/opt/mailman/venv/lib64/python3.6/site-packages/mailman/app/subscriptions.p > y", line 356, in _step_send_confirmation > > raise StopIteration > > StopIteration Tracebacks like the above are normal and probably shouldn't be logged at all. > Apr 29 16:16:28 2021 (1490) Uncaught runner exception: Expecting ':' > delimiter: line 1 column 256 (char 255) > > Apr 29 16:16:28 2021 (1490) Traceback (most recent call last): > > File > "/opt/mailman/venv/lib64/python3.6/site-packages/mailman/core/runner.py", > line 173, in _one_iteration > > self._process_one_file(msg, msgdata) > > File > "/opt/mailman/venv/lib64/python3.6/site-packages/mailman/core/runner.py", > line 266, in _process_one_file > > keepqueued = self._dispose(mlist, msg, msgdata) > > File > "/opt/mailman/venv/lib64/python3.6/site-packages/mailman/runners/command.py" > , line 208, in _dispose > > mlist, msg, msgdata, parts, results) > > File > "/opt/mailman/venv/lib64/python3.6/site-packages/mailman/commands/eml_confir > m.py", line 54, in process > > mlist).confirm(token) > > File > "/opt/mailman/venv/lib64/python3.6/site-packages/mailman/app/subscriptions.p > y", line 578, in confirm > > workflow.restore() > > File > "/opt/mailman/venv/lib64/python3.6/site-packages/mailman/app/workflow.py", > line 146, in restore > > data = json.loads(state.data) > > File "/usr/lib64/python3.6/json/__init__.py", line 354, in loads > > return _default_decoder.decode(s) > > File "/usr/lib64/python3.6/json/decoder.py", line 339, in decode > > obj, end = self.raw_decode(s, idx=_w(s, 0).end()) > > File "/usr/lib64/python3.6/json/decoder.py", line 355, in raw_decode > > obj, end = self.scan_once(s, idx) > > json.decoder.JSONDecodeError: Expecting ':' delimiter: line 1 column 256 > (char 255) > > Apr 29 16:16:28 2021 (1490) SHUNTING: > 1619705788.5856323+57a1a759275c59b732cfa8e2985f76cfcc27dda5 This one is the issue. There was some problem with the user's confirmation reply. View the shunted message with the command ``` mailman qfile path/to/var/queue/shunt/1619705788.5856323+57a1a759275c59b732cfa8e2985f76cfcc27dda5.pck ``` although that probably won't show anything wrong as it appears that the issue is with the saved workflow. You can get the token from the shunted message and then look at the database with something like ``` SELECT data FROM workflowstate WHERE token = '<the token>' ``` but I suspect the issue is because the database is MySQL or MariaDB, your Mailman core is older than 3.3.3 and your database server mode is such that data too long for column results in truncation, and the data in this case is truncated to 255 bytes. In Mailman 3.3.3, this column was changed from VARCHAR(255) to VARCHAR(510) for MySQL. As far as subscribing the user is concerned, you can in Postorius view the subscriptions waiting user confirmation and delete this one and then `mass subscribe` the user. -- Mark Sapiro <mark(a)msapiro.net> The highway is for gamblers, San Francisco Bay Area, California better use your sense - B. Dylan

4 years, 4 months

[MM3-users] Re: Can't deliver mails in queue

by Mark Sapiro

On 5/19/21 10:22 AM, Nathanael Schneider wrote: > > I then created a completely new List which did not exists in mm2.1, > subscribed two addresses and sent myself an EMail. That one worked as > intended. I then deleted the whole broken list and created it cleanly, > added the same two people, sent an email and nothing. This seems strange. If I understand, you are essentially saying the two lists are the same. I.e., you created a completely new List which did not exists in mm2.1, and that one worked. Then you deleted the whole broken list and created it cleanly ... What was different between this cleanly created list and the completely new List? > May 19 18:54:40 2021 (8280) Using agent: <mailman.mta.deliver.Deliver object at 0x7fb49b143780> > May 19 18:54:40 2021 (8280) IndividualDelivery to: nathanael(a)lumenliquid.net > May 19 18:54:40 2021 (8280) Using agent: <mailman.mta.deliver.Deliver object at 0x7fb4974541d0> > May 19 18:54:40 2021 (8280) IndividualDelivery to: nathanael(a)lumenliquid.net The fact that these are the only messages says that the attempt to send that message via smtp raised no exception as exceptions would have been logged, yet you say there's nothing in the maillog so there was no connect to Postfix. What are your settings for smtp_host: and smtp_port: in the [mta] section of mailman.cfg? ... > I have no clue what to do with this. I then turned the debug module > loglevel to debug. Also nothing useful. Just an endless list of > > [...] > May 19 18:17:29 2021 (7209) [outgoing] <function deliver at > 0x7f2faf384c80>: <B9531076-2480-4925-9A2B-57802B53D5ED(a)gmx.de> > May 19 18:17:29 2021 (7203) [ArchiveRunner] starting oneloop > May 19 18:17:29 2021 (7203) [ArchiveRunner] ending oneloop: 0 > May 19 18:17:29 2021 (7209) [OutgoingRunner] finishing filebase: > 1621441049.4089153+6dff56673dc64b890dd352941267782c264586dd > May 19 18:17:29 2021 (7209) [OutgoingRunner] doing periodic > May 19 18:17:29 2021 (7209) [OutgoingRunner] committing transaction > May 19 18:17:29 2021 (7209) [OutgoingRunner] checking short circuit > May 19 18:17:29 2021 (7209) [OutgoingRunner] ending oneloop: 1 > May 19 18:17:29 2021 (7209) [OutgoingRunner] starting oneloop > May 19 18:17:29 2021 (7209) [OutgoingRunner] processing filebase: > 1621441049.4628382+6a0437ea387a2508ad947c0a51712075cbdb6d2e > May 19 18:17:29 2021 (7209) [OutgoingRunner] processing onefile > May 19 18:17:29 2021 (7209) [outgoing] <function deliver at > 0x7f2faf384c80>: <B9531076-2480-4925-9A2B-57802B53D5ED(a)gmx.de> > [...] > > Which also tells me nothing I can understand. It says the message in queue entry 1621441049.4089153+6dff56673dc64b890dd352941267782c264586dd is handled but gets requeued as 1621441049.4628382+6a0437ea387a2508ad947c0a51712075cbdb6d2e which presumably is handled and requeued again ... > I have no clue what's > going wrong. (I've turned on debugging both on the original member list > and the reduced member list. Both hang on the first delivery they do). > If I restart mailman, the message gets correctly shunted as it is > interrupted mid-delivery. My maillogs don't register any activity beside > the listpost. Any ideas what I need to do to figure out what's not > working here or where the culprit could be? Not sure if it is related to > the mailinglist being in mailman2.1 before. I have no real understanding of why this isn't working. I don't think it's likely that it has to do with the mailing list being imported from MM 2.1, but I suppose it could be. How did you create and import the list? When you say you deleted the whole broken list and created it cleanly, what did you actually do? -- 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: Huge performance issue: Mailman doesn't (seem to) receive any mails.

by Abhilash Raj

On Wed, Sep 18, 2019, at 8:14 AM, Mark Sapiro wrote: > On 9/18/19 3:32 AM, Henrik Rasmussen wrote: > > I am running maxking/mailman-*:0.2 (GNU Mailman 3.2.0 (La Villa Strangiato)). > > > > It looks like Mailman is not receiving (enough) mails, but are keps in the Postfix queue and I can't figure out why. > > > > I get a lot of "mail for [172.19.199.2]:8024 is using up 7841 of 7841 active queue entries" in the postfix container log (more postfix log at the buttom. > > > I know nothing about Docker containers and how they communicate with > each other, but Postfix is trying to deliver mail via lmtp to > [172.19.199.2]:8024. Mailman's lmtp runner should be running and > listening on port 8024. Either that is not the case or that port is not > exposed to Postfix on IP 172.19.199.2. Right, that is what I was wondering, you verify that by using telnet on the specified IP and Port (172.19.199.2:8024). `docker-compose ps` lists all the running containers, do you see all the containers running? You mentioned that Mailman is not receiving enough emails, do you get *any* emails from Mailman? I am trying to see if this is a perf problem or if Mailman's LMTP isn't reachable at all. > > -- > 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/ > -- thanks, Abhilash Raj (maxking)

5 years, 11 months

[MM3-users] Re: Weekend releases

by Abhilash Raj

On Tue, Dec 10, 2019, at 8:27 AM, Mark Sapiro wrote: > On 12/10/19 2:58 AM, Paul Arenson wrote: > > Thank you. The setup I am using now has Hyperkitty 1.3.0 and I just wanted to confirm. Somewhere I thought I read there is a facility in the Hyperkitty archive interface to format text. Probably I misunderstood, but if there is such a facility, I am not seeing it. Maybe I am looking for something like Tiny Ice and thus can't find it. > > > Markdown rendering of message bodies in Hyperkitty is > <https://gitlab.com/mailman/hyperkitty/merge_requests/160>. This is > installed on <https://lists.mailman3.org/mailman3/> and > <https://mail.python.org/mailman3> but is not yet released. > To add more, if you look at the merge request, there are some pieces missing before it can be merged. Especially, a mechanism to opt-out on a per-list basis from this. While markdown is pretty nice to look at when you are dealing with certain mailing lists which communicates in plain text, it can be horrible to look at if the users aren't aware about markdown and/or the special markdown syntax. In practice, there is only so much we can do to render a random email as HTML using markdown syntax. Maybe I can get to it this holiday season and it can go out for interested folks in the next Hyperkitty release :) > -- > 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/ > -- thanks, Abhilash Raj (maxking)

5 years, 9 months

[MM3-users] Re: hyperkitty.views.mailman The MAILMAN_ARCHIVER_KEY was not sent as the Authorization HTTP header

by Odhiambo Washington

On Thu, Dec 29, 2022 at 2:54 AM Mark Sapiro <mark(a)msapiro.net> wrote: > On 12/28/22 12:22, Odhiambo Washington wrote: > > On Wed, Dec 28, 2022 at 8:35 PM Mark Sapiro <mark(a)msapiro.net> wrote: > > > >> On 12/27/22 22:00, Odhiambo Washington wrote: > >>> I worke up to 959 such entries in my mailmanweb.log: > >>> > >>> ERROR 2022-12-27 22:49:57,732 82073 hyperkitty.views.mailman The > >>> MAILMAN_ARCHIVER_KEY was not sent as the Authorization HTTP header. > >> ... > >>> > >>> What might have been the cause of this? > >>> > >> > >> Upgrading HyperKitty without upgrading mailman-hyperkitty. HyperKitty>= > >> 1.3.5 requires mailman-hyperkitty>=1.2.0. > > > Actually, HyperKitty>=1.3.5 with mailman-hyperkitty<1.2.0 produces a > different message so that isn't it. > > There is an issue with Apache. If you search the archives of this list > for the log message you'd find it, but see the last two posts in the > thread at > > https://lists.mailman3.org/archives/list/mailman-users@mailman3.org/thread/… > > But why these messages all of a sudden? Did you just change something? > I found a mismatch! MAILMAN_ARCHIVER_KEY != api_key A single quote character had sneaked in while copying the key over to the next file. I will watch what happens when the archiver is run next and whether I really need the ' WSGIPassAuthorization On'. Thank you very much as always. -- Best regards, Odhiambo WASHINGTON, Nairobi,KE +254 7 3200 0004/+254 7 2274 3223 "Oh, the cruft.", egrep -v '^$|^.*#' ¯\_(ツ)_/¯ :-)

2 years, 8 months

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

by Abhilash Raj

On Thu, Oct 26, 2017, at 06:39 PM, Mark Sapiro wrote: > On 10/26/2017 06:16 PM, Fabian A. Santiago wrote: > > > > > But in my testing, I replied to a subscription confirmation message and received back an undeliverable looping email error message from postfix. Any clues there you can offer? I can post to the list from any email added via the admin console. The test subscriber address was local to my server. From an outside address, same error. > > > This usually means that postfic is trying to deliver to an address and > the message already has a Delivered-To: header with that address. > > What are the headers of the "looping" message in the report? What are > the Postfix log messages related to that message? > > > > Once I registered the new email domain, I reverted my postfix config back to the default suggested by maxking's docker instructions. > > > > https://github.com/maxking/docker-mailman > > > I have essentially no knowledge of the docker container images, so I > can't be much help with issues specific to them. The Postfix integration in container images is basically just using regex instead of hash maps and everything else is same. I do remember atleast one other person facing a similar issue where Postfix wouldn't accept listname+token@domain addresses with our regex. I am thinking this is the same issue. > > -- > 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/ -- Abhilash Raj maxking(a)asynchronous.in

7 years, 10 months

[MM3-users] Re: Deleting default "example.com" domain breaks everything

by Abhilash Raj

On Fri, Jul 16, 2021, at 12:12 PM, Mark Sapiro wrote: > On 7/16/21 11:31 AM, mcarter(a)corneredrats.com wrote: > > Hello. I'm new with v3 of mailman. > > Installed via aptitude on deb10. > > After I logged in as admin, I created my actual domain, as "example.com" was there by default. > > I then deleted example.com, and everything broke. > > The only site I had was still using example.com. > > How do I either a) restore example.com in config or CLI (as web UI is completely broken now), or b) move my one and only "Site 1" to the domain I created? > > > Try setting `SITE = 0` in your Django settings file. If that doesn't > work, try successively 1, 2, etc. One of these should work. Usually, example.com is always 1 and then it increases sequentially. So, if this is the first one you created, I'd try using 2. > > Also going back to your prior thread, you had > > > root@mail:/usr/share/mailman3-web# python manage.py createsuperuser > > Aside from the python/python3 issue, you should run any Mailman and > Django management commands as the Mailman user (probably `list` in your > case), not as root. See https://gitlab.com/mailman/mailman/-/issues/920 > and https://gitlab.com/mailman/mailman/-/issues/776. > > > -- > 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/ > -- thanks, Abhilash Raj (maxking)

4 years, 1 month

[MM3-users] Re: redirecting -bounces replies

by Mark Sapiro

On 6/26/25 11:37, Hirayama, Pat wrote: > > When I look at the domains in mailman-core, I see: > >>>> show_domains() > <Domain fhcrc.org> > <Domain fredhutch.org> > <Domain lists.fhcrc.org, , alias: lists.fredhutch.org> > <Domain lists.hanc.info, , alias: > > - owner: cit-sys-engineering(a)fredhutch.org This is part of the problem. The alias domain for a list should not be a real domain. Apparently, someone set this up so that mail to lists in the lists.fhcrc.org domain would go to the corresponding list in the lists.fredhutch.org domain. I think that may actually work, but you need more. In order to add recipients to the patest-bounces addresses, the recipient domains need to have an alias domain. In the cases below the domains lists.fredhutch.org and lists.hanc.info. E.g set an alias domain for lists.fredhutch.org to x.lists.fredhutch.org and for lists.hanc.info to x.lists.hanc.info. Then postfix_vmap will contain entries like > pattest(a)lists.fhcrc.org pattest(a)lists.fredhutch.org > pattest-bounces(a)lists.fhcrc.org pattest-bounces(a)lists.fredhutch.org > pattest-confirm(a)lists.fhcrc.org pattest-confirm(a)lists.fredhutch.org > pattest-join(a)lists.fhcrc.org pattest-join(a)lists.fredhutch.org > pattest-leave(a)lists.fhcrc.org pattest-leave(a)lists.fredhutch.org > pattest-owner(a)lists.fhcrc.org pattest-owner(a)lists.fredhutch.org > pattest-request(a)lists.fhcrc.org pattest-request(a)lists.fredhutch.org > pattest-subscribe(a)lists.fhcrc.org pattest-subscribe(a)lists.fredhutch.org > pattest-unsubscribe(a)lists.fhcrc.org pattest-unsubscribe@lists.fredhutch.orgpattest@lists.fredhutch.org > > pattest(a)lists.fredhutch.org pattest(a)x.lists.fredhutch.org > pattest-bounces(a)lists.fredhutch.org pattest-bounces(a)x.lists.fredhutch.org > pattest-confirm(a)lists.fredhutch.org pattest-confirm(a)x.lists.fredhutch.org > pattest-join(a)lists.fredhutch.org pattest-join(a)x.lists.fredhutch.org > pattest-leave(a)lists.fredhutch.org pattest-leave(a)x.lists.fredhutch.org > pattest-owner(a)lists.fredhutch.org pattest-owner(a)x.lists.fredhutch.org > pattest-request(a)lists.fredhutch.org pattest-request(a)x.lists.fredhutch.org > pattest-subscribe(a)lists.fredhutch.org pattest-subscribe(a)x.lists.fredhutch.org > pattest-unsubscribe(a)lists.fredhutch.org pattest-unsubscribe@x.lists.fredhutch.orgpattest@lists.fredhutch.org > > phtest(a)lists.hanc.info pattest(a)x.lists.hanc.info > phtest-bounces(a)lists.hanc.info pattest-bounces(a)x.lists.hanc.info > phtest-confirm(a)lists.hanc.info pattest-confirm(a)x.lists.hanc.info > phtest-join(a)lists.hanc.info pattest-join(a)x.lists.hanc.info > phtest-leave(a)lists.hanc.info pattest-leave(a)x.lists.hanc.info > phtest-owner(a)lists.hanc.info pattest-owner(a)x.lists.hanc.info > phtest-request(a)lists.hanc.info pattest-request(a)x.lists.hanc.info > phtest-subscribe(a)lists.hanc.info pattest-subscribe(a)x.lists.hanc.info > phtest-unsubscribe(a)lists.hanc.info pattest-unsubscribe@x.lists.hanc.infopattest@lists.hanc.info And I think postfix_lmtp will contain entries like > pattest(a)x.lists.fredhutch.org lmtp:[mailman-core]:24 > pattest-bounces(a)x.lists.fredhutch.org lmtp:[mailman-core]:24 > pattest-confirm(a)x.lists.fredhutch.org lmtp:[mailman-core]:24 > pattest-join(a)x.lists.fredhutch.org lmtp:[mailman-core]:24 > pattest-leave(a)x.lists.fredhutch.org lmtp:[mailman-core]:24 > pattest-owner(a)x.lists.fredhutch.org lmtp:[mailman-core]:24 > pattest-request(a)x.lists.fredhutch.org lmtp:[mailman-core]:24 > pattest-subscribe(a)x.lists.fredhutch.org lmtp:[mailman-core]:24 > pattest-unsubscribe(a)x.lists.fredhutch.org lmtp:[mailman-core]:24 > > phtest(a)x.lists.hanc.info lmtp:[mailman-core]:24 > phtest-bounces(a)x.lists.hanc.info lmtp:[mailman-core]:24 > phtest-confirm(a)x.lists.hanc.info lmtp:[mailman-core]:24 > phtest-join(a)x.lists.hanc.info lmtp:[mailman-core]:24 > phtest-leave(a)x.lists.hanc.info lmtp:[mailman-core]:24 > phtest-owner(a)x.lists.hanc.info lmtp:[mailman-core]:24 > phtest-request(a)x.lists.hanc.info lmtp:[mailman-core]:24 > phtest-subscribe(a)x.lists.hanc.info lmtp:[mailman-core]:24 > phtest-unsubscribe(a)x.lists.hanc.info lmtp:[mailman-core]:24 In any case you will then be able to add the additional recipient to the phtest-bounces(a)lists.hanc.info entry in postfix_vmap. -- Mark Sapiro <mark(a)msapiro.net> The highway is for gamblers, San Francisco Bay Area, California better use your sense - B. Dylan

2 months, 2 weeks

[MM3-users] Re: Moderation action "None" is misleading

by Markus Grandpré

Dear Mr Sapiro, dear Mr Turnbull, thank you very much for your reply. For clarification I like to change: > What versions of Mailman and Postorius are you using? * mailman3, v3.3.8-2~deb12u2 * mailman3-web, v0+20200530-2.1 * python3-django-mailman3, v1.3.9-1 * python3-django-postorius, v1.3.8-3 * python3-mailman-hyperkitty, v1.2.1-1 * python3-mailmanclient, v3.3.5-1 with Debian GNU/Linux 12 (bookworm). So the newest changes: > This is https://gitlab.com/mailman/postorius/-/issues/577 fixed in > Postorius 1.3.9 by https://gitlab.com/mailman/postorius/-/ > merge_requests/811 are not yet available on our system. Hopefully we won't have to wait too long with Debian as there is already a lot of confusion among some of our many list administrators as we only started using Mailman3 for production a few days ago. Best Markus Am 04.02.25 um 19:25 schrieb Mark Sapiro: > On 2/4/25 02:51, Markus Grandpré wrote: >> Dear List, >> >> I find the use of the term 'None' (or 'Kein' in the German >> translation; see attachments) in the 'Moderation action' column of the >> member list misleading, as the term suggests that no moderation action >> is applied to the respective member. >> >> However, this is not necessarily the case. If you check a member’s >> "Administration options / Moderation" setting, a moderation action, >> such as "Moderation" or "List default", may be in effect. > > This is https://gitlab.com/mailman/postorius/-/issues/577 fixed in > Postorius 1.3.9 by https://gitlab.com/mailman/postorius/-/ > merge_requests/811 > > See the UI changes at https://docs.mailman3.org/projects/postorius/en/ > latest/news.html#news-1-3-9 > -- Markus Ludwig Grandpré Universität Konstanz Kommunikations-, Informations-, Medienzentrum (KIM) Abteilung IT-Dienste Forschung und Lehre, B803, Tel: ++49 7531 88 4342

7 months, 1 week

Search results for query "sapiro"