Search results for "public lists per domain" - Mailman-users

restricting public lists per virtual domain

by David Newman

Can lists set to be viewable on the index page be limited to the virtual domain they are a part of? Let's say I have two virtual domains: lists.dom1.tld lists.dom2.tld Currently, if any list in either domain is set to be viewable on the index page, it's viewable in both domains, not just the one it's a part of. How to restrict access on a per-domain basis? I searched the archives and found something about disabling archives per domain [1], but that's a different question. This seems like a standard problem and may have been asked a different way before, and I may have missed it. Thanks in advance for config clues. dn [1] https://lists.mailman3.org/archives/search?mlist=mailman-users%40mailman3.o…

2 years, 11 months

Re: restricting public lists per virtual domain

by Mark Sapiro

On 12/16/21 12:25 PM, David Newman wrote: > Can lists set to be viewable on the index page be limited to the virtual > domain they are a part of? > Have you set FILTER_VHOST = True in your Django settings? This works for HyperKitty and works partially for Postorius. For Postorius, it doesn't work if there are multiple domains with different email hosts which have the visiting host as their web host[1] but works otherwise. See https://gitlab.com/mailman/postorius/-/merge_requests/500 and https://gitlab.com/mailman/postorius/-/issues/394 In your case, as long as the domains lists.dom1.tld and lists.dom2.tld have different mail hosts, this should work. [1] An example of what doesn't work in Postorius is the following: Visit https://lists.example.com/mailman3/lists. If there are 2 domains with web host lists.example.com, one of which has mail host example.com and the other has mail host lists.example.com, all lists will be shown regardless of domain. On the other hand, if all the domains with web host lists.example.com have the same email host, say example.com, then only lists with email host example.com will be shown. -- Mark Sapiro <mark(a)msapiro.net> The highway is for gamblers, San Francisco Bay Area, California better use your sense - B. Dylan

2 years, 11 months

Re: restricting public lists per virtual domain

by David Newman

On 12/16/21 2:40 PM, Mark Sapiro wrote: > On 12/16/21 12:25 PM, David Newman wrote: >> Can lists set to be viewable on the index page be limited to the >> virtual domain they are a part of? >> > > > Have you set > > FILTER_VHOST = True > > in your Django settings? I had not, and this was the variable I was looking for. Thank you! This works for HyperKitty and works partially > for Postorius. For Postorius, it doesn't work if there are multiple > domains with different email hosts which have the visiting host as their > web host[1] but works otherwise. > > See https://gitlab.com/mailman/postorius/-/merge_requests/500 and > https://gitlab.com/mailman/postorius/-/issues/394 > > In your case, as long as the domains lists.dom1.tld and lists.dom2.tld > have different mail hosts, this should work. > > [1] An example of what doesn't work in Postorius is the following: > > Visit https://lists.example.com/mailman3/lists. If there are 2 domains > with web host lists.example.com, one of which has mail host example.com > and the other has mail host lists.example.com, all lists will be shown > regardless of domain. On the other hand, if all the domains with web > host lists.example.com have the same email host, say example.com, then > only lists with email host example.com will be shown. Awhile back Stephen Turnbull suggested a terminology guide that included an MM3-specific definition of FQDNs. Also in an MM3 context, I think it would be useful to distinguish between mail hosts and web hosts and domains (all in the general Internet sense) and mail domains and sites (in the MM3/Django/Postorious/Hyperkitty sense). Not sure I fully understand these distinctions yet, but I can take a crack at it. dn

2 years, 11 months

Re: restricting public lists per virtual domain

by Stephen J. Turnbull

David Newman writes: > Awhile back Stephen Turnbull suggested a terminology guide that > included an MM3-specific definition of FQDNs. I think that Mailman should use the usual definitions, but sometimes we have more restrictive implementations. For example, although we store the case sensitive form of email addresses, some checks for equality of email addresses are case insensitive even though local parts can be case sensitive at some hosts. That can be surprising, although frequently it's what users expect. It's going to be hard to document all of these, but even listing some of them will probably help users diagnose issues for themselves, or suggest improvements. > > Also in an MM3 context, I think it would be useful to distinguish > between mail hosts and web hosts and domains (all in the general > Internet sense) and mail domains and sites (in the > MM3/Django/Postorious/Hyperkitty sense). Yes, this is really complicated. Web hosts aren't too bad, although often www.example.com will be a CNAME for example.com and configurations like that, but Internet mail is quite a mess, what with CNAME, MX, and PTR at least being involved, and if you are doing signatures, all the stuff for SPF, DKIM, DMARC, ARC and more, not to forget that if you're actually sending and receiving mail you need to worry about distinctions among SMTP, LMTP, and SUBMIT, and all of the SSL/TLS versions. *sigh* > Not sure I fully understand these distinctions yet, but I can take a > crack at it. Just list them under "this stuff is really weird, watch out for dragons lest you be toasted from behind". :-) Steve

