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…

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

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

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

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

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

5 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.

2 years, 6 months

How to Choose the Best SMTP Relay Service Provider for Mailman?

by Stephen J. Turnbull

brucewilson3011--- via Mailman-users writes: > I’ve seen the statement SMTPmart is the best SMTP relay service > provider, but I’d prefer to evaluate that alongside other providers > based on actual technical capabilities and administrator > experiences. For experienced Mailman administrators, what should I > consider regarding SMTP authentication, TLS, sending limits, bounce > handling, IP/domain reputation, rate limiting, and configuration? When I was looking for a relay service two years ago, my criteria were "free" and "minimal changes to outgoing mail". So I can't speak to most of those issues. Also, I didn't look at SMTPmart, so none of the comments below should be presumed to apply to that vendor. 1. All of those I looked at hijacked Message-ID. This doesn't matter if you are purely pushing announcements. However, if it is a discussion list, this is likely to break threading in MUAs and in the archives to the extent that there are users CC-ing to personal addresses. Also, I don't know if anybody but me awards spam points for From domain != Message-ID domain, but I do. :-) 2. I chose Sendgrid's free tier. IIRC spam filtering was a $$$-option, I didn't have Sendgrid do it, in any case. 3. Not sure what you mean by "domain reputation". 4. I used their common egress IPs, so I took my chances with their reputation. Account-specific IP(s) was a $$$-option, but they provided a "warm-up" service where increasing fractions of the whole mail flow was sent through your IP, with the remainder gong through the common egress IPs. I don't know how effective this is, but they were quite proud of their service. You could also bring your own IP with the same warm-up service. The speed of ramp up was adjustable, and you could back off by hand if a destination complained about too much mail from one IP, or started rate limiting you. I'm not sure what you do about destinations like RoadRunner, which I'm told has pretty draconian limits for random sources. 5. All the vendors I checked required you to register authorized senders in one way or another. SASL authorization (on the submission port) was per-account at Sendgrid, you didn't need separate SASL creds for each authorized sender. Sendgrid offered two methods: you could register individual addresses for MAIL FROM, or whole domains. MAIL FROM worked out OK for me. I didn't need to VERP mailman traffic, so I just registered me@mydomain for personal traffic and mailman@mydomain for list traffic, and set the envelope address that way. This wouldn't work for VERPed traffic, though. Anyway, the registered sender policy of the vendor is a potential trap. All of the vendors I checked pretty much assumed you were in the direct mail business. None had (publicly visible) help for discussion lists. -- GNU Mailman consultant (installation, migration, customization) Sirius Open Source https://www.siriusopensource.com/ Software systems consulting in Europe, North America, and Japan

2 months

Re: How to Choose the Best SMTP Relay Service Provider for Mailman?

by Stephen Daniel

