Search results for query "sapiro"
- 6292 messages
[MM3-users] Re: Timeouts
by Abhilash Raj
> On Apr 25, 2021, at 7:06 PM, tlhackque via Mailman-users <mailman-users(a)mailman3.org> wrote:
>
> On 25-Apr-21 20:34, Mark Sapiro wrote:
>> On 4/25/21 4:37 PM, tlhackque via Mailman-users wrote:
>>
>>> The described timeouts are something that hyperkitty ought to be able to
>>> avoid. For apache, the timeout is idle time between blocks of output.
>>> Hyperkitty can avoid this by generating the archive in segments (based
>>> on size, or elapsed time), flushing its output buffer, generating a
>>> multi-file archive, and/or using Transfer-Encoding: chunked (chunked
>>> doesn't work for http/2). It ought to be able to break the
> work into
>>> blocks of "n" messages & do something to generate output. Besides
>>> avoiding timeouts, working in segments allows the GUI to display
>>> meaningful progress (e.g. if you're loading with XMLHttpRequest,
>>> "onprogress") It really oughtn't be up to the user to break up the
>>> request.
>> It is not the web server that times out. I'm not sure about uwsgi
>> because I don't use it, but the timeouts I see are on servers that use
>> gunicorn as the WSGI interface to Django and the timeout is in a
>> gunicorn worker. This is controlled by the timeout setting in the
>> gunicorn config. <https://docs.gunicorn.org/en/stable/settings.html#timeout>
>>
>> Note that even 300 seconds is not enough to download the entire
>> <https://mail.python.org/archives/list/python-dev@python.org/> archive.
>>
>> It may be possible to get HyperKitty to chunk the output to avoid this,
>> but it doesn't currently do that. Care to submit an MR?
>>
>>
> I'm afraid (u)WSGI, Django, and gunicorn are not technologies that I
> work with.
>
> It sounds as if hyperkitty is compiling the entire archive before
> sending the first byte.
>
> The gunicorn doc that you pointed to says
>
> Workers silent for more than this many seconds are killed and restarted.
> Setting it to 0 has the effect of infinite timeouts by disabling
> timeouts for all workers entirely.
>
> "Silent" sounds like the standard webserver "you have to push some bits,
> or we assume you're stuck".
>
> My understanding is that gunicorn is a Python persistence server that is
> run behind a webserver proxy. So the (proxy) webserver (apache, nginx,
> ...) timeouts also apply and would need to be increased.
>
> Might be interesting to try 0 (gunicorn) / 1200 (webserver) with your
> python-dev archive, time it and see how much (encoded) data is
> transferred... (I would expect most mailing list archives to compress
> nicely, though those with binary attachments wont.)
For uwsgi, I think the parameter is called `harakiri`[1][2] (I don’t know why such a name though).
[1]: https://uwsgi-docs.readthedocs.io/en/latest/Options.html#harakiri
[2]: https://uwsgi-docs.readthedocs.io/en/latest/Glossary.html
> if request takes longer than specified harakiri time (in seconds), the request will be dropped and the corresponding worker recycled.
This should be set to a long enough value that allows downloading the archive.
If you are using http socket, then you want http-timeout.
Also, to set the timeout in webserver (nginx)
location / {
uwsgi_read_timeout 120s;
uwsgi_send_timeout 120s;
uwsgi_pass 0.0.0.0:8000;
include uwsgi_params;
}
Or some other value that you want.
> But fiddling with timeouts is treating the symptom, not the root cause.
> The right solution is to stream, segment (or chunk) the output, because
> in the general case, no timeout is long enough. It'll always be
> possible to find an archive that's just one byte (or second) longer than
> any chosen timeout. (See the halting problem.) You want
> the timeout
> to catch a lack of progress, not total time that's a function of
> transaction size. (Webservers may also have limits on transaction size
> - e.g. mod_security, but they're only useful when the upper bound on a
> response is knowable.) Thus, the timeout(s) should be roughly
> independent of the archive size; on the order of time-to-first-byte
> (which ordinarily is longer than time between segments/chunks).
>
> Also note that streaming requires fewer server resources than compiling
> a complete archive before sending, since you don't need to create the
> entire archive in memory (or in a tempfile). You only need enough
> memory to efficiently buffer the file I/O and to contain the compression
> tables/output buffer. Except for trivial cases, this will be
> independent of the archive size. The only downside is that if the comm
> link is slow, you may hold a reader lock on the source data for longer
> than necessary with the current scheme.
>
> Seems as though this deserves an issue. I guess I could open one - but
> you have the experience/test cases.
Hyperkitty doesn’t actually create an archive in memory or in a temp file. It uses streaming response with on the fly compression to read from database and relay to the client for download.
https://gitlab.com/mailman/hyperkitty/-/blob/master/hyperkitty/views/mlist.…
The problem could be that uwsgi seems to kill an ongoing downloading process, not an idle one for some reason. And, it seems that it is a known and intentional behavior. I don’t see a good way to disable it completely, but perhaps it can be set to a long enough value that it never essentially kills a running worker which is moving bits.
--
thanks,
Abhilash Raj (maxking)
5 years, 4 months
[MM3-users] Re: Time Stand Still
by Fabian A. Santiago
On November 23, 2017 11:38:00 AM EST, Barry Warsaw <barry(a)list.org> wrote:
>Somewhen in the dark recesses of intarweb history, I found myself as
>the project leader for both Jython (née JPython) and GNU Mailman. I'd
>been involved with Jython since it was invented by Jim Hugunin around
>the time he came to work with us at Pythonlabs. I'd been contributing
>to Mailman since we inherited John Viega's Python-based Dave Matthews
>Band list server, and put it to use replacing python.org's Majordomo
>installation.
>
>I'd enjoyed both projects, but knew I could not lead both, so I had to
>make a choice. I chose to turn over Jython to a team that's done a
>much better job over the years than I ever could have. Something about
>email, and especially the communication and collaboration patterns that
>it facilitates, really fascinated me. I know, I know, but we all have
>our lapses of sanity. Mine has lasted almost 20 years, a bit more than
>"momentary" perhaps.
>
>I've rarely gotten paid to work on Mailman, but it did provide me some
>great opportunities. Most notably it led to my 10 year stint at
>Canonical. I was originally hired on there to integrate mailing lists
>with Launchpad, and Mailman was the obvious choice. I learned a ton
>doing that project, and working within the constraints of integrating
>the two Python-based systems, especially since Launchpad was originally
>not free software and Mailman was GPL'd. Later, the Zope-based
>Launchpad source code was released under the AGPL, making much of the
>monkeypatching unnecessary, but by then the system was solid and
>reliable, and you don't fix what's not broken.
>
>Except, I guess I did. I took a lot of the lessons from that work,
>along with a good hard look at all the problems with Mailman 2, and
>began to break another cardinal rule of software development: second
>system syndrome. The result is Mailman 3. It took forever, and we're
>still not at complete feature parity with Mailman 2, but at least it's
>Real Enough to be used at many Real Sites, including python.org and
>lists.fedoraprojects.org.
>
>It would be ridiculous for me to take significant credit for this. I
>have to acknowledge the amazing user community -- you! -- for all the
>support, patches, suggestions, feedback, patience, criticism,
>donations, and contributions that you've given to the project, and to
>me personally over the years. And my deepest gratitude goes to all the
>core developers that have stayed or come and gone, but most especially
>the current Cabal: Abhilash Raj, Aurelien Bompard, Florian Fuchs, Mark
>Sapiro, Stephen J. Turnbull, Terri Oda. You should know that each and
>every one of them is truly awesome, both in what they contribute
>technically, and in their amazing friendships. Mailman is infinitely
>better because of their involvement, and I've loved spending time with
>them over the years at the Pycon sprints, making releases and sharing
>teas and meals.
>
>My blog is called We Fear Change, and that's humorously taken from a
>90's bit in Mike Myer's excellent Wayne's World movie (a phrase
>actually uttered by the brilliant Dana Carvey as Garth). The irony of
>course is that while we all may fear change, it's the one constant
>thing we can count on. And in fact, we *require* change to thrive,
>because if you aren't changing, you aren't alive. Time, and being
>engaged with life's vagaries, means there's no alternative to change;
>it must be embraced.
>
>And so, with a vague reference to the many (good!) changes in my
>personal and professional life, I'm announcing that I'm stepping down
>from the project leadership role of GNU Mailman, effective... nowish!
>And it's with unanimous agreement among the GNU Mailman Steering
>Committee (a.k.a. the Mailman Cabal), that we are announcing Abhilash
>Raj as the new project leader.
>
>If you don't recognize Abhilash's name, you probably aren't paying
>attention, at least to Mailman 3. Abhilash came to us in 2013 as a
>Google Summer of Code student, and he's become one of the project's
>most valuable contributors. His list of accomplishments is long, and
>it includes everything from redesigning the website, to integrating CI
>with our GitLab build system, porting our code to the SQLAlchemy ORM,
>adding MySQL support, revving up adoption through his Docker images,
>along with his great coding work on Core, Postorius, HyperKitty, and
>mailmanclient.
>
>This transition is good for the project too. Email, its defining
>protocols and standards, and its role in our daily lives, has changed
>profoundly since the early days of Mailman. A fresh perspective and
>enthusiasm will help keep Mailman relevant to the changing ways we --
>especially the FLOSS and tech communities -- communicate.
>
>Please join me in supporting Abhilash in every way possible as he takes
>over in this new role as project leader. I'll be here when and if
>needed, even as I create space in my "spare" time for... Something
>Else. I look forward to the vision that Abhilash will bring to the
>project, and I know that he will do a great job. To me, Mailman has
>always been about collaboration, and the best
>way for it to succeed is for you to continue to contribute your
>insights, experiences, opinions, and skills with positive intention.
>
>-Barry
>
>https://www.wefearchange.org/
Congrats Abhilash! Love the docker images!
Thank you Barry! Mailman rocks!
--
Thanks,
Fabian S.
OpenPGP: 3C3FA072ACCB7AC5DB0F723455502B0EEB9070FC
8 years, 9 months
[MM3-users] Re: Fwd: Re: Removing a mail addresses and users
by Allan Hansen
All,
Thank you for your thoughtful responses to my call for a removal of the core vs. Django disconnect. From your responses it appears that my suggestion my issues were caused by the Mailman Core was not based in reality. Instead, the issue is how Postorius interacts with the Core. My apologies for overreaching, as the cause of my issues is not an issue to me. Keeping Core a simple list manager is fine, if Postorius is easy to use and does the expected.
As a Subscriber, you are able to do switch emails in subscriptions from your options page. The URL to which is displayed in the List's Summary page when you are logged in. Yes, it requires an approval if the list's settings are set to moderate but that is going to be fixed, see this issue[1]. It is quite simple IMO to fix this one, if someone wants to take this up.
Well, it’s more than that. Based on the current setup, I have asked my subscribers who want to change their subscription addresses to:
a. Create an account if you do not already have one.
b. Go to the user profile page.
c. Select ‘E-mail Addresses’.
d. Add the new e-mail to the user profile.
e. Wait for the verification notice and verify the new address.
e1. If it does not show send email to hansen(a)rc.org <mailto:hansen@rc.org> to get the email verified manually.
f. Sign in to the account again and to the user profile (or refresh the page if not signed out).
g. Select the new address as the primary address.
h. Click on ‘Manage Lists’
i. For each list you are subscribed to:
i1. Select the list
i2. Click ‘List Options Page.’
i3. Pull down the ’Select Email’ menu.
i4 Select your new email.
i5. Press ‘Change email used for subscription.
i6. When the moderator contacts you, explain that you are just changing your email.
i6.1. If the moderator is late, send a reminder or send email to hansen(a)rc.org <mailto:hansen@rc.org> to bypass the moderator.
Most people choke on these instructions, so I have unfortunately resorted to just asking them to subscribe the new address and forget about the old. This is not good for our reputation when the old addresses start bouncing. So, in more detail:
I would like to ask my subscribers who want to change their address to:
a. Create an account if you did not already have one.
b. Go to the user profile page.
c. Select ‘E-mail Addresses’.
d. Select an existing address e-mail listed the user profile.
e. Press new button ‘Change address’.
f. When page refreshes, enter the new e-mail address.
g. Press ‘Apply.'
d. Wait for the verification notice.
d1. If it does not show send email to hansen(a)rc.org <mailto:hansen@rc.org> to get the email verified manually.
In other words, in addition to ‘Make Primary’ and ‘Re-send Verification’ and ‘Remove’, another button says: ‘Change Address’ or’ ‘Replace Address’ or some such.
This button brings up another page that looks the same, but instead of ‘Add E-mail Adress’ is says : Enter New E-mail Address’
and instead of ‘Add E-mail’ is says: ‘Apply’. Then the page refreshes back to the original page, but the new address is now
replacing the old address. Optionally, it can show the old address still with a ‘pending change’ until verification.
Further, when the new address is verified, all lists get updated with the new address replacing the old
address and all settings associated with the old address are now associated with the new address. No moderator or admin
involvement needed (other than d1).
You are able to sign in via web and manage your email and subscriptions. The preferences also work exactly how you described above where the lower level override the default and/or upper level settings.
To some extent that is true, Abhilash, and I appreciate that. The above (address change) is a missing piece in that picture and I look forward to seeing it added, if you have time.
Yours,
Allan Hansen
hansen(a)rc.org
> On Jun 14, 2020, at 0:19 , Stephen J. Turnbull <turnbull.stephen.fw(a)u.tsukuba.ac.jp> wrote:
>
> Mark Sapiro writes:
>
>> Then the people who developed the web based management UI (Postorius)
>> and archive UI (HyperKitty) chose to develop those within a Django
>> framework and Django has its own concept of User separate from Mailman
>> Core and that is where the disconnect occurs.
>>
>> It's not that Mailman Core lacks what you want. It's that Django doesn't
>> use it.
>
> I think that's mostly right, in terms of the features that users miss.
> However, as far as I know, Mailman core does lack facilities for
> identification, authentication, and authorization of connections to
> the REST API. And that means that the front ends have to handle
> this. I would guess that's why the web interfaces are built around
> Django user authentication.
>
> I think it would be possible to have somewhat tighter integration
> between the Django "web users" and the Mailman core User objects, but
> it's not necessarily going to be trivial.
>
> I see that Abhilash is pretty optimistic, but I fear this this is
> going to be a long-tail situation where we're going to be seeing core
> user vs. web-gui user integration issues in 2030 (maybe by then only 1
> every 450 days ;-). I have some ideas, maybe in a couple weeks I can
> sketch them out.
>
> Steve
> _______________________________________________
> 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/
6 years, 3 months
[MM3-users] Re: hello， Discussion on how to subscribe to the mailing list
by 朱超
At 2023-01-17 15:56:35, "Stephen J. Turnbull" <stephenjturnbull(a)gmail.com> wrote:
>Mark Sapiro writes:
>
> > On 1/16/23 18:55, 朱超 wrote:
> > > Hi, When I subscribe the email list in Subscription Policy is
> > > confirm, Some problems happen in here：
> > > 1.Some mail mua reject send the confirm the message, because the
> > > length of recipient is too long. for exmaple:
> > > requirements-confirm+9605556e0b35a5da280c1de0d34a3e6f770f8ea5@domain,
> > > and the mail mua reject to modify about this.
> >
> > The default English template says in part:
> >
> > Before you can start using GNU Mailman at this site, you must first
> > confirm that this is your email address. You can do this by replying to
> > this message.
> >
> > Or you should include the following line -- and only the following
> > line -- in a message to $request_email:
> >
> > confirm $token
> >
> > I.e. It gives an alternative method if `reply` doesn't work. You can
> > provide a custom version of this template with different wording if you
> > think you can improve it.
>
>The problem is the reply address, though. Changing the template to
>suggest only the "confirm $token" in body method doesn't help people
>who hit R expecting that should work, especially since many "user
>fiendly" (misspelling intentional) MUAs don't display the address.
>Avoiding that requires code changes, I guess?
Yes, You got it. It is too cumbersome to ask the user to write a reply email for email confirmation.
>
> > > 2.It is inconvenient for users to use. Many people will
> > > mistakenly think that after clicking the subscribe button, it
> > > will be successful, and they will not process the email.
>
> > step, you can set Subscription Policy to Open, but then anyone can
> > maliciously subscribe third parties to the list.
>
>*Please* do not do this if your server is exposed to the Internet.
>There are bots that search for such servers, and sell lists of them to
>people who want to DOS mailboxes. You may find yourself banned across
>the Internet.
>
Yes.For service security, we will not set the Subscription Policy to open
>The only real alternative to confirmation is approval by moderators.
>I believe Mailman 3 offers that alternative as Mailman 2 did, can't
>check at the moment.
>
> > > Regarding the discussion on the subscription method of the
> > > mailing list, should we consider optimizing the subscription
> > > method of the mailing list, for example:
> > > 1. use the method of sending a verification code to subscribe by
> > > email，When you receive the verification code sent by the
> > > mailing list and fill it in again, you can subscribe
> > > successfully。
> >
> > How is this different from the present method.
>
>Just wording. I think they are thinking of the "invite" option that
>was provided in Mailman 2 mass subscribe (again, I think Mailman 3
>retains it but I never ever used it so I don't recall for sure). But
>it doesn't make sense for a user-initiated interaction.
>
> > If you want, you can make
> > a custom template and include something like:
> >
> > Alternatively, you can confirm by going to the URL
> >
> > https://www.example.com/mailman3/lists/$list_id/confirm/?token=$token
>
>If I understand the OP's PoV correctly, I think I would change the
>list information page to say "Send a personal invitation to join the
>list to [email address here]. If you aren't a subscriber, you can
>invite yourself." And change the word "confirm" in the confirmation
>template to "subscribe".
Why do you need to modify the mailman-core service， I suggest we should modify the code of the postorius, We can refer to postorius to reset the user password process，
Detail, through the postorius to send email to user, and user click the url in email to confirm subscribe the email，Currently I have achieved it this way。
> > We don't include that in the default template because Mailman core
> > doesn't know if you even have a web UI or how to access it if you
> > do.
>
>We should fix that, at least if the web interface is Postorius
>(wishlist, assigned to me):
>https://gitlab.com/mailman/mailman/-/issues/1055
>
>@mark
>https://gitlab.com/mailman/mailman/-/issues/901
>Maybe we can close this? I'm not sure why it was left open since
>there's no action proposed for Mailman improvement.
>
> > > 2. use the email to send a connection to confirm the
> > > subscription，People click the link to be redirected to a
> > > confirmation page to subscribe to the email。
> >
> > See above.
>
>Indeed, AFAICS almost everything the OP is suggesting amounts to an
>identical procedure as far as the Mailman server is concerned, it's
>just described to the subscriber differently. The one exception is
>the suggestion to eliminate the confirmation step, and while that is
>supported, it's quite likely to cause problems for third parties and
>eventually for the Mailman site unless you have an alternative ground
>source of truth such as an employee database.
>
>Steve
>_______________________________________________
>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/
>Archived at: https://lists.mailman3.org/archives/list/mailman-users@mailman3.org/message…
>
>This message sent to tom_toworld(a)163.com
3 years, 7 months
[MM3-users] Re: integrating mm3 with postfix / lmtp
by Fabian A. Santiago
On October 26, 2017 9:39:06 PM EDT, Mark Sapiro <mark(a)msapiro.net> wrote:
>On 10/26/2017 06:16 PM, Fabian A. Santiago wrote:
>
>>
>> But in my testing, I replied to a subscription confirmation message
>and received back an undeliverable looping email error message from
>postfix. Any clues there you can offer? I can post to the list from any
>email added via the admin console. The test subscriber address was
>local to my server. From an outside address, same error.
>
>
>This usually means that postfic is trying to deliver to an address and
>the message already has a Delivered-To: header with that address.
>
>What are the headers of the "looping" message in the report? What are
>the Postfix log messages related to that message?
>
>
>> Once I registered the new email domain, I reverted my postfix config
>back to the default suggested by maxking's docker instructions.
>>
>> https://github.com/maxking/docker-mailman
>
>
>I have essentially no knowledge of the docker container images, so I
>can't be much help with issues specific to them.
Return-Path: <MAILER-DAEMON>
Delivered-To: turtl(a)deviltracks.net
Received: by mail.garden-life.org (Postfix)
id 39F6C2055; Thu, 26 Oct 2017 21:02:17 -0400 (EDT)
Date: Thu, 26 Oct 2017 21:02:17 -0400 (EDT)
From: MAILER-DAEMON(a)mail.garden-life.org (Mail Delivery System)
Subject: Undelivered Mail Returned to Sender
To: turtl(a)deviltracks.net
Auto-Submitted: auto-replied
MIME-Version: 1.0
Content-Type: multipart/report; report-type=delivery-status;
boundary="2D7231948.1509066137/mail.garden-life.org"
Content-Transfer-Encoding: 7bit
Message-Id: <20171027010217.39F6C2055(a)mail.garden-life.org>
This is a MIME-encapsulated message.
--2D7231948.1509066137/mail.garden-life.org
Content-Description: Notification
Content-Type: text/plain; charset=us-ascii
This is the mail system at host mail.garden-life.org.
I'm sorry to have to inform you that your message could not
be delivered to one or more recipients. It's attached below.
For further assistance, please send mail to postmaster.
If you do so, please include this problem report. You can
delete your own text from the attached returned message.
The mail system
<test123-confirm+b7322edad83ae7ec99cfc5100161c7062d2c7685(a)gjb-online.com>: mail
for gjb-online.com loops back to myself
--2D7231948.1509066137/mail.garden-life.org
Content-Description: Delivery report
Content-Type: message/delivery-status
Reporting-MTA: dns; mail.garden-life.org
X-Postfix-Queue-ID: 2D7231948
X-Postfix-Sender: rfc822; turtl(a)deviltracks.net
Arrival-Date: Thu, 26 Oct 2017 21:02:17 -0400 (EDT)
Final-Recipient: rfc822; test123-confirm+b7322edad83ae7ec99cfc5100161c7062d2c7685(a)gjb-online.com
Original-Recipient: rfc822;test123-confirm+b7322edad83ae7ec99cfc5100161c7062d2c7685(a)gjb-online.com
Action: failed
Status: 5.4.6
Diagnostic-Code: X-Postfix; mail for gjb-online.com loops back to myself
--2D7231948.1509066137/mail.garden-life.org
Content-Description: Undelivered Message
Content-Type: message/rfc822
Content-Transfer-Encoding: 7bit
Return-Path: <turtl(a)deviltracks.net>
Received: from mail.garden-life.org (localhost [127.0.0.1])
by mail.garden-life.org (Postfix) with ESMTP id 2D7231948
for <test123-confirm+b7322edad83ae7ec99cfc5100161c7062d2c7685(a)gjb-online.com>; Thu, 26 Oct 2017 21:02:17 -0400 (EDT)
Authentication-Results: mail.garden-life.org (amavisd-new);
dkim=pass (1024-bit key) reason="pass (just generated, assumed good)"
header.d=garden-life.org
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=garden-life.org;
h=references:in-reply-to:to:subject:subject:message-id:from
:from:x-mailer:content-transfer-encoding:content-type
:content-type:date:date:mime-version; s=dkim; t=1509066135; x=
1509930136; bh=k85upIKMt3yA1zcaSrQxE349DcmKTq86MMRdi7hh2yw=; b=X
2phB5a1/LGy0J5YIHZTnbXOeoJ55wkcBrFax3cTvvXAAbfZEBsV3BLZ9Z25GdncT
CK7b3FU8He/70UAKZtcjreE1AP/hB89yX63xNSqFu2iULKIYMOhWaE/eWl897VhN
NIR1mONlrQxOUf5+o16As9WPdbAiEO/TKNMUpuyk+A=
X-Virus-Scanned: amavisd-new at mail.garden-life.org
X-Spam-Flag: NO
X-Spam-Score: 6.117
X-Spam-Level: ******
X-Spam-Status: No, score=6.117 tagged_above=2 required=6.2
tests=[RCVD_IN_PBL=3.558, RCVD_IN_RP_RNBL=1.284,
RCVD_IN_SORBS_DUL=0.001, RDNS_NONE=1.274]
autolearn=no autolearn_force=no
Received: from mail.garden-life.org ([127.0.0.1])
by mail.garden-life.org (mail.garden-life.org [127.0.0.1]) (amavisd-new, port 10026)
with ESMTP id 3zCxRxppUkZt
for <test123-confirm+b7322edad83ae7ec99cfc5100161c7062d2c7685(a)gjb-online.com>;
Thu, 26 Oct 2017 21:02:15 -0400 (EDT)
Received: from rainmail.deviltracks.net (keys.fspproductions.biz [IPv6:2600:3c03::f03c:91ff:fe24:1eeb])
by mail.garden-life.org (Postfix) with ESMTPSA id 1116A2F1
for <test123-confirm+b7322edad83ae7ec99cfc5100161c7062d2c7685(a)gjb-online.com>; Thu, 26 Oct 2017 21:02:15 -0400 (EDT)
Mime-Version: 1.0
Date: Fri, 27 Oct 2017 01:02:14 +0000
Content-Type: text/plain; charset="utf-8"
Content-Transfer-Encoding: quoted-printable
X-Mailer: RainLoop/1.11.3
From: turtl(a)deviltracks.net
Message-ID: <4e5829300419cfb7bf13d5a0d9ebebd1(a)deviltracks.net>
Subject: Re: confirm b7322edad83ae7ec99cfc5100161c7062d2c7685
To: test123-confirm+b7322edad83ae7ec99cfc5100161c7062d2c7685(a)gjb-online.com
In-Reply-To: <150906420646.31.12186705534373041145@mailman-core>
References: <150906420646.31.12186705534373041145@mailman-core>
X-Originating-IP: 108.53.239.102
October 26, 2017 8:30 PM, test123-confirm+b7322edad83ae7ec99cfc5100161c70=
62d2c7685@gjb-online.com=0Awrote:=0A=0A> Email Address Registration Confi=
rmation=0A> =0A> Hello, this is the GNU Mailman server at gjb-online.com.=
=0A> =0A> We have received a registration request for the email address=
=0A> =0A> turtl(a)deviltracks.net=0A> =0A> Before you can start using GNU M=
ailman at this site, you must first confirm=0A> that this is your email a=
ddress. You can do this by replying to this message,=0A> keeping the Subj=
ect header intact.=0A> =0A> If you do not wish to register this email add=
ress, simply disregard this=0A> message. If you think you are being malic=
iously subscribed to the list, or=0A> have any other questions, you may c=
ontact=0A> =0A> test123-owner(a)gjb-online.com
--2D7231948.1509066137/mail.garden-life.org--
Logs:
mail amavis[1576]: (01576-09) Passed CLEAN {RelayedInternal}, ORIGINATING LOCAL [2600:3c03::f03c:91ff:fe24:1eeb]:33512 [2600:3c03::f03c:91ff:fe24:1eeb] <turtl(a)deviltracks.net> -> <test123-confirm+b7322edad83ae7ec99cfc5100161c7062d2c7685(a)gjb-online.com>, Queue-ID: 15BD218EE, Message-ID: <09b6ea7c3203e7357e4e996c352223d0(a)deviltracks.net>, mail_id: UgTlYoHupO-Z, Hits: 6.117, size: 1663, queued_as: 928292055, dkim_new=dkim:garden-life.org, 451 ms, Tests: [RCVD_IN_PBL=3.558,RCVD_IN_RP_RNBL=1.284,RCVD_IN_SORBS_DUL=0.001,RDNS_NONE=1.274]
Oct 26 21:47:44 mail postfix/smtp-amavis/smtp[19971]: 15BD218EE: to=<test123-confirm+b7322edad83ae7ec99cfc5100161c7062d2c7685(a)gjb-online.com>, relay=127.0.0.1[127.0.0.1]:10026, delay=0.64, delays=0.18/0/0/0.46, dsn=2.0.0, status=sent (250 2.0.0 from MTA(smtp:[127.0.0.1]:10025): 250 2.0.0 Ok: queued as 928292055)
Oct 26 21:47:44 mail postfix/qmgr[1240]: 15BD218EE: removed
Oct 26 21:47:44 mail postfix/smtp[20025]: 928292055: to=<test123-confirm+b7322edad83ae7ec99cfc5100161c7062d2c7685(a)gjb-online.com>, relay=none, delay=0.04, delays=0.01/0.02/0/0, dsn=5.4.6, status=bounced (mail for gjb-online.com loops back to myself)
Oct 26 21:47:44 mail postfix/cleanup[19953]: 9E63E18EE: message-id=<20171027014744.9E63E18EE(a)mail.garden-life.org>
Oct 26 21:47:44 mail postfix/qmgr[1240]: 9E63E18EE: from=<>, size=5273, nrcpt=1 (queue active)
Oct 26 21:47:44 mail postfix/bounce[20027]: 928292055: sender non-delivery notification: 9E63E18EE
Oct 26 21:47:44 mail postfix/qmgr[1240]: 928292055: removed
Oct 26 21:47:44 mail postfix/pipe[19986]: 9E63E18EE: to=<turtl(a)deviltracks.net>, relay=dovecot, delay=0.03, delays=0/0/0/0.03, dsn=2.0.0, status=sent (delivered via dovecot service)
Oct 26 21:47:44 mail postfix/qmgr[1240]: 9E63E18EE: removed
[root@mail ~]#
--
Thanks,
Fabian S.
OpenPGP: 3C3FA072ACCB7AC5DB0F723455502B0EEB9070FC
8 years, 10 months
[MM3-users] Re: Changing web access
by Ralf Wiegand
GNU Mailman 3.3.1 (Tom Sawyer)
Python 3.6.8 (default, Sep 26 2019, 11:57:09)
[GCC 4.8.5 20150623 (Red Hat 4.8.5-39)]
config file: /opt/mailman/mailman/var/etc/mailman.cfg
db url: sqlite:////opt/mailman/mailman/var/data/mailman.db
devmode: DISABLED
REST root url: https://empire:8001/3.1/
REST credentials: r****n:r*****s
My REST API is running on "empire" (192.168.0.27), but isn't this
messages referencing
>>> snip
python manage.py runserver 0.0.0.0:8000
Performing system checks...
System check identified no issues (0 silenced).
April 22, 2020 - 19:05:09
Django version 2.2.12, using settings 'settings'
Starting development server at http://0.0.0.0:8000/
Quit the server with CONTROL-C.
ERROR Mailman REST API not available
Traceback (most recent call last):
File
"/opt/mailman/venv-3.6/lib64/python3.6/site-packages/urllib3-1.25.8-py3.6.egg/urllib3/connection.py",
line 157, in _new_conn
(self._dns_host, self.port), self.timeout, **extra_kw
File
"/opt/mailman/venv-3.6/lib64/python3.6/site-packages/urllib3-1.25.8-py3.6.egg/urllib3/util/connection.py",
line 84, in create_connection
raise err
File
"/opt/mailman/venv-3.6/lib64/python3.6/site-packages/urllib3-1.25.8-py3.6.egg/urllib3/util/connection.py",
line 74, in create_connection
sock.connect(sa)
ConnectionRefusedError: [Errno 111] Connection refused
During handling of the above exception, another exception occurred:
Traceback (most recent call last):
File
"/opt/mailman/venv-3.6/lib64/python3.6/site-packages/urllib3-1.25.8-py3.6.egg/urllib3/connectionpool.py",
line 672, in urlopen
chunked=chunked,
File
"/opt/mailman/venv-3.6/lib64/python3.6/site-packages/urllib3-1.25.8-py3.6.egg/urllib3/connectionpool.py",
line 387, in _make_request
conn.request(method, url, **httplib_request_kw)
File "/usr/lib64/python3.6/http/client.py", line 1254, in request
self._send_request(method, url, body, headers, encode_chunked)
File "/usr/lib64/python3.6/http/client.py", line 1300, in _send_request
self.endheaders(body, encode_chunked=encode_chunked)
File "/usr/lib64/python3.6/http/client.py", line 1249, in endheaders
self._send_output(message_body, encode_chunked=encode_chunked)
File "/usr/lib64/python3.6/http/client.py", line 1036, in _send_output
self.send(msg)
File "/usr/lib64/python3.6/http/client.py", line 974, in send
self.connect()
File
"/opt/mailman/venv-3.6/lib64/python3.6/site-packages/urllib3-1.25.8-py3.6.egg/urllib3/connection.py",
line 184, in connect
conn = self._new_conn()
File
"/opt/mailman/venv-3.6/lib64/python3.6/site-packages/urllib3-1.25.8-py3.6.egg/urllib3/connection.py",
line 169, in _new_conn
self, "Failed to establish a new connection: %s" % e
urllib3.exceptions.NewConnectionError:
<urllib3.connection.HTTPConnection object at 0x7f8dd8cdee80>: Failed to
establish a new connection: [Errno 111] Connection refused
During handling of the above exception, another exception occurred:
Traceback (most recent call last):
File
"/opt/mailman/venv-3.6/lib64/python3.6/site-packages/requests-2.23.0-py3.6.egg/requests/adapters.py",
line 449, in send
timeout=timeout
File
"/opt/mailman/venv-3.6/lib64/python3.6/site-packages/urllib3-1.25.8-py3.6.egg/urllib3/connectionpool.py",
line 720, in urlopen
method, url, error=e, _pool=self, _stacktrace=sys.exc_info()[2]
File
"/opt/mailman/venv-3.6/lib64/python3.6/site-packages/urllib3-1.25.8-py3.6.egg/urllib3/util/retry.py",
line 436, in increment
raise MaxRetryError(_pool, url, error or ResponseError(cause))
urllib3.exceptions.MaxRetryError: HTTPConnectionPool(host='localhost',
port=8001): Max retries exceeded with url:
/3.0/lists?advertised=true&count=0&page=1 (Caused by
NewConnectionError('<urllib3.connection.HTTPConnection object at
0x7f8dd8cdee80>: Failed to establish a new connection: [Errno 111]
Connection refused',))
During handling of the above exception, another exception occurred:
Traceback (most recent call last):
File
"/opt/mailman/mailmanclient/src/mailmanclient/restbase/connection.py",
line 96, in call
headers=headers)
File
"/opt/mailman/venv-3.6/lib64/python3.6/site-packages/requests-2.23.0-py3.6.egg/requests/api.py",
line 61, in request
return session.request(method=method, url=url, **kwargs)
File
"/opt/mailman/venv-3.6/lib64/python3.6/site-packages/requests-2.23.0-py3.6.egg/requests/sessions.py",
line 530, in request
resp = self.send(prep, **send_kwargs)
File
"/opt/mailman/venv-3.6/lib64/python3.6/site-packages/requests-2.23.0-py3.6.egg/requests/sessions.py",
line 643, in send
r = adapter.send(request, **kwargs)
File
"/opt/mailman/venv-3.6/lib64/python3.6/site-packages/requests-2.23.0-py3.6.egg/requests/adapters.py",
line 516, in send
raise ConnectionError(e, request=request)
requests.exceptions.ConnectionError:
HTTPConnectionPool(host='localhost', port=8001): Max retries exceeded
with url: /3.0/lists?advertised=true&count=0&page=1 (Caused by
NewConnectionError('<urllib3.connection.HTTPConnection object at
0x7f8dd8cdee80>: Failed to establish a new connection: [Errno 111]
Connection refused',))
During handling of the above exception, another exception occurred:
Traceback (most recent call last):
File
"/opt/mailman/venv-3.6/lib64/python3.6/site-packages/Django-2.2.12-py3.6.egg/django/core/handlers/base.py",
line 113, in _get_response
response = wrapped_callback(request, *callback_args, **callback_kwargs)
File "/opt/mailman/postorius/src/postorius/views/list.py", line 755,
in list_index
paginator_class=MailmanPaginator)
File "/opt/mailman/django-mailman3/django_mailman3/lib/paginator.py",
line 71, in paginate
objects = paginator.page(page_num)
File "/opt/mailman/django-mailman3/django_mailman3/lib/paginator.py",
line 46, in page
number = self.validate_number(number)
File
"/opt/mailman/venv-3.6/lib64/python3.6/site-packages/Django-2.2.12-py3.6.egg/django/core/paginator.py",
line 48, in validate_number
if number > self.num_pages:
File
"/opt/mailman/venv-3.6/lib64/python3.6/site-packages/Django-2.2.12-py3.6.egg/django/utils/functional.py",
line 80, in __get__
res = instance.__dict__[self.name] = self.func(instance)
File
"/opt/mailman/venv-3.6/lib64/python3.6/site-packages/Django-2.2.12-py3.6.egg/django/core/paginator.py",
line 97, in num_pages
if self.count == 0 and not self.allow_empty_first_page:
File
"/opt/mailman/venv-3.6/lib64/python3.6/site-packages/Django-2.2.12-py3.6.egg/django/utils/functional.py",
line 80, in __get__
res = instance.__dict__[self.name] = self.func(instance)
File "/opt/mailman/django-mailman3/django_mailman3/lib/paginator.py",
line 56, in count
return self.function(count=0, page=1).total_size
File "/opt/mailman/postorius/src/postorius/views/list.py", line 751,
in _get_list_page
advertised=advertised, mail_host=mail_host, count=count, page=page)
File "/opt/mailman/mailmanclient/src/mailmanclient/client.py", line
181, in get_list_page
return Page(self._connection, url, MailingList, count, page)
File "/opt/mailman/mailmanclient/src/mailmanclient/restbase/page.py",
line 37, in __init__
self._create_page()
File "/opt/mailman/mailmanclient/src/mailmanclient/restbase/page.py",
line 62, in _create_page
response, content = self._connection.call(self._build_url())
File
"/opt/mailman/mailmanclient/src/mailmanclient/restbase/connection.py",
line 120, in call
'Could not connect to Mailman API: ', repr(e))
mailmanclient.restbase.connection.MailmanConnectionError: ('Could not
connect to Mailman API: ',
'ConnectionError(MaxRetryError("HTTPConnectionPool(host=\'localhost\',
port=8001): Max retries exceeded with url:
/3.0/lists?advertised=true&count=0&page=1 (Caused by
NewConnectionError(\'<urllib3.connection.HTTPConnection object at
0x7f8dd8cdee80>: Failed to establish a new connection: [Errno 111]
Connection refused\',))",),)')
<<<< snip
not sure I understand???
On 4/22/20 2:50 PM, Mark Sapiro wrote:
> On 4/22/20 11:35 AM, Ralf Wiegand wrote:
>> but I am getting :
>>
>> mailmanclient.restbase.connection.MailmanConnectionError: ('Could not
>> connect to Mailman API: ',
>> 'ConnectionError(MaxRetryError("HTTPConnectionPool(host=\'localhost\',
>> port=8001): Max retries exceeded with url:
>> /3.0/lists?advertised=true&count=0&page=1 (Caused by
>> NewConnectionError(\'<urllib3.connection.HTTPConnection object at
>> 0x7f88fe4cb4e0>: Failed to establish a new connection: [Errno 111]
>> Connection refused\',))",),)')
>
> What do you have for ALLOWED_HOSTS in your settings file(s)? You may
> want something like
>
> ALLOWED_HOSTS = ['*']
>
> or
>
> ALLOWED_HOSTS = ['192.168.*']
>
6 years, 4 months
[MM3-users] Re: Archive not working - Reg.
by Nirmal J
Yes, There are files in that Directory.
root@list1:/var/lib/mailman3/archives/hyperkitty/spool# ls
1761648373.8935+904b919ee2129941efb5359d7fbc08cc66e154c8.pck 1761648373.917401+f2d75be071a12b44949318373ebcb0b05cf8341e.pck
root@list1:/var/lib/mailman3/archives/hyperkitty/spool#
The Mailmans var.logs/mailman.log contains
root@list1:/var/log/mailman3# cat mailman.log
Oct 29 00:00:03 2025 (678809) Master watcher caught SIGHUP. Re-opening log files.
Oct 29 00:00:03 2025 (678814) archive runner caught SIGHUP. Reopening logs.
Oct 29 00:00:03 2025 (678826) task runner caught SIGHUP. Reopening logs.
Oct 29 00:00:03 2025 (678815) bounces runner caught SIGHUP. Reopening logs.
Oct 29 00:00:03 2025 (678816) command runner caught SIGHUP. Reopening logs.
Oct 29 00:00:03 2025 (678818) lmtp runner caught SIGHUP. Reopening logs.
Oct 29 00:00:03 2025 (678827) virgin runner caught SIGHUP. Reopening logs.
Oct 29 00:00:03 2025 (678820) out runner caught SIGHUP. Reopening logs.
Oct 29 00:00:03 2025 (678821) pipeline runner caught SIGHUP. Reopening logs.
Oct 29 00:00:03 2025 (678817) in runner caught SIGHUP. Reopening logs.
Oct 29 00:00:03 2025 (678828) digest runner caught SIGHUP. Reopening logs.
Oct 29 00:00:03 2025 (678819) nntp runner caught SIGHUP. Reopening logs.
Oct 29 00:00:03 2025 (678823) retry runner caught SIGHUP. Reopening logs.
[2025-10-29 00:00:03 +0530] [683726] [INFO] Booting worker with pid: 683726
[2025-10-29 00:00:03 +0530] [678822] [WARNING] Worker with pid 678843 was terminated due to signal 15
[2025-10-29 00:00:03 +0530] [683727] [INFO] Booting worker with pid: 683727
[2025-10-29 00:00:03 +0530] [678822] [WARNING] Worker with pid 678844 was terminated due to signal 15
Oct 29 00:14:05 2025 (678826) Task runner evicted 0 expired pendings
Oct 29 00:14:05 2025 (678826) Task runner deleted 0 orphaned workflows
Oct 29 00:14:05 2025 (678826) Task runner deleted 0 orphaned requests
Oct 29 00:14:05 2025 (678826) Task runner deleted 0 orphaned messages
Oct 29 00:14:05 2025 (678826) Task runner evicted expired cache entries
[29/Oct/2025:01:00:02 +0530] "GET /3.1/lists?count=10&page=1 HTTP/1.1" 200 473 "-" "GNU Mailman REST client v3.3.5"
Oct 29 01:14:05 2025 (678826) Task runner evicted 0 expired pendings
Oct 29 01:14:05 2025 (678826) Task runner deleted 0 orphaned workflows
Oct 29 01:14:05 2025 (678826) Task runner deleted 0 orphaned requests
Oct 29 01:14:05 2025 (678826) Task runner deleted 0 orphaned messages
Oct 29 01:14:05 2025 (678826) Task runner evicted expired cache entries
[29/Oct/2025:02:00:01 +0530] "GET /3.1/lists?count=10&page=1 HTTP/1.1" 200 473 "-" "GNU Mailman REST client v3.3.5"
Oct 29 02:14:05 2025 (678826) Task runner evicted 0 expired pendings
Oct 29 02:14:05 2025 (678826) Task runner deleted 0 orphaned workflows
Oct 29 02:14:05 2025 (678826) Task runner deleted 0 orphaned requests
Oct 29 02:14:05 2025 (678826) Task runner deleted 0 orphaned messages
Oct 29 02:14:05 2025 (678826) Task runner evicted expired cache entries
[29/Oct/2025:03:00:02 +0530] "GET /3.1/lists?count=10&page=1 HTTP/1.1" 200 473 "-" "GNU Mailman REST client v3.3.5"
Oct 29 03:14:05 2025 (678826) Task runner evicted 0 expired pendings
Oct 29 03:14:05 2025 (678826) Task runner deleted 0 orphaned workflows
Oct 29 03:14:05 2025 (678826) Task runner deleted 0 orphaned requests
Oct 29 03:14:05 2025 (678826) Task runner deleted 0 orphaned messages
Oct 29 03:14:05 2025 (678826) Task runner evicted expired cache entries
[29/Oct/2025:04:00:02 +0530] "GET /3.1/lists?count=10&page=1 HTTP/1.1" 200 473 "-" "GNU Mailman REST client v3.3.5"
Oct 29 04:14:05 2025 (678826) Task runner evicted 0 expired pendings
Oct 29 04:14:05 2025 (678826) Task runner deleted 0 orphaned workflows
Oct 29 04:14:05 2025 (678826) Task runner deleted 0 orphaned requests
Oct 29 04:14:05 2025 (678826) Task runner deleted 0 orphaned messages
Oct 29 04:14:05 2025 (678826) Task runner evicted expired cache entries
[29/Oct/2025:05:00:01 +0530] "GET /3.1/lists?count=10&page=1 HTTP/1.1" 200 473 "-" "GNU Mailman REST client v3.3.5"
Oct 29 05:14:05 2025 (678826) Task runner evicted 0 expired pendings
Oct 29 05:14:05 2025 (678826) Task runner deleted 0 orphaned workflows
Oct 29 05:14:05 2025 (678826) Task runner deleted 0 orphaned requests
Oct 29 05:14:05 2025 (678826) Task runner deleted 0 orphaned messages
Oct 29 05:14:05 2025 (678826) Task runner evicted expired cache entries
[29/Oct/2025:06:00:02 +0530] "GET /3.1/lists?count=10&page=1 HTTP/1.1" 200 473 "-" "GNU Mailman REST client v3.3.5"
Oct 29 06:14:05 2025 (678826) Task runner evicted 0 expired pendings
Oct 29 06:14:05 2025 (678826) Task runner deleted 0 orphaned workflows
Oct 29 06:14:05 2025 (678826) Task runner deleted 0 orphaned requests
Oct 29 06:14:05 2025 (678826) Task runner deleted 0 orphaned messages
Oct 29 06:14:05 2025 (678826) Task runner evicted expired cache entries
[29/Oct/2025:07:00:01 +0530] "GET /3.1/lists?count=10&page=1 HTTP/1.1" 200 473 "-" "GNU Mailman REST client v3.3.5"
Oct 29 07:14:05 2025 (678826) Task runner evicted 0 expired pendings
Oct 29 07:14:05 2025 (678826) Task runner deleted 0 orphaned workflows
Oct 29 07:14:05 2025 (678826) Task runner deleted 0 orphaned requests
Oct 29 07:14:05 2025 (678826) Task runner deleted 0 orphaned messages
Oct 29 07:14:05 2025 (678826) Task runner evicted expired cache entries
[29/Oct/2025:08:00:02 +0530] "GET /3.1/lists?count=10&page=1 HTTP/1.1" 200 473 "-" "GNU Mailman REST client v3.3.5"
Oct 29 08:14:05 2025 (678826) Task runner evicted 0 expired pendings
Oct 29 08:14:05 2025 (678826) Task runner deleted 0 orphaned workflows
Oct 29 08:14:05 2025 (678826) Task runner deleted 0 orphaned requests
Oct 29 08:14:05 2025 (678826) Task runner deleted 0 orphaned messages
Oct 29 08:14:05 2025 (678826) Task runner evicted expired cache entries
[29/Oct/2025:09:00:02 +0530] "GET /3.1/lists?count=10&page=1 HTTP/1.1" 200 473 "-" "GNU Mailman REST client v3.3.5"
Oct 29 09:14:05 2025 (678826) Task runner evicted 0 expired pendings
Oct 29 09:14:05 2025 (678826) Task runner deleted 0 orphaned workflows
Oct 29 09:14:05 2025 (678826) Task runner deleted 0 orphaned requests
Oct 29 09:14:05 2025 (678826) Task runner deleted 0 orphaned messages
Oct 29 09:14:05 2025 (678826) Task runner evicted expired cache entries
-----Original Message-----
From: Mark <mark(a)msapiro.net>
To: mailman-users <mailman-users(a)mailman3.org>
Date: Tuesday, 28 October 2025 9:16 PM IST
Subject: [MM3-users] Re: Archive not working - Reg.
On 10/28/25 03:22, nirmal--- via Mailman-users wrote:
> After sending mail to a list, it is not reflecting back in Hyperkitty archive. Kindly help me in this regard.
Are there files in Mailman's var/archives/hyperkitty/spool/ direrctory?
What's in Mailman's var/logs/mailman.log?
--
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/
Archived at: https://lists.mailman3.org/archives/list/mailman-users@mailman3.org/message…
This message sent to nirmal(a)iitm.ac.in
10 months, 2 weeks
[MM3-users] Re: converting bulk accept_these_nonmembers in migration from mailman 2 to 3
by Lucio Chiappetti
Dear Mark, thanks for your interest.
On Fri, 11 Feb 2022, Mark Sapiro wrote:
> This may actually be a bug. I'll have to think about that. I've filed
> https://gitlab.com/mailman/mailman/-/issues/978 on this.
> This is https://gitlab.com/mailman/mailman/-/issues/794 (still open)
Given the time needed to solve the issues (I will anyhow notify the site
administrators, hopting they would update mailman when/if resolved), this
means we have to find a workaround.
> And those non-members all have there moderation action set to Defer
> which means their posts will be accepted but the additional checks such
> as too big, etc. will still be applied.
not sure what you mean by "defer". The non-member options I see are called
List default -- follow the list's default member action.
Hold -- This holds the message for approval by the list moderators.
Reject -- this automatically rejects the message by sending a bounce
notice to the post's author. The text of the bounce notice can be
configured by you.
Discard -- this simply discards the message, with no notice sent to the
post's author.
Accept -- accepts any postings without any further checks.
Default Processing -- run additional checks and accept the message.
> If they are nonmembers, you can accept the post and set moderation
> action in one operation in Postorius, but the regexps in
> hold_these_nonmembers will still take precedence.
OK, I've found where to do it, it requires to select the held message and
scroll to the bottom then set Moderation from a menu.
But if hold_these_nonmembers takes priority this will be uselesws in the
current setting.
> I'm not sure what you are looking at here. Imported nonmembers should
> all have moderation action set according to which *_these_nonmembers
> they came from. Imported members should have their moderation action set
> to Defer if they were unmoderated and if they were moderated, it should
> be set based on the 2.1 list's member_moderation_action.
I go to the non-member list, select non-member options and at the bottom
see an item Administration options Moderation. The possible values are
those I pasted above.
The actual value for most of the imported non-members is "Default
processing" while it is "List default" for thoase automatically added
afresh, It is "Discard" for a number of imported non-members with
spam-looking addresses (I guess they were in some other *_not_members part
of the standard 2.1 antispam ... I can't recall me doing something on
those)
Side question: is there a way to operate IN BULK on non-members ? Like it
is for members (I exported them to CSV).
>> - if so, how can we do it automatically for all 189 entries ?
>> - or move back the 189 addresses to accept_these_nonmembers ?
> Yes, move them back.
I am not so concerned of these 189 (or better of the 189 minus the discard
ones which should stay) ... anyhow moving them back will be uncomfortable
if there is not a bulk operation tool.
I am more concerned of the new cases automatically added.
Our member list includes 1043 addresses. Of these less than 20 use an
external address (say gmail), so they post "from home" and will pass.
194 addresses are of the form name.surname(a)inaf.it (these are likely to be
recently hired staff, who have and use onlyu the organization-wide
address).
All the rest (so still more than 800, can't really ask all of them to
re-register (*)) are of the form username(a)institute.inaf.it (and it won't
be easy also to bulk-delete and bulk-resubscribe because of the
inhomogeneous mapping of username to name.surname.
Of these about 800 some are lurkers and are no problem. Some are frequent
posters and remember to post from username(a)institute.inaf.it and are no
problem. Other may post from an alternate address (maybe even the old
address exists as a receiving-only alias), and in this case with
the current arrangement they will bo on hold every time.
I guess we should wait for the solution of issue 794
(*) by the way do you confirm that if one is subscribed to a list with an
address (be it bulk subscription, import or new fast subscription), this
person CANNOT change their settings (or address) unless one does a "sign
in" to a (Postorius) account ?
> It is because all the legacy *_these_nonmember actions are applied
> before nonmember moderation checks, so if an address matches a regex in
> hold_these_nonmembers, the post will be held regardless of the
> nonmember's moderation action.
> Addresses still work, and accept_these_nonmembers takes precedence over
> hold_these_nonmembers just as in MM 2.1.
This was not my impression when I ran a thorough test of 12 cases. Except
the obvious case of the subscriber posting from the subscription address,
all messages went on hold.
Whatever the non-member moderation would be (even if set to reject ! ...
but that makes sense if *_these_nonmembers prevail on non-member options),
and even if the address was set explicitly in accept_these_nonmembers
(should I delete it from the non-member list ?)
What is the actual order (or flow chart) of choices ?
*_these_nonmembers in the order listed in the page (within each in the
order of occurrence of regexp's) then non-member options ?
If I have Name.Surname(a)inaf.it in accept_these_nonmembers, then
hold_these_nonmembers set to
^.+@.+\.it
^.+@.+\.tng\.iac\.es
what do you foresee ?
And for different regexps, will processing terminate at the first
non-matching one, will they be ANDed or ORed, or what ?
I am reluctant to accept inconditionally ^.+\..+(a)inaf\.it (they may be
falsified, only the check on their presence in the other list (issue 794)
I guess I should remove the ^.+@.+\.it regexp AND AT THE SAME TIME change
the Default action to take when a non-member posts to the list to Hold
instead of Discard.
This way we'll have to check spam (instead of having it auto-discarded),
but if people with alternate addresses post, once they are entered in the
Non-member list they can be authorized to pass for the future ...
.. would it work ?
--
Lucio Chiappetti - INAF/IASF - via Corti 12 - I-20133 Milano (Italy)
For more info : http://www.iasf-milano.inaf.it/~lucio/personal.html
4 years, 7 months
[MM3-users] Re: Migrating mailman3 to latest ubuntu lts
by Helio Loureiro
And using the module manually works...
(venv) mailman@new-server ~ (v3.3.9) [0|127]> *ipython3*
/usr/lib/python3/dist-packages/IPython/core/interactiveshell.py:949:
UserWarning: Attempting to work in a virtualenv. If you encounter problems,
please install IPython inside the virtualenv.
warn(
Python 3.10.12 (main, Jun 11 2023, 05:26:28) [GCC 11.4.0]
Type 'copyright', 'credits' or 'license' for more information
IPython 7.31.1 -- An enhanced Interactive Python. Type '?' for help.
In [1]: *import MySQLdb*
(venv) mailman@new-sever ~ (v3.3.9)> *fg*
Send job 1, 'ipython3' to foreground
In [3]: *con = MySQLdb.connect("localhost", "mailman3web",
"*****************", "mailman3web")*
In [4]:
*cursor = con.cursor()*
In [5]: *cursor.execute("show tables")*
Out[5]: 34
In [6]: *print(cursor.fetchall())*
(('account_emailaddress',), ('account_emailconfirmation',),
('auth_group',), ('auth_group_permissions',), ('auth_permission',),
('auth_user',), ('auth_user_groups',), ('auth_user_user_permissions',),
('django_admin_log',), ('django_content_type',),
('django_mailman3_maildomain',), ('django_mailman3_profile',),
('django_migrations',), ('django_q_ormq',), ('django_q_schedule',),
('django_q_task',), ('django_session',), ('django_site',),
('hyperkitty_attachment',), ('hyperkitty_email',),
('hyperkitty_favorite',), ('hyperkitty_lastview',),
('hyperkitty_mailinglist',), ('hyperkitty_profile',),
('hyperkitty_sender',), ('hyperkitty_tag',), ('hyperkitty_tagging',),
('hyperkitty_thread',), ('hyperkitty_threadcategory',),
('hyperkitty_vote',), ('socialaccount_socialaccount',),
('socialaccount_socialapp',), ('socialaccount_socialapp_sites',),
('socialaccount_socialtoken',))
In [7]: *cursor.execute("select * from account_emailaddress")*
Out[7]: 2530
In [8]: *print(cursor.fetchall())*
So what can I do? Is there a way to troubleshoot the root cause of this
issue?
Best Regards,
Helio Loureiro
https://helio.loureiro.eng.br
https://github.com/helioloureiro
https://mastodon.social/@helioloureiro
On Tue, 19 Dec 2023 at 11:11, Helio Loureiro <helio(a)loureiro.eng.br> wrote:
> Hi,
>
> No luck :(
>
> (venv) mailman@new-server ~ (v3.3.9)> *pip freeze | egrep
> "mailman-web|django-mailman3|django-allauth"*
> django-allauth==0.59.0
> django-mailman3==1.3.11
> mailman-web==0.0.8
> (venv) mailman@new-server ~ (v3.3.9)> *pip install -U
> django-allauth==0.58.0*
> Collecting django-allauth==0.58.0
> Downloading django-allauth-0.58.0.tar.gz (861 kB)
> ---------------------------------------- 861.7/861.7 KB 9.4 MB/s eta
> 0:00:00
> Installing build dependencies ... done
> Getting requirements to build wheel ... done
> Installing backend dependencies ... done
> Preparing metadata (pyproject.toml) ... done
> Requirement already satisfied: requests-oauthlib>=0.3.0 in
> ./venv/lib/python3.10/site-packages (from django-allauth==0.58.0) (1.3.1)
> Requirement already satisfied: Django>=3.2 in
> ./venv/lib/python3.10/site-packages (from django-allauth==0.58.0) (4.1.13)
> Requirement already satisfied: pyjwt[crypto]>=1.7 in
> ./venv/lib/python3.10/site-packages (from django-allauth==0.58.0) (2.8.0)
> Requirement already satisfied: requests>=2.0.0 in
> ./venv/lib/python3.10/site-packages (from django-allauth==0.58.0) (2.31.0)
> Requirement already satisfied: python3-openid>=3.0.8 in
> ./venv/lib/python3.10/site-packages (from django-allauth==0.58.0) (3.2.0)
> Requirement already satisfied: asgiref<4,>=3.5.2 in
> ./venv/lib/python3.10/site-packages (from
> Django>=3.2->django-allauth==0.58.0) (3.7.2)
> Requirement already satisfied: sqlparse>=0.2.2 in
> ./venv/lib/python3.10/site-packages (from
> Django>=3.2->django-allauth==0.58.0) (0.4.4)
> Requirement already satisfied: cryptography>=3.4.0 in
> ./venv/lib/python3.10/site-packages (from
> pyjwt[crypto]>=1.7->django-allauth==0.58.0) (41.0.7)
> Requirement already satisfied: defusedxml in
> ./venv/lib/python3.10/site-packages (from
> python3-openid>=3.0.8->django-allauth==0.58.0) (0.7.1)
> Requirement already satisfied: urllib3<3,>=1.21.1 in
> ./venv/lib/python3.10/site-packages (from
> requests>=2.0.0->django-allauth==0.58.0) (2.1.0)
> Requirement already satisfied: charset-normalizer<4,>=2 in
> ./venv/lib/python3.10/site-packages (from
> requests>=2.0.0->django-allauth==0.58.0) (3.3.2)
> Requirement already satisfied: idna<4,>=2.5 in
> ./venv/lib/python3.10/site-packages (from
> requests>=2.0.0->django-allauth==0.58.0) (3.6)
> Requirement already satisfied: certifi>=2017.4.17 in
> ./venv/lib/python3.10/site-packages (from
> requests>=2.0.0->django-allauth==0.58.0) (2023.11.17)
> Requirement already satisfied: oauthlib>=3.0.0 in
> ./venv/lib/python3.10/site-packages (from
> requests-oauthlib>=0.3.0->django-allauth==0.58.0) (3.2.2)
> Requirement already satisfied: typing-extensions>=4 in
> ./venv/lib/python3.10/site-packages (from
> asgiref<4,>=3.5.2->Django>=3.2->django-allauth==0.58.0) (4.9.0)
> Requirement already satisfied: cffi>=1.12 in
> ./venv/lib/python3.10/site-packages (from
> cryptography>=3.4.0->pyjwt[crypto]>=1.7->django-allauth==0.58.0) (1.16.0)
> Requirement already satisfied: pycparser in
> ./venv/lib/python3.10/site-packages (from
> cffi>=1.12->cryptography>=3.4.0->pyjwt[crypto]>=1.7->django-allauth==0.58.0)
> (2.21)
> Building wheels for collected packages: django-allauth
> Building wheel for django-allauth (pyproject.toml) ... done
> Created wheel for django-allauth:
> filename=django_allauth-0.58.0-py3-none-any.whl size=1157319
> sha256=a430c552101d1ad47bc00b16d1c1d6df728afacdd13823927b4cbfb02c35dbfc
> Stored in directory:
> /local/mailman/.cache-ubuntu-22.04/pip/wheels/55/0a/79/e199827a18f310906c2a90b0e92b89c41daf21d2a502db6710
> Successfully built django-allauth
> Installing collected packages: django-allauth
> Attempting uninstall: django-allauth
> Found existing installation: django-allauth 0.59.0
> Uninstalling django-allauth-0.59.0:
> Successfully uninstalled django-allauth-0.59.0
> Successfully installed django-allauth-0.58.0
> (venv) mailman@new-server ~ (v3.3.9)> *mailman-web migrate*
> System check identified some issues:
>
> WARNINGS:
> account.EmailAddress: (models.W036) MariaDB does not support unique
> constraints with conditions.
> HINT: A constraint won't be created. Silence this warning if you don't
> care about it.
> account.EmailAddress: (models.W043) MariaDB does not support indexes on
> expressions.
> HINT: An index won't be created. Silence this warning if you don't care
> about it.
> Operations to perform:
> Apply all migrations: account, admin, auth, contenttypes,
> django_mailman3, django_q, hyperkitty, postorius, sessions, sites,
> socialaccount
> Running migrations:
> Applying account.0004_alter_emailaddress_drop_unique_email...Traceback
> (most recent call last):
> File
> "/local/mailman/venv/lib/python3.10/site-packages/django/db/backends/utils.py",
> line 89, in _execute
> return self.cursor.execute(sql, params)
> File
> "/local/mailman/venv/lib/python3.10/site-packages/django/db/backends/mysql/base.py",
> line 75, in execute
> return self.cursor.execute(query, args)
> File
> "/local/mailman/venv/lib/python3.10/site-packages/MySQLdb/cursors.py", line
> 179, in execute
> res = self._query(mogrified_query)
> File
> "/local/mailman/venv/lib/python3.10/site-packages/MySQLdb/cursors.py", line
> 330, in _query
> db.query(q)
> File
> "/local/mailman/venv/lib/python3.10/site-packages/MySQLdb/connections.py",
> line 257, in query
> _mysql.connection.query(self, query)
> MySQLdb.OperationalError: (2013, 'Lost connection to MySQL server during
> query')
>
> The above exception was the direct cause of the following exception:
>
> Traceback (most recent call last):
> File "/local/mailman/venv/bin/mailman-web", line 8, in <module>
> sys.exit(main())
> File
> "/local/mailman/venv/lib/python3.10/site-packages/mailman_web/manage.py",
> line 90, in main
> execute_from_command_line(sys.argv)
> File
> "/local/mailman/venv/lib/python3.10/site-packages/django/core/management/__init__.py",
> line 446, in execute_from_command_line
> utility.execute()
> File
> "/local/mailman/venv/lib/python3.10/site-packages/django/core/management/__init__.py",
> line 440, in execute
> self.fetch_command(subcommand).run_from_argv(self.argv)
> File
> "/local/mailman/venv/lib/python3.10/site-packages/django/core/management/base.py",
> line 402, in run_from_argv
> self.execute(*args, **cmd_options)
> File
> "/local/mailman/venv/lib/python3.10/site-packages/django/core/management/base.py",
> line 448, in execute
> output = self.handle(*args, **options)
> File
> "/local/mailman/venv/lib/python3.10/site-packages/django/core/management/base.py",
> line 96, in wrapped
> res = handle_func(*args, **kwargs)
> File
> "/local/mailman/venv/lib/python3.10/site-packages/django/core/management/commands/migrate.py",
> line 349, in handle
> post_migrate_state = executor.migrate(
> File
> "/local/mailman/venv/lib/python3.10/site-packages/django/db/migrations/executor.py",
> line 135, in migrate
> state = self._migrate_all_forwards(
> File
> "/local/mailman/venv/lib/python3.10/site-packages/django/db/migrations/executor.py",
> line 167, in _migrate_all_forwards
> state = self.apply_migration(
> File
> "/local/mailman/venv/lib/python3.10/site-packages/django/db/migrations/executor.py",
> line 252, in apply_migration
> state = migration.apply(state, schema_editor)
> File
> "/local/mailman/venv/lib/python3.10/site-packages/django/db/migrations/migration.py",
> line 130, in apply
> operation.database_forwards(
> File
> "/local/mailman/venv/lib/python3.10/site-packages/django/db/migrations/operations/fields.py",
> line 235, in database_forwards
> schema_editor.alter_field(from_model, from_field, to_field)
> File
> "/local/mailman/venv/lib/python3.10/site-packages/django/db/backends/base/schema.py",
> line 788, in alter_field
> self._alter_field(
> File
> "/local/mailman/venv/lib/python3.10/site-packages/django/db/backends/base/schema.py",
> line 858, in _alter_field
> self.execute(self._delete_unique_sql(model, constraint_name))
> File
> "/local/mailman/venv/lib/python3.10/site-packages/django/db/backends/base/schema.py",
> line 199, in execute
> cursor.execute(sql, params)
> File
> "/local/mailman/venv/lib/python3.10/site-packages/django/db/backends/utils.py",
> line 67, in execute
> return self._execute_with_wrappers(
> File
> "/local/mailman/venv/lib/python3.10/site-packages/django/db/backends/utils.py",
> line 80, in _execute_with_wrappers
> return executor(sql, params, many, context)
> File
> "/local/mailman/venv/lib/python3.10/site-packages/django/db/backends/utils.py",
> line 84, in _execute
> with self.db.wrap_database_errors:
> File
> "/local/mailman/venv/lib/python3.10/site-packages/django/db/utils.py", line
> 91, in __exit__
> raise dj_exc_value.with_traceback(traceback) from exc_value
> File
> "/local/mailman/venv/lib/python3.10/site-packages/django/db/backends/utils.py",
> line 89, in _execute
> return self.cursor.execute(sql, params)
> File
> "/local/mailman/venv/lib/python3.10/site-packages/django/db/backends/mysql/base.py",
> line 75, in execute
> return self.cursor.execute(query, args)
> File
> "/local/mailman/venv/lib/python3.10/site-packages/MySQLdb/cursors.py", line
> 179, in execute
> res = self._query(mogrified_query)
> File
> "/local/mailman/venv/lib/python3.10/site-packages/MySQLdb/cursors.py", line
> 330, in _query
> db.query(q)
> File
> "/local/mailman/venv/lib/python3.10/site-packages/MySQLdb/connections.py",
> line 257, in query
> _mysql.connection.query(self, query)
> django.db.utils.OperationalError: (2013, 'Lost connection to MySQL server
> during query')
> (venv) mailman@new-server ~ (v3.3.9) [0|1]> *more
> /etc/mailman3/settings.py*
> # Mailman Web configuration file.
> # /etc/mailman3/settings.py
>
> # Get the default settings.
> from mailman_web.settings.base import *
> from mailman_web.settings.mailman import *
>
> # Settings below supplement or override the defaults.
>
> #: Default list of admins who receive the emails from error logging.
> ADMINS = (
> ('Mailman Suite Admin', 'root@localhost'),
> )
>
> # Postgresql database setup.
> DATABASES = {
> 'default': {
> 'ENGINE': 'django.db.backends.mysql',
> 'NAME': 'mailman3web',
> 'USER': 'mailman3web',
> # TODO: Replace this with the password.
> 'PASSWORD': '***********',
> 'HOST': 'localhost',
> # PORT: set to empty string for default.
> 'PORT': '3306',
> # OPTIONS: Extra parameters to use when connecting to the database.
> #'OPTIONS': {
> # Set sql_mode to 'STRICT_TRANS_TABLES' for MySQL. See
> # https://docs.djangoproject.com/en/1.11/ref/
> # databases/#setting-sql-mode
> # 'init_command': "SET sql_mode='STRICT_TRANS_TABLES'",
> # 'charset': 'utf8mb4',
> #},
>
> }
> }
>
> # 'collectstatic' command will copy all the static files here.
> # Alias this location from your webserver to `/static`
> STATIC_ROOT = '/local/mailman/web/static'
>
> # enable the 'compress' command.
> COMPRESS_ENABLED = True
>
> # Make sure that this directory is created or Django will fail on start.
> LOGGING['handlers']['file']['filename'] =
> '/local/mailman/web/logs/mailmanweb.log'
>
> #: See https://docs.djangoproject.com/en/dev/ref/settings/#allowed-hosts
> ALLOWED_HOSTS = [
> "localhost", # Archiving API from Mailman, keep it.
> "127.0.0.1",
> # "lists.your-domain.org",
> # Add here all production domains you have.
> "*"
> ]
>
> #: See
> https://docs.djangoproject.com/en/dev/ref/settings/#csrf-trusted-origins
> (venv) mailman@new-server ~ (v3.3.9)> *mysql -umailman3web -p -h
> localhost mailman3web*
> Enter password:
> Reading table information for completion of table and column names
> You can turn off this feature to get a quicker startup with -A
>
> Welcome to the MariaDB monitor. Commands end with ; or \g.
> Your MariaDB connection id is 32
> Server version: 10.6.12-MariaDB-0ubuntu0.22.04.1 Ubuntu 22.04
>
> Copyright (c) 2000, 2018, Oracle, MariaDB Corporation Ab and others.
>
> Type 'help;' or '\h' for help. Type '\c' to clear the current input
> statement.
>
> MariaDB [mailman3web]> show tables;
> +-------------------------------+
> | Tables_in_mailman3web |
> +-------------------------------+
> | account_emailaddress |
> | account_emailconfirmation |
> | auth_group |
> | auth_group_permissions |
> | auth_permission |
> | auth_user |
> | auth_user_groups |
> | auth_user_user_permissions |
> | django_admin_log |
> | django_content_type |
> | django_mailman3_maildomain |
> | django_mailman3_profile |
> | django_migrations |
> | django_q_ormq |
> | django_q_schedule |
> | django_q_task |
> | django_session |
> | django_site |
> | hyperkitty_attachment |
> | hyperkitty_email |
> | hyperkitty_favorite |
> | hyperkitty_lastview |
> | hyperkitty_mailinglist |
> | hyperkitty_profile |
> | hyperkitty_sender |
> | hyperkitty_tag |
> | hyperkitty_tagging |
> | hyperkitty_thread |
> | hyperkitty_threadcategory |
> | hyperkitty_vote |
> | socialaccount_socialaccount |
> | socialaccount_socialapp |
> | socialaccount_socialapp_sites |
> | socialaccount_socialtoken |
> +-------------------------------+
> 34 rows in set (0.000 sec)
>
> Best Regards,
> Helio Loureiro
> https://helio.loureiro.eng.br
> https://github.com/helioloureiro
> https://mastodon.social/@helioloureiro
>
>
> On Mon, 18 Dec 2023 at 17:11, Mark Sapiro <mark(a)msapiro.net> wrote:
>
>> On 12/18/23 6:24 AM, Helio Loureiro wrote:
>> > Hi,
>> >
>> > Indeed it was the configuration. It was placed into
>> > /etc/mailman3/mailman-web.py. After a I changed to
>> > /etc/mailman3/settings.py a few things advanced a little bit more.
>> >
>> > I had to figure out how to fix mysqlclient installation since there
>> isn't a
>> > mention about it and the simple "pip install mysqclient" was breaking
>> with
>> > pkg-config issues. But it did work at the end.
>> >
>> > Now I can see further messages on mailman3-web than before.
>> >
>> > (venv) mailman@new-server ~ (v3.3.9)> mailman-web migrate
>> > System check identified some issues:
>> >
>> > WARNINGS:
>> > account.EmailAddress: (models.W036) MariaDB does not support unique
>> > constraints with conditions.
>> > HINT: A constraint won't be created. Silence this warning if you don't
>> care
>> > about it.
>> > account.EmailAddress: (models.W043) MariaDB does not support indexes on
>> > expressions.
>> > HINT: An index won't be created. Silence this warning if you don't care
>> > about it.
>> > Operations to perform:
>> > Apply all migrations: account, admin, auth, contenttypes,
>> > django_mailman3, django_q, hyperkitty, postorius, sessions, sites,
>> > socialaccount
>> > Running migrations:
>> > Applying
>> account.0004_alter_emailaddress_drop_unique_email...Traceback
>> > (most recent call last):
>>
>>
>> I'm not sure why there would be an issue with this migration, but there
>> is a possible compatibility issue depending on how you installed things.
>>
>> django-mailman3<=1.3.11 is not compatible with django-allauth>=0.58.
>>
>> In your venv, try
>> ```
>> pip install django-allauth\<0.58
>> ```
>>
>> --
>> 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/
>> Archived at:
>> https://lists.mailman3.org/archives/list/mailman-users@mailman3.org/message…
>>
>> This message sent to helio(a)loureiro.eng.br
>>
>
2 years, 8 months
[MM3-users] Re: Creating users via RestAPI / User-Management - a bunch of questions
by Stephen J. Turnbull
Mark Sapiro writes:
> On 6/20/25 06:39, Christian Schneider wrote:
> > What I stumble upon is the RestAPI calls to create a "working"
> > user (with the ability to login via WebUI).
> > When I follow the manual (from the url above) I create a user
> > (including password) that appears in the PostgreSQL database.
If you mean you create a User with password via the REST API, this
password is useless. It is not visible to the Django user management
code, and there is no way for a user to log in to Mailman via the REST
API -- the only one who can log in via REST is the superuser.
> > Even when I (via WebUI) set the user as "approved" this user is
> > not able to log in...
I'm not sure how this works, exactly, but I think what you need to do
via REST API is
1. Create the User.
2. Give it an email Address (this probably is automatic, I don't know
if you can create a "bare" user without an email address at all).
3. (probably optional) Set that address as verified.
Then through the Postorius interface you should be able to look up
that user via the email address. That should create a Django user if
one doesn't exist for that email address. I don't recall if Postorius
allows you to set the user's password. You may have to go via the
Django admin interface (the /admin location which is sibling to
/mailman3 and /archives). I'm not sure how to find that user (I don't
know what the user's account name in Django is, hopefully you can look
up the user via the email).
> > I assume this restriction is in accordance to the fact that there
> > is not equivalent Django user.
I don't think there can be a Postorius access to a Mailman user
without a Django user.
> > (There was a mail in the archive of the MM3 user group...stating
> > that one has to use the Django RestAPI to create the appropriate
> > user)
>
> The above is correct. The Mailman REST API only deals with Mailman
> core. Mailman core knows nothing about Django.
Right, if you want to do the whole thing in a script you'll have to
access Django.
> > How will a social account provider (like oidc) linkage (in
> > Django) fit in this concept?
> > Will oidc-accounts be copied to the Django's user database (or
> > PostgreSQL db) or is it an on-the-fly check against the
> > oidc-provider? (I assume second option)
> > What are the status-flags (staff status/superuser status/active
> > status) of the linked oidc-accounts? (Can I specify the status
> > flags?)
>
> I don't offhand know the answers to that, but I think logging in
> via a social account provider creates a Django user..
I can't speak for generic social accounts, but it definitely did that
for a Shibboleth-based SSO setup. Just pass the login credentials
provided by Shibboleth through to the social account stuff (verrrry
carefully :-), and everything just works.
Social auth gets the bare minimum information from the idP as far as I
know (didn't look into it carefully). At least in my case all we got
from Shibboleth was a display name (the personal name) and an email
address (not even an verifiable auth token, they trusted their network
that much). Users could set passwords but they didn't work (Django
could only be accessed by users logged in to the network, and if you
logged out, the request triggered by the redirect back to the login
page would log you right back in again! Freaky...).
> > A conceptual thought:
> > When "user1" (with email user1(a)example.com) is known to django
> > via oidc linkage and I create "user1" (also with email
> > user1(a)example.com) via RestAPI calls (following the url
> > https://docs.mailman3.org/projects/mailman/en/latest/src/mailman/rest/docs/…)
> > do I have a "complete" user then?
That depends on how the social auth is set up. Most likely the
account is linked to the email, Django trusts that email if validated
by the idP, and it will create a Django user to manage it if one
doesn't already exist. If you are accessing Postorius or HyperKitty,
that app will trust the email because it trusts Django, and it will
create a Mailman user as Mark described if one doesn't already exist.
(I don't think the Django and Mailman user-ids need to match, even.)
I'm not sure what happens if you create the Mailman user and assign it
that email address independently of creating the Django user. I think
it should "just work" to log in via Django as long as the idP vouches
that the email is authentic.
Note that there's one glitch remaining -- I'm pretty sure[1] that if
you have an existing Mailman user, and the email address is in the
unconfirmed state in Mailman, you'll have to confirm it to subscribe
to lists and probably to do any other work with that user logged in by
that address. You can do that via "one-time key" email dance, or via
the Mailman REST API though. (It may be possible to do that via the
Django admin API as well, but obviously you can't do that with
Postorius, or anybody could claim any address.)
Short version:
> > I mean a user who is able to login and who can be assigned to a
> > list as admin (e.g.) (In this case I would not have to care
> > about the Django user database... ;-))
>
> If the user can log in to the web UI with an associated email
> address, if that address is an admin of a list, the logged in user
> can admin the list.
Footnotes:
[1] Actually, I'm not sure at all but you *should* have to confirm!
--
GNU Mailman consultant (installation, migration, customization)
Sirius Open Source https://www.siriusopensource.com/
Software systems consulting in Europe, North America, and Japan
1 year, 2 months