Re: [tor-bugs] #32558 [Internal Services/Tor Sysadmin Team]: clarify what happens to email when we retire a user

["Tor Bug Tracker & Wiki" <blackhole@xxxxxxxxxxxxxx>]

#32558: clarify what happens to email when we retire a user
-------------------------------------------------+---------------------
 Reporter:  anarcat                              |          Owner:  tpa
     Type:  task                                 |         Status:  new
 Priority:  Medium                               |      Milestone:
Component:  Internal Services/Tor Sysadmin Team  |        Version:
 Severity:  Normal                               |     Resolution:
 Keywords:                                       |  Actual Points:
Parent ID:  #32519                               |         Points:
 Reviewer:                                       |        Sponsor:
-------------------------------------------------+---------------------

Comment (by anarcat):

 wow that's a lot of text. :) if i may, here's a summary of the three
 options arma proposed:

  1. '''deactivation delay'''. when a person leaves (either stops
 contributing to TPO or is not part of TPI), email stops working after a
 delay

  2. '''two systems, with grand-father clause'''. like the two systems case
 below, but with a "grand-father" clause that give a "TPO" (or "hacker")
 access (ie. it doesn't get closed) to the email if they were already core
 before joining TPI

  3. '''two systems: hacker and corporate'''. the '''hacker''' group is: if
 you are part of "core", your email keeps working when you leave, and never
 gets redirected. the '''corporate''' group includes people who did *not*
 get the email by being admitted in the "core" group, those emails are
 disabled or redirected when they leave.

 I hope that's a good summary, please correct any misconceptions I might
 have carried.

 ----

 That said, I'm not sure I see the distinction between option 2 and 3
 above, nor what that distinction would bring in the first place. Maybe it
 tries to fix the "some details still to be worked out" problem, but I find
 those two confusing.

 Furthermore, I think it misses a key idea that should be formally
 proposed:

  4. '''email is private, forwards for function'''. ie. with exceptions,
 emails keep working when we grant people access to @torproject.org. this
 includes "corporate" people that were not admitted to "core". emails are
 '''not forwarded''' ever, except in rare cases where accounts legitimitaly
 belonging to TPI/TPO should be reset and are associated with a personal
 email address. all "function-level" communications should happen through
 official channels ("fundraisigin@", "accounting@", "torproject-admin@",
 etc)

 I understand there are strong feelings, especially in TPI, that we *need*
 to be able to forward people's emails when they leave. I would argue that
 is a sign of a problem in our communications more than a policy that we
 should adopt formally.

 If people contact anarcat@ instead of torproject-admin@, that's a problem
 which we need to fix, for example. If only because it's possible that I
 eventually leave the organisation, or more likely go on a long vacation,
 during which time it's absolutely irrelevant to write me directly for help
 about TPA. I constantly remind people of this, and it generally works. If
 we do *not* institute that policy correctly, we will have a lot of trouble
 keeping track of those roles in the first place - using forwards is not
 really going to help us anyways.

 ----

 Besides, it seems to me we are trying two different and somewhat unrelated
 problems:

  * A. '''what happens when someone leaves''': do they keep their forward?
  * B. '''can we read other people's mail''': specifically, when A happens,
 do we, can we, should we forward their emails to some one else?

 The four proposals on the table can be formatted in this matrix, from what
 I understand:

 || Proposal || A. Expiry || B. Forward || Notes ||
 || 1. deactivation delay   || yes    || maybe? || policy on forwards not
 clarified ||
 || 2. two systems with grand-father  || if TPI || if TPI || depends on how
 the user got the account originally ||
 || 3. two systems || if TPI || if TPI || emails can expire and redirect if
 not core ||
 || 4. private     || no     || no || emails don't expire at all and do not
 forward, with exceptions ||

 I will end by mentioning that proposal 1 is the current status quo. The
 retire-a-user procedure I have now *does* deactivate users accounts and
 emails after a delay, and has been applied to people already. I have only
 *recently* made a note in that procude that people *might* need to keep
 their email, but that's definitely unclear.

 So we definitely need more clarity on this procedure, otherwise mistakes
 like the one I did last week will keep on happening.

--
Ticket URL: <https://trac.torproject.org/projects/tor/ticket/32558#comment:3>
Tor Bug Tracker & Wiki <https://trac.torproject.org/>
The Tor Project: anonymity online

_______________________________________________
tor-bugs mailing list
tor-bugs@xxxxxxxxxxxxxxxxxxxx
https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-bugs