Current Status
Standard Review
Additional sponsor responses posted 9/1/2009
IET: Mailing List Replacement
Since 1993, UC Davis electronic mailing lists have been managed with an application called Listproc. Originally developed by an organization which has since dissolved, Listproc is now unsupported and essentially obsolete. This project is intended to replace Listproc with a modern mailing list management application, and to examine and update the associated mailing list guidelines used by campus customers and administrators.
Sponsor
Information and Educational Technology (IET)
Contacts
- Project Manager
- Jatinder Singh
To View Entire Submission
Reviewers
Core contributors to this review included Thomas Amsler (IET), Pamela Davis (School of Education), Bob Ono (IET), and David Walker (IET). Comments and discussion were also solicited via the Dean’s Technology Council (DTC), Technology Infrastructure Forum (TIF), and other similar venues.
Feedback Received to Date (9/1/2009)
Revision History
- 7/24/09
- Initial feedback and sponsor responses
- 9/1/09
- Additional sponsor responses posted
Contents
- Reviewer Observations and Comments
- Reviewer Suggestions and Advice
- Questions, Potential Gaps, and Requests for Clarification
- Campus IT Architect Review
- Campus IT Security Coordinator Review
Reviewer Observations and Comments
Reviewers agreed that a Listproc replacement was definitely needed. Comments focused on the range, features and limitations of potential candidate solutions.
Reviewer Suggestions and Advice
Google Groups/Google Wave
One reviewer recommended the consideration of a third alternative, as follows:
Even though the currently selected Listproc replacements, Mailman and Sympa, are good candidates, I would suggest a look at Google Groups. Google Groups may even be part of the currently used Gmail/GoogleDocs/etc. student services. Another project that's emerging and getting a lot of attention is Google Wave, which should be released by the end of the year.
The benefits of using any of these Google projects would be quite significant:
- Google hosts these services, so there should be no hosting/maintenance/etc. costs. If there are any service fees, they would be at a very competitive rate.
- Both of these services provide industry-leading REST APIs, which allow for easy integration.
- Google services scale well.
Sponsor: Google Groups has some of the functionality of a mailing list program, can be used to share resources in a designated group, and is compatible with Usenet news, but it currently lacks the rich features and community support of Mailman and Sympa. It would be more viable as a candidate to replace InterNet News (a Usenet news server package) than Listproc. Google Groups occupies a different product space, and lacks the rich features and community support of Mailman and Sympa.
Google Wave, at this point in its development, acts more like a messaging client than a fully functional mailing list manager. Further, a limited public beta testing of Google Wave isn't slated to begin until Sept. 30, and Listproc's replacement requires some degree of maturity and adoption in the higher education market.
At some point in the future the campus will again need to evaluate mailing-list software, and perhaps by then Google Wave and/or Google Groups will be more mature and competitive with other classic dedicated products.
Questions, Potential Gaps, and Requests for Clarification
Scalability
Do the candidate solutions have a record (number of lists) limit? Will you load-test the programs during the testing phase? The recommendation that the system must be scalable and sustainable must not be lost in the "feature richness" of the new listserv.
Sponsor: During the product-scoring phase, two categories addressed these issues: Architecture, which addresses scaling, and Support, which includes sustainability. Each category represents 10 percent of the total scoring criteria. Among other questions, the sustainability category asks if the product has good support, and if the product is run at many educational institutions (some operate more lists than UC Davis does). The proposed architecture is a high-availability design that includes two cross-connected servers and two storage arrays, similar to the architecture for the campus Cyrus email servers.
We will load-test the candidate application before the service is rolled out.
API
Any Listproc replacement candidate should have a REST and/or SOAP API so that its services can be easily integrated with existing IET and other campus projects.
Sponsor: The API is addressed in the Architecture section of the selection criteria. Sympa does have a SOAP API
Campus IT Architect Review
As another reviewer observed, there are multiple tools available and that will be available in the near future. The space of collaboration tools is evolving rapidly right now, and it's hard enough to know what to support today, let alone in the future. That said, there are commonalities among these tools that we can leverage to avail ourselves of new tools and services as they become available. In particular:
- All of these tools need to know who the members of a collaborating group are;
- The scope of the community served by the authentication method chosen should be as broad as possible.
(I've written some thoughts about this at https://confluence.ucdavis.edu/confluence/x/qYDb.)
With respect to the mailing list replacement proposal:
- The ability to integrate with LDAP-based group management services provided by the Identity and Access Management (IAM) project should be a requirement to enable sharing of group definitions with other services.
- For authentication, UC Davis' CAS service should be invoked via Shibboleth, rather than directly, to increase the scope of the community served.
- Future integration with COmanage (http://middleware.internet2.edu/co/) should be considered as part of the evaluation.
Sponsor: The project assumes that LDAP attributes will identify members of a collaborating group, and this aspect of the mailing list service can mature as the new IAM project matures. Dynamic list generation, authentication, and the use of LDAP and CAS are addressed in the Integration section of the scoring criteria.
COmanage recognizes Sympa as a product that integrates with its framework.
We will implement CAS or Shibboleth authentication as appropriate, based on consultation with IET Middleware.
Campus IT Security Coordinator Review
The campus will benefit from the replacement of the current mailing list system. Some clarification within the main document and evaluation scoring protocol would be helpful, particularly in the following areas:
Infrastructure integration: The campus Identity management solution is projected to be in production during the spring of 2010. The mailing list document could be enhanced to discuss how a new mailing list application could take advantage of the identity management services that will be available through Sun Identity Manager Suite.
Sponsor: The new application will work well with the new campus ID management solution. When the Sun Identity Manager Suite goes into production, the new mailing list software should be able to use CAS to authenticate UC Davis account holders, and LDAP to identify and update groups for mailing lists.
Privacy: The scoring protocol should include the capability to establish default settings. For example, it is preferable that a mailing list solution permit the establishment of default restrictive privacy level with the capability for the list administrator to change the privacy level to a less-restrictive category.
Sponsor: As part of its review of mailing list use guidelines, the project workgroup will select default settings for the list administrator and end-user parameters, and we can ask that those settings reflect a restrictive privacy level. A list administrator could still change those levels for a given list, as desired.
Privacy is rated as part of the security category in the scoring documents.
Software application security issues: The document discussion on security could be expanded to address three different but related issues. The first issue concerns mailing list application software compatibility with the availability of critical security patches for supporting systems, such as operating system and database. It is essential that a development community/function is available to ensure that vendor security patches do not interrupt production mail list services.
Sponsor: The software patch history for critical security patches will be examined during the scoring of the mailing list packages in the security section entitled “software application security issues addressed in a timely manner.”
Patches will be tested in our mailing list test server before being applied to our production service. Nothing will be added until it has been tested, which should minimize the interruption of services when patches are applied.
The second issue concerns whether the mailing list application developer maintains a support structure for acceptance of security vulnerability customer reports and has the capability/commitment to release application updates in response to reports of high severity security vulnerabilities. This service helps to maintain the integrity and availability of a mail list service.
Sponsor: Both candidates seem to maintain the necessary support structure to accept reports and release updates.
The third issue concerns the mailing list application use of a security testing protocol as part of the development cycle. This security integration will help preserve the integrity, availability and privacy/security settings of a mail list service.
Sponsor: Security administrators will verify the security of the web interfaces via Appscan as part of any major upgrade test cycle for the mailing list application.
List passwords: Weak list passwords could permit unauthorized individuals to change privacy/security settings of established lists. The scoring protocol should be expanded to evaluate list capability to meet the more stringent password standards or integrate list administration with CAS authentication. The document identifies CAS integration as a requirement but does not discuss the scope of integration.
Sponsor: Access to list management functions will be allowed only when the user authenticates via CAS; using passwords in plain text files won’t be sufficient.
Anti-Virus: While the document references a requirement for SpamAssassin, it does not mention an anti-virus integration requirement. The campus mailing list must not become a virus vector and the scoring protocol must include anti-virus integration.
Sponsor: All messages are routed through the campus mail routers and clamAV before being routed to mail list server, so anti-virus is already part of the process. SpamAssassin integration allows for customizable thresholds by the list owner, giving the list owner the ability to determine the spam threshold for their list. The ability to remove individual messages from mailing list web archives (for security or any other reason) will be scored during the review.