Search results for "Postorius" - Mailman-users

Re: Change the default value for the General Archive Policy

by Stephen J. Turnbull

Markus Grandpré writes: > many thanks for your reply. When I create a mailing list without an > archive, You cannot do that in Postorius. All of the "style" options provide for an archive. "Ordinary discussion" and "announce" have public archives, and the last option is "discussion with private archives". How are you doing this? > "Settings > Archiving > Archive policy" is always set to "Public > archives". I was wondering if it's possible to change the default > to "Do not archive this list" instead. The choices for setting are defined at line 386 (or so) of postorius/forms/list_forms.py: archive_policy_choices = ( ('public', _('Public archives')), ('private', _('Private archives')), ('never', _('Do not archive this list')), ) This is implemented as a line of radio buttons. There is no default for a *new* list, it's implied by the style choice. For an existing list you are shown the current setting -- there's no default to change to, you have to click on a button. If by "default" you mean "first in the list", you can patch the form in Postorius, but we're not going to change the order, since our primary audience is public discussion lists. In theory we could provide a mechanism to configure the order, but I think that's very unlikely to happen -- Mailman isn't and doesn't want to be Emacs. -- 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

Re: mailing list aliases

by Abhilash Raj

On Fri, 2018-01-19 at 16:30 -0800, Mark Sapiro wrote: > On 01/19/2018 03:09 PM, Dmitry Makovey wrote: > > Not sure whether to mark this "SOLVED" yet - but when I manually updated > > postgres DB with the aliases I wanted - everything started to work as > > expected. > > > > so it does sound like a bug in mailman-core 3.3.0 . Shall I file it or > > was it already fixed in 3.3.1 (anouncement page didn't list that fix) > > > As far as I know, this is not a bug in core. It is > <https://gitlab.com/mailman/postorius/issues/58> however, this may in > fact be a bug in the REST API in which case I don't think it's fixed in > API 3.3.1 I guess we are all talking about the same thing, but just to mention, 3.1.1 is the latest release (instead of 3.3.1). > > > > 2. Related to #1 - we've migrated our mailing lists from foo(a)my.com to > > > foo(a)lists.my.com however we've preserved old addresses. But in new setup > > > mail sent in gets stopped for moderation with: "X-Mailman-Rule-Hits: > > > implicit-dest" . What's the best course of action here to get mailing > > > list respond to multiple email addresses? > > > acceptable_aliases is the way to address this, but as you note, it can't > be properly set via Postorius and possibly via REST. > > _______________________________________________ > Mailman-users mailing list > mailman-users(a)mailman3.org > https://lists.mailman3.org/mailman3/lists/mailman-users.mailman3.org/ -- thanks, Abhilash Raj

8 years, 8 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

9 months, 3 weeks

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

8 years, 4 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

6 years, 5 months

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

6 years, 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, 8 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

6 years

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

9 months, 2 weeks

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, 11 months

Mailman-users search results for query "Postorius"