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

[MM3-users] Re: Moderation request email from a non existing user

by Mark Sapiro

On 5/31/22 02:15, David Lopez via Mailman-users wrote: > Every day mailman (MM 3.3.3 (Tom Sawyer)) sends me an email with a held unsubcription request from X user. This user is not subcribed to that list anymore but every day an email is sending to the list owner. On the web interface there's nothing pending for approval or similar. Is there anyway to avoid receiving this anoyning email every day? Thanks in advance. Postorius >=1.3.5 has an `Unsubscription Requests` choice in the `Subscription requests` pull down. This choice will list the request with and allow you to delete it. For earlier Postorius this needs to be done via the REST API or via mailman shell. For example: ``` $ bin/mailman shell -l list(a)example.com Welcome to the GNU Mailman shell Use commit() to commit changes. Use abort() to discard changes since the last commit. Exit with ctrl+D does an implicit commit() but exit() does not. The variable 'm' is the list(a)example.com mailing list >>> pendingsdb = getUtility(IPendings) >>> for token, data in pendingsdb.find(m, pend_type='unsubscription'): ... if data['token_owner'] == 'moderator': ... pendingsdb.confirm(token) ... data about the request will be displayed here >>> commit() >>> ``` -- Mark Sapiro <mark(a)msapiro.net> The highway is for gamblers, San Francisco Bay Area, California better use your sense - B. Dylan

3 years, 11 months

[MM3-users] Re: Performance issues with Mailman 3

by Mark Sapiro

On 10/6/22 15:08, Wong, Wesley wrote: > Hi, I am having some performance problems with Mailman 3 (version 3.3.5) when it sends out a lot of messages to people. We recently migrated from our old Mailman 2.1.x system to Mailman 3.x about 3 months ago. We host about 350 lists with membership counts varying between 10 to 1500 members on some of the lists. I noticed that outbound messages from Mailman to our outbound SMTP are getting delayed up to an hour when Mailman is processing a lot of messages going to lists. I suspect the difference is your Mailman 3 instance has full VERP enabled and your Mailman 2.1 instance did not. I.e., In MM 2.1, you did not override the default `VERP_DELIVERY_INTERVAL = 0` in mm_cfg.py, but in MM 3 you have `verp_delivery_interval: 1` in the `mta` section of mailman.cfg. > I was wondering if there are good performance tuning tips to be considered for Mailman 3 (i.e. OS, database and/os Mailman Core). I am running the setup on a VM. Here is my configuration for VM and OS: Search the Titles for `performance` at https://wiki.list.org/. The articles you find are all written for MM 2.1, but you're really dealing with the MTA and the issues are the same for MM 3. -- Mark Sapiro <mark(a)msapiro.net> The highway is for gamblers, San Francisco Bay Area, California better use your sense - B. Dylan

3 years, 7 months

[MM3-users] Re: running a script for the mailman-shell (to discard held messages) gives errors about a package argument for relative import

by Mark Sapiro

On 6/15/24 03:10, via Mailman-users wrote: > > Now, obviously, I put these exact lines in a script, so I don't have to type it out every single time, and try to run it using > >> sudo -u list mailman shell -l testlist.our-server.de -r ./mm_discard_held.py > > but that invariably gives me ... > TypeError: the 'package' argument is required to perform a relative import for './mm_discard_held' To run a script named mm_discard_held.py in that way, the script must define a function mm_discard held. The content needs to be something like ``` from mailman.app.moderator import handle_message from mailman.config import config from mailman.interfaces.action import Action from mailman.interfaces.request import IListRequests # The above are needed. These imports are done automatically when # running mailman shell interactively, but not when running a script. def mm_discard_held(mlist) rdb = IListRequests(mlist) for req in rdb.held_requests: if req.request_type == RequestType.held_message: config.db.commit() ``` See `mailman shell --details` > I've tried moving it to the path where the mailman binary lives, as suggested. That is what you should do. -- Mark Sapiro <mark(a)msapiro.net> The highway is for gamblers, San Francisco Bay Area, California better use your sense - B. Dylan

1 year, 10 months

[MM3-users] Re: Pck files stuck in out queue

by Mark Sapiro

