Search results for "Postorius" - Mailman-users

delete unverified accounts

by noemi

Hi, I'm noticing that a lot of 'spammers' are registering themself via postorius. They do not send emails, neither they are in any list, so they are not technically spammers, but they are a lot [maybe around 500 subscribed in the last month]. While waiting for a captcha system[0] for the main distribution, I'm looking for a rapid/easy way to delete this accounts; since they are not 'verified', I was wondering if I can locate this information in the mailman3 database or if there is some easier way to delete all unverified accounts. Do some of you any help or indications? I'm using GNU Mailman 3.3.9 (Tom Sawyer). Thanks, noemi for pangea.org [ https://lists.mailman3.org/archives/list/mailman-users@mailman3.org/thread/… ]

2 years, 9 months

Re: Extracting mailing list users

by Jan Eden

On 2023-01-02 14:36, Eggert Ehmke via Mailman-users wrote: > Thank you, that worked! Now all my addresses are clean. > > Still, don't you think this should be possible via Postorius, or by some mailman cli command, like > mailman rename_member <old> <new> > > It happened I had still the patched cli_members.py where I had both the old and new line active: > print(formataddr((address.display_name, address.original_email)), file=outfp) > print(f'{address.display_name} <{address.original_email}>', file=outfp) > The first (old) line still produces the output with utf-8 codes. Is this to be expected? I would assume the original line outputs the QP-escaped names, to be used in an email header. - Jan

3 years, 8 months

Re: Turn off social logins?

by Hagen Bauer

Hi, same thing here. A lot of usergroups "accept" social media but in regards to data privacy like to avoid it. Although technical not true people might believe that Facebook & Co have access to the data in a local mailman install. I would like to disable it to but havent yet the time to dive into it. +1 for site wide disabling Regards Hagen On 12.02.19 17: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/ >

7 years, 7 months

Re: confirm-email: error NoReverseMatc

by Simon Hanna

On 01/31/2018 11:59 AM, Peter Münster wrote: > On Wed, Jan 31 2018, Simon Hanna wrote: > >> It's complaining about an empty url used for reversing. Do you mind sharing >> your settings.py file? we don't need the secret key and logins for stuff, so >> you can mask those. the rest should be ok to make public. > Ok, here are the settings (mainly from mailman-suite): > > SESSION_SERIALIZER = 'django.contrib.sessions.serializers.PickleSerializer' > LOGIN_URL = 'account_login' > LOGIN_REDIRECT_URL = '' > LOGOUT_URL = 'account_logout' I guess that's the issue. Try using something else for LOGIN_REDIRECT_URL It should either be a valid path so "/postorius/" for instance or a valid view name like "list_index"

8 years, 7 months

Re: How to subscribe members without sending unsubscribe message

by Mark Sapiro

On 9/15/25 14:11, Flo via Mailman-users wrote: > Hi, > > I need to remove subscribed members without sending them an > unsubscription message. Despite of my research I haven't figured out how > to do this using the GUI. With Postorius, you can do it by first setting the list's Automatic Responses -> Send goodbye message to No, and then doing the unsubscribe. From the command line, you can use the `mailman delmembers` command which has options to control the sending of the admin notice and the goodbye message. -- Mark Sapiro <mark(a)msapiro.net> The highway is for gamblers, San Francisco Bay Area, California better use your sense - B. Dylan

1 year

Re: Subscription requires confirmation when list is set as Open

by Joachim Schrod

