Search results for "Postorius" - Mailman-users

hosted signup is producing unexpected results

by tokyoprogressive＠mac.com

In my test of the two forms of signup, I am getting these unexpected results. Is it my settings or is something weird within the program itself? 1) https://list.tokyoprogressive.org/postorius/lists/discuss.list.tokyoprogres… 2) Choose "You can also subscribe without creating an account. If you wish to do so, please use the form below" 3) Then I have to approve it. They get "Welcome to the "Discuss" mailing list! To post to this list, send your email to: discuss(a)list.tokyoprogressive.org 4) But I have to approve it.I assume this is because they do not yet have a real account. And they should be listed as a NON MEMBER? 5) But even when they sign up here: https://list.tokyoprogressive.org/accounts/signup/?next=%2Fpostorius%2Flist… they get an email from my provider (NOT MY LIST????) as follows: "Hello from mailman3.emwd.com! You're receiving this e-mail because user iCloud has given yours as an e-mail address to connect their account. To confirm this is correct, go to https://list.tokyoprogressive.org/accounts/confirm-email/MTE3:1iA44k:E7w7xh… Thank you from mailman3.emwd.com! mailman3.emwd.com" 6) And this is where it gets weird. If they send from their email program and get the welcome (Welcome to the "Discuss" mailing list! To post to this list, send your email to: discuss(a)list.tokyoprogressive.org You can unsubscribe or make adjustments to your options via email by sending a message to....... I then get a notice: "Your mail to 'discuss(a)list.tokyoprogressive.org' with the subject test notice Is being held until the list moderator can review it for approval. The message is being held because: The message is not from a list member" 7) While if they send FROM THE interface it goes through. 8) What I am confused about. Signing up for an account should make them a member, right? Subscribing should make them a non member, no? But here it seems that both make them a non member. And worse, someone with an account sending from the Interface has their message get through while the same person sending from an email program has me get a notice that a non member is trying to post. Before I can move my actual members over from another mailing list provider, I want to make sure what works and what doesn't. Thanks. paul!!!

7 years, 1 month

Re: [MM3-users]Re: [Mailman-Users] Mailman3 administration

by Barry Warsaw

On Jun 20, 2016, at 10:47 PM, Bill wrote: >And it leads me to think about timelines. > >I'm aware that the freeze for Debian 9 (Stretch) is scheduled for the end of >this year, and that we can expect it to be released sometime in >mid-2017. (Don't quote me on that though ;) And I'm not sure about Centos, I >didn't see a Mailman 3.0 package there or in Fedora. We have a Debian maintainer who did some work on packaging, but got stuck on a few issues. I think one of the biggest problems is also something that HK/Postorius is grappling with right now - the eminent demise of persona.org. Work is being done to switch over to django-social-auth, and that's a blocker for a full 3.1 suite release. For the core, the last big missing thing is the unsubscription workflow (see GL#213). I'll be looking at that, trying to adapt or finish Abhilash's work there. >But is there any chance that a Mailman 3.0 or 3.1 package is going to make it >into current release cycles? I'd like for it to happen; we'll have to see. >But we're in the evaluation/design phase of this project and from the >providers point of view it would be helpful to know if they should wait a few >months for Mailman 3.0/3.1 or just go ahead now with 2.1.x and upgrade to 3.1 >at some point down the road. While their list admins are experienced, they >are new to Mailman and the fewer burps the better. Although they may very >well take a run at 3.0 now and see how things work out. We just need some >sort of timeline to consider. I still think we can get a 3.1 release out by year's end, if not sooner. As I say, we have just a couple of blockers left, though they may or may not be small. I'd say, don't try to deploy 3.0, but either go with the git heads, or wait for hopefully some beta releases of 3.1 coming soon. I am seriously considering not releasing a 3.0.4 and just EOL'ing 3.0.x once 3.1 is released. It should be a smooth upgrade if you already have 3.0 deployed. Cheers, -Barry

