Mailman 3 August 2019 - 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

Change of my homepage
by sandeep kumar 31 Aug '19

31 Aug '19

Hi Team I want to customize my home page of mailman 3 . When I type my site name it should go to another page and from there when I click distribution lists link It should redirect to mailman 3 default homepage. I am trying to achieve this and failing in this regard. Expert team please give me any suggestions and clues regarding the dependencies that may involved in changing this. -- Regards Sandeep Kumar +91-9642669192

2 3

SSL error while connecting to hyperkitty
by sandeep kumar 31 Aug '19

31 Aug '19

Hi Team Iam using httpd to work with ssl on mailman 3 using proxy pass. After this configuration Iam not able to connect to hyperkitty. It is throwing ssl certificate error in mailman.log file. What should be the configuration of hyperkitty while using https in mailman..? Please help me with this Iam struck here from past 4 days Rgrds Sandeep Sent from my iPhone

2 3

Mails are not archiving in hyperkitty
by sandeep kumar 28 Aug '19

28 Aug '19

Hi Team We are encountering a weird issue, after enabling archives for a list, mails are not archived and not seen in hyperkitty. No error observed. How will the communication between postorius and hyperkitty takes place..?? Sent from my iPhone

1 0

Error after starting mailman-suite
by sandeep kumar 23 Aug '19

23 Aug '19

Hi Team We observed the following error after starting the mailman-suite. If some one has experienced the same please provide any inputs. Exception happened during processing of request from ('127.0.0.1', 50210) Traceback (most recent call last): File "/usr/lib64/python3.6/socketserver.py", line 651, in process_request_thread self.finish_request(request, client_address) File "/usr/lib64/python3.6/socketserver.py", line 361, in finish_request self.RequestHandlerClass(request, client_address, self) File "/usr/lib64/python3.6/socketserver.py", line 721, in __init__ self.handle() File "/var/lib/mailman/venv3/lib64/python3.6/site-packages/Django-2.1.8-py3.6.egg/django/core/servers/basehttp.py", line 171, in handle self.handle_one_request() File "/var/lib/mailman/venv3/lib64/python3.6/site-packages/Django-2.1.8-py3.6.egg/django/core/servers/basehttp.py", line 179, in handle_one_request self.raw_requestline = self.rfile.readline(65537) File "/usr/lib64/python3.6/socket.py", line 586, in readinto return self._sock.recv_into(b) ConnectionResetError: [Errno 104] Connection reset by peer -- Regards Sandeep Kumar +91-9642669192

2 2

Implementing `bounce_you_are_disabled_warnings_interval` in `Send_Warnings` function.
by Aaryan Bhagat 20 Aug '19

20 Aug '19

