- DALnet-services - nomad.dal.net

Fwd: More services changes - draft
by Mark Salerno 19 Feb '10

19 Feb '10

DALnet is pleased to announce the following changes to its' user services: 1) Changed services not to expire on-line identified users even if they didn't identify for 30 days. Note that you must use the nick regularly while being identified to it to k eep it registered. Services will not keep nicknames you do not use and do not identify to for 30+ days. 2) Fixed a bug when MemoServ temporarily "forgot" memos in rare cases. 3) Small fix to the Indonesian language pack. Thanks again to Kobi for assisting in this build, and to the various opers that helped us test these on a closed testnet. For SRA, -mjs

1 0

2010-02-15 Services changes
by Mark Salerno 18 Feb '10

18 Feb '10

DALnet is pleased to announce the following changes to its' user services: 1) Indonesian language pack has been added. Feel free to try it with the "/NickServ LANG ID" command. Special thanks to moonlite for writing it! 2) We removed some confusing notices about NickServ SET ENFORCE that were sent on nickname registrations. 3) Founders can no longer be added to AOP/SOP/AKICK lists. 4) NickServ SET URL command now supports https:// URLs. Special thanks to Kobi for helping provide coding assistance on these items. If you have any suggestion or request for a services (NickServ/ChanServ/MemoServ) feature, feel free to suggest it on our services mailing list: dalnet-services@ For SRA, -mjs

5 8

RFC Services Access and Bahamut Interaction
by PapaSmurf 06 Jan '10

06 Jan '10

