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

[MM3-users] Re: Moderation not working?

by peter＠chubb.wattle.id.au

>>>>> "Mark" == Mark Sapiro <mark(a)msapiro.net> writes: Mark> On 11/24/20 12:30 PM, peter(a)chubb.wattle.id.au wrote: >> >> Hi Folks, Running a shiny new instance of mailman3, as per the >> Debian package (version 3.2.2) but the moderation doesn't seem to >> work. WE got hit by a heap of spammers overnight, even though the >> 'hold for moderation' bit is set for non-members (and now for >> members too). Mark> If the action for member posts was accept ot default processing Mark> at the time, perhaps the spam spoofed a member address in one of Mark> From:, Reply-To:, Sender: or the envelope sender, Nope ... >> Emails seem just to get straight through. Mark> Even now with both member and non-member actions set to hold? Haven't seen any emails since setting that bit, so can't tell yet. The only think I noticed after trawling through all the configs is there was no moderator address set up. In Mailman 2.1 that meant the list owner would be asked to moderate. I've added a couple of addresses to see what happens next For other lists on the same mailman instance I *am* seeing moderation requests for non-member postings --- but they had explicit moderator addresses configured. Peter C

5 years

[MM3-users] Re: is there a mailman command/setting to periodically clean archives?

by David Newman

On 12/29/21 4:11 PM, Mark Sapiro wrote: > On 12/29/21 3:58 PM, William Oliver wrote: >> >> I'd like to delete all my archives that are more than a certain age, >> e.g. more than a week old. I can easily do that with a cron job, >> deleting old files in >> >> >> /opt/mailman/mm/var/archives/prototype/testlist(a)example.com/* >> >> which is, as far as I can see the only place archive emails live. > > > Those are emails archived in the prototype archiver. That's all the > prototype archiver does - store the mail there. The HyperKitty archived > emails are stored in the mailmanweb database in the hyperkitty_email > table. Attachments are in the hyperkitty_attachment table and other > tables are also involved. As a followup: Is there any need or advantage to running both the prototype and hyperkitty archivers? I did an installation following the venv directions, and it looks as though the system now uses both archivers. If this is a duplication of effort and storage, is it safe to disable the prototype archiver like this: # /etc/mailman3/mailman.cfg .. [archiver.prototype] enable: no and then delete anything under here? /opt/mailman/mm/var/archives/prototype/ Thanks dn

3 years, 11 months

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

by Odhiambo Washington

