Jill Gemmill, University of Alabama, Birmingham
John-Paul Robinson, University of Alabama, Birmingham
HTML: Coming Soon
PPT: Coming Soon

Discussion Points

Jill Gemmill began the discussion with the group by stating the deliverables of the group.

As a new working group in Internet2, the group’s deliverables are:
· Design and conduct survey resulting in documentation detailing the higher education community’s needs for middleware-enable list management;
· Develop a model of mailing list management software operations identifying middleware-enabled attributes;
· Implement one open source prototype utilizing federated authentication, authorization and identification; and
· Develop documentation for developers on how to middleware-enable list management.

John-Paul Robinson led the group’s discussion on defining a list, the purpose of a mailing list, the list’s expected features, how a group is used in the context of list management and how a list is used.

The two most audible concerns of the group regarding list management are list integrity and list privacy. The center of both concerns is spam management. Is the list breakable? Will it help prioritize incoming mail? Can the list be cracked and e-mail address given to spammers? Will identity be compromised? Several individuals within the group mentioned using various e-mail addresses to manage spam and to prioritize e-mails. When some e-mail address accounts become full, the account is terminated and a new account is established. An additional concern is list-spamming overloading an institution’s servers. Is middleware-enabled list management the correct tool for spam management?

Privacy issues encompass knowledge of e-mail sender and knowledge of e-mail recipient. For example, the registrar sending an e-mail to students enrolled in a specific class where the registrar is prohibited from knowing the students’ identity. Also, how is privacy requested and granted? Finally, who can see the list of members? It was suggested that these functional features of the list could be enabled by Shibboleth and PKI to provide guidelines for feature management by application, list manager or the end user.

The group advocated further definition of:
· The purpose of a mailing list, the list’s expected features, the purpose of a group in the context of list management, and how a list is used;
· The functional features of the list and where/how the features are managed (i.e. application, list manager or end user); and
· Policy definitions.

What must happen to make middleware-enable list management transparent to the end-user? And, what are the issues facing higher education institutions with middleware-enabled list management? What kind of interfaces are necessary for middlewareenabled list management? E-mail, web, IMAP, NNTP and private mailboxes. Do other interfaces exist?

From a technology perspective what integration points exist? LDAP, Shibboleth and PKI are readily apparent examples Do other integration points exist?

The group considers developing use cases addressing:
· White/black lists in group applications;
· The functional features of the list and where/how the features are managed (i.e. application, list manager or end user); The functional features are derived from authentication and authorization;
· The integrity of the list. Is the list breakable? Will it help prioritize incoming mail? Can the list be cracked and e-mail address given to spammers? Will identity be compromised?;
· Privacy issues: Knowing or not knowing who is receiving mail. Knowing or not knowing who sent the e-mail. Requesting privacy. Who can see the list of members?
· Interfaces; e-mail, web, IMAP, NNTP and private mailboxes.
· Integration points: LDAP, Shibboleth and PKI