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

[MM3-users] Re: Django-allauth compatibility (ACCOUNT_AUTHENTICATION_METHOD and ACCOUNT_EMAIL_REQUIRED)

by Mark Sapiro

On 5/14/25 11:50, Jan Eden via Mailman-users wrote: > > – and solved them with the additions to /etc/mailman3/settings.py > suggested by Mark: > > del ACCOUNT_AUTHENTICATION_METHOD > ACCOUNT_LOGIN_METHODS = {'email', 'username'} I suggested the above. > del ACCOUNT_EMAIL_REQUIRED > ACCOUNT_SIGNUP_FIELDS = ['email*', 'username*', 'password1*', 'password2*'] I didn't suggest these. That was from another poster in that thread. We don't set ACCOUNT_SIGNUP_FIELDS = ['email*', 'username*', 'password1*', 'password2*'] in mailman_web/settings/mailman.py because the default is ACCOUNT_SIGNUP_FIELDS = ['username*', 'email', 'password1*', 'password2*'] and that plus ACCOUNT_EMAIL_REQUIRED = True is the same thing. However, it appears that there is a deprecation warning with django-allauth >= 65.5. I haven't seen this because the sites I manage are all using django-allauth 65.4.1 So to avoid the deprecations with django-allauth >= 65.5 it is appropriate to drop ACCOUNT_EMAIL_REQUIRED and set ACCOUNT_SIGNUP_FIELDS = ['email*', 'username*', 'password1*', 'password2*'] However, that setting doesn't exist in django-allauth < 65.5 so we also need to require django-allauth >= 65.5. I will do this. -- Mark Sapiro <mark(a)msapiro.net> The highway is for gamblers, San Francisco Bay Area, California better use your sense - B. Dylan

11 months, 3 weeks

[MM3-users] Re: Issues sending to gmail and yahoo e-mails

by Mark Sapiro

On 9/10/25 14:59, jkoral(a)luc.edu wrote: > OK, we successfully set this up on our mail domain and are able to send to gmail now, but we ran into another issue. After making those changes, when I create a new thread, instead of the e-mail coming from the list e-mail, it is now coming from my personal work e-mail. Can this be changed? You said in a prior post > I added DMARC mitigation to this list with "Replace From: with list address" and "DMARC Mitigate unconditinally - Yes" The DMARC Address I have in there is ^.*(a)gmail\.com$ Setting DMARC Addresses to ^.*(a)gmail\.com$ does no harm but is redundant as DMARC Mitigate unconditinally = Yes applies the DMARC mitigation action to all mail. How are you starting a new thread? Is this in HyperKitty? In any case, with those settings all mail from the list should be From: the list address. If that is not the case, I don't know why it would happen. If you posted by email, perhaps you are looking at a message received directly rather than from the list. -- Mark Sapiro <mark(a)msapiro.net> The highway is for gamblers, San Francisco Bay Area, California better use your sense - B. Dylan

7 months, 4 weeks

[MM3-users] mail stuck in "out" queue

by Mark Sapiro

On 3/29/19 2:28 PM, Dmitry Makovey wrote: > I've had encountered this situation now twice: mail is being stuck in > "out" queue and nothing in the logs indicates the issue. Is there a way > to ask mailman-core politely to attempt delivery (perhaps with increased > debugging in the logs) *without* restarting the core (which does solve > *this* problem but creates other problems, like availability of the > mailman as a whole) Is the "out" runner running? ps -fwwA |grep runner=out If not, you should be able to start it as the Mailman user with a command like /path/to/python3 /path/to/mailman/bin/runner -C /path/to/mailman.cfg --runner=out:0:1 See 'ps -fwwA|grep runner' for examples. If the out runner is running, is there a file named *.bak along with all the *.pck files in queue/out/ And if it's not, is there anything in Mailman's logs to indicate why it died? Also, 'mailman restart' should only take a matter of seconds, but if the out runner is running but not processing its queue, I think sending it a SIGINT should restart it. -- Mark Sapiro <mark(a)msapiro.net> The highway is for gamblers, San Francisco Bay Area, California better use your sense - B. Dylan

7 years, 1 month

[MM3-users] Re: Fwd: [Django] ERROR (EXTERNAL IP): Internal Server Error: /mailman3/hyperkitty/api/mailman/archive

by Mark Sapiro

