Search results for "Postorius" - Mailman-users

Re: 404 on fresh install (Debian11)

by Jeremy Stanley

On 2023-03-23 09:07:02 -0700 (-0700), Mark Sapiro wrote: [...] > bookworm (testing) and sid (unstable) do have current versions of > Mailman core and django-mailman3 and possibly mailman3-web > 0+20200530-2.1 has current Postorius and HyperKitty, but those are > generally not the Debian packages that most users would install. And those will also become out of date over time, because Debian is a stable server distribution so intentionally freezes the versions of software it supplies and backports only critical/security fixes to those increasingly outdated versions when warranted. Basically it's a question of whether users value stability with a bit of security support over newest versions of software and new features. The upstream Mailman packages on PyPI (and container images) cater to users who want the latest versions of the software, packages in stable server distros like Debian cater to users who want to safely go years between behavior changes in software. Both are valid choices, it just comes down to the user's specific situation. That said, when you have trouble with the packaged versions of software in Debian, the expectation is that you ask on Debian mailing lists and possibly report bugs in the Debian bug tracker, rather than burdening upstream software maintainers with details that might be specific to choices or mistakes in Debian's packages. The package maintainers in Debian generally forward bug reports upstream if they determine the issue you've encountered isn't related to how it's been packaged, isn't already fixed upstream (in which case they might backport the fix), et cetera. -- Jeremy Stanley

2 years, 5 months

Re: Howto: Mass import of nonmembers in several lists?

by Mark Sapiro

On 1/10/22 4:00 AM, Paul Paulchen wrote: > > So without adding all nonmembers with postorius step by step 8x20 times, there is an easier way to do it. > I thought so, because the import21 command did this as well when we migrated to mailman3. You could script it with `mailman shell`. If you really want this, I'll help. > I read about the command "mailman addmembers" https://docs.mailman3.org/projects/mailman/en/latest/src/mailman/commands/d… > > I am guessing, that I need to create a file like in the example of the addmembers, adding all my nonmember users with their email addy. > But how can I add/ tell the command in this massimport that the new members are nonmembers in the existing lists?! You can't without modifying the code. > Hope I explained my case properly. I appreciate your responds! Thanks in advance. My question is why do you want to add these nonmembers. The only thing gained by adding a nonmember is the ability to set the nonmember's moderation action to other than the default, and you can handle that with the legacy * these non-members settings which take priority over the nonmember's moderation action anyway. Note that if a nonmember posts to a list, she will automatically be added to the list as a nonmember with default moderation action if she isn't one of the list's nonmembers already. -- 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: disabling social login

by Abhilash Raj

