View Issue Details

Jump to NotesJump to History
IDProjectCategoryView StatusDate SubmittedLast Update
0001298unrealircdpublic2003-10-13 04:322004-12-01 16:07
ReporterStealth Assigned Tocodemastr 
PrioritynormalSeveritytweakReproducibilityalways
Status resolvedResolutionfixed 
Fixed in Version3.2.3 
Summary0001298: set::gline-address
DescriptionIt would be nice if the kline address (set in set::kline-address) is shown when a /*LINE command is used.
TagsNo tags attached.
3rd party modules

Activities

AngryWolf

2003-10-13 10:18

reporter   ~0003812

Servers A and B are on network N. User U is on server A, and Oper O is on server B. O bans U globally from the network. Which email address do you think should be shown? The kline address of server B or A, and why? Can you see now, this request is quite illogical?

Stealth

2003-10-13 20:16

reporter   ~0003813

Well, usually (on all the networks I've seen), all the servers have the same email address. And if O bans U and U sends an email using A's email, why can't A just forward the email to B? And in this case A's email would be shown because that is the server U is connected/connecting to.

Stealth

2004-10-24 22:11

reporter   ~0008106

Any coders have any ideas about this?

aquanight

2004-10-25 00:25

reporter   ~0008107

Bahamut has a seperate e-mail setting for global bans... so...

set {
    gline-address "[email protected]";
};

?

syzop

2004-10-26 10:17

administrator   ~0008117

Yeah, if implemented, it should be a seperate item [note: not in 3.2.2].
Furthermore, it should be completely optional, if ::gline-address is not specified then the current behavior should be left unchanged [1].

[1]: There was quite some talk in the forum about this, since services sometimes append contact addresses or urls a "forced use" of ::gline-address behavior is not preferable.

Stealth

2004-10-26 14:00

reporter   ~0008119

Syzop, I agree that this option should be optional. I am shure that with the number of networks that would find this useful, there are just as many networks that don't want/won't use a feature like this.

Also, to keep services from appending their own address to it, I think U:Lines should be exempt from this option. This will keep 2 addresses from getting added to the end.

aquanight

2004-10-26 16:11

reporter   ~0008125

Last edited: 2004-10-26 16:12

 Slight problem there. The address is what is shown when the ERR_YOUREBANNEDCREEP numeric is sent. Here's the relevant code from s_user.c which relates to K-Lines:

        /*
         * following block for the benefit of time-dependent K:-lines
         */
        if ((bconf =
            Find_ban(sptr, make_user_host(user->username, user->realhost),
            CONF_BAN_USER)))
        {
            ircstp->is_ref++;
            sendto_one(cptr,
                ":%s %d %s :*** You are not welcome on this server (%s)"
                " Email %s for more information.",
                me.name, ERR_YOUREBANNEDCREEP,
                cptr->name, bconf->reason ? bconf->reason : "",
                KLINE_ADDRESS);
            return exit_client(cptr, cptr, cptr, "You are banned");
        }

So, if we wanted to keep that format, it'd be something like this:
<me.name> <ERR_YOUREBANNEDCREEP> <nick> :*** You are not welcome on this network (<reason>). Email <email> for more information.

So as you can see, the email isn't appended to the reason, it's part of the "you are banned" text. To have it not appear for U-Lines would be more work, and anyway, how would Unreal know that the original setter of the G-Line was a U-Line? Example, OperServ set the gline 3 years ago, and since then I decided to have it called DictatorServ or something instead. Now Unreal comes to display the gline text to someone. How does it know this "OperServ" was a U-Line? The nick history certainly wouldn't have any info on it, and I don't think coders want to add a "was-ulined" flag for this.

edited on: 2004-10-26 16:12

syzop

2004-10-26 16:16

administrator   ~0008126

I too think this should either be on or off, not some exception for ulines or whatever... I'm not too keen on having like 24393 options for this small thingy, not to mention the practical problems that aquanight mentioned.

Plasma

2004-10-27 23:53

reporter   ~0008137

Add an option to have a GLINE email address please, it would be appreciated.

Zell

2004-11-02 11:22

reporter   ~0008215

Hmm. Interesting. After a little playing with the code, detecting a U-Line on the user is not only illogical [as aquanight said], but difficult. How the Services I use sets its G:Lines [from an OperServ AKILL], it sends the AKILL command to the server, and tells the server that the TKL-setter was the user who sent the /os AKILL command. So, if I do /os akill blah... then the server says G:Line from Zell. I'm definitely not a U:Line, so that wont work either. Personally, I dont see a need for a G-Line address... not to mention its gonna take a lot of code rewriting to include it.

Summary: I agree with Syzop and aquanight, and if implemented it's a good idea, but its not such a widely popular idea IMHO.

Plasma

2004-11-02 20:10

reporter   ~0008227

A lot of code? Hardly.

Simply add a g-line directive in the config file.

When a user connects to a particular server (say mine) and they are glined, the server sends back the email specified in the g-line directive.

Easy.

Zell

2004-11-03 16:31

reporter   ~0008244

I guess you don't understand how the code works. You would need to add the directive, as you say. But you would also have to do this:

* add code to the gline command
* gline command checks to see if set::gline-address is set
* if set::gline-address is set, add the data from it to the ban message
* if not set, proceed as normal

that sounds simple, but it takes a lot more coding to set up new directives and then to parse its information into the gline command. Not impossible, but time consuming. Do we REALLY need this feature?

Plasma

2004-11-03 18:50

reporter   ~0008247

When a user connects and is glined, it simply sends

"Email X for more information" to another notice message (or along with the ban reason) before they are disconnected.

Its done with a kline already, should be no problem to have it done for a gline.

aquanight

2004-11-04 01:49

reporter   ~0008248