2 years, 11 months

Disable archives per list

by Bernd Wurst

Hello, we are about to migrate our Mailman 2 instance to Mailman 3. As we are hosting many (small) mailing lists for different customers, we get in trouble about future handling of mail archives. Mailman 2 just used mbox files per list and flat files for public archive, so archives do not matter apart from some storage. With hyperkitty, all messages for all lists are stored in on single database and I'm a little bit scared of a single database table with dozens of GB of data. Many of our users do not really need archiving, some customers also asked archiving to be disabled for legal reasons within their lists. Can I as the server admin disable archiving (or set other list options) in a way that the list admin can not change it via postorious? Can I have custom archiver settings per list or per domain (customer-specific hyperkitty)? regards, Bernd

3 years, 9 months

Re: Disable archives per list

by Mark Sapiro

On 2/25/21 1:57 AM, Bernd Wurst wrote: > > Can I as the server admin disable archiving (or set other list options) > in a way that the list admin can not change it via postorious? As the server admin, you can enable/disable archivers sitewide. See <https://gitlab.com/mailman/mailman/-/blob/master/src/mailman/config/schema.…> et seq. Note that the prototype archiver, if enabled, stores messages in the file system in maildir format. Normally a list admin can select which of the enabled archivers is active for that list via Postorius. To prevent this, you would have to modify Postorius. It would be easy enough to just remove settings from the relevant templates. > Can I have custom archiver settings per list or per domain > (customer-specific hyperkitty)? I'm not sure what you mean by "custom archiver settings", but other than enable/disable and public/private, probably not. -- Mark Sapiro <mark(a)msapiro.net> The highway is for gamblers, San Francisco Bay Area, California better use your sense - B. Dylan

3 years, 8 months

Re: Welcome message template errors

by Mark

On 2024-04-25 01:37, Mark Sapiro wrote: > I think the difference is http vs https, not the IP vs domain name. > > Also, with either of these, you are addressing the web server and not > the wsgi server. The wsgi server is presumable listening on port 8000 > and in the beginning when you had the default > > POSTORIUS_TEMPLATE_BASE_URL = 'http://localhost:8000' With this default, the template URI is in the format of http://localhost:8000/mailman3/api/templates/list/mytestlist.mydomain.com/l… Looking at this URI in lynx (on the same server as Mailman) it returns the text of the custom Welcome template, as does curl and wget. And it's the same if 127.0.0.1 is used in place of localhost -- ie. http://127.0.0.1:8000/mailman3/api/templates/list/mytestlist.mydomain.com/l… And the same result if the domain name is used with https -- ie. https://mydomain.com/mailman3/api/templates/list/mytestlist.mydomain.com/li… So, the template is all good, it can be accessed by Lynx, but the part of the Mailman suite that sends out the custom Welcome message cannot access it and spits out the error. Where are the custom templates stored? Is there a permissions issue perhaps? A grep for the text of my Welcome message turns up zero results. # grep -Rnw '/' -e 'Test two million for welcome' By the way, in Lynx when the template's URI uses the public ip adress -- ie. http://my-public-ip-address/mailman3/api/templates/list/mytestlist.mydomain… ... it returns a "404 page not found" in Lynx. Given that this is pretty much an out-of-the-box installation (venv installation as per the docs) and everything else works perfectly I'm thinking surely others have encountered this. Or is it just me? It's completely done my head in, so if anyone can offer a glimmer of light I'll grab it. > <REDACTED-PUBLIC-IPv4-ADDRESS> instead of 127.0.0.1. Also, > Have you set > ALLOWED_HOSTS in your settings.py? It should be something like > ``` > ALLOWED_HOSTS = [ > "localhost", # Archiving API from Mailman, keep it. > "127.0.0.1", > "<REDACTED-PUBLIC-IPv4-ADDRESS>", > "MYDOMAIN.COM", > ] Yes.

6 months, 4 weeks

Mailman-users search results for query "public lists per domain"