Mailman-Developers October 2017

mailman-developers@python.org

11 participants
14 discussions

Mailman 2.1.25 released
by Mark Sapiro 23 Nov '17

23 Nov '17

I am pleased to announce the release of Mailman 2.1.25. Python 2.4 is the minimum supported, but Python 2.7 is strongly recommended. This is a routine bug fix release with a minor new feature and some accessibility improvements for screen readers. See the attached README.txt 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 https://www.gnu.org/software/mailman http://mailman.sourceforge.net/ https://mirror.list.org/ Mailman 2.1.25 can be downloaded from https://launchpad.net/mailman/2.1/ https://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

2 2

Use of the public suffix list
by Alessandro Vesely 04 Nov '17

04 Nov '17

Hi all, I noticed (from a DMARC mitigation utility that Lindsay extracted) that Mailman features its own approach to using the PSL. Of course, development must go on, and sometimes it is a waste of time trying to make a super-duper scaffolding for a job that can be carried out complying to the KISS principle. At any rate, what is the future of DMARC lookups in Mailman? * The specs say that "DMARC should be amended to use [a method better than PSL] as soon as it is generally available" [1]. I believe that sentence refers to RDAP, which was released more or less at the same time (March 2015) [2]. [1] https://tools.ietf.org/html/rfc7489#appendix-A.6 [2] https://datatracker.ietf.org/wg/weirds/documents/ * There are various Python packages for domain name splitting. They obviously use the PSL, but supposedly would transparently switch to a better method in case. If Mailman used one such package, a practical advantage for users would be to update the PSL in only one place, if they happened to use the same dependency. I found six packages. tldextract [3] is the only one of them which caches a JSON object rather than the original textual representation of the list. It uses a frozenset. tld [4] and publicsuffixlist [5] also build a set. publicsuffix[6] and publicsuffix2 [7] build lists of nested dictionaries from all the labels. dnspy [8] builds a dictionary of FQDNs, somewhat like Mailman. How does the time to build the structure compare with the time taken by DSN queries? [3] https://pypi.python.org/pypi/tldextract [4] https://pypi.python.org/pypi/tld [5] https://pypi.python.org/pypi/publicsuffixlist [6] https://pypi.python.org/pypi/publicsuffix [7] https://pypi.python.org/pypi/publicsuffix2 [8] https://pypi.python.org/pypi/dnspy * Debian distributes a publicsuffix package which brings a textual version of the list. Since stretch, it also brings a "dafsa" version. Nowadays, most C implementations (Firefox, Chromium) use dafsa. They build the structure using offsets rather than pointers, so that the blob can be defined in a source file as a literal static array of chars, in order to minimize loading time. That strategy works well as long as the relevant package is upgraded more frequently than the PSL. Otherwise, as for libpsl, one ends up using obsolete data. Surprisingly, the publisuffix package itself is not upgraded as frequently as the PSL. This bug [9] is what prompted me to write this message. I guess you, as Mailman developers, have pondered this subject and I'd be interested to know what you think. [9] https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=879008 TIA for any reply Ale --

3 4

Re: [Mailman-Developers] Signing commits with gpg
by Barry Warsaw 26 Oct '17

26 Oct '17

On Oct 24, 2017, at 16:52, Abhilash Raj <maxking(a)asynchronous.in> wrote: > > Gitlab now supports verification of commit signatures and it would be > awesome if we start signing commits. It is a relatively painless process > and happens automatically with little configuration. Very cool that GL has enabled this! Thanks for sending the recipe too. I definitely encourage folks (especially core devs) to start signing commits. Cheers, -Barry

5 6

Signing commits with gpg
by Abhilash Raj 24 Oct '17

24 Oct '17