10 years, 2 months

Re: UnicodeEncodeError: 'ascii' codec can't encode character

by Marvin Gülker

Hi, Am 10. Dezember 2019 um 17:09 Uhr +0900 schrieb Stephen J. Turnbull: > You're the "it's 2019, let's use SMTP UTF8 everywhere" guy, right? No, I'm not that guy. I've not said anything like that, nor have I knowingly configured Postfix to use that. I've looked up how to do it now that you mention it, and found the smtputf8_enable parameter[1]. I have not used it, but it turns out that it is enabled by default. I can turn it off and see if that makes any difference in the future. Testing with telnet, Postfix indeed announced "250 SMTPUTF8" on EHLO. > If you're right about the umlaut being the trigger, the first thing I'd look at is a feature-negotiation problem in the MTA delivering to Mailman. I'm pretty sure our LMTP does not offer the SMTP UTF8 feature. In that case the problem should go away with disabling SMTPUTF8, I suppose? > I would guess this is in the shunt queue. If there's only one file there, you can just delete it. There was a whole bunch of files in that directory. I've taken a look several of them, and as they were all spam, I've taken the liberty to delete them all (this list is so low volume that I know all the senders personally anyway). However, even after restarting mailman, the 500 error persists when visiting the held messages page in postorius. I've also looked into all the other queue directories, they were all empty. > Assuming you're right about your name being the trigger, U+FFFD REPLACEMENT CHARACTER is not in your name. I confess that I haven't visited the held messages page for a very long time (because I didn't have a reason to; I received no notifications of held messages). Only after I received the notification that my errorneous message was being held, I visited it, and I was faced with the 500 error. If Mailman failed to notify me of held messages previously, they might have been in hold status already and one of them might be the cause. Marvin [1]: http://www.postfix.org/postconf.5.html#smtputf8_enable PS: Sorry for the missing link [1] from the last mail. Here it is: https://gitlab.com/mailman/hyperkitty/issues/201 -- Blog: https://mg.guelker.eu

6 years, 10 months

Re: About to Install MM3 -- Seeking clarification

by Mark Sapiro

On 10/12/22 01:24, Onyeibo Oku wrote: > > Good Morning Everyone, > > I installed and managed mailman 2 for about two years. I am now > ready to try Mailman 3. The documentation for version 2 was lucid and > this forum was quite helpful in the past. > > Now I'd like to proceed with installating MM3 but I doubt my > understanding of the docs. It seems to assume that users will know what > to do. > > Okay, don't laugh! I just want to be sure what I am doing. Does the > following sequence resemble the proper steps? As Eggert says, we aren't laughing ... > 1. Download the source from a git repo (I understood that one) > 2. Create a virtual environment (venv perhaps ... not stated explicitly) > 3. activate the virtual environment > 4. from the git project root, run: ./mailman start Step 4 is premature. More below. > I know, its stupid. I had to ask. Not stupid ... > It would really build my confidence > someone would confirm the above steps or counter then with something > very explicit. What about process ownership? Do I need to have a unix > mailman user? What else do I need to get mailman up and running > before proceeding to configuration. Ahaa! I perused the config docs a > bit. Where can I find the .cfg file? As Eggert suggests, see https://docs.mailman3.org/en/latest/install/virtualenv.html and follow that. You don't need to download the source from GitLab. Following that doc will get the latest releases from PyPI via pip. Those are still somewhat out of date - we really should make new releases - so if you want the latest from GitLab, there are a couple of ways to do it. Perhaps the easiest is to just run the various `pip install` commands as documented and then upgrade Mailman core in your venv with ``` pip install --upgrade git+https://gitlab.com/mailman/mailman@master ``` and update the various mailman web packages with ``` pip install --upgrade git+https://gitlab.com/mailman/xxx@master ``` where xxx is mailman-web, mailman-hyperkitty, django-mailman3, postorius, hyperkitty. I.e., run it 5 times, once for each value of xxx. -- Mark Sapiro <mark(a)msapiro.net> The highway is for gamblers, San Francisco Bay Area, California better use your sense - B. Dylan

