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

[MM3-users] Re: Permission denied for fulltext_index

by Mark Sapiro

On 11/27/22 00:35, Jan Eden via Mailman-users wrote: > > – but the existing directory /opt/mailman/fulltext_index (and its > contents) are readable and writeable by mailman:mailman: > >> drwxrwxr-x 2 mailman mailman 4096 Nov 27 08:00 fulltext_index/ >> >> -rw-rw-r-- 1 mailman mailman 4473 Nov 27 08:00 _MAIN_65.toc >> -rw-rw-r-- 1 mailman mailman 15456 Nov 27 08:00 MAIN_bc0cs2aohovftat6.seg >> -rw-rw-r-- 1 mailman mailman 15454 Nov 27 06:00 MAIN_brbo8i8edmlz0za4.seg >> -rw-rw-r-- 1 mailman mailman 15462 Nov 27 07:00 MAIN_ewnemc7lsnodd3y7.seg >> -rw-rw-r-- 1 mailman mailman 157324 Nov 27 04:00 MAIN_qag60g1rrumshtc2.seg >> -rw-rw-r-- 1 mailman mailman 15459 Nov 27 05:00 MAIN_w6e0ohurasusy61d.seg >> -rwxrwxr-x 1 mailman mailman 0 Nov 24 16:00 MAIN_WRITELOCK* > > I fail to see where haystack tries (and fails) to create the directory. > FWIW, deleting threads is not a problem. It is uwsgi trying to do this. What user is it running as? Maybe you need to add that user to the `mailman` group. Deleting threads is not an issue, apparently because it doesn't try to update the search index. -- 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: Odd behavior: notifications for list membership, etc. from "owner user" sent as "owner user"?

by Mark Sapiro

On 7/10/26 09:01, Thomas Ward via Mailman-users wrote: > > Upon deeper trackdown of this, our owner user mailman(a)example.com is > seeing messages sent to it from @lists.example.com and > @distro.example.com from mailman(a)example.com (despite the From in the > envelope being list-bounces+mailman=example.com(a)[lists|distro].example.com) These messages are sent to (envelope recipients) the list admins but with a To: header of `list-owner@...` and a From: header of the address configured as the site_owner in mailman.cfg. You can change the From: from the site owner address to the `list-owner@...` address with a patch like: ``` --- a/src/mailman/email/message.py +++ b/src/mailman/email/message.py @@ -237,10 +237,11 @@ class OwnerNotification(UserNotification): if roster is None: recipients = set([config.mailman.site_owner]) to = config.mailman.site_owner + sender = config.mailman.site_owner else: recipients = set(address.email for address in roster.addresses) to = mlist.owner_address - sender = config.mailman.site_owner + sender = mlist.owner_address super().__init__(recipients, sender, subject, text, mlist.preferred_language) # Envelope sender ``` -- Mark Sapiro <mark(a)msapiro.net> The highway is for gamblers, San Francisco Bay Area, California better use your sense - B. Dylan

3 months, 1 week

[MM3-users] Re: SMTPSenderRefused - howto enable STARTTLS for local mail drop

by Mark Sapiro