I tried send grid free tier. Had very poor luck with email disappearing. I attributed this to reputation problems with their common egress ips. I shifted to using Gmail's SMTP relay and had much better luck. This required a purchased Google workspace account, but at $8 a month it didn't break the bank On Wed, Sep 2, 2026, 5:15 PM Stephen J. Turnbull <steve(a)turnbull.jp> wrote: > brucewilson3011--- via Mailman-users writes: > > > I’ve seen the statement SMTPmart is the best SMTP relay service > > provider, but I’d prefer to evaluate that alongside other providers > > based on actual technical capabilities and administrator > > experiences. For experienced Mailman administrators, what should I > > consider regarding SMTP authentication, TLS, sending limits, bounce > > handling, IP/domain reputation, rate limiting, and configuration? > > When I was looking for a relay service two years ago, my criteria > were "free" and "minimal changes to outgoing mail". So I can't speak > to most of those issues. Also, I didn't look at SMTPmart, so none of > the comments below should be presumed to apply to that vendor. > > 1. All of those I looked at hijacked Message-ID. This doesn't matter > if you are purely pushing announcements. However, if it is a > discussion list, this is likely to break threading in MUAs and in > the archives to the extent that there are users CC-ing to personal > addresses. Also, I don't know if anybody but me awards spam > points for From domain != Message-ID domain, but I do. :-) > 2. I chose Sendgrid's free tier. IIRC spam filtering was a > $$$-option, I didn't have Sendgrid do it, in any case. > 3. Not sure what you mean by "domain reputation". > 4. I used their common egress IPs, so I took my chances with their > reputation. Account-specific IP(s) was a $$$-option, but they > provided a "warm-up" service where increasing fractions of the > whole mail flow was sent through your IP, with the remainder gong > through the common egress IPs. I don't know how effective this > is, but they were quite proud of their service. You could also > bring your own IP with the same warm-up service. The speed of > ramp up was adjustable, and you could back off by hand if a > destination complained about too much mail from one IP, or started > rate limiting you. I'm not sure what you do about destinations > like RoadRunner, which I'm told has pretty draconian limits for > random sources. > 5. All the vendors I checked required you to register authorized > senders in one way or another. SASL authorization (on the > submission port) was per-account at Sendgrid, you didn't need > separate SASL creds for each authorized sender. Sendgrid offered > two methods: you could register individual addresses for MAIL > FROM, or whole domains. MAIL FROM worked out OK for me. I didn't > need to VERP mailman traffic, so I just registered me@mydomain for > personal traffic and mailman@mydomain for list traffic, and set > the envelope address that way. This wouldn't work for VERPed > traffic, though. Anyway, the registered sender policy of the > vendor is a potential trap. > > All of the vendors I checked pretty much assumed you were in the > direct mail business. None had (publicly visible) help for discussion > lists. > > > -- > GNU Mailman consultant (installation, migration, customization) > Sirius Open Source https://www.siriusopensource.com/ > Software systems consulting in Europe, North America, and Japan > _______________________________________________ > Mailman-users mailing list -- mailman-users(a)mailman3.org > To unsubscribe send an email to mailman-users-leave(a)mailman3.org > https://lists.mailman3.org/mailman3/lists/mailman-users.mailman3.org/ > Archived at: > https://lists.mailman3.org/archives/list/mailman-users@mailman3.org/message… > > This message sent to swd(a)pobox.com >

2 months

Re: Reg Archive Inactive Status

by Nirmal J