4 years

Re: Trying to save a new style

by pcjkollmorgen＠hotmail.com

Thanks. I was able to create a python module and install it which sets up 2 new styles, and I have one of those now set as the default list style in Postorius. I needed to include a few more interfaces but otherwise kept to the example plugin file (just made another file for the other list). ``` from public import public from mailman.interfaces.styles import IStyle from mailman.styles.default import LegacyDefaultStyle from zope.interface import implementer from mailman.interfaces.action import Action, FilterAction from mailman.interfaces.archiver import ArchivePolicy from mailman.interfaces.autorespond import ResponseAction from mailman.interfaces.bounce import UnrecognizedBounceDisposition from mailman.interfaces.digests import DigestFrequency from mailman.interfaces.mailinglist import ( DMARCMitigateAction, Personalization, ReplyToMunging, SubscriptionPolicy, ArchiveRenderingMode) from mailman.interfaces.nntp import NewsgroupModeration from mailman.model.roster import RosterVisibility # Documentation on List styles # https://docs.mailman3.org/projects/mailman/en/latest/src/mailman/styles/doc… # also some was worked out from src/mailman/styles/base.py @public @implementer(IStyle) class MyPrivateStyle(LegacyDefaultStyle): # Provide a unique name to this style so it doesn't clash with the ones # defined by default. name = 'my-announce-style' # Provide a usable description that will be shown to the users in Web # Interface. description = 'My Announce mailing list style.' def apply(self, mailing_list): """See `IStyle`.""" # Set settings from super class. super().apply(mailing_list) # Make modifications on top. mailing_list.admin_immed_notify = True mailing_list.admin_notify_mchanges = True mailing_list.advertised = True mailing_list.allow_list_posts = False mailing_list.anonymous_list = False mailing_list.archive_policy = ArchivePolicy.private mailing_list.archive_rendering_mode = ArchiveRenderingMode.markdown mailing_list.collapse_alternatives = False mailing_list.convert_html_to_plaintext = False mailing_list.default_member_action = Action.defer mailing_list.default_nonmember_action = Action.hold mailing_list.digest_send_periodic = False mailing_list.digests_enabled = False mailing_list.include_rfc2369_headers = True mailing_list.max_message_size = "40000" mailing_list.max_num_recipients = "30" mailing_list.member_roster_visibility = RosterVisibility.moderators mailing_list.send_goodbye_message = True mailing_list.send_welcome_message = True mailing_list.subscription_policy = SubscriptionPolicy.moderate mailing_list.unsubscription_policy = SubscriptionPolicy.moderate ``` Having a docker-mailman setup means needing to install this any time that the mailmail-core container is rebuilt (not all that often), however the source code for the module can live in a host volume such as /opt/mailman/core/var/plugins , it is simply an execution of the install which is need after a container is rebuilt. eg: docker exec mailman-core pip install -E /opt/mailman/var/plugins/yourplugin I currently need to pip install django-allauth[saml] and apk add openldap-dev (this one should be in a new version of the container) on any new mailman-core container anyway so I'm not too worried.

2 years, 4 months

Re: Can't add emails to accept_these_nonmembers

by Ibiam Chihurumnaya