Hi All, Gitlab now supports verification of commit signatures and it would be awesome if we start signing commits. It is a relatively painless process and happens automatically with little configuration. Spoofing authors in git is quite easy, actually provided as a command line option (--author, --reset-author), and I believe it would be a good practice to sign all the commits (even outside of Mailman). Here are steps for how you can do that: 1. Add your public key to Gitlab (https://gitlab.com/profile/gpg_keys) 2. Commit with `-S` (capital S) Here is the relevant section of `.gitconfig` to auto-sign every commit you make (no need for step 2 if you do this): ``` [user] name = Abhilash Raj email = raj.abhilash1(a)gmail.com signingkey = 541EA0448453394FF77A0ECC9D9B2BA061D0A67C [commit] gpgsign = true ``` Once you have pushed a signed commit to Gitlab and have uploaded your gpg public key, you will see a green "Verified" button alongside every commit. (See https://gitlab.com/maxking/mailman/commits/msapiro/mailman-pending) -- Abhilash Raj maxking(a)asynchronous.in

1 0

Re: [Mailman-Developers] Renaming a list
by Mark Sapiro 24 Oct '17

24 Oct '17

On 10/23/2017 05:02 PM, Abhilash Raj wrote: > On Mon, Oct 23, 2017, at 08:59 AM, Barry Warsaw wrote: >> On Oct 23, 2017, at 11:48, Aurelien Bompard <aurelien(a)bompard.org> wrote: >>> >>> I wanted to rename a list (only the list_name, not the list_id) and I >>> figured I would make the transition smoother by adding an "AcceptableAlias" >>> with the old name. I did that and realized that the acceptable aliases are >>> not added to the postfix_lmtp file, as a result emails sent to the old >>> address are just bounced at the Postfix level. >>> Is this the intended behavior ? >> >> It is. The thinking is that whatever email addresses end up funneling to >> a list is really outside of Mailman’s control. That’s really part of >> your MTA’s configuration, and acceptable aliases are just a way of >> telling Mailman to expand its implicit address logic. > > As I understand, AcceptableAliases are defined as regular expressions, > what if Mailman put the values that are a valid list name to > transport_maps? Converting regex to a listname doesn't sound like a > straight forward thing to me though. I think that's going to be too complex and error prone. > This most definitely adds some complexity for unique checks of > Listnames. I am not sure if we already check acceptable alias rules for > existing mailing lists to make sure they don't match any new list > created. We'd have to do it if we start putting acceptable aliases in > transport maps. We don't and it doesn't matter for what acceptable_aliases is intended to be used for. The background is a list can be configured (and is by default) to require_explicit_destination. which is intended as an anti-spam measure. I.e. it requires the list posting address to appear in To: or Cc: of the message and stops "To: undisclosed recipients:;" type of mail. > As a feature, it could be helpful to have multiple posting addresses for > a single List. Are there any major downsides to doing this? You can, either by aliases, .forwards or other MTA type configurations. And that's exactly what acceptable_aliases is for - to accept those alternate posting addresses as valid explicit destinations. But, I think it should be up to the installation to configure their MTAs or whatever for this. I don't thing we should be trying to generate MTA configurations for alternate list names bases on acceptable_aliases. -- Mark Sapiro <mark(a)msapiro.net> The highway is for gamblers, San Francisco Bay Area, California better use your sense - B. Dylan

2 1

Re: [Mailman-Developers] Renaming a list
by Barry Warsaw 24 Oct '17

24 Oct '17

On Oct 23, 2017, at 11:48, Aurelien Bompard <aurelien(a)bompard.org> wrote: > > I wanted to rename a list (only the list_name, not the list_id) and I > figured I would make the transition smoother by adding an "AcceptableAlias" > with the old name. I did that and realized that the acceptable aliases are > not added to the postfix_lmtp file, as a result emails sent to the old > address are just bounced at the Postfix level. > Is this the intended behavior ? It is. The thinking is that whatever email addresses end up funneling to a list is really outside of Mailman’s control. That’s really part of your MTA’s configuration, and acceptable aliases are just a way of telling Mailman to expand its implicit address logic. > BTW, changing the list_name attribute is sufficient to rename a list, > right? I didn't find anything else to change since everything seems to be > keyed to the list_id but I thought I'd check with you. Correct. List name is mutable but list-id is not, even if you move it to a different domain! -Barry

2 1

Renaming a list
by Aurelien Bompard 23 Oct '17

23 Oct '17

Hey folks! I wanted to rename a list (only the list_name, not the list_id) and I figured I would make the transition smoother by adding an "AcceptableAlias" with the old name. I did that and realized that the acceptable aliases are not added to the postfix_lmtp file, as a result emails sent to the old address are just bounced at the Postfix level. Is this the intended behavior ? BTW, changing the list_name attribute is sufficient to rename a list, right? I didn't find anything else to change since everything seems to be keyed to the list_id but I thought I'd check with you. Thanks! Aurélien

1 0

DMARC mitigation code question
by Lindsay Haisley 20 Oct '17

20 Oct '17

Mark, et al While configuring the MM 2.1 DMARC mitigation code for use in Courier- MTA I note that the return from _DMARCProhibited(..) for a detected policy of "p=none" is True, just as it is for "p=quarantine" and "p=reject". Why is this? I would assume that if this code is reached, and p=none, that no From munging would be required. -- Lindsay Haisley | "The first casualty when FMP Computer Services | war comes is truth." 512-259-1190 | http://www.fmp.com | -- Hiram W Johnson

2 4

Extracting some Mailman code
by Lindsay Haisley 17 Oct '17

17 Oct '17

Hey folks, This is a request for a pointer to some code rather than an offering for Mailman, but I hope my cred with the Mailman developers will fetch me a bit of help. I can read code and find this out myself, but one of the Mailman devs can probably give me some pointers that will save me a lot of time, time being the only human resource which is truly limited! I'm running Courier-MTA, an excellent MTA around which I've built FMP's small ESP services. Courier has the ability to do a simple email redirect using an alias address in a flat file, in a special directory, containing only the email address to which email should be redirected. Courier also has the ability to interpret lines in this file starting with "|" as programs to which the body of an email can be submitted via stdin and any required processing done therein. I'm the author of courier-to-mailman.py in the contrib collection in Mailman 2's current standard code which works this way. I'm seeing increasing problems with DMARC rejection of emails sent through this simple redirection mechanism, for obvious reasons, and I'm thinking that I might borrow code from Mailman to re-write the From address just as Mailman does when handling a list with from_is_list set to "Munge From", and then pipe emails for selected ESP clients through this filter. Said filter must: * detect whether or not the sending domain publishes a DMARC "p=reject" or "p=quarantine" record * If so, parse out the From address in the email and rewrite it in the general form Mailman uses with "on behalf of ..." giving the origianl sender and specifying the mail server's DN in the sender address. ... after which the email will be sent on to the recipients _real_ address. The management of the message body, the piping and such is handled quite well by Courier. I assume that this would mitigate the DMARC issue for redirections through our mail server, just as it does for Mailman. So, if someone could give me a few pointers to the relevant code in Mailman 2, and any suggestions which might save me some time, I can take it from there. I'm python-literate and have hacked our copy of Mailman here in the past - perhaps more than is wise since every time I upgrade I need to apply a number of patches to bring my mods along with the upgrade :) Thanks for any help you can give me. If it's too much bother, tell me so and I'll put on my hacker's hat and go read code :) Ciao, -- Lindsay Haisley | "Behold! Our way lies through a FMP Computer Services | dark wood whence in which 512-259-1190 | weirdness may wallow!” http://www.fmp.com | --Beauregard

