Re: moving list from mm3 -> mm3
by Mark Sapiro
On 12/8/23 08:01, Jens Günther wrote:
>
> This is a nice collection of the configuration of a certain list. Does
> anybody know how I would get this data back to the newly created list in
> the second working mm3-instance? Shouldn't it be possible via POST
> command? I thought of something like:
>
> curl -u restadmin:restpass -d @short.domain -H "Content-Type:
> application/json" localhost:8001/3.1/lists/&short.&domain/config
>
> But it returns {"title": "405 Method Not Allowed"} and I don't know
> where to look in the docs, since it shows almost always a way through
> mailman shell.
You need a PUT command, not POST. Try the above with `-X PUT`.
> ## Members, moderators, owners
>
> To export all members I normally run within mm-core-container as user
> mailman the following command:
>
> mailman members &short.&domain > &short.txt
>
> To fill them back in, it can be done in Postorius (or is there a way
> through API?).
You can use Postorius -> Mass operations -> Mass subscribe to add the
members, but you can't do that for owners and moderators. Also you lose
information about the members such as Delivery status, Delivery mode and
other user settings.
> What I would love to know is how to get out Owners of the corresponding
> lists and reimport them in the new one (which will be the same at the
> end :-D but different instance).
You can use the --role option with `mailman members` to get owners and
moderators, but short of a custom script, you have to add them manually.
> ## registered users
>
> This part is somehow tricky, since I have no clue how to do it. Some of
> the mailinglist-admins don't want to bother their list-owners again with
> registering newly on the other system. Is there a way to export all
> users (I think I found them in the DB in the table auth_users, somehow
> in combination with account_emailaddress) and get them over to the new
> instance (actually I just need part of them, but that's another question
> that I might solve lateron on my own).
>
> Maybe the answer is already here:
> https://docs.mailman3.org/projects/mailman/en/latest/src/mailman/rest/docs/…
> -> but can somebody help to get this working (import/export)?
That is not the answer. Those are Mailman core users, not Django (web
login) users. You need to get the relevant entries from the auth_users
and account_emailaddress tables and add them to the new DB.
--
Mark Sapiro <mark(a)msapiro.net> The highway is for gamblers,
San Francisco Bay Area, California better use your sense - B. Dylan
2 years, 3 months
Re: Deactivate list without deleting it?
by Colin Watson
On Tue, Jan 16, 2018 at 10:59:28AM +0900, Stephen J. Turnbull wrote:
> Colin Watson writes:
>
> > Ideally, I'd like mailing lists to have a "deactivated" state in
> > addition to full deletion. In this state, the list would appear
> > nonexistent for most purposes: incoming email would be rejected,
> > Postorius would deny its existence, etc.
>
> [...]
>
> > Has there been any discussion of this in the past, or any advice as to
> > implementation strategy?
>
> I don't recall anybody discussing this. Your use case is your use
> case, but I think if we were going to implement this I'd probably want
> "partial" deactivation where the archives remain available but no mail
> is delivered, can't subscribe, etc. I'm also not sure I'd want
> Postorius to deny it ever existed. That seems rather unfriendly
> (again, I don't understand your use case, so that is not a comment on
> your requirements).
I possibly should have explained our situation in a little more detail.
The way we have things set up with Mailman 2.1 is that any team in
Launchpad (teams are basically just a collection of people, with varying
policies on who can join them etc.) can have a mailing list if its
administrators want one, and they enable it in the Launchpad web UI. If
you want to subscribe to one of these lists, you join the team in
question and you press the "Subscribe to mailing list" button.
Launchpad runs the show and tells Mailman exactly what to do. So in
fact we have all of Mailman's user interface disabled except for the
list archives, and Postorius wouldn't come into it in our case - I
probably shouldn't have confused things by bringing it up
hypothetically.
We'd probably want to do roughly the same kind of thing with Mailman 3,
at least to start with, though we may well want to make some of
HyperKitty's advanced features work with single-sign-on integration. I
haven't looked into that in any detail yet.
I can definitely see that both "preserve archives" vs. "hide archives"
are potentially useful things to do.
> It seems to me that dump, delete, and restore may be the best approach
> for the HyperKitty side because HyperKitty maintains all that state.
> Of course this could be done inside the database. Also, perhaps you
> can (ab)use the ArchivePolicy enum by adding an "inactive" element,
> but core has no way to enforce those on the archiver (which can be a
> third party host like mail-archive.com) and I'm not sure HyperKitty
> ever consults core about that once the archive is created.
I'd been thinking more of a new enum in HyperKitty for the visibility
state, since it does seem like quite an archiver-specific thing.
(Dump/delete/restore would of course be possible, but it's somewhat
cumbersome to do externally and it seems like an odd way to go about
things internally given the ability to change the DB schema.) I agree
that not all archiver implementations can support this.
> I'm not sure what you mean about IArchiver; as far as I can see that
> interface is sort of half-duplex: it provides the information core
> needs *about* the archiver to do core's side of archiving, not for
> core to communicate *with* the archiver. In fact all of the concrete
> code is callbacks provided by the archiver, and once a message is
> archived the core forgets about it. So this isn't "just" an
> extension; it's a fundamental redesign of IArchiver.
Well, IArchiver.archive_message sends a message from core to the
archiver. I'd been thinking of something like
IArchiver.set_list_visibility(mlist, visibility) which would send a
message from core to the archiver to instruct it to show/hide the
archives. It doesn't seem too out of line, though I'm not wedded to it
either.
I suppose that one alternative could be that we handle this in a
Launchpad-specific add-on to HyperKitty, since at a minimum we'll need
some of our own code there to deal with sign-in for private lists. So
the same bit of custom code that determines whether a list's archives
are private could hide them from everyone except their owner, or even
deny their existence entirely. It sounds like maybe we'd be better off
pursuing that?
> I'm not sure that's not a good thing, but we do need to think about
> it. ISTM we're gradually converging back on the monolithic approach
> to MLM, with the distribution, administration, and archiving quite
> tightly interwoven, and I'm not sure I like that. OTOH, we do get a
> lot of requests for ever more bundling.
Given our requirements, the decreased coupling in Mailman 3 is a very
good thing, and I'm definitely not looking for more bundling. I hope
I've clarified that above.
Thanks,
--
Colin Watson [cjwatson(a)ubuntu.com]
8 years, 2 months
Re: Another interesting error...
by Mark Sapiro
On 04/23/2018 01:31 PM, Darren Smith wrote:
> So it appears that there was a message sent to one of our mailing lists
> that was put into the held message queue. However, when attempting to go to
> the message to do the moderation, the web page returns and Error 500.
>
> Looking in the mailman log, I found this:
>
> Apr 23 14:21:02 2018 (17878) REST request handler error:
> Traceback (most recent call last):
> File "/opt/mailman3/conda/lib/python3.6/wsgiref/handlers.py", line 137,
> in run
> self.result = application(self.environ, self.start_response)
> File
> "/opt/mailman3/conda/lib/python3.6/site-packages/mailman/database/transac
> tion.py", line 50, in wrapper
> rtn = function(*args, **kws)
> File
> "/opt/mailman3/conda/lib/python3.6/site-packages/mailman/rest/wsgiapp.py"
> , line 214, in __call__
> return super().__call__(environ, start_response)
> File "/opt/mailman3/conda/lib/python3.6/site-packages/falcon/api.py",
> line 227 , in __call__
> responder(req, resp, **params)
> File
> "/opt/mailman3/conda/lib/python3.6/site-packages/mailman/rest/post_modera
> tion.py", line 167, in on_get
> resource = self._make_collection(request)
> File
> "/opt/mailman3/conda/lib/python3.6/site-packages/mailman/rest/helpers.py"
> , line 159, in _make_collection
> for resource in collection]
> File
> "/opt/mailman3/conda/lib/python3.6/site-packages/mailman/rest/helpers.py"
> , line 159, in <listcomp>
> for resource in collection]
> File
> "/opt/mailman3/conda/lib/python3.6/site-packages/mailman/rest/post_modera
> tion.py", line 157, in _resource_as_dict
> resource = self._make_resource(request.id)
> File
> "/opt/mailman3/conda/lib/python3.6/site-packages/mailman/rest/post_modera
> tion.py", line 100, in _make_resource
> make_header(decode_header(resource['subject'])))
> File "/opt/mailman3/conda/lib/python3.6/email/header.py", line 174, in
> make_he ader
> h.append(s, charset)
> File "/opt/mailman3/conda/lib/python3.6/email/header.py", line 295, in
> append
> s = s.decode(input_charset, errors)
> UnicodeDecodeError: 'gb2312' codec can't decode byte 0x87 in position 2:
> illegal multibyte sequence
>
> It LOOKS as if there might be a character in the email somewhere - possibly
> in the subject or sender fields? - that is somehow unexpected.
It appears that the Subject: header is RFC 2047 encoded and there is an
encoded word with charset gb2312 that contains an invalid encoding.
The message is apparently defective, but this kind of defect shouldn't
cause a 500 error.
I can't tell for sure from the traceback if this is Postorius or some
other application accessing the REST api. Is it Postorius or something else?
> I am attempting to find the held message - can someone point me where I can
> go to see the message so that I can see what might be causing the problem?
It's in Mailman's database in the 'message' table.
--
Mark Sapiro <mark(a)msapiro.net> The highway is for gamblers,
San Francisco Bay Area, California better use your sense - B. Dylan
7 years, 10 months
Re: One-click unsubscribe?
by Stephen J. Turnbull
Jered Floyd writes:
> I'm not going to defend Google's implementations and policies here,
I'm not asking anybody to do it one way or the other, I'm just
generally pissed off that mailing lists have to bear the burden of the
abuse of mail protocols by large monopolistic companies, who won't
impose sensible restrictions on their users (a domain with p=reject
should not be sending to mailing lists).
> but the RFC 2369 fields are regularly insufficient.
You're right. I misread the code to say that the List-Unsubscribe
field would contain the subscribed address if the distributed post was
personalized, but it doesn't. We can fix that (in the case of a
personalized list), and we should fix it with RFC 8058.
I'll need to check, but I think we want to add a full configuration
section on Postorius for all the List-* fields (RFCs 2369, 2919, and
now 8058). Besides the options to include the fields and set their
content, there should be options for "Mailman standard" mailto and
http(s) URIs, as well as an option to edit the http(s) URI for folks
who use something other than Postorius.
I need to go back and read RFC 8058, but I think that the address
information in the RFC 8058 URI can be completely opaque. I'm not
sure if that's the best approach.
> Regardless of that, the little box that says "this message is from
> a mailing list; would you like to unsubscribe?" that appears on my
> iDevice is extremely useful and a great user affordance.
RFC 2369 is a standard. Every serious MUA should provide that button
for every list that provides a List-Unsubscribe field, along with help
for the case where the address to unsubscribe is not provided.
> RFC 8058 is a standard; there's no reason for us to be needlessly
> hostile to implementing it. (That's independent from prioritizing
> it or finding someone with the time, of course.)
I haven't noticed needless hostility. It's a LOT of work to do
properly, though. Among other things, RFC 8058 requires "The
List-Unsubscribe header field MUST contain one HTTPS URI." We don't
necessarily control the implementation of that -- Postorius is an
optional component, and Mailman core does not expose an HTTP port to
the Internet by design. It's going to require changing several
schemas in Mailman configuration, data models, and databases.
> Are you suggesting just adding bogus RFC 8058 headers to appease
> GMail?
No, as explained above, I thought that Mailman was already adding
subscription information to the "leave" field. The risk in what I was
thinking was entirely DOS attacks on the list's subscribers via an
insecure 1-click implementation.
> The leave address is not sufficient for this, and as per up-thread
> cannot be applied in rfc_2369.py because it is pre-personalization.
That doesn't matter, since it's an easy-to-implement personalization.
Just go to the end of the field, backspace past the ">", and insert a
query providing the address and/or RFC 8058 token.
> > I see in your later message that you haven't enabled
> > personalization in Mailman. [...]
Again, this was from misreading the code. My bad, I apologize.
> don't think there's really any case in which personalization should
> be disabled in the modern internet mail world, and would argue (but
> not very strongly) that the options to turn this off probably ought
> be removed from Mailman.
I would oppose that. There are use cases where broadcast of generic
messages make sense and unsubscribe does not, such as addresses and
lists provided as a condition of organization membership.
> (At the very least, personalization ought be the default.)
That's plausible.
--
GNU Mailman consultant (installation, migration, customization)
Sirius Open Source https://www.siriusopensource.com/
Software systems consulting in Europe, North America, and Japan
3 months, 2 weeks
Re: Protocol version
by David Krantz
Hi,
I decided to investigate this a bit more... I find the following in
mailman.log (I have removed the dates and my domain names but
otherwise it is unchanged. I find it strange that postorius calls the
3.0 api version to get versions and otherwise uses the 3.1 version.
This probably is the explanation for it displaying API version 3.0
when it actually uses 3.1.
GET /3.1/domains HTTP/1.1" 200 1658 "-" "GNU Mailman REST client v3.3.0"
GET /3.1/domains/example.com HTTP/1.1" 200 216 "-" "GNU Mailman REST
client v3.3.0"
POST /3.0/lists/find HTTP/1.1" 200 19177 "-" "GNU Mailman REST client v3.3.0"
GET /3.0/system/versions HTTP/1.1" 200 286 "-" "GNU Mailman REST client v3.3.0"
GET /3.1/domains HTTP/1.1" 200 1658 "-" "GNU Mailman REST client v3.3.0"
GET /3.1/domains/lists.example.com HTTP/1.1" 200 230 "-" "GNU Mailman
REST client v3.3.0"
POST /3.0/lists/find HTTP/1.1" 200 19177 "-" "GNU Mailman REST client v3.3.0"
GET /3.1/domains HTTP/1.1" 200 1658 "-" "GNU Mailman REST client v3.3.0"
GET /3.1/domains/example.com HTTP/1.1" 200 216 "-" "GNU Mailman REST
client v3.3.0"
POST /3.0/lists/find HTTP/1.1" 200 19177 "-" "GNU Mailman REST client v3.3.0"
GET /3.0/system/versions HTTP/1.1" 200 286 "-" "GNU Mailman REST client v3.3.0"
GET /3.1/domains HTTP/1.1" 200 1658 "-" "GNU Mailman REST client v3.3.0"
GET /3.1/domains/lists.example.com HTTP/1.1" 200 230 "-" "GNU Mailman
REST client v3.3.0"
GET /3.1/domains/example.com HTTP/1.1" 200 216 "-" "GNU Mailman REST
client v3.3.0"
GET /3.1/users/0039b9f69d624016bbedfddebc11f1e4/addresses HTTP/1.1"
200 467 "-" "GNU Mailman REST client v3.3.0"
GET /3.1/domains/example.com/owners HTTP/1.1" 200 396 "-" "GNU Mailman
REST client v3.3.0"
GET /3.0/system/versions HTTP/1.1" 200 286 "-" "GNU Mailman REST client v3.3.0"
GET /3.1/domains HTTP/1.1" 200 1658 "-" "GNU Mailman REST client v3.3.0"
GET /3.1/domains/lists.example.com HTTP/1.1" 200 230 "-" "GNU Mailman
REST client v3.3.0"
GET /3.1/domains/example.com HTTP/1.1" 200 216 "-" "GNU Mailman REST
client v3.3.0"
POST /3.0/lists/find HTTP/1.1" 200 19177 "-" "GNU Mailman REST client v3.3.0"
Thanks
// David
On Fri, Mar 6, 2020 at 9:42 PM David Krantz <gazorg(a)gmail.com> wrote:
>
> Hi.
>
> I have the following displayed when I look at the "System Information"
> in Postorius:
>
> Mailman Core Version GNU Mailman 3.3.0 (La Villa Strangiato)
> Mailman Core API Version 3.0
> Mailman Core Python Version 3.7.6 (default, Dec 19 2019, 23:49:42)
> [GCC 5.4.0 20160609]
>
> What surprises me is the protocol version. I have tried to set the
> protocol version to 3.1 in mailman core (which should be the latest
> according to the documentation) and restarting both core and web but
> that gives no effect. Normally I have not had any protocol version
> defined. Everything seems to work just fine but something is strange,
> either the documentation, my setup or mailman/postorius.
>
> // David
5 years, 11 months
Re: How to remove a nonmember from a list
by skenny＠scss.tcd.ie
Abhilash Raj wrote:
> Could be, I am not sure which operation is it stuck at. Can you check logs to see
> where is it breaking?
Sure. I'm doing all this under Docker; below is what I see in /opt/mailman-web-data/logs/mailmanweb.log when I try to delete a nonmember via the web interface. Thediagnostics appear 30 seconds after I click on 'delete':
ERROR 2020-04-09 20:35:51,482 19 postorius.middleware Mailman REST API not available
Traceback (most recent call last):
File "/usr/lib/python3.6/site-packages/urllib3/connectionpool.py", line 672, in urlopen
chunked=chunked,
File "/usr/lib/python3.6/site-packages/urllib3/connectionpool.py", line 421, in _make_request
six.raise_from(e, None)
File "<string>", line 3, in raise_from
File "/usr/lib/python3.6/site-packages/urllib3/connectionpool.py", line 416, in _make_request
httplib_response = conn.getresponse()
File "/usr/lib/python3.6/http/client.py", line 1346, in getresponse
response.begin()
File "/usr/lib/python3.6/http/client.py", line 307, in begin
version, status, reason = self._read_status()
File "/usr/lib/python3.6/http/client.py", line 276, in _read_status
raise RemoteDisconnected("Remote end closed connection without"
http.client.RemoteDisconnected: Remote end closed connection without response
During handling of the above exception, another exception occurred:
Traceback (most recent call last):
File "/usr/lib/python3.6/site-packages/requests/adapters.py", line 449, in send
timeout=timeout
File "/usr/lib/python3.6/site-packages/urllib3/connectionpool.py", line 720, in urlopen
method, url, error=e, _pool=self, _stacktrace=sys.exc_info()[2]
File "/usr/lib/python3.6/site-packages/urllib3/util/retry.py", line 400, in increment
raise six.reraise(type(error), error, _stacktrace)
File "/usr/lib/python3.6/site-packages/urllib3/packages/six.py", line 734, in reraise
raise value.with_traceback(tb)
File "/usr/lib/python3.6/site-packages/urllib3/connectionpool.py", line 672, in urlopen
chunked=chunked,
File "/usr/lib/python3.6/site-packages/urllib3/connectionpool.py", line 421, in _make_request
six.raise_from(e, None)
File "<string>", line 3, in raise_from
File "/usr/lib/python3.6/site-packages/urllib3/connectionpool.py", line 416, in _make_request
httplib_response = conn.getresponse()
File "/usr/lib/python3.6/http/client.py", line 1346, in getresponse
response.begin()
File "/usr/lib/python3.6/http/client.py", line 307, in begin
version, status, reason = self._read_status()
File "/usr/lib/python3.6/http/client.py", line 276, in _read_status
raise RemoteDisconnected("Remote end closed connection without"
urllib3.exceptions.ProtocolError: ('Connection aborted.', RemoteDisconnected('Remote end closed connection without response',))
During handling of the above exception, another exception occurred:
Traceback (most recent call last):
File "/usr/lib/python3.6/site-packages/mailmanclient/restbase/connection.py", line 96, in call
headers=headers)
File "/usr/lib/python3.6/site-packages/requests/api.py", line 60, in request
return session.request(method=method, url=url, **kwargs)
File "/usr/lib/python3.6/site-packages/requests/sessions.py", line 533, in request
resp = self.send(prep, **send_kwargs)
File "/usr/lib/python3.6/site-packages/requests/sessions.py", line 646, in send
r = adapter.send(request, **kwargs)
File "/usr/lib/python3.6/site-packages/requests/adapters.py", line 498, in send
raise ConnectionError(err, request=request)
requests.exceptions.ConnectionError: ('Connection aborted.', RemoteDisconnected('Remote end closed connection without response',))
During handling of the above exception, another exception occurred:
Traceback (most recent call last):
File "/usr/lib/python3.6/site-packages/django/core/handlers/base.py", line 113, in _get_response
response = wrapped_callback(request, *callback_args, **callback_kwargs)
File "/usr/lib/python3.6/site-packages/django/contrib/auth/decorators.py", line 21, in _wrapped_view
return view_func(request, *args, **kwargs)
File "/usr/lib/python3.6/site-packages/postorius/auth/decorators.py", line 38, in wrapper
return fn(*args, **kwargs)
File "/usr/lib/python3.6/site-packages/postorius/views/list.py", line 943, in remove_role
roster = getattr(the_list, '{}s'.format(role))
File "/usr/lib/python3.6/site-packages/mailmanclient/restobjects/mailinglist.py", line 86, in nonmembers
response, content = self._connection.call(url, data)
File "/usr/lib/python3.6/site-packages/mailmanclient/restbase/connection.py", line 119, in call
raise MailmanConnectionError('Could not connect to Mailman API')
mailmanclient.restbase.connection.MailmanConnectionError: Could not connect to Mailman API
ERROR 2020-04-09 20:35:51,509 19 django.request Service Unavailable: /postorius/lists/scss-sysadmins.lists.scss.tcd.ie/remove/nonmember/skenny(a)scss.tcd.ie
ERROR 2020-04-09 20:35:51,509 19 django.request Service Unavailable: /postorius/lists/scss-sysadmins.lists.scss.tcd.ie/remove/nonmember/skenny(a)scss.tcd.ie
The file /opt/mailman-web-data/logs/uwsgi.log contains just one line:
[pid: 19|app: 0|req: 82/96] 172.19.199.5 () {46 vars in 1233 bytes} [Thu Apr 9 20:35:20 2020] GET /postorius/lists/scss-sysadmins.lists.scss.tcd.ie/remove/nonmember/skenny(a)scss.tcd.ie => generated 5583 bytes in 31411 msecs (HTTP/1.0 503) 5 headers in 180 bytes (1 switches on core 0)
> Can you try doing the same with the REST API, just to verify if it is the Core which
> has the issue or it is the web frontend.
Using the REST API, I can successfully remove a named nonmember from the list. But I see the same pause-then-fail behaviour when I try to simply list all the nonmembers. My snippet of code can happily produce a listing of the members, but it gets stuck trying to list nonmembers, and then 30 seconds later it crashes out with exactly the same error messages as when I tried to delete a user in the web interface (see above). My piece of code appears below (II invoke it like this:
docker exec -it mailman-core bash -c 'python3 /opt/mailman/local/probe.py scss-sysadmins(a)lists.scss.tcd.ie').
from mailmanclient import Client
from mailmanclient import MailingList
import sys
my_list = str(sys.argv[1])
client = Client('http://172.19.199.2:8001/3.0', 'restadmin', 'restpass')
this_list = client.get_list(my_list)
print("\n\nMembers:\n-------------------------------------------------")
for i in this_list.members:
print(i)
print("\nNonmembers:\n-------------------------------------------------")
for i in this_list.nonmembers:
print(i)
Thanks again
Stephen
5 years, 11 months
Re: Template path
by Mark Sapiro
On 9/17/20 9:33 AM, Seth Seeger wrote:
> Hello everyone,
>
> I’m running Mailman from Docker containers, without much customization. (Postorius 1.3.3, Core 3.3.1, API 3.1, Python 3.8.5). I’ve created a list:user:notice:welcome template, and when I try to confirm a subscription, I get an error.
>
> I followed previous emails on this list which told me to set POSTORIUS_TEMPLATE_BASE_URL in /opt/mailman/web/settings_local.py, but that doesn’t seem to make any difference. (I set it to a different value and the error message didn’t change. I also tried setting it in /opt/mailman/core/settings_local.py to no effect. After each change, I restarted mailman-web and mailman-core containers.)
How did you create the template? In Postorius or by manually creating a
file somewhere? If by creating a file, POSTORIUS_TEMPLATE_BASE_URL is
not relevant, but ensure that the file is findable and readable by Mailman.
> From within mailman-web and mailman-core containers, I can reach “mailman-web:8000”.
>
> In the webpage, I see: Mailman REST API not available. Please start Mailman core.
The REST APT is normally exposed on port 8001, not 8000 (See `port` in
`mailman conf -s webservice`.
What is your setting for MAILMAN_REST_API_URL? does the port match?
> In /opt/mailman/core/var/logs/mailman.log, I get:
>
> [17/Sep/2020:16:23:29 +0000] "GET /3.1/lists/xxx.example.com HTTP/1.1" 200 416 "-" "GNU Mailman REST client v3.3.1"
It appears you are connecting to the REST API, but ...
...
> urllib3.exceptions.ReadTimeoutError: HTTPConnectionPool(host='mailman-web', port=8000): Read timed out. (read timeout=5)
Something appears to be trying to connect to REST on port 8000
--
Mark Sapiro <mark(a)msapiro.net> The highway is for gamblers,
San Francisco Bay Area, California better use your sense - B. Dylan
5 years, 6 months
Re: Default values for lists in Mailman 3
by Mark Sapiro
On 9/30/24 02:17, Markus Grandpré wrote:
> Dear Mark, dear list,
>
> in Menu "Mass Operations / Mass Subscription" I have set the default
> value for checkbox "Invitation" in file
> </usr/lib/python3/dist-packages/postorius/forms/list_forms.py> (on
> Debian 12) as you had suggested:
>
>
> invitation = forms.BooleanField(
> label=_('Invitation'),
> initial=True,
> required=False,
> help_text=_(
> 'If checked, the other checkboxes are ignored and the users
> will '
> 'be sent an invitation to join the list and will be
> subscribed '
> 'upon acceptance thereof.'
> ),
> widget=forms.CheckboxInput(),
> )
This is correct.
> However, administrators of mailing lists on our Mailman3 demo system
> report that the invitation is still sent, even if they have deactivated
> the sending of the invitation via the “Invitation” checkbox.
If the admin is unchecking the Invitation box but not checking the Pre
Verified box, the user will still be sent an address confirmation
request. Perhaps the admins are mistaking this for an invitation. It the
desire is to immediately subscribe the user with no further interaction,
in addition to the Invitation box being unchecked, all three of the Pre
confirm, Pre approved and Pre verified boxes must be checked.
You may wish to set the Pre Verified default to checked in a manner
similar to the above, or with Postorius >=1.3.14 (not yet released) you
will be able to add
```
POSTORIUS_DEFAULTS = {
'mass_subscription_pre_verify': True
}
```
to your Django settings to accomplish this.
--
Mark Sapiro <mark(a)msapiro.net> The highway is for gamblers,
San Francisco Bay Area, California better use your sense - B. Dylan
1 year, 5 months
Re: Apache+mod_wsgi issue
by Guillermo Hernandez (Oldno7)
El 26/12/22 a las 16:08, Odhiambo Washington escribió:
> On Mon, Dec 26, 2022 at 5:07 PM Eggert Ehmke<eggert(a)eehmke.de> wrote:
Odhiambo, I didn't change anything from my config as I wrote down in
https://forums.FreeBSD.org/threads/mailman-3.61050/post-488128, save the
python version (I upgraded to 3.9 moths ago, as I posted in this list).
My urls.py looks like this:
###################
from django.conf import settings
### mod. 30/10/22
###from django.conf.urls import include, url
from django.conf.urls import include
from django.urls import re_path as url
#####
from django.contrib import admin
from django.urls import reverse_lazy
from django.views.generic import RedirectView
urlpatterns = [
url(r'^$', RedirectView.as_view(
url=reverse_lazy('list_index'),
permanent=True)),
url(r'^postorius/', include('postorius.urls')),
url(r'^hyperkitty/', include('hyperkitty.urls')),
url(r'', include('django_mailman3.urls')),
url(r'^accounts/', include('allauth.urls')),
# Django admin
url(r'^admin/', admin.site.urls),
url(r'^mailman3/', include('postorius.urls')),
url(r'^archives/', include('hyperkitty.urls')),
]
>> Ok,
>>
>> I hope this is readable. I just copíed the content of some files into the
>> pastebin, don't know if it is possible to post tar.gz there.
>> https://pastebin.ubuntu.com/p/mmRJJwKDc3/
>>
>> Just tell me if this works for you, and when something is missing.
>> Most of the settings are copied from some other sites and just adjusted
>> for my
>> needs.
>> Good luck!
>
> So it seems your WSGIDaemonProcess is defined somewhere outside the VHOST,
> right? Or it wasn't necessary?
> And what does your urls.py look like?
>
> My setup is PUBLIC for everyone so I will not hide the domain name :-)
>
> In my setup, MM3 is installed in /opt/mailman/mm/. and mod_wsgi is enabled
> in Apache.
> I am running uwsgi on a TCP socket, not unix socket.
>
> The whole of my *VHOST:*
> <CUT>
> WSGIDaemonProcess mailman-web display-name=mailman-web
> maximum-requests=1000 umask=0002 user=mailman group=mailman
> python-path=/opt/mailman/mm:/opt/mailman/mm/venv/lib/python3.9/site-packages:/opt/mailman/mm/venv/lib/python3.9
> python-home=/opt/mailman/mm/venv home=/opt/mailman/mm/var
> WSGIRestrictSignal Off
> <VirtualHost *:443>
> ServerName mm3-lists.kictanet.or.ke
>
> SSLEngine on
> SSLCertificateFile "/usr/local/etc/letsencrypt/live/
> mm3-lists.kictanet.or.ke/cert.pem"
> SSLCertificateKeyFile "/usr/local/etc/letsencrypt/live/
> mm3-lists.kictanet.or.ke/privkey.pem"
> SSLCertificateChainFile "/usr/local/etc/letsencrypt/live/
> mm3-lists.kictanet.or.ke/chain.pem"
> CustomLog /var/log/mm3-lists-access.log combined
> ErrorLog /var/log/mm3-lists-error.log
> LogLevel info
> Alias /favicon.ico /opt/mailman/mm/static/hyperkitty/img/favicon.ico
> Alias /static "/opt/mailman/mm/static"
> <Directory "/opt/mailman/mm/static">
> Require all granted
> </Directory>
> WSGIScriptAlias / /opt/mailman/mm/wsgi.py
> <Directory "/opt/mailman/mm/">
> <Files wsgi.py>
> Order deny,allow
> Allow from all
> Require all granted
> </Files>
> WSGIProcessGroup mailman-web
> </Directory>
> </VirtualHost>
> </CUT>
>
> *2. uwsgi.ini:*
> <CUT>
> [uwsgi]
> http-socket = 127.0.0.1:8000
> pidfile = /opt/mailman/mm/var/uwsgi.pid
> chdir = /opt/mailman/mm/
> virtualenv = /opt/mailman/mm/venv/
> module=mailman_web.wsgi:application
> env =PYTHONPATH=/opt/mailman/mm/
> env =DJANGO_SETTINGS_MODULE=settings
> master = true
> process = 2
> threads = 2
> attach-daemon = /opt/mailman/mm/venv/bin/mailman-web qcluster
> req-logger =file:/opt/mailman/mm/var/logs/uwsgi.log
> logger = qclusterfile:/opt/mailman/mm/var/logs/uwsgi-qcluster.log
> log-route = qcluster uwsgi-daemons
> logger = cronfile://opt/mailman/mm/var/logs/uwsgi-cron.log
> log-route = cron uwsgi-cron
> logger =file:/opt/mailman/mm/var/logs/uwsgi-error.log
> uid = mailman
> gid = mailman
> </CUT>
>
> *3. uwsgi - *Running supervised (supervisord):
> <CUT>
> [program:uwsgi]
> directory=/opt/mailman/mm/
> environment=PYTHONPATH=/opt/mailman/mm/
> command=/usr/bin/su -m mailman -c '/opt/mailman/mm/venv/bin/uwsgi --ini
> /opt/mailman/mm/uwsgi.ini' 2>&1 | logger -t uwsgi
> autostart=true
> autorestart=true
> user=mailman
> group=mailman
> stopasgroup=true
> killasgroup=true
> </CUT>
>
> *4. urls.py*:
> <CUT>
> from django.conf.urls import include
> from django.urls import re_path
> from django.contrib import admin
> from django.urls import reverse_lazy
> from django.views.generic import RedirectView
> from django_mailman3.views.profile import delete_account, user_profile
> urlpatterns = [
> re_path(r'^$', RedirectView.as_view(
> url=reverse_lazy('list_index'),
> permanent=True)),
> re_path(r'^postorius/', include('postorius.urls')),
> re_path(r'^hyperkitty/', include('hyperkitty.urls')),
> re_path(r'^user-profile/delete$', delete_account,
> name='mm_user_account_delete'),
> re_path(r'^user-profile/$', user_profile, name='mm_user_profile'),
> re_path(r'^accounts/', include('allauth.urls')),
> re_path(r'^admin/', admin.site.urls),
> re_path(r'^mm/', include('postorius.urls')),
> re_path(r'^archives/', include('hyperkitty.urls')),
> ]
> </CUT>
>
> And that's pretty much what I am using on my FreeBSD server.
>
>
> PS: Possible to bottom-post instead of top-posting? :)
>
--
___________________________________________
Mailman's content filtering has removed the
following MIME parts from this message.
Content-Type: image/png
Name: firma-GHP-emails.png
Replaced multipart/alternative part with first alternative.
3 years, 2 months
Re: One-click unsubscribe?
by Stephen J. Turnbull
Jered Floyd writes:
> > I guess it would be a matter of keeping 2 tokens in the database.
>
> In the case we sign/encrypt a tuple of (list, subscriber,
> timestamp) we don't need to store anything in the database.
True, but I'm concerned with the computation cost of validation. That
shouldn't matter ordinarily, legit unsubscribes will be rare, but it
could be a vulnerability to a DOS attack.
> Option 1: signed/encrypted tuple (list, subscriber, timestamp)
> Option 2: UUID referencing a unique subscription in the database
>
> Sounds like you are favoring the 2nd option?
Yes, with explicit timestamp. The concerned party has knowledge of
the first two. None of that is anybody else's business. Nerds like me
would be pleased to be told the third component, and if expiration
times are going to be "several months" as you suggested, I figure they
should last as long as the signing key does.
> RFC 8058 doesn't specify response codes or really any behavior in
> response to the POST request. The user never sees this interaction.
Probably not. It's a little surprising that they said almost nothing
(except some dark mutterings about hints that the address is valid).
Maybe it's not necessary. If the list wants to they can provide a
goodbye message, and if it fails the subscriber will get a valid
token. :-) I just think it would be kind of rude not to give a
response in the case of an expired token, because the subscriber did
everything right as far as they can see.
> On the other hand, in Postorius we probably want to support a GET
> interaction against the same URI which provides a page with a
> button that generates the equivalent POST.
I don't think so. We can already put the list and address in the
footer's unsubscribe link.[1] That would likely involve a login
interaction.[2] The token alone wouldn't be sufficient credentials,
because the footer is extremely likely to leak into public spaces.
> Incidentally, I imagine 8058 defines this as a POST interaction to
> avoid the mail-scanner issue we talked about last message.
Ah, good point. I've worked with John Levine, he's that smart and
definitely that WG is that smart.
> Ah, to be outside the US, where the concept of consumer protections
> still exists...
Lina Khan lives!
Footnotes:
[1] Of course this would require changing GET processing of the
unsubscribe link, it doesn't work that way now. But this should be a
separate feature from RFC 8058 processing.
[2] If the user has a Postorius session active, they'll be whisked on
through. But most users won't.
--
GNU Mailman consultant (installation, migration, customization)
Sirius Open Source https://www.siriusopensource.com/
Software systems consulting in Europe, North America, and Japan
3 months, 1 week