On Sat, Dec 17, 2022 at 9:59 AM Odhiambo Washington <odhiambo(a)gmail.com> wrote: > > > On Sat, Dec 17, 2022 at 9:33 AM Mark Sapiro <mark(a)msapiro.net> wrote: > >> On 12/16/22 22:21, Mark Sapiro wrote: >> > >> > I suggest you look at ownership and permissions. >> > >> > ``` >> > find /opt/mailman/mm/static/ -not -user mailman >> > find /opt/mailman/mm/static/ -not -perm -u+rw >> > find /opt/mailman/mm/static/ -type d -not -perm -u+x >> > ``` >> > and the same on >> > /opt/mailman/mm/venv/lib/python3.9/site-packages/hyperkitty/ >> > >> > >> >> If the above doesn't reveal anything substantial, then let me know and >> I >> >> can bump up the verbosity. >> > >> > >> > I don't know if --verbosity 3 will reveal anything or not. You could >> try. >> >> >> Did you see the post at >> < >> https://lists.mailman3.org/archives/list/mailman-users@mailman3.org/message…>? >> >> Have you tried >> ``` >> django-admin clear_cache >> > > (venv) mailman@list:~$ /opt/mailman/mm/bin/django-admin clear_cache > Cache "default" has been cleared! > (venv) mailman@list:~$ ls -al /opt/mailman/mm/static/CACHE/ > total 16 > drwxr-xr-x 4 mailman mailman 4096 Dec 16 22:01 . > drwxr-xr-x 9 mailman mailman 4096 Dec 4 06:38 .. > drwxr-xr-x 2 mailman mailman 4096 Dec 16 22:01 css > drwxr-xr-x 2 mailman mailman 4096 Dec 16 22:01 js > (venv) mailman@list:~$ ls -al /opt/mailman/mm/static/CACHE/css/ > total 8 > drwxr-xr-x 2 mailman mailman 4096 Dec 16 22:01 . > drwxr-xr-x 4 mailman mailman 4096 Dec 16 22:01 .. > (venv) mailman@list:~$ ls -al /opt/mailman/mm/static/CACHE/js/ > total 8 > drwxr-xr-x 2 mailman mailman 4096 Dec 16 22:01 . > drwxr-xr-x 4 mailman mailman 4096 Dec 16 22:01 .. > (venv) mailman@list:~$ > > So all the css files that were in /opt/mailman/mm/static/CACHE/css/ are > gone after running `django-admin clear_cache`. > > After that, I did run my mailman-post-update script again which created > dirfferent files under CACHE/css/ as the date shows > (venv) mailman@list:~$ ls -al /opt/mailman/mm/static/CACHE/ > total 20 > drwxr-xr-x 4 mailman mailman 4096 Dec 16 22:46 . > drwxr-xr-x 9 mailman mailman 4096 Dec 4 06:38 .. > drwxr-xr-x 2 mailman mailman 4096 Dec 16 22:46 css > drwxr-xr-x 2 mailman mailman 4096 Dec 16 22:46 js > -rw-r--r-- 1 mailman mailman 621 Dec 16 22:46 manifest.json > (venv) mailman@list:~$ ls -al /opt/mailman/mm/static/CACHE/css/ > total 176 > drwxr-xr-x 2 mailman mailman 4096 Dec 16 22:46 . > drwxr-xr-x 4 mailman mailman 4096 Dec 16 22:46 .. > -rw-r--r-- 1 mailman mailman 162923 Dec 16 22:46 output.1d3a3c0dd51d.css > -rw-r--r-- 1 mailman mailman 1209 Dec 16 22:46 output.9a7b11621c5a.css > -rw-r--r-- 1 mailman mailman 569 Dec 16 22:46 output.e68c4908b3de.css > (venv) mailman@list:~$ > > I then rebooted the system just to be sure everything is restarted. > > And the PROBLEM IS SOLVED :-) > > Thank you very much for your time spent in following this up with me to > the conclusion. > So just for the record, I have added the clear_cache option to the script. Maybe this will benefit someone else one day. <CUT> #!/bin/bash set -e BINDIR="/opt/mailman/mm/bin" CONFDIR="/opt/mailman/mm" SETTINGS="settings" DJANGO_CONTROL_SCRIPT="$BINDIR/django-admin" STATIC_DIR="$CONFDIR/static" DEBUG="False" set -x if [ "$DEBUG" == "False" ]; then mkdir -p "$STATIC_DIR" || : "$DJANGO_CONTROL_SCRIPT" clear_cache "$DJANGO_CONTROL_SCRIPT" collectstatic --clear --noinput --verbosity 0 "$DJANGO_CONTROL_SCRIPT" compress "$DJANGO_CONTROL_SCRIPT" compilemessages fi syncdb_cmd="$DJANGO_CONTROL_SCRIPT migrate" if [[ ! -t 1 ]]; then # stdout is not a terminal syncdb_cmd="$syncdb_cmd --noinput" fi $syncdb_cmd echo 'Do you want to rebuild the search index? This takes a long time.' echo 'Type "Yes" to continue; anything else to quit.' read -p "> " response if [ "x$response" != "xYes" ] ; then exit; fi "$DJANGO_CONTROL_SCRIPT" update_index </CUT> The important thing here is that after an update, it helps to run the following 4 options with your "django-admin" script (whatever it is named) - clear_cache, collectstatic, compress, compilemessages. -- Best regards, Odhiambo WASHINGTON, Nairobi,KE +254 7 3200 0004/+254 7 2274 3223 "Oh, the cruft.", egrep -v '^$|^.*#' ¯\_(ツ)_/¯ :-)

2 years, 11 months

[MM3-users] Fwd: Re: Removing a mail addresses and users

by Allan Hansen