Mark Sapiro wrote: > On 2/26/26 13:20, Ibiam Chihurumnaya via Mailman-users wrote: > > I'm doing it in mailman shell, list_name is a List object, and it seems to have a settings > > attribute as list_name.settings returns > > {'acceptable_aliases': [], ...} > > I would really like to know what Mailman version this is, and how it was > installed? In my case with Mailman core from the head of the GitLab branch: > $ mailman shell -l list.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.example.com mailing list > >>> m.settings > Traceback (most recent call last): > File "<console>", line 1, in <module> > AttributeError: 'MailingList' object has no attribute 'settings' > >>> m.settings['accept_these_nonmembers'] > Traceback (most recent call last): > File "<console>", line 1, in <module> > AttributeError: 'MailingList' object has no attribute 'settings' > >>> Currently running Mailman 3.3.10 and I followed the instructions from https://docs.mailman3.org/en/latest/install/virtualenv.html# to install. This is the output from mine, I get the same output as you do when I try exactly what you do; mailman shell -l systems-logs(a)lists.sugarlabs.org 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 systems-logs(a)lists.sugarlabs.org mailing list >>> m.settings Traceback (most recent call last): File "<console>", line 1, in <module> AttributeError: 'MailingList' object has no attribute 'settings' I get something else when I do it differently - how I've been doing it so far -. mailman shell 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. >>> from mailmanclient import Client >>> from mailmanclient import Client >>> client = Client('http://localhost:8001/3.1', '**', '**') >>> sg = client.domains[0] >>> sy = sg.get_lists()[-1] >>> sy <List 'systems-logs(a)lists.sugarlabs.org'> >>> sy.settings {'acceptable_aliases': [], 'accept_these_nonmembers': [], 'admin_immed_notify': True, 'admin_notify_mchanges': False, 'administrivia': True, 'advertised': False, 'allow_list_posts': True, 'anonymous_list': False, 'archive_policy': 'public', 'archive_rendering_mode': 'text', 'autorespond_owner': 'none', 'autorespond_postings': 'none', 'autorespond_requests': 'none', 'autoresponse_grace_period': '90d', 'autoresponse_owner_text': '', 'autoresponse_postings_text': '', 'autoresponse_request_text': '', 'bounces_address': 'systems-logs-bounces(a)lists.sugarlabs.org', 'bounce_info_stale_after': '7d', 'bounce_notify_owner_on_bounce_increment': False, 'bounce_notify_owner_on_disable': True, 'bounce_notify_owner_on_removal': True, 'bounce_score_threshold': 5, 'bounce_you_are_disabled_warnings': 3, 'bounce_you_are_disabled_warnings_interval': '7d', 'collapse_alternatives': True, 'convert_html_to_plaintext': False, 'created_at': '2026-02-04T21:53:10.928951', 'default_member_action': 'defer', 'default_nonmember_action': 'accept', 'description': '', 'digest_last_sent_at': '2026-02-27T11:24:11.916379', 'digest_send_periodic': True, 'digest_size_threshold': 30.0, 'digest_volume_frequency': 'monthly', 'digests_enabled': True, 'display_name': 'Systems-logs', 'discard_these_nonmembers': [], 'dmarc_mitigate_action': 'no_mitigation', 'dmarc_mitigate_unconditionally': False, 'dmarc_addresses': [], 'dmarc_moderation_notice': '', 'dmarc_wrapped_message_text': '', 'emergency': False, 'filter_action': 'discard', 'filter_content': False, 'filter_extensions': [], 'filter_types': [], 'first_strip_reply_to': False, 'forward_unrecognized_bounces_to': 'administrators', 'fqdn_listname': 'systems-logs(a)lists.sugarlabs.org', 'gateway_to_mail': False, 'gateway_to_news': False, 'hold_these_nonmembers': [], 'include_rfc2369_headers': True, 'info': '', 'join_address': 'systems-logs-join(a)lists.sugarlabs.org', 'last_post_at': '2026-02-27T11:32:51.317220', 'leave_address': 'systems-logs-leave(a)lists.sugarlabs.org', 'linked_newsgroup': '', 'list_name': 'systems-logs', 'mail_host': 'lists.sugarlabs.org', 'max_message_size': 40, 'max_num_recipients': 10, 'max_days_to_hold': 0, 'member_roster_visibility': 'moderators', 'moderator_password': None, 'newsgroup_moderation': 'none', 'next_digest_number': 60, 'nntp_prefix_subject_too': True, 'no_reply_address': 'noreply(a)lists.sugarlabs.org', 'owner_address': 'systems-logs-owner(a)lists.sugarlabs.org', 'pass_types': [], 'pass_extensions': [], 'personalize': 'none', 'post_id': 316, 'posting_address': 'systems-logs(a)lists.sugarlabs.org', 'posting_pipeline': 'default-posting-pipeline', 'preferred_language': 'en', 'process_bounces': True, 'reject_these_nonmembers': [], 'reply_goes_to_list': 'no_munging', 'reply_to_address': '', 'request_address': 'systems-logs-request(a)lists.sugarlabs.org', 'require_explicit_destination': True, 'respond_to_post_requests': True, 'send_goodbye_message': True, 'send_welcome_message': True, 'subject_prefix': '[Systems-logs] ', 'subscription_policy': 'confirm', 'unsubscription_policy': 'confirm', 'usenet_watermark': None, 'volume': 1} > > Presumably in your case, you could do > list_name.settings['accept_these_nonmembers'].append('user(a)example.com') > > or > > list_name.settings['accept_these_nonmembers'].extend(['user1(a)example.com', > 'user2(a)example.com', 'user3(a)example.com']) > > but as I've said previously, accept_these_nonmembers is not the > preferred way to do this. Something like > $ mailman addmembers --delivery disabled FILE LIST > Yes, I see now that it's not the preferred way to do it. It's difficult to know that when looking at the documentation. > where FILE contains the addresses to add, one per line and LIST is the > list name would add the addresses as members with delivery disabled. To > add them as nonmembers with moderation_action Defer: > $ mailman shell -l list.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.example.com mailing list > >>> from mailman.app.membership import add_member > >>> addresses = ('user1(a)example.com', 'user2(a)example.com', > ... 'user3(a)example.com') > >>> for addr in addresses: > ... rr = RequestRecord(addr) > ... nm = add_member(m, rr, role=MemberRole.nonmember) > ... nm.moderation_action = Action.defer > ... > >>>commit() Thank you! > > Of course, all of this can be done, perhaps more easily, using the > Postorius web UI. Yes, but like I've mentioned in another thread, I don't have access to the web UI because I can't get a confirmation link. > -- > Mark Sapiro <mark(a)msapiro.net> The highway is for gamblers, > San Francisco Bay Area, California better use your sense - B. Dylan

