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

[MM3-users] Re: How to promote non-members to members?

by Quanah Gibson-Mount

--On Wednesday, March 16, 2022 7:54 PM -0700 Mark Sapiro <mark(a)msapiro.net> wrote: > On 3/16/22 12:56, Quanah Gibson-Mount wrote: >> >> Thanks for the response. Unfortunately I'm currently stuck with the >> junk shipped by Debian. Yet another reason to move to a standalone >> install and avoid their broken packages. > > > In the mean time, you can handle these issues via REST or via `mailman > shell`. For example: > ``` > $ mailman shell -l list(a)example.com > 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. > >>> pendings = getUtility(IPendings) > >>> sub_mgr = ISubscriptionManager(m) > >>> for token, data in pendings.find(pend_type='subscription'): > ... if data['token_owner'] != 'subscriber': > ... continue > ... if data['email'] != 'user(a)example.com': > ... continue > ... sub_mgr.confirm(token) > ... > >>> commit() > ``` > > The above will find the pending confirmation for user(a)example.com on the > list list(a)example.com and confirm it. Hi Mark, I gave this a whirl. First I just had it print out all the emails waiting for confirmation just to confirm I saw the user in question had a pending subscription request, which they did (two in fact for the same email). So then I ran your code to confirm it, and it blows up with an error: >>> for token, data in pendings.find(pend_type='subscription'): ... if data['token_owner'] != 'subscriber': ... continue ... if data['email'] != 'xxxxxxxx(a)xxxxx.org': ... continue ... sub_mgr.confirm(token) ... Traceback (most recent call last): File "<console>", line 6, in <module> File "/usr/lib/python3/dist-packages/mailman/app/subscriptions.py", line 545, in confirm workflow.restore() File "/usr/lib/python3/dist-packages/mailman/app/workflow.py", line 149, in restore setattr(self, attr, data[attr]) File "/usr/lib/python3/dist-packages/mailman/app/subscriptions.py", line 119, in address_key assert self.address is not None AssertionError Regards, Quanah

3 years, 10 months

[MM3-users] Re: Invalid FilterAction: discard. Treating as discard

by Henrik Rasmussen