I thought I'd give this mailing list a much-needed kickstart. More coming to the helpers mailing list after Christmas (maybe after new years). This is meant to be an unofficial RFC (request for comments) pertaining to the information posted here, so post away. ;p TOPIC: ChanServ/NickServ access and Bahamut/Services interaction. OBJECTIVE: Potential enhancements to be explored by services coders, and to provide helpers with information. * NickServ Access NickServ ACC 3 = Nick is ID'd to NickServ NickServ ACC 2 = Nick matches an access entry NickServ ACC 1 = Nick is registered NickServ ACC 0 = Nick is not registered Special thanks to " phnx " for providing the following info for NickServ ACC 1... Either the person using the nick isn't the owner, or the owner is using it and they registered the nick before Jan 1, 2003 (and they never turned Enforce On). The owner, under this scenario, had to AUTH via the web link (not through services). Else, the nick had to be registered before Jan 1, 2000 (when AUTH wasn't around), and never set Enforce On. * ChanServ Access ChanServ ACC 5 = Founder access via ChanServ identification ChanServ ACC 4 = Founder access via NickServ identification ChanServ ACC 3 = Founder access via Founder access entry ChanServ ACC 2 = Channel SOp, or matches an SOp access entry ChanServ ACC 1 = Channel AOp, or matches an AOp access entry ChanServ ACC 0 = All Other users/channel guests ChanServ ACC -1 = Akick'd users ChanServ ACC -2 = Channel has been Frozen or Closed * NickServ Access Entries Adding access entries (to channel founder, SOp and AOp nicknames) has many implications to proper channel management and security. ChanServ ACC 3/2/1 can be obtained by matching AOp or above access entries. SECTION 1: GENERALITIES * Ident > Access Matches > OpGuard 1.1 The ChanServ Ident feature is set on, by default, upon new channel registrations for very good reasons. This does two things: a. It negates access matches (and potential problems for channel managers/founders). b. It negates ChanServ's Unsecure feature (which requires access matches to function). 1.2 The ChanServ OpGuard (Secured Ops) feature is negated by access matches (ChanServ ACC 3/2/1). Only Ident can negate access matches; not OpGuard. 1.3 The ChanServ Unsecure feature is superceeded by Ident, and has no bearing on OpGuard. With Ident off, unsecure does nothing more than what access matches do by themselves. Basically, unsecure is now obsolete. SECTION 2: OP LISTS & ACCESS RULES 2.1 Only founder can be added to two op lists (by nickname only). Founder and AOp or SOp list. If the founder wants to be on all 3 lists, they must be added by address to the third. AOps and SOps can only be on one list by nickname. To be on both AOp/SOp lists, the second list must be added by address. 2.2 Access Rules 2.2.1 ChanServ Ident must be switched off for access matches to function. 2.2.2 Founders (ChanServ ACC 5/4/3) can be akick'd, but AOps/SOps cannot. ChanServ ACC 3 founders can ADD/DEL SOps. 2.2.3 AOps/SOps cannot be added if their nick/address is on the akick list. 2.2.4 Akicks (ChanServ ACC -1) can be bypassed if the akick'd matches founder/SOp/AOp access entry (or they are founder). Akick'd users can send channel memos (as long as they match the memo level set for the channel). 2.2.5 Founders can be akick'd by anyone with an access of ChanServ ACC -1 or higher (5/4/3/2/1/0/-1) as long as they match any SOp or higher's (ACC 5/4/3/2) access list. Note: Must be SOp or higher to add/del akicks. =============================================================== Services Coders: With the above rules, how about making new channel registrants (founders) automatically added to the SOp list (as well as being named founder). Why? 1. SOps cannot add the founder to the akick list (because the founder is on the SOp list). 2. Adding founder to the AOp list is pointless; SOps can delete the AOp entry then akick the founder at will. 3. If the founder wants off the SOp list (to use his/her 100 max SOp-entry quota) they can do so after channel registration. 4. If founder is the founder, what would it matter if the founder is akick'd? ANSWER: The founder changes founder name, but still uses the original founder name (to visit the channel). The new founder doesn't have an access entry (or Ident could be on). SOp adds the original founder nick to akick. Founder, using original founder nick, gets banned upon re-entry into the channel. Ultimately, founders get a truer sense of being top dog (without the hassle of adding their other ID to the SOp list). =============================================================== 2.2.6 With Ident switched on, ChanServ ACC 3 doesn't exist. SECTION 3: UNREGISTERED CHANNEL FOUNDERS (NICKSERV ACC 0) 3.1 In the "eyes" of services (ChanServ/NickServ), a dropped nick is the same as an expired nick. 3.2 A founder purposely drops his founder nick. He/she will continue to have ChanServ ACC 5 as long as: A) they do not log off DALnet B) Successor doesn't take over C) anyone else doesn't set themself as founder. 3.3 Such a founder can do all channel-related management they could before with two exceptions: A) They cannot send channel memos (a registered nick is required to send/read memos). B) They cannot drop the channel (ChanServ memos the drop code). 3.4 They can bypass Ident/Restrict/Opguard/etc features. SECTION 4: BAHAMUT IRCD/SERVICES INTERACTIONS 4.1 Not much is known of the interation between services and bahamut IRCd. I believe this matter needs to be explored more by helpers/coders, and the information needs to be shared (on this mailing list, or by updating http://docs.dal.net/ with proper information). 4.2 Examples of interactions: 4.2.1 ChanServ mkick and channel excepts. Excepts (channel mode +e) are designed to allow people in who match a large ban set (from abusive users, etc). If a guest is on the except list and an mkick is issued (by the highest ranking op on the channel), guess who ChanServ doesn't kick? Right, the guest. Mass kick does not unset excepts, and allows excepts to remain in the channel throughout the mass kick process. 4.2.2 ChanServ restrict and channel excepts. When a restricted channel has a violation (a non AOp/SOp/Founder joins), and an except is set, ChanServ will join the channel and unset the excepts before removing the guest. 4.3 Excepts, like all channel modes, are IRCd command features. The bond bahamut and services share is more apparent than what we think we know. This avenue needs to be explored more. Maybe we can get this mailing list kickstarted with said chatter (pertaining to findings resulting from testing any and all interactions). Well, happy holidays to all. tchin tchin! PapaSmurf

6 16

Little bug in NickServ
by PapaSmurf 04 Jan '10

04 Jan '10

I stumbled upon this by accident, but might be useful to fix with the next services upgrade. I was playing with my online profile (for DALnet)... https://users.dal.net/userinfo.php?nick=PapaSmurf I tried adding the httpS URL to my NickServ URL. It won't allow httpS addresses. It, however, lets you use... http://users.dal.net/userinfo.php?nick=PapaSmurf ...and when double clicked, or copied to a browser, it loads the profile just fine. Still, maybe an upgrade to NickServ allowing the httpS protocol would be nice. PapaSmurf

2 1

Re: [DALnet-services] ENFORCE
by James Hess 04 Jan '10

04 Jan '10

On Sat, Jan 2, 2010 at 10:33 AM, Vin King <vin.king(a)gmail.com> wrote: > ways to enforce it on. We still get questions about how to turn it off, > because it still looks like an option. It's obviously (IMO) broken that it's not an option... turning ENFORCE off should be just fine. NickServ ACCESS lists are a security risk, when you are OP'ed on Channels (channels that don't use IDENT). And 60 seconds to identify is really only sufficient for users with short passwords or quick typists who notice the NickServ message immediately. So ENFORCE by default forces some risky practices such as saving passwords in the IRC client, or using access lists, which are in the hands of bad guys. It may impact some nicknames that were registered for role-playing purposes, and meant to be shared (but without providing access). Then roleplayers' only option for such character nicknames is to forego registration (and risk the nick be stolen), or to use an access list such as *!*@*... The only beneficial effect of forcing ENFORCE to be on, that I see: users who turn off ENFORCE without understanding the implications, may accidentally let their nicknames expire (when they fail to identify to it) -- -J

