Mailman 3 November 2014 - Mailman-Developers

mailman-bundler-3.0b2 Login methods
by Vijay Tico 10 Nov '14

10 Nov '14

Hi, I have installed mailman-bundler-3.0b2. On the Postorius login page, by default there is the Google, persona and Yahoo authentication. I only want basic native application authentication, which I can't see in this page. Tweaking the AUTHENTICATION_BACKENDS variable in development.py, I could disable the Google and Yahoo authentication and 'django.contrib.auth.backends.ModelBackend' seemingly corresponds to the persona authentication. AUTHENTICATION_BACKENDS = ( #'social_auth.backends.google.GoogleBackend', #'social_auth.backends.yahoo.YahooBackend', #'social_auth.backends.OpenIDBackend', 'django.contrib.auth.backends.ModelBackend', ) So the question does Postorius/Hyperkitty support basic authentication at all? How can I enable it? Cheers

5 9

mailman-bundler-3.0b1 error - Does it have an HTTPS login page?
by Vijay Tico 06 Nov '14

06 Nov '14

Hi, After installation of mailman-bundler-3.0b1 according to the instructions in README.rst and running the web interface, the web server runs and responds HTTP requests. The problem is that when I click the Login button on the top right of the page, I am redirected to this url: https://localhost:8000/archives/accounts/login The server naturally doesn't respond to this, as its an HTTPS request being sent to an HTTP server. I tried some hacks, but could not get it working (I don't know django at all). How can I solve this? Why has this happened? Bests

2 2

MM3 Sqlite to PostgreSQL migration?
by Guillaume Libersat 04 Nov '14

04 Nov '14

Hi, We are currently running a MM3 instance in "production" with a SQLite backend (at ulists.org). It was at first a test, but a lot of people have already started to use the service and now we are kind of stuck (but happy ;-) ). First, I've seen a lot of DBLock issues in the logs and I think there also is a race condition happening with Held Messages that leads to subsequents 500 until you manually copy fake email files (If I'm correct, the held message file is deleted, then the SQL query is made but fails. The result is a system in an inconsistent state: there's a held message in DB, but no more on disk). Second, I've tried to manually migrate to PostgreSQL but did not succeed because of a lot typing issues and differences between these two databases. Barry told me there's an SQLAlchemy port that is soon to be released, at least in alpha stage. Do you think it could help to achieve such a migration? I'm willing to help testing this new backend and, if someone can guide me with the MM stuff, write migration scripts. Thanks and again, MM3 is really an awesome suite of software! :) Guillaume

2 1

ORM layer transition
by Barry Warsaw 04 Nov '14

04 Nov '14

Hi Developers! In honor of the penultimate Mailman Day of 2014, I wanted to announce a significant transition in the implementation of Mailman 3 and call out the contributions of two of our members. For a long while now we've used Storm as the ORM layer in MM3. ORM, meaning "object relational mapper" is the chunk of code that translates between the persistent Python objects in a running MM3 system and the underlying SQL database. Storm was a good choice many years ago because it was a nice, simple, thin layer that was easy to understand, use, and customize. In the intervening years though, Storm has shown its age. It is no longer effectively maintained upstream, and it does not support Python 3. While MM3 is not yet a Python 3 application, it is my strong desire to eventually make it so. The fact that Storm has no Python 3 port, and is unlikely to, would prevent MM3 from being ported[*]. In a survey of the alternative available standalone Python ORMs, SQLAlchemy stands out as popular, well-maintained, long stable, and Python 3 compatible, and thus I am happy to announce that the MM3 trunk has been ported to SQLAlchemy (SA). The full test suite completes against both SQLite and PostgreSQL as back-ends, and I would expect that with a little bit of work (contributions welcome!) any other back-end supported by SA should work too. In addition, rather than the ball-of-hack I wrote to migrate the database schema from one version to another, we will now be using Alembic to manage schema migrations. I must acknowledge two really spectacular contributions from our members. Abhilash Raj began the SA port almost on a dare by me on IRC and with many discussions in various forums, produced the bulk of the port. He asked great questions, answered mine own with patience, showed good diligence, and the depth of knowledge about MM3 that such a port required. I have never met Abhilash in person but the quality of his work is impressive. Aurélien Bompard also provided invaluable contributions to this branch. Some of you may recognize Aurélien from his work on Hyperkitty, the fabulous new archiver. Aurélien was able to join us last year at the Pycon sprint, and it was really great to be able to hang out with him. He did an incredible amount of testing and refinement on the SA branch, feeding me patches that fixed a few of the outstanding test failures, especially on PostgreSQL. Without the contributions of both Abhilash and Aurélien, this port would not have happened. Kudos to them, and my personal appreciation for their patience and enthusiastic good spirits in working with their picky, curmudgeonly project leader, who took much too long to review and merge their work. :) I encourage the adventurous among you to grab the bzr trunk and give it a whirl. Do let us know here or in the bug tracker about any problems you might encounter, especially if you are upgrading from an existing Storm-based instance of MM3. At least one more release of the core is planned this year. Enjoy, -Barry [*] We have one other known Python 2-only dependency blocking our porting efforts. We use the restish library as our REST/HTTP framework, and while there are many things I love about restish, it falls into the same camp as Storm. It's Python 2-only, and effectively abandoned upstream. Fortunately we have a ready alternative in the Falcon framework. I have a branch of MM3 ported to Falcon ready to go as soon as upstream releases its new version, which will have a few changes I submitted that allows us to implement restish-style object-based traversal. This means we can port to Falcon, keep largely the same REST code in place, and be ready for Python 3.

