Search results for "Postorius" - Mailman-users

Re: Mailman Core 3.3.2 is now out

by Seth Seeger

When will these changes be available via the docker container? Thanks, Seth > On Nov 6, 2020, at 8:38 PM, Abhilash Raj <maxking(a)asynchronous.in> wrote: > > Hi Everyone, > > I am pleased to announce that with a week long delay from the planned date, > GNU Mailman Core 3.3.2 is now finally out. This release includes both bug fixes > and some new features. > > Some notable changes include: > - Support for inviting users to join mailing lists. > - New adddmembers, delmembers and syncmembers command to manage membership from CLI. > - Addition of new REST API endpoints that return the count of held messages and subscription requests of much faster page loads in Postorius. > - Addition of support for filtering in some API endpoints like Members and Subscription requests. > - Support for address= option in email join command to subscribe an address other then sending address. > - Addition of who email command to lookup memberships. > - Expose emergency field for MailingList resource in REST API. > - Several bug fixes to support new major version of libraries like dnspython, flufl.* etc. > > You can install it using: > > $ pip install --upgrade mailman > > The tarball for the release is available at PyPI: > > https://pypi.org/project/mailman/ > > Finally, many thanks to all the contributors who have helped make this release a success! > > -- > Abhilash Raj (maxking) on behalf of Mailman Core team > _______________________________________________ > 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/

5 years, 11 months

Re: urls.py location on venv install

by Mark Sapiro

On 8/9/26 09:08, Torsten wrote: > > In fact, my settings.py does contain these import lines: > > import os This should not be needed unless something further down references os. > from mailman_web.settings.base import * > from mailman_web.settings.mailman import * > > BASE_DIR = ('/var/lib/mailman3/web') > > SECRET_KEY = '<MYSECRETKEY>' > DEBUG = False > > #: Default list of admins who receive the emails from error logging. > ADMINS = ( ('Mailman Suite Admin', 'torsten(a)bbadmin.de'),) > > ALLOWED_HOSTS = ['localhost', '127.0.0.1',] You may also want your public facing web domain here. > INSTALLED_APPS = [ > 'django_mailman3', > 'postorius', > 'hyperkitty', > # Uncomment the next line to enable the admin: > 'django.contrib.admin', I'm hoping there's more to this file, but in any case unless you're adding or deleting something from the definition in mailman-web/settings/base.py, this is redundant and if you are adding, it's better to do ``` INSTALLED_APPS.append('app.to.add') ``` or to remove something, for example ``` del INSTALLED_APPS[INSTALLED_APPS.index(django.contrib.admin')] ``` > And I have the mailman_web/urls.py in the venv where mailman was installed. If you are using gunicorn as your wsgi server, I think there is an issue in the documentation. <https://docs.mailman3.org/en/latest/install/virtualenv.html#setting-up-guni…> says etc/mailman3/gunicorn.conf should contain `chdir = "/opt/mailman/mm"`. I think this is wrong. It should be `chdir = "/etc/mailman3"`. -- Mark Sapiro <mark(a)msapiro.net> The highway is for gamblers, San Francisco Bay Area, California better use your sense - B. Dylan

2 months, 2 weeks

Re: Is there an option to "disable" a list temporarily? (feature request?!)

by Washington Odhiambo

On Mon, Feb 2, 2026 at 2:27 PM Christian Schneider < christian.schneider(a)tu-dortmund.de> wrote: > Hello dear Mailman Team, > > I scanned through the web interface of my mailman instance... > and I did not find an option to disable a list temporarily ("sending" and > "access to web interface")... > This might come in handy when a list is abused for sending spams > or when a list owner wants his/her list to be removed... > Instead of removing the list instantly I would disable it for three months > first... > (You never know with users... ;-) ) > Preferably I would backup the list (settings and members) and the archives, > but as seen in the discussion there is actually no backup mechanism for > lists... > > Is there an option to disable a list (except from resetting passwords and > remove/disable mail aliases)? > To disable access to Postorius, you can achieve that using the web server. To disable mail processing, you do that by disabling the mail aliases or just redirect a list address to /dev/null. > If not I'd like to hand this in as a feature request... xD > I always see the Devs say that you do that by creating an issue in gitlab. -- Best regards, Odhiambo WASHINGTON, Nairobi,KE +254 7 3200 0004/+254 7 2274 3223 In an Internet failure case, the #1 suspect is a constant: DNS. "Oh, the cruft.", egrep -v '^$|^.*#' ¯\_(ツ)_/¯ :-) [How to ask smart questions: http://www.catb.org/~esr/faqs/smart-questions.html]

