Search results for "Postorius" - Mailman-users

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, 7 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, 8 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, 5 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, 9 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, 7 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, 3 months

Re: Apache+mod_wsgi issue

by Odhiambo Washington

On Sat, Dec 24, 2022 at 1:51 AM Mark Sapiro <mark(a)msapiro.net> wrote: > On 12/22/22 22:26, Odhiambo Washington wrote: > > On Fri, Dec 23, 2022 at 9:21 AM Odhiambo Washington <odhiambo(a)gmail.com> > > wrote: > > > >> And now I am having a problem with mod_wsgi. > >> First, the URL displayed when I load the page looks bogus to me. > >> While I expect the URL to be > >> https://mm3-lists.kictanet.or.ke/mailman3/domains/, mod_wsgi give me > >> https://mm3-lists.kictanet.or.ke/mailman3/mailman3/domains/ - there is > an > >> extra /mailman3! > > > See below: > > > >> So I have; > >> 1. https://mm3-lists.kictanet.or.ke/mailman3/mailman3/lists/ - > working, > >> or appears to. > >> 2. https://mm3-lists.kictanet.or.ke/mailman3/mailman3/domains/ - > working, > >> or appears to. > >> 3. https://mm3-lists.kictanet.or.ke/mailman3/mailman3/bans/ - working, > or > >> appears to > >> 4. https://mm3-lists.kictanet.or.ke/mailman3/mailman3/users - working, > or > >> appears to > >> 5. > >> > https://mm3-lists.kictanet.or.ke/mailman3/mailman3/lists/kictanet.lists.kic… > >> - This throws an exception error when I click "Manage Subscription". > >> > >> -> https://pastebin.ubuntu.com/p/RkKH793Jgw/ > > > messages like these > > [Fri Dec 23 09:10:55.393386 2022] [wsgi:error] [pid 74857] [remote > 197.232.81.246:14181] File > "/opt/mailman/mm/venv/lib/python3.9/site-packages/mailmanclient/restbase/connection.py", > > line 160, in call > [Fri Dec 23 09:10:55.393390 2022] [wsgi:error] [pid 74857] [remote > 197.232.81.246:14181] raise HTTPError(params.get('url'), > response.status_code, > [Fri Dec 23 09:10:55.393394 2022] [wsgi:error] [pid 74857] [remote > 197.232.81.246:14181] urllib.error.HTTPError: HTTP Error 500: {"title": > "500 Internal Server Error"} > > Indicate an uncaught exception in Mailman core. What's in mailman.log? > A good catch here! mailman.log was mostly having a complaint about a missing config file - /etc/mailman3/mailman-hyperkitty.cfg I then just did a symlink: ln -s /opt/mailman/mm /etc/mailman3, which then made things start working. And I don't like this, so I think I will put all my configs into /opt/mailman/mm/etc/ and link /etc/mailman3 to this path instead. What bite me is probably related to this experience by Turnbull: https://lists.mailman3.org/archives/list/mailman-users@mailman3.org/message… I am on FreeBSD where user applications should have config files in /usr/local/etc/ and not /etc/ so having /etc/mailman3 and not /usr/local/etc/mailman3 kinda makes me feel weird. >> And while I do not quite understand the error itself, there is also one > >> particular line that I also saw that has left me baffled: > >> [Fri Dec 23 08:53:18.290411 2022] [core:info] [pid 91236] [client > >> 197.232.81.246:13865] AH00128: File does not exist: > >> /usr/local/www/apache24/data/archives/list/ > >> kictanet(a)lists.kictanet.or.ke/thread/VIHCC6MSXZSNHY7YPEJ3D2US4N7MHJEC/, > >> referer: > >> > https://mm3-lists.kictanet.or.ke/archives/list/kictanet@lists.kictanet.or.ke > > This is because something is doing an HTTP GET for > `/archives/list/ > kictanet(a)lists.kictanet.or.ke/thread/VIHCC6MSXZSNHY7YPEJ3D2US4N7MHJEC/` > <http://kictanet@lists.kictanet.or.ke/thread/VIHCC6MSXZSNHY7YPEJ3D2US4N7MHJE…> > and the URL is not recognized as one handled by mod_wsgi so apache tries > to get it from its DocumentRoot. > > mod_wsgi has to serve a number of URLs. Look in /opt/mailman/mm/urls.py > for urlpatterns. You will probably see things like > > url(r'^accounts/', include('allauth.urls')), > # Django admin > url(r'^admin/', admin.site.urls), > url(r'^mailman3/', include('postorius.urls')), > url(r'^archives/', include('hyperkitty.urls')), > > Those are all things that need to be handled by mod_wsgi > > In your apache config, you only have a WSGIScriptAlias for /mailman3. > Thus paths need to be prefixed with /mailman3 in order to be handled by > mod_wsgi. I'm not sure what is doing this prefixing, but without it > paths that don't begin with /mailman3 don't work unless you also have > things like > > WSGIScriptAlias /accounts /opt/mailman/mm/wsgi.py > WSGIScriptAlias /admin /opt/mailman/mm/wsgi.py > WSGIScriptAlias /archives /opt/mailman/mm/wsgi.py > > in your apache config. > These are my files: 1. urls.py <CUT > from django.conf.urls import include from django.urls import re_path from django.contrib import admin from django.urls import reverse_lazy from django.views.generic import RedirectView urlpatterns = [ re_path(r'^$', RedirectView.as_view( url=reverse_lazy('list_index'), permanent=True)), re_path(r'^postorius/', include('postorius.urls')), re_path(r'^hyperkitty/', include('hyperkitty.urls')), re_path(r'', include('django_mailman3.urls')), re_path(r'^accounts/', include('allauth.urls')), # Django admin re_path(r'^admin/', admin.site.urls), re_path(r'^mailman3/', include('postorius.urls')), re_path(r'^archives/', include('hyperkitty.urls')), ] </CUT> 2. apache.conf <CUT> ... Alias /static "/opt/mailman/mm/static" <Directory "/opt/mailman/mm/static"> Require all granted </Directory> # WSGIScriptAlias /mailman3 /opt/mailman/mm/wsgi.py # WSGIScriptAlias /accounts /opt/mailman/mm/wsgi.py # WSGIScriptAlias /admin /opt/mailman/mm/wsgi.py # WSGIScriptAlias /archives /opt/mailman/mm/wsgi.py # WSGIScriptAlias /user-profile /opt/mailman/mm/wsgi.py # WSGIScriptAlias /hyperkitty /opt/mailman/mm/wsgi.py # WSGIScriptAlias /postorius /opt/mailman/mm/wsgi.py WSGIScriptAlias / /opt/mailman/mm/wsgi.py <Directory "/opt/mailman/mm/"> <Files wsgi.py> Order deny,allow Allow from all Require all granted </Files> WSGIProcessGroup mailman-web </Directory> <CUT> > > I also need to add the fact that at the point where I am clicking "Manage > > Subscription", the URL has changed to > > > https://mm3-lists.kictanet.or.ke/mailman3/archives/list/kictanet@lists.kict… > > (just a single /mailman3). > > > > > Something is adding mailman3/ to URLs. In the above the URL should be > > https://mm3-lists.kictanet.or.ke/archives/list/kictanet@lists.kictanet.or.k…, > > but an extra /mailman3 is added. The others are like > https://mm3-lists.kictanet.or.ke/mailman3/lists/ and an extra /mailman3 > is added. > I have tested with creating all those commented out aliases and that ended up still giving me /mailman3/mailman3/* which I did not like, although everything appeared to work. I then ended up with only "WSGIScriptAlias / /opt/mailman/mm/wsgi.py" and now when I type https://mm3-lists.kictanet.or.ke I end up at https://mm3-lists.kictanet.or.ke/mailman3/lists/. Of course something has appended "/mailman3" So this has resulted in all URLs having /mailman3/ appended, except for the /archives link. Now my question is about what could be adding the /mailman3. Is it possible that I installed something out of the ordinary? -- Best regards, Odhiambo WASHINGTON, Nairobi,KE +254 7 3200 0004/+254 7 2274 3223 "Oh, the cruft.", egrep -v '^$|^.*#' ¯\_(ツ)_/¯ :-)