On 2/7/25 10:08, Lieuallen, Thomas Otis via Mailman-users wrote: > > I have a remaining issue that baffles me. With my test list, I created a template for ‘list:member:regular:header’. It just has text in it, keeping it simple. I create it and see the entries in the database tables and they are correct. However, when I send a test email, my template text is not inserted, but instead another simple text: “testing hello”. I do the same with list:member:regular:footer, and it works just fine. It is just the header that is working incorrectly. When I remove that postorius header template for the list, that ‘testing hello’ goes away. So, it’s only appearing when I have a postorius template setup for that list. What do you get from the following database queries? SELECT * FROM template WHERE name = 'list:member:regular:header'; SELECT * FROM postorius_emailtemplate WHERE name = 'list:member:regular:header'; Depending on your installation, these tables may be in separate databases, i.e., template table in mailman db and postorius_emailtemplate in mailmanweb db. And what do you get if you go to the uri in the result(s) from the first query? The context in the first results and maybe the second results should also be a clue. -- Mark Sapiro <mark(a)msapiro.net> The highway is for gamblers, San Francisco Bay Area, California better use your sense - B. Dylan

1 year, 3 months

[MM3-users] Re: Is there an option to "disable" a list temporarily? (feature request?!)

by Mark Sapiro

On February 2, 2026 3:26:40 AM PST, Christian Schneider <christian.schneider(a)tu-dortmund.de> wrote: >Hello dear Mailman Team, > >I scanned through the web interface of my mailman instance... >and I did not find an option to disable a list temporarily ("sending" and "access to web interface")... >This might come in handy when a list is abused for sending spams >or when a list owner wants his/her list to be removed... >Instead of removing the list instantly I would disable it for three months first... >(You never know with users... ;-) ) >Preferably I would backup the list (settings and members) and the archives, >but as seen in the discussion there is actually no backup mechanism for lists... > >Is there an option to disable a list (except from resetting passwords and remove/disable mail aliases)? > >If not I'd like to hand this in as a feature request... xD There is an emergency moderation setting. It isn't really what you're asking for, but it might be helpful for spam attacks. As far as backup and restore of lists is concerned, there are issues at <https://gitlab.com/mailman/mailman/-/issues/1182> and <https://gitlab.com/mailman/postorius/-/issues/13>. -- Mark Sapiro <mark(a)msapiro.net> Sent from my Not_an_iThing with standards compliant, open source software.

3 months

[MM3-users] Re: Log rotation

by Mark Sapiro

On 04/10/2018 03:39 PM, Abhilash Raj wrote: > Yes, this is a known thing and the reason for it is that the SIGTERM isn't delivered till the process wakes up next time. We can have the process sleep for a smaller amount of time to fix this, but then it would mean that it will be running much more often. > > It is the Retry runner, which has sleep_time set to 15m. I don't know if you want to retry very often, like 2min or 5min, but you can change it by adding the following snippet to your mailman.cfg A long time ago (in a galaxy far away) Mailman 2.1 had a global DELIVERY_RETRY_WAIT setting. This setting had been ineffective for years, relying instead on the retry runner's sleep time. In 2.1.26, for what turned out to be a probably spurious reason, I made DELIVERY_RETRY_WAIT effective again, although the retry runner still sleeps for 15 minutes. We could implement something similar in MM 3 to allow the retry runner to have a much shorter sleep time without actually retrying the delivery that often. The down side of that is even though we aren't retrying delivery each time the runner wakes up, we are dequeueing and requeueing the message each time and this would have a file system impact. -- Mark Sapiro <mark(a)msapiro.net> The highway is for gamblers, San Francisco Bay Area, California better use your sense - B. Dylan

8 years

[MM3-users] Re: dmarc_mitigate_unconditionally vs. mitigate_owner_mail

by Mark Sapiro

On April 28, 2026 5:57:16 PM GMT+02:00, "Lichtinger, Bernhard" <Bernhard.Lichtinger(a)lrz.de> wrote: >I expected that with "mitigate_owner_mail = no" there would be no munge_from for mails to list-owner@mailman. >But in the end "dmarc_mitigate_unconditionally = yes" has higher precedence than "mitigate_owner_mail = no" in handlers/dmarc.py. > >I am not sure if this is a bug or a feature ;) I need to look at this. If in fact dmarc_mitigate_unconditionally = yes trumps mitigate_owner_mail = no, that is unintentional and a bug and will be fixed. >With mitigate_owner_mail = yes and munge_from is the list posting address really a good choice for the new header from address? Good question. >Not only auto replies but also owners who click "reply all" without thinking will post to the list. But using the list-owner as new header from would also have some drawbacks, e.g. the possibility of an endless loop of auto replies. Adding the "precedence: list" header also to mails sent to the list-owner might prevent this in most cases at least. But this feels like putting more tape on the problem. These are all important considerations. Definitely things to consider. >In my opinion the least bad solution would be to give "mitigate_owner_mail = no" higher precedence than "dmarc_mitigate_unconditionally = yes". This is definitely the intent and will be fixed. -- Mark Sapiro <mark(a)msapiro.net> Sent from my Not_an_iThing with standards compliant, open source software.

