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

[MM3-users] Re: list footer questions

by Mark Sapiro

On 6/7/20 9:40 AM, kelly.close(a)lrewater.com wrote: > > So I have a template file here: > /var/lib/mailman3/templates/lists/f2p2-test.udfcd-lists.org/en/list:member:regular:footer.txt > > I had to create everything below templates/ as that folder was empty on install. I made sure what I created had the same permissions as the templates folder. I'm not sure what else to do. Is there a configuration file somewhere perhaps the identifies the path of the templates folder and maybe I need to adjust it? There are two things. One is the location of the `templates/` directory. That is located in `$var_dir` and the value of that depends on the settings for ``` [mailman] layout: ``` and ``` [paths.<layout_value>] var_dir: ``` in mailman.cfg. I'm not certain, but I think `/var/lib/mailman3/` is correct for the Debian/Ubuntu package. The other thing that affects this is the value of the URI for the template in the database. This is somewhat tricky. The docs are at <https://docs.mailman3.org/projects/mailman/en/latest/src/mailman/rest/docs/…>, but there isn't an example of retrieving URIs via REST. I.e. something like ``` curl -urestadmin:restpass http://localhost:8001/3.1/lists/f2p2-test.udfcd-lists.org/uris ``` should work, but returns a 404 when I try it on one of my lists that has a URI. I look in mailman's database with a query like ``` select name, context, uri from template; ``` What you are looking for is a row with `name` = `list:member:regular:footer` and `context` = `f2p2-test.udfcd-lists.org`. If there is one and it has a uri other than `mailman:///$listname/$language/list:member:regular:footer.txt` then Mailman will look there for the template. -- 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: Enable delivery

by Mark Sapiro

On 12/10/24 10:43, Hirayama, Pat wrote: > Apologies, I should've said my "Mailman 3" server, not listserv. > > MTA logs do not show messages being sent to the member(s) in question, even though other members are being sent messages. Nothing out of the mailman server, and nothing received by our outbound Postfix MTAs. > > As for the CLI commands, I keep getting Attribute Error when I try them, like: > > /opt/mailman # mailman shell -l listname(a)mailman.tld > 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 listname(a)mailman.tld mailing list >>>> from mailman.core.constants import system_preferences >>>> mbr = m.members.get_member('user(a)domain.com.') >>>> print(mbr.delivery_status) > Traceback (most recent call last): > File "<console>", line 1, in <module> > AttributeError: 'NoneType' object has no attribute 'delivery_status' Are you literally typing mbr = m.members.get_member('user(a)domain.com.') That needs to be an actual list member's email without a trailing period. The fact that mbr is None means whatever you provided is not a member of the listname(a)mailman.tld list. Curious that the member(s) in question are not amongst the recipients delivered to the MTA even though >> when I run: >> >> mailman members --nomail any listname@listserv >> >> Nothing is returned. This should only happen if the members are digest members (are they) or are directly addressed in To: or Cc: of the post. -- Mark Sapiro <mark(a)msapiro.net> The highway is for gamblers, San Francisco Bay Area, California better use your sense - B. Dylan

1 year, 6 months

[MM3-users] Re: nginx configuration on a multitasking server

by Mark Sapiro

On 12/23/21 9:57 AM, David Newman wrote: > > The task-pending message that MM3 sends to list owners and moderators > just says generically to check the dashboard, without providing a URL. > > Can that be modified to provide an explicit URL, something like this? > > https://lists.example.com/mailman3/lists/listname Yes, That particular message is built from the list:admin:action:post template. You may wish to make custom versions of that and other templates. The templates and their default values are at https://gitlab.com/mailman/mailman/-/tree/master/src/mailman/templates/en You can make custom versions of templates in two ways. You can create if necessary a /opt/mailman/mm/var/templates directory (it probably already exists). Within that directory, sitewide English templates are put in the site/en/ directory, domain specific English templates are put in the domains/<domain_name>/en/ directory and list specific English templates are put in the lists/<list_id>/en/ directory. For templates like this, you probably want sitewide ones. E.g., site/en/list:admin:action:post.txt --------------------------------------------------------------- As list administrator, your authorization is requested for the following mailing list posting: List: $listname From: $sender_email Subject: $subject The message is being held because: $reasons At your convenience, visit https://lists.example.com/mailman3/lists/$list_id/held_messages to approve or deny the request. --------------------------------------------------------------- The other way to create custom templates is via Postotrius, but Postorius only creates list and domain specific templates. Also, if you create a template in Postorius, it overrides any in /opt/mailman/mm/var/templates/ until you delete it in Postorius. Info about templates and what substitution variables can be used is at https://docs.mailman3.org/projects/mailman/en/latest/src/mailman/rest/docs/… -- Mark Sapiro <mark(a)msapiro.net> The highway is for gamblers, San Francisco Bay Area, California better use your sense - B. Dylan

4 years, 6 months

[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

1 year, 5 months

[MM3-users] Re: Confirmation emails aren't sent to users.

by Ibiam Chihurumnaya

Mark Sapiro wrote: > On 2/13/26 05:41, Ibiam Chihurumnaya via Mailman-users wrote: > > Mark Sapiro wrote: > > OK, this is Django. The default EMAIL_BACKEND from > > mailman_web/settings/base.py is > > django.core.mail.backends.smtp.EmailBackend and unless you've changed > > that or added overrides various other defaults are > > EMAIL_HOST = "localhost" > > EMAIL_PORT = 25 > > EMAIL_HOST_USER = "" > > EMAIL_HOST_PASSWORD = "" > > EMAIL_USE_TLS = False > > EMAIL_USE_SSL = False > > EMAIL_SSL_CERTFILE = None > > EMAIL_SSL_KEYFILE = None > > Are those appropriate? Do you have an outgoing MTA listening on > > localhost:25? What's in it's logs? > > I don't have any of those set, didn't realize I needed to have them set, the docs didn't make it obvious too. > > I also didn't notice them in schema.cfg in mailman. > > You normally don't need to set any of those. The defaults should be fine > for a local MTA listening on port 25, however what's in /etc/hosts for > localhost. If it's the IPv6 address ::1, I suggest changing it to 127.0.0.1. Yes, I did change it after you'd said so in the other thread. > > smtp_port is currently set to 25, and I do have an outgoing MTA listening on localhost:25. > > Nothing shows up in the MTA logs about this particular email. > > Again, whats the address for localhost in /etc/hosts? I changed it to 127.0.0.1 after you said so in the last thread. > -- > Mark Sapiro <mark(a)msapiro.net> The highway is for gamblers, > San Francisco Bay Area, California better use your sense - B. Dylan

4 months, 1 week

[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

1 year, 4 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

4 years, 5 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

3 years, 2 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, 7 months

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

Search results for query "sapiro"