2 years, 10 months

HyperKitty failure

by horvath.arpad.szfvar＠gmail.com

Hi, I try to connect mailman3 to hyperkitty, but there is no success so far. You can see the details below. How can I solve the problem? As I have several domain name (like lists.xxx.hu, xxx.hu, yyy.hu) on the same server, so I guess localhost won't work. In mailman-hyperkitty.cfg there is a line: base_url: http://lists.xxx.hu/hyperkitty/ /etc/mailman3/mailman-web.py includes "*" in ALLOWED_HOSTS I have an error message in /var/log/mailman3/mailman.log Dec 30 21:41:23 2021 (126976) HyperKitty failure on http://lists.xxx.hu/hyperkitty/api/mailman/archive: (405) Dec 30 21:41:23 2021 (126976) Exception in the HyperKitty archiver: Dec 30 21:41:23 2021 (126976) Traceback (most recent call last): File "/usr/lib/python3/dist-packages/mailman_hyperkitty/__init__.py", line 154, in _archive_message url = self._send_message(mlist, msg) File "/usr/lib/python3/dist-packages/mailman_hyperkitty/__init__.py", line 210, in _send_message raise ValueError(result.text) ValueError In /var/log/mailman3/web/mailman-web.log WARNING 2021-12-30 20:41:23,816 127032 django.request Method Not Allowed (GET): /hyperkitty/api/mailman/archive [pid: 127032|app: 0|req: 101/101] 109.230.236.204 () {38 vars in 592 bytes} [Thu Dec 30 20:41:23 2021] GET /hyperkitty/api/mailman/archive?key=lHzJB%2FzfSWUrbPKZ84JNSlLXHVyCDt8T => generated 0 bytes in 1 msecs (HTTP/1.1 405) 6 headers in 189 bytes (1 switches on core 0) WARNING 2021-12-30 20:41:23,854 127032 django.request Method Not Allowed (GET): /hyperkitty/api/mailman/archive On Debian 11, I have these packages ii mailman3 3.3.3-1 all Mailing list management system ii mailman3-full 3.3.3-1 all Full Mailman3 mailing list management suite (metapackage) ii mailman3-web 0+20200530-2 all Django project integrating Mailman3 Postorius and HyperKitty ii python3-django-mailman3 1.3.5-2 all Django library to help interaction with Mailman3 (Python 3 version) ii python3-mailman-hyperkitty 1.1.0-10 all Mailman3 plugin to archive emails with HyperKitty Thanks, Arpad