5 12

Re: [Mailman-Developers] Migrating Postorius and Hyperkitty to Python 3
by Terri Oda 09 Oct '17

09 Oct '17

What's the state for Centos? I think it was the last likely distro we cared about with old python needs, but I'm not sure core supports it at all any more. On October 1, 2017 2:12:46 PM PDT, Abhilash Raj <maxking(a)asynchronous.in> wrote: >Hi All, > >Mailman uses Django web framework for the web based frontends, >Postorius >- The Official UI, and Hyperkitty - The official Archiver. They are >both >Django "apps" which means that they can be plugged into any other >existing Django "project" (aka Django "installation") to work alongside >other apps that people might be running. > >Currently, both the Django apps we have are Python 2 only, we have >talked about moving to Python 3 but we decided we want it to be >bilingual (support both 2 & 3). The reason we decided that was because >if people would want to embed Postorius & Hyperkitty in their >installations, they need to be able to run it under whatever python >versions they are using. > >I want to revisit this assumption for being bilingual. Currently, there >is no supported version of Django which doesn't support Python 3. >Starting from v2.0, set to release in December 2017, Django is going to >drop Python2 support. Now, that doesn't mean no one can run Django >under >Python2, 1.11 (LTS version) supports Python2 and will be supported >probably till Python 2 is supported (April 2020 according to [1]). > >I believe that our (limited) development efforts would be best utilized >if we just drop the support for Python 2 in Postorius & Hyperkitty >instead of trying to be bilingual. Any day one of our dependencies may >decide to do the same, and we would have to then use Python 3 anyway. >Also, dropping Python 2 support doesn't seem like a lot of pain for >anyone, you just need another instance of Django running, which is not >*that* hard using uwsgi (in Emperor mode). I believe most of our >dependencies should support Python 3, or should have a good enough >replacement if it doesn't. > > >Thoughts? > >[1]: https://www.djangoproject.com/download/ > >-- > Abhilash Raj > maxking(a)asynchronous.in >_______________________________________________ >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/terri%40toybox.ca > >Security Policy: http://wiki.list.org/x/QIA9

4 3

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

2008

2007

2006

2005

2004

2003

2002

2001

2000

1999

1998

1997

Mailman-Developers October 2017