Mark Sapiro wrote: > On 6/6/19 6:02 AM, Henrik Rasmussen wrote: > > Still, attachments (PDF) is removed by Mailman. I as > > the list admin to send a new mail, but hold it back, to see what type it is. > You have to add the MIME types for the attachments you want kept the the > list's pass_types. You need to do this via mailman shell or REST as it > isn't currently exposed in Postorius. > Here's an example from a list that wants to accept PDFs as well as word > processing and spreadsheet documents. Note that nappdf and x-pdf are > uncommon PDF subtypes that I have seen. > ['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' > ] Thanks, done! However, PDF's and an image is still filterd out. On May 21st the list admin tested by setting Filter content to 'No'. As expected, the mail was received as sent, with PDF attachment, inline image and HTML intact. Resending this mail to a newly created test list (from Outlook by selecting Resend, which does exactly just that, the mail was again received as sent, even the config of Alter Messages as the same as the list having the problem. The difference was that list(m.pass_types) is [] Now, setting m.pass_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'] on the new testlist and resending the mail again, the mail still came out intact. So I guess the problem must be something complete different. Also I wonder why a newly created list accepts the PDF in question, when list(m.pass_types) is []. /Henrik Rasmussen

6 years, 7 months

[MM3-users] Re: Clean-up of non-members

by Odhiambo Washington

On Mon, Dec 23, 2024 at 1:37 AM Mark Sapiro <mark(a)msapiro.net> wrote: > On 12/22/24 05:25, Odhiambo Washington via Mailman-users wrote: > > > > Perhaps you can make a feature request in gitlab? > > And while at it, please add: mailman nonmembers LISTSPEC > > With the later, it would be easier to delete non-members from the CLI as > > well. > > > Isn't this just `mailman members --role nonmember LISTSPEC`? > I didn't know that the option was right in front of me, but it seems there is a problem: GNU Mailman 3.3.10 (Tom Sawyer), Mailman Core API Version 3.1 ``` (venv) mailman@eu:~$ mailman members --role nonmember kictanet(a)lists.kictanet.or.ke Traceback (most recent call last): File "/opt/mailman/mm/venv/bin/mailman", line 8, in <module> sys.exit(main()) ^^^^^^ File "/opt/mailman/mm/venv/lib/python3.11/site-packages/click/core.py", line 1157, in __call__ return self.main(*args, **kwargs) ^^^^^^^^^^^^^^^^^^^^^^^^^^ File "/opt/mailman/mm/venv/lib/python3.11/site-packages/click/core.py", line 1078, in main rv = self.invoke(ctx) ^^^^^^^^^^^^^^^^ File "/opt/mailman/mm/venv/lib/python3.11/site-packages/mailman/bin/mailman.py", line 69, in invoke return super().invoke(ctx) ^^^^^^^^^^^^^^^^^^^ File "/opt/mailman/mm/venv/lib/python3.11/site-packages/click/core.py", line 1688, in invoke return _process_result(sub_ctx.command.invoke(sub_ctx)) ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ File "/opt/mailman/mm/venv/lib/python3.11/site-packages/click/core.py", line 1434, in invoke return ctx.invoke(self.callback, **ctx.params) ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ File "/opt/mailman/mm/venv/lib/python3.11/site-packages/click/core.py", line 783, in invoke return __callback(*args, **kwargs) ^^^^^^^^^^^^^^^^^^^^^^^^^^^ File "/opt/mailman/mm/venv/lib/python3.11/site-packages/click/decorators.py", line 33, in new_func return f(get_current_context(), *args, **kwargs) ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ File "/opt/mailman/mm/venv/lib/python3.11/site-packages/mailman/commands/cli_members.py", line 223, in members display_members(ctx, mlist, role, regular, File "/opt/mailman/mm/venv/lib/python3.11/site-packages/mailman/commands/cli_members.py", line 106, in display_members dn = address.display_name or member.user.display_name ^^^^^^^^^^^^^^^^^^^^^^^^ AttributeError: 'NoneType' object has no attribute 'display_name' (venv) mailman@eu:~$ ``` From Postorius, there are 806 nonmembers. -- Best regards, Odhiambo WASHINGTON, Nairobi,KE +254 7 3200 0004/+254 7 2274 3223 In an Internet failure case, the #1 suspect is a constant: DNS. "Oh, the cruft.", egrep -v '^$|^.*#' ¯\_(ツ)_/¯ :-) [How to ask smart questions: http://www.catb.org/~esr/faqs/smart-questions.html]

1 year, 1 month

[MM3-users] Re: Solved Re: after last upgrade I've got a CSRF failed verification

by Guillermo Hernandez (Oldno7)

El 27/10/22 a las 21:39, Mark Sapiro escribió: > On 10/27/22 03:04, Guillermo Hernandez (Oldno7) via Mailman-users wrote: >> >> Since I made all the mailman3 enviroment wide server open (not using >> venv) I already executed the migration doing a >> >> su -m mailman3 -c "python3 manage.py collectstatic" >> su -m mailman3 -c "python3 manage.py migrate" >> >> Being mailman3 the user who runs all of mailman3 related stuff >> >> I had problems doing the migrate part, showing an error of lacking >> perms. I solved it running the migration under root (I know it could >> be trouble after, but...) > > It would be much better to identify the problem files/directories and > adjust their ownership. It is possible that running stuff as root in > the past left things owned by root causing the issue. The problem was in the intent of execute one of the migrate parts and showed about python files. I'm pretty sure that I've been very carefull not running things as root before as I know it can mess all up. But this time it was an dead end and I needed to go through. In a few days I will upgrade another server. I will document the error if I find it again. > >> >> After that the compress part showed errors... but the postorius web >> maintenance was working well except for the CSRF error verification. >> I will trace the compress errors and will try to find the problem later. > > > Do you have `COMPRESS_ENABLED = True` in your settings? If that's not > the issue, it may be in the settings for COMPRESS_PRECOMPILERS > I will try to trace it and comment what I find. Thaks a lot for your support. -- ___________________________________________ Mailman's content filtering has removed the following MIME parts from this message. Content-Type: image/png Name: firma-GHP-emails.png Replaced multipart/alternative part with first alternative.

3 years, 3 months

[MM3-users] Re: upgrading in FreeBSD 13.1-p7: problem with aiosmtpd and lmtp runner

by Guillermo Hernandez (Oldno7)

El 4/4/23 a las 3:31, Mark Sapiro escribió: > Guillermo Hernandez (Oldno7) wrote: > >> I thought I said it: I reboot this server everyday at 06:40 CEST time. >> That's why I'm sure it's not an undetected problem for weeks. The lists >> in this last upgraded server are with daily traffic. I'm suscribed to all. > > I've looked at this a bit further. Prior to Mailman core 3.3.4 we required aiosmtpd>=1.1. In 3.3.4 we required aiosmtpd>=1.4.1 and now we require aiosmtpd>=1.4.3. The code in aiosmtpd that triggers the issue in the socket module was added in aiosmtpd==1.3.1. So it is likely that your prior Mailman core version was <3.3.4 and your aiosmtpd dependency was <1.3.1, so the Mailman upgrade would also have upgraded aiosmtpd to a version which triggered the socket issue. I think tou are completely right about the aiosmtpd changes. But I had mailman 3.3.5 installed since end of september of '21, mailman 3.3.6 since end of october '22, and mailman 3.3.7 since the beginning of december of last year. You can search the list and find my messages about that upgrades and problems I had with them. Just to make it clear: It happened upgrading from 3.3.7 to 3.3.8 The upgrade procedure I did all the times is pip install --upgrade django-mailman3 mailman mailman-hyperkitty mailmanclient postorius django hyperkitty uwsgi mod-wsgi and if I see some trouble I did it with a --force-reinstall parameter (not that I remember it happened last times that I upgraded) (and then the collectstatic, etc.) If I missed something, I don't know. > _______________________________________________ > Mailman-users mailing list --mailman-users(a)mailman3.org > To unsubscribe send an email tomailman-users-leave(a)mailman3.org > https://lists.mailman3.org/mailman3/lists/mailman-users.mailman3.org/ > Archived at:https://lists.mailman3.org/archives/list/mailman-users@mailman3.org/mess… > > This message sent toguillermo(a)querysoft.es > -- ___________________________________________ Mailman's content filtering has removed the following MIME parts from this message. Content-Type: image/png Name: firma-GHP-emails.png Replaced multipart/alternative part with first alternative.

2 years, 9 months

[MM3-users] Re: Archive search failing on one list

by Mark

On 2023-10-11 04:38, Mark Sapiro wrote: > > Steve has addressed your issues with multiple Django admin commands, > some of which apparently don't reference the correct settings. > >> The format of my final line is different to yours ... > It is not a clue as to the problem. The format of that > `representation` changed in HyperKitty 1.3.5. What is your version? > HyperKitty version 1.3.4 > What happens if you do, with the appropriate Django admin and list > name, > ``` > python3 manage.py update_index_one_list thepost(a)example.com > ``` > Thank you Mark and Steve, That worked a treat! python3 manage.py update_index_one_list thepost(a)example.com Running that command returned the message "Indexing 12 emails", then returned to the shell prompt when done. It successfully indexed the messages in the archive, and I could then do a search on the existing messages. On 2023-10-11 00:54, Stephen J. Turnbull wrote: > The process of search index construction is both CPU and wall-clock > time intensive. For this reason, the cron jobs that do regular > index updating (I think once an hour?) are separate from the utility > that constructs the index in the first place when you have existing > archives (either migrated from another MLM such as Mailman 2, or if > you're upgrading to better archive software). The messages in the archive came directly from the list (ie. they weren't imported). It looks as though running that command flushed out a cobweb, as the hourly indexing is now happening. Some time after I had run that indexing command, a new message was posted to the list, and appeared in the archive. I searched (a)immediately, (b) 15 mins after, and (c)an hour and a bit after. As Steve said, the newer messages are automatically indexed hourly. So it wasn't until after that hourly index that the search terms in the newer messages were showing up in the search results. I can't say I understand the inner workings of the process yet, but we have a working archive search and I'm very happy about that. Thank you again, Mark

2 years, 3 months

[MM3-users] Re: update problems in virtualenv

by Christian H. Kuhn

Hi Mark, thank you for your answer. I did both updates, and haven't seen the warning since. KR QNo Am 05.11.2025 um 01:40 schrieb Mark Sapiro: > On 11/4/25 11:47, Christian H. Kuhn via Mailman-users wrote: >> Hi all, >> >> i followed https://docs.mailman3.org/en/latest/install/virtualenv.html >> and ran in different problems. Here's the first. >> >> All mailman-web runjobs report: >> >> System check identified some issues: >> >> WARNINGS: >> ?: settings.ACCOUNT_AUTHENTICATION_METHOD is deprecated, use: >> settings.ACCOUNT_LOGIN_METHODS = {'username', 'email'} >> ?: settings.ACCOUNT_EMAIL_REQUIRED is deprecated, use: >> settings.ACCOUNT_SIGNUP_FIELDS = ['email*', 'username*', 'password1*', >> 'password2*'] > > > This is https://gitlab.com/mailman/mailman-web/-/issues/37 fixed for the > next release. There are two ways to fix this. You can upgrade mailman- > web in your venv by activating the venv and doing > > pip install --upgrade git+https://gitlab.com/mailman/mailman-web > > Or you can add the following to your settings.py after the imports from > mailman_web.settings.base and mailman_web.settings.mailman > ``` > del ACCOUNT_EMAIL_REQUIRED > del ACCOUNT_AUTHENTICATION_METHOD > ACCOUNT_SIGNUP_FIELDS = ['username*', 'email*', 'password1*', 'password2*'] > ACCOUNT_LOGIN_METHODS = {'email', 'username'} > ``` > >> (venv) mailman@bywater:~/mm/var/data$ pip install --upgrade >> mailman==3.3.10 >> Collecting mailman==3.3.10 > ... >> INFO: pip is looking at multiple versions of mailman to determine >> which version is compatible with other requirements. This could take a >> while. >> ERROR: Could not find a version that satisfies the requirement >> nntplib; python_version >= "3.13" (from mailman) (from versions: none) >> ERROR: No matching distribution found for nntplib; python_version >= >> "3.13" >> >> standard-nntplib 3.13.0 is installed. > > This is an issue with Mailman 3.3.10 and Python >= 3.13 fixed by > https://gitlab.com/mailman/mailman/-/merge_requests/1348 > > Here again if you want to upgrade Mailman core you can do > > pip install --upgrade git+https://gitlab.com/mailman/mailman > > to get the latest from gitlab. >

2 months, 4 weeks

[MM3-users] Re: Apple Mail encoding again

by Stephen J. Turnbull

Mark Sapiro writes: > On 4/14/22 08:21, Stephen J. Turnbull wrote: > Yes. The C-T-E on all the multipart parts was quoted-printable, not > allowed under RFC 2045. That's what I expected (we're talking about Apple Mail), but thanks for confirming. > The Python email library says the message is defective. Mailman's lmtp > runner in turn rejects the defective message with a 501 status > https://gitlab.com/mailman/mailman/-/blob/master/src/mailman/runners/lmtp.p… > > It could accept a defective message or one with specific defects, but > this is problematic for further processing. For example, at least one > MUA, Thunderbird, renders such a message with an empty body. Sure, but that's not our problem. I mean, I have my MUA set to ignore HTML so I get empty bodies all the time! :-) We are perfectly within our rights to just let the Apple Mail and Thunderbird users fight about it. :-) If it causes problems for *our* processing, that's another matter. I don't see why it would, though. Whether we *want* to do that depends on how much trouble that causes for our main constituency (list and site admins), and whether we can provide discoverable documentation of the problem. My take is that this seems to be an extremely rare problem, and at least some MUAs are able to read the message, so we should let it through. If we wanted to be really obnoxious, we could add a header to the message This message does not conform to mail standards. Some clients may omit some or all of the content. Or we could make passing it an option, perhaps as a pseudo-content type in "Pass these content types" or as a separate option. I feel strongly enough that Postel implies "let it through" that I'll write up a PR shortly (a few days). Sleep on it, we bring in Abhilash and I guess Barry?, and if you all still don't like it, veto it -- my time is no big deal, it'll only be an hour to put it together I think. Steve

