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

[MM3-users] Re: Bulk update of members' moderation settings

by Mark Sapiro

On 11/18/21 12:37 PM, Alex King via Mailman-users wrote: > I imported a list from mailman 2.1 using > https://docs.mailman3.org/en/latest/migration.html. > > It happens that emergency moderation was set on the mailman 2.1 list, > and this has resulted in all members having Moderation set to Hold. I > now want to change that to Default Processing for all members. > > Is there a way to achieve that in bulk without clicking through the > members options for each member in Postorius? I don't understand how this happened. The mailman 2.1 list's emergency setting should hsave been imported as the emergency setting of the Mailman 3 list and should not affect individual member's moderation at all. However, to set the moderation action for all members of a list to default processing You can do something like this in mailman shell ``` bin/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.interfaces.action import Action >>> for member in m.members.members: ... member.moderation_action = Action.defer ... >>> commit() ``` -- 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: urls.py location on venv install

by Mark Sapiro

On 8/10/26 07:15, Torsten wrote: > > mailman throws this one: > > 2026-08-10 16:11:20 [FALCON] [ERROR] GET > /3.1/lists?advertised=true&count=0&page=1 => Traceback (most recent call > last): > File "/opt/mailman/venv/lib/python3.13/site-packages/falcon/app.py", > line 476, in __call__ > process_resource(req, resp, resource, params) > ~~~~~~~~~~~~~~~~^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ > File > "/opt/mailman/venv/lib/python3.13/site-packages/mailman/rest/wsgiapp.py", line 65, in process_resource > raise HTTPUnauthorized( > ~~~~~~~~~~~~~~~~^ > '401 Unauthorized', > ^^^^^^^^^^^^^^^^^^^ > 'REST API authorization failed', > ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ > challenges=[realm]) > ^^^^^^^^^^^^^^^^^^^ > TypeError: HTTPUnauthorized.__init__() takes 1 positional argument but 3 > positional arguments (and 1 keyword-only argument) were given This is from a Mailman core version < 3.3.10. It was fixed for Mailman >= 3.3.10 by <https://gitlab.com/mailman/mailman/-/merge_requests/1267>. It appears that you don't have the latest Mailman core. > and mailman-web this one: Which is a result of the one above. > > I have taken the old database from the Debian configuration and moved it > to /opt/mailman... where it should belong (I hope). The database(s) should be in the location(s) pointed to by the [databases] section of mailman.cfg and the DATABASES attribute in settings.py. In an installation per https://docs.mailman3.org/en/latest/install/virtualenv.html these are postgresql databases accessed via the postgresql server. -- Mark Sapiro <mark(a)msapiro.net> The highway is for gamblers, San Francisco Bay Area, California better use your sense - B. Dylan

2 months, 1 week

[MM3-users] Re: Custom templates (was: Re: Re: nginx configuration on a multitasking server)

by Mark Sapiro

On 1/14/22 6:58 PM, David Newman wrote: > > On 1/14/22 6:35 PM, Mark Sapiro wrote: >> >> The place for feature requests for Mailman core (which this is) is >> https://gitlab.com/mailman/mailman/-/issues, however, this is not >> straightforward as Mailman core doesn't know if you even have >> Postorius or some other web management UI installed or what the URL to >> access it might be. Thus it's not just a simple matter of editing >> templates. It would also require a configuration setting for the base >> URL for the web admin UI and changes in logic to provide an >> appropriate replacement depending on whether or not the base URL was >> configured. > > Understood, thanks. Although this distinction is very important for > server admins, it's likely not meaningful for many list owners and > moderators. For them, MM2.1 sent an email saying "go here" and > MM3/Django/Postorius/Hyperkitty doesn't, at least not out of the box. > > There is some pending template in use by default, just not one with a > URL included. All the templates have defaults and the defaults don't have URLs because these are unknown to core. > Is this something better handled in the venv and/or Web installation > docs? Or should I file a feature request for core, or Postorious or > someplace else? I think a feature request for core is appropriate. I'm only saying implementing this is a non-trivial change. What I do on sites I admin is put custom versions of all these domain:admin:notice:new-list.txt list:admin:action:post.txt list:admin:action:subscribe.txt list:admin:action:unsubscribe.txt list:admin:notice:pending.txt list:member:digest:footer.txt list:member:digest:masthead.txt list:member:regular:footer.txt list:user:action:invite.txt list:user:action:subscribe.txt list:user:action:unsubscribe.txt list:user:notice:post.txt list:user:notice:probe.txt list:user:notice:welcome.txt in /opt/mailman/mm/var/templates/site/en and at mail.python.org which also has German language lists, in /opt/mailman/mm/var/templates/site/de. That could be documented, but it would be preferable to be able to document just a base web management URL and then put a replacement such as $web_ui in the default templates and replace that with a URL if configured or some generic text otherwise. -- 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: Alias Domains in postfix_domains wrong way around?

by Mark Sapiro