1 week, 3 days

[MM3-users] Re: Recommended way to backup a mailman3 instance

by Mark Sapiro

On 4/13/20 3:22 AM, Andrew Hodgson wrote: > > I was working round my own backup strategy a few weeks ago as I discussed earlier on this list. One thing I found when the directory structure that Mailman Core uses is that the lists directories do not get re-created when Mailman Core starts if they don't already exist. Is this something that should happen, and when would those directories get created? Every other directory did get re-created. > > In my case I was moving from a Dockerised installation to one using venvs, and as the directories from the Docker installation were empty as there hadn't been any postings for a few days, I didn't transfer those over. I created the list directories myself and everything carried on. These var/lists/<list-id>/ directories hold the digest.mmdf files which are mailboxes containing the messages for the next digest. A list post will be added to the digest.mmdf file which will be created if necessary, but if the var/lists/<list-id>/ directory doesn't exist, the create will fail. Thus, the var/lists/<list-id>/ directories need to exist. Normally, they are created when the list is created so they need to be part of a backup. -- Mark Sapiro <mark(a)msapiro.net> The highway is for gamblers, San Francisco Bay Area, California better use your sense - B. Dylan

6 years

[MM3-users] Re: Restore/export existing Mailman lists + hyperkitty archives on a new server

by Mark Sapiro

On 9/15/22 23:10, Kimmo L wrote: >> Those errors should result in the affected messages being saved as *.pck >> files in Mailman's var/archives/hyperkitty/spool/ directory. Possibly >> there is only one such 'bad message' which is retried each time there is >> a new post resulting in the same error. How many such files are there? >> If only one, please send me that one too. Also, these can be examined >> with mailman qfile. > There was 3 file. I used the mailman qfile command and the output was this: > [----- start pickle -----] > <----- start object 1 -----> > Traceback (most recent call last): ...> File "/usr/lib64/python3.9/email/generator.py", line 239, in _handle_text > raise TypeError('string payload expected: %s' % type(payload)) > TypeError: string payload expected: <class 'list'> These again are anonymized posts that had important headers removed because of the incorrect anonymous_list_keep_headers setting. > After i cleaned up /var/archives/hyperkitty/spool folder, mailman.log file is much cleaner and i dont see any new no "Message-ID" error at the moment. Yes. Now that you have the default anonymous_list_keep_headers setting things should be OK going forward. -- Mark Sapiro <mark(a)msapiro.net> The highway is for gamblers, San Francisco Bay Area, California better use your sense - B. Dylan

3 years, 7 months

[MM3-users] Re: Is there a way of recording bounce messages?

by Mark Sapiro

On 9/27/23 06:35, Mohsen Masoudfar wrote: >>> I am interested to know more about the reasons behind these bounces, they are all handled by Postfix and deleted. ...>>> Is there a way to send them to a mailbox? Or prevent them from being deleted, so that I can look into the message body? Presumibly you have settings for Postfix like those at https://docs.mailman3.org/projects/mailman/en/latest/src/mailman/docs/mta.h… or https://docs.mailman3.org/en/latest/install/virtualenv.html#setup-mta The simplest way is to deliver bounces to some user instead of Mailman. This will disable automated bounce processing for the list so it should be done temporarily only to see a few bounce messages and then reverted. Lets say you have a few problem lists, list1(a)example.com and list2(a)example.com. Put the following in Postfix main.cf ``` virtual_alias_domains = example.com virtual_alias_maps = regexp:/etc/postfix/temp-aliases ``` Then create /etc/postfix/temp-aliases with this content ``` list1-bounces(a)example.com user(a)example.net list2-bounces(a)example.com user(a)example.net ``` where user(a)example.net is the address that should receive the bounces. There are also ways to save copies of all mail received by Postfix. See, e.g., https://www.electricmonk.nl/log/2015/03/06/keep-an-archive-of-all-mails-goi… -- Mark Sapiro <mark(a)msapiro.net> The highway is for gamblers, San Francisco Bay Area, California better use your sense - B. Dylan

2 years, 7 months

Search results for query "sapiro"