8 months, 3 weeks

Re: starting gunicorn per mailman.log yet gunicorn not installed

by Mark Sapiro

On 6/26/23 1:15 AM, Odhiambo Washington wrote: > On Mon, Jun 26, 2023 at 9:29 AM Stephen J. Turnbull < > turnbull.stephen.fw(a)u.tsukuba.ac.jp> wrote: > >> Yes, it makes sense. Mailman 3 core is basically an application which >> manages a webserver that provides the REST API, a database of domains, >> users, and lists, an LMTP server for incoming posts and an SMTP client >> for outgoing distribution. Mailman uses gunicorn to provide the >> webserver. >> >> Installation of gunicorn is handled as a package dependency, so you >> probably wouldn't notice unless you were watching the installation >> process very carefully. >> > > It doesn't make sense, IMHO, because as the OP says, > 1. his ExecStart is: > ExecStart=/opt/mailman/venv/bin/uwsgi --ini /etc/mailman3/uwsgi.ini" *and > not* > ExecStart=/opt/mailman/venv/bin/gunicorn -c /etc/mailman3/gunicorn.conf > mailman_web.wsgi:application. > > 2. He has not knowingly created any gunicorn.conf > > Why would Gunicorn be Exec-ing itself? :-) As Steve says, Mailman core uses Gunicorn to manage it's REST API. This has nothing to do with whatever WSGI server (uWSGI, Gunicorn, Apache mod_wsgi, ...) is used to support the Django applications (django-mailman3, hyperkitty and postorius). I.e., there is always a Gunicorn instance configured and started by Mailman core, regardless of whatever WSGI server supports Django or even if one isn't running Django at all. -- Mark Sapiro <mark(a)msapiro.net> The highway is for gamblers, San Francisco Bay Area, California better use your sense - B. Dylan

3 years, 4 months

Re: Can't add emails to accept_these_nonmembers

by Ibiam Chihurumnaya

Stephen J. Turnbull wrote: > Ibiam Chihurumnaya via Mailman-users writes: > > I had done the members part in the past, but the issue with it was > > I wanted certain members to not receive messages from the list, but > > only send to the list. > > As Mark explained, you can set those members to 'Default Processing' > in the moderation option, and to 'No Mail' in the mail options. In > that case they or list owners could reset them to receive mail. Yes, I'll try this. > The alternative is to add the addresses one by one as non-members and > set their moderation. In that case they cannot receive mail, although > they may be able to subscribe themselves depending on list settings, > or an administrator could subscribe them. In both cases the nonmember > would remain unless removed by an administrator. > In both cases, although you can add members with mass subscription, > there are no "mass" operations to update the subscription option or to > create non-members in Postorius, you need to do it one by one. You > can automate that by using a loop over a list of addresses in Mailman > shell, or if you expect to do it more than once, you could create a > withlist script to use with the -r option. It's just a few emails so I'm doing it manually. > -- > GNU Mailman consultant (installation, migration, customization) > Sirius Open Source https://www.siriusopensource.com/ > Software systems consulting in Europe, North America, and Japan

8 months

Re: Twitter OAuth2

by Odhiambo Washington

On Wed, Dec 28, 2022 at 8:23 PM Mark Sapiro <mark(a)msapiro.net> wrote: > On 12/27/22 21:46, Odhiambo Washington wrote: > > On Tue, Dec 27, 2022 at 8:08 PM Mark Sapiro <mark(a)msapiro.net> wrote: > >> > >> I see from another post that you've decided against using Twitter, but > >> to answer the question, Twitter does not require adding anything to > >> SOCIALACCOUNT_PROVIDERS. > >> > > > > I tried it and ended up with: > > > > ERROR 2022-12-28 08:40:18,895 97440 django.request Internal Server Error: > > /accounts/twitter/login/ > > Traceback (most recent call last): > ... > > allauth.socialaccount.models.SocialApp.DoesNotExist: SocialApp matching > > query does not exist. > > > Do you have > > 'allauth.socialaccount.providers.twitter', > > in INSTALLED_APPS? > Here is what I have in settings_local.py: 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', ) -- Best regards, Odhiambo WASHINGTON, Nairobi,KE +254 7 3200 0004/+254 7 2274 3223 "Oh, the cruft.", egrep -v '^$|^.*#' ¯\_(ツ)_/¯ :-)