On 10/24/20 10:34 AM, Hans-Martin Mosner wrote: > > Is my understanding correct that postfix_domains should have the true (externally visible) domains as keys, and values > that basically don't matter, or should it have both the real domains and their alias names as keys? With such a > convoluted setup, my brain twists a little. I'm not sure what's going on in your case. I have two separate servers that use alias domains, and for both of them, the postfix_domains file lists the alias domain as the key and the real domain as the value. This works fine with the Postfix settings ``` transport_maps = hash:/path-to-mailman/var/data/postfix_lmtp relay_domains = hash:/path-to-mailman/var/data/postfix_domains virtual_alias_maps = hash:/path-to-mailman/var/data/postfix_vmap ``` Is this what you have? Note that the address should be remapped from list@true_domain to list@alias_domain by virtual_alias_maps prior to checking relay_domains. Perhaps you have some other unusual thing in your Postfix configuration. What does `postconf -n` report? This is what I see in the mail log for a typical delivery ``` Oct 18 13:30:44 example postfix/lmtp[13745]: 108CA1F8A03: to=<list(a)x.example.org>, orig_to=<list(a)example.org>, relay=127.0.0.1[127.0.0.1]:8024, delay=0.08, delays=0.05/0.01/0/0.02, dsn=2.0.0, status=sent (250 Ok) ``` where example.org is the true domain and x.example.org is the alias domain. -- Mark Sapiro <mark(a)msapiro.net> The highway is for gamblers, San Francisco Bay Area, California better use your sense - B. Dylan

5 years, 11 months

[MM3-users] Re: Installation -- error on mailman-web migrate

by Mark Sapiro

On 9/16/21 8:43 PM, Mark Dale via Mailman-users wrote: > > ... and then at the beginning of many errors printed to screen I now have... > > /opt/mailman/venv/lib/python3.9/site-packages/django_q/conf.py:139: UserWarning: Retry and timeout are misconfigured. Set retry larger than timeout, > failure to do so will cause the tasks to be retriggered before completion. > See https://django-q.readthedocs.io/en/latest/configure.html#retry for details. The current version of mailman_web/settings/mailman.py has ``` Q_CLUSTER = { 'retry': 360, 'timeout': 300, 'save_limit': 100, 'orm': 'default', } ``` Earlier versions omitted the `'retry': 360` which is the issue. > Completely not comprehending the above doc (and being absolutely clueless about django), I blindly added "retry: 30" ... > root@mx:~# nano -c /opt/mailman/venv/lib/python3.9/site-packages/django_q/tests/settings.py > > # Django Q specific > Q_CLUSTER = { > "name": "django_q_test", > "cpu_affinity": 1, > "testing": True, > "log_level": "DEBUG", > "django_redis": "default", > "retry": 30, Make that "retry": 360, > } > > > ... but no joy. Is it me or are there some pieces missing from the documentation? > > > _______________________________________________ > 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/ > -- Mark Sapiro <mark(a)msapiro.net> The highway is for gamblers, San Francisco Bay Area, California better use your sense - B. Dylan

5 years, 1 month

[MM3-users] Re: Bounce processing HTML

by Mark Sapiro

On 11/25/25 8:51 AM, pashdown(a)xmission.com wrote: > Where do I set forward_unrecognized_bounces_to ? I can't find documentation on this. If you have Postorius it's Settings -> Bounce Processing -> Forward unrecognized bounces. It is a list attribute with 3 possible values which are discard them, forward to list owners/moderators or forward to the site admin. The default value when lists are created is forward to list owners/moderators. However none of this is relevant to your situation because the bounces you are getting that result in the Bounce message for a non subscriber log messages you are seeing are not unrecognized. As I said at https://lists.mailman3.org/archives/list/mailman-users@mailman3.org/message… I think these are spam sent to the list-bounces address that one of the heuristic recognizers treats as a real DSN and parses those non-addresses. In order to see the actual messages, you will have to configure your MTA to deliver them to a human or you could apply this patch ``` --- a/src/mailman/runners/bounce.py +++ b/src/mailman/runners/bounce.py @@ -49,6 +49,7 @@ class BounceRunner(Runner): # List isn't doing bounce processing? if not mlist.process_bounces: return False + maybe_forward(mlist, msg) # Try VERP detection first, since it's quick and easy context = BounceContext.normal addresses = StandardVERP().get_verp(mlist, msg) ``` to copy all bounce messages to the forward_unrecognized_bounces_to destination. -- Mark Sapiro <mark(a)msapiro.net> The highway is for gamblers, San Francisco Bay Area, California better use your sense - B. Dylan

10 months, 3 weeks

[MM3-users] Re: Installing mailman 3

by Mark Sapiro

