Grouper Users - Open Discussion List

[Peter DiCamillo <>]

At Brown we use both Listserv (http://www.lsoft.com/products/listserv.asp)  and Sympa (http://www.sympa.org) for mailing lists. In general, we use Listserv for ordinary mailing lists, but use Sympa for group-based lists, due to advantages Sympa offers when using groups. Sympa lists can having regular subscribers who add or remove themselves, or are added or removed by an administrator. Subscribers can also come from an include file, and subscribers can come from specifying an LDAP filter _expression_ and mail attribute. The LDAP support works well with typical Grouper isMemberOf provisioning. These types of subscribers can co-exist for the same list, and Sympa keeps track of the source of a subscriber. As a result, subscribers who are added from file inclusion or from LDAP are not allowed to unsubscribe. With respect to list settings, Sympa supports "families" of lists that are created from a settings template. Settings in the template can be specified as modifiable or not modifiable by list administrators. Settings that are not modifiable don't show up when admins use the UI to manage the list. An example of settings that could not be modified would be the LDAP filter and mail attribute.

Currently we use Sympa for community mailing lists and for course mailing lists. An example of a community mailing list would be brown.community.all. It might be used if a high-level administrator wanted to send email to the entire campus. Course mailing lists are used by instructors and TAs to communicate with their students. In these cases, the membership is maintained by provisioning from Workday and Banner to Grouper, and then to LDAP. We wouldn't want members to be able to unsubscribe. We are investigating additional, more general uses of group-based lists, as Steve Carmody wrote about.

Peter

On 11/16/15 3:34 PM, Julio Polo wrote:

Definitely, mailing list integration opens a new can of worms.  We provide an option for groups to be synchronized with a respective LISTSERV mailing list, and we have observed that people tend to unsubscribe themselves from mailing lists, even if they've never received email from that mailing list.  The group admin needs to be alerted of such discrepancies, and currently, the only viable option is to remove the person from the Grouper group.  I can imagine there may be scenarios where a person needs to remain in the group (for AuthZ purposes) but can be off the mailing list.  There may also be use cases where it's unacceptable for someone to unsubscribe from a mailing list (though that's probably a losing argument if you engage with the subscriber).

We have also encountered the external email subscriber issue (where the email address cannot be derived from a subject in Grouper).   For now, we track these external email addresses in a file associated with each group that syncs to a mailing list.  The same goes for any mailing list configuration settings (LISTSERV headers).  We need to control certain LISTSERV header settings in order to handle errors associated with the group-to-mailing-list sync, but we also want to allow the group and/or mailing list admin to choose how their list will behave (e.g. is it moderated?  who can send to the list?).   We currently address this by taking over the administration of the LISTSERV headers; any changes have to go through us.  This won't scale, so we'll eventually need a better way to address this and the many other issues that come with integrating Grouper groups with external group repositories.

-julio

Julio Polo
Enterprise Middleware, Identity and Access Management
Information Technology Services
University of Hawaii

On Fri, Nov 13, 2015 at 10:44 AM, Jeff McCullough <> wrote:

This question is both for other schools as well as the grouper team. As we look further at an integration with Google Groups, there are several mailing list options to think thru. There are the issues of external identities and options for requesting/subscribing/leaving a group (those standard mailing list functions). If we want one group source, grouper, that pushes groups to all the campus services, then grouper may need to have extra functionality. If you have mailing list service, aka mailman, the ability to add any email to a list is standard, send email to confirm are standard features. One can also request to be added to a list. Subscribing/leaving are also standard, and grouper already has those features in opt-in/opt-out permissions. When it comes to sending email, I know it is possible to have grouper send email when someone is added/removed from a group, but that is more a confirmation that the event happened rather than a confirmation cycle where the person being added is confirming they want to be added by replying or following a link. I’m not suggesting that the confirmation cycle be there in groups, but noting it is a standard feature of mailing lists. Lastly, when it comes to sending emails, there are times when sending an email might be confusing or unnecessary, so having a way to signal to the system that we want an email sent is useful.

For any school that has made a conversion from a regular mailing list to Google Groups, how did you had those features above? Did you find work arounds or just decided they were not going to be available. For the grouper team, I’m wondering if there has been any design discussions around including email features and the ability to create an identity or to just include an external email account in a group. I know that last one has all sorts of issues, but just want to get a sense of direction. There are the external identities which have an invite process and there are the general external identity features offered through vendors like Cyrius Identity. There isn’t the ability to just add an external identity when that might be useful.

Thanks,
Jeff