3 4

Fwd: [sympa-users] thoughts re. DMARC impacts
by Victoriano Giralt 03 Nov '14

03 Nov '14

Folks, first my excuses for the "dual posting" but I did not want to loose the odd Mailman developer that is not subscribed to the users list. This has recently circulated in the sympa-users lists. As a proud member of both communities I think that the synergy Miles proposes could really have some impact. Actually, it would be great if the possible RFC had an author from each and every list manager in existence (there are not so many :)), or at least from the big ones, including the commercial dinosaur, ListServ (I'm connected to a big instance of this beast, so I might get a direct channel to them). All this said, please, take a look at Miles message ;-) -------- Original Message -------- Subject: [sympa-users] thoughts re. DMARC impacts Date: Mon, 27 Oct 2014 20:45:32 -0400 From: Miles Fidelman <mfidelman(a)meetinghouse.net> Reply-To: Miles Fidelman <mfidelman(a)meetinghouse.net> To: sympa-users(a)cru.fr <sympa-users(a)cru.fr>, dmarc(a)ietf.org <dmarc(a)ietf.org> Folks, Many of us just had to deal with the impacts of DMARC on our lists. In the aftermath, I've been participating on the dmarc-ietf email list - trying to discuss ways to "fix DMARC" to better coexist with lists and other 3rd-party services (like "send this article to...."). Unfortunately, it seems like the discussion is bogged down in two regards: - the ietf-dmarc working group is charted to "enhance DMARC" - dealing with its impacts is not really the focus - folks want a general purpose solution Personally, I'd like to see a short-term solution to make our lives easier, as list managers - sort of the way that NAT has been dealing with IPv4 address exhaustion, while we wait for IPv6 to happen. I've been thinking along the lines of an update to RFC2369 - the 16-year-old document defines the List-* headers. Say by adding a couple of headers along the lines of: List-Original-Author: <the original author> List-Original-Reply-To: <the original message's Reply-To> List-Reply-To: <the list-specific reply-to - either author of list> Seems to me that this would: 1. give us a standard way to find the original author (and for HTML mail, to reply by clicking on a mailto: URL in the header) 2. provide standardized information that could be used by MUAs for identifying, and presenting reply options (maybe leading to "reply to list" and "reply to author" buttons starting to show up on toolbars) 3. set the stage for adding some authentication mechanisms that accomplish what DMARC is intended to do (e.g. by adding a few more headers that cryptographically authenticate the new List- headers and bind them to the message body) It strikes me that this might proceed rather quickly, if incorporated into an RFC co-authored and submitted by folks from the mailing list software community (i.e., the folks who'd write the patches to Sympa, Mailman, ezmlm, etc) - particularly if some running code were to be implemented as part of the process. (Can you say, "rough consensus and running code?") Reactions? Anybody want to collaborate on a draft RFC for submission through the independent submissions path? Any thoughts on who needs to be involved from the Sympa community, and/or from the other mailing list software communities? Miles Fidelman (a frustrated sympa administrator) -- In theory, there is no difference between theory and practice. In practice, there is. .... Yogi Berra -- Victoriano Giralt Central ICT Services Systems Manager University of Malaga +34952131415 SPAIN ================================================================== Note: signature.asc is the electronic signature of present message A: Yes. > Q: Are you sure ? >> A: Because it reverses the logical flow of conversation. >>> Q: Why is top posting annoying in email ?

2 1