7 months, 3 weeks

Re: Try to Implement Template for The message sent to subscribers when a subscription confirmation is required

by Gerald Vogt

On 17.02.26 09:29, Stephen J. Turnbull wrote: > Gerald Vogt writes: > > > Why would you double book port 80? That's really a bad idea and > > causes issues like the one you see... > > When I read that I assumed that nginx would resolve in favor of the > narrower interface:port declaration. But IPv6 is still a different interface and ::1 would always go into that "EXTERNAL" server as that's also the default_server. You cannot connect with IPv6 into the other "INTERNAL" server. And I think beyond that there is no "narrow" measure for interface:ports declarations. If two server blocks use the same interface and port, the server will use the server_name to determine which block to use (named-based virtual-host) and if none matches either the declared "default_server" or if no default server has been declared it's using the first matching block. > If double-booking is happening, nginx should be issuing an error, or > (nginx being pretty picky in my experience) even refusing to start. Maybe I have used the wrong term "double-booking", but most often, you have full overlap on your servers (i.e. server name virtual hosts, listening to all your interfaces on ports 80 and/or 443). > Anyway, OP should look for messages about problems binding to ports in > the nginx and uwsgi logs. > > > Your "INTERNAL" server binds to 127.0.0.1 port 80, only. > > That's not quite true. Normally the WSGI service will bind to another > port for Postorius/HyperKitty, typically 8000. I am only referring to the nginx config posted. That is listening to 127.0.0.1:80 specifically which means it is not listening to [::1]:80. The "INTERNAL" server overlaps on 127.0.0.1:80 with the other block. i.e. on 127.0.0.1:80 it will use the server_name to determine which block to use and only "localhost" will go into the "INTERNAL" block. So only connections to 127.0.0.1:80 or localhost:80 using IPv4 will go into the "INTERNAL" block. Any other network connection to port 80 will always go into the other block including [::1]:80 or localhost:80 using IPv6. As I have suggested, it would be better to use a different port number for the "INTERNAL" block. -Gerald

