1 <!DOCTYPE HTML PUBLIC
"-//W3C//DTD HTML 3.2//EN">
4 <TITLE> [IRCServices] More suggestions
6 <LINK REL=
"Index" HREF=
"index.html" >
7 <LINK REL=
"made" HREF=
"mailto:ircservices%40ircservices.za.net?Subject=%5BIRCServices%5D%20More%20suggestions&In-Reply-To=">
8 <META NAME=
"robots" CONTENT=
"index,nofollow">
9 <META http-equiv=
"Content-Type" content=
"text/html; charset=us-ascii">
10 <LINK REL=
"Previous" HREF=
"001658.html">
11 <LINK REL=
"Next" HREF=
"001661.html">
13 <BODY BGCOLOR=
"#ffffff">
14 <H1>[IRCServices] More suggestions
</H1>
16 <A HREF=
"mailto:ircservices%40ircservices.za.net?Subject=%5BIRCServices%5D%20More%20suggestions&In-Reply-To="
17 TITLE=
"[IRCServices] More suggestions">strider at chatcircuit.com
19 <I>Wed Mar
21 04:
20:
04 PST
2001</I>
21 <LI>Previous message:
<A HREF=
"001658.html">[IRCServices] More suggestions
23 <LI>Next message:
<A HREF=
"001661.html">Re Strider: [IRCServices] More suggestions
25 <LI> <B>Messages sorted by:
</B>
26 <a href=
"date.html#1660">[ date ]
</a>
27 <a href=
"thread.html#1660">[ thread ]
</a>
28 <a href=
"subject.html#1660">[ subject ]
</a>
29 <a href=
"author.html#1660">[ author ]
</a>
34 <PRE>I think he means no one ELSE can register it for
24h, you have
24h to
35 confirm it. What would be the point in making a user wait?
37 I actually like these suggestions for the most part. I've seen too many
38 users on our network register about
3 nicks and register as many chans as
39 possible (results in ban anyways because we can see them do that through
40 modifications we've made).
42 As for the memo, it is true any of the linked nicks can see the memo. Maybe
43 make a confimation instead. User attempts a link, person being linked to has
44 to confirm it before the link is active. But then, if you have the access to
45 link, then chances are this could be worked around anyways.
47 Beau (Strider) Steward
48 chatcircuit administrator and
6bit band member
49 <A HREF=
"http://www.ircservices.za.net/mailman/listinfo/ircservices">strider at chatcircuit.com
</A> www.chatcircuit.com
50 <A HREF=
"http://www.ircservices.za.net/mailman/listinfo/ircservices">ircadmin at chatcircuit.com
</A> irc.chatcircuit.com
51 <A HREF=
"http://www.ircservices.za.net/mailman/listinfo/ircservices">strider at
6bit.net
</A> www
.6bit.net
52 ----- Original Message -----
53 From:
"Yusuf Iskenderoglu
" <<A HREF=
"http://www.ircservices.za.net/mailman/listinfo/ircservices">uhc0 at rz.uni-karlsruhe.de
</A>>
54 To:
<<A HREF=
"http://www.ircservices.za.net/mailman/listinfo/ircservices">ircservices at ircservices.za.net
</A>>
55 Sent: Tuesday, March
20,
2001 11:
51 AM
56 Subject: Re: [IRCServices] More suggestions
62 </I>><i> On Tue,
20 Mar
2001, Partizanu wrote:
64 </I>><i> > a) Have NickServ sends a memo each time a nick is linked - inform the
65 </I>><i> > nick owner that another nick was linked to his nick
67 </I>><i> Not effective because memos are merged together and become visible by any
68 </I>><i> of the linked nicks.
71 </I>><i> > b) Make an option to logging system adding switch-style on services.conf
73 </I>><i> > NSLog +IPEL-RMA
74 </I>><i> > R - registration
75 </I>><i> > I - identification
76 </I>><i> > M - manual drop
77 </I>><i> > P - password change
78 </I>><i> > E - email changed
79 </I>><i> > L - links
80 </I>><i> > A - access list add/del
81 </I>><i> > Maybe the same for CSLog?
83 </I>><i> What is the use of seeing access changes ? What services root is
84 </I>><i> interested in access list changes ? Not sure about linking but, I already
85 </I>><i> enforced services to log everything listed here.
88 </I>><i> > And about password/email discussion:
90 </I>><i> > 1. Rezervation phase
91 </I>><i> > /msg nickserv register mypass
<A HREF=
"http://www.ircservices.za.net/mailman/listinfo/ircservices">my at email.address
</A>
92 </I>><i> > NickServ - Your nick is now reserved
93 </I>><i> > NickServ - Please check
<A HREF=
"http://www.ircservices.za.net/mailman/listinfo/ircservices">my at email.address
</A> for instructions
95 </I>><i> > Services sends a 'master-password' to
<A HREF=
"http://www.ircservices.za.net/mailman/listinfo/ircservices">my at email.address
</A>
96 </I>><i> > Nick is now reserved, no one can register it for
24 h
97 </I>><i> > Nick can't be added to access lists BUT it can be drop/forbid/suspend
99 </I>><i> It is unlikely that you can enforce people to not-being-able-to-get-opped
100 </I>><i> after registration. This way you would even prevent people registering
101 </I>><i> channels they would like to register, or they had to wait
24 online (with
102 </I>><i> a ppp connection, of course, or do all of your users have direct
103 </I>><i> connection?)
106 </I>><i> > 2. Confirmation phase
107 </I>><i> > /msg nickserv confirm
<master-password
>
108 </I>><i> > NickServ - Your nick is now confirmed and register
110 </I>><i> Except from the
24h pause, I do not see any difference to the AUTH system
111 </I>><i> I already described.
113 </I>><i> > ----------------
114 </I>><i> > What problems solve this:
115 </I>><i> > a) verify if the email address if it's a valide one or not
116 </I>><i> > b) verify if the email address is actually 'reachable' for the user
117 </I>><i> > c) prevent users register lots of nicks in a easy way
118 </I>><i> AUTH results in the same, too.
120 </I>><i> > d) make sure user really wants that nick (is not a 'one night nick') -
121 </I>><i> > why wait x days for a nick to expire in this case?
123 </I>><i> My implementation was a services.conf definition of NSExpireNonauth days.
124 </I>><i> How will you know that the remote mail system is not accidentally down?
125 </I>><i> What happens, if the master password email cannot be sent within
3 days,
126 </I>><i> but the fourth?
128 </I>><i> > e) user can't change nick's passws without the 'master-passwd' - a
129 </I>><i> > safety check never hurts
130 </I>><i> > f) user can't change nicks's email address without the 'master-passwd' -
131 </I>><i> > a safety check never hurts
132 </I>><i> > (about (e) and (f) - I don't think users change their pass and mails so
133 </I>><i> > often that this procedure become a pain
134 </I>><i> > - let's keep in mind that passwd and email are important identification
135 </I>><i> > elements - again a little safety measure won't hurt)
137 </I>><i> I do not share your opinion of turning the services system to undernet's
138 </I>><i> diplomacy of channel registrations. Services is a tool, which is there
139 </I>><i> to make life easier. Points of security are correct, but in my oppinion
140 </I>><i> not necessary.
142 </I>><i> > g) a user can loose his password, he will always be able to change it
143 </I>><i> > useing the 'master-passwd'
144 </I>><i> > h) a password can be stolen, the thief can't change it
145 </I>><i> > i) it's unlikely that the 'master-passwd' can be taken (this is used
146 </I>><i> > only once at registration and from time to time when changeing
147 </I>><i> > passwd/email) - it's not used everytime like the current nick passwd
149 </I>><i> The same is also with the AUTH system.
155 </I>><i> Yusuf Iskenderoglu *** eMail
<A HREF=
"http://www.ircservices.za.net/mailman/listinfo/ircservices">uhc0 at rz.uni-karlsruhe.de
</A>
158 </I>><i> -----------------------------------------------------------
159 </I>><i> To unsubscribe, mail
<A HREF=
"http://www.ircservices.za.net/mailman/listinfo/ircservices">ircservices-request at ircservices.za.net
</A>
160 </I>><i> with the word UNSUBSCRIBE in the subject of the mail.
161 </I>><i> <A HREF=
"http://www.ircservices.za.net/mailman/listinfo/ircservices">http://www.ircservices.za.net/mailman/listinfo/ircservices
</A>
172 <LI>Previous message:
<A HREF=
"001658.html">[IRCServices] More suggestions
174 <LI>Next message:
<A HREF=
"001661.html">Re Strider: [IRCServices] More suggestions
176 <LI> <B>Messages sorted by:
</B>
177 <a href=
"date.html#1660">[ date ]
</a>
178 <a href=
"thread.html#1660">[ thread ]
</a>
179 <a href=
"subject.html#1660">[ subject ]
</a>
180 <a href=
"author.html#1660">[ author ]
</a>
projects / irc.git / blob