3 years, 10 months

Re: Can't subscribe on new site/domain

by Flo

On 10/9/25 19:19, Mark Sapiro wrote: > On 10/9/25 5:02 AM, Flo via Mailman-users wrote: >> Hi, >> >> I added a new site in Django: lists.example.com >> >> Usually I click on 'view site' and I can add a Domain in Postorios. In >> this case I get an error message and I need to add a Domain in Django. >> Then I can go to 'view site'. >> >> I can create a mailing list there. However when I send an email to be >> subscribed, I get the following in mailman.log (and nothing else >> happens): >> >> >> Oct 09 13:46:24 2025 (110452) deque: do_confirm_verify >> Traceback (most recent call last): > ... >> File "/usr/lib/python3/dist-packages/mailman/model/domain.py", line >> 177, in __getitem__ >> raise KeyError(mail_host) >> KeyError: 'lists.example.com' > > It appears you don't have a domain in Mailman core with mail_host = > 'lists.example.com'. > > Do you see one in Postorius' domains view? If not, perhaps you need to > add it. > I can see it in Postorius. I have created the a simialar site before and deleted the site and then again created this one. Maybe the database is messed up? I have deleted site - group - list now. And created the site again. If I go to 'view site' I see all mailing lists on the server and not only from this site/domain. This is the first thing where it shows irregularities. Flo

3 weeks, 2 days

Re: django fake users

by roberto

Hello, yes we talk about django users who are not subscribing to any list only to the django user managment. Automatically removing this users like described above with a cron job is a good idea, but i would more like to avoid this users. Obvious this users are created by a bot, would it not be helpfully to use any kind of captcha? Am 17.01.21 um 12:24 schrieb Andrew Hodgson: > Stephen J. Turnbull wrote: > >> r.woithe(a)callassoftware.com writes: >>> is there a opportunity to avoid django fake users? >>> Because of it is not stopping, further and further fake users are > subscribing. >> Require moderator approval for subscribing. > I don't think this would help the issue. What I am seeing here is users signing up through Postorius using the sign up option which then creates an account in Django (but not Mailman). Yesterday alone I had over 700 of these accounts created. I don't know whether they pass email confirmation or not (I don't see this in Django admin), however they don't get added as users in Mailman and they don't attempt to subscribe to any list. > >> It may be possible to do something automatic, but you need to explain how you know these users are "fake", and it has to be something that can easily be detected with a few lines of Python. If it becomes at all complex, it will almost surely make trouble for "real" subscribers. > I agree, this is why I am taking the route of running a regular Cron job to delete the users as explained earlier. > > Andrew.

4 years, 9 months

Mailman-users search results for query "Postorius"