Hi list,
how can I disable user registration? There are only two users, me - the admin - and an additional owner/moderator. The list setup we use is completely managed by the owner/moderator (about 100 mail adresses per list).
Thanks Torge
On Thu, Mar 28, 2019, at 9:20 AM, Torge Riedel wrote:
Hi list,
how can I disable user registration? There are only two users, me - the admin - and an additional owner/moderator. The list setup we use is completely managed by the owner/moderator (about 100 mail adresses per list).
Nothing yet, I have some ideas though. Opened a ticket here1.
Thanks Torge
Mailman-users mailing list -- mailman-users@mailman3.org To unsubscribe send an email to mailman-users-leave@mailman3.org https://lists.mailman3.org/mailman3/lists/mailman-users.mailman3.org/
-- thanks, Abhilash Raj (maxking)
On 3/28/19 10:41 AM, Abhilash Raj wrote:
Nothing yet, I have some ideas though. Opened a ticket here1.
Or https://gitlab.com/mailman/django-mailman3/issues/23 to get to the specific issue.
-- Mark Sapiro <mark@msapiro.net> The highway is for gamblers, San Francisco Bay Area, California better use your sense - B. Dylan
Am 28.03.19 um 18:47 schrieb Mark Sapiro:
On 3/28/19 10:41 AM, Abhilash Raj wrote:
Nothing yet, I have some ideas though. Opened a ticket here1.
Or https://gitlab.com/mailman/django-mailman3/issues/23 to get to the specific issue.
Thank you, I've left a comment to describe my scenario.
jens.guenther@posteo.de writes:
Same question here :-)
This is not a simple question. Mailman is built from the ground up on the assumption that users sign up. Making sign-up easy and powerful is the raison d'etre of Mailman.
One obvious approach is to add "^.$" to each list's ban list (eventually that should be configurable as a list style, so "easy" to make domainwide or sitewide), but that doesn't stop people from creating users via Postorius. One way to address that would be to clean out users with no subscriptions once a week or so.
I guess you could go into the templates and remove the accounts/signup/ links everywhere if "denial by obscurity" is enough, or into urls.py and send that URL to a "Get out of here you hacker!" view. Since these interventions are global, though, so the desideratum of "no site admin intervention" is right out. Users are site-global.
On 3/20/21 6:22 AM, Stephen J. Turnbull wrote:
One obvious approach is to add "^.$" to each list's ban list (eventually that should be configurable as a list style, so "easy" to make domainwide or sitewide), but that doesn't stop people from creating users via Postorius. One way to address that would be to clean out users with no subscriptions once a week or so.
I think you mean "^.*$", but that won't work as being banned means you can't be added to the list by any means and you can't post.
-- Mark Sapiro <mark@msapiro.net> The highway is for gamblers, San Francisco Bay Area, California better use your sense - B. Dylan
On Mar 20, 2021, at 6:22 AM, Stephen J. Turnbull <turnbull.stephen.fw@u.tsukuba.ac.jp> wrote:
jens.guenther@posteo.de writes:
Same question here :-)
This is not a simple question. Mailman is built from the ground up on the assumption that users sign up. Making sign-up easy and powerful is the raison d'etre of Mailman.
One obvious approach is to add "^.$" to each list's ban list (eventually that should be configurable as a list style, so "easy" to make domainwide or sitewide), but that doesn't stop people from creating users via Postorius. One way to address that would be to clean out users with no subscriptions once a week or so.
I guess you could go into the templates and remove the accounts/signup/ links everywhere if "denial by obscurity" is enough, or into urls.py and send that URL to a "Get out of here you hacker!" view. Since these interventions are global, though, so the desideratum of "no site admin intervention" is right out. Users are site-global.
Modifying urls.py to match `/accounts/signup` and redirect to a static page that says “Signups are disabled” or just event a 404 page is probably easiest to do. diff --git a/example_project/urls.py b/example_project/urls.py index 9c854989..3187756e 100644 --- a/example_project/urls.py +++ b/example_project/urls.py @@ -23,16 +23,22 @@ This file is the main URL config for a Django website including HyperKitty. from django.conf import settings from django.conf.urls import include, url from django.contrib import admin +from django.http import Http404 from django.urls import path, reverse_lazy from django.views.generic import RedirectView +def not_found(request): + raise Http404("Signups are disabled on this site.") + + urlpatterns = [ url(r'^$', RedirectView.as_view( url=reverse_lazy('hk_root'))), url(r'^hyperkitty/', include('hyperkitty.urls')), # url(r'^postorius/', include('postorius.urls')), url(r'', include('django_mailman3.urls')), + url(r'^accounts/signup', not_found), url(r'^accounts/', include('allauth.urls')), # Django admin url(r'^admin/', admin.site.urls), This did the job for me locally and will present the user with a 404 page saying the “Signups are disabled on this site”. Note it is important to put the new pattern before the “^accounts/“ pattern since the URLs are matched in the order they are defined. -- thanks, Abhilash Raj (maxking)
I was looking for exactly this functionality myself this week. We have an organization of 2000 members and we wanted an independent way of controlling who can access a list. In the end I decided that mailman3 was designed for something completely different than what we needed, so I've scrubbed this approach.
On Mar 20, 2021, at 11:10 AM, mailman3@digicrime.com wrote:
I was looking for exactly this functionality myself this week. We have an organization of 2000 members and we wanted an independent way of controlling who can access a list.
When you say “independent way of controlling who can access a list”, do you mean that even like disabling the signups or like an even more fine grained logic around who can subscribe to what list and such?
Disabling signups is easy enough, I responded to a message in this thread.
In the end I decided that mailman3 was designed for something completely different than what we needed, so I've scrubbed this approach.
Mailman-users mailing list -- mailman-users@mailman3.org To unsubscribe send an email to mailman-users-leave@mailman3.org https://lists.mailman3.org/mailman3/lists/mailman-users.mailman3.org/
-- thanks, Abhilash Raj (maxking)
I believe that your patch was for the web front end, but that would still allow people to join by sending email to listname-join@example.com. We wouldn't be running any web interface anyway. I wanted to disable all methods of users joining and only rely upon an administrative process to handle who joins. It's easy to imagine a corporate use case for this, such as "all people with offices in building 43" or "all employees with dependents on health insurance" where the definition of who is on a list is maintained in an external system. We're not actually a corporation - we're a professional society with different member classes in our membership database. In any case, the decision of who belongs on a list is not made by the user.
In the interim I discovered another problem with DMARC failures in gmail when mail is sent through mailman3. Mail sent directly from our exim instance doesn't have this problem, so perhaps it's a problem with SRS. I won't be investigating this further, but I'm sure that SPF hard fails will be causing more problems for mailing lists in the future.
On 3/20/21 1:22 PM, mailman3@digicrime.com wrote:
I believe that your patch was for the web front end, but that would still allow people to join by sending email to listname-join@example.com. We wouldn't be running any web interface anyway. I wanted to disable all methods of users joining and only rely upon an administrative process to handle who joins. It's easy to imagine a corporate use case for this, such as "all people with offices in building 43" or "all employees with dependents on health insurance" where the definition of who is on a list is maintained in an external system. We're not actually a corporation - we're a professional society with different member classes in our membership database. In any case, the decision of who belongs on a list is not made by the user.
I understand these scenarios, but unless there is a high volume of spurious subscriptions, can't this be handled by setting the subscription police to include moderator approval?
In the interim I discovered another problem with DMARC failures in gmail when mail is sent through mailman3. Mail sent directly from our exim instance doesn't have this problem, so perhaps it's a problem with SRS. I won't be investigating this further, but I'm sure that SPF hard fails will be causing more problems for mailing lists in the future.
SPF always fails DMARC alignment on forwarded mail, whether from a mailing list or other forwarding mechanism because even though SPF may pass, the domain is that of the forwarding server, not the original sender.
While it is possible for a domain to set a DMARC policy and to rely only on SPF for validation, any domain with a DMARC policy should also be DKIM signing the mail because DKIM signatures will survive simple forwarding such as via .forward files or MTA aliases.
-- Mark Sapiro <mark@msapiro.net> The highway is for gamblers, San Francisco Bay Area, California better use your sense - B. Dylan
My understanding was that DMARC is merely a superset of DKIM+SPF along with some other policies. I have that set up on some of my domains. The weird part is that DKIM and SPF both passed, but DMARC was failing - I didn't realize it can happen but apparently it can: https://dmarcian.com/how-can-spfdkim-pass-and-yet-dmarc-fail/ We are in the process of introducing SRS for forwarded emails because we recently started seeing more SPF hard fail policy instances (e.g., columbia.edu).
This thread has drifted off topic anyway - sorry about that. The original topic was about user registration, which was orthogonal to this.
On 3/20/21 4:00 PM, mailman3@digicrime.com wrote:
My understanding was that DMARC is merely a superset of DKIM+SPF along with some other policies. I have that set up on some of my domains. The weird part is that DKIM and SPF both passed, but DMARC was failing - I didn't realize it can happen but apparently it can: https://dmarcian.com/how-can-spfdkim-pass-and-yet-dmarc-fail/
Your reference explains it. DMARC requires a valid SPF or DKIM sig with a domain which "aligns" with the domain of the From: address. Your valid SPF and DKIM signature from your domain will not be enough for DMARC to pass because your domain won't "align" with the From: domain. "align" is a technical term defined in RFC 7489. This is what ARC (RFC 8617) is trying to address.
-- Mark Sapiro <mark@msapiro.net> The highway is for gamblers, San Francisco Bay Area, California better use your sense - B. Dylan
participants (6)
-
Abhilash Raj -
jens.guenther＠posteo.de -
mailman3＠digicrime.com -
Mark Sapiro -
Stephen J. Turnbull -
Torge Riedel