8 months

Re: LookupError: unknown encoding: _iso-2022-jp$esc

by Mark Sapiro

On 09/07/2018 08:30 AM, Thor Atle Rustad wrote: > This happens when I open a page of Held Messages containing an offending > message. I get Server Error (500) in Postorius. Here is the mailman.log: > > > Sep 07 15:25:39 2018 (32) REST request handler error: > Traceback (most recent call last): > File "/usr/local/lib/python3.6/wsgiref/handlers.py", line 137, in run > self.result = application(self.environ, self.start_response) > File > "/usr/local/lib/python3.6/site-packages/mailman/database/transaction.py", > line 50, in wrapper > rtn = function(*args, **kws) > File "/usr/local/lib/python3.6/site-packages/mailman/rest/wsgiapp.py", > line 214, in __call__ > return super().__call__(environ, start_response) > File "/usr/local/lib/python3.6/site-packages/falcon/api.py", line 244, in > __call__ > responder(req, resp, **params) > File > "/usr/local/lib/python3.6/site-packages/mailman/rest/post_moderation.py", > line 160, in on_get > resource = self._make_collection(request) > File "/usr/local/lib/python3.6/site-packages/mailman/rest/helpers.py", > line 159, in _make_collection > for resource in collection] > File "/usr/local/lib/python3.6/site-packages/mailman/rest/helpers.py", > line 159, in <listcomp> > for resource in collection] > File > "/usr/local/lib/python3.6/site-packages/mailman/rest/post_moderation.py", > line 150, in _resource_as_dict > resource = self._make_resource(request.id) > File > "/usr/local/lib/python3.6/site-packages/mailman/rest/post_moderation.py", > line 77, in _make_resource > resource['msg'] = msg.as_string() > File "/usr/local/lib/python3.6/site-packages/mailman/email/message.py", > line 54, in as_string > value = email.message.Message.as_string(self) > File "/usr/local/lib/python3.6/email/message.py", line 158, in as_string > g.flatten(self, unixfrom=unixfrom) > File "/usr/local/lib/python3.6/email/generator.py", line 116, in flatten > self._write(msg) > File "/usr/local/lib/python3.6/email/generator.py", line 181, in _write > self._dispatch(msg) > File "/usr/local/lib/python3.6/email/generator.py", line 214, in _dispatch > meth(msg) > File "/usr/local/lib/python3.6/email/generator.py", line 243, in > _handle_text > msg.set_payload(payload, charset) > File "/usr/local/lib/python3.6/email/message.py", line 315, in set_payload > payload = payload.encode(charset.output_charset) > LookupError: unknown encoding: _iso-2022-jp$esc I think this should be fixed in Mailman core 3.2.0. It is related to Mailman core issues 256, 437 and 470 and merge requests 197, 322, 350 and 375. In particular, it looks like you are missing at least <https://gitlab.com/mailman/mailman/merge_requests/375>. -- Mark Sapiro <mark(a)msapiro.net> The highway is for gamblers, San Francisco Bay Area, California better use your sense - B. Dylan

8 years, 1 month

Re: Moderate mails from owner

by Mark Sapiro

