Why was its password changed?

Aug 29 15:35 UTC 2003

The polytarp account.

response 2 of 110:

Aug 30 03:55 UTC 2003

Yup, if an account has it's mail forwarded to abc@xyz.com, then we'll
happily reset the password and mail it to abc@xyz.com.  Apparantly
those who actually wade through the awesome heap of staff mail we get
every day were being annoyed by the extraneous mail, and decided to take
a slightly creative approach to fixing the problem.  Certainly fits
long standing policy.

response 4 of 110:

Aug 30 15:58 UTC 2003

No, only to people who foolishly forward their email to staff. 

response 6 of 110:

Aug 30 16:55 UTC 2003

No, we're saying that there's a longstanding policy that's been followed.
It has nothing to do with liking or not liking anything.

response 8 of 110:

Aug 30 18:00 UTC 2003

That's an aside.

response 10 of 110:

Aug 30 18:06 UTC 2003

(#8 slipped in; my response was to #7.)

response 12 of 110:

Aug 30 22:02 UTC 2003

A .forward file pointing to e-mail account X is fairly convincing proof
that the owner of the grex account trusts the person(s) with access to
X to read all of his/her personal e-mail.  Access to e-mail is accepted
as proof of authority/ownership quite widely on the internet.  I think
this is a pretty reasonable policy for grex to follow.

response 14 of 110:

Aug 31 01:43 UTC 2003

O please.  You said you mail person A's password to person B, just as though
a .forward to person B means the two are the same person.  But, of course,
in doing that you give access to all of person A's private files and archived
mail to person B, and you said you did the same thing here with staff.  This
clearly indicates you've violated both polytarp's and other people's privacy.

response 16 of 110:

Aug 31 02:57 UTC 2003

It took me a few responses to follow the rationale behind what was 
done.

Why was the polytarp account forwarding all of it's mail to staff, dah?

response 18 of 110:

Aug 31 07:31 UTC 2003

Perhaps the origins of this policy need to be explained, so I'll attempt to
do that.

Staff gets lots of request from people who have lost their passwords, and
needs some way to verify that the person sending the request is in fact the
owner of the account.  To do that, in general, staff looks at information in
the account to find some contact information put there by the account's owner.
Most commonly used are phone numbers or e-mail addresses from the .plan file
(what shows up in finger output), but if that's not good enough, staff
sometimes needs to look elsewhere.  One of those "elsewheres" is the user's
.forward file, on the assumption that the account holder is by definition the
legitimate user of an account, and anywhere mail to that account gets
forwarded can be assuemed to be that person.

Then came the problem of impersonations, generally a case where somebody
creates an account and claims to be somebody else.  There wasn't a policy for
that, but it fit nicely into the password reset policy, in that if somebody
claimed to be somebody else, and that somebody else wanted it stopped,
it was quite legitimate to give control of an account to the person whose
account it claimed to be.

From there, I assumeit to have been a relatively easy jump that if forwarding
mail to an address established that that address belonged to the account's
owner, giving control over an account to the person whose address the accounts
mail was being forwarded to was quite legitimate.

Of course, in most of thsoe cases, staff could easily claim that as far as
they knew, and had been told by hte owner of the account, the account belonged
to the person whose address showed up in the account.  In polytarp's case,
staff knew the account wasn't staff's.  Still, this strikes me as a pretty
basic application of policy and past precident as written.  Do any of
polytar's clones have suggestions for how this might be changed for the
better?

response 20 of 110:

Aug 31 16:53 UTC 2003

David, if you don't want any of your mail, you can forward it to /dev/null.

response 22 of 110:

Sep 1 01:52 UTC 2003

For various reasons, I don't find the second paragraph of #17
to be credible.

I'm comfortable with how this was handled.