On 11/20/20 8:24 AM, Gordon Dickens wrote: > My mailman3 installation has now been up and running successfully for > several weeks without any issues and then the following error message > was emailed to me by my server. > What's up with this error message and what do I need to do? > Thanks, > Gordon > > -------- Forwarded Message -------- > Subject: [Django] ERROR (EXTERNAL IP): Internal Server Error: > /mailman3/hyperkitty/api/mailman/archive > Date: Fri, 20 Nov 2020 01:25:41 -0000 > From: [1]root(a)host2.mailhub4u.com > To: [2]gordon(a)mailhub4u.com > Internal Server Error: /mailman3/hyperkitty/api/mailman/archive > OperationalError at /hyperkitty/api/mailman/archive > (1366, "Incorrect string value: '\\xF0\\x9F\\xA4\\xA3\\xF0\\x9F...' for > column `mailman3web`.`hyperkitty_email`.`content` at row 1") '\xF0\x9F\xA4\xA3' is a utf-8 encoding for the emoji '🤣'. For MySQL and MariaDB, 4-byte encodings require the database allow utf8mb4. If your Django database settings use the mysql database engine as in ``` DATABASES = { 'default': { 'ENGINE': 'django.db.backends.mysql', ``` You need to add ``` 'OPTIONS': {'charset': 'utf8mb4'} ``` -- Mark Sapiro <mark(a)msapiro.net> The highway is for gamblers, San Francisco Bay Area, California better use your sense - B. Dylan

5 years, 5 months

[MM3-users] Re: Mailman3 not working following distribution upgrade from Debian 10 to 11.

by Mark Sapiro

On 2/4/22 14:54, gordon(a)dickens.com wrote: > Hi Mark, > > Thanks very much for your prompt and helpful reply! > > I made the change to the mailman3 configuration for Apache that you recommended since I am using uwsgi. Now, I am able to start/status/stop the mailman3-web service without errors. However, now, when I then attempt to access the mailman installation on my server with my browser, I get the following message in the browser window: > > Internal Server Error > > I am unable to find any errors in the mailman3 logs or in the Apache error logs. However the Apache access logs have the following: > > 173.165.166.34 - - [04/Feb/2022:17:06:20 -0500] "GET /mailman3 HTTP/1.1" 500 21 > > Do you have any idea as to what is going on now? Any suggestions for troubleshooting this? Without more log info, I don't know what the issue is. Have you looked in /var/log/mailman3/mailman.log and /var/log/mailman3/web/mailman-web.log? Possibly there is a uwsgi log somewhere in /var/log that might have something relevant. -- Mark Sapiro <mark(a)msapiro.net> The highway is for gamblers, San Francisco Bay Area, California better use your sense - B. Dylan

4 years, 3 months

[MM3-users] Re: Removing the option to delete a list on the Postorious interface

by Mark Sapiro

On 6/14/22 13:43, Wong, Wesley wrote: > Hi, I have a question on the Postorious web interface in Mailman 3. I have found that a list owner can delete a list through the Postorious interface if they have the role of owner to the list. I wanted to have it either disabled or removed but I am not sure where to look to make changes to it. I would rather remove it from the interface totally so it would be done from the command line. Any help would be greatly appreciated. The simplest change would be to edit postorius/templates/postorius/menu/list_nav.html and remove the line. ``` <li role="tab" class="nav-item"><a href="{% url 'list_delete' list.list_id %}" class="{% nav_active_class current 'list_delete' %} nav-link">{% trans 'Delete' %}</a></li> ``` In addition to the above, you could edit postorius/urls.py and remove the line ``` re_path(r'^delete$', list_views.list_delete, name='list_delete'), ``` or in older Postorius versions ``` url(r'^delete$', list_views.list_delete, name='list_delete'), ``` to render the `delete` URL unknown. -- 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: Trying to understand the mailman.cfg from the virtualenv installation guide

by Mark Sapiro

On 9/8/24 01:04, unite42--- via Mailman-users wrote: > Hello, > > I'm trying to install Mailman3 following the Virtualenv Installation guide. I would like to understand why the configurations in the displayed mailman.cfg are recommended. > > Especially the following two: > > [archiver.prototype] > enable: yes > > "The prototype archiver stores messages individually in > var/archives/prototype/LIST_NAME/." > https://lists.mailman3.org/archives/list/mailman-users@mailman3.org/message… > > Do I need this, when using hyperkitty? Is this a fail-safe recommendation? The prototype archiver is separate from and independent of HyperKitty. If you are using HyperKitty as an archiver, you don't need the prototype archiver. Note however that if the prototype archiver is not enabled, it can't be used at all, but if it is enabled, it can still be enabled or disabled on a per-list basis. > [mta] > verp_confirmations: yes > verp_personalized_deliveries: yes > verp_delivery_interval: 1 > > What is the background of these recommendations? These settings enable VERP for all list messages. This results in more reliable bounce processing. -- 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: Cannot Create New List

