Directory Group Expiry Policy

This document describes the renewal and expiry policies for groups in the MCommunity Directory.

Policy Summary

When a group is created, its expiration is set to a year from the date of creation. If the group is still effective or active at that point, the group owner(s) must renew it.

Groups that are not renewed before the expiry date will be "disabled"- no entry or activity will be possible within the group. An expired group remains in the directory in a disabled state for one year. During that time, the group owner(s) can renew it. Expired/disabled groups are deleted from the directory one year after they expire, unless they are renewed.

Group Expiration Steps

1. When a group is created, it is set to expire one year from the date of creation.

   Group owners can renew the group at any time. See the Renewing Groups section of Managing Groups that You Own in the MCommunity Directory for renewal instructions.

2. Ninety days before a group should expire, an email renewal notice is sent to the owner(s) through email. Group owners must have a valid mail forwarding address in their directory entry in order to receive renewal notices. A group owner can then choose any of these options:

   • Renew the group (see renewal instructions in group ownership documentation).

   • Allow the group to expire on its original expiration date.

   • Delete the group if it is no longer needed (see deletion instructions in group ownership documentation).

   The text of the 90-day notice is provided at the end of this document (Appendix: Text of the 90-Day and 30-Day Renewal Reminder Notices).

3. Thirty days before a group should expire, a final renewal reminder notice is sent to the owner(s) through email. Group owners must have a valid mail forwarding address in their directory entry in order to receive renewal notices.

4. The group is disabled on its expiration date. Disabled groups no longer work. Mail sent to a disabled group will be returned to the sender. If a disabled group is used to control authorization (for access to a website or wiki), the authorization will fail. The group's directory entry will be marked "disabled."

   The text of the 30-day notice is provided in Appendix: Text of the 90-Day and 30-Day Renewal Reminder Notices.

5. The group will remain in the directory in a disabled state for one year. The owner(s) can renew it during this time. After one year, if it is not renewed, it will be deleted from the directory. Once it is deleted, it cannot be retrieved or renewed.

Note If a group owner is no longer maintaining a group that is still needed by its members, the members of that group can request ownership so that it can be renewed and maintained. Group members who wish to become owners of otherwise abandoned groups can contact the ITS Service Center.

Frequently Asked Questions (FAQ)

1. Why can't we leave groups in the directory forever?

2. What happens when a group expires?

3. Will I be notified before my group expires?

4. If the owners are unreachable, could you notify the members instead?

5. Can you set groups to expire a year after their last use?

6. Can groups be renewed automatically every time a change is made?

7. Did you consider the needs of U-M schools, colleges, and departments in setting this policy?

1. Why can't we leave groups in the directory forever?
   There are several reasons why we want to remove obsolete groups from the directory:

   Spam: Many people are annoyed at the amount of spam they receive as members of obsolete groups. By setting expiration dates, we provide group owners with reminders to check their groups and renew those that are still needed. We provide a method for removal of unused, forgotten groups.

   ITS staff who provide support to users (the ITS Service Center, Postmaster, User Advocate) report that the spam sent to obsolete groups is a significant problem for the U-M community. Users are unhappy with unmaintained groups.

   U-M is periodically blacklisted by major Internet Service Providers (ISPs) because of the quantity of spam going to members of obsolete groups. When this happens, the ISP stops accepting mail from @umich.edu addresses that is sent to its members.

    

   Group names: A number of obsolete groups use names that members of the university community would like to use for new groups.

2. What happens when a group expires?
   When a group expires, it is disabled. It ceases to function in all ways except one—if you search the directory for the group by name, you will find it. The entry will indicate that the group is disabled.

   Mail sent to a disabled group is returned to the sender as undeliverable. If the group is being used for authorization (such as for access to websites or account provisioning), the authorization will fail.

   The group owner(s) can renew a disabled group. If a group has been abandoned by the owner but is still needed, the group members can contact the ITS Service Center and ask for a transfer of ownership.

   A disabled group remains in the directory for one year. If it is not renewed during that year, it is deleted from the directory.

3. Will I be notified before my group expires?
   Yes. The group owner(s) will be notified through email twice when the group nears its expiration date:

   • Email reminder notification 90 days before expiration
     Final email reminder notification 30 days before expiration

   The notifications are sent to the email forwarding address(es) listed in the group owner's directory entry. The text of the notices is provided in Appendix: Text of the 90-Day and 30-Day Renewal Reminder Notices.

   During the group creation process, a notice of the group's impending expiration in the absence of renewal is displayed on the group creation confirmation page.

4. If the owners are unreachable, could you notify the members instead?
   It is the group owners' responsibility to manage their groups and to provide a valid mail forwarding address. If a group owner neglects this responsibility and becomes unreachable, a group member can contact Directory Administration ([email protected]) and ask to take on ownership of the group.

