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

[MM3-users] Re: Rejection Reason for refusing a subscription request

by Abhilash Raj

> On Mar 27, 2021, at 3:03 PM, Mark Sapiro <mark(a)msapiro.net> wrote: > > On 3/27/21 2:08 PM, Brian Carpenter wrote: >> I was testing out the process of rejecting an incoming subscription >> request. Choosing the reject option for a moderated subscription request >> does send out a rejection notice but it gives no reason for the >> rejection. > ... >> Is there a place somewhere in Postorius to provide a rejection reasons >> for moderated subscription requests? Does Mailman 3 core provide this >> via its REST api but it is just not revealed in Postorius yet? > > > It's in Postorius since 1.3.3. If in the held message view, you click > the subject of a held message, you get a popup dialog the shows the > message with options to also show headers or the raw message. There is > also a dropdown t=o set the poster's moderation action and a box for a > reject reason if you click the reject button in the dialog. > > Do you not see this? I guess Brian was asking about Subscription Requests. Support for specifying reason when rejecting subscription requests has been added in master and will be a part of next release, 1.3.5 most probably. -- thanks, Abhilash Raj (maxking)

4 years, 3 months

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

by Andreas Barth

* Quanah Gibson-Mount (quanah(a)symas.com) [211104 22:59]: > > > --On Thursday, November 4, 2021 8:25 AM -0700 Mark Sapiro > <mark(a)msapiro.net> wrote: > > >On 11/4/21 5:04 AM, Wolfgang Bock via Mailman-users wrote: > >> > >>My conclusion: > >>I ask you to consider these experiences in an update for the mailman3 > >>packages in debian bullseye. It would save time, questions and nerves. > > > > > >Issues with Debian packaging should be directed to Debian. > > Or as previously discussed, the debian packages should be avoided entirely. I strongly disagree with that statement. Distribution packages have their own up- and downsides. Of course, how they are done is to be discussed with the distribution, so: if something is wrong with a debian package, please follow the instructions on bugs.debian.org on reporting bugs. However, they have the advantage that they're integrated with the distribution. They have the disadvantage that they're stable for some time - that is why it's called a stable release. If they have all the features someone wants, they usually work fine (and my first mm3-installation was the default debian package). If one looks for bleeding edge, of course that's not what one can expect from a distribution package - but that's also a feature. Andi

3 years, 8 months

[MM3-users] Re: Error after HyperKitty 1.3.x upgrade

by Florian Schulze

On 29 Jun 2020, at 23:40, Mark Sapiro wrote: > On 6/29/20 1:38 AM, Florian Schulze wrote: >> Hi! >> >> After upgrading to HyperKitty 1.3.x I get the following error for >> qcluster: >> >> File ".../lib/python3.7/site-packages/django_q/cluster.py", line >> 300, >> in pusher >> task = SignedPackage.loads(task[1]) >> File ".../lib/python3.7/site-packages/django_q/signing.py", line >> 31, >> in loads >> serializer=PickleSerializer) >> File ".../lib/python3.7/site-packages/django_q/core_signing.py", >> line >> 38, in loads >> return serializer().loads(data) >> File ".../lib/python3.7/site-packages/django_q/signing.py", line >> 44, >> in loads >> return pickle.loads(data) >> AttributeError: Can't get attribute 'process_task_result' on <module >> 'hyperkitty.tasks' from >> '.../lib/python3.7/site-packages/hyperkitty/tasks.py'> >> >> How do I recover from that? It seems like there are still persisted >> tasks in the qcluster queue using the old code from 1.2.x with the >> old >> locking implementation. > > Have you stopped ans started qcluster since upgrading? Yes > Are you running the Django periodic jobs? They were disabled because of the errors (someone else did the upgrade). I have enabled them again and will watch it and report back. Regards, Florian Schulze

5 years

[MM3-users] Re: Emailing a list from the list server

by Mark Dadgar