On Mon, Nov 6, 2017, at 10:26 AM, Simon Hanna wrote: > On 11/06/2017 07:22 PM, Dmitry Makovey wrote: > > Hi, I'm trying to disable social login and running into troubles > > stepping on it's remnants all over the place. What's the proper sequence > > for disabling social login in MM3 install? > comment out 'allauth.socialaccount' and all social providers in the > INSTALLED_APPS in your settings.py This apparently doesn't work, Hyperkitty apparently depends on this to do some stuff. I haven't dug up in there, but the migrations would break if we remove this from INSTALLED_APPS. Instead, please let the 'allauth.socialaccount' be there, along with 'allauth.account' and 'allauth' and everything else related to allauth should be removed. It looks something like this: ```` 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', 'paintstore', 'compressor', 'haystack', 'django_extensions', 'django_q', 'allauth', 'allauth.account', 'allauth.socialaccount', ) ``` I tested this works, see [1]. [1]: https://lists.araj.me/postorius/lists/ > They shouldn't be enabled by default in the first place I guess, since > pretty much all of them require further setup in order to work > properly... > > How are you running MM3? > _______________________________________________ > Mailman-users mailing list > mailman-users(a)mailman3.org > https://lists.mailman3.org/mailman3/lists/mailman-users.mailman3.org/ -- Abhilash Raj maxking(a)asynchronous.in

7 years, 10 months

Re: Mailman issues after re-boot

by Mark Sapiro

On 9/16/23 5:29 AM, Paul Rubin wrote: > *I need to know what to remove, how to correctly update, etc., That said > the two scripts appear to be very similar:* > > mail:/opt/mailman # head /usr/bin/mailman > > #!/usr/bin/python3 > # EASY-INSTALL-ENTRY-SCRIPT: 'mailman==3.3.4','console_scripts','mailman' > __requires__ = 'mailman==3.3.4' > import re > import sys > from pkg_resources import load_entry_point > > if __name__ == '__main__': > sys.argv[0] = re.sub(r'(-script\.pyw?|\.exe)?$', '', sys.argv[0]) > sys.exit( This is no good because it uses the system Python and won't have the venv's site-packages in its path. > mail:/opt/mailman # head /opt/mailman/venv/bin/mailman > #!/opt/mailman/venv/bin/python3 > # -*- coding: utf-8 -*- > import re > import sys > from mailman.bin.mailman import main > if __name__ == '__main__': > sys.argv[0] = re.sub(r'(-script\.pyw|\.exe)?$', '', sys.argv[0]) > sys.exit(main()) > mail:/opt/mailman # This one is good because it uses the venv python3 and thus uses site-packages from the venv. > *Given the two years since the last reboot I also tried following * > https://docs.mailman3.org/en/latest/upgrade-guide.html *to make sure I was > running the latest* > > pip install -U mailman postorius django-mailman3 hyperkitty mailman-web Thin may be part of the issue. The above may not upgrade dependencies as needed. You may need the `--upgrade-strategy eager` option. -- Mark Sapiro <mark(a)msapiro.net> The highway is for gamblers, San Francisco Bay Area, California better use your sense - B. Dylan

1 year, 11 months

Re: Django Internal Server Error on held_messages

by Andrew Hodgson

Hasan Berkay Çağır wrote: >We've been running a Mailman3 instance with Debian 10's official package: >For some reason, and only on some lists, when we try to see held messages on Postorius, we get an error message "An error occurred while processing your request." and the following error email: >""" >Internal Server Error: /postorius/lists/list.example.com/held_messages [...] >File "/usr/lib/python3/dist-packages/mailmanclient/restobjects/mailinglist.py" in get_held_page > 134. return Page(self._connection, url, HeldMessage, count, page) >File "/usr/lib/python3/dist-packages/mailmanclient/restbase/page.py" in __init__ > 37. self._create_page() >File "/usr/lib/python3/dist-packages/mailmanclient/restbase/page.py" in _create_page > 62. response, content = self._connection.call(self._build_url()) >File "/usr/lib/python3/dist-packages/mailmanclient/restbase/connection.py" in call > 99. raise HTTPError(url, response.status, content, response, None) Have you checked the various Mailman logs from Mailman Core? I had something similar to this and it was because the message files relating to the particular held message had been deleted from the file system but were still referenced in the database when I moved to a new server a while back. In my case I fixed the problem by copying a valid held message file to the location where the referenced message should be and was able to delete it via the web interface. This is a hacky workaround but was sufficient to get me through my mistake. This may not be the case of course but you should find more info in the Mailman logs itself on the server, not sure where those are by default on the Debian package. Thanks. Andrew.

3 years, 5 months

Re: I did something stupid. Can i back out of it?

by Mark Sapiro

On 2/19/22 08:33, William Oliver wrote: > > So... I run a small mailinglist using mailman3 that has been workiing > great for a couple of months. Last week, all my users from gmail got > kicked off because gmail decided that the list messages were > "unsolicited email". I didn't find out about it until the users hit > their mailman3 bounce limit. I *thought* would be seeing all the > bounce messages, but apparently not. I didn't see any config settings > for "see all the bounce messages" so i thought to myself, "Self, well > maybe that's because my mailinglist username doesn't have a mailbox in > /home/listname". Assuming your Mailman core version is 3.3.5 and Postorius is 1.3.6, you will see settings like `Notify owner on bounce increment`, ` Notify owner on disable` and `Notify owner on removal` under `Bounce Processing`. Presumable you did get the notification of removal, so delivery to the owner works. Are the increment and disable (or maybe just disable if your versions are older) notices set to Yes? > So, I decided to try that. I created /home/listname/Maildir/* and > logged in as fplist to see if it would put mail there. In order to log > in as listname, I gave the user listname a password. Can't you just reverse those steps. I.e. remove /home/listname/ and remove the listname user? -- Mark Sapiro <mark(a)msapiro.net> The highway is for gamblers, San Francisco Bay Area, California better use your sense - B. Dylan

3 years, 6 months

ANNOUNCE: Mailman 3.1.0 final!

by Barry Warsaw

Hello Mailpeople! On behalf of the entire team and all our wonderful contributors, I'm happy to announce the release of GNU Mailman 3.1 final. My deep thanks go to all the Mailman project sprinters at Pycon 2017 for getting us over the line! Two years after the original release of Mailman 3.0, this version contains a huge number of improvements across the entire stack. Many bugs have been fixed and new features added in the Core, Postorius (web u/i), and HyperKitty (archiver). Upgrading from Mailman 2.1 should be better too. We are seeing more production sites adopt Mailman 3, and we've been getting great feedback as these have rolled out. Important: mailman-bundler, our previous recommended way of deploying Mailman 3, has been deprecated. Abhilash Raj is putting the finishing touches on Docker images to deploy everything, and he'll have a further announcement in a week or two. Feedback is welcome: https://github.com/maxking/docker-mailman What is GNU Mailman? GNU Mailman is free software for managing electronic mail discussion and e-newsletter lists. Mailman is integrated with the web, making it easy for users to manage their accounts and for list owners to administer their lists. Mailman supports built-in archiving, automatic bounce processing, content filtering, digest delivery, and more. Mailman 3 is released under the terms of the GNU General Public License, version 3. The best places to start for all things related to this release: http://docs.mailman3.org/ http://www.list.org/ https://gitlab.com/mailman (Note: due to timezone skew, some of the tarballs may not be available on PyPI until tomorrow.) Happy Mailman Day, -Your friendly neighborhood cabal An overview of what's new in Mailman 3.1 ======================================== Feature parity with Mailman 2.1 ------------------------------- * You should be able to do just about everything that you could do in Mailman 2.1 *except* for topics and sibling/umbrella lists. Core ---- * Added support for Python 3.5 and 3.6 * MySQL is now an officially supported database * Many improvements with importing Mailman 2.1 lists * DMARC mitigations have been added, based on, but different than the same feature in Mailman 2.1 * The REST API requires HTTP/1.1 * A new REST API version (3.1) has been added which changes how UUIDs are interpreted, fixing the problem for some JavaScript libraries * Many new REST resources and methods have been added * Individual mailing lists can augment the system's header matching rules * `mailman create` now creates missing domains by default * `mailman digests` now has `--verbose` and `--dry-run` options * `mailman shell` now supports readline history * `mailman members` can filter members based on their subscription roles * A new template system has been added for all messages originating from inside Mailman. * The Message-ID-Hash header replaces X-Message-ID-Hash * New placeholders have been added for headers and footers * Unsubscriptions can now be confirmed and/or moderated Postorius/HyperKitty -------------------- * General U/I and U/X improvements * Many more features from the Core's have been plumbed through * We've adopted Django social auth logins and dropped Persona (since it's no longer supported upstream). You can now log in via Facebook, Google, GitHub, and GitLab. Backward incompatibilities -------------------------- * Core/REST: Held message resources now have an `original_subject` key that is not RFC 2047 decoded. `subject` is now RFC 2047 decoded. * Core/REST: If you've run pre-release versions from git head, and stored welcome and goodbye templates via REST, the template key names have changed backward incompatibility.

8 years, 3 months

Re: Error Logging - what changed with the New Year releases?

by Odhiambo Washington

On Sat, Jan 14, 2023 at 11:57 PM Mark Sapiro <mark(a)msapiro.net> wrote: > On 1/14/23 11:44, Odhiambo Washington wrote: > > On Sat, Jan 14, 2023 at 7:13 PM Mark Sapiro <mark(a)msapiro.net> wrote: > > > >> Nothing in those releases per se would affect this. This is Django and > >> django-allauth. Perhaps when you updated the Mailman packages, you also > >> updated these dependencies. > >> > > > > Which dependencies would those be? > > Django and django-allauth. > (venv) [mailman@gw ~/mm]$ pip freeze | grep jango Django==4.1.5 django-allauth==0.52.0 django-appconf==1.0.5 django-compressor==4.1 django-extensions==3.2.1 django-gravatar2==1.4.4 django-haystack==3.2.1 django-mailman3==1.3.9 django-picklefield==3.1 django-q==1.3.9 djangorestframework==3.14.0 > > > > When I upgraded, the command I ran was: > > > > pip install --upgrade --force mailman mailmanclient postorius hyperkitty > > mailman-hyperkitty django-mailman3 > > > Do you mean --force-reinstall? pip has no --force option. I *think* > --force-reinstall will upgrade dependencies. Depending on your pip > version, --upgrade alone may or may not upgrade dependences. Older > versions of pip will, but newer versions, at least without > --force-upgrade require --upgrade-strategy eager to update dependencies. > I have used --force-reinstall. > > And how do I find out what is suppressing the logging for the social > > accounts? > > That's a django-allauth question. > Let me go RTFM again :-) -- Best regards, Odhiambo WASHINGTON, Nairobi,KE +254 7 3200 0004/+254 7 2274 3223 "Oh, the cruft.", egrep -v '^$|^.*#' ¯\_(ツ)_/¯ :-)

2 years, 7 months

Re: Finding a user to delete them

by Quanah Gibson-Mount

--On Saturday, March 14, 2020 7:03 PM +0900 "Stephen J. Turnbull" <turnbull.stephen.fw(a)u.tsukuba.ac.jp> wrote: > For alternatives to Postorius and the Mailman shell, Brian Carpenter > (follow Allan's subthread) is working on a new management UI (using > PHP), and I believe there's a working node.js API "out there > somewhere". Please be very considerate of Brian's time; he and EMWD > constitute a bulwark of the Mailman ecosystem and will be even busier > with the UI project. But do pass on your suggestions to him as well > as to us, he's indicated he's open to that. Thanks Steve, Generally I just found the mailman shell examples in the documentation lacking, as: * it used functions not available without loading additional modules not listed in the documentation * the steps to find accounts is lacking, since they don't work for email addresses that are not yet verified * I could find no documentation on what fields are available in the user object, so I was unable to find the account via other methods, including the actual username created by mailman3 (which seems odd, wouldn't this be a standard way to find users..?) The Django UI is the only thing that let me find the miscreated user and delete it. Hopefully the bug I filed about github user integration being badly broken will receive some priority, given the bug causes new accounts to incorrectly be created for existing users. --Quanah -- Quanah Gibson-Mount Product Architect Symas Corporation Packaged, certified, and supported LDAP solutions powered by OpenLDAP: <http://www.symas.com>

5 years, 5 months

Programmatic Creation of Users

by jciesla＠techsupportme.com

I am returning to Mailman after being away for a LONG time and I need to create 40 lists with ~350 subscribers spread across those lists. After a lot of testing I am now able to create users from the Core Shell and set (most of) the necessary values. Having jumped that hurdle I have hit a roadblock and I am hoping that the list can provide some insight and/or solutions. After a lot of research I now understand that what I am doing in the Core Shell is creating a User entity which has one or more email addresses as well as one or more roles and preferences that exist at the global level. This user entity can Subscribe to zero or more lists. If I am incorrect in the summation please let me know! Assuming that the previous information is correct that brings us to my current dilemma. Specifically, the User entity can Subscribe and interact with lists using the email commands, but they can't Login using the Postorius web interface. If I understand correctly the reason that they can't login is that the underlying Django system does not recognize their account because the account that was created in Core isn't accessible by Django. Instead the user needs to create a Django-specific account at which point the information from Core becomes available in the user's web UI. If that is in fact accurate then I want to take the next logical leap: is it possible to programmatically create an account in Django that is tied to the account that was created in Core? Any information is greatly appreciated! -John

3 years, 1 month

Mailman-users search results for query "Postorius"