Adding a slightly different perspective to Abhilash's and Barry's.
ddw David Wilson writes:
From my perspective of being an senior (ie overaged) person desirous of implementing fully-featured, capable, scalable, reliable, secure
I'm not sure if "secure" is a real requirement, a nice-to-have, or intended as a compliment to Mailman, but "secure" is not something we can claim. Mail is inherently a security problem, because there is no universal way to authenticate senders. It's possible under certain conditions to configure a system to be secure in the sense of allowing only authentic senders, but even when possible it is not easy. Ask John Podesta (for a well-known example) or Matt Tait (aka Twitter's @pwnallthethings, a security expert who has publically admitted that he's come "this close" to clicking on spear-phishing attachments).
Mailman itself is a complex application with a very large attack surface. If containerized, it will be rather difficult to exploit the rest of the system, but Mailman itself contains a lot of private data (email addresses and associated display names, which are frequently real names), and in enterprise situations may have access to enterprise databases "containing the whole store".
applications such as Mailman, I am convinced that I am thoroughly over my head.
That's what we're here for! Of course we're volunteers, so our availability is less than 99% reliable and time is limited. I don't know of any consulting services providing Mailman 3 consulting yet, but given the activity of this list I believe we'll see them soon. If you have funding to offer and want to kickstart the process, you could go to the vendors page on our website and talk to some of them.
From my limited perspective, it would seem to me that a 'nice to have' system would incorporate the following.
- An open container standard configurable system install, compatible with different web & mail servers, DB utilities, etc;
We have a container system which is configurable. However, IMHO "standard" and "configurable/compatible" are incompatible goals. What we can reasonably provide is a full system-in-a-box for people who only want to configure Mailman itself (ie, add lists and users, and configure their settings in the web interfaces). For people with specific desiderata such as a particular mail transport agent or web server different from those provided by our "Mailman-3-in-a-box", they're going to need somewhat advanced sysadmin skills for the forseeable future because the configuration requirements of web services and mail services must be coordinated, and have subtle, implementation-dependent interactions.
We hope that the vendors referred to above (including mail hosts, mail consultants, and system management framework vendors like cPanel) will soon start providing more "Mailman 3 in a box" services (both software distributions and as VMs in cloud services), as well as consulting services for those with specific needs not served by existing containerized versions.
- Python 3 version Django utilities for archiving and mail list name management;
In progress.
- A design/plan from an inside expert perspective stating costs, time and resources to implement the plan, incorporating crowdfunding to pay for project.
We don't have spare cycles at the moment. None of us actively consult for money on Mailman, which means neither direct engineering capability nor management capability are available. I'm considering this, but since I'm currently a life-long academic with a full-time job for the next few years, I'm not in a big hurry, and would need to acquire skills/partners for the aspects I've no experience in. :-) (I guess that's :-( from your perspective.) With a two-year timeline, if I decide to do it, likely I'd actually open for business in about 1.5-2 years (based on seasonal cycles in free time). I don't know offhand of anyone else even thinking about it.
This could change at any time with entry of new developers, of course, but it's only fair to warn you that this is the current status.
- As a backup incentive to the crowdfunding plan might be the offer of an expert to set up a system for each significant amount donated, say US$1,000, such as might be accomplished by an SSL session on the target computer/server after the user has specified all necessary detail as required in a template.
We do have ways to donate via our relationship with the FSF, but the same issues described above (no reliable gobs of available time for project oversight or actual development) apply.
I am sure that the program author and other major contributors could greatly enhance this list.
In summary, I guess what I am requesting is an overview forecast by half year period and out for the next two years?
For 6 and 12 months out, Abhilash's summary list, and Barry's, all are goals I support. We should also have a plug-in implementating the ARC protocol which improves authentication capabilities by allowing a list's subscribers (more precisely, their mail hosts) to extend transitive trust to senders that the list has authenticated. Although providing such authentication services *in Mailman* is suboptimal and sometimes impossible, we can provide containerized Mailman with that service.
Steve
-- Associate Professor Division of Policy and Planning Science http://turnbull/sk.tsukuba.ac.jp/ Faculty of Systems and Information Email: turnbull@sk.tsukuba.ac.jp University of Tsukuba Tel: 029-853-5175 Tennodai 1-1-1, Tsukuba 305-8573 JAPAN