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

[MM3-users] Re: Mailing list welcome message won't update

by Mark Sapiro

On 1/15/25 14:29, via Mailman-users wrote: > Thanks Stephen and Mark. > > I checked whether group and world have 'x' permission on every directory in the path to the files and found below: > > root@lists:/var/lib/mailman3/templates# ll > total 12 > drwxr-xr-x 3 list list 4096 Oct 10 2018 ./ > drwxr-xr-x 12 list list 4096 Jan 9 05:08 ../ > drwxr--r-- 5 list list 4096 Mar 30 2021 lists/ > > > root@lists:/var/lib/mailman3/templates# cd lists/ > root@lists:/var/lib/mailman3/templates/lists# ll > total 20 > drwxr--r-- 5 list list 4096 Mar 30 2021 ./ > drwxr-xr-x 3 list list 4096 Oct 10 2018 ../ > drwxr--r-- 3 list list 4096 Jan 8 01:14 [redacted].lists.[redacted].org.au/ > > > root@lists:/var/lib/mailman3/templates/lists# cd p[redacted].lists.[redacted].org.au/ > root@lists:/var/lib/mailman3/templates/lists/[redacted].lists.[redacted].org.au# ll > total 12 > drwxr--r-- 3 list list 4096 Jan 8 01:14 ./ > drwxr--r-- 5 list list 4096 Mar 30 2021 ../ > drwxr--r-- 2 list list 4096 Jan 15 04:45 en/ > > So, group and world did not have 'x' permission to all the superordinate directories. I don't think that matters. As long as everything is running as user `list`. How are you testing. Are you running a `mailman` command and if so, are you running that as user `list`. Note that `mailman` commands should only ever be run as the Mailman user, `list` in your case. If that explains the issue, fine. Otherwise this seems to be an issue with the Debian package and should be reported to Debian. See https://wiki.list.org/x/12812344 -- Mark Sapiro <mark(a)msapiro.net> The highway is for gamblers, San Francisco Bay Area, California better use your sense - B. Dylan

10 months, 4 weeks

[MM3-users] Re: Filter question

by Mark Sapiro

On 2/7/25 17:32, Chris via Mailman-users wrote: > List has "filter content" set. > Filter Mime-Type [] > Filter Extensions exe bat cmd com pif scr vbs cpl > Accept Mime Media Types > > multipart > message/rfc822 > text/plain > text/html > application/pdf > application/nappdf > application/x-pdf > application/rtf > application/vnd.oasis.opendocument.spreadsheet > application/vnd.openxmlformats-officedocument.spreadsheetml.sheet > application/vnd.ms-excel > application/vnd.oasis.opendocument.text > application/vnd.openxmlformats-officedocument.wordprocessingml.document > application/msword > > Allow Extensions .zip .7z > > > Reduce Alternative No > Convert to Plain-Text No > > > > Now I'm sending an Message from outlook (html) with Inline Images. > Content Filter off: Works fine > Conent Filter On,: All except the image ist fine. The image gets lost and only a placeholder is shown > > > <img data-cid="image001.png(a)01D65210.566F56E0" height="51" id="Grafik_x0020_1" src="../../attachment/view/tmai1738975737149948386/aW1hZ2UwMDEucG5nQDAxRDY1MjEwLjU2NkY1NkUw;jsessionid=03FDBB0F16AFB10F7439822AB2C59450-n4.bap20a" style="width: 3.3437in;height: 0.5312in;" width="321"> This is removed because you don't have image/png in accept mime types. If you want to accept images, you should probably add just the `image` main type to accept mime types. > Even if MimeTypes filter is [] signature (p7s) gets filtered. > Any hint? To accept these, add application/x-pkcs7-signature application/pkcs7-signature and you may also want to add application/pgp-signature When accept mime types is non-empty, only those types will be accepted. Filtering on extensions only applies to mime parts with a filename parameter and again, if Allow Extensions is non-empty, only those filename extensions will be accepted. See https://gitlab.com/mailman/mailman/-/blob/master/src/mailman/handlers/mime_… -- Mark Sapiro <mark(a)msapiro.net> The highway is for gamblers, San Francisco Bay Area, California better use your sense - B. Dylan

