Mailman 3 April 2016 - Mailman-Developers

before next release: disable backscatter in default installation
by Jo Rhett 07 Nov '22

07 Nov '22

Hi. There's a fairly simple problem here that needs to be addressed. And it's mostly a documentation/install problem. I'm hoping we can get this resolved before the next release. PROBLEM: Mailman comes out of the box ready to backscatter spam people. Yes, it's easy enough to fix. But because it comes stock this way, and is documented to install this way, most people install it to do this. Those of us who work in abuse departments are tired of hearing "well that's how Mailman works". We also object to having to teach people how to fix their mailman installations because it's not documented in the current manual. This is *exactly* like Sendmail 14 years ago. We didn't accept it then, and Sendmail fixed the problem. RESOLUTION: Mailman default installation should not backscatter in a default configuration. 1. Don't create backscatter aliases for subscribe/unsubscribe/etc by default. Nearly everyone uses web based signup. 2. Discard or hold messages from non-subscribers by default. I would think that it would be perfectly reasonable to have documentation on how to enable the 1980s-style -request / -subscribe etc aliases. However this documentation should have a note that this is against the AUP of nearly every network provider, and enabling it will likely cause them to get listed in various blacklists as a backscatter source. FYI: I know that this goes against the instincts of many old-time mailing list advocates here. But after dealing with a 10k/hour backscatter DoS my tolerance for this problem is understandably limited. Yes, it was a sweet day back in the 1980s. I was running a mailing list server and several UUCP gateways at the time, so I remember them well. But those days are past, and we need to deal with the reality of today. -- Jo Rhett Net Consonance : consonant endings by net philanthropy, open source and other randomness

21 168

Translation
by Simon Hanna 11 Jan '17

11 Jan '17

Hi, I just completed setting up the Mailman 3 projects on zanata.org They can be found here: https://translate.zanata.org/project/view/mailman https://translate.zanata.org/project/view/postorius https://translate.zanata.org/project/view/hyperkitty I'm hesitating to ask people to translate because zanata is really slow and I'm afraid of scaring people away from translating mailman in the future :D Anyhow, I'm writing to ask for your opinions. What do you think about zanata? Maybe you can try translating a couple of things and report how you feel about it. I stumbled across a few other open source solutions: https://translatewiki.net http://pootle.locamotion.org/ https://demo.weblate.org/ This mediagoblin issue discussed some alternatives when they switched away from transifex. https://issues.mediagoblin.org/ticket/913 There seems to be a pootle server run by gnu itself. https://chapters.gnu.org/pootle/ What do you think? Simon

4 9

Mailman 2.1.22 release
by Mark Sapiro 17 Apr '16

17 Apr '16

I am pleased to announce the release of Mailman 2.1.22. Python 2.4 is the minimum supported, but Python 2.7 is strongly recommended. There are no new features in this release. There are a few i18n updates and some bug fixes. See the attached README for details. Mailman is free software for managing email mailing lists and e-newsletters. Mailman is used for all the python.org and SourceForge.net mailing lists, as well as at hundreds of other sites. For more information, please see our web site at one of: http://www.list.org http://www.gnu.org/software/mailman http://mailman.sourceforge.net/ http://mirror.list.org/ Mailman 2.1.22 can be downloaded from https://launchpad.net/mailman/2.1/ http://ftp.gnu.org/gnu/mailman/ https://sourceforge.net/projects/mailman/ -- Mark Sapiro <mark(a)msapiro.net> The highway is for gamblers, San Francisco Bay Area, California better use your sense - B. Dylan

1 0

Re: [Mailman-Developers] Postorius and verified email addresses
by Simon Hanna 11 Apr '16

11 Apr '16

>In that case, how should this address be validated? Should Postorius >consider that the login system always validates addresses and set them >as >verified in Mailman? Should it ask mailman to verify the email >addresses >when it encounters a user's un-verified address? This does not seem >possible in REST at the moment (unless I missed it), and should be >protected against multiple checks. > >Ideas? I started a thread about this a couple of months back. I was asking about what authentication system to switch to, since persona is being dropped. I found a couple of solutions and have my personal favorite: django-allauth I have a merge request pending that adds basic functionality for it in postorius. I think that it's better than python-social-auth that hyperkitty is currently using. Short version: it supports both external (social) and internal (django) auth systems and offers options to combine/switch between them . Allauth provides Signals that I used to verify the addresses in Mailman. The link to my merge request: https://gitlab.com/mailman/postorius/merge_requests/130 The link to my previous post: https://mail.python.org/pipermail/mailman-developers/2016-January/025338.ht… -- Sent from my Android device with K-9 Mail. Please excuse my brevity.

3 5

Re: [Mailman-Developers] Postorius and verified email addresses
by Barry Warsaw 06 Apr '16

06 Apr '16

On Apr 06, 2016, at 06:08 PM, Aurelien Bompard wrote: >In that case, how should this address be validated? Should Postorius >consider that the login system always validates addresses and set them as >verified in Mailman? Should it ask mailman to verify the email addresses >when it encounters a user's un-verified address? This does not seem >possible in REST at the moment (unless I missed it), and should be >protected against multiple checks. This is why POST on members (i.e. create a subscription) has a pre_verified flag, which defaults to False. The core already has a subscription workflow to send the address a confirmation email if the subscribing address is not already verified, and pre_verified is False. (It will send a similar confirmation email if pre_confirmed is False and the mailing list is set to confirm or confirm_then_moderate.) By default, confirmation can only effectively happen by email reply, but the intent is that you could modify the confirm.txt template[1] to include the appropriate link back into Postorius which would effect the same verification step as a mail-back. This link would POST to <api>/addresses/<email>/verify to verify the user's email address. Thinking about it the terms you describe above, I guess there's another workflow that isn't directly covered. When Postorius creates the user, an address is also created and linked to the user, but it cannot be set as the preferred address until it's verified. I can see where you might want to send the verification email at some point before a subscription event, so that the linked address gets verified and thus could be set as their preferred address. If that's a use case you think we need, do file a bug. I don't think it would be too difficult to implement. Cheers, -Barry [1] Or w.r.t. GL issue #112, set a 'confirm.txt' template URL.