All, This disconnect between Mailman Core and Django and Postorius is, by far, the weakest and, for subscribers, most confusing aspect of MM3 (once it has been installed, which is extremely hard and confusing). In a true account-centric system, you set up a web account and from there manage your emails and, for each email, your subscriptions. Subscription options would be hierarchical: account/email/list, with lower levels inheriting/overriding settings from/the level above. That’s really what I had expected when I pushed for us to move our 50 email lists to MM3 and I was very excited about the prospect, as it would solve a lot of system/subscriber management issues I had managing MM2. Alas, I was very surprised that that’s not how MM3 works. Some things got harder, even, such as the inability to change subscription addresses, which should have been a showstopper from the start! I still hope that MMxx OOTB will get there, but I guess it’ll be along haul. Would we be talking about MM4 to be released 20 years from now? Some dedicated and skilled developers are currently investing heavily in a replacement for Postorius, but I really believe that any work is better spent transforming Mailman Core etc. into a true account-based system. Then, and only then, will it make sense to build new and better interfaces on top, as, without a healthy core, such interface will currently may have to inherit the confusion and disconnect that currently is so aggravating. The above is not meant to aggravate the MM3 development team, for which I have utmost respect and gratitude, and which I admire for their tireless support given over decades to the community of admins. Software development is devilishly hard and time consuming. Yours, Allan Hansen hansen(a)rc.org > Begin forwarded message: > > From: Mark Sapiro <mark(a)msapiro.net> > Subject: [MM3-users] Re: Removing a mail addresses and users > Date: June 10, 2020 at 12:46:01 PDT > To: mailman-users(a)mailman3.org > > On 6/10/20 10:23 AM, Abhijith PA via Mailman-users wrote: >> Hello. >> >> I tried to remove random email address signing ups (which I signed up >> while testing) via admin panel. After removing I tried to sign up again, >> but I am getting, >> >> 'A user is already registered with this e-mail address' > > You removed the user's subscription from the list, but you didn't remove > the user from the system. > > Mailman3 has a concept of `user` which didn't exist in Mailman 2.1. > User's have addresses and a user or one of the user's addresses can > belong to a list with one or more roles (non-member, member, moderator > or owner) > > >> Combing through the database, I found auth_user table in mailman3web db >> still contain those mail address. How to wipe email address entirely >> from the db so I can signup again without the 'forget password' method > > There are a couple of things. If you log in to the web UI as a django > superuser, you can go to the django admin UI -> Users section and delete > the User, but I think that will only delete the web user and not delete > the user from Mailman core. > > You can also log in to the web UI as the user and go to > <https://lists.mailman3.org/user-profile/delete>, but that again only > deletes the web user, and if you could do that, you could just subscribe > once you're logged in, so I assume that's what you want to avoid. > > I don't think there is a way for a user as opposed to a site admin to > delete her user record from Mailman core and even for a site admin, > there's no way in Postorius to delete a user from core. It has to be > done via REST > <https://docs.mailman3.org/projects/mailman/en/latest/src/mailman/rest/docs/…> > or `mailman shell`. > > -- > 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 > To unsubscribe send an email to mailman-users-leave(a)mailman3.org > https://lists.mailman3.org/mailman3/lists/mailman-users.mailman3.org/

5 years, 6 months

[MM3-users] Re: Problem with list creation

by Abhilash Raj

On Thu, Sep 17, 2020, at 4:17 AM, Stephen J. Turnbull wrote: > Mark Sapiro writes: > > On 9/16/20 8:25 AM, Pawel Grzywaczewski wrote: > > > > We increased timeout in mailman.cfg > > This looks like the issue in Shashikanth's post, too: > https://lists.mailman3.org/archives/list/mailman-users@mailman3.org/message… > They are also creating more than 1000 lists. > > Do we know why these timeouts are happening? (Search for "list > creation times out" returns no results in either core or Postorius > issues.) This is the first time I am actually seeing this. I tried hammering a local server with default number of workers, 2, and created 5000 lists in a loop and went through pretty smooth. I am probably not replicating the exact situation, I am using the sqlite database (which I presumed would be slow and choke up faster but...it didn't). Creating list isn't one of the slow operations AFAIK, so I am actually surprised that it needs increasing timeout. It could be the interaction with database layer maybe, but I can't be sure without more debugging. > _______________________________________________ > 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/ > -- thanks, Abhilash Raj (maxking)

5 years, 2 months

[MM3-users] Re: New installation, new issue: mailman3 migrate -- no module CommonMark

by Bill Oliver

On Sun, 2024-10-27 at 10:01 -0700, Mark Sapiro wrote: > On 10/27/24 05:13, Bill Oliver wrote: > > > > (venv) mailman@mail:~$ pip freeze | grep readme > > readme-renderer==17.4 > > > Which is over 6 years old. Howat did that get installed? Current > version > is 44.0. There may or may not be an issue with the current version as > it > imports cmarkgfm which is in the venv of all the MM 3 installations I > support, but I don't know how it gets there as even though > readme_renderer imports it, it is not listed as required by > readme_renderer or anything else. > > In any case, in your venv, do > ``` > pip install --update readme_renderer cmarkgfm > ``` > That did the trick, though I had to use --upgrade instead of --update. Thanks... Now on to the next step. I don't know about the libraries. Here's my mailman info. It seems like the right version of python. (venv) mailman@mail:~$ mailman info GNU Mailman 3.3.10 (Tom Sawyer) Python 3.10.12 (main, Sep 11 2024, 15:47:36) [GCC 11.4.0] config file: /etc/mailman3/mailman.cfg db url: postgresql://mailman:qazASD%401cko@localhost/mailman devmode: DISABLED REST root url: http://localhost:8001/3.1/ REST credentials: restadmin:restpass Thanks for your help! billo

1 year, 1 month

[MM3-users] Re: Changes in Django admin interface are not syncing to postorius gui /database

by ulf.rapphahn＠offis.de