10 months

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

by Mark Sapiro

On 1/18/22 06:24, Stephan Krinetzki wrote: > Hello, > > We are using Mailman 3.3.5 with Hyperkitty 1.3.5. Mailman 3 is installed in a venv and deployed using Apache and uwsgi. This works quite well so far, only withheld messages cause us a problem: If we try to approve them via Postorius, the message is delivered to the list immediately, but the success message in Postorius takes a long time - on average the process hangs for three minutes until the message is no longer displayed. We have already adjusted the timeout in gunicorn.cfg, but this does not improve the situation. Are there any tips on how we can speed up the REST API? Or is it even a configuration error? There are two steps in handling the POST for a held message. The first step is accepting, rejecting or discarding the message. This is happening immediately. The second step is handling the poster's moderation action based on the choice from the Set member moderation dropdown in the view of the held message. This is processed by the code at <https://gitlab.com/mailman/postorius/-/blob/master/src/postorius/views/list…>. If no selection has been made, the default value POSTed for moderation_choice is `no-action` and that code is skipped. If it is one of the choices `Hold for moderation`, `Reject (with notification)`, `Discard (no notification)`, `Accept immediately (bypass other rules)` or `Default processing` that is processed. So presumably a selection has been made and processing is stuck on getting the member or setting the member's moderation action. Possibly the logs of your database manager will have information. -- Mark Sapiro <mark(a)msapiro.net> The highway is for gamblers, San Francisco Bay Area, California better use your sense - B. Dylan

3 years, 10 months

[MM3-users] Re: REST API http://.../3.1/users/../preferred_address returns 404 for GET and POST

by Mark Sapiro

