restricting public lists per virtual domain
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
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@msapiro.net> The highway is for gamblers, San Francisco Bay Area, California better use your sense - B. Dylan
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
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
participants (3)
-
David Newman -
Mark Sapiro -
Stephen J. Turnbull