Mark Sapiro wrote: > Lists, not Mailman lists. When you create a list in Postorius or Mailman > core, this is a Mailman list. A corresponding HyperKitty list will also > be created if hyperkitty is one of the active archivers for the list so > you see it in Django. > When you create a list in Django, it is only a HyperKitty list and will > be visible in HyperKitty, but no Mailman list is created so the list is > not in Mailman/Postorius. Thank you (also for Odhiambo) Now remains one question: We have a (internal) Active Directory (AD) Authentication for Mailman3. So everyone who wants to work as an owner nor moderator must be an AD-User. In hyperkitty I am able to assign these list rights directly to AD-Loginnames. With the logic above I have to assign these rights in postorius too by assining the mail address of the users AD-Account? (I see no AD-Data here). Or would it works to assing the mail address of the users AD-Account first an then the allocation will automaticly synced to hyperkitty - maybe using the mail address as key? What would be the best practice for owner/moderator user management? Thank you!

1 year, 1 month

[MM3-users] Re: [Django] ERROR (EXTERNAL IP): Internal Server Error: /mailman3/lists/test2.***/settings/message_acceptance MultipleObjectsReturned .. get() returned more than one EmailAddress -- it returned 2!

by Marco Emilio Poleggi

Thanks, Mark. On 2025-09-01 19:40, Mark Sapiro wrote: > On 9/1/25 08:17, ^m'e via Mailman-users wrote: >> >> The same problem appeared today with my mariadb-based installation. @Mark, >> do you have a mysql version of your scripts? > > I'm not certain as I don't offhand have a way to test, but I think > > g/psycopg2/s//pymysql/ > > (i.e. just replace both occurrences of `psycopg2` with `pymysql`) will do it. > Yeah, it works! In my case, no uppercase addresses were found by the UC_fix script, whereas the Mult_primary did spot two accounts, both with 'staff status' in Django admin UI and with the same set of extra addresses. Most probably my fault, as I intended to use both accounts for administrative tasks and played to far with assigning the same sets of addresses, one of which was primary for one account. I guess that was causing the failure, right? -- ^m'e ___________________________________________ Mailman's content filtering has removed the following MIME parts from this message. Content-Type: application/pgp-keys Name: OpenPGP_0xC366FCF67CDBD9F9.asc

3 months, 1 week

[MM3-users] Re: Error: 451 Requested action aborted

by Hagen Bauer

On 16.11.18 00:41, Mark Sapiro wrote: > On 11/15/18 8:23 AM, Hagen Bauer wrote: >> Hi >> I am running mailman in docker and I start to receive this error when my >> postfix tries to deliver a mail >> >> said: 451 Requested action aborted: error in processing (in reply to end >> of DATA command)) >> >> Any idea what is going wrong and where to look for problems? > > > Is there more information in the Postfix mail.log? > > no, in postfix this is the only entry. But I believe I solved one problem and now have to work on the next one. First I saw this error in in a log file ERROR could not translate host name "database" to address: Name does not resolve Based on this hint https://github.com/moby/moby/issues/8425 adding external dns server made this message go away. Now I find this error in my logs. : ERROR: xlog flush request 0/1FA5640 is not satisfied --- flushed only to 0/1E9C7A0 CONTEXT: writing block 0 of relation base/16384/16525 I believe this is related to some sort of database corruption but since I have no idea about postgres I am not sure (I chose the docker images because I didnt want to care about the Internals) any suggestions are welcome

7 years

[MM3-users] Re: SUBSCRIBE_FORM_SECRET in MM3?

by Phil Stracchino

On 2020-01-30 12:01, Mark Sapiro wrote: > On 1/30/20 1:50 AM, Gila Halpern wrote: >> I've been looking into ways to prevent spam on my company's list, and one thing I came across was the SUBSCRIBE_FORM_SECRET option in the Mailman configuration, which embeds a CSRF token into the form, and prevents it from being submitted until five seconds after it renders, to keep bots from subscribing. Unfortunately, the information I found pertained to Mailman 2. Does this option exist in MM3 as well, or is there a similar option? > > > This feature in MM 2.1 is not very effective. On mail.python.org, this > feature as well as reCAPTCHA is enabled (e.g. > <https://mail.python.org/mailman/listinfo/mailman-users>) and we still > get periodic attacks of robotic subscribes that get around these measures. Human verification vs. verification-defeating countermeasures is an ongoing arms race which, frankly, humans have been losing for a long time. I have more than once commented, not entirely joking, that we're reaching a point where *FAILURE* to complete the CAPTCHA is evidence that you're a human. We need to come up with a better verification paradigm than presenting increasingly difficult puzzles which AI agents are better overall at solving than humans are. -- Phil Stracchino Babylon Communications phils(a)caerllewys.net phil(a)co.ordinate.org Landline: +1.603.293.8485 Mobile: +1.603.998.6958

5 years, 10 months

Search results for query "sapiro"