3 years, 9 months

[MM3-users] Re: HyperKitty/Mailman3 issues

by Florian Schulze

On 22 Nov 2018, at 19:53, Mark Sapiro wrote: > On 11/22/18 2:58 AM, Florian Schulze wrote: >> Hi! >> >> I tried setting up Scheduled Tasks as described in >> <http://docs.mailman3.org/en/latest/config-web.html#scheduled-tasks-required> >> >> but the "runjobs" command can't be found. I see the hyperkitty and >> mailman commands when using "help". > > > Does "help" show a list under [django_extensions] including runjob and > runjobs? > > Is 'django-extensions' in the list of INSTALLED_APPS in your Django > settings? That was the issue. Thanks! >> The "qcluster" service is working. >> >> Using Django 2.1.1 and HyperKitty 1.2.1. >> >> Maybe related to that, I have two issues with archives. >> >> 1. Changing the archiving setting in the Web-UI to something else >> than >> public seems to have no effect. The already archived messages are >> still >> accessible in public. > > > This is related. It is one of the "daily" jobs that updates this. Note > that changing to "private" will require login after the "daily" jobs > run, but changing to "do not archive" will leave the existing archive > accessible. After manually running the daily job, the archive is now private. >> 2. Related to 1., how can I remove a list archive without affecting >> other lists? > > > There's no easy way. For the "prototype" archiver, the archives for a > list are in var/archives/prototype/listname(a)example.com/ and that > directory can be removed, but that doesn't affect HyperKitty. > HyperKitty's archives are in the Mailman database and multiple tables > are involved. > > One could try just removing the row for the list from the > hyperkitty_mailinglist table. That may render the list's archive > inaccessible via the web UI, but I have no idea what would be broken > by > doing this. I hope this will be added at some point. For now I have the archive set to private. Thanks again for the pointers! Regards, Florian Schulze