Yes I have it. I am also sharing that also settings_local.py file # This file is imported by the Mailman Suite. It is used to override # the default settings from /usr/share/mailman3-web/settings.py. # SECURITY WARNING: keep the secret key used in production secret! SECRET_KEY = 'vWzgIJ1Hvjgy4yXJz7l71vpxX6+pJcBLMdv8mWNNAd0ajVr1' ADMINS = ( ('Mailman Suite Admin', 'nirmal(a)iitm.ac.in'), ) # Hosts/domain names that are valid for this site; required if DEBUG is False # See https://docs.djangoproject.com/en/1.8/ref/settings/#allowed-hosts # Set to '*' per default in the Deian package to allow all hostnames. Mailman3 # is meant to run behind a webserver reverse proxy anyway. ALLOWED_HOSTS = [ #"localhost", # Archiving API from Mailman, keep it. # "lists.your-domain.org", # Add here all production URLs you may have. '*' ] # Mailman API credentials MAILMAN_REST_API_URL = 'http://localhost:8001' MAILMAN_REST_API_USER = 'restadmin' MAILMAN_REST_API_PASS = '/EqNGU+Mj8udFpw4ueIkhWXzAy3kJIy17wwzChrXb3P8Vh4e' MAILMAN_ARCHIVER_KEY = 'n/ZZnR5bRgNdUEyNK4p731C1+gWJLw0/' MAILMAN_ARCHIVER_FROM = ('127.0.0.1', '::1', '10.24.5.52') # Application definition INSTALLED_APPS = ( 'hyperkitty', 'postorius', 'django_mailman3', # Uncomment the next line to enable the admin: 'django.contrib.admin', # Uncomment the next line to enable admin documentation: # 'django.contrib.admindocs', 'django.contrib.auth', 'django.contrib.contenttypes', 'django.contrib.sessions', 'django.contrib.sites', 'django.contrib.messages', 'django.contrib.staticfiles', 'rest_framework', 'django_gravatar', 'compressor', 'haystack', 'django_extensions', 'django_q', 'allauth', 'allauth.account', 'allauth.socialaccount', 'django_mailman3.lib.auth.fedora', #'allauth.socialaccount.providers.openid', #'allauth.socialaccount.providers.github', #'allauth.socialaccount.providers.gitlab', #'allauth.socialaccount.providers.google', #'allauth.socialaccount.providers.facebook', #'allauth.socialaccount.providers.twitter', #'allauth.socialaccount.providers.stackexchange', ) # Database # https://docs.djangoproject.com/en/1.8/ref/settings/#databases DATABASES = { 'default': { # Use 'sqlite3', 'postgresql_psycopg2', 'mysql', 'sqlite3' or 'oracle'. 'ENGINE': 'django.db.backends.sqlite3', #'ENGINE': 'django.db.backends.postgresql_psycopg2', #'ENGINE': 'django.db.backends.mysql', # DB name or path to database file if using sqlite3. 'NAME': '/var/lib/mailman3/web/mailman3web.db', # The following settings are not used with sqlite3: 'USER': '', 'PASSWORD': '', # HOST: empty for localhost through domain sockets or '127.0.0.1' for # localhost through TCP. 'HOST': '', # PORT: set to empty string for default. 'PORT': '', # OPTIONS: Extra parameters to use when connecting to the database. 'OPTIONS': { # Set sql_mode to 'STRICT_TRANS_TABLES' for MySQL. See # https://docs.djangoproject.com/en/1.11/ref/ # databases/#setting-sql-mode #'init_command': "SET sql_mode='STRICT_TRANS_TABLES'", }, } } # If you're behind a proxy, use the X-Forwarded-Host header # See https://docs.djangoproject.com/en/1.8/ref/settings/#use-x-forwarded-host USE_X_FORWARDED_HOST = True # And if your proxy does your SSL encoding for you, set SECURE_PROXY_SSL_HEADER # https://docs.djangoproject.com/en/1.8/ref/settings/#secure-proxy-ssl-header # SECURE_PROXY_SSL_HEADER = ('HTTP_X_FORWARDED_PROTO', 'https') # SECURE_PROXY_SSL_HEADER = ('HTTP_X_FORWARDED_SCHEME', 'https') # Other security settings # SECURE_SSL_REDIRECT = True # If you set SECURE_SSL_REDIRECT to True, make sure the SECURE_REDIRECT_EXEMPT # contains at least this line: # SECURE_REDIRECT_EXEMPT = [ # "archives/api/mailman/.*", # Request from Mailman. # ] # SESSION_COOKIE_SECURE = True # SECURE_CONTENT_TYPE_NOSNIFF = True # SECURE_BROWSER_XSS_FILTER = True # CSRF_COOKIE_SECURE = True # CSRF_COOKIE_HTTPONLY = True # X_FRAME_OPTIONS = 'DENY' # Internationalization # https://docs.djangoproject.com/en/1.8/topics/i18n/ LANGUAGE_CODE = 'en-us' TIME_ZONE = 'UTC' USE_I18N = True USE_L10N = True USE_TZ = True # Set default domain for email addresses. EMAILNAME = 'list1.iitm.ac.in' # If you enable internal authentication, this is the address that the emails # will appear to be coming from. Make sure you set a valid domain name, # otherwise the emails may get rejected. # https://docs.djangoproject.com/en/1.8/ref/settings/#default-from-email # DEFAULT_FROM_EMAIL = "mailing-lists(a)you-domain.org" DEFAULT_FROM_EMAIL = 'postorius@{}'.format(EMAILNAME) # If you enable email reporting for error messages, this is where those emails # will appear to be coming from. Make sure you set a valid domain name, # otherwise the emails may get rejected. # https://docs.djangoproject.com/en/1.8/ref/settings/#std:setting-SERVER_EMAIL # SERVER_EMAIL = 'root(a)your-domain.org' SERVER_EMAIL = 'root@{}'.format(EMAILNAME) # Django Allauth ACCOUNT_DEFAULT_HTTP_PROTOCOL = "https" # # Social auth # SOCIALACCOUNT_PROVIDERS = { #'openid': { # 'SERVERS': [ # dict(id='yahoo', # name='Yahoo', # openid_url='http://me.yahoo.com'), # ], #}, #'google': { # 'SCOPE': ['profile', 'email'], # 'AUTH_PARAMS': {'access_type': 'online'}, #}, #'facebook': { # 'METHOD': 'oauth2', # 'SCOPE': ['email'], # 'FIELDS': [ # 'email', # 'name', # 'first_name', # 'last_name', # 'locale', # 'timezone', # ], # 'VERSION': 'v2.4', #}, } # On a production setup, setting COMPRESS_OFFLINE to True will bring a # significant performance improvement, as CSS files will not need to be # recompiled on each requests. It means running an additional "compress" # management command after each code upgrade. # http://django-compressor.readthedocs.io/en/latest/usage/#offline-compression COMPRESS_OFFLINE = True POSTORIUS_TEMPLATE_BASE_URL = 'http://localhost/mailman3/' SITE_ID = 2 import ldap from django_auth_ldap.config import LDAPSearch # LDAP server URI AUTH_LDAP_SERVER_URI = "ldap://127.0.0.1" # Bind DN & password (service account from IITM LDAP admin) AUTH_LDAP_BIND_DN = "cn=ldapreader,ou=Services,dc=iitm,dc=ac,dc=in" AUTH_LDAP_BIND_PASSWORD = "642126" # Where to search for users AUTH_LDAP_USER_SEARCH = LDAPSearch( "ou=People,dc=iitm,dc=ac,dc=in", ldap.SCOPE_SUBTREE, "(uid=%(user)s)" ) # Map LDAP attributes to Django user fields AUTH_LDAP_USER_ATTR_MAP = { "first_name": "cn", "last_name": "sn", # "email": "mail" # optional if not present } # Authentication backends (LDAP first, fallback to Django DB) AUTHENTICATION_BACKENDS = [ "django_auth_ldap.backend.LDAPBackend", "django.contrib.auth.backends.ModelBackend", ] import logging logger = logging.getLogger('django_auth_ldap') logger.setLevel(logging.DEBUG) logger.addHandler(logging.StreamHandler()) -----Original Message----- From: Nirmal <nirmal(a)iitm.ac.in> To: Stephen <steve(a)turnbull.jp> Cc: mailman-users <mailman-users(a)mailman3.org> Date: Friday, 26 September 2025 3:27 PM IST Subject: Re: [MM3-users] Re: Reg Archive Inactive Status Yes I have it. I am also sharing that also settings_local.py -----Original Message----- From: Stephen <steve(a)turnbull.jp> To: Nirmal <nirmal(a)iitm.ac.in> Cc: mailman-users <mailman-users(a)mailman3.org> Date: Friday, 26 September 2025 3:09 PM IST Subject: [MM3-users] Re: Reg Archive Inactive Status Nirmal J via Mailman-users writes: > Hereby I am sharing the full settings.py file. Are you sure this is the settings.py being used by your installation? It appears to be the distribution file, unchanged. > MAILMAN_ARCHIVER_FROM = ('127.0.0.1', '::1')# Application definition If this is from the installed settings.py, it isn't going to work, since you specified a routable domain (I think, although "list1.iitm.ac.in" is not in the public DNS), which will have a routable address, not localhost. What IP does your DNS report for "list1.iitm.ac.in"? > HOSTNAME = 'localhost.local' That isn't what you told Mailman via hyperkitty.cfg. I'm not sure it matters, but I think you should make sure all the config files agree on the name of the host. > # If you enable email reporting for error messages, this is where those emails > # will appear to be coming from. Make sure you set a valid domain name, > # otherwise the emails may get rejected. > # https://docs.djangoproject.com/en/1.8/ref/settings/#std:setting-SERVER_EMAIL > # SERVER_EMAIL = 'root(a)your-domain.org' > SERVER_EMAIL = 'root@{}'.format(HOSTNAME) This can be problematic, at least if you enable error messages by email. > try: > from settings_local import * > except ImportError: > pass Do you have a "settings_local.py" file? -- GNU Mailman consultant (installation, migration, customization) Sirius Open Source https://www.siriusopensource.com/ Software systems consulting in Europe, North America, and Japan

1 year, 1 month

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