On 07/21/2017 09:36 AM, Rafael Mora wrote: > > Postfix <http://www.postfix.org/>: To setup Postfix, add the following > configuration to master.cf: > > # Support the default VERP delimiter.recipient_delimiter = > +unknown_local_recipient_reject_code = 550owner_request_special = > notransport_maps = > hash:/path-to-mailman/var/data/postfix_lmtplocal_recipient_maps = > hash:/path-to-mailman/var/data/postfix_lmtprelay_domains = > hash:/path-to-mailman/var/data/postfix_domains > > > I added that config at the bottom of the master.cf file and did a 'postfix > reload' and I got this error message: > > [root@localhost ~]# postfix reload > /usr/sbin/postconf: fatal: file /etc/postfix/master.cf: line 129: bad field > count > postfix/postfix-script: fatal: cannot execute /usr/sbin/postconf! First of all, in a report such as this, it would really help if you reported what is actually in master.cf in the vicinity of line 129. However, that said, the doc is wrong. The lines should be added to main.cf, not master.cf. See <https://gitlab.com/mailman/mailman-suite-doc/issues/14>. Also, what you post above is quite garbled. It is not clear what you meant, but the lines to add should be # Support the default VERP delimiter. recipient_delimiter = + unknown_local_recipient_reject_code = 550 owner_request_special = no transport_maps = hash:/path-to-mailman/var/data/postfix_lmtp local_recipient_maps = hash:/path-to-mailman/var/data/postfix_lmtp relay_domains = hash:/path-to-mailman/var/data/postfix_domains and should not be wrapped as in your post. -- Mark Sapiro <mark(a)msapiro.net> The highway is for gamblers, San Francisco Bay Area, California better use your sense - B. Dylan

9 years, 2 months

[MM3-users] Re: Header and footer templates in MM3

by Mark Sapiro

On 1/19/20 1:15 AM, Gila Halpern wrote: > I read the earlier message from Peter Mueller about message decoration, and > where the templates are in the file system. However, when I edit the > header and footer templates in Postorius, those templates do not appear in > the location specified. Should I be looking somewhere else? The templates created in Postorius are created in the postorius_emailtemplate table in Mailman's database and referenced via URLs like 'https://example.com/mailman3/api/templates/list/<list-id>/<template-name>'. I.e., they are not stored in the file system. > (I intend to > write a program to rotate though several headers/footers, so I need to know > where to have it write to.) If Postorius has set a template for a list, it has set the URI for that template and list to one similar to that above and that URI ultimately references the template in the database. You have choices. You can set the templates in Postorius and your program can do database queries to rotate the template text, or you can set the template URIs via Mailman's TemplateManager to file system paths or not set them and use the default paths (deleting them in Postorius will leave them unset). See <https://mailman.readthedocs.io/en/latest/src/mailman/rest/docs/templates.ht…> -- Mark Sapiro <mark(a)msapiro.net> The highway is for gamblers, San Francisco Bay Area, California better use your sense - B. Dylan

6 years, 8 months

[MM3-users] Re: Mailman3 stopped working after Upgrade to Ubuntu 21.04

by Mark Sapiro

On 8/7/21 4:35 AM, Thomas Möhle via Mailman-users wrote: > Hey, > > I have set up mailman3 with mailman3-web on my mailserver and after > upgrading to Ubuntu 21.04 my setup stopped working. In what way? Do list posts get delivered? What works and what doesn't? What are the observable symptoms for things that don't work? > I can see repeating > log entries of mailman trying to reach something within hyperkitty and > getting an error. The same constant repeating cycle of log entries is > visible in my log files. It appears from your logs that Mailman core's attempts to reach the hyperkitty api may be failing. Mailman core uses the mailman_hyperkitty module to communicate with the hyperkitty api to get the url at which a message will be stored and to deliver a message to hyperkitty. This may not be working. There are probably unarchived messages in Mailman's var/archives/hyperkitty/spool/ directory. What do you get for example if you go in a web browser with hyperkitty running to https://mail.bitkomplex.de/mailman3/hyperkitty/api/mailman/urls?mlist=landw… And please don't post secret keys and change the value of api_key: in mailman-hyperkitty.cfg and the corresponding value in MAILMAN_ARCHIVER_KEY in your Django settings. -- Mark Sapiro <mark(a)msapiro.net> The highway is for gamblers, San Francisco Bay Area, California better use your sense - B. Dylan

5 years, 2 months

[MM3-users] Re: messages in queue/shunt

by Mark Sapiro

On 5/7/23 08:39, Christian via Mailman-users wrote: > Can/should old messages residing in queue/shunt be manually removed? I see > they were delivered. Is there any reason to leave them there? Thank you!! If they were delivered, they shouldn't be in queue/shunt/. Messages are shunted (placed in queue/shunt/) because of some exception in processing that caused processing to be aborted. It is possible for a message to be shunted even though it was delivered if the exception that caused it to be shunted occurred in the archive runner or the digest runner. When a message is shunted, an entry is made in mailman.log indicating the reason and giving a traceback. This information can be used to determine if there is some issue in Mailman that caused the exception, and if so, that issue can be fixed and the message's processing continued via `mailman unshunt`. Also, pointing `mailman qfile` at the shunted .pck file will not only display the raw message, but also metadata indicating which queue was being processed when the exception occurred. In any case, If the message is not going to be unshunted because it was spam or too old to be relevant or whatever, it should be removed from queue/shunt/ if for no other reason than so a future `mailman unshunt` won't requeue it. -- Mark Sapiro <mark(a)msapiro.net> The highway is for gamblers, San Francisco Bay Area, California better use your sense - B. Dylan

3 years, 5 months

Search results for query "sapiro"