1 0

Postorius and verified email addresses
by Aurelien Bompard 06 Apr '16

06 Apr '16

Hey people, Mailman has the notion of "verified" email addresses. When a user is created / registered in Postorius, a Mailman user can be created. It's off by default but it seems like a logical thing to do. This user will be created when the client visits the user profile or preferences pages anyway, because it needs it in Mailman at that point. However, the address that the user is created with is not verified. It's a good thing because Django, by itself, does not verify email addresses. The social auth providers that we use do validate them, but not Django, and when internal auth is involved then it's only Django. In that case, how should this address be validated? Should Postorius consider that the login system always validates addresses and set them as verified in Mailman? Should it ask mailman to verify the email addresses when it encounters a user's un-verified address? This does not seem possible in REST at the moment (unless I missed it), and should be protected against multiple checks. Ideas? Aurélien

1 0

New Mailman 3 users list
by Mark Sapiro 05 Apr '16

05 Apr '16

I'm happy to announce a new list for Mailman 3 users and others interested in Mailman 3. This list is running on a new Mailman 3 installation at lists.mailman3.org. The list's posting address is <mailman-users(a)mailman3.org>. The list's info page is <https://lists.mailman3.org/mailman3/lists/mailman-users.mailman3.org/> and its archives are at <https://lists.mailman3.org/archives/list/mailman-users@mailman3.org/>. The top level Postorius page is <https://lists.mailman3.org/mailman3/> and the HyperKitty archiver is at <https://lists.mailman3.org/archives/>. You can subscribe by email by sending a blank message to <mailman-users-join(a)mailman3.org> and responding to the resulting confirmation request. You can also subscribe by going to the info page at <https://lists.mailman3.org/mailman3/lists/mailman-users.mailman3.org/>, logging in and subscribing. Log in offers three options. There are Google and Facebook OAuth2 login links on the log in page to log in with a Google or Facebook account, and there is a 'Login by email' link to login via Persona with any address you register and confirm with Persona. This is a new installation of Mailman 3 so there are still kinks to work out, and any issues can be discussed on the list or reported to the trackers at <https://gitlab.com/mailman/postorius/issues>, <https://gitlab.com/mailman/hyperkitty/issues> or <https://gitlab.com/mailman/mailman/issues> as appropriate. Enjoy! -- Mark Sapiro <mark(a)msapiro.net> The highway is for gamblers, San Francisco Bay Area, California better use your sense - B. Dylan

1 0

Unable to commit changes from mailman shell to database
by Gurkirpal Singh 02 Apr '16

02 Apr '16

I tried the doing it the way you did and got the same result. After checking with "dir()" I found a "commit" method. I tried running it and it worked. >>> dir() ['IUserManager', '__builtins__', 'a', 'abort', 'commit', 'config', 'getUtility', 'l', 'm', 'now', 'um', 'user_manager', 'x'] >>> commit <bound method SABaseDatabase.commit of <mailman.database.postgresql.PostgreSQLDatabase object at 0x7efbf969c9e8>> >>> commit() >>> Maybe it was there because I'm using PostgreSQL but it worked for me.

2 1

Re: [Mailman-Developers] Unable to commit changes from mailman shell to database
by Barry Warsaw 02 Apr '16

02 Apr '16

On Apr 02, 2016, at 06:17 AM, Anirudh Dahiya wrote: >I have been playing with mailman shell but upon creating objects like >domains and addresses, and subsequestly committing them to database by >calling transaction.commit() I am unable to see changes in the database(and >thus on Postorius) >The current approach I am taking towards committing transaction is first >creating a connection object by calling config.db.engine.connect() . After >that, I am creating a transaction object by calling connection.begin() . >Finally after creating domain and address objects, I call >transaction.commit(),which executes succesfully, but I am unable to see >changes being reflected in the database. Which database backend are you using, SQLite or PostgreSQL? When you're checking the database, is this from a different process? How are you checking the database? Can you give us the exact set of commands you're using both to change things and to check things? E.g. maybe paste a console session so we can reproduce it. `mailman shell` exposes some globals, such as commit(), abort(), the config object, and the mailing list `m` object if you gave the -l option. I don't think you normally need to do the config.db.engine.connect() call or the connection.begin() call, and I don't know whether those are create subtransactions or otherwise interfering with your operations. Cheers, -Barry

1 0

Unable to commit changes from mailman shell to database
by Anirudh Dahiya 02 Apr '16

02 Apr '16

Hi I have been playing with mailman shell but upon creating objects like domains and addresses, and subsequestly committing them to database by calling transaction.commit() I am unable to see changes in the database(and thus on Postorius) The current approach I am taking towards committing transaction is first creating a connection object by calling config.db.engine.connect() . After that, I am creating a transaction object by calling connection.begin() . Finally after creating domain and address objects, I call transaction.commit(),which executes succesfully, but I am unable to see changes being reflected in the database. Thanks Anirudh Dahiya (IRC spark)

1 0