5. Can you set groups to expire a year after their last use?
   No. Unfortunately, this is not possible for two reasons:

   1. Information about email timestamps (basically a look-up of the members' mail forwarding addresses at the time of mail delivery) is not logged. There is no way to know when mail was last sent to a directory group.

   2. Even if this information were logged, there would be no way to know whether the message last sent to the group was spam or legitimate mail.

6. Can groups be renewed automatically every time a change is made?
   Automatic renewals would be inconsistent. The process that evaluates groups for renewal and expiration runs once a day. When a change is made to a group, the uniqname and associated tiemstamp are recorded. If another change is made before the process runs, the change is made, and the information is overwritten. Therefore, the process only retains the unqiname and timestamp of the final change.

   Consider these examples of the inconsistent results that could occur:

   • Various programs make changes to groups that would, but should not, trigger renewal. Such changes include a member uniqname change or removal of a member from the directory.

   • Imagine that a large group of students (most of whom are now alumni) has become obsolete. Periodically, spam is sent to the group. In annoyance, a group member contacts the ITS Service Center and asks to be removed from the group. This removal would show up as a change to the group, and the group would then be renewed automatically—even though the group is obsolete.

   • Some have suggested that automatic renewals only happen if an owner makes a change, but it is not always possible to determine that a change was made by an owner. For example, if an owner makes a change to a group, and, later in the day before the batch process is run, the uniqname program makes a change to a member entry in that group because that person has changed his or her uniqname, the batch process will only see information about the most recent entity (the uniqname program) that made a change. The batch process would not "know" that the owner had made a change.

   • Say that a person owns two groups, one joinable and one not. A member joins the joinable group; the group is changed and is therefore renewed automatically. The owner will likely wonder why the expiration date changes on one group but not the other.

7. Did you consider the needs of U-M schools, colleges and departments in setting this policy?
   Yes. The initial idea for the policy was a response to many requests from the members of the university community to combat the spam issue.

   In the summer of 2006, when the policy was little more than an idea, ITS staff went to the Academic Computing Support Forum (ACSF) and to the MCommunity Governance Board to get their general approval and input before proceeding. Both these groups are made up of representatives from various U-M organizations. ACSF members are mostly information technology staff. They meet regularly to share updates about university information technology. The Governance Board includes representatives from schools and colleges, as well as from business units such as the Registrar's Office and Human Resources.

   A draft policy was presented to both groups in fall 2006. Considerable discussion ensued regarding some of the policy details, such as whether expired groups could be deleted from the directory. Rather than have ITS staff make the final decisions on the policy details, ITCS referred these decisions to the MCommunity Governance Board. The board reached agreement on the policy details in January 2007, and the policy was implemented in February 2007.

Appendix: Text of the 90-Day and 30-Day Renewal Reminder Notices

90-Day Renewal Reminder

Date: <date sent will appear here>
From: [email protected]
Reply-To: [email protected]
To: <your e-mail address will appear here>
Subject: In 90 days, your MCommunity Directory group(s) will expire

You own one or more groups in the MCommunity Directory <http://mcommunity.umich.edu> that will expire in 90 days. If not renewed, the group(s) listed below will expire on <expiry date will appear here>.

Instructions for renewing groups, as well as more information about group expiry, can be found in 'Managing Groups that You Own in the MCommunity Directory' at:
<https://documentation.its.umich.edu/node/356>

If you renew, review the group settings to be sure they are still appropriate, particularly the setting for group member visibility. You are responsible for respecting group member needs for privacy.

If you have questions or need help with this, please contact the ITS Service Center at 734-764-HELP (764-4357), or [email protected].

- MCommunity Directory

List of group(s) expiring -

Groupname 1
Groupname 2 (etc)

30-Day Renewal Reminder

Date: <date sent will appear here>
From: [email protected]
Reply-To: [email protected]
To: <your e-mail address will appear here>
Subject: In 30 days, your MCommunity Directory group(s) will expire

You own one or more groups in the MCommunity Directory <http://mcommunity.umich.edu> that will expire in 30 days. If not renewed, the group(s) listed below will expire on <expiry date will appear here>.

Instructions for renewing groups, as well as more information about group expiry, can be found in 'Managing Groups that You Own in the MCommunity Directory' (S4382) at:
<https://documentation.its.umich.edu/node/356>

If you renew, review the group settings to be sure they are still appropriate, particularly the setting for group member visibility. You are responsible for respecting group member needs for privacy.

If you have questions or need help with this, please contact the ITS Service Center at 734-764-HELP (764-4357), or [email protected].

- MCommunity Directory

List of group(s) expiring -

Groupname 1
Groupname 2 (etc)