by Mark Sapiro

On 11/1/25 10:20, dap1--- via Mailman-users wrote: > I'm trying to create a list (on Ubuntu) and I'm getting this: > > <venv> $ python3 > Python 3.12.3 (main, Aug 14 2025, 17:47:21) [GCC 13.3.0] on linux > Type "help", "copyright", "credits" or "license" for more information. >>>> owners = ['xxxx(a)ddddddddd.net'] >>>> from mailman.app.lifecycle import create_list >>>> ant = create_list('llllllllllllll(a)dddddddd.net', owners) > Traceback (most recent call last): > File "<stdin>", line 1, in <module> > File "/opt/mailman/venv/lib/python3.12/site-packages/mailman/app/lifecycle.py", line 74, in create > _list > getUtility(IEmailValidator).validate(fqdn_listname) > ^^^^^^^^^^^^^^^^^^^^^^^^^^^ > File "/opt/mailman/venv/lib/python3.12/site-packages/zope/component/_api.py", line 180, in getUtil > ity > raise ComponentLookupError(interface, name) > zope.interface.interfaces.ComponentLookupError: (<InterfaceClass mailman.interfaces.address.IEmailVa > lidator>, '') I'm not sure why this doesn't work, but it probably will if you do it in `mailman shell` which defines a lot of things for you. However, it is much simpler to just use the `mailman create` command to create a list. See `mailman create --help` -- Mark Sapiro <mark(a)msapiro.net> The highway is for gamblers, San Francisco Bay Area, California better use your sense - B. Dylan

6 months, 1 week

[MM3-users] Re: Hyperkitty download mbox

by Mark Sapiro

On 4/30/21 1:00 PM, Andrew Hodgson wrote: > > I tried this but get the same error, hope I did the modification correctly. > > [2021-04-30 19:56:31 +0000] [22104] [ERROR] Error handling request > Traceback (most recent call last): > File "/opt/mailman/venv/lib/python3.7/site-packages/gunicorn/workers/sync.py", line 180, in handle_request > for item in respiter: > File "/opt/mailman/venv/lib/python3.7/site-packages/hyperkitty/views/mlist.py", line 335, in stream_mbox > msg = email.as_message() > File "/opt/mailman/venv/lib/python3.7/site-packages/hyperkitty/models/email.py", line 178, in as_message > msg["Message-ID"] = "<%s>" % self.message_id.strip(' <>\r\n') This is the change I suggested, so you did it correctly. > File "/usr/lib/python3.7/email/message.py", line 409, in __setitem__ > self._headers.append(self.policy.header_store_parse(name, val)) > File "/usr/lib/python3.7/email/policy.py", line 145, in header_store_parse > raise ValueError("Header values may not contain linefeed " > ValueError: Header values may not contain linefeed or carriage return characters I don't understand why that change didn't work, but you could try replacing that line with ``` msg["Message-ID"] = "<%s>" % re.sub('[ <>\r\n]', '', self.message_id) ``` -- Mark Sapiro <mark(a)msapiro.net> The highway is for gamblers, San Francisco Bay Area, California better use your sense - B. Dylan

5 years

[MM3-users] Re: mailman3 postorius cannot retrieve template

by Mark Sapiro

On 11/2/21 3:28 PM, Wolfgang Bock via Mailman-users wrote: > > I get an db-entry in the mailman3 table template which doesnt lead to a > suitable link: > https://localhost/postorius/api/templates/list/testliste01.mydomain.de/list: > member:regular:footer > > In the next stept it leads to a flood of entries in my syslog because django > is asking for a certificate match for "localhost": > Nov 2 11:47:49 myserver mailman3[175334]: Nov 02 11:47:49 2021 (175334) > Certificate did not match expected hostname: localhost. Certificate: ... > > Letsencrypt cannot deliver this match for "localhost", it is impossible to > configurate letsencrypt to do so. > > The running script must create a postgres INSERT database command which > includes the correct domain-name including the correct path > .../mailman3/api/templates .... and not ... postorius/api/.... > > I dont know, where is the place to correct this. > - in mailman-web.py ?? > ... > ALLOWED_HOSTS ... '*' > or > MAILMAN_REST_API_URL = 'http://localhost:8001' > or > POSTORIUS_TEMPLATE_BASE_URL = 'https://localhost/mailman3/' If you normally access Postorius on your site at something like https://www.example.com/postorius, than set that as POSTORIUS_TEMPLATE_BASE_URL -- 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

Search results for query "sapiro"