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

[MM3-users] Re: Mysterious Bounces Being Logged

by Allan Hansen

All, Appreciation to Brian for bringing this up. After upgrading to MM3, a lot of legitimate users' subscriptions on my lists have been disabled even though they still get at least some messages (according to them), while some were correctly disabled. Yes, I need to be informed of bounces, because when the accounts get disabled, I don't want my reply to be 'Huh? I don't have a clue why.' I reported this before. Yours, Allan On 3/26/21, 14:08 , "Brian Carpenter" <brian_carpenter(a)emwd.com> wrote: On 3/26/21 2:59 PM, Mark Sapiro wrote: > They are being bounced by a downstream MTA. If you want to know why, you > have a few choices. You can mail the address yourself and hopefully get > a DSN back. You can install this patch: I would think any mail administrator for a mailman server would want to know why bounces are happening. I never saw this issue with Mailman 2. Did it exist? Is the patch going to make it to the next version of Mailman 3 core? Are there any plans to make bounce processing more transparent to server admins so we can troubleshoot delivery issues? -- Brian Carpenter Harmonylists.com Emwd.com _______________________________________________ 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/

5 years

[MM3-users] Re: Moving existing lists to a new domain

by Jeremy Stanley

On 2024-09-18 16:36:50 -0700 (-0700), Mark Sapiro wrote: > On 9/18/24 10:13, Jeremy Stanley wrote: [...] > > Since all the lists for the given domain will be moving to the same > > unused new domain on the existing server, and can move at the same > > time, I suppose this could be done through (offline if necessary) > > backend database update queries. [...] > ``` > UPDATE mailinglist SET mail_host = 'new.domain' WHERE mail_host = > 'old_domain'; > ``` [...] > ``` > UPDATE mailinglist SET list_id = CONCAT(list_name, '.', mail_host) WHERE > mail_host = 'new_domain'; > ``` > For HyperKitty, similar changes need to be made to the > hyperkitty_mailinglist table. The `name` column entries need to be changed > from `listname(a)old.domain` to `listname(a)new.domain` and the `list_id` column > entries need to be changed from `listname.old.domain` to > `listname.new.domain` Preparing to test this, I poked around the schema a bit and noticed that the domain names are also embedded as strings in the following fields: django_mailman3_maildomain.mail_domain django_site.domain django_site.name domain.mail_host Can anyone think of any additional tables/columns which would need updating for this? I'll see if scanning a dump of the full DB content turns up anything I might be missing too. Thanks again! -- Jeremy Stanley

1 year, 4 months

[MM3-users] Re: Mailman notify generating emails for request that aren't visible.

by Abhilash Raj

> On Nov 1, 2021, at 9:07 AM, Mark Sapiro <mark(a)msapiro.net> wrote: > > On 10/31/21 10:42 PM, Simon Coggins wrote: >> Looking at the code in gitlab it looks like it wasn’t merged until 1.3.6: >> https://gitlab.com/mailman/postorius/-/blob/1.3.6/src/postorius/urls.py#L53 >> But it’s not in 1.3.5: >> https://gitlab.com/mailman/postorius/-/blob/1.3.5/src/postorius/urls.py#L49 > > > Yes, I was mistaken. That code was merged on 14 Feb 2021 and is not in Postorius 1.3.4 which was released on 2 Feb. It should have been in 1.3.5 and I don't know why it is not at https://gitlab.com/mailman/postorius/-/blob/1.3.5/src/postorius/urls.py#L49, but that is moot in any case. > 1.3.5 was a security release with no fixed included. It was branched off from 1.3.4 and only the security fix was applied. One Gitlab pro tip is when you are trying to determine which particular release a particular commit is included in, you can click on the the “…” three dots next to "parent 6096958a master” just under the title and it will show all the tags and branches that this commit is included in. https://gitlab.com/mailman/postorius/-/commit/0aba874cae15b1baae2839dca57d3… for example, is included in 1.3.6b1, 1.3.6 and jquery and master branch. -- thanks, Abhilash Raj (maxking)

4 years, 5 months

[MM3-users] Re: Show diplay_name in a list

by Abhilash Raj

On Mon, Sep 30, 2019, at 6:33 AM, Joel Lord wrote: > On 9/29/19 5:59 PM, Mark Sapiro wrote: > >> Any idea what I was missing there? > > Often, member.display_name doesn't exist or is "None". > This seems to also be the problem that I submitted a while back (6 > months ago?) that the notification to the moderator of subscription > requests, which should include both display name and email address of > the requestor, only has the email address. We've been trying to track > the problem down in code but it keeps going deeper and deeper... This should be the UI trying to unconditionally convert a Python object to string. Name string transforms correctly, but since the absence of a name is denoted by a None object (as opposed to an empty string ''), the renderer mindlessly converts it to "None". It could be fixed with a simple {% if member.display_name is not None %}{{ member.display_name }}{% endif %} in the right place in the Django template. > > -- > Joel Lord > Web Administrator, Alpha Psi Omega Grand Cast > etc... etc... etc... > _______________________________________________ > 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/ > -- thanks, Abhilash Raj (maxking)

6 years, 6 months

[MM3-users] Re: Whitelist non subscriber

by Stephan Krinetzki

Mark Sapiro wrote: > On 08/06/2018 06:43 AM, Stephan Krinetzki wrote: > > > The steps are as follows, right? > > - Add users to the list and give the role "nonmember" > > - Set moderation action ('defer' or 'accept') > > Right. Good. So i understand it :) > > > > The only thing missing in the documentation is a note on how to do > > this via the Admin API. Who can explain that to me? > > Can you be more specific about what you are looking for? If by "Admin > API" you mean the REST API, are you asking how to interact with it or > what specific POST/PUT/PATCH commands to send? > > Or are you asking about the 'mailman shell' command? > With Admin API I mean the REST API from the localhost. Whether it's the REST API, the Mailman shell or the Admin API, I personally don't care. The only important thing is that we can set and use this role. However, I think that's settled anyway, since you're writing > > Also, we want to expose the nonmember role in Postorius and enable > setting moderation action for nonmembers, but we didn't get that in MM > 3.2/Postorius 1.2. So the whitelistening is not working at the moment, right?

7 years, 7 months

[MM3-users] Re: Subscription requires confirmation when list is set as Open

by Joachim Schrod

Mark Sapiro writes: > > > I maintain a mailing list for a private holiday where people don't > > subscribe themselves; I subscribe them. I have vetted their email > > address beforehand. (The subscribers are mostly not able to handle a > > verification email, nor any email-based workflow at all.) Is there a > > configuration option for a mailing list that sets "Pre Verified" to > > true as a default? > > > This is https://gitlab.com/mailman/postorius/-/issues/563 it was fixed > by https://gitlab.com/mailman/postorius/-/merge_requests/930 which was > later extended by > https://gitlab.com/mailman/postorius/-/merge_requests/945 however these > are not available until Postorius 1.3.14 which is not yet released. > > These add a setting, POSTORIUS_DEFAULTS, which can be used to set these > defaults. E.g., setting > > POSTORIUS_DEFAULTS = {'mass_subscription_pre_verify': True} > > will set the default for Pre Verified to True. So far, the only defaults > that can be set in this manner are mass_subscription_pre_confirm, > mass_subscription_pre_approve, mass_subscription_pre_verify and > mass_subscription_invite and those not until Postorius 1.3.14, but more > may be added. Thanks a lot for this info -- I'm looking forward for an upcoming Postorius 1.3.14 release! ;-) :-) Happy holidays and a good new year to everyone, Joachim

1 year, 3 months

[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)

5 years

[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

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

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

Search results for query "sapiro"