Mark writes: > > > On 2024-12-19 02:22, Joachim Schrod wrote: > > > Is there a > > configuration option for a mailing list that sets "Pre Verified" to > > true as a default? > > Hi, > > Editing the list_forms.py file will set the "Pre Verified" checkbox > default to "checked" ... > > /opt/mailman/venv/lib/python3.11/site-packages/postorius/forms/list_forms.py > > ... changing initial=False to initial=True - onLine 1267 > > > pre_verified = forms.BooleanField( > label=_('Pre Verified'), > initial=True, > ... > > And then restart of mailman3 and mailmanweb after editing. Works like a charm, thanks a lot! Happy holidays, Joachim

1 year, 9 months

Re: Run 'manage.py makemigrations' to make new migrations

by Abhilash Raj

On Wed, Jun 29, 2022, at 2:21 AM, christopher.claus(a)tgcamberg1848.de wrote: > Hello together, > > at startup of my docker-container with mailman 0.4.3 i got some > warnings to apply some data-model-migrations. I´m very unfamilar with > python and django and be not sure how to handle it. Are these warnings > from mailman and should i migrate the data-model (and how)? Or should > i ignore these message for keeping mailman in a safe state? This might have something to do with the newer Django versions being pulled in during the build. Given that they are warnings, I don't think they will affect data. But regardless, can you open an issue on Github to track this? We want to make sure that either we downgrade Django or make sure affected components are updated to properly support new versions of Django. I can take a look a bit later to see what's this new W402 check that was added. > > Best regards, > chrclaus > > > System check identified some issues: > > WARNINGS: > django_mailman3.MailDomain: (models.W042) Auto-created primary key > used when not defining a primary key type, by default > 'django.db.models.AutoField'. > HINT: Configure the DEFAULT_AUTO_FIELD setting or the > DjangoMailman3Config.default_auto_field attribute to point to a > subclass of AutoField, e.g. 'django.db.models.BigAutoField'. > django_mailman3.Profile: (models.W042) Auto-created primary key used > when not defining a primary key type, by default > 'django.db.models.AutoField'. > HINT: Configure the DEFAULT_AUTO_FIELD setting or the > DjangoMailman3Config.default_auto_field attribute to point to a > subclass of AutoField, e.g. 'django.db.models.BigAutoField'. > hyperkitty.Attachment: (models.W042) Auto-created primary key used > when not defining a primary key type, by default > 'django.db.models.AutoField'. > HINT: Configure the DEFAULT_AUTO_FIELD setting or the > HyperKittyConfig.default_auto_field attribute to point to a subclass of > AutoField, e.g. 'django.db.models.BigAutoField'. > hyperkitty.Email: (models.W042) Auto-created primary key used when not > defining a primary key type, by default 'django.db.models.AutoField'. > HINT: Configure the DEFAULT_AUTO_FIELD setting or the > HyperKittyConfig.default_auto_field attribute to point to a subclass of > AutoField, e.g. 'django.db.models.BigAutoField'. > hyperkitty.Favorite: (models.W042) Auto-created primary key used when > not defining a primary key type, by default > 'django.db.models.AutoField'. > HINT: Configure the DEFAULT_AUTO_FIELD setting or the > HyperKittyConfig.default_auto_field attribute to point to a subclass of > AutoField, e.g. 'django.db.models.BigAutoField'. > hyperkitty.LastView: (models.W042) Auto-created primary key used when > not defining a primary key type, by default > 'django.db.models.AutoField'. > HINT: Configure the DEFAULT_AUTO_FIELD setting or the > HyperKittyConfig.default_auto_field attribute to point to a subclass of > AutoField, e.g. 'django.db.models.BigAutoField'. > hyperkitty.MailingList: (models.W042) Auto-created primary key used > when not defining a primary key type, by default > 'django.db.models.AutoField'. > HINT: Configure the DEFAULT_AUTO_FIELD setting or the > HyperKittyConfig.default_auto_field attribute to point to a subclass of > AutoField, e.g. 'django.db.models.BigAutoField'. > hyperkitty.Profile: (models.W042) Auto-created primary key used when > not defining a primary key type, by default > 'django.db.models.AutoField'. > HINT: Configure the DEFAULT_AUTO_FIELD setting or the > HyperKittyConfig.default_auto_field attribute to point to a subclass of > AutoField, e.g. 'django.db.models.BigAutoField'. > hyperkitty.Tag: (models.W042) Auto-created primary key used when not > defining a primary key type, by default 'django.db.models.AutoField'. > HINT: Configure the DEFAULT_AUTO_FIELD setting or the > HyperKittyConfig.default_auto_field attribute to point to a subclass of > AutoField, e.g. 'django.db.models.BigAutoField'. > hyperkitty.Tagging: (models.W042) Auto-created primary key used when > not defining a primary key type, by default > 'django.db.models.AutoField'. > HINT: Configure the DEFAULT_AUTO_FIELD setting or the > HyperKittyConfig.default_auto_field attribute to point to a subclass of > AutoField, e.g. 'django.db.models.BigAutoField'. > hyperkitty.Thread: (models.W042) Auto-created primary key used when > not defining a primary key type, by default > 'django.db.models.AutoField'. > HINT: Configure the DEFAULT_AUTO_FIELD setting or the > HyperKittyConfig.default_auto_field attribute to point to a subclass of > AutoField, e.g. 'django.db.models.BigAutoField'. > hyperkitty.ThreadCategory: (models.W042) Auto-created primary key used > when not defining a primary key type, by default > 'django.db.models.AutoField'. > HINT: Configure the DEFAULT_AUTO_FIELD setting or the > HyperKittyConfig.default_auto_field attribute to point to a subclass of > AutoField, e.g. 'django.db.models.BigAutoField'. > hyperkitty.Vote: (models.W042) Auto-created primary key used when not > defining a primary key type, by default 'django.db.models.AutoField'. > HINT: Configure the DEFAULT_AUTO_FIELD setting or the > HyperKittyConfig.default_auto_field attribute to point to a subclass of > AutoField, e.g. 'django.db.models.BigAutoField'. > postorius.EmailTemplate: (models.W042) Auto-created primary key used > when not defining a primary key type, by default > 'django.db.models.AutoField'. > HINT: Configure the DEFAULT_AUTO_FIELD setting or the > PostoriusConfig.default_auto_field attribute to point to a subclass of > AutoField, e.g. 'django.db.models.BigAutoField'. > Operations to perform: > Apply all migrations: account, admin, auth, contenttypes, > django_mailman3, django_q, hyperkitty, postorius, sessions, sites, > socialaccount > Running migrations: > No migrations to apply. > Your models in app(s): 'postorius' have changes that are not yet > reflected in a migration, and so won't be applied. > Run 'manage.py makemigrations' to make new migrations, and then > re-run 'manage.py migrate' to apply them. > _______________________________________________ > 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/ -- thanks, Abhilash Raj (maxking)

4 years, 2 months

Re: Mailman core: basic internationalization howto?

by Mark Sapiro

On 10/06/2017 07:34 AM, thor.rustad(a)gmail.com wrote: > I made it work, sort of, after creating the directory structure templates/site/no and put the templates inside the 'no' folder. However, I can't make it work without setting the language manually for each list first. New lists are created with English as their language, breaking the creation of welcome mail. Also, I can not add members to the lists from Postorius. I want all new lists to use utf-8 without having to use mailman shell. How can it be done? Put [mailman] default_language: no in your mailman config. -- Mark Sapiro <mark(a)msapiro.net> The highway is for gamblers, San Francisco Bay Area, California better use your sense - B. Dylan

8 years, 11 months

Re: Disable user registration

by Mark Sapiro

On 3/20/21 6:22 AM, Stephen J. Turnbull wrote: > > 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 think you mean "^.*$", but that won't work as being banned means you can't be added to the list by any means and you can't post. -- Mark Sapiro <mark(a)msapiro.net> The highway is for gamblers, San Francisco Bay Area, California better use your sense - B. Dylan

5 years, 6 months

Re: MM3 List Templates

by Odhiambo Washington

On Wed, Dec 21, 2022 at 1:50 PM Odhiambo Washington <odhiambo(a)gmail.com> wrote: > I am reading > https://wiki.list.org/DOC/Mailman%203%20installation%20experience > regarding templates and I am confused about > whether to treat the path /opt/mailman/mm/var/templates/*site*/en/ > literally or even if that information is still relevant. > I created the exact path and put those templates in there, but they do not > show up on Postorius. > Responding to myself and apologizing for the noise. I have read https://lists.mailman3.org/archives/list/mailman-users@mailman3.org/message… as regards templates. There is still a lot to learn about MM3. -- Best regards, Odhiambo WASHINGTON, Nairobi,KE +254 7 3200 0004/+254 7 2274 3223 "Oh, the cruft.", egrep -v '^$|^.*#' ¯\_(ツ)_/¯ :-)

3 years, 9 months

Mailman-users search results for query "Postorius"