|
Grex > Coop12 > #156: Make off-site e-mail and ftp a non-default priviledge | |
|
| Author |
Message |
| 25 new of 70 responses total. |
davel
|
|
response 25 of 70:
| 
Dec 6 16:30 UTC 2002 |
But what gull added in #23 is right on the mark, too.
|
cross
|
|
response 26 of 70:
|
Dec 6 17:38 UTC 2002 |
Regarding #22; Thanks, but I just don't have the time. :-(
|
jmsaul
|
|
response 27 of 70:
|
Dec 6 23:13 UTC 2002 |
22 and 23 look right on the mark to me, but all of this has been said before,
over and over again. And nothing changes.
|
spooked
|
|
response 28 of 70:
|
Dec 7 00:09 UTC 2002 |
I believe I was the last staffer added, a few years back.
|
jep
|
|
response 29 of 70:
|
Dec 7 03:38 UTC 2002 |
I understand the point of #23. I understand it *really* *really*
well. I was on the staff of M-Net once. It is very hard to turn over
any control of something important to you, to anyone to whom you aren't
close.
However, I would like to suggest there are other trustworthy and
capable people on Grex besides just the ones who were staff when Grex
first opened for business. The ones you want may not jump up and down
and scream and yell and demand to be added to the staff; those are the
ones who should be viewed very skeptically. The ones you want almost
have to be sought out, wooed, and brought into the tight Inner Circle.
Or started with a little responsibility, evaluated, and then brought in.
It takes a *lot* of faith and trust to turn over the keys, root
password, and especially *control* to someone you don't know. But
dangit, every user on Grex has trusted the current staff, to some
extent. In most cases, they've done so without knowing much about any
of the staff. Surely some of that trust can be returned, to some of
the users.
It is vitally necessary that this happen. Right now, there are
proposals earlier in this item about turning off newuser and setting up
tiers of access, just to relieve the burden on the staff. One thing
that could happen, with some more help, is to relieve some of that
burden. Another is it would spread the future of Grex onto more
shoulders than those of just Marcus and STeve.
I'd say it's just as important, though, that it would be socially
beneficial. Right now there's an Inner Circle of no more than 15
people, and maybe only half that. We all know who they are. They will
always be elected to the Board if they run. They are the only ones who
can suggest any kind of change and have any chance of having it
implemented. If they really want to see a change, they can persuade
just a few others to make it happen, and then it will happen. (It
doesn't happen often.)
Grex is egalitarian, but some pigs are more equal than others. As long
as that is so, and especially when the Inner Circle is as static as it
is, then most people here are just visitors.
It's unrealistic to think that visitors are going to support Grex the
way the Inner Circle does. Give a little access to governance and
control by some others, and it might well go a long way toward bringing
in more support. It would bring in more buy-in.
Anyway, I call it foolish to cut services -- and much worse, exclude
new people -- without trying to relieve the burden on the staff in a
more positive way.
|
mdw
|
|
response 30 of 70:
|
Dec 7 03:54 UTC 2002 |
There are other trustworthy folks. Some of them *are* staff now. We've
also had a few bad experiences. You don't want to know. It's hard to
find people who are qualified, trustworthy, and have the time and
interest to volunteer. Although, now that I think about it, we never
thought of asking John Ellis Perry Jr. to volunteer. I bet there's
something useful we could do with his skills and I bet he has oodles of
spare time.
|
jep
|
|
response 31 of 70:
|
Dec 7 04:52 UTC 2002 |
No, I don't have huge amounts of spare time. I don't have great
interest, but might be willing to pitch in some if I knew I could
help. I sure don't have skills like yours, Marcus, but have survived
for a decade in part based on what I know about Unix. Somehow I think
I could even contribute useful technical ability to Grex.
I don't really expect you to ask me, though. I tried to make it clear
I'm not looking for a position on the Grex staff. I'm strongly
suggesting that there's something wrong, if it's seen as a better idea
to cut back on Grex than to try some new staff members.
I'm also aware of some of the bad experiences. You're right, it's not
really something I have to know more about. I'm suggesting that you
not give up, but instead, try harder to find more good new people.
|
keesan
|
|
response 32 of 70:
|
Dec 7 16:45 UTC 2002 |
JEP is possibly the most honest person I know. And trustworthy. Honest
people are not always good at recognizing dishonest people. How does one go
about determining who is trustworthy enough to be staff?
|
jep
|
|
response 33 of 70:
|
Dec 7 23:53 UTC 2002 |
I'm not asking for anyone's trust or for any responsibility on Grex. I
do not have a long history of strong interest in Grex. I was involved
in a conflict with Grex in the past, several years ago. I haven't
always had the sort of philosophy about running a conferencing system
which the Inner Circle of Grex has had. These things all make me a
less than ideal candidate for the Grex staff.
I'm suggesting it's better to extend a little trust to a few additional
people than to shut down newuser and mail, and that there are very
likely people here who could help if approached. I'm one, but believe
there to be others.
|
davel
|
|
response 34 of 70:
|
Dec 8 19:29 UTC 2002 |
Hmm. One thing this whole discussion has made me think is this: Maybe one
problem is that we've tended to wait for people to volunteer rather than
identify candidates & invite them to volunteer. (And John's certainly right
(going back to #29 here) that in many cases those who really want to volunteer
are not good candidates.) As several folks have pointed out, many staff tasks
are not very technically demanding; caution, restraint, & thoroughness are
rather more important. (One rather obvious example: responding to
I-forgot-my-password email. This is something that takes almost nothing
beyond the ability to type correctly in technical ability, but requires
root access.)
John, I think you'd be a very welcome addition to the staff, & if they don't
jump at your rather reluctant expressions of willingness to serve I can't
imagine why not. Just my $.02, I admit; you may have all kinds of skeletons
in your closet that I don't know about.
|
other
|
|
response 35 of 70:
|
Dec 8 20:12 UTC 2002 |
When my term on the board expires, I would be interested in volunteering
to take on some low-skill staff responsibilities. Heck, even before then
if there isn't significant concern about it.
|
remmers
|
|
response 36 of 70:
|
Dec 8 20:29 UTC 2002 |
I'd like to see more people get involved in helping manage the system.
Since this is the discussion item for a specific proposal, conversation
about how to do that might better be moved to a new item.
As to Russ's proposal: One of the arguments people make in support of
it is that it will free up staff time to deal with other issues. It's
not clear to me that it will have that effect. Keep in mind that in
passing this proposal, you would be adding another item to staff's
to-do list -- namely, implementation of the proposal.
Although I'm staff, I don't normally do system-tweaking at that level,
so I don't know precisely how big a project this would be. To do the
ftp part, you'd have to modify the behavior of ftpd (the "daemon" that
listens for and process external ftp requests) so that it would allow
ftp access to certain users and deny it to others. Offhand I don't
know if ftpd supports that. Does anybody else know? If it doesn't,
then some staff person would have to figure out how to modify ftpd to
provide that functionality. We'd need the source code (do we even
have it?). Even if we do have source, it sounds like a substantial
job.
Something else to think about it -- even if we teach our official
ftp software to distinguish between users, that alone won't necessarily
close leaks that would enable a user to do an end-run around the
policy. Are there loopholes lurking in shadows?
I think that implementing the email part of the proposal could pose
similar difficulties.
Before I could even consider voting in favor of this, I'd want some
estimate from knowledgable staff regarding feasibility.
|
remmers
|
|
response 37 of 70:
|
Dec 8 20:30 UTC 2002 |
(#34 and #35 slipped in, but my #36 seems to fit anyway. ;-)
|
jep
|
|
response 38 of 70:
|
Dec 8 21:51 UTC 2002 |
re #34: With great appreciation and all due respect, Dave, you should
check with other staff members before committing yourself to an opinion.
I'm not interested in advocating either for or against myself, but I
can acknowledge I might not be welcome. I only want to repeat the
idea, oft mentioned before but rarely implemented, that if there's a
shortage of staffer time, a solution could be to add staff. If it's
done successfully, there are many other benefits as well.
re #36: I brought it up directly as a counter-proposal to Russ's idea,
so I feel the discussion is in an appropriate place right here.
|
remmers
|
|
response 39 of 70:
|
Dec 8 22:32 UTC 2002 |
(Dave L. is not a staff member.)
Re #38, last paragraph: To an extent, if you're using it to argue
against Russ's proposal. Personally, I think that looking for ways
to augment staff is a good idea regardless of the fate of Russ's
proposal, and deserves its own item at some point.
Donning my voteadm hat for a moment: This is an official "member
proposal" item, and so some timelines apply, as specified by the
bylaws. After two weeks have elapsed, the proposer can either
drop the proposal or submit a final wording to be voted on by
the membership. Since Russ posted the item on December 4, the
two-week point occurs on December 18.
|
jep
|
|
response 40 of 70:
|
Dec 8 22:42 UTC 2002 |
(My goof on davel being on staff.)
|
russ
|
|
response 41 of 70:
|
Dec 9 03:34 UTC 2002 |
Re #36: The current method requires a lot of maintenance too; I recall
Marcus saying the way he deals with FTP abuse is by altering ftpd to
block the offending accounts. It would probably be much easier to have
a file which contains the list of non-members who are allowed to use
FTP, and permit all staff to alter it (it can't break much).
The advantage for ftp is that staff wouldn't have to run around chasing
abusers all the time, which is one less thing for staff to do. I doubt
we'd ever see another edonkey episode if we did this.
Eliminating off-site e-mail as a default priviledge would be a more
complicated matter, but if staff is spending a lot of time cleaning
up after mail overflows it might be worth it regardless.
|
davel
|
|
response 42 of 70:
|
Dec 9 13:30 UTC 2002 |
(Re 40 re 39 re 34: John (remmers) is correct, and I indicated I was speaking
only for myself anyway. <raspberry> <stupid ascii smiley face>)
|
jep
|
|
response 43 of 70:
|
Dec 9 17:45 UTC 2002 |
Hmmph. If you're in a decision making position, then what you think is
a decision-making factor. For a wild example with no basis in fact, if
mdw says he's opposed to gay people on the staff, but it's only his
private opinion, it's not really only his private opinion. (I do not
believe Marcus thinks anything of the sort.)
But anyway, it's not relevant in this case.
|
russ
|
|
response 44 of 70:
|
Dec 10 02:53 UTC 2002 |
Note that Grex has been on Spamcop's black-hole list for a
while. This is a problem that blocking off-site e-mail for
non-members who haven't made a special request would get rid
of.
|
gull
|
|
response 45 of 70:
|
Dec 10 14:16 UTC 2002 |
Actually, it's not quite accurate to say it's been on the black-hole
list 'for a while'. It's been on it intermittently, for fairly short
periods each time.
Really, this is a problem with SpamCop. Their blocking system is overly
sensitive. It's not the kind of system I would want to use to reject
mail, and in fact they warn against using it that way. Any site using
it to block mail is, IMHO, irresponsible.
|
jp2
|
|
response 46 of 70:
|
Dec 10 15:35 UTC 2002 |
This response has been erased.
|
keesan
|
|
response 47 of 70:
|
Dec 10 19:35 UTC 2002 |
We have been blacklisted since Sunday, as I found out when one of my mails
bounced, and we may be blacklisted for a week. Is there some way to program
things at grex to not allow bulk mailings to anyone but paid members and local
dial-ins? Bulk mailings being mail to groups or to more than three people
at a time. But I suppose there are ways around that too.
AOL has also been blacklisted for periods of time. The bigger systems are
less likely to be blacklisted because one spammer is not going to increase
the percentage of spams coming from them to a critical value as easily. Yet
most of my spam comes from the bigger free email providers like yahoo and
hotmail. I don't get the point of spamcop's approach.
|
albaugh
|
|
response 48 of 70:
|
Dec 10 19:49 UTC 2002 |
The point is, if grex wanted to "deny" e-mail to new accounts as a new
default, how easy would it be to change the newuser software to not set up
e-mail automatically, or alternately, leave newuser alone, but create a new
"delete e-mail after the fact" software thing? If the answer is "very hard"
or "will take a long time before worked on / completed", then even if spam
from jerky new users is the cause of grex e-mail woes, what is going to get
done about it beyond the wringing of hands?
|
remmers
|
|
response 49 of 70:
|
Dec 10 20:45 UTC 2002 |
The problem is that newuser doesn't explicitly "set up" email, it
simply sets up a Unix account on Grex. Unix accounts automatically
get access to email. I'm not aware of an existing mechanism for
granting/denying email access on a per-user basis. We'd have to
invent one.
I'm opposed to the email part of this proposal in any case and
basically agree with gull in one of his early responses. I could
be persuaded about the ftp part if it's easy to implement.
|