On Jun 1, 2020, at 11:45 AM, Mark Sapiro <mark(a)msapiro.net> wrote: > On 6/1/20 10:02 AM, Mark Dadgar wrote: >> >> I cannot email a list from an account on the list server itself (for example, programmatically by script, but also manually) using mail / mailx / mutt / etc from the command line. The emails just disappear into the ether. > > > What's in Postfix's mail.log? Jun 1 11:54:55 mail postfix/lmtp[238922]: 1F42613BEB5: to=<test3(a)pdc-racing.net>, relay=127.0.0.1[127.0.0.1]:8024, delay=0.04, delays=0.02/0.01/0/0.02, dsn=2.0.0, status=sent (250 Ok) smtp.log: Jun 01 11:54:55 2020 (238852) Peer: ('127.0.0.1', 53402) Jun 01 11:54:55 2020 (238852) ('127.0.0.1', 53402) handling connection Jun 01 11:54:55 2020 (238852) ('127.0.0.1', 53402) Data: b'LHLO mail.pdc-racing.net' Jun 01 11:54:55 2020 (238852) ('127.0.0.1', 53402) Data: b'MAIL FROM:<mark(a)pdc-racing.net>' Jun 01 11:54:55 2020 (238852) ('127.0.0.1', 53402) sender: mark(a)pdc-racing.net Jun 01 11:54:55 2020 (238852) ('127.0.0.1', 53402) Data: b'RCPT TO:<test3(a)pdc-racing.net>' Jun 01 11:54:55 2020 (238852) ('127.0.0.1', 53402) recip: test3(a)pdc-racing.net Jun 01 11:54:55 2020 (238852) ('127.0.0.1', 53402) Data: b'DATA' Jun 01 11:54:55 2020 (238852) ('127.0.0.1', 53402) Data: b'QUIT' Jun 01 11:54:55 2020 (238852) ('127.0.0.1', 53402) connection lost Jun 01 11:54:55 2020 (238852) Connection lost during _handle_client() Test3 is a working mailman3 list. There are no posts held for moderation. - Mark ----- mark(a)pdc-racing.net | 408-348-2878

5 years, 1 month

[MM3-users] Re: {Spam?} Re: Monthly mailman-web job using a lot of memory

by Andy Smith

Hi, On Fri, Jul 01, 2022 at 12:57:41PM -0700, Mark Sapiro wrote: > I second Mark Dadgar's comment to replace whoosh with xapian. It > will help, although it requires rebuilding the entire search > index. Thanks both. Yes I am currently using whoosh which is the Debian packages' default. I decided to dramatically reduce the number of messages in our archives, as the vast majority of them are for lists that had never actually been looked at ever when under Mailman2, and external archives of them already exist. For ~6k messages it still took approx 16 hours to run that monthly job, and during that time spewed out thousands of these errors: Failed to remove document 'hyperkitty.email.29351' from Whoosh: Traceback (most recent call last): File "/usr/lib/python3/dist-packages/haystack/backends/whoosh_backend.py", line 309, in remove self.index.delete_by_query(q=self.parser.parse('%s:"%s"' % (ID, whoosh_id))) File "/usr/lib/python3/dist-packages/whoosh/index.py", line 365, in delete_by_query w = self.writer() File "/usr/lib/python3/dist-packages/whoosh/index.py", line 464, in writer return SegmentWriter(self, **kwargs) File "/usr/lib/python3/dist-packages/whoosh/writing.py", line 515, in __init__ raise LockError whoosh.index.LockError …so I'm not even sure if it worked. I will definitely have to look in to switching to Xapian. Thanks, Andy

3 years

[MM3-users] Re: Importing config and archives only partially succeeded?

by Eric Broens

