Mailman 3 December 2015 - 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

Let's try to package mailman3 in Debian!
by Pierre-Elliott Bécue 22 Feb '16

22 Feb '16

Hey, As a Debian fanboy and also a mailman addict, I'd like to try packaging it in Debian. As I'm not a DD and as I'm not in a hurry, I'd like to take some time to think about what would be relevant. For that, I'd like to have some help. And I was suggested to come here and ask. I decided to use https://gitlab.com/groups/mailman as a basis for my work. First of all, to create the source package, I've to think about what to put in it. It seems that if I want to have a good source package, I need 5 repos : - Mailman - HyperKitty - Postorius - HyperKitty - MailMan Plugin - MailmanClient My first question is "Am I right?". And the second one is whould I consider looking into mailman-suite-doc and also have it in the source package? On another way, I also see that there is a standalone postorius repo and also some django project files for HyperKitty in another one. I have the impression it is more designed for people to work on as standalone - forkable projects for other features, and so I wouldn't need them in a Debian package. Am I also right? Thanks for your answer, I hope I'll be able to make this package look as you'd like. :) Cheers, -- PEB

5 13

Re: [Mailman-Developers] Student looking to contribute towards GNU Mailman
by Stephen J. Turnbull 02 Jan '16

02 Jan '16

Rishab Jaju writes: > Hi Abhilash, > > I am interested in the following project: "Subscriber Profile > Pages". Can I work on this project, or is somebody else working on > it? Even if somebody else is working on it, they may appreciate the help. Even if they are but don't want help, you can try yourself (but of course competing implementations means yours is less likely to actually get integrated). Now that you have posted here, I would recommend getting to work unless you have an alternative project you would prefer to work on. Remember, at this stage you'll spend most of your time learning about Mailman, and your code is likely to get a lot of suggestions for improvement, so you won't be making much in the way of wasted effort even if you end up abandoning this particular project for whatever reason at an early stage. While digging into the code, you may also find a more interesting (to you) project before GSoC opens, or you may find that to do the profile page project you need to add basic facilities, and do that for GSoC. Don't commit yourself to a specific project for GSoC yet. The next thing to do is to check the tracker. I found these: https://gitlab.com/mailman/mailman/issues/62 https://gitlab.com/mailman/postorius/issues/5 Neither seems to suggest that anybody is actually working on this project. Note that the issues are titled "User Profile Pages" rather than "Subscriber Profile Pages" -- searching for appropriate issues is an art. Don't kill yourself trying to do an exhaustive search or coming up with the perfect keywords. If you decide to work on this, come up with a summary of what *you* want to do (it may help to refer to the existing issue descriptions), and post it as an RFE (request for enhancement), most likely on the Postorius tracker. That will allow others interested in the project (both potential users and developers) to find you. Mention that you are working on the project, and link to the existing issues. A bit of advice: I tend to disagree with Our Fearless Leader: I think there's more of a role for "core" in this. Specifically, discoverability of resources. Resources are spread across the three main components, and the list archives at least will have multiple implementations in common use. Steve

2 1

Re: [Mailman-Developers] Student looking to contribute towards GNU Mailman
by Abhilash Raj 31 Dec '15

31 Dec '15

Hi Rishab, On 12/29/2015 06:32 PM, Rishab Jaju wrote: > Hello everybody, > > I am a third year student looking to contribute towards GNU Mailman for the > upcoming Google Summer of Code program. > > I am very proficient in C++, Java, Python and Scheme. I have done some > projects in machine learning as well as NLP. > > What level of knowledge would I need to contribute to the project? What > sort of project would be appropriate for my skill set? There is no specific knowledge level that is required to contribute to GNU Mailman project except basic Python and common sense. You can get started by looking at the issues and reading code for the mailman project that you can find at the project website. If it is not already clear from the website, I would tell you that the development is focused around Mailman 3.0 and its sister projects. Getting started is same as every year, so you can look at the last year's GSoC page in the mailman wiki till we create and update the new page for 2016. > > Thank you, > Rishab Jaju. > _______________________________________________ > Mailman-Developers mailing list > Mailman-Developers(a)python.org > https://mail.python.org/mailman/listinfo/mailman-developers > Mailman FAQ: http://wiki.list.org/x/AgA3 > Searchable Archives: http://www.mail-archive.com/mailman-developers%40python.org/ > Unsubscribe: https://mail.python.org/mailman/options/mailman-developers/raj.abhilash1%40… > > Security Policy: http://wiki.list.org/x/QIA9 > -- thanks, Abhilash Raj

2 1

Student looking to contribute towards GNU Mailman
by Rishab Jaju 30 Dec '15

30 Dec '15

Hello everybody, I am a third year student looking to contribute towards GNU Mailman for the upcoming Google Summer of Code program. I am very proficient in C++, Java, Python and Scheme. I have done some projects in machine learning as well as NLP. What level of knowledge would I need to contribute to the project? What sort of project would be appropriate for my skill set? Thank you, Rishab Jaju.

1 0

Re: [Mailman-Developers] Website re-org?
by Barry Warsaw 27 Dec '15

27 Dec '15

On Dec 24, 2015, at 09:55 AM, Tom Browder wrote: >In my opinion, that link should replace ALL other links under the >Documentation menu at the top of the home page (www.list.org), and it >should clearly specify MM 3, something like: > > Documentation > > Mailman 3 => http://docs.mailman3.org/en/latest/ > >I am ready (finally) to start new lists with MM 3 and that, I assume, >is where I should look. Although, I do like the "quick links" nature of the Documentation menu. One less click once you know where you want to go. Maybe the docs.mailman3.org page can be linked from an "Overview" menu item? Cheers, -Barry