Hm, I just found something. There is a difference in the rejection of clients banned by a TKL KLine (/kline) and one rejected by a ban user {} K:Line. Observe:

/kline with expiration:

[23:36:16] * Connecting to 192.168.2.97 (6667)
* Identd request from 192.168.2.97
* Identd replied: 4494, 6667 : USERID : UNIX : aquanight
[23:36:16] -irc.*- *** Looking up your hostname...
[23:36:16] -irc.*- *** Checking ident...
[23:36:16] -irc.*- *** Couldn't resolve your hostname; using your IP address instead
[23:36:16] -irc.*- *** Received identd response
aquanight Nickname is already in use.
[23:36:16] -irc.*- *** If you are having problems connecting due to ping timeouts, please type /quote pong C38DA3A6 or /raw pong C38DA3A6 now.
[23:36:16] -irc.*- *** You are banned from irc.* (Test)
[23:36:16] Closing Link: shadownight[192.168.2.97] (User is banned (Test))
[23:36:16] * Disconnected

/kline with no expiration:

[23:39:06] * Connect retry #1 192.168.2.97 (6667)
* Identd request from 192.168.2.97
* Identd replied: 4853, 6667 : USERID : UNIX : aquanight
[23:39:06] -irc.*- *** Looking up your hostname...
[23:39:06] -irc.*- *** Checking ident...
[23:39:06] -irc.*- *** Received identd response
[23:39:06] -irc.*- *** Couldn't resolve your hostname; using your IP address instead
aquanight Nickname is already in use.
[23:39:06] -irc.*- *** If you are having problems connecting due to ping timeouts, please type /quote pong B675911B or /raw pong B675911B now.
[23:39:06] -irc.*- *** You are permanently banned from irc.* (Test)
[23:39:06] Closing Link: shadownight[192.168.2.97] (User is permanently banned (Test))
[23:39:06] * Disconnected

And via config:

[23:39:36] * Connecting to 192.168.2.97 (6667)
* Identd request from 192.168.2.97
* Identd replied: 4919, 6667 : USERID : UNIX : aquanight
[23:39:37] -irc.*- *** Looking up your hostname...
[23:39:37] -irc.*- *** Checking ident...
[23:39:37] -irc.*- *** Couldn't resolve your hostname; using your IP address instead
[23:39:37] -irc.*- *** Received identd response
aquanight Nickname is already in use.
[23:39:37] -irc.*- *** If you are having problems connecting due to ping timeouts, please type /quote pong 7724FDC2 or /raw pong 7724FDC2 now.
*** You are not welcome on this server (Test) Email *@* for more information.
[23:39:37] Closing Link: shadownight[192.168.2.97] (You are banned)
[23:39:37] * Disconnected

See the difference? TKL KLines don't even send the email as it is - that's only used for ban user {} klines!

Stealth

2004-11-13 14:29

reporter   ~0008321

Last edited: 2004-11-13 14:41

 I had a small idea for gline-email...

Unreal should add the gline-email following this process:

Receive GLINE from client or server
if the GLINE was not a TKL or a ULined nick, add the gline-email
write the gline to memory
broadcast to network (where applicable)

This will make each server responsable for adding its own gline-email to the gline. This basically just does not add the gline-email to GLINES done by TKL between servers, and from ULines (if for some reason they send an actual GLine), All this done BEFORE the Gline is added to the memory.

Dodge_Ram

2004-11-26 23:47

reporter   ~0008418

Personally, I actually see no use for this -- Why couldn't opers just add the email address to the end of their reason for their /*line?

Plasma

2004-11-27 00:50

reporter   ~0008419

Because people forget, and its a pain to have to tack that on if you dont remember.

Why is it so difficult to add a gline email directive if there is already one for kline.

Make the gline directive local, it does not have to be in sync with the rest of the network, leave it up to the admin's configuration to have all the gline emails the same on each server.

Surely this is not a difficult feature to add?

codemastr

2004-12-01 16:07

reporter   ~0008447

set::gline-address added in .199

Issue History

Date Modified Username Field Change
2003-10-13 04:32 Stealth New Issue
2003-10-13 10:18 AngryWolf Note Added: 0003812
2003-10-13 20:16 Stealth Note Added: 0003813
2004-10-24 22:11 Stealth Note Added: 0008106
2004-10-25 00:25 aquanight Note Added: 0008107
2004-10-26 10:17 syzop Note Added: 0008117
2004-10-26 14:00 Stealth Note Added: 0008119
2004-10-26 16:11 aquanight Note Added: 0008125
2004-10-26 16:12 aquanight Note Edited: 0008125
2004-10-26 16:16 syzop Note Added: 0008126
2004-10-27 23:53 Plasma Note Added: 0008137
2004-11-02 11:22 Zell Note Added: 0008215
2004-11-02 20:10 Plasma Note Added: 0008227
2004-11-03 16:31 Zell Note Added: 0008244
2004-11-03 18:50 Plasma Note Added: 0008247
2004-11-04 01:49 aquanight Note Added: 0008248
2004-11-13 14:29 Stealth Note Added: 0008321
2004-11-13 14:41 Stealth Note Edited: 0008321
2004-11-26 23:47 Dodge_Ram Note Added: 0008418
2004-11-27 00:50 Plasma Note Added: 0008419
2004-11-28 13:17 codemastr Status new => assigned
2004-11-28 13:17 codemastr Assigned To => codemastr
2004-12-01 15:34 codemastr Summary kline address => set::gline-address
2004-12-01 16:07 codemastr Status assigned => resolved
2004-12-01 16:07 codemastr Fixed in Version => 3.2.3
2004-12-01 16:07 codemastr Resolution open => fixed
2004-12-01 16:07 codemastr Note Added: 0008447