Hi Mark, 1.Regarding the repeated access of /archives/api/mailman/urls seems to be related to mailman not being able to open port 25. This is weird because other mails have been distributed. The mailman log shows:Dec 12 22:16:48 2020 (1471) ACCEPT: < message id > Dec 12 22:16:52 2020 (1474) Cannot connect to SMTP server localhost on port 25 webserver logs:<host > - - [12/Dec/2020:22:16:50 +0100] "GET /archives/api/mailman/urls ?mlist=...&key=*** HTTP/1.1" 200 64 "-" "python-requests/2.25.0" <host > - - [12/Dec/2020:22:16:52 +0100] "GET /archives/api/mailman/urls?mlist=...&msgid=< message id >&key=*** HTTP/1.1" 200 105 "-" "python-requests/2.25.0" This last entry is repeated forever (until I stop the mailserver for a few minutes, but later on this happens again for other mails too). 2..Regarding the mails on the archive page, for most of the lists it is solved now. So probably one of the periodic jobs fixed that.The mailinglist which showed 0 participants 0 subscribers, does show now 0 participants 66 discussions.I have checked the member tables, and the members for this mailinglist are included there. 3.What I notice now too is that the hourly runjobs tasks don't seem to finish.I would have to check what they exactly do. Can I somehow activate logging for these? mailman 300042 300016 1 08:00 ? 00:09:18 /opt/mailman/venv/bin/python3 /opt/mailman/venv/bin/django-admin runjobs hourly --pythonpath /opt/mailman/mailman-suite/mailman-suite_project --settings settingsmailman 302158 302149 2 09:00 ? 00:09:10 /opt/mailman/venv/bin/python3 /opt/mailman/venv/bin/django-admin runjobs hourly --pythonpath /opt/mailman/mailman-suite/mailman-suite_project --settings settingsmailman 304513 304506 2 10:00 ? 00:09:38 /opt/mailman/venv/bin/python3 /opt/mailman/venv/bin/django-admin runjobs hourly --pythonpath /opt/mailman/mailman-suite/mailman-suite_project --settings settingsmailman 308631 308620 3 11:00 ? 00:09:29 /opt/mailman/venv/bin/python3 /opt/mailman/venv/bin/django-admin runjobs hourly --pythonpath /opt/mailman/mailman-suite/mailman-suite_project --settings settingsmailman 312847 312832 3 12:00 ? 00:09:15 /opt/mailman/venv/bin/python3 /opt/mailman/venv/bin/django-admin runjobs hourly --pythonpath /opt/mailman/mailman-suite/mailman-suite_project --settings settingsmailman 317343 317332 4 13:00 ? 00:09:20 /opt/mailman/venv/bin/python3 /opt/mailman/venv/bin/django-admin runjobs hourly --pythonpath /opt/mailman/mailman-suite/mailman-suite_project --settings settingsmailman 320079 320072 7 14:00 ? 00:09:08 /opt/mailman/venv/bin/python3 /opt/mailman/venv/bin/django-admin runjobs hourly --pythonpath /opt/mailman/mailman-suite/mailman-suite_project --settings settingsmailman 322618 322610 13 15:00 ? 00:08:54 /opt/mailman/venv/bin/python3 /opt/mailman/venv/bin/django-admin runjobs hourly --pythonpath /opt/mailman/mailman-suite/mailman-suite_project --settings settingsmailman 325205 325198 84 16:00 ? 00:06:56 /opt/mailman/venv/bin/python3 /opt/mailman/venv/bin/django-admin runjobs hourly --pythonpath /opt/mailman/mailman-suite/mailman-suite_project --settings settings Best Regards,Eric On Sunday, December 13, 2020, 06:29:19 AM GMT+1, Mark Sapiro <mark(a)msapiro.net> wrote: On 12/12/20 7:40 PM, Eric Broens via Mailman-users wrote: > There are no messages in var/archives/hyperkitty/spool/. At this time of the night (4:40 AM local time), there is no incoming mail. I'm not sure what is causing the repeated access of /archives/api/mailman/urls... This call comes from Mailman core in order to request the URL at which a message will be archived. It is called from mailman/src/mailman/handlers/rfc_2369.py when adding the Archived-At: header and from mailman/src/mailman/handlers/decorate.py in order to get the hyperkitty_url replacement value. I don't understand why it would be called repeatedly for the same message. Are there any clues in mailman.log. > I just noticed when clicking on "All Threads" or "Threads by month", the emails are displayed. The statistic however shows that there were no mails in the past month, while there actually are.When clicking "Recent", "Most Active", etc. the page shows "No discussions this month (yet)." What if you look at "threads by month" and select the current month? > Another observation. For one list, which is one of the more active ones, the bar diagram is not empty, while showing 0 participants and 0 discussions (see attached screenshot).This one however shows the mailthreads when opening the list. I think the basic issue is when you see no messages, HyperKitty, for whatever reason thinks there are no current messages. I'm not sure, but if there are recent posts, are they all in threads started more than 30 days ago? As far as all the participants/discussions counts being zero, I think one of the periodic jobs will fix that (possibly the daily recent_threads_cache job) -- Mark Sapiro <mark(a)msapiro.net> The highway is for gamblers, San Francisco Bay Area, California better use your sense - B. Dylan _______________________________________________ Mailman-users mailing list -- mailman-users(a)mailman3.org To unsubscribe send an email to mailman-users-leave(a)mailman3.org https://lists.mailman3.org/mailman3/lists/mailman-users.mailman3.org/

