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

[MM3-users] Re: # comment allowed in a template file?

by skenny＠scss.tcd.ie

Mark Sapiro wrote: > If you mean can you add a '#' line that won't be part of the actual > rendered template, the answer is No. OK, thanks for the clarification. > > Initially, I created the template files with owner set to "root". This resulted in > > postings to lists getting stuck in mailman-core. It's vital that these files are owned > > by user "mailman". Once I changed the owner of the file to the latter, everything > > worked. > I don't think they need to be owned by 'mailman' as long as they are > readable by 'mailman' Yes, your formulation is a more accurate statement than mine (I could have instead simply relaxed the permissions on the files to make them world-readable). The effect of the template files not being readable by user "mailman" was interesting. Hundreds of lines like the following got written to mailman-core's var/log/smtp.log file at the rate of 4 per second: Jul 23 17:09:54 2020 (25) Using agent: <mailman.mta.bulk.BulkDelivery object at 0x7fdf9e7b5f28> (the hex number was different each time). Having excessively restrictive permissions on the template files is a silly - but easy enough - mistake to make. If it were possible to add it to Mailman 3, a more descriptive logging message could point others who make it in the right direction, perhaps. I spent a long time trying to figure out why messages weren't getting sent out from Mailman core, and in the end it was luck in form of a colleague's suggestion about file permissions that got me out of the rut. Thanks for the great support, Stephen Kenny

5 years, 10 months

[MM3-users] Re: Change the default value for the General Archive Policy

by Markus Grandpré

Dear Mr Hochstein, Thank you very much for providing the link. I'm afraid the same misunderstanding as with Marc Sapiro has occurred here. I'm aware that there are three different styles to choose from when creating a mailing list. However, the setting "Settings > Archiving > Archive policy" can be configured independently of the list creation process. Still, it would be beneficial if the default value after creating a list without an archive were not "Public archive", but rather "Do not archive this list". This would help prevent list administrators from being tempted to immediately enable a public archive when setting up an archive later—especially in cases where the list is intended to be private. Kind regards, Markus Grandpré Am 6/23/25 um 22:48 schrieb Thomas Hochstein: > Markus Grandpré wrote: > >> currently, when I create a new mailing list with MM3 the value for "Archive policy" is always set to "Public archives". >> I'd like to change the default value for "Archive policy" to "Do not archive this list". How can I do this? > > Perhaps > <https://lists.mailman3.org/archives/list/mailman-users@mailman3.org/thread/…> > has some pointers how to accomplish that? > > -thh > _______________________________________________ > 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/ > Archived at: https://lists.mailman3.org/archives/list/mailman-users@mailman3.org/message… > > This message sent to markus.grandpre(a)uni-konstanz.de -- Markus Grandpré Universität Konstanz Kommunikations-, Informations- und Medienzentrum (KIM) Abteilung IT-Dienste Forschung, Lehre und Infrastruktur Sachgebiet Diensteadministration Tel: ++49 7531 88 4342

11 months

[MM3-users] Re: Current status and issue deleting Archives in Mailman3

by Abhilash Raj

> On Nov 2, 2021, at 12:51 PM, Mark Sapiro <mark(a)msapiro.net> wrote: > > On 11/2/21 11:50 AM, bob B wrote: >> So I am teaching myself to fish, and see that it is actually django-admin, so that is in >> mailman-web? (in docker) >> But i get this: >> $ docker exec -it mailman-web /bin/bash >> bash-5.0# django-admin shell >> Python 3.8.10 (default, May 6 2021, 06:30:44) >> [GCC 9.3.0] on linux >> Type "help", "copyright", "credits" or "license" for more information. >> (InteractiveConsole) >>>>> from hyperkitty.models import MailingList >> Traceback (most recent call last): > ... >> raise ImproperlyConfigured( >> django.core.exceptions.ImproperlyConfigured: Requested setting INSTALLED_APPS, but settings are not configured. You must either define the environment variable DJANGO_SETTINGS_MODULE or call settings.configure() before accessing settings. > > > Do what it says. I.e. run > > DJANGO_SETTINGS_MODULE=path/to/settings; django-admin shell DJANGO_SETTINGS_MODULE expects a Python import path, instead of a filesystem path. The docker has documentation on running management commands, which in this case is “shell” [1] $ docker exec -it mailman-web python3 manage.py shell [1]: https://asynchronous.in/docker-mailman/web/#django-management-commands I know there are plethora of ways to run Django management commands, but this is the easiest one for docker. django-admin will work too, but you have to be in the right working directory for the import path to work and it get weird. I’ve always disliked how Django management commands work unfortunately and in trying to “fix” that with “mailman-web” (which isn’t adopted by container images), i feel I might have re-invented a third option. -- thanks, Abhilash Raj (maxking)

