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

[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, 2 months

[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 month, 3 weeks

[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, 2 months

[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, 9 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, 8 months

[MM3-users] Re: Weird behavior with Outlook and any MM3 List

by Mark Sapiro

On 11/1/23 09:42, Thomas Ward via Mailman-users wrote: > I'm seeing some *really* odd behavior with Mailman 3 and Microsoft Outlook clients (even Outlook Web Access). > > When messages come in with a subject prefix, of any way shape or form, Microsoft Outlook seems to *completely strip* the prefixes from any "reply" sent, which could be problematic. > > While the "In-Reply-To" header is still intact and such, Microsoft just seems to 'strip' prefixes from subject lines and that causes a problem in some cases. > > Has anyone observed this behavior before? If so, have you found any workarounds? This is a Microsoft/Outlook issue. As you note at https://lists.mailman3.org/archives/list/mailman-users@mailman3.org/message… this is just the way Outlook displays the message subject. I know of now way around this, but I don't use Microsoft MUAs. Does Outlook also strip the prefix from replies? This probably wouldn't matter for replies to the list as the list will add it back, but might be an issue for other direct recipients. Presumably, Outlook is looking at the [] around the prefix. You might try either dropping the brackets or using something else such as _My-List_ instead of [MyList]. -- 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

[MM3-users] Re: Permission denied for fulltext_index

by Mark Sapiro

On 11/30/22 08:41, Jan Eden via Mailman-users wrote: > > Changing the PATH value to a full path (/opt/mailman/fulltext_index) > and restarting mailman-web generates a different error: Yes, it should be a full path. >> ERROR 2022-11-30 16:38:37,953 1028315 django.request Internal Server Error: /archives/list/testing@lists.eden.one/thread/T6MCILAVQYV5QIOGHJB3JNJ26Z7E2Z35/reattach-suggest >> Traceback (most recent call last): >> File "/opt/mailman/venv/lib/python3.10/site-packages/django/core/handlers/exception.py", line 55, in inner >> response = get_response(request) >> File "/opt/mailman/venv/lib/python3.10/site-packages/django/core/handlers/base.py", line 197, in _get_response >> response = wrapped_callback(request, *callback_args, **callback_kwargs) >> File "/opt/mailman/venv/lib/python3.10/site-packages/hyperkitty/lib/view_helpers.py", line 137, in inner >> return func(request, *args, **kwargs) >> File "/opt/mailman/venv/lib/python3.10/site-packages/hyperkitty/views/thread.py", line 454, in reattach_suggest >> sugg_thread = msg.object.thread >> AttributeError: 'NoneType' object has no attribute 'thread' This says that searching the archive for this list for messages matching the current message subject returns None. It is probably a bug that we don't test for this, but what exactly are you doing? See the post at https://lists.mailman3.org/archives/list/mailman-users@mailman3.org/message… for the only way I've been able to create an error like this. -- Mark Sapiro <mark(a)msapiro.net> The highway is for gamblers, San Francisco Bay Area, California better use your sense - B. Dylan

3 years, 6 months

[MM3-users] Re: Strange URL in error message

by Mark Sapiro

On 7/17/24 11:47 PM, waps(a)tantalus.jena.thur.de wrote: > Hi Mark, > thanks for your patience. But now I get a little spinning wheel on the archive site, 3 "Error 500" in the Browser console and /var/log/mailman3/web/mailman-web.log shows repeatedly the error: > > ERROR 2024-07-18 08:34:38,261 1760 django.request Internal Server Error: /mailman3/hyperkitty/list/latex-team(a)latex-project.org/posted-to > Traceback (most recent call last): ...> File "/usr/lib/python3/dist-packages/django/db/models/query.py", line 435, in get > raise self.model.DoesNotExist( > hyperkitty.models.thread.Thread.DoesNotExist: Thread matching query does not exist. > > Since the archive is still quite empty and we have only one mailing lis, it would not be a big loss if it could resettet. But how I can do the, without resettinh the member data? Could it be that the Sqlite interface is not as stable as one the the "real databases"? As a superuser, you can go to /mailman3/hyperkitty/list/latex-team(a)latex-project.org/ and delete the archive. This will not delete the mailing list, and an empty archive will eventually be recreated, and new posts will be archived. Regarding the issue, see https://gitlab.com/mailman/hyperkitty/-/issues/504. Ensure that cron is running the Django hourly, daily, etc. tasks and that qcluster is running. -- Mark Sapiro <mark(a)msapiro.net> The highway is for gamblers, San Francisco Bay Area, California better use your sense - B. Dylan

1 year, 11 months

[MM3-users] Re: Mailman 3 on Ubuntu 18.04

by Mark Sapiro

On 12/9/18 12:53 PM, Odhiambo Washington wrote: > On Sun, 9 Dec 2018 at 22:37, Mark Sapiro <mark(a)msapiro.net> wrote: >> >> The nginx logs generally aren't too useful. Both Mailman core and Django >> write logs. Core's log is probably in var/log/mailman.log where is >> defined in mailman.cfg as var_dir. Django's log is defined in Django's >> settings in the LOGGING setting. >> > > Which file contains Django's settings? See <http://docs.list.org/en/latest/pre-installation-guide.html#django-knowledge>. >>> Ultimately I need to figure out: >>> 1. How the mailman queue runners are started and stopped >> >> mailman start >> > > Why not systemctl mailman start?? Just wondering, as that is what I am > seeing is common in Ubuntu. > Does this make the components start after a reboot? 'mailman start' is the command that starts Mailman. When you install Mailman, you typically create an init, upstart or systemd script to enable 'systemctl mailman start'. Presumably the Ubuntu mailman3-full package installs such scripts for Mailman and other components that need to be started at boot, but I'm not that familiar with this package. >>> 2. Migrate s few lists from Mailman2 to this Mailman3 >> >> mailman import21 >> <django management> hyperkitty_import >> > > Please show me where that is documented. I have to pull my lists from an > old machine to this new one. Those commands have --help options. There is also some documentation at <https://mailman.readthedocs.io/en/latest/src/mailman/commands/docs/import.h…> and <https://hyperkitty.readthedocs.io/en/latest/install.html#importing-the-curr…>. All of our formal documentation is at <http://docs.list.org/en/latest/>. > So, when you talk about Django settings, you are referring to mailman.cfg > file??? :-) No. I am talking about a file often named settings.py and which my in turn import a file named something like settings_local.py. See my first answer above. > I have spent all my weekend till now, trying to figure all this out. Life > seems a little easier with mm2.x .... I expect some of that is just what you're familiar with, but yes, Mailman 3 is more complex than Mailman 2.1 just as Mailman 2.1 is more complex than a Bcc: list. -- Mark Sapiro <mark(a)msapiro.net> The highway is for gamblers, San Francisco Bay Area, California better use your sense - B. Dylan

7 years, 6 months

[MM3-users] Re: How to identify the exact reason behind the shunting of the mails ?

by Mark Sapiro

On 6/18/21 3:34 AM, Shashikanth Komandoor wrote: > Thank you Mark for your immediate response. > > The below are the tracebacks I could find in the mailman log. > > *Jun 17 19:04:08 2021 (8642) Uncaught runner exception: sequence item 0: > expected str instance, Header foundJun 17 19:04:08 2021 (8642) Traceback > (most recent call last): File > "/var/lib/mailman/mailman/src/mailman/core/runner.py", line 173, in > _one_iteration self._process_one_file(msg, msgdata) File > "/var/lib/mailman/mailman/src/mailman/core/runner.py", line 266, in > _process_one_file keepqueued = self._dispose(mlist, msg, msgdata) File > "/var/lib/mailman/mailman/src/mailman/runners/pipeline.py", line 37, in > _dispose process(mlist, msg, msgdata, pipeline) File > "/var/lib/mailman/mailman/src/mailman/core/pipelines.py", line 50, in > process handler.process(mlist, msg, msgdata) File > "/var/lib/mailman/mailman/src/mailman/handlers/avoid_duplicates.py", line > 59, in process addrs = getaddresses(msg.get_all(header, [])) File > "/usr/lib64/python3.6/email/utils.py", line 112, in getaddresses all = > COMMASPACE.join(fieldvalues)TypeError: sequence item 0: expected str > instance, Header foundJun 17 19:04:08 2021 (8642) SHUNTING: > 1623936848.367641+4753f8127953071ddcabfe828ebe72fcf04d0ae2* This is https://gitlab.com/mailman/mailman/-/issues/881 which is fixed by https://gitlab.com/mailman/mailman/-/merge_requests/841 which will be in Mailman 3.3.5 when it's released. -- Mark Sapiro <mark(a)msapiro.net> The highway is for gamblers, San Francisco Bay Area, California better use your sense - B. Dylan

5 years

Search results for query "sapiro"