#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@lists.torproject.org https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-bugs