4 years, 6 months

[MM3-users] Re: Mailman not able to process "big" requests

by Jonas Felber

Thank you for your support, I got informed that we are now able to send out emails again. The problem was that the crashes we got while mass subscribing led to database corruptions. (From what I know, the problem was on our side, as we kubernetes did not properly restore some files after restarting so the database got corrupted (apparently we are running now a cleanup script on each restart)) There are still some problems, but I just wanted to send out a quick update. Thanks for your support, Jonas Jonas Felber <jonas.felber(a)vis.ethz.ch> Aktuar & CTF Präsident VIS - Verein der Informatik Studierenden an der ETH Zürich CAB E 31, Universitätstr. 6, ETH Zentrum, CH-8092 Zürich https://www.vis.ethz.ch > On 24 Apr 2018, at 17:21, Darren Smith <silas.crutherton(a)gmail.com> wrote: > > Our installation at https://lists.rootsweb.ancestry.com has around 33,000 > lists and somewhere around 1.5 million members. We have lists with 5,000+ > members. > > Note that I haven't tried any mass subscriptions. When we upgraded from > mailman 2 to mailman 3, we used the old .pck files and ran the import on > each of the lists. It did take about 6 weeks to do the full import all > 33,000 lists. I'm not joking. > > As for sending messages - there isn't any problem sending that many > messages out, but then we are also not trying to subscribe list members at > the time. We are, though, in the process of importing the old archives from > our old mailman 2 system. This doesn't seem to affect the rest of the > system. > > We have seen some inefficiencies in the new system, such as the front page > of postorius - loading all of the information for 200 lists (if the user > set the "lists per page" to 200) was bringing down the system. We have our > own metadata system to be able to search for lists by state/region/surname > (ours is a genealogy mailing list system), so we had to replace the front > page with our own "find a list" functionality. > > The other main problem was the page where a user can see what lists they > subscribe to. That page was also a denial of service if the user had > several hundred lists they are subscribed to. And for a genealogy mailing > list system, this is common. > > We have actually ended up creating our own API layer (only accessible on > the local machine) and make certain calls to it for the most painful of the > issues. One of these days (when we get a moment to breathe) we are going to > post some of our changes to the project so that we can ditch our own API > and just use the internal REST API. > > To be fair, the inefficiencies are not necessarily with mailman or the rest > API itself - but with Postorius making hundreds of calls to load a single > page. Though if the API supported loading multiple lists at once instead of > having to load them serially, that might help as well. > > So while we have not seen any timeout issues on the call to mass subscribe > users, we HAVE found several other calls that are effectively a denial of > service and have gotten around them ourselves, with plans to contribute to > the project in the near future. > > -Darren > > >> On Tue, Apr 24, 2018 at 8:47 AM, Mark Sapiro <mark(a)msapiro.net> wrote: >> >>> On 04/24/2018 12:36 AM, Abhilash Raj wrote: >>> On Mon, Apr 23, 2018, at 10:41 PM, Jonas Felber wrote: >> >>>> We also have a problem with sending out emails to "large" (>50) groups, >>>> as they seem to not getting sent out at all. Do you have any idea what >>>> the problem here could be? >>> >>> Which MTA are you using? What do you see in mailman's logs and MTA's >> logs? >>> >>> I haven't seen this kind of problem before with Mailman 3. This very >> list is hosted using Mailman 3 and I believe has more than 50 subscribers. >> >> >> Nor have I seen this issue. This list currently has 158 non-digest >> members. There are several @python.org Mailman 3 lists with over 100 >> non-digest members including the active yt-users(a)python.org list with >> 301 members, and I have gotten no reports of an issue like this. >> >> Also, there are over 600 lists at <https://lists.fedoraproject.org/>, >> and I don't think this is an issue there either. >> >> -- >> 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/ >> > _______________________________________________ > Mailman-users mailing list > mailman-users(a)mailman3.org > https://lists.mailman3.org/mailman3/lists/mailman-users.mailman3.org/ >

8 years, 1 month

[MM3-users] Re: How to strip DKIM headers on a domain level or a list level

by Mark Dadgar

