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)

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.

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)

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

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