2 1

Re: [DALnet-services] HelpServ Overhaul - RFC (request for comments)
by PapaSmurf 02 Jan '10

02 Jan '10

Well, as helpers on help channels (#help, #dalnethelp, #irchelp, etc), we help users with this information all the time. A user joins and asks why they are banned from channel #*****. As helpers, we do a simple command to find the person who banned them. /mode #***** b #***** *!*(a)*.aol.com set by PapaSmurf!PapaSmurf(a)*****.hsd1.co.comcast.net (Fri Jan 01 09:20:40) #***** End of Channel Ban List We, as helpers, give them a pre-existing Bahamut command or tell them the nick of the channel operator who banned them. We usually state to message them politely and ask why they were banned. Most often it is a bot that does the banning, but at least we get to explain why they were banned (i.e. they match a pre-existing ban, ChanServ akick'd them, etc). Basically, with the ' /helpserv banned ' topic, I was just using commands already in existence with Bahamut (and has been since I started using DALnet... 1998). --- On Thu, 12/31/09, Irvine A. Eatmon - prez <prez(a)dal.net> wrote: > From: Irvine A. Eatmon - prez <prez(a)dal.net> > Subject: Re: [DALnet-services] HelpServ Overhaul - RFC (request for comments) > To: "PapaSmurf" <freedried(a)yahoo.com> > Cc: dalnet-services(a)lists.dal.net > Date: Thursday, December 31, 2009, 6:47 PM > Having commands that allow users > information to see WHO banned them from a > channel, including user addresses, etc... is not something > I believe > DALnet should implement. > > Yes, channel bans are not exactly top-secret information, > as others in a > channel can see who set the bans and execute a /WHOIS to > view the users > used IP Address/Hostname. > > However, giving users direct access to this, can be bad. > This gives them > the information needed, via an easy tool that DALnet would > be endorsing, > to send messages to the Operator (ChanOp) in question, that > may be > slanderous and hateful. It may also open up for floods of > that ChanOp in > question. > > We should have that information remain as-is, with nothing > new being > revealed or made more easily accessable. > > > [ Irvine A. Eatmon ] > [ prez - prez(a)dal.net ] > [ rapport.ix.us.dal.net ] > [ Global Operator - Services Administrator ] > [ Web Team Member ] > > > Obviously the information in HelpServ is obsolete. > Just a few commands I > > find even remotely useful for helping new users to > DALnet... > > > > 1. /helpserv rules > > 2. /helpserv basics > > 3. /helpserv etiquette > > > > I made a post to the helpers@ mailing list with > Bahamut IRCd commands for > > non-oper users. Maybe we could revamp /helpserv basics > with taht > > information. I went to #bahamut weeks ago, and a > channel op there said he > > didn't know of an existing Bahamut IRCd command list > to reference (hence > > the reason I posted it). > > > > Maybe we can revamp HelpServ to use as a reference > tool (with relevant > > topics) for help channel staff to reference newbies > to. > > > > Some topic examples... > > > > /helpserv welcome - Welcome msg from DALnet > > /helpserv listhelp - list of help channels > > /helpserv register - nick/chan registration benefits > > /helpserv vhosts - DALnet doesn't have a HostServ, but > BNC... > > /helpserv threats - if threatened, what to do > (contacts?) > > /helpserv services - Differentiate DALnet from other > networks > > > > Note: With the services topic, such things as no > halfops, botserv, X, etc. > > > > /helpserv banned - basic information to check who > banned & how to msg... > > > > Note: with the banned topic, maybe stuff like... /mode > #channel b to see > > who banned them, and /whois to see what their addy is, > etc. > > > > I'd like to see some posts to this thread with other > examples. Maybe we > > can all talk the services coders into revamping the > obsolete service. > > Still, I find it useful, and it should not be phased > out. I would be more > > than happy to donate my time in writing samples to > submit to this mailing > > list for RFCs. Together, we can get working topics > compiled and update > > HelpServ. > > > > > > PapaSmurf > > > > > > > > _______________________________________________ > > DALnet-services mailing list > > DALnet-services(a)lists.dal.net > > https://lists.dal.net/mailman/listinfo/dalnet-services > > > > > [ Irvine A. Eatmon ] > [ prez - prez(a)dal.net ] > [ rapport.ix.us.dal.net ] > [ Global Operator - Services Administrator ] > [ Web Team Member ] > >

3 2

HelpServ Overhaul - RFC (request for comments)
by PapaSmurf 01 Jan '10

01 Jan '10

Obviously the information in HelpServ is obsolete. Just a few commands I find even remotely useful for helping new users to DALnet... 1. /helpserv rules 2. /helpserv basics 3. /helpserv etiquette I made a post to the helpers@ mailing list with Bahamut IRCd commands for non-oper users. Maybe we could revamp /helpserv basics with taht information. I went to #bahamut weeks ago, and a channel op there said he didn't know of an existing Bahamut IRCd command list to reference (hence the reason I posted it). Maybe we can revamp HelpServ to use as a reference tool (with relevant topics) for help channel staff to reference newbies to. Some topic examples... /helpserv welcome - Welcome msg from DALnet /helpserv listhelp - list of help channels /helpserv register - nick/chan registration benefits /helpserv vhosts - DALnet doesn't have a HostServ, but BNC... /helpserv threats - if threatened, what to do (contacts?) /helpserv services - Differentiate DALnet from other networks Note: With the services topic, such things as no halfops, botserv, X, etc. /helpserv banned - basic information to check who banned & how to msg... Note: with the banned topic, maybe stuff like... /mode #channel b to see who banned them, and /whois to see what their addy is, etc. I'd like to see some posts to this thread with other examples. Maybe we can all talk the services coders into revamping the obsolete service. Still, I find it useful, and it should not be phased out. I would be more than happy to donate my time in writing samples to submit to this mailing list for RFCs. Together, we can get working topics compiled and update HelpServ. PapaSmurf

3 3

RE: [DALnet-services] dalnet-services@ observations
by Kalpin Erlangga Silaen 31 Dec '09

31 Dec '09

We are not discussing about MTA nor MDA. We are talking about services Kalpin Sent from my Nokia phone -----Original Message----- From: James Hess Sent: 01/01/2010 12:20:46 PM To: Jason Slagle Cc: dalnet-services(a)lists.dal.net Subject: Re: [DALnet-services] dalnet-services@ observations On Thu, Dec 31, 2009 at 5:23 PM, Jason Slagle <raistlin(a)tacorp.net> wrote: > On Wed, 30 Dec 2009, Jason Hill wrote: [snip] > Apparently the only ISP's and email providers you use run windows :P Pretty > much every unix MTA I've come across uses case sensitive usernames. Well the > LDA does anyways. You mean case-Insensitive, right? In current versions of Sendmail, Sendmail 8: sending e-mail to "BlaHBlaH" will reach the same destination as sending to blahblah. The E-MAIL ADDRESS is case-insensitive with respect to delivery. The LOCAL USERNAME must is case-sensitive, and must be all lowercase. Of course the case of characters in e-mail message headers are preserved, but they have nothing to do with delivery. Only the envelope recipient is important, and that's case-insensitive. That is: no matter what case of characters you type in the e-mail address that you SEND to the MTA, sendmail always converts it to lowercase. The e-mail goes to the username that is the same as the e-mail address, but all lowercase. This is true, unless you are one of those very unusual sites that do something like MODIFY_MAILER_FLAGS(`LOCAL', `+u')dnl *(In fact, if you create a unix user with an uppercase character in their username, they won't be able to receive mail at all until/unless you create an /etc/aliases entry to map username: User) Postfix and a few others do pretty much the same thing, differing in some fine details (but the SMTP rcpt to: is case-insensitive nonetheless)... > Jason -- -J _______________________________________________ DALnet-services mailing list DALnet-services(a)lists.dal.net https://lists.dal.net/mailman/listinfo/dalnet-services

1 0

dalnet-services@ observations
by PapaSmurf 31 Dec '09

31 Dec '09

Kobi: Thanks for the reply to the post. I replied, and thought it went to the mailing list. Everyone: I started playing with NS/CS access one day and found some peculiarities. Kobi and DALnet now know of them, and I am pleased. Hopefully the bugs I pointed out will be fixed for the next services release. I posted to the helpers@ mailing list yesterday, and I found that the initial to welcome message from dalnet hasn't been updated since 1996. At the beginning of the email, it says to post to the helpers list, to mail to Helpers(a)lists.dal.net -- Well, you will get the email sent back; only helpers(a)lists.dal.net (lowercase h) works. I am not sure if dalnet-services@ is the same way, but the same syntax is there... Welcome to the DALnet-services(a)lists.dal.net mailing list! Anyway, I hope we can generate more threads here. I believe there is a lot to discuss (to make services better). Myself, I'd like to see HelpServ completely overhauled. The information within is way too obsolete... Maybe I will start a thread next about it. Stay tuned. ;) As for the rest of you, start posting some threads on the general mailing lists. We are here to make DALnet better; to discuss possible improvements. PapaSmurf

5 5

Re: DALnet-services Digest, Vol 7, Issue 1
by Houmood Abdulrahman 29 Dec '09

29 Dec '09

hello .. i like this topic and i want to add something for it.. like C-Founder access .. which can delete sop and edit description and mlock ..etc try to thinking about this access it is so nice :D regards. -darkelf. On Sun, Dec 27, 2009 at 11:00 PM, <dalnet-services-request(a)lists.dal.net>wrote: > Send DALnet-services mailing list submissions to > dalnet-services(a)lists.dal.net > > To subscribe or unsubscribe via the World Wide Web, visit > https://lists.dal.net/mailman/listinfo/dalnet-services > or, via email, send a message with subject or body 'help' to > dalnet-services-request(a)lists.dal.net > > You can reach the person managing the list at > dalnet-services-owner(a)lists.dal.net > > When replying, please edit your Subject line so it is more specific > than "Re: Contents of DALnet-services digest..." > > > Today's Topics: > > 1. RFC Services Access and Bahamut Interaction (PapaSmurf) > > > ---------------------------------------------------------------------- > > Message: 1 > Date: Fri, 18 Dec 2009 09:05:17 -0800 (PST) > From: PapaSmurf <freedried(a)yahoo.com> > Subject: [DALnet-services] RFC Services Access and Bahamut Interaction > To: dalnet-services(a)lists.dal.net > Message-ID: <135821.36367.qm(a)web62107.mail.re1.yahoo.com> > Content-Type: text/plain; charset=us-ascii > > I thought I'd give this mailing list a much-needed kickstart. More coming > to the > helpers mailing list after Christmas (maybe after new years). > > This is meant to be an unofficial RFC (request for comments) pertaining to > the information > posted here, so post away. ;p > > > > TOPIC: ChanServ/NickServ access and Bahamut/Services interaction. > > OBJECTIVE: Potential enhancements to be explored by services coders, and to > provide > helpers with information. > > > > * NickServ Access > > > NickServ ACC 3 = Nick is ID'd to NickServ > NickServ ACC 2 = Nick matches an access entry > NickServ ACC 1 = Nick is registered > NickServ ACC 0 = Nick is not registered > > Special thanks to " phnx " for providing the following info for NickServ > ACC 1... > > Either the person using the nick isn't the owner, or the owner is using it > and they > registered the nick before Jan 1, 2003 (and they never turned Enforce On). > The owner, > under this scenario, had to AUTH via the web link (not through services). > Else, the > nick had to be registered before Jan 1, 2000 (when AUTH wasn't around), and > never set > Enforce On. > > > > * ChanServ Access > > > ChanServ ACC 5 = Founder access via ChanServ identification > ChanServ ACC 4 = Founder access via NickServ identification > ChanServ ACC 3 = Founder access via Founder access entry > ChanServ ACC 2 = Channel SOp, or matches an SOp access entry > ChanServ ACC 1 = Channel AOp, or matches an AOp access entry > ChanServ ACC 0 = All Other users/channel guests > ChanServ ACC -1 = Akick'd users > ChanServ ACC -2 = Channel has been Frozen or Closed > > > > * NickServ Access Entries > > > Adding access entries (to channel founder, SOp and AOp nicknames) has many > implications > to proper channel management and security. ChanServ ACC 3/2/1 can be > obtained by > matching AOp or above access entries. > > > > > SECTION 1: GENERALITIES > > > * Ident > Access Matches > OpGuard > > > 1.1 The ChanServ Ident feature is set on, by default, upon new channel > registrations > for very good reasons. This does two things: > > a. It negates access matches (and potential problems for channel > managers/founders). > b. It negates ChanServ's Unsecure feature (which requires access matches to > function). > > > 1.2 The ChanServ OpGuard (Secured Ops) feature is negated by access matches > (ChanServ ACC 3/2/1). Only Ident can negate access matches; not OpGuard. > > > 1.3 The ChanServ Unsecure feature is superceeded by Ident, and has no > bearing on > OpGuard. With Ident off, unsecure does nothing more than what access > matches do by > themselves. Basically, unsecure is now obsolete. > > > > > SECTION 2: OP LISTS & ACCESS RULES > > > 2.1 Only founder can be added to two op lists (by nickname only). Founder > and AOp or > SOp list. If the founder wants to be on all 3 lists, they must be added by > address to > the third. AOps and SOps can only be on one list by nickname. To be on both > AOp/SOp > lists, the second list must be added by address. > > > > 2.2 Access Rules > > > 2.2.1 ChanServ Ident must be switched off for access matches to function. > > 2.2.2 Founders (ChanServ ACC 5/4/3) can be akick'd, but AOps/SOps cannot. > ChanServ > ACC 3 founders can ADD/DEL SOps. > > 2.2.3 AOps/SOps cannot be added if their nick/address is on the akick list. > > 2.2.4 Akicks (ChanServ ACC -1) can be bypassed if the akick'd matches > founder/SOp/AOp > access entry (or they are founder). Akick'd users can send channel memos > (as long as > they match the memo level set for the channel). > > 2.2.5 Founders can be akick'd by anyone with an access of ChanServ ACC -1 > or higher > (5/4/3/2/1/0/-1) as long as they match any SOp or higher's (ACC 5/4/3/2) > access list. > > Note: Must be SOp or higher to add/del akicks. > > > =============================================================== > Services Coders: > > With the above rules, how about making new channel registrants (founders) > automatically > added to the SOp list (as well as being named founder). Why? > > 1. SOps cannot add the founder to the akick list (because the founder is on > the SOp list). > > 2. Adding founder to the AOp list is pointless; SOps can delete the AOp > entry then akick > the founder at will. > > 3. If the founder wants off the SOp list (to use his/her 100 max SOp-entry > quota) they > can do so after channel registration. > > 4. If founder is the founder, what would it matter if the founder is > akick'd? > > ANSWER: The founder changes founder name, but still uses the original > founder name (to > visit the channel). The new founder doesn't have an access entry (or Ident > could be on). > SOp adds the original founder nick to akick. Founder, using original > founder nick, gets > banned upon re-entry into the channel. Ultimately, founders get a truer > sense of being > top dog (without the hassle of adding their other ID to the SOp list). > =============================================================== > > > 2.2.6 With Ident switched on, ChanServ ACC 3 doesn't exist. > > > > > SECTION 3: UNREGISTERED CHANNEL FOUNDERS (NICKSERV ACC 0) > > > 3.1 In the "eyes" of services (ChanServ/NickServ), a dropped nick is the > same as an > expired nick. > > 3.2 A founder purposely drops his founder nick. He/she will continue to > have ChanServ > ACC 5 as long as: A) they do not log off DALnet B) Successor doesn't take > over > C) anyone else doesn't set themself as founder. > > 3.3 Such a founder can do all channel-related management they could before > with two > exceptions: > > A) They cannot send channel memos (a registered nick is required to > send/read memos). > B) They cannot drop the channel (ChanServ memos the drop code). > > 3.4 They can bypass Ident/Restrict/Opguard/etc features. > > > > > SECTION 4: BAHAMUT IRCD/SERVICES INTERACTIONS > > > 4.1 Not much is known of the interation between services and bahamut IRCd. > I believe > this matter needs to be explored more by helpers/coders, and the > information needs to > be shared (on this mailing list, or by updating http://docs.dal.net/ with > proper > information). > > 4.2 Examples of interactions: > > 4.2.1 ChanServ mkick and channel excepts. > > Excepts (channel mode +e) are designed to allow people in who match a large > ban set > (from abusive users, etc). If a guest is on the except list and an mkick is > issued > (by the highest ranking op on the channel), guess who ChanServ doesn't > kick? Right, > the guest. Mass kick does not unset excepts, and allows excepts to remain > in the > channel throughout the mass kick process. > > 4.2.2 ChanServ restrict and channel excepts. > > When a restricted channel has a violation (a non AOp/SOp/Founder joins), > and an except > is set, ChanServ will join the channel and unset the excepts before > removing the guest. > > 4.3 Excepts, like all channel modes, are IRCd command features. The bond > bahamut and > services share is more apparent than what we think we know. This avenue > needs to be > explored more. Maybe we can get this mailing list kickstarted with said > chatter > (pertaining to findings resulting from testing any and all interactions). > > > > > Well, happy holidays to all. tchin tchin! > > > PapaSmurf > > > > > > ------------------------------ > > _______________________________________________ > DALnet-services mailing list > DALnet-services(a)lists.dal.net > https://lists.dal.net/mailman/listinfo/dalnet-services > > > End of DALnet-services Digest, Vol 7, Issue 1 > ********************************************* >

1 0