2 1

Re: [Mailman-Developers] MM 3 REST API
by Barry Warsaw 26 Dec '15

26 Dec '15

On Dec 24, 2015, at 11:08 AM, Tom Browder wrote: >Where should I look for the complete, definitive documentation on the >MM3 REST API? Sadly, there's no programmatic way to gather the specifications for the REST API. The best you have is the online documentation... http://mailman.readthedocs.org/en/latest/README.html ...and the source. You can refer to two other projects which access the API though, and which might also help. https://gitlab.com/mailman/mailmanclient - is the official Python bindings to the REST API. https://gitlab.com/astuart/mailmania - is Andrew Stuart's authenticating proxy, which exposes a public REST API bridging to the internal REST API that the core exposes. At some point, we'll pull this in as an official subproject. I'd welcome contributions to help make the REST API more discoverable and/or better documented. Cheers, -Barry

3 3

MM 3 REST API
by Tom Browder 24 Dec '15

24 Dec '15

Where should I look for the complete, definitive documentation on the MM3 REST API? I would like to use Perl for my bulk handling of mailing lists, subscriptions, etc. Thanks! -Tom

1 0

Website re-org?
by Terri Oda 24 Dec '15

24 Dec '15

Abhilash did a lovely job on the new website, but while the layout has changed, a lot of the content hasn't. And I'm not sure what we've got lines up very with what people want out of our website, so I'm thinking about re-organizing. Right now, I suspect that when people visit list.org, these are the things they want to do: 1. Find out what mailman is. We're good at that right now: there's good info on the main page and then links to features. 2. Find out how to get and install the latest version of Mailman. Need improvement here. Mailman 2.1 download links are good. Mailman 3 directs you to PyPI but then there's nothing explaining about how Mailman now is a suite and it's this bunch of packages. Also nothing about how you can use mailman-bundler rather than trying to make the magic happen yourself. I wrote something up and put in a merge request, pending someone proofreading it: https://gitlab.com/mailman/mailman-website/merge_requests/5 3. Find out how to report a bug We kind of fail on this one, except if you want to report a security issue. Again, this is more complex than it might seem since there's a bunch of different components. 4. Find the docs / get help with an issue. The good: they're linked right there in the top bar. The bad: is someone looking at this going to know they want the docs for postorius vs hyperkitty? Will any of that make sense? I think we might need a landing page here. We do have a "help" link and the "wiki" link in this area too, but I think a landing page could bring this all together more nicely. 5. Find out how to contribute. This is going to be especially gsoc students. We've got some nice developer links and yeay, this is one of the pages that lists out all the parts of Mailman! But we could really use a startup guide here. We do have a nice Donate link for financial contributions, though. 6. Figure out how to get in touch with us. This page is pretty decent, with the mailing lists and IRC and all. Maybe if we had a "how to report a bug" page it should be linked here, but otherwise full marks. 7. Learn more about Mailman We've got some good resources: features, media, the code of conduct, etc. But probably we should group this all together so that it's easier for people to find the other important things they want without wading through all these links. I'd suggest we keep the top of page links as they are, since they're super useful to people who know what they're looking for already, and have the left side menu be more about the guides. But I think we should replace all the links down the left-hand side of the page with links that match up with those goals, so the menu would probably look something like: * About Mailman - combine all the about mailman stuff here, although we also want to leave the main page as is, so there may be a bit of duplication here. * Get Mailman - Links to source code and install guides, high level description of what to do. * Help and Documentation - landing page with a link to the docs, wiki and mailing lists, with instructions. Maybe some search boxes? Userguides go here too. * Report an issue / Contact Us - landing page with reminder about reporting security bugs, links to bug trackers, mailing lists, irc * How to Contribute - new contributors guide here, prefaced by the basic source/gitlab links Thoughts on better ways to set this up? Other suggestions of things people often want out of our website? Terri

4 6

Re: [Mailman-Developers] Mailman 3 production setup testbed
by Terri Oda 21 Dec '15

21 Dec '15

On 2015-11-24 7:32 AM, Andrew Hodgson wrote: > My confusion relates to the virtual environment that I create. I am > running from the dedicated MM3 user I created, and I am looking to > expand the bundler from the user’s home directory in /home (for > example). When I create the virtual environment, the files are all > held in this directory, and I really want the MM3 to be installed > system wide as this will be the only program running on this machine. > Do I even need to create a virtual environment at all? Are there any > other guides relating to setting up MM3 for a purely production > environment with minimal dependencies? I hit this same issue, as it were. In my case, I knew exactly what was going on and why but, the problem arose when I needed other people to be able to do mailman-related stuff on the machine and it feels *really* weird to people to go into my home directory to restart mailman. I think we should probably update the docs to suggest that you start by making a directory where you'd like mailman installed, rather than the way the guide is currently written where it sometimes surprises people that they have a live mailman install in their home directory (as opposed to the workflow people may be expecting which more like "I get a staged copy of my source in my home directory and then I type make install and it puts the executables and config files in expected places") What would be a good default directory to have in the docs if I want to update them to suggest you start somewhere other than your home directory? /opt/mailman is probably the most appropriate one according to the LSB. Does anyone want to make another suggestion before I update the docs to suggest that as a logical place to put your mailman stuff? (I'll leave a note saying that if you're just trying stuff out then your home directory is fine, too.) Terri

3 5