3 years, 10 months

Re: Turn off social logins?

by tlhackque

I am one who uses Mailman to support a closed community. Social logins are NOT a good thing there. Besides encouraging spam signups (social media accounts are easy to get - just ask the spammers), they tie your site to the privacy and other policies of the providers. This includes that when they authenticate, they also track users and sites. Monetizing the data. Many people find this objectionable. And not auditable. When I tried to use MM3, turning off social logins was one of the first things I tried to configure. It wasn't easy. First I commented out too much, then too little. The resulting errors were opaque. I hope things have improved - at present I keep an eye on MM3, but it's not usable for me at this time. So I may be somewhat behind the times. The admin interface could use an authentication control panel - per site, and per-list. Click to enable/disable the social (password, 2-factor, and other plugin) providers. On the whole, MM3 is far to painful to set up - editing hierarchies of config files assumes a technical person runs the list. Frequently, people who want lists aren't. [X} login with Google [x] login with passwords [x] login with GitHub is comprehensible - the implications may not be, but better to explain policies than how to edit a config file written in a foreign language. There's a big difference between "installing" (that can assume some technical knowledge) and "configuring" (that should not). The former has to do with where you put files, how updates and time-driven events are enabled. The latter is how one expresses one's site policies/preferences. Package managers and MaxKing's containers are "good enough" for installing. "configuring" by config files and extensive wiki searches is not. The persistent echos of issues I raised and appear on the list from others are in the same vein. Cut and paste is not scalable for bulk subscribing thousands of users. Neither is API performance. Or "resent confirmation codes". or... I recognize that replacing a mature technology is hard. MM3 has a lot of potential. It's just not there, for me, yet. On 12-Feb-19 11:11, Stephen J. Turnbull wrote: > Note: I've changed the order of sentences from Torge's post to fit my > responses. > > Torge Riedel writes: > > > I do agree, same here on my side. Lot's of my users are very > > "sensitive" to social media and don't want see them here. > > This is the first I've heard of this. Obviously it's fairly > widespread; *please* speak up if anyone have similar issues that we > haven't addressed. AFAIK all of the currently active Mailman > developers believe that social auth is a GoodThang[tm], so we're > unlikely to DTRT as you see it without your help. > > > I need to migrate from mailman2 to mailman3 and was wondering why > > social accounts are enabled by default > > By default Mailman 3 is social media: you have a profile, you can be > searched in the indicies of the archives, and so on. The large auth > providers provide more secure authentication, and a lot of convenience > for users who have such accounts already. They also take some > administrative burden off the list and site managers when people lose > their passwords and forget what their subscription address is, and > similar scenarios. Clearly, these are not universally-valued > features, but I think that they justify the current defaults. > > > and are difficult to disable. > > They're easy enough to disable (easy to recognize and just add a hash > character in front), since you have to edit settings_local.py to > install anyway. If you're using a packaged version and the package > configuration utility doesn't handle it, there's nothing we can do > about it. The distro will have to deal with that. > > It should be better documented, I imagine (haven't checked yet). > > > I propose something like an additional setting listing the enabled > > social accounts. > > Do you mean in the Postorius administration interface? If so, do you > want it by-site, by-domain, or by-list? ("You" is everybody who wants > to disable social auth, not just Torge!) > > If you mean in settings_local.py, I suggested something similar > earlier. It's not obvious it would be easy to do (sometimes these > things are order-dependent, though that's bad practice). > > > And if the admin is setting this to an empty value in the > > settings_local.py everything is disabled > > Because the settings are a Python module, this is the way > settings_local.py works anyway. That's why Mark suggested editing > INSTALLED_APPS. > _______________________________________________ > 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/ -- This communication may not represent my employer's views, if any, on the matters discussed.

7 years, 8 months

Re: Post-installation documentation?

by David Newman