7 years, 1 month

[MM3-users] Re: Solved Re: after last upgrade I've got a CSRF failed verification

by Guillermo Hernandez (Oldno7)

El 27/10/22 a las 21:39, Mark Sapiro escribió: >> After that the compress part showed errors... but the postorius web >> maintenance was working well except for the CSRF error verification. >> I will trace the compress errors and will try to find the problem later. > > > Do you have `COMPRESS_ENABLED = True` in your settings? If that's not > the issue, it may be in the settings for COMPRESS_PRECOMPILERS While I'm tracing the problem out, this is the configuration I had working and the error it shows after upgrade: <------- snip of settings.py> # COMPRESS_PRECOMPILERS = ( ('text/less', 'lessc {infile} {outfile}'), ('text/x-scss', 'sassc -t compressed {infile} {outfile}'), ('text/x-sass', 'sassc -t compressed {infile} {outfile}'), ) # On a production setup, setting COMPRESS_OFFLINE to True will bring a # significant performance improvement, as CSS files will not need to be # recompiled on each requests. It means running an additional "compress" # management command after each code upgrade. # http://django-compressor.readthedocs.io/en/latest/usage/#offline-compression #### activo compresion 18/12/20 COMPRESS_OFFLINE = True ###COMPRESS_OFFLINE = False <---------- end snip> And below is the error it shows: /usr/local/mailman3 # su -m mailman3 -c "python3 manage.py compress" Traceback (most recent call last): File "/usr/local/mailman3/manage.py", line 10, in <module> execute_from_command_line(sys.argv) File "/usr/local/lib/python3.9/site-packages/django/core/management/__init__.py", line 446, in execute_from_command_line utility.execute() File "/usr/local/lib/python3.9/site-packages/django/core/management/__init__.py", line 440, in execute self.fetch_command(subcommand).run_from_argv(self.argv) File "/usr/local/lib/python3.9/site-packages/django/core/management/__init__.py", line 279, in fetch_command klass = load_command_class(app_name, subcommand) File "/usr/local/lib/python3.9/site-packages/django/core/management/__init__.py", line 49, in load_command_class return module.Command() File "/usr/local/lib/python3.9/site-packages/django/core/management/base.py", line 274, in __init__ raise TypeError("requires_system_checks must be a list or tuple.") TypeError: requires_system_checks must be a list or tuple. -- ___________________________________________ Mailman's content filtering has removed the following MIME parts from this message. Content-Type: image/png Name: firma-GHP-emails.png Replaced multipart/alternative part with first alternative.

3 years, 3 months

Search results for query "sapiro"