From turnbull.stephen.fw at u.tsukuba.ac.jp Wed Nov 1 22:31:46 2017 From: turnbull.stephen.fw at u.tsukuba.ac.jp (Stephen J. Turnbull) Date: Thu, 2 Nov 2017 11:31:46 +0900 Subject: [Mailman-Developers] Use of the public suffix list In-Reply-To: References: Message-ID: <23034.33682.20820.706355@turnbull.sk.tsukuba.ac.jp> Alessandro Vesely writes: > * 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/ I see nothing in a quick look at the RDAP spec to suggest that an organizational/administrative domain (AD) field has been defined. It seems like it's just intended to be a replacement for whois, of course allowing extensions like delegating the AD to subdomains (or however that would work -- it's not obvious to me). That presumably would either be registered in the RDAP extensions registry or as a separate RFC. I've seen no discussion of this on DMARC channels either. > Surprisingly, the publisuffix package itself is not upgraded as > frequently as the PSL. I'm not surprised. Most users of the package won't be upgrading that frequently either, I suppose, but will rather be downloading it from the source. In any case, this isn't a problem for Mailman to deal with; it's easy enough to access the public suffix list. A site could do that as a cron job once a day and almost all Mailman subscribers would be protected due to our "count bounces once per day" algorithm -- only sites with an extremely low bounce threshold would have a problem. I suppose there is a backscatter issue, but it's not clear to me that that is such a big deal. This isn't a big deal for us at the moment, and my assessment is that it will not be one for the forseeable future. With the exception of WePublished1.3BillionAddressBooksToSpammers!.com and WeDidToo.com, I haven't heard of anybody publishing p=reject except for domains that produce only transactional mailflows. I'm sure there are many others, but I expect that most people will be subscribing to lists with mailboxes whose domains either have their own _dmarc TXT record or have an "obvious" administrative domain, or are "p=none" per default. Do you have a reason to believe otherwise? Steve From vesely at tana.it Thu Nov 2 06:13:23 2017 From: vesely at tana.it (Alessandro Vesely) Date: Thu, 2 Nov 2017 11:13:23 +0100 Subject: [Mailman-Developers] Use of the public suffix list In-Reply-To: <23034.33682.20820.706355@turnbull.sk.tsukuba.ac.jp> References: <23034.33682.20820.706355@turnbull.sk.tsukuba.ac.jp> Message-ID: On Thu 02/Nov/2017 03:31:46 +0100 Stephen J. Turnbull wrote: > Alessandro Vesely writes: > >> * 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/ > > I see nothing in a quick look at the RDAP spec to suggest that an > organizational/administrative domain (AD) field has been defined. It > seems like it's just intended to be a replacement for whois, of course > allowing extensions like delegating the AD to subdomains (or however > that would work -- it's not obvious to me). That presumably would > either be registered in the RDAP extensions registry or as a separate > RFC. I've seen no discussion of this on DMARC channels either. Yes, RDAP is WHOIS with a machine-readable format. In both cases, a name retrieved from a public domain name registry (DNR) is an "organizational" domain. Rfc7843 defines a publicIds.type to recognize DNRs. That way, one could work out the PSL based on authoritative sources. To make the method practical, RDAP addresses the bootstrap problem (rfc7484), whereby a client could learn DNR info in one shot. To get a feeling of the state of the project, compare the contents of the following URLs --neither of which is usually up to date: https://www.iana.org/domains/root/db http://data.iana.org/rdap/dns.json The second one is mentioned here: https://github.com/arineng/nicinfo/wiki/RDAP-FAQ >> Surprisingly, the publisuffix package itself is not upgraded as >> frequently as the PSL. > > I'm not surprised. Most users of the package won't be upgrading that > frequently either, I suppose, but will rather be downloading it from > the source. PSL take the bother of writing "have your app download the list no more than once per day", so a cron job for each client would do. It is more difficult to coordinate apps, so as to download a single copy for all of them, in the unlikely case that more than one app run on the same host. That way, it becomes a potential packaging problem. > In any case, this isn't a problem for Mailman to deal with; it's easy > enough to access the public suffix list. A site could do that as a > cron job once a day and almost all Mailman subscribers would be > protected due to our "count bounces once per day" algorithm -- only > sites with an extremely low bounce threshold would have a problem. I > suppose there is a backscatter issue, but it's not clear to me that > that is such a big deal. > > This isn't a big deal for us at the moment, and my assessment is that > it will not be one for the forseeable future. With the exception of > WePublished1.3BillionAddressBooksToSpammers!.com and WeDidToo.com, I :-) > haven't heard of anybody publishing p=reject except for domains that > produce only transactional mailflows. I'm sure there are many others, > but I expect that most people will be subscribing to lists with > mailboxes whose domains either have their own _dmarc TXT record or > have an "obvious" administrative domain, or are "p=none" per default. > > Do you have a reason to believe otherwise? No, not really. If anything, I see less and less authenticated mail, both ham and spam. (Possibly an effect of that p=reject?) I know that it is a good thing that DMARC and PSL bring the possibility to learn domain names, but I don't know why. Thank you for sharing your insights Ale -- From johnl at taugh.com Thu Nov 2 08:32:48 2017 From: johnl at taugh.com (John Levine) Date: 2 Nov 2017 12:32:48 -0000 Subject: [Mailman-Developers] Use of the public suffix list In-Reply-To: Message-ID: <20171102123248.12703.qmail@ary.lan> In article you write: >Hi all, >* 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]. Sorry, that is wrong. It was refering to the DBOUND working group which failed to produce anything despite having two reasonable drafts from Casey Deccio and me. RDAP has nothing to do with PSL style boundaries. R's, John From turnbull.stephen.fw at u.tsukuba.ac.jp Sat Nov 4 03:28:04 2017 From: turnbull.stephen.fw at u.tsukuba.ac.jp (Stephen J. Turnbull) Date: Sat, 4 Nov 2017 16:28:04 +0900 Subject: [Mailman-Developers] Use of the public suffix list In-Reply-To: References: <23034.33682.20820.706355@turnbull.sk.tsukuba.ac.jp> Message-ID: <23037.27652.626258.981658@turnbull.sk.tsukuba.ac.jp> Alessandro Vesely writes: > Yes, RDAP is WHOIS with a machine-readable format. In both cases, > a name retrieved from a public domain name registry (DNR) is an > "organizational" domain. Yes, but my understanding of the discussions on the DMARC list leading to use of the PSL in RFC 7843 is that organizational domain != administrative domain, and that's why the existing whois wasn't sufficient to replace the PSL. Did I miss something? > Thank you for sharing your insights And you too! I will take a look at the DBOUNDS discussion mentioned by John, as well as tracking the progress of RDAP. Steve -- Associate Professor Division of Policy and Planning Science http://turnbull/sk.tsukuba.ac.jp/ Faculty of Systems and Information Email: turnbull at sk.tsukuba.ac.jp University of Tsukuba Tel: 029-853-5175 Tennodai 1-1-1, Tsukuba 305-8573 JAPAN From maxking at asynchronous.in Tue Nov 7 18:03:01 2017 From: maxking at asynchronous.in (Abhilash Raj) Date: Tue, 07 Nov 2017 15:03:01 -0800 Subject: [Mailman-Developers] Rolling releases for Container Images and Funding Campaign for Mailman Message-ID: <1510095781.206043.1165061648.2E7F862C@webmail.messagingengine.com> Hi Everyone, As you all know I have been working on container images for Mailman 3. We now have a new "rolling" tag for both mailman-core and mailman-web images. These images have latest source installed for every Mailman component. You can find more information about them on the website [3]. New images are available on quay.io and, moving forward, the rest of the image builds will also be moved to Quay[4][5]. These images are built using git-heads *only* if they are passing our test suite and are re-generated weekly. You should be aware that while all these components are tested with their individual test suites, their combination might sometimes not be stable. This will get you updates/bug-fixes much faster :) As most of you already know, Mailman 3 is the new and improved version with extra features, better security and much better architecture. We released Mailman Suite 3.0 in April 2015 and have come a long ways since then. Mailman Suite 3.1, release May 2016, was aimed to provide feature-parity with Mailman 2.x series and we think we _almost_ hit that goal. Apart from no monthly password reminders, Mailman 3 has a much better Administrator/User interface, REST API for scripting, a really awesome archiver, support for multiple domains, support for external plugins, support for SSO/social login and so much more! I love working on Mailman and would enjoy being able to do so full time for next 6-8 weeks. Mailman 3 is not very far from becoming the default version everyone would use, but it still needs some work to get there. I need help from you, the users of Mailman, to get us there. If you or your organization would like to move to (or, already moved to) Mailman 3, I urge you to donate[1] to us. There are options to donate using Credit Card, Paypal, Bitcoin, Wire Transfer (of any currency), Check and money order. If this campaign succeeds, here is a road map of what I intend to get done: - Move Django apps(UI/Archiver) to Python 3 (or bilingual) - Fork `mailman import` command to provide an upgrade path to Mailman 3.x from Mailman 2.x - Fix MySQL compatibility in Core - Changes in Postorius: - Add support for missing options that are already exposed in Core?s API - e.g. Support for setting templates - Find the commonly used options that are not exposed in Core, add them to Core's API and add to Postorius - Add Admin Dashboard project from GSoC 2014 (maybe?) - Add better testing of container images and provide deployment instructions for Kubernetes & Docker Swarm - Improve the container images to work with new micro-services architecture, to achieve scaling and redundancy in services. - Administrator/User documentation for Postorius & Mailman - (optional) Fork [mmcli](https://github.com/rajeevs1992/mailmancli) project from Rajeev, fix if there is anything missing and add it as an additional command line tool to work with Mailman Core. Maybe pull it under Mailman umbrella. Except for these, if there is something more important that is preventing the adoption of Mailman 3 from your end, we can discuss them. I'd like to mention that I have been working on Mailman 3 for quite some time now and I intend to implement every single item on the list. You donations would help it get done much sooner, hopefully in time for 3.2 release schedule (at PyCon US 2018). You can follow the progress of this campaign here[2]. [1]: https://my.fsf.org/civicrm/contribute/transact?reset=1&id=22 [2]: https://wiki.list.org/x/17892025 [3]: https://asynchronous.in/docker-mailman/#rolling-releases [4]: https://quay.io/repository/maxking/mailman-web [5]: https://quay.io/repository/maxking/mailman-core -- Abhilash Raj maxking at asynchronous.in From simon at hannaweb.eu Wed Nov 8 07:38:55 2017 From: simon at hannaweb.eu (Simon Hanna) Date: Wed, 8 Nov 2017 13:38:55 +0100 Subject: [Mailman-Developers] Rolling releases for Container Images and Funding Campaign for Mailman In-Reply-To: <1510095781.206043.1165061648.2E7F862C@webmail.messagingengine.com> References: <1510095781.206043.1165061648.2E7F862C@webmail.messagingengine.com> Message-ID: <7640496d-28e5-a9ee-2e85-175f5316591d@hannaweb.eu> On 11/08/2017 12:03 AM, Abhilash Raj wrote: > New images are available on quay.io and, moving forward, the rest of > the image builds will also be moved to Quay[4][5]. Since docker deployment is currently the recommended install, with manual installs using the master branches for "experts" I wonder why you are using Quay. It looks like it's a non-free system. Why use Quay but refuse to use a non-free translation system like transifex? > These images are built using git-heads *only* if they are passing our > test suite and are re-generated weekly. You should be aware that while > all these components are tested with their individual test suites, their > combination might sometimes not be stable. This will get you > updates/bug-fixes much faster :) This contradicts what you said in my merge request for Postorius https://gitlab.com/mailman/postorius/merge_requests/232#note_43388756 You either use released versions, or make sure that the master branches are always compatible. You can't have both with the current development model. > If this campaign succeeds, here is a road map of what I intend to get > done: Sounds great, what is the limit where the campaign succeeds? What will happen to the funds if it doesn't? > - Add Admin Dashboard project from GSoC 2014 (maybe?) Didn't find anything using google. What is that project about? > - Add better testing of container images and provide deployment > instructions for Kubernetes & Docker Swarm To be honest, I don't think we should all in on containers. Yes they are nice, but I guess most people would prefer distro packages. Even if people want containers, I for instance would prefer plain systemd-nspawn > - Improve the container images to work with new micro-services > architecture, > to achieve scaling and redundancy in services. The current bottleneck is the rest api from core. IMO bulk actions, filtering and sorting should be added there before trying to have multiple postorius/hyperkitty instances serving the same core... From barry at list.org Wed Nov 8 14:53:05 2017 From: barry at list.org (Barry Warsaw) Date: Wed, 8 Nov 2017 11:53:05 -0800 Subject: [Mailman-Developers] Rolling releases for Container Images and Funding Campaign for Mailman In-Reply-To: <7640496d-28e5-a9ee-2e85-175f5316591d@hannaweb.eu> References: <1510095781.206043.1165061648.2E7F862C@webmail.messagingengine.com> <7640496d-28e5-a9ee-2e85-175f5316591d@hannaweb.eu> Message-ID: On Nov 8, 2017, at 04:38, Simon Hanna wrote: > > On 11/08/2017 12:03 AM, Abhilash Raj wrote: >> New images are available on quay.io and, moving forward, the rest of >> the image builds will also be moved to Quay[4][5]. > Since docker deployment is currently the recommended install, with manual installs using the master branches for "experts" I wonder why you are using Quay. > It looks like it's a non-free system. Why use Quay but refuse to use a non-free translation system like transifex? Is there a free (software) equivalent to Quay? Caveat: I don?t know anything about Quay, so I don?t know what services and advantages it provides. > If this campaign succeeds, here is a road map of what I intend to get >> done: > Sounds great, what is the limit where the campaign succeeds? What will happen to the funds if it doesn?t? The funds all go to the GNU Mailman project?s FSF donation fund. A portion of every donation goes to the FSF, and the Mailman Steering Committee ultimately decides what to do with what?s left in our account. In the past we?ve used it sponsor GSoC students coming to Pycon sprints. > To be honest, I don't think we should all in on containers. > Yes they are nice, but I guess most people would prefer distro packages. > Even if people want containers, I for instance would prefer plain systemd-nspawn There are folks working on Debian packages. I?m not aware of similar efforts for other distro ecosystems. But I don?t think it?s all or nothing, and it does make sense for us (the GNU Mailman project) to support containers to help with adoption, experimentation, and deployment, while working with distro volunteers to package the code up for those platforms. Cheers, -Barry -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 833 bytes Desc: Message signed with OpenPGP URL: From maxking at asynchronous.in Wed Nov 8 17:52:09 2017 From: maxking at asynchronous.in (Abhilash Raj) Date: Wed, 08 Nov 2017 14:52:09 -0800 Subject: [Mailman-Developers] [MM3-users] Re: Rolling releases for Container Images and Funding Campaign for Mailman In-Reply-To: <7640496d-28e5-a9ee-2e85-175f5316591d@hannaweb.eu> References: <1510095781.206043.1165061648.2E7F862C@webmail.messagingengine.com> <7640496d-28e5-a9ee-2e85-175f5316591d@hannaweb.eu> Message-ID: <1510181529.3386463.1166270880.4E19F10C@webmail.messagingengine.com> On Wed, Nov 8, 2017, at 04:38 AM, Simon Hanna wrote: > On 11/08/2017 12:03 AM, Abhilash Raj wrote: > > New images are available on quay.io and, moving forward, the rest of > > the image builds will also be moved to Quay[4][5]. > Since docker deployment is currently the recommended install, with > manual installs using the master branches for "experts" I wonder why you > are using Quay. For those who don't know about it, Quay is a container registry offering from CoreOS. The main reason why I chose to move to Quay, from DockerHub that we are currently using, is security. Some parts of both Dockerhub and Quay are open source and some aren't. There isn't a very clear boundary/transparency in what technologies they use. Both are free to use for open source projects. However, Quay provides an improved security model with RBAC to push images from build server, without having to put my account password on the build server. It also includes a (open source) security scanner for images, which looks for vulnerabilities in packages included in the image so that I can re-build them if one is found. There are open source registries available, most popular of which I know is provided by Gitlab. However, I feel Quay is better for my current workflow, which involves lots of bash scripts for building and testing images on public CI system for rolling releases. Given more free cycles, I do intend to have a better build pipeline and possibly use Gitlab's own registry to distribute images. > It looks like it's a non-free system. Why use Quay but refuse to use a > non-free translation system like transifex? > > These images are built using git-heads *only* if they are passing our > > test suite and are re-generated weekly. You should be aware that while > > all these components are tested with their individual test suites, their > > combination might sometimes not be stable. This will get you > > updates/bug-fixes much faster :) > This contradicts what you said in my merge request for Postorius > https://gitlab.com/mailman/postorius/merge_requests/232#note_43388756 > > You either use released versions, or make sure that the master branches > are always compatible. You can't have both with the current development > model. Not exactly, I still believe all our git-heads should be compatible with released (i.e. stable) versions of dependencies, regardless of the fact that we maintain those dependencies. Also, there is at least one test per-project which tests with git-heads of dependencies we maintain, so that we know if we make any incompatible changes. I am not sure what in the current development model prevents us to do both? The story for container images is different than testing with git-heads. We need better integration testing for the entire suite to be stable in conjunction, rather than independently. In fact, containers might be the perfect way to actually do the integration testing. > > If this campaign succeeds, here is a road map of what I intend to get > > done: > Sounds great, what is the limit where the campaign succeeds? What will > happen to the funds if it doesn't? > > - Add Admin Dashboard project from GSoC 2014 (maybe?) > Didn't find anything using google. What is that project about? https://www.google-melange.com/archive/gsoc/2015/orgs/gnu_mailman/projects/bhaveshgoyal093.html > > - Add better testing of container images and provide deployment > > instructions for Kubernetes & Docker Swarm > To be honest, I don't think we should all in on containers. > Yes they are nice, but I guess most people would prefer distro packages. > Even if people want containers, I for instance would prefer plain > systemd-nspawn Like Barry mentioned, it doesn't have to be all-or-nothing. There is work being done on distro packaging for Debian and I am ready to help others trying to do the same for other distros! Systemd-nspawn isn't really a production grade tool to use containers. I am not sure about how much it adheres to the OCI specs, but if it does, it should not matter which deployment tool you are using with images. I wouldn't mind adding configurations for systemd-nspawn in the documentation, contributions are most welcome. > > - Improve the container images to work with new micro-services > > architecture, > > to achieve scaling and redundancy in services. > The current bottleneck is the rest api from core. IMO bulk actions, > filtering and sorting should be added there before trying to have > multiple postorius/hyperkitty instances serving the same core... I didn't say they will be served from the same core ;-) Yes, the Core's API can be further improved to be more efficient. But that doesn't prevent us from scaling. I understand there are issues around multiple instances of containers, but I have ideas to get around most of them. -- Abhilash Raj maxking at asynchronous.in From simon at hannaweb.eu Sun Nov 12 11:06:54 2017 From: simon at hannaweb.eu (Simon Hanna) Date: Sun, 12 Nov 2017 17:06:54 +0100 Subject: [Mailman-Developers] Rolling releases for Container Images and Funding Campaign for Mailman In-Reply-To: <1510181529.3386463.1166270880.4E19F10C@webmail.messagingengine.com> References: <1510095781.206043.1165061648.2E7F862C@webmail.messagingengine.com> <7640496d-28e5-a9ee-2e85-175f5316591d@hannaweb.eu> <1510181529.3386463.1166270880.4E19F10C@webmail.messagingengine.com> Message-ID: <2cc9ad8f-81e9-e4f1-da1a-b2516cda8c92@hannaweb.eu> >>> These images are built using git-heads *only* if they are passing our >>> test suite and are re-generated weekly. You should be aware that while >>> all these components are tested with their individual test suites, their >>> combination might sometimes not be stable. This will get you >>> updates/bug-fixes much faster :) >> This contradicts what you said in my merge request for Postorius >> https://gitlab.com/mailman/postorius/merge_requests/232#note_43388756 >> >> You either use released versions, or make sure that the master branches >> are always compatible. You can't have both with the current development >> model. > Not exactly, I still believe all our git-heads should be compatible with > released (i.e. stable) versions of dependencies, regardless of the fact > that we maintain those dependencies. > > Also, there is at least one test per-project which tests with git-heads > of dependencies we maintain, so that we know if we make any incompatible > changes. > > I am not sure what in the current development model prevents us > to do both? > > The story for container images is different than testing with git-heads. > We need better integration testing for the entire suite to be stable in > conjunction, rather than independently. In fact, containers might be the > perfect way to actually do the integration testing. Scenario: Core changes something about rest that is backwards incompatible. The change is commited to master. Since your containers use the master branches, all future builds will fail until mailmanclient and postorius/hyperkitty. If you want to always have Postorius (and others) compatible with the latest release of master, development for Postorius will be a Pain, because you can't use the master branch of mailman for testing and quick changes. Also your containers and all integration tests that can be done with them will always fail. Until you fix Postorius and the other clients... So why not just have the master branches always compatible and make life easier for developers. I don't see a good reason why you want to do it the other way round... Any bug in core that affects Postorius will also just remain there until you release a new version of core. If you really really want to have it your way, there have to be more frequent releases. >>> - Improve the container images to work with new micro-services >>> architecture, >>> to achieve scaling and redundancy in services. >> The current bottleneck is the rest api from core. IMO bulk actions, >> filtering and sorting should be added there before trying to have >> multiple postorius/hyperkitty instances serving the same core... > I didn't say they will be served from the same core ;-) > > Yes, the Core's API can be further improved to be more efficient. But > that > doesn't prevent us from scaling. I understand there are issues around > multiple > instances of containers, but I have ideas to get around most of them. I just don't want that people that have issues with big installations get the answer: We know of that issue, please deploy Mailman on X containers/machines as a workaround From maxking at asynchronous.in Sun Nov 12 14:14:22 2017 From: maxking at asynchronous.in (Abhilash Raj) Date: Sun, 12 Nov 2017 11:14:22 -0800 Subject: [Mailman-Developers] [MM3-users] Rolling releases for Container Images and Funding Campaign for Mailman In-Reply-To: <2cc9ad8f-81e9-e4f1-da1a-b2516cda8c92@hannaweb.eu> References: <1510095781.206043.1165061648.2E7F862C@webmail.messagingengine.com> <7640496d-28e5-a9ee-2e85-175f5316591d@hannaweb.eu> <1510181529.3386463.1166270880.4E19F10C@webmail.messagingengine.com> <2cc9ad8f-81e9-e4f1-da1a-b2516cda8c92@hannaweb.eu> Message-ID: <1510514062.3812750.1169950768.672E9843@webmail.messagingengine.com> On Sun, Nov 12, 2017, at 08:06 AM, Simon Hanna wrote: > > >>> These images are built using git-heads *only* if they are passing our > >>> test suite and are re-generated weekly. You should be aware that while > >>> all these components are tested with their individual test suites, their > >>> combination might sometimes not be stable. This will get you > >>> updates/bug-fixes much faster :) > >> This contradicts what you said in my merge request for Postorius > >> https://gitlab.com/mailman/postorius/merge_requests/232#note_43388756 > >> > >> You either use released versions, or make sure that the master branches > >> are always compatible. You can't have both with the current development > >> model. > > Not exactly, I still believe all our git-heads should be compatible with > > released (i.e. stable) versions of dependencies, regardless of the fact > > that we maintain those dependencies. > > > > Also, there is at least one test per-project which tests with git-heads > > of dependencies we maintain, so that we know if we make any incompatible > > changes. > > > > I am not sure what in the current development model prevents us > > to do both? > > > > The story for container images is different than testing with git-heads. > > We need better integration testing for the entire suite to be stable in > > conjunction, rather than independently. In fact, containers might be the > > perfect way to actually do the integration testing. > Scenario: Core changes something about rest that is backwards > incompatible. The change is commited to master. Since your containers > use the master branches, all future builds will fail until mailmanclient > and postorius/hyperkitty. Yes, that is a totally possible scenario. But, given that kind of testing we currently do, this scenario can happen not only to git-heads but also releases. That is what I am trying to build using container images. The fact that I *announced* and *released* these rolling images for public use, is only because people asked for it before. These images come with a fair amount of warning that, right now, they can break! > If you want to always have Postorius (and others) compatible with the > latest release of master, development for Postorius will be a Pain, > because you can't use the master branch of mailman for testing and quick > changes. Also your containers and all integration tests that can be done > with them will always fail. It would most definitely be a pain if we were to break REST API frequently, but that is quite rare. Given that in future API will be consumed by not just us, it is important to keep this assumption true. Another wishful project I have is to be able to "map" the REST API and monitor for changes; it'd also help us with lemme (the authenticating/authorization proxy for Core). And yes, container images will fail, and that's the point! I want them to fail so that releases don't :) Rolling images are meant to bring a faster feedback-loop from users who are OK with rare occasional breaking and want to help test the software, something like public-beta releases. > Until you fix Postorius and the other clients... So why not just have > the master branches always compatible and make life easier for > developers. Incompatible changes are released only with major version upgrades, so it is not going to happen with everyone, unless they choose to use the git-heads and get themselves into it. > I don't see a good reason why you want to do it the other way round... > > Any bug in core that affects Postorius will also just remain there until > you release a new version of core. > > If you really really want to have it your way, there have to be more > frequent releases. Yes, we definitely don't want to say "use new beta-quality container images or stone age stable release". Going forward, we will have more frequent releases too :) > >>> - Improve the container images to work with new micro-services > >>> architecture, > >>> to achieve scaling and redundancy in services. > >> The current bottleneck is the rest api from core. IMO bulk actions, > >> filtering and sorting should be added there before trying to have > >> multiple postorius/hyperkitty instances serving the same core... > > I didn't say they will be served from the same core ;-) > > > > Yes, the Core's API can be further improved to be more efficient. But > > that > > doesn't prevent us from scaling. I understand there are issues around > > multiple > > instances of containers, but I have ideas to get around most of them. > I just don't want that people that have issues with big installations > get the answer: > We know of that issue, please deploy Mailman on X containers/machines as > a workaround Containers are just an easy way to scale, given that we already have them, it'd be fun to see if I can make multiple instances run in parallel. Given that _most_ parts store their data in a data store (database, redis etc), it shouldn't be too difficult. There will be quirks with logging, queues in Core and hence held message views in Postorius, but apart from that, I think everything else can be served using any random instance of Core/Postorius/Hyperkitty. We can most definitely run multiple instances of Hyperkitty, which I feel will be more used than any other part of UI. If we partition the data smartly, we could do the same with Core. Again, these are just theories and needs much more testing and some changes in components themselves! This would most definitely increase the availability and auto-scaling. Making Core's API more efficient would definitely be a good thing and we do intend to do that in future. But, this would still be relevant if we had an efficient REST API, it's not a band-aid to the actual problem :) -- Abhilash Raj maxking at asynchronous.in From barry at list.org Mon Nov 13 21:15:11 2017 From: barry at list.org (Barry Warsaw) Date: Mon, 13 Nov 2017 21:15:11 -0500 Subject: [Mailman-Developers] Rolling releases for Container Images and Funding Campaign for Mailman In-Reply-To: <2cc9ad8f-81e9-e4f1-da1a-b2516cda8c92@hannaweb.eu> References: <1510095781.206043.1165061648.2E7F862C@webmail.messagingengine.com> <7640496d-28e5-a9ee-2e85-175f5316591d@hannaweb.eu> <1510181529.3386463.1166270880.4E19F10C@webmail.messagingengine.com> <2cc9ad8f-81e9-e4f1-da1a-b2516cda8c92@hannaweb.eu> Message-ID: On Nov 12, 2017, at 11:06, Simon Hanna wrote: > Scenario: Core changes something about rest that is backwards incompatible. The change is commited to master. The REST API is versioned, so it would be a bug to introduce a backward incompatibility in the same API version. That?s why for example a new API version was introduced to handle the UUID data type change. There was no way to make that backward compatible, so we had to bump the API version, but we didn?t remove the old API version so clients written against that still work. Adding a new API generally doesn?t require bumping the API version. Cheers, -Barry -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 833 bytes Desc: Message signed with OpenPGP URL: From maxking at asynchronous.in Wed Nov 15 22:29:01 2017 From: maxking at asynchronous.in (Abhilash Raj) Date: Wed, 15 Nov 2017 19:29:01 -0800 Subject: [Mailman-Developers] Migrating Postorius and Hyperkitty to Python 3 In-Reply-To: <1506892366.1092546.1124303592.674357F2@webmail.messagingengine.com> References: <1506892366.1092546.1124303592.674357F2@webmail.messagingengine.com> Message-ID: <1510802941.14222.18.camel@asynchronous.in> Update on this (sorry for the top post), So we are going to move forward with Python 3 only and will be dropping Python 2 support in next major release for each components. I am (slowly) working through the test suite to improve the coverage so that nothing breaks when we move to Python 3. There are already some pending merge requests from Simon (thank you!) on both Django-Mailman 3 and Postorius. Once I am done with tests, I will dig in to review them both and co-ordinate with Simon to land them. thanks, Abhilash On Sun, 2017-10-01 at 14:12 -0700, Abhilash Raj 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/ > From maxking at asynchronous.in Sun Nov 19 14:05:51 2017 From: maxking at asynchronous.in (Abhilash Raj) Date: Sun, 19 Nov 2017 11:05:51 -0800 Subject: [Mailman-Developers] Mailman Core 3.1.1 and Postorius 1.1.1 released Message-ID: <1511118351.17556.22.camel@asynchronous.in> Hello Everyone, I am pleased to announce the release of Mailman Core 3.1.1 and Postorius 1.1.1. Python 2.7 is the only supported version for Postorius 1.1.1 and Python 3.5-3.6 are supported for Mailman Core 3.1.1. Both of these are bugfix releases and include some improvements. For a full list of changes, please see [1] for Core and [2] for Postorius. [1]: http://mailman.rtfd.io/en/release-3.1/src/mailman/docs/NEWS.html [2]: http://docs.mailman3.org/projects/postorius/en/latest/news.html For more information about GNU Mailman, please see our wesbite at one of the following: http://www.list.org https://www.gnu.org/software/mailman http://mailman.sourceforge.net/ https://mirror.list.org/ Documentation for Mailman 3 is available at: http://docs.mailman3.org/en/latest/ Both of these can be downloaded from PyPI. https://pypi.org/project/mailman/ https://pypi.org/project/postorius/ thanks, Abhilash Raj From skoranda at gmail.com Mon Nov 20 12:20:13 2017 From: skoranda at gmail.com (Scott Koranda) Date: Mon, 20 Nov 2017 11:20:13 -0600 Subject: [Mailman-Developers] 3.1.x REST API enhancements around preferred email address Message-ID: <20171120172013.GC33354@paprika.localdomain> Hello, I am interested in contributing enhancements around preferred address to the REST API for version 3.1.x. To prove out my use case(s) and familiarize myself with the code I have made changes already. Here are some example curl command line invocations and output to illustrate: 1) Create an address for an existing user and mark that address as the user's preferred address: curl -u restadmin:restpass \ -X POST \ -d email=skoranda at example.nil \ -d preferred=1 \ http://mytestbed.com:8001/3.1/users/e57ecfd0c0c74a319ac958b18882a6d8/addresses This returns a '201 Created'. 2) Return the preferred address, if set, for a user: curl -u restadmin:restpass \ -X GET \ http://mystestbed.com:8001/3.1/users/e57ecfd0c0c74a319ac958b18882a6d8 | python -m json.tool { "created_on": "2017-11-11T22:20:45.950949", "display_name": "Scott Koranda", "http_etag": "\"26bc0d9f21eb145248884aedae4c1ffd00b608d2\"", "is_server_owner": false, "password": "$6$rounds=656000$gWGfwpajfZ7rVn5O$Sl559B2TgtpJWXA2i67G5ukjzkV6iTp4NgP.6FJpMFMUTDdDXULAmwdN8YW92w87EdctgqFqAUkUqS6.EOTCz/", "preferred_address": "skoranda at example.nil", "self_link": "http://mytestbed.com:8001/3.1/users/e57ecfd0c0c74a319ac958b18882a6d8", "user_id": "e57ecfd0c0c74a319ac958b18882a6d8" } 3) Update/patch a user to set a preferred address: curl -u restadmin:restpass \ -X PATCH \ -d preferred_address=skoranda at example.nil \ http://mytestbed.com:8001/3.1/users/e57ecfd0c0c74a319ac958b18882a6d8 This returns a '204 No Content'. 4) Get all addresses for a user with the preferred address (if set) having the attribute 'preferred' set to 'true': curl -u restadmin:restpass \ -X GET \ http://mytestbed.com:8001/3.1/users/e57ecfd0c0c74a319ac958b18882a6d8/addresses | python -m json.tool { "entries": [ { "email": "skoranda at example.nil", "http_etag": "\"492824d150f9f11e32d530d3cad0f76422bddb48\"", "original_email": "skoranda01 at example.nil", "preferred": true, "registered_on": "2017-11-13T22:35:17.232180", "self_link": "http://mytestbed.com:8001/3.1/addresses/skoranda at example.nil", "user": "http://mytestbed.com:8001/3.1/users/e57ecfd0c0c74a319ac958b18882a6d8", "verified_on": "2017-11-20T16:48:51.738145" }, { "email": "skoranda01 at example.nil", "http_etag": "\"f0f28c1c6a925a595269d3fe21ef7fc1515d7670\"", "original_email": "skoranda01 at example.nil", "registered_on": "2017-11-20T16:46:20.941262", "self_link": "http://mytestbed.com:8001/3.1/addresses/skoranda01 at example.nil", "user": "http://mytestbed.com:8001/3.1/users/e57ecfd0c0c74a319ac958b18882a6d8", "verified_on": "2017-11-20T16:46:20.941595" }, ], "http_etag": "\"89c46bd312c6f1a344e6e6180aed6f11b62e6048\"", "start": 0, "total_size": 2 } Before I submit a pull request I would be grateful for any comments or feedback on the functionality as illustrated above, or any other comments or feedback. I will also begin the "copyright assignment" paperwork as explained at https://wiki.list.org/DEV/Home Thank you for your consideration. Sincerely, Scott Koranda From sca at andreasschulze.de Thu Nov 23 03:00:11 2017 From: sca at andreasschulze.de (A. Schulze) Date: Thu, 23 Nov 2017 09:00:11 +0100 Subject: [Mailman-Developers] Mailman 2.1.25 released / LP#1696066 In-Reply-To: <102d4978-61d0-67ac-d5ed-7c1603c86fd8@msapiro.net> Message-ID: <20171123090012.Horde.N21KTKP3K4rYY1y_UMG2pub@andreasschulze.de> Mark Sapiro: > I am pleased to announce the release of Mailman 2.1.25. Hello, this version contain a fix for LP#1696066 that work for most postfix users. But not for me :-/ postfix know different types of maps: http://www.postfix.org/DATABASE_README.html#types the corresponding files have different suffixes. But the code in Mailman/MTA/Postfix.py handle only .db files while I use cdb. Andreas From barry at list.org Thu Nov 23 11:38:00 2017 From: barry at list.org (Barry Warsaw) Date: Thu, 23 Nov 2017 11:38:00 -0500 Subject: [Mailman-Developers] Time Stand Still Message-ID: <40668691-DBED-4703-B49C-56E309586F52@list.org> Somewhen in the dark recesses of intarweb history, I found myself as the project leader for both Jython (n?e JPython) and GNU Mailman. I'd been involved with Jython since it was invented by Jim Hugunin around the time he came to work with us at Pythonlabs. I'd been contributing to Mailman since we inherited John Viega's Python-based Dave Matthews Band list server, and put it to use replacing python.org's Majordomo installation. I'd enjoyed both projects, but knew I could not lead both, so I had to make a choice. I chose to turn over Jython to a team that's done a much better job over the years than I ever could have. Something about email, and especially the communication and collaboration patterns that it facilitates, really fascinated me. I know, I know, but we all have our lapses of sanity. Mine has lasted almost 20 years, a bit more than "momentary" perhaps. I've rarely gotten paid to work on Mailman, but it did provide me some great opportunities. Most notably it led to my 10 year stint at Canonical. I was originally hired on there to integrate mailing lists with Launchpad, and Mailman was the obvious choice. I learned a ton doing that project, and working within the constraints of integrating the two Python-based systems, especially since Launchpad was originally not free software and Mailman was GPL'd. Later, the Zope-based Launchpad source code was released under the AGPL, making much of the monkeypatching unnecessary, but by then the system was solid and reliable, and you don't fix what's not broken. Except, I guess I did. I took a lot of the lessons from that work, along with a good hard look at all the problems with Mailman 2, and began to break another cardinal rule of software development: second system syndrome. The result is Mailman 3. It took forever, and we're still not at complete feature parity with Mailman 2, but at least it's Real Enough to be used at many Real Sites, including python.org and lists.fedoraprojects.org. It would be ridiculous for me to take significant credit for this. I have to acknowledge the amazing user community -- you! -- for all the support, patches, suggestions, feedback, patience, criticism, donations, and contributions that you've given to the project, and to me personally over the years. And my deepest gratitude goes to all the core developers that have stayed or come and gone, but most especially the current Cabal: Abhilash Raj, Aurelien Bompard, Florian Fuchs, Mark Sapiro, Stephen J. Turnbull, Terri Oda. You should know that each and every one of them is truly awesome, both in what they contribute technically, and in their amazing friendships. Mailman is infinitely better because of their involvement, and I've loved spending time with them over the years at the Pycon sprints, making releases and sharing teas and meals. My blog is called We Fear Change, and that's humorously taken from a 90's bit in Mike Myer's excellent Wayne's World movie (a phrase actually uttered by the brilliant Dana Carvey as Garth). The irony of course is that while we all may fear change, it's the one constant thing we can count on. And in fact, we *require* change to thrive, because if you aren't changing, you aren't alive. Time, and being engaged with life's vagaries, means there's no alternative to change; it must be embraced. And so, with a vague reference to the many (good!) changes in my personal and professional life, I'm announcing that I'm stepping down from the project leadership role of GNU Mailman, effective... nowish! And it's with unanimous agreement among the GNU Mailman Steering Committee (a.k.a. the Mailman Cabal), that we are announcing Abhilash Raj as the new project leader. If you don't recognize Abhilash's name, you probably aren't paying attention, at least to Mailman 3. Abhilash came to us in 2013 as a Google Summer of Code student, and he's become one of the project's most valuable contributors. His list of accomplishments is long, and it includes everything from redesigning the website, to integrating CI with our GitLab build system, porting our code to the SQLAlchemy ORM, adding MySQL support, revving up adoption through his Docker images, along with his great coding work on Core, Postorius, HyperKitty, and mailmanclient. This transition is good for the project too. Email, its defining protocols and standards, and its role in our daily lives, has changed profoundly since the early days of Mailman. A fresh perspective and enthusiasm will help keep Mailman relevant to the changing ways we -- especially the FLOSS and tech communities -- communicate. Please join me in supporting Abhilash in every way possible as he takes over in this new role as project leader. I'll be here when and if needed, even as I create space in my "spare" time for... Something Else. I look forward to the vision that Abhilash will bring to the project, and I know that he will do a great job. To me, Mailman has always been about collaboration, and the best way for it to succeed is for you to continue to contribute your insights, experiences, opinions, and skills with positive intention. -Barry https://www.wefearchange.org/ -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 833 bytes Desc: Message signed with OpenPGP URL: From mark at msapiro.net Thu Nov 23 12:53:44 2017 From: mark at msapiro.net (Mark Sapiro) Date: Thu, 23 Nov 2017 09:53:44 -0800 Subject: [Mailman-Developers] Mailman 2.1.25 released / LP#1696066 In-Reply-To: <20171123090012.Horde.N21KTKP3K4rYY1y_UMG2pub@andreasschulze.de> References: <20171123090012.Horde.N21KTKP3K4rYY1y_UMG2pub@andreasschulze.de> Message-ID: <7f11e0aa-4adf-db0a-d866-0a86e464587c@msapiro.net> On 11/23/2017 12:00 AM, A. Schulze wrote: > > this version contain a fix for LP#1696066 that work for most postfix users. > But not for me :-/ > > postfix know different types of maps: > http://www.postfix.org/DATABASE_README.html#types > the corresponding files have different suffixes. But the code in > Mailman/MTA/Postfix.py > handle only .db files while I use cdb. Thank you for the report. See and . I have fixed the code to not throw OSError if there is no .db file, but I don't attempt to change group and mode of .cdb or other non-.db table types. This basically reverts the situation to pre-2.1.25 for those types. -- Mark Sapiro The highway is for gamblers, San Francisco Bay Area, California better use your sense - B. Dylan From andrew.stuart at supercoders.com.au Thu Nov 23 15:16:43 2017 From: andrew.stuart at supercoders.com.au (Andrew Stuart) Date: Fri, 24 Nov 2017 07:16:43 +1100 Subject: [Mailman-Developers] Time Stand Still In-Reply-To: <40668691-DBED-4703-B49C-56E309586F52@list.org> References: <40668691-DBED-4703-B49C-56E309586F52@list.org> Message-ID: <7998FF7C-39AF-4241-9F6F-FBB92B1C1642@supercoders.com.au> Thank Barry for Mailman and your many years of dedication. I certainly learned much about Python, programming and leadership from Barry during my brief time involved with Mailman. Any chance of some sort of ?technical retrospective? blog post on the project journey talking about where it came from and how it evolved technically, your guiding philosophies running such a project the principles upon which the software is built etc? Congratulations Abhilash on an exciting opportunity and an affirmation of your skills and dedication - looking forward to seeing where you take things. Andrew From geneshuman at gmail.com Tue Nov 28 18:44:54 2017 From: geneshuman at gmail.com (Gene Shuman) Date: Tue, 28 Nov 2017 15:44:54 -0800 Subject: [Mailman-Developers] ARC PR for Mailman 3 Message-ID: Hello all, Over the past few months I've developed an patch for Mailman 3, giving it ARC email authentication capabilities. The work is (99%)completed, and it just needs somebody to do a final review of the ARC functionality itself so I can implement any requested changes. I had been working with Barry Warsaw, who had done a preliminary stylistic review, and subsequently, I've eliminated all raised issues. The branch is rebased as of last week, and passes all of qa, except one instance, which is something I'd like to discuss with somebody.(It fails a style test for line lengths in a test file which contains a bunch of cryptographic hashes) . Aside from that all qa pipelines pass. Also, there is a decent amount of included documentation, but it could still use a bit more work. I'm planing on doing right before the branch is merged, and maybe with some additional guidance of the community. So, in communicating with Barry, it seems he doesn't have the time to continue working on this with me. So, I'm reaching out to see if there is anybody with the interest and availability to review the PR. It's not particularly complex, and just introduces 2 new handlers into the pipeline. Thanks & Regards, =Gene Shuman PS. The PR uses a library dkimpy with code that I wrote which passes the ARC reference test suite(which I also wrote) 100%. So all of the cryptographic signing & validating in the PR validates against the current rfc of the protocol. So the crypto can be largely ignored. However you can easily test this functionality by sending ARC signed messages to say gmail, which does ARC validation, & looking at the headers. From skoranda at gmail.com Wed Nov 29 07:48:14 2017 From: skoranda at gmail.com (Scott Koranda) Date: Wed, 29 Nov 2017 06:48:14 -0600 Subject: [Mailman-Developers] 3.1.x REST API enhancements around preferred email address In-Reply-To: <20171120172013.GC33354@paprika.localdomain> References: <20171120172013.GC33354@paprika.localdomain> Message-ID: <20171129124814.GA123978@paprika.localdomain> Hello, Just a gentle 'bump' to see if anyone has any feedback on the proposed REST API changes below or if I should submit a pull request? Thanks, Scott K > Hello, > > I am interested in contributing enhancements around preferred address > to the REST API for version 3.1.x. > > To prove out my use case(s) and familiarize myself with the code I have > made changes already. Here are some example curl command line > invocations and output to illustrate: > > 1) Create an address for an existing user and mark that address as the > user's preferred address: > > curl -u restadmin:restpass \ > -X POST \ > -d email=skoranda at example.nil \ > -d preferred=1 \ > http://mytestbed.com:8001/3.1/users/e57ecfd0c0c74a319ac958b18882a6d8/addresses > > This returns a '201 Created'. > > 2) Return the preferred address, if set, for a user: > > curl -u restadmin:restpass \ > -X GET \ > http://mystestbed.com:8001/3.1/users/e57ecfd0c0c74a319ac958b18882a6d8 | python -m json.tool > > { > "created_on": "2017-11-11T22:20:45.950949", > "display_name": "Scott Koranda", > "http_etag": "\"26bc0d9f21eb145248884aedae4c1ffd00b608d2\"", > "is_server_owner": false, > "password": "$6$rounds=656000$gWGfwpajfZ7rVn5O$Sl559B2TgtpJWXA2i67G5ukjzkV6iTp4NgP.6FJpMFMUTDdDXULAmwdN8YW92w87EdctgqFqAUkUqS6.EOTCz/", > "preferred_address": "skoranda at example.nil", > "self_link": "http://mytestbed.com:8001/3.1/users/e57ecfd0c0c74a319ac958b18882a6d8", > "user_id": "e57ecfd0c0c74a319ac958b18882a6d8" > } > > 3) Update/patch a user to set a preferred address: > > curl -u restadmin:restpass \ > -X PATCH \ > -d preferred_address=skoranda at example.nil \ > http://mytestbed.com:8001/3.1/users/e57ecfd0c0c74a319ac958b18882a6d8 > > This returns a '204 No Content'. > > 4) Get all addresses for a user with the preferred address (if set) having > the attribute 'preferred' set to 'true': > > curl -u restadmin:restpass \ > -X GET \ > http://mytestbed.com:8001/3.1/users/e57ecfd0c0c74a319ac958b18882a6d8/addresses | python -m json.tool > > { > "entries": [ > { > "email": "skoranda at example.nil", > "http_etag": "\"492824d150f9f11e32d530d3cad0f76422bddb48\"", > "original_email": "skoranda01 at example.nil", > "preferred": true, > "registered_on": "2017-11-13T22:35:17.232180", > "self_link": "http://mytestbed.com:8001/3.1/addresses/skoranda at example.nil", > "user": "http://mytestbed.com:8001/3.1/users/e57ecfd0c0c74a319ac958b18882a6d8", > "verified_on": "2017-11-20T16:48:51.738145" > }, > { > "email": "skoranda01 at example.nil", > "http_etag": "\"f0f28c1c6a925a595269d3fe21ef7fc1515d7670\"", > "original_email": "skoranda01 at example.nil", > "registered_on": "2017-11-20T16:46:20.941262", > "self_link": "http://mytestbed.com:8001/3.1/addresses/skoranda01 at example.nil", > "user": "http://mytestbed.com:8001/3.1/users/e57ecfd0c0c74a319ac958b18882a6d8", > "verified_on": "2017-11-20T16:46:20.941595" > }, > ], > "http_etag": "\"89c46bd312c6f1a344e6e6180aed6f11b62e6048\"", > "start": 0, > "total_size": 2 > } > > Before I submit a pull request I would be grateful for any comments > or feedback on the functionality as illustrated above, or any other comments > or feedback. > > I will also begin the "copyright assignment" paperwork as explained at > > https://wiki.list.org/DEV/Home > > Thank you for your consideration. > > Sincerely, > > Scott Koranda