On 4/13/23 13:21, Eric Vyncke wrote: > Humm after some more investigations, it seems that my mailman3 installation via debian packages is completely mixed up :-( This would explain the issue if the REST API is using 3.2.2 code and postorius is expecting 3.3.5... > > drwxr-xr-x 29 root root 4096 Nov 18 2021 /usr/lib/python3/dist-packages/mailman > drwxr-xr-x 2 root root 4096 Nov 18 2021 /usr/lib/python3/dist-packages/mailman-3.2.2.egg-info > drwxr-xr-x 8 root root 4096 Nov 18 2021 /usr/lib/python3/dist-packages/mailmanclient > drwxr-xr-x 2 root root 4096 Nov 18 2021 /usr/lib/python3/dist-packages/mailmanclient-3.2.2.egg-info > drwxr-xr-x 4 root root 4096 Apr 13 14:29 /usr/lib/python3/dist-packages/mailman_hyperkitty > drwxr-xr-x 2 root root 4096 Apr 13 14:28 /usr/lib/python3/dist-packages/mailman_hyperkitty-1.1.0.egg-info > drwxr-sr-x 30 root staff 4096 Apr 13 09:32 /usr/local/lib/python3.8/dist-packages/mailman > drwxr-sr-x 2 root staff 4096 Nov 18 2021 /usr/local/lib/python3.8/dist-packages/mailman-3.3.5.dist-info > drwxr-sr-x 9 root staff 4096 Nov 18 2021 /usr/local/lib/python3.8/dist-packages/mailmanclient > drwxr-sr-x 2 root staff 4096 Nov 18 2021 /usr/local/lib/python3.8/dist-packages/mailmanclient-3.3.3.dist-info > drwxr-sr-x 4 root staff 4096 Apr 12 20:47 /usr/local/lib/python3.8/dist-packages/mailman_web > drwxr-sr-x 2 root staff 4096 Nov 18 2021 /usr/local/lib/python3.8/dist-packages/mailman_web-0.0.5.dist-info Yes, that would be the problem if the Python running Mailman core was using libraries in /usr/lib/python3/dist-packages/ and the Python running Django was using libraries in /usr/local/lib/python3.8/dist-packages/. The ability to get/set preferred_address via REST was added to Mailman core 3.3.0 and is not in 3.2.2. -- 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: MM2.1 -> MM3.3 migration. To hold or not hold

by Mark Sapiro

On 11/16/24 21:41, mark(a)suburbia.org.au wrote: > > When I add new members through Mass operations -> Mass subscribe, the new members have a Moderation Action of `None`. Correct. > I've looked through the archives of this list, and from what I can tell: > > According to https://lists.mailman3.org/archives/list/mailman-users@mailman3.org/message… > >> None does not mean no moderation. None means use the list default >> as opposed to one of the specific actions defined > > The thread at https://lists.mailman3.org/archives/list/mailman-users@mailman3.org/thread/… seems to also repeat the above, that `none` means the configured setting for the list. > > However, I've just done a test of a newly added user (a test email account for me), seen that the Moderation Action is `None`, but when I posted to the list from the address, it was not held for moderation, and went through. > > Am I missing something with the expected functionality? A member's moderation action of None means use the `Default action to take when a member posts to the list`. Is that set to `Hold for moderation`? Actually, it is good practice to set that to `Hold for moderation` for all lists or at least all those that don't require moderator approval for subscription to prevent a spammer from subscribing and spamming the list. Then, upon approving a member's post you can also set the member's moderation action to `default processing` and upon discarding a spammers post, you can also set the spammer's moderation action to `Discard`. -- Mark Sapiro <mark(a)msapiro.net> The highway is for gamblers, San Francisco Bay Area, California better use your sense - B. Dylan

1 year

[MM3-users] Re: Is it possible to grant all users the ability to Create List

by Mark Sapiro

On 7/12/21 8:25 AM, tibor.molnar(a)waltoninstitute.ie wrote: > Hi, > > I would like to know if anyone have implemented this feature or used any workaround to be able to grant users with the ability to create list. This has been a feature in mailman2 where you as a user were able to create list with a password and you did not need to be a superuser in order to do that. I do understand that in the development documentation it states the following: Three of Django’s default User roles are relevant for Postorius: > > Superuser: Can do everything. > AnonymousUser: Can view list index and info pages. > Authenticated users: Can view list index and info pages. Can (un)subscribe from lists. > > Can we maybe add a different user role where the user would be able to create lists? If this is possible would anyone let me know how? The user's `role` is a Django thing. A user can be given either `staff` or `superuser` status or both or neither. As far as Django is concerned, `staff` status only allows the user to visit the Django administration interface. Currently, Postorius has decorators @list_owner_required, @list_moderator_required and @superuser_required defined in postorius/auth/decorators.py. There is also a @login_required decorator in django.contrib.auth.decorators. Postorius decorates the list_new() function in postorius/views/list.py with @login_required and @superuser_required. It would be simple enough to create a new @staff_required decorator which would require staff or superuser status and replace the @superuser_required decorator on the list_new() function with @staff_required. Then any user with `staff` status could create lists. -- Mark Sapiro <mark(a)msapiro.net> The highway is for gamblers, San Francisco Bay Area, California better use your sense - B. Dylan

4 years, 5 months

[MM3-users] Re: Postorius is not working (throws "Error 500" suddenly after changing POSTORIUS_TEMPLATE_BASE_URL and changing back)

by Mark Sapiro

On 9/30/23 15:23, Wikinaut wrote: > After having changed and re-changed "only" the line in /etc/mailman3/mailman-web.py (which looks to be only a "blinder" and the real problem could be a different one) > > POSTORIUS_TEMPLATE_BASE_URL = 'http://localhost/mailman3/' This should not include the mailman3/ path. If http://localhost/mailman3/ gets to Postorius, it should just be 'http://localhost/'. > the web access via Postorius is not working any more and throws "Error 500" > > My logfile /var/log/mailman3/web/mailman-web.log shows now > ...> from django.utils.encoding import force_bytes, force_str, force_text > ImportError: cannot import name 'force_text' from 'django.utils.encoding' (/usr/local/lib/python3.9/dist-packages/django/utils/encoding.py) > > I already run pip install -U postorius to update that (looks okay to me): > > Requirement already satisfied: postorius in /usr/local/lib/python3.9/dist-packages (1.3.8) ... > Requirement already satisfied: django<4.2,>=3.2 in /usr/local/lib/python3.9/dist-packages (from postorius) (4.1.9) ... > dpkg -l | grep django > ii python3-django 2:2.2.28-1~deb11u2 all High-level Python web development framework Something is confused here. Your Django version from dpkg is 2.2.28, bit from your above `pip install`, it is 4.1.9. I'm not sure haw the Debian package installs, but probably in a venv. > ii python3-django-q 1.2.1-1 all Django multiprocessing distributed task queue (Python 3 version) I don't know what the django-q version in the venv is, but Django >=4.0 requires django-q >=1.3.0 If The Debian backage includes Django>=4.0 and django-q<1.3.0, it's a Debian packaging issue. -- Mark Sapiro <mark(a)msapiro.net> The highway is for gamblers, San Francisco Bay Area, California better use your sense - B. Dylan

2 years, 2 months

[MM3-users] Re: (venv) mailman-web migrate (as explained) fails with "django.core.exceptions.ImproperlyConfigured: allauth.account.middleware.AccountMiddleware must be added to settings.MIDDLEWARE"

by Mark Sapiro

On 10/19/23 12:12, Eggert Ehmke via Mailman-users wrote: > Hello Mark, > > I am also using MySql/MariaDb, I followed your suggestion. This would uninstall a lot of > other packages, is that safe? I did not continue. > > > $ pip uninstall psycopg2_binary > Found existing installation: psycopg2-binary 2.9.6 > Uninstalling psycopg2-binary-2.9.6: > Would remove: > /opt/mailman/venv/lib/python3.11/site-packages/psycopg2/* > /opt/mailman/venv/lib/python3.11/site-packages/psycopg2_binary-2.9.6.dist-info/* > /opt/mailman/venv/lib/python3.11/site-packages/psycopg2_binary.libs/ > libcom_err-2abe824b.so.2.1 > /opt/mailman/venv/lib/python3.11/site-packages/psycopg2_binary.libs/ > libcrypto-2cd0ac56.so.1.1 > /opt/mailman/venv/lib/python3.11/site-packages/psycopg2_binary.libs/ > libgssapi_krb5-497db0c6.so.2.2 > /opt/mailman/venv/lib/python3.11/site-packages/psycopg2_binary.libs/libk5crypto- > b1f99d5c.so.3.1 > /opt/mailman/venv/lib/python3.11/site-packages/psycopg2_binary.libs/libkeyutils- > dfe70bd6.so.1.5 > /opt/mailman/venv/lib/python3.11/site-packages/psycopg2_binary.libs/libkrb5- > fcafa220.so.3.3 > /opt/mailman/venv/lib/python3.11/site-packages/psycopg2_binary.libs/libkrb5support- > d0bcff84.so.0.1 > /opt/mailman/venv/lib/python3.11/site-packages/psycopg2_binary.libs/ > liblber-69811697.so.2.0.200 > /opt/mailman/venv/lib/python3.11/site-packages/psycopg2_binary.libs/libldap- > e7812872.so.2.0.200 > /opt/mailman/venv/lib/python3.11/site-packages/psycopg2_binary.libs/ > libpcre-9513aab5.so.1.2.0 > /opt/mailman/venv/lib/python3.11/site-packages/psycopg2_binary.libs/ > libpq-227f62f1.so.5.15 > /opt/mailman/venv/lib/python3.11/site-packages/psycopg2_binary.libs/ > libsasl2-883649fd.so.3.0.0 > /opt/mailman/venv/lib/python3.11/site-packages/psycopg2_binary.libs/ > libselinux-0922c95c.so.1 > /opt/mailman/venv/lib/python3.11/site-packages/psycopg2_binary.libs/ > libssl-0331cfe8.so.1.1 > Proceed (Y/n)? n Yes, it is safe. the things listed other than psycopg2/* are just installation information about psycopg2_binary. No other packages are actually involved. -- Mark Sapiro <mark(a)msapiro.net> The highway is for gamblers, San Francisco Bay Area, California better use your sense - B. Dylan

2 years, 1 month

[MM3-users] Re: File "/usr/lib/python2.7/httplib.py", line 1148, in getresponse raise ResponseNotReady()

by Mark Sapiro

On 10/2/20 2:58 PM, Alex Schuilenburg via Mailman-users wrote: > > I ran both on the original archive, cleanarch made no changes and > check_hk_import just retported the number of messages. That's actually expected with this mbox as there are apparantly no unescaped `From ` lines in the message body and no other serious defects. > As it turns out, the message was imported, but with the dodgy email as > sender which was fixed by the insert/update as per my comment. > > Hope you have some success with the redacted mbox example. As I mention at <https://gitlab.com/mailman/hyperkitty/-/issues/320#note_422998204> I imported the mbox to a test list, and there were noe real issues. What issue there is is the mbox message's actual From: header is ``` From: Firstname Surname at example-UK <user(a)example.com> ``` Part of what's going on is some MM 2.1 archives has email addresses obfuscated by replacing `@` with ` at ` so the import process reverses this and changes the From: to header is ``` From: Firstname Surname@example-UK <user(a)example.com> ``` which now contains two email addresses albeit not separated by a comma and picks the first. The message then gets properly archived with sender `Firstname Surname@example-UK` which is a syntactically valid email address and doesn't cause the ResponseNotReady() exception in sync_mailman so I don't see that issue. The difference is either the fact that my test runs with the HEAD of the GitLab branch which may not have the issue or the difference between the real From: header and the sanitized one is significant. -- 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: Hyperkitty list overview error: thread matching query does not exist

by Mark Sapiro

On 5/23/22 11:11, Darren Hart via Mailman-users wrote: > When attempting to visit the hyperkitty archives list overview for one of my two lists: > > Https://lists.mydomain.com/hyperkitty/list/mylist@mydomain.com/ > > The area where the threads should appear shows the loading spinner (but the activity summary bar chart and most active posters post counts do eventually load). > > The following appears in /var/log/mailman3/web/mailman-web.log: > > > ERROR 2022-05-23 17:50:50,201 1694 django.request Internal Server Error: /hyperkitty/list/mylist(a)mydomain.com/posted-to > Traceback (most recent call last): ... > File "/usr/lib/python3/dist-packages/django/db/models/query.py", line 406, in get > raise self.model.DoesNotExist( > hyperkitty.models.thread.Thread.DoesNotExist: Thread matching query does not exist. > > Viewing “All Threads” or Threads by month (any month) work as expected, displaying the appropriate threads. > > The archives for this list worked previously. There was an incident that resulted in DNS not working and the archiver failing for a few days. The mail that came in during that time does show up in the other views. > > The hyper kitty archives for a second list on this Mailman3 instance is working correctly. > > How can I fix this view of the archives? Or how can I get more information on what might be failing? I'm not sure if this will help, but try running your django management command with arguments `runjob recent_threads_cache`. Note that this will be run daily if you are running the Cron Jobs for Mailman Web. See https://docs.mailman3.org/en/latest/install/virtualenv.html?highlight=perio… -- 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

Search results for query "sapiro"