Deprovisioning Email

The purpose of this document is to discuss methods of programmatically deprovisioning e-mail accounts.

At this time e-mail accounts are deprovisioned by hand.

• The eaddress data is removed from the registry by IRM
• The mail account is marked for deletion in the mail server by the mail team
• After 32 days the mail account is removed from the mail server

Note that name arbitration uses both the registry and the mail server, as long as the address exists in either place it cannot be used by anyone else.

• Mail must be deprovisioned programmatically
• When a PID enters the shelved state, its e-mail account should be deprovisioned
  • If the PID has an e-mail account then notify the owner of the PID, allowing a 30 day window before the e-mail account is expired
• When a PID enters the locked state, the password to the e-mail account should be set to an impossible hash (effectively locking the e-mail account)
• All data associated with an e-mail account (aliases, forwards) must be preserved until that account is deleted on the mail server
• See Deprovisioning PIDs, as the problem spaces overlap

E-mail management in ED will no longer have the ability to delete an e-mail account, deletes are controlled by the mail server.
Instead we will concern ourselves with e-mail expiration.

• A PID is marked as 'Locked' (e-mail accounts cannot be created or renewed when in this state)
  1. e-mail account gets impossible hash, mail cannot be accessed
  2. if e-mail is being forwarded, forward is removed until PID is no longer locked
• A PID is marked as 'Shelved' (e-mail accounts cannot be created or renewed when in this state)
  1. e-mail expiration date set to 66 days in the future (30 day grace period + 36 days in deleted state)
  2. e-mail is sent notifying user of impending deletion of e-mail account
  3. 30 days after notification, e-mail account has its deleted state flag set to true
     • e-mail account is marked for deletion, which means mail cannot be accessed
  4. after 36 days the registry will delete the eaddress data associated with the PID (freeing the aliases to be used by other people)
     • after ~32 days the mail server will delete the mail account
• A PID is marked as 'To Be Released' (e-mail accounts cannot be created when in the state)
  • PID cannot enter this state if e-mail account exists
• An e-mail account can be expired directly via the DAT, this will replace the current delete functionality
• if at any point the e-mail account is renewed (i.e. the expiration date is removed), the e-mail account will be unmarked for deletion or recreated

• Registry schema update (e-mail expiration, PID expiration notification)
• Business logic coding (shelving the PID)
• Web interface update (DAT)
• Scheduler service (deleting eaddress data)
• Replication stream update (mail)

Useful information:

• a mail account marked for deletion cannot be accessed by the owner and cannot receive new mail
• a mail account marked for hold cannot be accessed by the owner, but can receive new mail
  • this feature is not currently used as it is very expensive
• with the proposed solution it may be possible to remove the namearbiter's dependency on the mail server, since the registry is storing the eaddress data longer than it is contained in the mail server

— dfisher@vt.edu 2005/09/27 12:52

It might be good to add, under the problem statement, that for shelved state pids the deprovisioning must cause new mail to bounce and not allow access to the mail account by the account owner, and the intent is that the mail server account will be deleted. For locked state pids the deprovisioning must allow new mail to continue to be received, not allow access to the mail account by the account owner, and not cause the mail server account to be deleted.

Under lifecycle probably should have a bullet for ‘a PID is marked as locked’ with the action being that the email account state will not change but the password for the account would be set random. In addition, any replications that follow this change will not allow the user password information to replicate until the PID account again goes to active state.

Should we have lifecycle entries for a PID going back to active state from shelved or locked? What about shelved to locked, or locked to shelved?

It seems that the replication code for the mail server needs just the ED accountState information, in addition to the fields that it currently receives. This assumes that if the pid expiration date is removed, the record would also no longer be in the shelved state. Is this true? If not, I think both the accountState and the pid expiration date would need to be added to the DSML record because of locked state.

One thing to note is that as long as the mail server record exists, it must have a mail field.

It helps me to think in terms of what the mail server replication code would do. The replication to the mail server would react to the ED account state as follows:

• The incoming record has an ED accountState of active
  • matching mail server record found
    • mail server record in active state – this includes a record that previously had an ED accountState of locked and thus has a random password
      • all currently required fields are present in the replicated record –> leave mail server record in active state and allow all fields to replicate
      • some currently required field are not present in the replicated record –> leave mail server record ‘as is’, skip replication and log error
    • mail server record in deleted state
      • all currently required fields are present in the replicated record –> switch the mail server record to active and allow all fields to replicate
      • some currently required fields are not present in the replicated record –> leave the mail server record ‘as is’, skip replication and log error
  • no matching mail server record found
    • all currently required fields are present in the replicated record –> create a new mail server record in ‘active’ state
    • some currently required fields are not present in the replicated record –> leave mail server record ‘asis’, skip replication and log error
• The incoming record has an ED accountState of shelved
  • matching mail server record found
    • make sure that the mail server state is changed to deleted, no matter what the status of the other fields in the replication record
    • if the mail server record has a random password set, do not replicate the user password information
    • do not allow the mail field to be removed from the mail server record
    • allow all other fields to replicate, even if some currently required fields are not present in the replication record
  • no matching mail server record found
    • no work to do
• The incoming record has an ED accountState of locked
  • matching mail server record found
    • if not done already, set the password to a random value
    • do not allow the user password information to replicate
    • do not allow the mail field to be removed from the mail server record
    • mail server record in active state
      • all currently required fields are present in the replicated record –> leave mail server record in active state and allow all fields, except as noted previously, to replicate
      • some currently required field are not present in the replicated record –> leave mail server record ‘as is’, skip replication and log error
    • mail server record in deleted state
      • all currently required fields are present in the replicated record –> switch the mail server record to active and allow all fields, except as noted previoulsy, to replicate
      • some currently required fields are not present in the replicated record –> do nothing further with this mail server record, skip replication and log error
  • no matching mail server record found
    • no work to do

— cwinfrey@vt.edu 2005/09/28 16:44

Is there a need for IRM to maintain the ability to release e-mail aliases prior to the time the mail account is completely deleted from the mail server? Do they need the functionality for both active and shelved PIDs? If a department fails to reassign an alias before a PID is shelved, the department head will probably call IRM and ask for help. What options would be available to IRM to remove an alias from a shelved PID before the mail account on the mail server is deleted?

• IRM will still be able to manage expired email accounts — dfisher@vt.edu 2005/10/05 11:30

I also think we need an easy way to adjust the proposed 35-day interval since e-mail purge policies on the smail server may change.

— dunker@vt.edu 2005/09/29 19:10

Do we need something similar to this for AD (Hokies) so that the Exchange account can not be used and authentication using the Hokies account is blocked?

— cwinfrey@vt.edu 2005/09/28 16:44