On 4/30/19 1:04 AM, Henrik Rasmussen wrote: > @Mark: I am really sorry for the delayed responses, but this is a very low frequency list. I have subscribed to the list using a non-Microsoft address to see the outcome. > > The mails does indeed contain 'X-Mailman' headers. > > X-Mailman-Rule-Hits:nonmember-moderation > X-Mailman-Rule-Misses:dmarc-mitigation; no-senders; approved; emergency; loop; banned-address; member-moderation It looks like the message hit the nonmember-moderation rule and was accepted. This can happen in a few ways: First we determine the senders. Assuming the config is default, these are the addresses in From:, the envelope sender, and addresses in Reply-To: and Sender: if any. The only address I can see in the message headers that hasn't been altered by Mailman is the From: and maybe Reply-To: which you have munged to [LISTNAME](a)senderdep.example.com. Anyway that unmunged address and possibly others from the original incoming message will be users of the list with role nonmember. Now each of those (possibly only the one) nonmember(s) is checked for a moderation action. Since the message does not appear to have been held or processed through rules beyond nonmember-moderation, we presumably found a moderation action of accept. This can happen in a few ways., If this list was originally imported from Mailman 2.1 by the 'mailman import21' command, there may be a legacy accept_these_nonmembers attribute for the list. If so, and if a nonmember sender address matches an address or pattern in the list's accept_these_nonmembers, the message will be accepted. Otherwise if the moderation_action for a nonmember sender address is accept the message will be accepted. You need to check the list's accept_these_nonmembers attribute and the non-member address's moderation action. If you have recent Postorius, you can see nonmembers and their options from the 'users' -> Non-members view. In any case, you can do something like mailman shell -l list.example.com Welcome to the GNU Mailman shell The variable 'm' is the list.example.com mailing list >>> m.accept_these_nonmembers returns a possibly empty list Then for the sender addresses >>> memb = m.nonmembers.get_member('sender address') >>> memb.moderation_action This may return <Action.accept: 3> in which case you may want >>> memb.moderation_action = m.default_nonmember_action -- Mark Sapiro <mark(a)msapiro.net> The highway is for gamblers, San Francisco Bay Area, California better use your sense - B. Dylan

7 years, 5 months

Re: Question about message bounce stats

by Abhilash Raj

> On Aug 30, 2021, at 11:27 AM, Stephen J. Turnbull <stephenjturnbull(a)gmail.com> wrote: > > Ruth Ivimey-Cook writes: > >> If Abhilash has a starting point, > > IIRC it was quite primitive, and probably not at the the individual > message level, more like list level. We do keep a bounce score for Member (email, mailinglist pair) that is right now only available in Mailman’s database and is used for the purposes of un-subscriptions or disabling delivery. We haven’t had a chance to expose these values through REST API, but it is something I’d be happy to accept a patch for and isn’t too difficult if someone wants to pick up the task. It might be helpful at some point to expose some of those stats to the list owner or site admin as well in Postorius. > >> and there is acceptance from others to integrate something of this >> sort, then I could possibly help make it happen. > > If you're that interested, I'd say get started, at least on sketching > out requirements. There will probably be some nitpicking about code > style and the like, and there may be delays in integrating stuff due > to the peanut gallery contributing requirements that we decide we want > in the feature, but I don't think there's a problem with the basic > idea. Yep, +1. It would be good to first figure out what more stats do we need/want and if they just need to be exposed through the API or we need to setup some offline setup for calculating those metrics with some mechanism and then expose. > > We won't be putting tracking pixels and the like in outgoing posts, > but as long as it's internal data already generated by normal Mailman > operation, I would be somewhere between very surprised and shocked > (SHOCKED, I tell you!) if it weren't accepted. Yeah, anything that is possible to generate with regular Mailman operation is already possible for a site admin to get from logs with some scripting. So, the idea to expose them in a better UX I guess should be okay. Only thing we might want to consider is how much of that data is exposed to non-server-admins (list owners, mods etc) and the policy enforcement for that if users don’t like the default. -- thanks, Abhilash Raj (maxking)

5 years, 1 month

Mailman-users search results for query "Postorius"