4 years, 6 months

[MM3-users] Re: Enable delivery

by Hirayama, Pat

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' >>> Thanks, -p Pat Hirayama Pronouns: he/him/his Systems Engineer IT | Systems Engineering Fred Hutchinson Cancer Center O 206.667.4856 phirayam(a)fredhutch.org ________________________________ From: Mark Sapiro <mark(a)msapiro.net> Sent: Monday, December 9, 2024 18:38 To: mailman-users(a)mailman3.org <mailman-users(a)mailman3.org> Subject: [MM3-users] Re: Enable delivery CAUTION: This email originated from outside of the organization. Do not click links or open attachments unless you recognize the sender and know the content is safe. On 12/9/24 17:35, Hirayama, Pat wrote: > Greetings, > > I'm finding something a bit odd with our listserv. Please see https://urldefense.com/v3/__https://wiki.list.org/DOC/Mailman*20is*20not*20… > Some of the members of some of the lists are reporting that they aren't receiving messages sent to the list. When I review the member options for the person in question, I see that Delivery Status shows nothing selected (i.e. neither radio button is selected for Enabled or Disabled). If you look in the MTA logs is mail being sent to them. As far as the Delivery Status showing nothing, that means the member's delivery_status is None. The ultimate delivery status is determined by checking first the member's delivery_status, then the address's delivery_status, then the user's delivery_status and finally Mailman's global preferences. The first non-None value is what's used. See https://urldefense.com/v3/__https://gitlab.com/mailman/mailman/-/blob/maste… Also see the various tabs at https://urldefense.com/v3/__https://www.example.com/mailman3/accounts/subsc… > If I select Enabled and Save, then delivery starts working for that user. This should only happen if the users address or user based preference or the global preference is Disabled. > There are other members of the list that have neither Enabled or Disabled selected, but they are working. Which also seems to mean that when I run: > > mailman members --nomail any listname@listserv > > Nothing is returned. Because all members ultimately have delivery enabled. > If anyone has any ideas about why this might be the case, or how I might proactively identify other members who aren't receiving mail, that would be appreciated. Alternately, any thoughts on how I might force all members to Delivery Status Enabled, that would also be great. It shouldn't be necessary to do that. For one of these members, e.g. user(a)example.com, that isn't getting mail, do this in mailman shell ``` 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. The variable 'm' is the list(a)example.com mailing list >>> from mailman.core.constants import system_preferences >>> mbr = m.members.get_member('user(a)example.com') >>> print(mbr.delivery_status) (this will print the ultimate delivery_status, for the components do) >>> print(mbr.preferences.delivery_status) (output) >>> print(mbr.address.preferences.delivery_status) (output) >>> print(mbr.address.user.preferences.delivery_status) (output) >>> print(system_preferences.delivery_status) (output) >>> ``` The first of the (output) lines which is not None should be the same as the output from print(mbr.delivery_status). -- Mark Sapiro <mark(a)msapiro.net> The highway is for gamblers, San Francisco Bay Area, California better use your sense - B. Dylan _______________________________________________ Mailman-users mailing list -- mailman-users(a)mailman3.org To unsubscribe send an email to mailman-users-leave(a)mailman3.org https://urldefense.com/v3/__https://lists.mailman3.org/mailman3/lists/mailm… Archived at: https://urldefense.com/v3/__https://lists.mailman3.org/archives/list/mailma… This message sent to phirayam(a)fredhutch.org

6 months, 3 weeks

[MM3-users] Re: configuring postfix local recipient table

by Alexander Inzinger-Zrock