On 11/25/21 10:28 AM, Mark Sapiro wrote: > On 11/24/21 10:17 PM, David Newman wrote: >> On 11/24/21 2:36 PM, Mark Sapiro wrote: >>> >>> To import archives run the Django admin command with arguments >>> >>> hyperkitty_import -l alist(a)example.com >>> /path/to/mailman2.1/archives/private/alist.mbox/alist.mbox >> >> Good up to here, but ... hyperkitty_import not found. >> >> This wasn't covered in the venv docs: > > It is covered at > https://docs.mailman3.org/en/latest/migration.html#upgrade-strategy > > Your issue is probably that the Django admin command you ran is not > accessing your `settings.py`. You may need to do > ``` > export DJANGO_SETTINGS_MODULE=settings > export PYTHONPATH=/path/to/directory/containing/settings.py > ``` > before running the Django admin command. These can also be given as > --settings and --pythonpath options to the Django admin command. Thanks for this. After setting these variables and restarting mailman3 and mailmanweb, the mailman user still cannot find a hyperkitty_import command (neither can root, btw). Again, I installed MM3 and Django/Postorius/Hyperkitty using the venv and web docs previously referenced. On the plus side, all lists now appear in the admin web page. However, lists created from the admin page do not appear in a site list page, even though all lists are in the same site/domain. Finally, how to make these exports permanent? I did not see this covered in the migration doc above. This is on a Debian system where the mailman user's shell is bash. Is this simply a matter of adding environment variables in the mailman user's .bashrc file? Thanks dn

4 years, 11 months

Re: How to best disable message decoration for all lists defined for a domain

by Mark Sapiro

On 3/18/19 2:19 PM, Ralph Seichter wrote: > Hello list. > > I have read [1] and [2], but I am not quite sure what the recommended > method is to completely disable message headers/footers and subject > modifications for *all* lists tied to a specific domain. Being new to > Mailman 3, I was actually surprised that there are no configuration > switches in the Web UI's settings for mailing lists that allow me to get > rid of unwanted message decorations. It's still a work in progress. You can do it via list settings except for one issue [1]. See that issue and also the post referenced in it's description [2]. To not modify the Subject for a list, on the list's Settings -> List Identity tab, set 'Subject prefix' empty. To not add headers and or footers, you need empty templates for them. These could be created via the list's Templates form except until [1] is fixed, you can't make empty templates. You can use the method in [2] to create empty var/templates/domains/DOMAIN.NAME/LC/list:member:generic:footer.txt and var/templates/domains/DOMAIN.NAME/LC/list:member:generic:header.txt files for the domain and language. Then as long as no list specific templates are created for lists in that domain, no headers or footers will be added. [1] <https://gitlab.com/mailman/postorius/issues/331> [2] <https://lists.mailman3.org/archives/list/mailman-users@mailman3.org/message…> -- Mark Sapiro <mark(a)msapiro.net> The highway is for gamblers, San Francisco Bay Area, California better use your sense - B. Dylan

7 years, 7 months

How to approve moderated messages via email?

by Stephen J. Turnbull

Brian Carpenter writes: > What is the protocol to approve moderated messages via email? I > hope I asking the question correctly. Is this capability important to you or your clients? If so, what is the context? I ask because, as you know, email is rather insecure by default. Making it highly secure would require a lot of effort and sophistication for the moderator, eg, PGP signatures, but there might be intermediate levels that would be appropriate for many lists. For example, the Mailman 2 mechanism. I forget exactly what Mailman 2 does, but if the post to be approved were identified by a one-time key, then a spammer would have to have both the moderation password and the key (presumably by intercepting the moderation email) to approve their own spam. That's still a plausible scenario in principle[1] so I don't much like it (and I bet that's why Barry didn't implement it), but it would be straightforward to implement. Footnotes: [1] Ie, a moderator falls for a phish; then Ms. Cantor[2] probably got everything she needs to spoof approvals. It's questionable whether a spammer would go to the trouble of identifying a moderator, phishing them, reading their mail, and using the email approval to spam for profit, of course. But I can easily imagine it if somebody hates you. On the other hand, if they have your Gmail password, and you use your Gmail account to authenticate to Postorius, they can do it by web, so disallowing email approvals is no help. Security is hard .... Maybe we should implement 2FA for privileged roles. [2] Original "Green Card Lawyer".

5 years, 9 months

Mailman-users search results for query "Postorius"