On Nov 23, 2020, at 8:00 PM, Joel Lord <jpl(a)ilk.org> wrote: > On 11/23/2020 10:48 PM, Mark Sapiro wrote: >> On 11/23/20 7:22 PM, Mark Dadgar wrote: >>> >>> I also believe that it’s common for unsophisticated users to just start marking list emails as spam stop seeing them instead of figuring out how to unsubscribe. Which really sucks for everyone else. >> Several servers I'm involved with managing are subscribed to Yahoo's >> feedback loop (go to https://help.yahoo.com/kb/postmaster and select >> "Complaint Feedback Loop"). Reporting list mail as spam is one way to >> get quickly removed from a list. However, this is a bit complicated >> because the "report spam" button in Yahoo's web mail UI is right next to >> the "delete" button, so some reports are accidents. > > I've done the same thing, but Yahoo is pretty good at sanitizing their report to make it difficult to impossible to tell who actually needs to get ejected. I added "Sent to %(user_name)s at %(user_address)s" to the footer and while they'd generally get the user_address wiped out, the user_name would generally survive. > > And because Yahoo's UI is flawed as Mark pointed out, with the delete and spam buttons adjacent, I'd usually give people a couple chances before I'd airlock them. Yeah, I’ve been subscribed to the Yahoo feedback loops for ever and ever. If you’ve got verp turned on, you can decode the original address from that in the headers. - Mark ----- mark(a)pdc-racing.net | 408-348-2878

5 years, 6 months

[MM3-users] Re: mailman3 not working for mailman21 lists

by Diana von Bidder

Hi Stephen On Mon, 2022-08-22 at 23:51 +0900, Stephen J. Turnbull wrote: > blup(a)fortytwo.ch writes: > > Try queue/, especially look for the out[going], pipeline, and shunt > subdirectories. I have several entries in /var/lib/mailman3/queue/shunt/ with Aug 21 timestamps, and several entries in /var/lib/mailman3/queue/shunt/ with current timestamp (i.e. everytime I ls -l there is a new timestamp with the current time). > > > Is the 'outgoing' qrunner still running? (ps ax | grep outgoing) > > > > no > > Sorry, I got that wrong. Mark recommends this: > > ps -fwwA|grep runner=|sed s/.*runner=// > > and gave this as sample output: [..] My output looks exactly the same. > > I have more or less no Python knowledge (i.e. I can read and > > understand Python but can't write it). Could you please give me > > detailed command by command instructions. Thanks. > > I'll take a look at it tomorrow, but I can't promise results until > the weekend if I can't write a script in 30 minutes. Normally Mark > Sapiro would handle this kind of thing, but he's offline for a couple > weeks so you've got me. My knowledge is mostly on the email > protocols side of things (Internet message format, authentication > protocols), not the internal processing. I'll do what I can, but if > I can't do it real quick it's probably going to take me several > hours, which I'm not going to have until the weekend. Having something by the weekend would be perfectly fine. Thanks for your time! Regards Diana

3 years, 9 months

[MM3-users] AttributeError: ,> 'ReopenableFileHandler' object has no attribute '_stream'

by David Newman

((reposting with correct subject line -- sorry!)) Greetings. I am attempting a complete Mailman 3 installation on a Debian 10 system that already runs Mailman 2, following this documentation: https://docs.mailman3.org/en/latest/install/virtualenv.html Even following this guide, I'd had a lot of issues with permissions, where directories and files were owned by list rather than mailman. After correcting those issues, I then got to the point of checking mailman3's status, and systemctl shows this error: Nov 19 20:09:57 [REDACTED] mailman[1463]: Error in atexit._run_exitfuncs: Nov 19 20:09:57 [REDACTED] mailman[1463]: Traceback (most recent call last): Nov 19 20:09:57 [REDACTED] mailman[1463]: File "/usr/lib/python3.7/logging/__init__.py", line 2038, in shutdown Nov 19 20:09:57 [REDACTED] mailman[1463]: h.flush() Nov 19 20:09:57 [REDACTED] mailman[1463]: File "/opt/mailman/venv/lib/python3.7/site-packages/mailman/core/logging.py", line 67, in flush Nov 19 20:09:57 [REDACTED] mailman[1463]: if self._stream: Nov 19 20:09:57 [REDACTED] mailman[1463]: AttributeError: 'ReopenableFileHandler' object has no attribute '_stream' There is an October 2019 thread on this error [1] but I think it's in a different context, where the OP already had mailman3 running, and was trying to migrate Mailman 2 lists. Also, regarding those permissions issues above, it matters which "layout" value is in /etc/mailman3/mailman.cfg. I'd tried "dev" because I saw a post from Mark Sapiro recommending that, but then mailman3 wanted me to create a bunch of directories under /etc, even though $var_dir was set to /var/lib/mailman3. Things seem to go better, except for the confusion between lists/mailman ownership, when I set layout to "debian", which was the default. Thanks in advance for clues on addressing the ReopenableFileHandler error above. dn [1] https://lists.mailman3.org/archives/list/mailman-users@mailman3.org/thread/…

4 years, 6 months

[MM3-users] Re: Broken web UI after upgrade

by Odhiambo Washington

On Fri, Dec 16, 2022 at 11:17 PM Mark Sapiro <mark(a)msapiro.net> wrote: > On 12/16/22 03:36, Odhiambo Washington wrote: > > > > I am probably getting closer to where the problem is. By looking at nginx > > error_log while access the site, I see that there are > > just two CSS files that are missing, as shown in the error lo here: > > https://pastebin.ubuntu.com/p/7wbwMgqMyS/ > > > > Question is - why is it specifically looking for these two files > > - /opt/mailman/mm/static/CACHE/css/output.93545e20bc30.css > > -/opt/mailman/mm/static/CACHE/css/output.e1f0c6022e8f.css > > > > Where are these files supposed to come from and why are they missing? > > I have looked at my current CACHE directory and compared with the backup > of > > the same site before upgrade and these files aren't the same either: > > They come from django admin `compress` which used files created by > django admin collectstatic. > When I run that, I did not even get any errors. > > I suggest you run > ``` > django-admin collectstatic --clear --noinput --verbosity 2 > The output is here: https://pastebin.ubuntu.com/p/qkR2bDYv3G/ > django-admin compress --verbosity 2 > The output of the above is here: https://pastebin.ubuntu.com/p/T7jQPrs3JX/ ``` > where `django-admin` is your django admin command. If this doesn't fix > the issue, perhaps the more verbose output will help find the issue. > If the above doesn't reveal anything substantial, then let me know and I can bump up the verbosity. -- Best regards, Odhiambo WASHINGTON, Nairobi,KE +254 7 3200 0004/+254 7 2274 3223 "Oh, the cruft.", egrep -v '^$|^.*#' ¯\_(ツ)_/¯ :-)

3 years, 5 months

[MM3-users] Re: Held messages: Long time waiating for response of the Mailman API

by Jacob Sievert

Hello, we seem to have the same problem right now. We are still on python3.6 and postgresql 12.9 I looked at our Table pendedkeyvalue and we have roughly 35k rows in that table, is that normal or shouldn't those get cleaned up after a while? with regards Jacob On 2022-01-28 15:57, Stephan Krinetzki wrote: > Stephen J. Turnbull wrote: >> Mark Sapiro writes: >> > mailmancore/API ->database >> > that seems to have an issue and only with this one >> > DELETE FROM pendedkeyvalue WHERE pendedkeyvalue.id = XXX >> > query. However, like you, I have no idea as to what you could do further >> > to debug this. >> > I have an idea, but it seems so obvious that presumably it's already >> been tried: log in to the database as mailman with pgsql and try >> deleting something. If that works immediately, try with mailmanclient >> and the mailman command line utility. >> Steve > > Well, we didn't try this. Since we don't know what the query for > deleting a held message in the database needs to look like, we left > that out for now. If someone can help me there, it would be great. > > Over the mailman shell it hangs as long as on the web ui (using > mailman shell -l list@host and iterating over the held messages). So > it is the communication Mailman API <-> Database. > _______________________________________________ > 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/

4 years, 3 months

[MM3-users] Re: Where to find disabled members?

by Bill Oliver

On Mon, 2024-11-04 at 22:36 -0800, Mark Sapiro wrote: > On 11/4/24 19:28, Bill Oliver wrote: > > > > a) See who is disabled, and > > b) un-disable them by hand > > > > or... do I just have to wait seven days for them to automatically > > get > > un-disabled? > > They do not get automatically re-enabled ever the user or you has to > manually re-enable delivery. > > For an individual user, in Postorius you can click the user in the > members list and see their delivery status and reset it. > > To deal with the whole list membership for a list, you can do > ``` > $ 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 > >>> for member in m.members.members: > ... if member.delivery_status == DeliveryStatus.by_bounces: > ... member.preferences.delivery_status = > DeliveryStatus.enabled > ... > >>> commit() > >>> > ``` > If you just want to list them > ``` > >>> for member in m.members.members: > ... if member.delivery_status == DeliveryStatus.by_bounces: > ... print(member) > ... > >>>``` > Thank you. It worked like magic. Looks like I've got some learnin' to do with respect to the cli. I've never played with it beyond the commands indicated for installation. It looks like a great way to manage things. I much prefer a cli to gui for most of this kind of thing. billo

1 year, 6 months

Search results for query "sapiro"