*Action Items*

New
[AI] {Paul, Serge and Olivier} will begin developing a list of generic topics addressing spam and mailing list management software.
[AI] {SteveO} will gather email policy links from survey responses and incorporate them on the WG’s web site.
[AI] {Jill} will notify EDUCAUSE of Mailing List survey results to be placed in the EDUCAUSE library.
[AI] {Jim} will incorporate Sympa developers’ comments into the WG’s models.

Carry Over
[AI] {John-Paul} will prepare discussion points for Mailman discussion.
[AI] {Jill} will solicit topics from the WG for a potential WG output session at the Spring I2 Member Meeting, and will request for WG output session at Spring I2 Member Meeting.
[AI] {Jim} will follow up on status of UW-Madison and INQ.
[AI] {John-Paul} will work to find someone interested in packaging and maintaining Sympa for Fedora Core.
[AI] {Jim and John-Paul} will discuss local-interface preference storing of attributes. And, will send a brief summary of the discussion to the WG via the list.
[AI] {SteveO} will gain a better understanding of Sympa documentation and translation requests and coordinate follow up w/ Renee and Jill.
[AI] {Jill} will develop VO survey distribution list, and will follow up with NSF and DOE for possible VO survey candidates.

*Attendees*
Jill Gemmill, UAB (Chair)
John-Paul Robinson, UAB
Serge Aumont, Comité Réseau des Universités (FR)
Olivier Salaun, Comité Réseau des Universités (FR)
Jeff Eaton, Carnegie Mellon University
Jim Phelps, University of Wisconsin – Madison
Terrie Clark, Internet2
Lisa Hogeboom, Internet2
Steve Olshansky, Internet2

*Discussion*
Sympa developers joined the WG’s call. Topics of discussion follow:

The description of Message Authentication Signature Standards (MASS) – The IETF definition can be found at http://www1.ietf.org/proceedings_new/04nov/mass.html. An additional article from Network Magazine discussing Domain Keys and MASS can be found at http://www.networkmagazine.com/shared/article/showArticle.jhtml?
articleId=52600292&classroom=

The WG’s Domain model closely matched the Sympa model except in the cases of authorization, authentication and message sanitization. The Sympa model uses both user attribute and user authorization to determine who can send certain messages and to determine the size of messages to be sent and to determine the size of the message to be sent. Sympa does not check user authorization and message properties separately in sequence. The authorization process uses sender attributes, sender authentication and message attributes to determine message handling (i.e. send, moderate or distribute). This concept does not easily fit into the MList Domain model. Both models similarly present web interfaces and mail interfaces to authenticate users, administrative features and subscription features. The group discussed incorporating message sanitization and authentication or authorization as a potential middleware application. Additional services such as message signing services may also be middleware enabled. Sympa considers the sender of the message to be one attribute of the message. In considering messages that do not associate a rule with a user, all information about the message is distributed through the message routing service. Sympa’s message sanitization can be viewed as an external process. If a function is entirely internal to an application, then it is not considered middleware enabled. Likewise, if rules are externally stored, then a middleware solution is required for the function.

The “publish list” function facilities publishing the list to internal and external applications once changes or updates have been made to the list. The Sympa developers commented that perhaps the domain model should include a message bouncer function addressing the following questions: How will the MList model manage subscribers - via attribute? Or, via automation? If we define list membership how then do we convey errors? Does the error remain with the mailing list? And, will the mailing list software suspend errors automatically in certain cases? How does mailing list software handle bounced messages and removal from the mailing list? The bounce error is separated into two functions that should be distinguished in the model. The first is to analyze the bounced message. The second is to determine actions (if any, remove from list, alarm list owner, etc.) for the related list member.

In addition to being a major issue for mailing service software, spam is also a major issue for mailing list management software. Mailing list management software does not protect email addresses from Spammers. Nor does mailing list management software prevent spammers from collecting email addresses. Sympa has been asked to provide the original subscription information along with all technical information to verify that messages originating from Sympa are not spam. Considering that mailing list servers can be placed on ISP blacklists, it will become important to contact ISPs to allow for message transmission if wrongly added to a blacklist.

The WG desires to have a reference document for handling signed email messages. Perhaps the PKI technical WG (HEPKI-TAG) can assist.

The mailing list survey summary is complete and has been posted on the WG’s website. The high-ed e-mail admin mailing list has been notified with a solicitation for comments.

The next call is Wednesday, February 2, 2005 at 12:00PM ET. A new, permanent call in number will be distributed with the agenda prior to the call.