I am developing the processing of bounce messages as my GSoC project. Currently the `Bounce Functions` are being developed in [this](https://gitlab.com/mailman/mailman/merge_requests/538) pr on GitLab. There is one `bool` attribute called `bounce_you_are_disabled_warnings_interval` in the `Mailing List` model. It means >The number of days between each disabled notification. Implementing this has a problem - Say in the case of `process_bounces` function which processes the `BounceEvents` function it is easy it just takes one by one the events from the database and processes them. - In the case of `Send_Warnings` function if the same approach was followed, meaning it would take one by one the `Address` instances, check tuples in the `bounce_info` attribute ( see the pr for this ) and see whether to send a warning mail or not to can be a slow method. - Let's suppose the `Addresses` list is very long, then an `Address` instance in the very bottom of the list whose subscription has been disabled and some warning emails send, now waits to receive another mail as the interval is more than `bounce_you_are_disabled_warnings_interval`. - If the function is enumerating from the top then in order to take action first it has to reach this `Address` instance but the interval is already crossed. This can cause slow performance as the `warning mail` will be sent way late than it actually should have been sent. - Also if I am implementing 2 functions `process_bounces` and `send_warnings` what if both of them attempted at the same `Address` instance? - Basically `implementation on sending warning mails` and `implementation to increase bounce_score` are separate things and they can cause problems if they processed the same instance. Pointers on above will be helpful. Am I missing something above?

3 15

Initialization of GSOD Project
by Ariessa N 19 Aug '19

19 Aug '19

Hello everyone, I’m Ariessa Norramli and I’m a GSOD participant with the project “Instructions to Migration from Mailman 2 to Mailman 3”. My accepted proposal can be viewed at: http://bit.ly/ariessa_migration_gsod_application During the doc development period, I'll deliver a weekly blog post to summarise what I did throughout the respective week.The blog posts can be viewed at: https://medium.com/@ariessa_norramli I'll use the mailing list as my main source of communication with mentors. Thank you. Best Regards, *Ariessa Norramli*

2 1

Migrating mailman 2 to mailman 3.1
by sandeep kumar 15 Aug '19

15 Aug '19

Hi Team I have successfully completed implementation of mailman with some customizations (like sending sms to moderators for pending lists, Authenticating into mailman 3 using existing LDAP,and some minor changes) Now that we are ready to go into production. We are currently running mailman 2 in our production. Now the biggest challenge is we have to migrate around 3000 lists from mailman 2 to mailman 3. Is there any documentation or any inputs from the team would be appreciated and will be very helpful. Iam trying to access docs.mailman3.org but it is not opening don't why.? This group helped me a lot in bringing my mailman 3 upto this stage. The process of migration would complete my project. Requesting your valuable inputs Regards Sandeep Sent from my iPhone

4 5

Re: mailman3 merge strategies (squashing commits vs. leaving commits as they are)
by Abhilash Raj 09 Aug '19

09 Aug '19

+ Mailman Developers, since this seems like a general discussion topic. On Thu, Aug 8, 2019, at 2:01 AM, Mike Gabriel wrote: > Hi Abhilash, > > I just looked into the two recent merges from Daniel on mailman's > master branch. > > I noticed that you squashed the MR branch commits into one commit > before the merge and that this one commit uses the latest commit > messages of the MR branch to describe what the squashed commits do. > Unfortunately, that commit messages does not appropriately describe > what the commit in fact does. > > The resulting commit on master for the merge of MR !543 is this: > > ``` > commit baf7fbca96cf77ae028740b668d79a906eb600ef > Author: Daniel Teichmann <daniel(a)teichm-sh.de> > Date: Thu Aug 8 01:25:05 2019 +0000 > > commands/tests/test_cli_members.py: Add testcase for del_infp > files containing commented and blank lines > > ``` This looks surprising to me, I was hoping that it would use the title of the MR as the commit message and description as the description of the commit. Looking a bit more closely at the documentation[1], it looks like it will pickup: > The squashed commit’s commit message will be either: > - Taken from the first multi-line commit message in the merge. > - The merge request’s title if no multi-line commit message is found. I am going to keep an eye out for the commit message in future before merging, thanks for pointing this out. [1]: https://docs.gitlab.com/ee/user/project/merge_requests/squash_and_merge.html > It contains the complete "mailman members --delete" code (all commits > from MR !543), but its commit message is the message of the top commit > that was on the MR branch. Commit content and commit message deviate. > > > As this merging strategy seems to be a sub-optimal strategy, I'd love > to discuss it for mailman3, if that's ok. > > So... > > IMHO, it would be much better (for the sake of transparency and code > change documentation) to either avoid commit squashing on merges > (iirc, it can be disabled in GitLab on a pre project level) or > explicitly demand from contributors to stuff all their code changes > into one commit and ship an appropriate commit msg. This could have happened a few times in the past because I didn't know Gitlab would pick a commit message with the multi-line comment. However, this is not a general pattern that I am trying to enforce here. It would be great to have single commit MRs, however, after the review, I'd prefer to have additional commits added to the MR as compared to sqashing + force push. Additional commits makes 2nd and 3rd reviews much more easy, since I can just look at the comments I made and the changes made in the newer commits. Finally, we want the MR to be merged as a single commit, so we use the Gitlab's sqash-merge feature. It works okay most of the times, like I mentioned above. > For big MRs the second option is really sub-optimal (esp. from a > (Debian) downstream maintainer's point of view): if I needed to > cherry-pick tiny changes on the code into a stable mailman3 release in > Debian, for example, then I'd love to have atomic changes to > cherry-pick from in the upstream Git. However, if all merges' commits > get squashed before being applied on master, then the changesets on > master become quite bulky and un-cherry-pickable. Ideally, MRs are a complete unit and it doesn't make sense IMO to cherry-pick only parts of the MR. MRs should be atomic. If there are two independent things being done in a single MR, it should ideally be split into separate MRs and hence get merged as separate commits. > > For future merge requests, would you prefer us to stuff all changes of > one MR into one commit? Or is it ok, to have several commits in one > MR? This would IMHO require from you to not squash the commits on > those MRs. I hope I answered this above, but in summary, please squash commits when your Open the MR, but please don't force-push when you make requested changed from the review. Also, we maintainers should be aware and just keep an eye out for the commit message. It is totally possible in Gitlab to change the Squash'd commit's message and in case Gitlab doesn't pick up the MR's title and desc, I'll try to pick it up manually. Does that sound reasonable? > Please let me know what your position is on this. Thanks! > > Mike > -- > > DAS-NETZWERKTEAM > c\o Technik- und Ökologiezentrum Eckernförde > Mike Gabriel, Marienthaler str. 17, 24340 Eckernförde > mobile: +49 (1520) 1976 148 > landline: +49 (4351) 850 8940 > > GnuPG Fingerprint: 9BFB AEE8 6C0A A5FF BF22 0782 9AF4 6B30 2577 1B31 > mail: mike.gabriel(a)das-netzwerkteam.de, http://das-netzwerkteam.de > > -- thanks, Abhilash Raj (maxking)

3 3

GNU Mailman Season of Docs Proposal Selection
by Stephen J. Turnbull 09 Aug '19

09 Aug '19

To the applicants to Google Season of Docs with GNU Mailman: Cc: Mailman Developers [This is an abbreviated version of the message sent directly to the applicants.] Thank you all for your interest in GNU Mailman, and for applying to Season of Docs with the Mailman organization. First, I would like to congratulate Ariessa Norramli, whose project "Instructions for Migrating from Mailman 2 to Mailman 3" we selected for implementation this autumn. The list of all projects selected is available on the Season of Docs website at https://developers.google.com/season-of-docs/docs/participants/ Public discussion of the project will take place on the Mailman Developers mailing list <mailman-developers(a)python.org>. We will also negotiate a blogging requirement during the community bonding period. Of course Mailman is a public project on GitLab, and you can follow progress of the documentation project there. URLs for the blog and the repo will be posted to the mailing list. I hope all of the applicants will find some way to participate in the Mailman project as suits time and interest. About the Selection Process: Eight technical writers in some way expressed interest in Season of Docs with GNU Mailman, of whom five entered proposals via the Season of Docs website. Two of those proposals were stubs containing little or no content, which were eliminated quickly. The remaining three proposals were all very high quality, and in fact we could have selected any of them. Each had small advantages and disadvantages compared to the other two. The tie-breaking criterion was the content of the proposal: after consulting with Abhilash, I decided that the migration instructions project was our biggest documentation need based on the questions we get on the Mailman 3 users mailing list. -- Associate Professor Division of Policy and Planning Science http://turnbull.sk.tsukuba.ac.jp/ Faculty of Systems and Information Email: turnbull(a)sk.tsukuba.ac.jp University of Tsukuba Tel: 029-853-5175 Tennodai 1-1-1, Tsukuba 305-8573 JAPAN

1 0