Am 29.04.25 um 18:27 schrieb Mark Sapiro: >> Last idea before that would be to >> >> 1. delete the files: >> >> -rw-r--r-- 1 mailman mailman 0 Mar 21 11:58 postfix_domains >> -rw-r--r-- 1 mailman mailman 12K Mar 24 11:44 postfix_domains.db >> -rw-r--r-- 1 mailman mailman 0 Mar 21 11:58 postfix_lmtp >> -rw-r--r-- 1 mailman mailman 12K Mar 24 11:44 postfix_lmtp.db >> >> 2. restart services >> >> 3. test if programms make new files >> >> 4. report to mailinglist >> >> Would that be of interest to someone? > > Yes. + [X] deactivate services + mailman3.service + mailmanweb.service + postfix.service + postfix(a)-.service + [X] deleting files under /opt/mailman/mm/var/data + postfix_domains + postfix_domains.db + postfix_lmtp + postfix_lmtp.db + [X] restart services + mailman3.service + mailmanweb.service + postfix.service + postfix(a)-.service LEARNINGS: + no new files made (expected). + despite mailman3.service reports: + 'Apr 30 14:37:40 mlist01-prod mailman[533171]: Generating MTA alias maps' + postfix warns about the deleted files (expected): Apr 30 14:41:02 mlist01-prod postfix/error[533928]: warning: hash:/opt/mailman/mm/var/data/postfix_domains is unavailable. open database /opt/mailman/mm/var/data/postfix_domains.db: No such file or directory Apr 30 14:42:02 mlist01-prod postfix/error[533928]: warning: fast_flush_domains: hash:/opt/mailman/mm/var/data/postfix_domains: table lookup problem Apr 30 14:42:02 mlist01-prod postfix/error[533928]: warning: C5B821C00E5: flush service failure

2 months

[MM3-users] Re: Help with installing Postorius and Hyperkitty on Ubuntu 19

by Andrew Bernard

Hi Mark, Thanks for your great help. But despite decades of UNIX experience, my area is not Django (yet). The nub of my question is that I thought you have to have a manage.py file for Django to be able to set up the various affairs, such as making the database migrations and so on. It is that that is eluding me. Apologies for this hopelessly newbie question. I was impressed with your method of installation in the page referenced, and I have foolwed that closely. But I am puzzled about the build script. If I run as user mailman, not root, it wanted to install under /usr. which of course results in permission denied. I had to modify the script to say this: python setup.py install --prefix /opt/mailman/mm/venv I am concerned that I have also misunderstood something here. A On Sun, 9 Jun 2019 at 00:57, Mark Sapiro <mark(a)msapiro.net> wrote: > On 6/8/19 4:04 AM, Andrew Bernard wrote: > > > > Where is the Django config area for the > > pip installed modules? It is this that I find obscure. > > The short answer is wherever you put it. If you look at > <https://wiki.list.org/DOC/Mailman%203%20installation%20experience> > which Abhilash mentioned, you'll see what I do. > > >

6 years

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

by Quanah Gibson-Mount

--On Thursday, March 17, 2022 12:06 PM -0700 Mark Sapiro <mark(a)msapiro.net> wrote: > This says that there is no Address object with the email > xxxxxxxx(a)xxxxx.org > > What do you get in `mailman shell` for > ``` > >>> um = getUtility(IUserManager) > >>> um.get_address('xxxxxxxx(a)xxxxx.org') > >>> um.get_user('xxxxxxxx(a)xxxxx.org') > ``` > These should return an Address and a User respectively. If they don't, > did you perhaps run some process to delete the user? I've done nothing in regard to this user. Neither command returns anything. I see it return my user object if I test with my own email address. > If the user is gone, you should be able to replace > ``` > ... sub_mgr.confirm(token) > ``` > in the above with > ``` > ... wfm = getUtility(IWorkflowStateManager) > ... pendings.confirm(token, expunge=True) > ... wfm.discard(token) > ``` > to clear the pending subscription and workflow and then be able to mass > subscribe the user. I did this, and can confirm that they no longer show up in the list of pending subscriptions via the mailman shell interface for that list. However, if I go to mass subscribe them via the interface, I get: HTTP Error 409: b'Subscription request already pending' Regards, Quanah

3 years, 3 months

Search results for query "sapiro"