On 12/6/21 2:51 AM, Stefan Bauer wrote: > Need to bring this up again. Django now sends with STARTTLS, but mailman > itself, does still only drop mails in cleartext. > Dec 6 11:47:33 al01 postfix/lmtp[7598]: A6422600510: > to=<remote-party@remote>, relay=127.0.0.1[127.0.0.1]:8024, delay=0.01, > delays=0.01/0/0/0.01, dsn=2.0.0, status=sent (250 Ok) > Dec 6 11:47:33 al01 postfix/qmgr[29156]: A6422600510: removed > Dec 6 11:47:35 al01 postfix/smtpd[8092]: disconnect from localhost[::1] > ehlo=1 mail=2 rcpt=2 data=2 commands=7 > > No starttls=1 at all :( > > Does the above settings work for anyone? > > etc/mailman3/mailman.cfg > [mta] > incoming: mailman.mta.postfix.LMTP > outgoing: mailman.mta.deliver.deliver > > smtp_host: localhost > smtp_port: 25 > smtp_user: > smtp_pass: > smtp_verify_hostname: false > smtp_verify_cert: false > smtp_secure_mode: starttls This should work. What do you see in Mailman's smtp.log if you add ``` [logging.smtp] level: debug ``` to mailman.cfg. However, do you really need this. It will only affect delivery from Mailman to Postfix via the loopback interface on the localhost. -- Mark Sapiro <mark(a)msapiro.net> The highway is for gamblers, San Francisco Bay Area, California better use your sense - B. Dylan

4 years, 10 months

[MM3-users] Re: Poor rendering of disabled registration page

by Mark Sapiro

On 12/22/24 04:16, Torge Riedel via Mailman-users wrote: > > 1. The page has a poor rendering, as far as I can see not css is referenced > 2. A would prefer that I am able to hide the registration button > > Is either of this possible to be fixed in the future? The lack of styling is fixed for django-mailman3 1.3.16 by https://gitlab.com/mailman/django-mailman3/-/merge_requests/303 You can fix it by adding the django_mailman3/templates/account/signup_closed.html file as in this patch: ``` diff --git a/django_mailman3/templates/account/signup_closed.html b/django_mailman3/templates/account/signup_closed.html new file mode 100644 index 0000000..bc83950 --- /dev/null +++ b/django_mailman3/templates/account/signup_closed.html @@ -0,0 +1,11 @@ +{% extends "account/base.html" %} + +{% load i18n %} + +{% block head_title %}{% trans "Sign Up Closed" %}{% endblock %} + +{% block content %} +<h1>{% trans "Sign Up Closed" %}</h1> + +<p>{% trans "We are sorry, but the sign up is currently closed." %}</p> +{% endblock %} ``` Disabling the signup button on the resultant page is trickier as that currently comes from the hyperkitty/templates/hyperkitty/base.html which is used all over. -- Mark Sapiro <mark(a)msapiro.net> The highway is for gamblers, San Francisco Bay Area, California better use your sense - B. Dylan

1 year, 9 months

[MM3-users] Re: How to delete empty archives by script?

by Mark Sapiro

On 10/12/26 5:12 AM, Andreas Vetter wrote: > > First try, first problem: > > (venv) mailman@lists:~> django-admin shell > Python 3.11.15 (main, Aug 14 2026, 20:29:30) [GCC] on linux > Type "help", "copyright", "credits" or "license" for more information. > (InteractiveConsole) >>>> from hyperkitty.models import MailingList > Traceback (most recent call last): ... > 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. > > I don't see INSTALLED_APPS in any of the configuration files. Where should this > be defined? It is defined in mailman_web.settings.base which is imported by /etc/mailman3/settings.py. The issue is your django-admin command is not accessing the /etc/mailman3/settings.py file. Did you ever try the interaction in <https://lists.mailman3.org/archives/list/mailman-users@mailman3.org/message…>? If so, what is the difference between the django-admin you ran there and this one? In any case try ``` PYTHONPATH=/etc/mailman3 DJANGO_SETTINGS_MODULE=settings django-admin shell ``` -- Mark Sapiro <mark(a)msapiro.net> The highway is for gamblers, San Francisco Bay Area, California better use your sense - B. Dylan

1 week, 2 days

[MM3-users] Re: Cannot request password reset: "The e-mail address is not assigned to any user account"

by Mark Sapiro

On 1/26/22 22:21, dave--- via Mailman-users wrote: > > Using the web API, I have created several mailing lists and I have added members to these lists also using the web API (most relevant: https://docs.mailman3.org/projects/mailman/en/latest/src/mailman/rest/docs/…) specifying that each member is already pre_verified, pre_confirmed, and pre_approved. The lists themselves seem to be working fine. > > The problem is when our staff try to reset their password (through Postorious) to get access and do moderation tasks. The error message "The e-mail address is not assigned to any user account" displays no matter which email address I enter (except the one from MAILMAN_ADMIN_USER which works). The password reset is for a Django user, which is distinct from a Mailman user. The users you added via the web API are Mailman users, but in order to access their lists via the web UI they have to `sign up` to create a Django account. -- Mark Sapiro <mark(a)msapiro.net> The highway is for gamblers, San Francisco Bay Area, California better use your sense - B. Dylan

4 years, 8 months

[MM3-users] Re: Mails sent by mailman-web runjobs hourly

by Mark Sapiro

On 6/16/22 03:44, Eggert Ehmke wrote: > I get lots of mails originating from the mailman-web runjobs hourly. They are > sent to mailman@<mytld>. The content looks like > > 07:00:03 [Q] INFO Enqueued 12571 > 07:00:03 [Q] INFO Enqueued 12572 > 07:00:03 [Q] INFO Enqueued 12573 > > How can I disable these emails? These message come from Django Q, https://django-q.readthedocs.io/en/latest/ I don't think there is a way to disable those specific messages which occur at times when tasks are queued instead of started immediately. They are sent to `mailman` because `mailman` owns the crontab and the crontab has no MAILTO=. You can redirect these and all other messages from hourly jobs by surrounding the hourly jobs command in the crontab with MAILTO= as in ``` MAILTO=other(a)example.com @hourly /opt/mailman/mm/bin/django-admin runjobs hourly MAILTO=mailman ``` or possibly discard them with something like ``` @hourly /opt/mailman/mm/bin/django-admin runjobs hourly > /dev/null ``` but either of these could redirect or discard other messages from hourly jobs which you might want. -- Mark Sapiro <mark(a)msapiro.net> The highway is for gamblers, San Francisco Bay Area, California better use your sense - B. Dylan

4 years, 4 months

[MM3-users] Re: Expire non-members

by Mark Sapiro

On 2/8/26 18:36, John Price wrote: > I notice that a lot of the non-members (I didn't look at all ~230) don't > seem to be in the master user list. Maybe until they confirm the user > record is not created yet? If the address was just added from a nonmember post, it won't have a user record. As I said before, there is no pending confirmation for the nonmember. The address has been added as a nonmember and that's it. They won't be added as a member unless they request subscription at which point they will have to confirm if the list's subscription policy requires it. > Anyway, I'd love a subscribe timestamp so I could calculate how long it > has been, but I can rig something up with a daily cron job and a simple > DB of emails and the date it noticed them on the non-members list and > delete them after a few days. Thanks for the info! For the nonmember, nonmember.address.registered_on is probably the timestamp you are looking for. -- Mark Sapiro <mark(a)msapiro.net> The highway is for gamblers, San Francisco Bay Area, California better use your sense - B. Dylan

8 months, 1 week

[MM3-users] Re: spanish localization

by Mark Sapiro

On 2/12/21 3:21 AM, Victoriano Giralt wrote: > > I just wanted to make visible that the .mo files were a "bit old". For > example, Guillermo, in this thread, pointed that the Spanish > translation was quite compelte. Actualy, I spent some hours bringing > them to 100% around Christmas. But, the .mo file for es from the pip > install --update i did recently is dated November 7th. I have > definitely added a lot of translated material from then until the end > of the year. Why do you say the .mo files are old. The timestamps are all Feb 3 02:47 which is when the package was built for PyPI. > I know the translation happens outside the development community. I > tried to point that there might be some synchronisation problem, so to > say, between the translation site and the packaging of the latest > mailman release. When things are changed on weblate, we get automatically generated merge requests to update our source. We don't always merge them immediately, but we certainly do merge all the outstanding ones before making a release. -- Mark Sapiro <mark(a)msapiro.net> The highway is for gamblers, San Francisco Bay Area, California better use your sense - B. Dylan

5 years, 8 months

[MM3-users] Re: Schedule for a resolution of #406, #410 and #437

by Mark Sapiro

On 12/14/2017 02:14 PM, Abhilash Raj wrote: > On Wed, Dec 13, 2017, at 12:11 AM, Henrik Rasmussen wrote: >> I was wondering when #406<https://gitlab.com/mailman/mailman/issues/406>, >> #410<https://gitlab.com/mailman/mailman/issues/410> and >> #437<https://gitlab.com/mailman/mailman/issues/437> could be fixed. It >> seems that it would not be far, as >> !322<https://gitlab.com/mailman/mailman/merge_requests/322> is ready to >> be merged. > > Merged right now! :) And I have updated lists.mailman3.org and mail.python.org. Note however that <https://gitlab.com/mailman/mailman/merge_requests/322> does not fix <https://gitlab.com/mailman/mailman/issues/437> as noted at <https://gitlab.com/mailman/mailman/issues/437#note_46539617>. It also doesn't fix <https://gitlab.com/mailman/mailman/issues/441>. That appears due to a new bug related to <https://bugs.python.org/issue27321>, but which is a different message defect that causes UnicodeEncodeError to be thrown instead of KeyError. I have reported this at <https://bugs.python.org/issue32330>. I have created <https://gitlab.com/mailman/mailman/merge_requests/350> and <https://gitlab.com/mailman/mailman/merge_requests/351> to fix these issues. -- Mark Sapiro <mark(a)msapiro.net> The highway is for gamblers, San Francisco Bay Area, California better use your sense - B. Dylan

8 years, 10 months

Search results for query "sapiro"