Anzeige:
test
Anzeige:

Uncategorised

Stern inaktivStern inaktivStern inaktivStern inaktivStern inaktiv

The Client-To-Client Protocol (CTCP)

 

CTCP - Bezug Internet Relay Chat

 

 

Quelle: http://irchelp.org/irchelp/rfc/ctcpspec.html

 

The Client-To-Client Protocol (CTCP)
Klaus Zeuge <Diese E-Mail-Adresse ist vor Spambots geschützt! Zur Anzeige muss JavaScript eingeschaltet sein!>
Troy Rollo <Diese E-Mail-Adresse ist vor Spambots geschützt! Zur Anzeige muss JavaScript eingeschaltet sein!>
Ben Mesander <Diese E-Mail-Adresse ist vor Spambots geschützt! Zur Anzeige muss JavaScript eingeschaltet sein!>


The Client-To-Client Protocol is meant to be used as a way to
1/ in general send structured data (such as graphics,
voice and different font information) between users
clients, and in a more specific case:
2/ place a query to a users client and getting an answer.

 

 

*****************************************
BASIC PROTOCOL BETWEEN CLIENTS AND SERVER
*****************************************

Characters between an Internet Relay Chat (IRC) client and server are
8 bit bytes (also known as octets) and can have numeric values from
octal \000 to \377 inclusive (0 to 255 decimal). Some characters are
special:

CHARS ::= '\000' .. '\377' 
NUL ::= '\000'
NL ::= '\n'
CR ::= '\r'

Note: `\' followed by three digits is used to denote an octal value in this
paper. `\' followed by an alphabetic character is used to denote a C
language style special character, and `..' denotes a range of characters.

A line sent to a server, or received from a server (here called "low
level messages") consist or zero or more octets (expcept NUL, NL or
CR) with either a NL or CR appended.

L-CHARS ::= '\001' .. '\011' | '\013' | '\014' |
'\016' .. '\377'
L-LINE ::= L-CHARS* CR LF

Note: The `*' is used here to denote "zero or more of the preceding class of 
characters", and the `|' is used to denote alternation.

A NUL is never sent to the server.

*****************
LOW LEVEL QUOTING
*****************

Even though messages to and from IRC servers cannot contain NUL, NL,
or CR, it still might be desirable to send ANY character (in so called
"middle level messages") between clients. In order for this to be
possible, those three characters have to be quoted. Therefore a quote
character is needed. Of course, the quote character itself has to be
quoted too, since it is in-band.

M-QUOTE ::= '\020'

(Ie a CNTRL/P).

When sending a middle level message, if there is a character in the
set { NUL, NL, CR, M-QUOTE } present in the message, that character is
replaced by a two character sequence according to the following table:

NUL --> M-QUOTE '0'
NL --> M-QUOTE 'n'
CR --> M-QUOTE 'r'
M-QUOTE --> M-QUOTE M-QUOTE

When receiving a low level message, if there is a M-QUOTE, look at the
next character, and replace those two according to the following table
to get the corresponding middle level message:

M-QUOTE '0' --> NUL
M-QUOTE 'n' --> NL
M-QUOTE 'r' --> CR
M-QUOTE M-QUOTE --> M-QUOTE

If the character following M-QUOTE is not any of the listed
characters, that is an error, so drop the M-QUOTE character from the
message, optionally warning the user about it. For example, a string
'x' M-QUOTE 'y' 'z' from a server dequotes into 'x 'y' 'z'.

Before low level quoting, a message to the server (and in the opposite
direction: after low level dequoting, a message from the server) looks
like:

M-LINE ::= CHARS*

***********
TAGGED DATA
***********

To send both extended data and query/reply pairs between clients, an
extended data format is needed. The extended data are sent in the text
part of a middle level message (and after low level quoting, in the
text part of the low level message).

To send extended data inside the middle level message, we need some
way to delimit it. This is done by starting and ending extended data
with a delimiter character, defined as:

X-DELIM ::= '\001'

As both the starting and ending delimiter looks the same, the first
X-DELIM is called the odd delimiter, and the one that follows, the
even delimiter. The next one after that, an odd delimiter, then and
even, and so on.

When data are quoted (and conversely, before being dequoted) any number
of characters of any kind except X-DELIM can be used in the extended
data inside the X-DELIM pair.

X-CHR ::= '\000' | '\002' .. '\377'

An extended message is either empty (nothing between the odd and even
delimiter), has one or more non-space characters (any character but
'\040') or has one or more non-space characters followed by a space
followed by zero or more characters.

X-N-AS ::= '\000' | '\002' .. '\037' | '\041' .. '\377'
SPC ::= '\040'
X-MSG ::= | X-N-AS+ | X-N-AS+ SPC X-CHR*

Note: Here `+' is used to denote "one or more of the previous class of 
characters", and `*' is used to denote "zero or more of the previous 
class of characters".

The characters up until the first SPC (or if no SPC, all of the X-MSG)
is called the tag of the extended message. The tag is used to denote
what kind of extended data is used.

The tag can be *any* string of characters, and if it contains
alphabetics, it is case sensitive, so upper and lower case matters.

Extended data is only valid in PRIVMSG and NOTICE commands. If the
extended data is a reply to a query, it is sent in a NOTICE, otherwise
it is sent in a PRIVMSG. Both PRIVMSG and NOTICE to a user and to a
channel may contain extended data.

The text part of a PRIVMSG or NOTICE might contain zero or more
extended messages, intermixed with zero or more chunks of non-extended
data.

******************
CTCP LEVEL QUOTING
******************

In order to be able to send the delimiter X-DELIM inside an extended
data message, it has to be quoted. This introduces another quote
character (which differs from the low level quote character so it
won't have to be quoted yet again).

X-QUOTE ::= '\134'

(a back slash - `\').

When quoting on the CTCP level, only the actual CTCP message (extended
data, queries, replies) are quoted. This enables users to actually
send X-QUOTE characters at will. The following translations should be
used:

X-DELIM --> X-QUOTE 'a'
X-QUOTE --> X-QUOTE X-QUOTE

and when dequoting on the CTCP level, only CTCP messages are dequoted
whereby the following table is used.

X-QUOTE 'a' --> X-DELIM
X-QUOTE X-QUOTE --> X-QUOTE

If an X-QUOTE is seen with a character following it other than the
ones above, that is an error and the X-QUOTE character should be
dropped. For example the CTCP-quoted string 'x' X-QUOTE 'y' 'z'
becomes after dequoting, the three character string 'x' 'y' 'z'.

If a X-DELIM is found outside a CTCP message, the message will contain
the X-DELIM. (This should only happen with the last X-DELIM when there
are an odd number of X-DELIM's in a middle level message.)

****************
QUOTING EXAMPLES
****************

There are three levels of messages. The highest level (H) is the text
on the user-to-client level. The middle layer (M) is on the level
where CTCP quoting has been applied to the H-level message. The lowest
level (L) is on the client-to-server level, where low level quoting
has been applied to the M-level message.

The following relations are true, with lowQuote(message) being a
function doing the low level quoting, lowDequote(message) the low
level dequoting function, ctcpQuote(message) the CTCP level quoting
function, ctcpDequote(message) the CTCP level dequoting function, and
ctcpExtract(message) the function which removes all CTCP messages from
a message:

L = lowQuote(M)
M = ctcpDequote(L)

M = ctcpQuote(H)
H = ctcpDequote(ctcpExtract(M))

When sending a CTCP message embedded in normal text:

M = ctcpQuote(H1) || '\001' || ctcpQuote(X) || '\001' || ctcpQuote(H2)

Note: The operator || denotes string concatenation.

Of course, there might be zero or more normal text messages and zero
or more CTCP messages mixed.

- --- Example 1 -----------------------------------------------------------------

A user (called actor) wanting to send the string:

Hi there!\nHow are you?

to user victim, i.e. a message where the user has entered an inline
newline (how this is done, if at all, differs from client to client),
will result internaly in the client in the command:

PRIVMSG victim :Hi there!\nHow are you? \K?

which will be CTCP quoted into:

PRIVMSG victim :Hi there!\nHow are you? \\K?

which in turn will be low level quoted into:

PRIVMSG victim :Hi there!\020nHow are you? \\K?

and sent to the server after appending a newline at the end.

This will arrive on victim's side as:

:actor PRIVMSG victim :Hi there!\020nHow are you? \\K?

(where the \\K would look similar to OK in SIS D47 et. al.) which after
low level dequoting becomes:

:actor PRIVMSG victim :Hi there!\nHow are you? \\K?

and after CTCP dequoting:

:actom PRIVMSG victim :Hi there!\nHow are you? \K?

How this is displayed differs from client to client, but it suggested
that a line break should occour between the words "there" and "How".

- --- Example 2 -----------------------------------------------------------------

If actor's client wants to send the string "Emacs wins" this might
become the string "\n\t\big\020\001\000\\:" when being SED-encrypted
[SED is a simple encryption protocol between IRC clients implemented
with CTCP. I don't have any reference for it -- Ben] using some key,
so the client starts by CTCP-quoting this string into the string
"\n\t\big\020\\a\000\\\\:" and builds the M-level message:

PRIVMSG victim :\001SED \n\t\big\020\\a\000\\\\:\001

which after low level quoting becomes:

PRIVMSG victim :\001SED \020n\t\big\020\020\\a\0200\\\\:\001

which will be sent to the server, with a newline tacked on.

On victim's side, the string:

:actor PRIVMSG victim :\001SED \020n\t\big\020\020\\a\0200\\\\:\001

will be received from the server and low level dequoted into:

:actor PRIVMSG victim :\001SED \n\t\big\020\\a\000\\\\:\001

whereafter the string "\n\t\big\020\\a\000\\\\:" will be extracted
and first CTCP dequoted into "\n\t\big\020\001\000\\:" and then
SED decoded getting back "Emacs wins" when using the same key.

- --- Example 3 -----------------------------------------------------------------

If the user actor wants to query the USERINFO of user victim, and is
in the middle of a conversation, the client may decide to tack on
USERINFO request on the end of a normal text message. Let's say actor
wants to send the textmessage "Say hi to Ron\n\t/actor" and the CTCP
request "USERINFO" to victim:

PRIVMSG victim :Say hi to Ron\n\t/actor

plus:

USERINFO

which after CTCP quoting become:

PRIVMSG victim :Say hi to Ron\n\t/actor

plus:

USERINFO

which gets merged into:

PRIVMSG victim :Say hi to Ron\n\t/actor\001USERINFO\001

and after low level quoting:

PRIVMSG victim :Say hi to Ron\020n\t/actor\001USERINFO\001

and sent off to the server.

On victim's side, the message:

:actor PRIVMSG victim :Say hi to Ron\020n\t/actor\001USERINFO\001

arrives. This gets low level dequoted into:

:actor PRIVMSG victim :Say hi to Ron\n\t/actor\001USERINFO\001

and thereafter split up into:

:actor PRIVMSG victim :Say hi to Ron\n\t/actor

plus:

USERINFO

After CTCP dequoting both, the message:

:actor PRIVMSG victim :Say hi to Ron\n\t/actor

gets displayed, while the CTCP command:

USERINFO

gets replied to. The reply might be:

USERINFO :CS student\n\001test\001

which gets CTCP quoted into:

USERINFO :CS student\n\\atest\\a

and sent in a NOTICE as it is a reply:

NOTICE actor :\001USERINFO :CS student\n\\atest\\a\001

and low level quoted into:

NOTICE actor :\001USERINFO :CS student\020n\\atest\\a\001

after which is it sent to victim's server.

When arriving on actor's side, the message:

:victim NOTICE actor :\001USERINFO :CS student\020n\\atest\\a\001

gets low level dequoted into:

:victim NOTICE actor :\001USERINFO :CS student\n\\atest\\a\001

At this point, all CTCP replies get extracted, giving 1 CTCP reply and
no normal NOTICE:

USERINFO :CS student\n\\atest\\a

The remaining reply gets CTCP dequoted into:

USERINFO :CS student\n\001test\001

and presumly displayed to user actor.

*******************
KNOWN EXTENDED DATA
*******************

Extended data passed between clients can be used to pass structured
information between them. Currently known extended data types are:

ACTION - Used to simulate "role playing" on IRC.
DCC - Negotiates file transfers and direct tcp chat 
connections between clients.
SED - Used to send encrypted messages between clients.

ACTION
======
This is used by losers on IRC to simulate "role playing" games. An
action message looks like the following:

\001ACTION barfs on the floor.\001

Clients that recieve such a message should format them to indicate the
user who did this is performing an "action". For example, if the user
"actor" sent the above message to the channel "#twilight_zone", other
users clients might display the message as:

[ACTION] actor->#twilight_zone: barfs on the floor.

Presumably other users on the channel are suitably impressed.

DCC
=== 
DCC stands for something like "Direct Client Connection". CTCP DCC
extended data messages are used to negotiate file transfers between
clients and to negotiate chat connections over tcp connections between
two clients, with no IRC server involved. Connections between clients
involve protocols other than the usual IRC protocol. Due to this
complexity, a full description of the DCC protocol is included
separately at the end of this document in Appendix A.

SED
===
SED probably stands for something like "Simple Encryption D???". It is
used by clients to exchange encrypted messages between clients. A
message encoded by SED probably looks something like:

\001SED encrypted-text-goes-here\001

Clients which accept such messages should display them in decrypted
form. It would be nice if someone documented this, and included the
encryption scheme in an Appendix B.

*************************
KNOWN REQUEST/REPLY PAIRS
*************************

A request/reply pair is sent between the two clients in two phases.
The first phase is to send the request. This is done with a "privmsg"
command (either to a nick or to a channel -- it doesn't matter).

The second phase is to send a reply. This is done with a "notice"
command.

 

 

The known request/reply pairs are for the following commands.

FINGER - Returns the user's full name, and idle time.
VERSION - The version and type of the client.
SOURCE - Where to obtain a copy of a client.
USERINFO - A string set by the user (never the client coder)
CLIENTINFO - Dynamic master index of what a client knows.
ERRMSG - Used when an error needs to be replied with.
PING - Used to measure the delay of the IRC network
between clients.
TIME - Gets the local date and time from other clients.

FINGER
======
This is used to get a user's real name, and perhaps also the idle time
of the user (this usage has been obsoleted by enhancements to the IRC
protocol. The request is in a "privmsg" and looks like

\001FINGER\001

while the reply is in a "notice" and looks like

\001FINGER :#\001

where the # denotes contains information about the users real name,
login name at clientmachine and idle time and is of type X-N-AS.

VERSION
=======
This is used to get information about the name of the other client and
the version of it. The request in a "privmsg" is simply

\001VERSION\001

and the reply

\001VERSION #:#:#\001

where the first # denotes the name of the client, the second # denotes
the version of the client, the third # the enviroment the client is
running in.

Using

X-N-CLN ::= '\000' .. '\071' | '\073' .. '\377'

the client name is a string of type X-N-CLN saying things like "Kiwi"
or "ircII", the version saying things like "5.2" or "2.1.5c", the
enviroment saying things like "GNU Emacs 18.57.19 under SunOS 4.1.1 on
Sun SLC" or "Compiled with gcc -ansi under Ultrix 4.0 on VAX-11/730".


SOURCE

This is used to get information about where to get a copy of the
client. The request in a "privmsg" is simply

\001SOURCE\001

and the reply is zero or more CTCP replies of the form

\001SOURCE #:#:#\001

followed by an end marker

\001SOURCE\001

where the first # is the name of an Internet host where the client can
be gotten from with anonymous FTP the second # a directory names, and
the third # a space separated list of files to be gotten from that
directory.

Using

X-N-SPC ::= '\000' .. '\037' | '\041' .. '\377'

the name of the FTP site is to be given by name like "cs.bu.edu" or
"funic.funet.fi".

The file name field is a directory specification optionally followed
by one or more file names, delimited by spaces. If only a directory
name is given, all files in that directory should be copied when
retrieving the clients source. If some files are given, only those
files in that directpry should be copied. Note that the spcification
allows for all characters but space in the names, this includes
allowing :. Examples are "pub/emacs/irc/" to get all files in
directory pub/emacs/irc/, the client should be able to first login as
user "ftp" and the give the command "CD pub/emacs/irc/", followed by
the command "mget *". (It of course has to take care of binary and
prompt mode too). Another example is "/pub/irc Kiwi.5.2.el.Z" in which
case a "CD /pub/irc" and "get Kiwi.5.2.el.Z" is what should be done.


USERINFO
========
This is used to transmit a string which is settable by the user (and
never should be set by the client). The query is simply

\001USERINFO\001

with the reply

\001USERINFO :#\001

where the # is the value of the string the client's user has set.

CLIENTINFO
==========
This is for client developers use to make it easier to show other
client hackers what a certain client knows when it comes to CTCP. The
replies should be fairly verbose explaining what CTCP commands are
understood, what arguments are expected of what type, and what replies
might be expected from the client.

The query is the word CLIENTINFO in a "privmsg" optionally followed by
a colon and one or more specifying words delimited by spaces, where
the word CLIENTINFO by itself,

\001CLIENTINFO\001

should be replied to by giving a list of known tags (see above in
section TAGGED DATA). This is only intended to be read by humans.

With one argument, the reply should be a description of how to use
that tag. With two arguments, a description of how to use that
tag's subcommand. And so on.

ERRMSG
======
This is used as a reply whenever an unknown query is seen. Also, when
used as a query, the reply should echo back the text in the query,
together with an indication that no error has happened. Should the
query form be used, it is

\001ERRMSG #\001

where # is a string containing any character, with the reply

\001ERRMSG # :#\001

where the first # is the same string as in the query and the second #
a short text notifying the user that no error has occurred.

A normal ERRMSG reply which is sent when a corrupted query or some
corrupted extended data is received, looks like

\001ERRMSG # :#\001

where the first # is the the failed query or corrupted extended data
and the second # a text explaining what the problem is, like "unknown
query" or "failed decrypting text".

PING
====
Ping is used to measure the time delay between clients on the IRC
network. A ping query is encoded in a privmsg, and has the form:

\001PING timestamp\001

where `timestamp' is the current time encoded in any form the querying
client finds convienent. The replying client sends back an identical
message inside a notice:

\001PING timestamp\001

The querying client can then subtract the recieved timestamp from the
current time to obtain the delay between clients over the IRC network.

TIME
====
Time queries are used to determine what time it is where another
user's client is running. This can be useful to determine if someone
is probably awake or not, or what timezone they are in. A time query
has the form:

\001TIME\001

On reciept of such a query in a privmsg, clients should reply with a
notice of the form:

\001TIME :human-readable-time-string\001

For example:

\001TIME :Thu Aug 11 22:52:51 1994 CST\001

********
EXAMPLES
********


Sending

PRIVMSG victim :\001FINGER\001

might return

:victim NOTICE actor :\001FINGER :Please check my USERINFO
instead :Klaus Zeuge (sojge@mizar) 1 second has passed since
victim gave a command last.\001

(this is only one line) or why not

:victim NOTICE actor :\001FINGER :Please check my USERINFO
instead :Klaus Zeuge (sojge@mizar) 427 seconds (7 minutes and
7 seconds) have passed since victim gave a command last.\001

if Klaus Zeuge happens to be lazy? :-)

Sending

PRIVMSG victim :\001CLIENTINFO\001

might return

:victim NOTICE actor :\001CLIENTINFO :You can request help of the
commands CLIENTINFO ERRMSG FINGER USERINFO VERSION by giving
an argument to CLIENTINFO.\001

Sending

PRIVMSG victim :\001CLIENTINFO CLIENTINFO\001

might return

:victim NOTICE actor :\001CLIENTINFO :CLIENTINFO with 0
arguments gives a list of known client query keywords. With 1
argument, a description of the client query keyword is
returned.\001

while sending

PRIVMSG victim :\001clientinfo clientinfo\001

probably will return something like

:victim NOTICE actor :\001ERRMSG clientinfo clientinfo :Query is
unknown\001

as tag "clientinfo" isn't known.

Sending

PRIVMSG victim :\001CLIENTINFO ERRMSG\001

might return

:victim NOTICE actor :\001CLIENTINFO :ERRMSG is the given answer
on seeing an unknown keyword. When seeing the keyword ERRMSG,
it works like an echo.\001

Sending

PRIVMSG victim :\001USERINFO\001

might return the somewhat pathetically long

:victim NOTICE actor :\001USERINFO :I'm studying computer
science in Uppsala, I'm male (somehow, that seems to be an
important matter on IRC:-) and I speak fluent swedish, decent
german, and some english.\001

Sending

PRIVMSG victim :\001VERSION\001

might return:

:victim NOTICE actor :\001VERSION Kiwi:5.2:GNU Emacs
18.57.19 under SunOS 4.1.1 on Sun
SLC:FTP.Lysator.LiU.SE:/pub/emacs Kiwi-5.2.el.Z
Kiwi.README\001

if the client is named Kiwi of version 5.2 and is used under GNU Emacs
18.57.19 running on a Sun SLCwith SunOS 4.1.1. The client claims a
copy of it can be found with anonymous FTP on FTP.Lysator.LiU.SE after
giving the FTP command "cd /pub/emacs/". There, one should get files
Kiwi-5.2.el.Z and Kiwi.README; presumably one of the files tells how to
proceed with building the client after having gotten the files.

--------------------------------------------------------------------------------

**********************************************************************
Appendix A -- A description of the DCC protocol
**********************************************************************

By Troy Rollo (Diese E-Mail-Adresse ist vor Spambots geschützt! Zur Anzeige muss JavaScript eingeschaltet sein!)
Revised by Ben Mesander (Diese E-Mail-Adresse ist vor Spambots geschützt! Zur Anzeige muss JavaScript eingeschaltet sein!)

Troy Rollo, the original implementor of the DCC protocol, said
that the DCC protocol was never designed to be portable to clients
other than IRCII. However, time has shown that DCC is useable in
environments other than IRCII. IRC clients in diverse languages, such
as ksh, elisp, C, and perl have all had DCC implementations.

Why DCC?
========

DCC allows the user to overcome some limitations of the IRC
server network and to have a somewhat more secure chat connection
while still in an IRC-oriented protocol.

DCC uses direct TCP connections between the clients taking
part to carry data. There is no flood control, so packets can be sent
at full speed, and there is no dependance on server links (or load
imposed on them). In addition, since only the initial handshake for
DCC conections is passed through the IRC network, it makes it harder
for operators with cracked servers to spy on personal messages.

How?
====

The initial socket for a DCC connection is created
by the side that initiates (Offers) the connection. This socket
should be a TCP socket bound to INADDR_ANY, listening for
connections.

The Initiating client, on creating the socket, should
send its details to the target client using the CTCP command
DCC. This command takes the form:

DCC type argument address port [size]

type - The connection type.
argument - The connectin type dependant argument.
address - The host address of the initiator as an integer.
port - The port or the socket on which the initiator expects
to receive the connection.
size - If the connection type is "SEND" (see below), then size
will indicate the size of the file being offered. Obsolete
IRCII clients do not send this, so be prepared if this is
not present.

The address, port, and size should be sent as ASCII representations of
the decimal integer formed by converting the values to host byte order
and treating them as an unsigned long, unsigned short, and unsigned
long respectively.

Implementations of the DCC protocol should be prepared to
accept further arguments in a CTCP DCC message. There has been some
discussion of adding another argument that would specify the type of
file being transferred - text, binary, and perhaps others if DCC is
implemented on operating systems other than UNIX. If additional
arguments are added to the protocol, they should have semantics such
that clients which ignore them will interoperate with clients that
don't in a sensible way.

The following DCC connection types are defined:

Type Purpose Argument
CHAT To carry on a semi-secure conversation the string "chat"
SEND To send a file to the recipient the file name

Although the following subcommand is included in the IRCII DCC command,
it does _not_ transmit a DCC request via IRC, and thus is not
discussed in this document:

TALK Establishes a TALK connection


Implementation
==============

The CHAT and SEND connection types should not be
accepted automatically as this would create the potential for
terrorism. Instead, they should notify the user that an
offer has been made, and allow the user to accept it.

The recipient should have the opportunity to rename a file
offered with the DCC SEND command prior to retrieving it. It is also
desirable to ensure that the offered file will not overwrite an
existing file.

Older IRCII clients send the entire pathname of the file being
transmitted. This is annoying, and newer clients should simply send
the filename portion of the file being transmitted.

The port number should be scrutinized - if the port number is
in the UNIX reserved port range, the connection should only be
accepted with caution.

If it is not possible in the client implementation language to
handle a 32-bit integer (for instance emacs 18 elisp and ksh 88), then
it is often possible to use the hostname in the originating PRIVMSG.

The following are the steps which should occur in the clients
(this description assumes use of the BSD socket interface on a UNIX
system).

Initiator:
DCC command issued.
Create a socket, bind it to INADDR_ANY, port 0, and
make it passive (a listening socket).
Send the recipient a DCC request via CTCP supplying
the address and port of the socket. (This
is ideally taken from the address of the local
side of the socket which is connected to a
server. This is presumably the interface on
the host which is closest to the rest of
the net, and results in one less routing hop
in the case of gateway nodes).
Continue normally until a connection is received.

On a connection:
Accept the connection.
Close the original passive socket.
Conduct transaction on the new socket.

Acceptor:
CTCP DCC request received.
Record information on the DCC request and notify the user.

At this point, the USER should be able to abort (close) the
request, or accept it. The request should be accepted with
a command specifying the sender, type, and argument, or
a subset of these where no ambiguity exists.

If accepted, create a TCP socket.
Connect the new socket to the address and port supplied.
Conduct the transaction over the socket.


Type specific details.
======================

CHAT Data sent across a CHAT connection should be sent line-by-line
without any prefixes or commands. A CHAT connection ends when
one party issues the DCC CLOSE command to their clients, which
causes the socket to be closed and the information on the connection
to be discarded. The terminating character of each line is a 
newline character, '\n'.

FILE Data is sent in packets, rather than dumped in a stream manner.
This allows the DCC SEND connection to survive where an FTP
connection might fail. The size of the packets is up to the
client, and may be set by the user. Smaller packets result
in a higher probability of survival over bad links.
The recipient should acknowledge each packet by transmitting
the total number of bytes received as an unsigned, 4 byte
integer in network byte order. The sender should not continue
to transmit until the recipient has acknowledged all data
already transmitted. Additionally, the sender should not
close the connection until the last byte has been
acknowledged by the recipient.

Older IRCII clients do not send the file size of the file
being transmitted via DCC. For those clients, note that it is
not possible for the recipient to tell if the entire file has
been received - only the sender has that information, although
IRCII does not report it. Users generally verify the transfer
by checking file sizes. Authors of clients are urged to use
the size feature.

Note also that no provision is made for text translation.

The original block size used by IRCII was 1024. Other clients
have adopted this. Note, however, that an implementation should accept
any blocksize. IRCII currently allows a user-settable blocksize.

 

Stern inaktivStern inaktivStern inaktivStern inaktivStern inaktiv

RFC2813

 

RFC 2813 Internet Relay Chat: Server Protocol 

 

Vorwort:

Was sind RFC's ? (Quelle: http://www1.tfh-berlin.de/~s715053/vsg_ub2.html ) 



Zunächst ist RFC eine Abkürzung für den englischen Begriff "Request for Comments", also eine Kommentar-Anforderung. RFCs sind eine Form von Diskussionspapieren, in denen technische Komponenten wie zum Beispiel die Architektur des Internets, der Aufbau von Protokollen, die Form von eMail-Headern usw. erklärt werden. Unter anderem werden alle verfügbaren Internet-Standards in RFC-Dokumenten veröffentlicht. Prinzipiell kann jeder Autor RFC-Dokumente schreiben. 
Alle so genannten Internet Standards sind zwar als RFCs veröffentlicht, aber nur ein kleiner Teil der RFCs sind echte Standards. RFCs sind eine durchnummerierte Serie von Dokumenten, die verschiedene tatsächliche und vorgeschlagene Gewohnheiten beschreiben, die einen Bezug zum Internet haben und von der IETF herausgegeben werden. Die Sammlung ist sowohl hinsichtlich des Themas, als auch des so genannten Status, uneinheitlich. Viele RFCs behandeln technische Festsetzungen und Übereinkommen - die Protokolle.
Protokolle sind für die Zusammenarbeit der Systeme unentbehrlich; Programme, die untereinander Daten austauschen, müssen auf einigen Übereinstimmungen hinsichtlich des Datenformates und verwandten Themen beruhen.
• geschichtliche Informationen zu den RFCs: RFC 2555

Wozu werden RFC-Dokumente gebraucht (Quelle: http://www1.tfh-berlin.de/~s715053/vsg_ub2.html )

RFC-Dokumente können gebraucht werden, um zum Beispiel festzustellen, ob eine Anwendung, ein Protokoll oder eine Funktion einem der in den RFCs veröffentlichten Internet-Standards entspricht. Auf die Weise kann zum Beispiel festgestellt werden, ob ein eMail-Client sich an die Vorgaben der RFC hält oder nicht. Die Erarbeitung dieser Standards liegt in der Verantwortung der ISOC. Das heißt, es werden Vorgaben erarbeitet, die für Implementierungen benutzt werden können und sollen.
Aufgaben der ISOC unter: ISOC

Wo finde ich weitere RFC-Dokumente ?
http://www.rfc-editor.org/

 

RFC 2813 Internet Relay Chat: Server Protocol

 


Network Working Group C. Kalt
Request for Comments: 2813 April 2000
Updates: 1459
Category: Informational


Internet Relay Chat: Server Protocol

Status of this Memo

This memo provides information for the Internet community. It does
not specify an Internet standard of any kind. Distribution of this
memo is unlimited.

Copyright Notice

Copyright (C) The Internet Society (2000). All Rights Reserved.

Abstract

While based on the client-server model, the IRC (Internet Relay Chat)
protocol allows servers to connect to each other effectively forming
a network.

This document defines the protocol used by servers to talk to each
other. It was originally a superset of the client protocol but has
evolved differently.

First formally documented in May 1993 as part of RFC 1459 [IRC], most
of the changes brought since then can be found in this document as
development was focused on making the protocol scale better. Better
scalability has allowed existing world-wide networks to keep growing
and reach sizes which defy the old specification.

 

 

 

 

 

 

 

 


Kalt Informational [Page 1]

RFC 2813 Internet Relay Chat: Server Protocol April 2000


Table of Contents

1. Introduction ............................................... 3
2. Global database ............................................ 3
2.1 Servers ................................................ 3
2.2 Clients ................................................ 4
2.2.1 Users ............................................. 4
2.2.2 Services .......................................... 4
2.3 Channels ............................................... 4
3. The IRC Server Specification ............................... 5
3.1 Overview ............................................... 5
3.2 Character codes ........................................ 5
3.3 Messages ............................................... 5
3.3.1 Message format in Augmented BNF ................... 6
3.4 Numeric replies ........................................ 7
4. Message Details ............................................ 7
4.1 Connection Registration ................................ 8
4.1.1 Password message .................................. 8
4.1.2 Server message .................................... 9
4.1.3 Nick .............................................. 10
4.1.4 Service message ................................... 11
4.1.5 Quit .............................................. 12
4.1.6 Server quit message ............................... 13
4.2 Channel operations ..................................... 14
4.2.1 Join message ...................................... 14
4.2.2 Njoin message ..................................... 15
4.2.3 Mode message ...................................... 16
5. Implementation details .................................... 16
5.1 Connection 'Liveness' .................................. 16
5.2 Accepting a client to server connection ................ 16
5.2.1 Users ............................................. 16
5.2.2 Services .......................................... 17
5.3 Establishing a server-server connection. ............... 17
5.3.1 Link options ...................................... 17
5.3.1.1 Compressed server to server links ............ 18
5.3.1.2 Anti abuse protections ....................... 18
5.3.2 State information exchange when connecting ........ 18
5.4 Terminating server-client connections .................. 19
5.5 Terminating server-server connections .................. 19
5.6 Tracking nickname changes .............................. 19
5.7 Tracking recently used nicknames ....................... 20
5.8 Flood control of clients ............................... 20
5.9 Non-blocking lookups ................................... 21
5.9.1 Hostname (DNS) lookups ............................ 21
5.9.2 Username (Ident) lookups .......................... 21
6. Current problems ........................................... 21
6.1 Scalability ............................................ 21
6.2 Labels ................................................. 22

 

Kalt Informational [Page 2]

RFC 2813 Internet Relay Chat: Server Protocol April 2000


6.2.1 Nicknames ......................................... 22
6.2.2 Channels .......................................... 22
6.2.3 Servers ........................................... 22
6.3 Algorithms ............................................. 22
7. Security Considerations .................................... 23
7.1 Authentication ......................................... 23
7.2 Integrity .............................................. 23
8. Current support and availability ........................... 24
9. Acknowledgements ........................................... 24
10. References ................................................ 24
11. Author's Address .......................................... 25
12. Full Copyright Statement ................................... 26

1. Introduction

This document is intended for people working on implementing an IRC
server but will also be useful to anyone implementing an IRC service.

Servers provide the three basic services required for realtime
conferencing defined by the "Internet Relay Chat: Architecture"
[IRC-ARCH]: client locator (via the client protocol [IRC-CLIENT]),
message relaying (via the server protocol defined in this document)
and channel hosting and management (following specific rules [IRC-
CHAN]).

2. Global database

Although the IRC Protocol defines a fairly distributed model, each
server maintains a "global state database" about the whole IRC
network. This database is, in theory, identical on all servers.

2.1 Servers

Servers are uniquely identified by their name which has a maximum
length of sixty three (63) characters. See the protocol grammar
rules (section 3.3.1) for what may and may not be used in a server
name.

Each server is typically known by all other servers, however it is
possible to define a "hostmask" to group servers together according
to their name. Inside the hostmasked area, all the servers have a
name which matches the hostmask, and any other server with a name
matching the hostmask SHALL NOT be connected to the IRC network
outside the hostmasked area. Servers which are outside the area have
no knowledge of the individual servers present inside the area,
instead they are presented with a virtual server which has the
hostmask for name.

 


Kalt Informational [Page 3]

RFC 2813 Internet Relay Chat: Server Protocol April 2000


2.2 Clients

For each client, all servers MUST have the following information: a
netwide unique identifier (whose format depends on the type of
client) and the server to which the client is connected.

2.2.1 Users

Each user is distinguished from other users by a unique nickname
having a maximum length of nine (9) characters. See the protocol
grammar rules (section 3.3.1) for what may and may not be used in a
nickname. In addition to the nickname, all servers MUST have the
following information about all users: the name of the host that the
user is running on, the username of the user on that host, and the
server to which the client is connected.

2.2.2 Services

Each service is distinguished from other services by a service name
composed of a nickname and a server name. The nickname has a maximum
length of nine (9) characters. See the protocol grammar rules
(section 3.3.1) for what may and may not be used in a nickname. The
server name used to compose the service name is the name of the
server to which the service is connected. In addition to this
service name all servers MUST know the service type.

Services differ from users by the format of their identifier, but
more importantly services and users don't have the same type of
access to the server: services can request part or all of the global
state information that a server maintains, but have a more restricted
set of commands available to them (See "IRC Client Protocol" [IRC-
CLIENT] for details on which) and are not allowed to join channels.
Finally services are not usually subject to the "Flood control"
mechanism described in section 5.8.

2.3 Channels

Alike services, channels have a scope [IRC-CHAN] and are not
necessarily known to all servers. When a channel existence is known
to a server, the server MUST keep track of the channel members, as
well as the channel modes.

 

 

 

 


Kalt Informational [Page 4]

RFC 2813 Internet Relay Chat: Server Protocol April 2000


3. The IRC Server Specification

3.1 Overview

The protocol as described herein is for use with server to server
connections. For client to server connections, see the IRC Client
Protocol specification.

There are, however, more restrictions on client connections (which
are considered to be untrustworthy) than on server connections.

3.2 Character codes

No specific character set is specified. The protocol is based on a a
set of codes which are composed of eight (8) bits, making up an
octet. Each message may be composed of any number of these octets;
however, some octet values are used for control codes which act as
message delimiters.

Regardless of being an 8-bit protocol, the delimiters and keywords
are such that protocol is mostly usable from US-ASCII terminal and a
telnet connection.

Because of IRC's Scandinavian origin, the characters {}|^ are
considered to be the lower case equivalents of the characters []\~,
respectively. This is a critical issue when determining the
equivalence of two nicknames, or channel names.

3.3 Messages

Servers and clients send each other messages which may or may not
generate a reply. Most communication between servers do not generate
any reply, as servers mostly perform routing tasks for the clients.

Each IRC message may consist of up to three main parts: the prefix
(OPTIONAL), the command, and the command parameters (maximum of
fifteen (15)). The prefix, command, and all parameters are separated
by one ASCII space character (0x20) each.

The presence of a prefix is indicated with a single leading ASCII
colon character (':', 0x3b), which MUST be the first character of the
message itself. There MUST be NO gap (whitespace) between the colon
and the prefix. The prefix is used by servers to indicate the true
origin of the message. If the prefix is missing from the message, it
is assumed to have originated from the connection from which it was
received. Clients SHOULD not use a prefix when sending a message
from themselves; if they use one, the only valid prefix is the
registered nickname associated with the client.

 

Kalt Informational [Page 5]

RFC 2813 Internet Relay Chat: Server Protocol April 2000


When a server receives a message, it MUST identify its source using
the (eventually assumed) prefix. If the prefix cannot be found in
the server's internal database, it MUST be discarded, and if the
prefix indicates the message comes from an (unknown) server, the link
from which the message was received MUST be dropped. Dropping a link
in such circumstances is a little excessive but necessary to maintain
the integrity of the network and to prevent future problems. Another
common error condition is that the prefix found in the server's
internal database identifies a different source (typically a source
registered from a different link than from which the message
arrived). If the message was received from a server link and the
prefix identifies a client, a KILL message MUST be issued for the
client and sent to all servers. In other cases, the link from which
the message arrived SHOULD be dropped for clients, and MUST be
dropped for servers. In all cases, the message MUST be discarded.

The command MUST either be a valid IRC command or a three (3) digit
number represented in ASCII text.

IRC messages are always lines of characters terminated with a CR-LF
(Carriage Return - Line Feed) pair, and these messages SHALL NOT
exceed 512 characters in length, counting all characters including
the trailing CR-LF. Thus, there are 510 characters maximum allowed
for the command and its parameters. There is no provision for
continuation message lines. See section 5 for more details about
current implementations.

3.3.1 Message format in Augmented BNF

The protocol messages must be extracted from the contiguous stream of
octets. The current solution is to designate two characters, CR and
LF, as message separators. Empty messages are silently ignored,
which permits use of the sequence CR-LF between messages without
extra problems.

The extracted message is parsed into the components <prefix>,
<command> and list of parameters (<params>).

The Augmented BNF representation for this is found in "IRC Client
Protocol" [IRC-CLIENT].

The extended prefix (["!" user "@" host ]) MUST NOT be used in server
to server communications and is only intended for server to client
messages in order to provide clients with more useful information
about who a message is from without the need for additional queries.

 

 


Kalt Informational [Page 6]

RFC 2813 Internet Relay Chat: Server Protocol April 2000


3.4 Numeric replies

Most of the messages sent to the server generate a reply of some
sort. The most common reply is the numeric reply, used for both
errors and normal replies. The numeric reply MUST be sent as one
message consisting of the sender prefix, the three digit numeric, and
the target of the reply. A numeric reply is not allowed to originate
from a client; any such messages received by a server are silently
dropped. In all other respects, a numeric reply is just like a normal
message, except that the keyword is made up of 3 numeric digits
rather than a string of letters. A list of different replies is
supplied in "IRC Client Protocol" [IRC-CLIENT].

4. Message Details

All the messages recognized by the IRC server and client are
described in the IRC Client Protocol specification.

Where the reply ERR_NOSUCHSERVER is returned, it means that the
target of the message could not be found. The server MUST NOT send
any other replies after this error for that command.

The server to which a client is connected is required to parse the
complete message, returning any appropriate errors. If the server
encounters a fatal error while parsing a message, an error MUST be
sent back to the client and the parsing terminated. A fatal error
may follow from incorrect command, a destination which is otherwise
unknown to the server (server, client or channel names fit this
category), not enough parameters or incorrect privileges.

If a full set of parameters is presented, then each MUST be checked
for validity and appropriate responses sent back to the client. In
the case of messages which use parameter lists using the comma as an
item separator, a reply MUST be sent for each item.

In the examples below, some messages appear using the full format:

:Name COMMAND parameter list

Such examples represent a message from "Name" in transit between
servers, where it is essential to include the name of the original
sender of the message so remote servers may send back a reply along
the correct path.

The message details for client to server communication are described
in the "IRC Client Protocol" [IRC-CLIENT]. Some sections in the
following pages apply to some of these messages, they are additions
to the message specifications which are only relevant to server to

 

Kalt Informational [Page 7]

RFC 2813 Internet Relay Chat: Server Protocol April 2000


server communication, or to the server implementation. The messages
which are introduced here are only used for server to server
communication.

4.1 Connection Registration

The commands described here are used to register a connection with
another IRC server.

4.1.1 Password message

Command: PASS
Parameters: <password> <version> <flags> [<options>]

The PASS command is used to set a 'connection password'. The
password MUST be set before any attempt to register the connection is
made. Currently this means that servers MUST send a PASS command
before any SERVER command. Only one (1) PASS command SHALL be
accepted from a connection.

The last three (3) parameters MUST be ignored if received from a
client (e.g. a user or a service). They are only relevant when
received from a server.

The <version> parameter is a string of at least four (4) characters,
and up to fourteen (14) characters. The first four (4) characters
MUST be digits and indicate the protocol version known by the server
issuing the message. The protocol described by this document is
version 2.10 which is encoded as "0210". The remaining OPTIONAL
characters are implementation dependent and should describe the
software version number.

The <flags> parameter is a string of up to one hundred (100)
characters. It is composed of two substrings separated by the
character "|" (%x7C). If present, the first substring MUST be the
name of the implementation. The reference implementation (See
Section 8, "Current support and availability") uses the string "IRC".
If a different implementation is written, which needs an identifier,
then that identifier should be registered through publication of an
RFC. The second substring is implementation dependent. Both
substrings are OPTIONAL, but the character "|" is REQUIRED. The
character "|" MUST NOT appear in either substring.

Finally, the last parameter, <options>, is used for link options.
The only options defined by the protocol are link compression (using
the character "Z"), and an abuse protection flag (using the character

 

 

Kalt Informational [Page 8]

RFC 2813 Internet Relay Chat: Server Protocol April 2000


"P"). See sections 5.3.1.1 (Compressed server to server links) and
5.3.1.2 (Anti abuse protections) respectively for more information on
these options.

Numeric Replies:

ERR_NEEDMOREPARAMS ERR_ALREADYREGISTRED

Example:

PASS moresecretpassword 0210010000 IRC|aBgH$ Z

4.1.2 Server message

Command: SERVER
Parameters: <servername> <hopcount> <token> <info>

The SERVER command is used to register a new server. A new connection
introduces itself as a server to its peer. This message is also used
to pass server data over whole net. When a new server is connected
to net, information about it MUST be broadcasted to the whole
network.

The <info> parameter may contain space characters.

<hopcount> is used to give all servers some internal information on
how far away each server is. Local peers have a value of 0, and each
passed server increments the value. With a full server list, it
would be possible to construct a map of the entire server tree, but
hostmasks prevent this from being done.

The <token> parameter is an unsigned number used by servers as an
identifier. This identifier is subsequently used to reference a
server in the NICK and SERVICE messages sent between servers. Server
tokens only have a meaning for the point-to-point peering they are
used and MUST be unique for that connection. They are not global.

The SERVER message MUST only be accepted from either (a) a connection
which is yet to be registered and is attempting to register as a
server, or (b) an existing connection to another server, in which
case the SERVER message is introducing a new server behind that
server.

Most errors that occur with the receipt of a SERVER command result in
the connection being terminated by the destination host (target
SERVER). Because of the severity of such event, error replies are
usually sent using the "ERROR" command rather than a numeric.

 


Kalt Informational [Page 9]

RFC 2813 Internet Relay Chat: Server Protocol April 2000


If a SERVER message is parsed and it attempts to introduce a server
which is already known to the receiving server, the connection, from
which that message arrived, MUST be closed (following the correct
procedures), since a duplicate route to a server has been formed and
the acyclic nature of the IRC tree breaks. In some conditions, the
connection from which the already known server has registered MAY be
closed instead. It should be noted that this kind of error can also
be the result of a second running server, problem which cannot be
fixed within the protocol and typically requires human intervention.
This type of problem is particularly insidious, as it can quite
easily result in part of the IRC network to be isolated, with one of
the two servers connected to each partition therefore making it
impossible for the two parts to unite.

Numeric Replies:

ERR_ALREADYREGISTRED

Example:

SERVER test.oulu.fi 1 1 :Experimental server ; New server
test.oulu.fi introducing itself and
attempting to register.

:tolsun.oulu.fi SERVER csd.bu.edu 5 34 :BU Central Server ; Server
tolsun.oulu.fi is our uplink for
csd.bu.edu which is 5 hops away. The
token "34" will be used by
tolsun.oulu.fi when introducing new
users or services connected to
csd.bu.edu.

4.1.3 Nick

Command: NICK
Parameters: <nickname> <hopcount> <username> <host> <servertoken>
<umode> <realname>

This form of the NICK message MUST NOT be allowed from user
connections. However, it MUST be used instead of the NICK/USER pair
to notify other servers of new users joining the IRC network.

This message is really the combination of three distinct messages:
NICK, USER and MODE [IRC-CLIENT].

The <hopcount> parameter is used by servers to indicate how far away
a user is from its home server. A local connection has a hopcount of
0. The hopcount value is incremented by each passed server.

 

Kalt Informational [Page 10]

RFC 2813 Internet Relay Chat: Server Protocol April 2000


The <servertoken> parameter replaces the <servername> parameter of
the USER (See section 4.1.2 for more information on server tokens).

Examples:

NICK syrk 5 kalt millennium.stealth.net 34 +i :Christophe Kalt ; New
user with nickname "syrk", username
"kalt", connected from host
"millennium.stealth.net" to server
"34" ("csd.bu.edu" according to the
previous example).

:krys NICK syrk ; The other form of the NICK message,
as defined in "IRC Client Protocol"
[IRC-CLIENT] and used between
servers: krys changed his nickname to
syrk

4.1.4 Service message

Command: SERVICE
Parameters: <servicename> <servertoken> <distribution> <type>
<hopcount> <info>

The SERVICE command is used to introduce a new service. This form of
the SERVICE message SHOULD NOT be allowed from client (unregistered,
or registered) connections. However, it MUST be used between servers
to notify other servers of new services joining the IRC network.

The <servertoken> is used to identify the server to which the service
is connected. (See section 4.1.2 for more information on server
tokens).

The <hopcount> parameter is used by servers to indicate how far away
a service is from its home server. A local connection has a hopcount
of 0. The hopcount value is incremented by each passed server.

The <distribution> parameter is used to specify the visibility of a
service. The service may only be known to servers which have a name
matching the distribution. For a matching server to have knowledge
of the service, the network path between that server and the server
to which the service is connected MUST be composed of servers whose
names all match the mask. Plain "*" is used when no restriction is
wished.

The <type> parameter is currently reserved for future usage.

 

 

Kalt Informational [Page 11]

RFC 2813 Internet Relay Chat: Server Protocol April 2000


Numeric Replies:

ERR_ALREADYREGISTRED ERR_NEEDMOREPARAMS
ERR_ERRONEUSNICKNAME
RPL_YOURESERVICE RPL_YOURHOST
RPL_MYINFO

Example:

SERVICE Diese E-Mail-Adresse ist vor Spambots geschützt! Zur Anzeige muss JavaScript eingeschaltet sein! 9 *.fr 0 1 :French Dictionary r" registered on
server "9" is being announced to
another server. This service will
only be available on servers whose
name matches "*.fr".

4.1.5 Quit

Command: QUIT
Parameters: [<Quit Message>]

A client session ends with a quit message. The server MUST close the
connection to a client which sends a QUIT message. If a "Quit
Message" is given, this will be sent instead of the default message,
the nickname or service name.

When "netsplit" (See Section 4.1.6) occur, the "Quit Message" is
composed of the names of two servers involved, separated by a space.
The first name is that of the server which is still connected and the
second name is either that of the server which has become
disconnected or that of the server to which the leaving client was
connected:

<Quit Message> = ":" servername SPACE servername

Because the "Quit Message" has a special meaning for "netsplits",
servers SHOULD NOT allow a client to use a <Quit Message> in the
format described above.

If, for some other reason, a client connection is closed without the
client issuing a QUIT command (e.g. client dies and EOF occurs on
socket), the server is REQUIRED to fill in the quit message with some
sort of message reflecting the nature of the event which caused it to
happen. Typically, this is done by reporting a system specific
error.

Numeric Replies:

None.

 

Kalt Informational [Page 12]

RFC 2813 Internet Relay Chat: Server Protocol April 2000


Examples:

:WiZ QUIT :Gone to have lunch ; Preferred message format.

4.1.6 Server quit message

Command: SQUIT
Parameters: <server> <comment>

The SQUIT message has two distinct uses.

The first one (described in "Internet Relay Chat: Client Protocol"
[IRC-CLIENT]) allows operators to break a local or remote server
link. This form of the message is also eventually used by servers to
break a remote server link.

The second use of this message is needed to inform other servers when
a "network split" (also known as "netsplit") occurs, in other words
to inform other servers about quitting or dead servers. If a server
wishes to break the connection to another server it MUST send a SQUIT
message to the other server, using the name of the other server as
the server parameter, which then closes its connection to the
quitting server.

The <comment> is filled in by servers which SHOULD place an error or
similar message here.

Both of the servers which are on either side of the connection being
closed are REQUIRED to send out a SQUIT message (to all its other
server connections) for all other servers which are considered to be
behind that link.

Similarly, a QUIT message MAY be sent to the other still connected
servers on behalf of all clients behind that quitting link. In
addition to this, all channel members of a channel which lost a
member due to the "split" MUST be sent a QUIT message. Messages to
channel members are generated by each client's local server.

If a server connection is terminated prematurely (e.g., the server on
the other end of the link died), the server which detects this
disconnection is REQUIRED to inform the rest of the network that the
connection has closed and fill in the comment field with something
appropriate.

When a client is removed as the result of a SQUIT message, the server
SHOULD add the nickname to the list of temporarily unavailable
nicknames in an attempt to prevent future nickname collisions. See

 


Kalt Informational [Page 13]

RFC 2813 Internet Relay Chat: Server Protocol April 2000


section 5.7 (Tracking recently used nicknames) for more information
on this procedure.

Numeric replies:

ERR_NOPRIVILEGES ERR_NOSUCHSERVER
ERR_NEEDMOREPARAMS

Example:

SQUIT tolsun.oulu.fi :Bad Link ? ; the server link tolson.oulu.fi
has been terminated because of "Bad
Link".

:Trillian SQUIT cm22.eng.umd.edu :Server out of control ; message
from Trillian to disconnect
"cm22.eng.umd.edu" from the net
because "Server out of control".

4.2 Channel operations

This group of messages is concerned with manipulating channels, their
properties (channel modes), and their contents (typically users). In
implementing these, a number of race conditions are inevitable when
users at opposing ends of a network send commands which will
ultimately clash. It is also REQUIRED that servers keep a nickname
history to ensure that wherever a <nick> parameter is given, the
server check its history in case it has recently been changed.

4.2.1 Join message

Command: JOIN
Parameters: <channel>[ %x7 <modes> ]
*( "," <channel>[ %x7 <modes> ] )

The JOIN command is used by client to start listening a specific
channel. Whether or not a client is allowed to join a channel is
checked only by the local server the client is connected to; all
other servers automatically add the user to the channel when the
command is received from other servers.

Optionally, the user status (channel modes 'O', 'o', and 'v') on the
channel may be appended to the channel name using a control G (^G or
ASCII 7) as separator. Such data MUST be ignored if the message
wasn't received from a server. This format MUST NOT be sent to
clients, it can only be used between servers and SHOULD be avoided.

 

 

Kalt Informational [Page 14]

RFC 2813 Internet Relay Chat: Server Protocol April 2000


The JOIN command MUST be broadcast to all servers so that each server
knows where to find the users who are on the channel. This allows
optimal delivery of PRIVMSG and NOTICE messages to the channel.

Numeric Replies:

ERR_NEEDMOREPARAMS ERR_BANNEDFROMCHAN
ERR_INVITEONLYCHAN ERR_BADCHANNELKEY
ERR_CHANNELISFULL ERR_BADCHANMASK
ERR_NOSUCHCHANNEL ERR_TOOMANYCHANNELS
ERR_TOOMANYTARGETS ERR_UNAVAILRESOURCE
RPL_TOPIC

Examples:

:WiZ JOIN #Twilight_zone ; JOIN message from WiZ

4.2.2 Njoin message

Command: NJOIN
Parameters: <channel> [ "@@" / "@" ] [ "+" ] <nickname>
*( "," [ "@@" / "@" ] [ "+" ] <nickname> )

The NJOIN message is used between servers only. If such a message is
received from a client, it MUST be ignored. It is used when two
servers connect to each other to exchange the list of channel members
for each channel.

Even though the same function can be performed by using a succession
of JOIN, this message SHOULD be used instead as it is more efficient.
The prefix "@@" indicates that the user is the "channel creator", the
character "@" alone indicates a "channel operator", and the character
'+' indicates that the user has the voice privilege.

Numeric Replies:

ERR_NEEDMOREPARAMS ERR_NOSUCHCHANNEL
ERR_ALREADYREGISTRED

Examples:

:ircd.stealth.net NJOIN #Twilight_zone :@WiZ,+syrk,avalon ; NJOIN
message from ircd.stealth.net
announcing users joining the
#Twilight_zone channel: WiZ with
channel operator status, syrk with
voice privilege and avalon with no
privilege.

 

Kalt Informational [Page 15]

RFC 2813 Internet Relay Chat: Server Protocol April 2000


4.2.3 Mode message

The MODE message is a dual-purpose command in IRC. It allows both
usernames and channels to have their mode changed.

When parsing MODE messages, it is RECOMMENDED that the entire message
be parsed first, and then the changes which resulted passed on.

It is REQUIRED that servers are able to change channel modes so that
"channel creator" and "channel operators" may be created.

5. Implementation details

A the time of writing, the only current implementation of this
protocol is the IRC server, version 2.10. Earlier versions may
implement some or all of the commands described by this document with
NOTICE messages replacing many of the numeric replies. Unfortunately,
due to backward compatibility requirements, the implementation of
some parts of this document varies with what is laid out. One
notable difference is:

* recognition that any LF or CR anywhere in a message marks
the end of that message (instead of requiring CR-LF);

The rest of this section deals with issues that are mostly of
importance to those who wish to implement a server but some parts
also apply directly to clients as well.

5.1 Connection 'Liveness'

To detect when a connection has died or become unresponsive, the
server MUST poll each of its connections. The PING command (See "IRC
Client Protocol" [IRC-CLIENT]) is used if the server doesn't get a
response from its peer in a given amount of time.

If a connection doesn't respond in time, its connection is closed
using the appropriate procedures.

5.2 Accepting a client to server connection

5.2.1 Users

When a server successfully registers a new user connection, it is
REQUIRED to send to the user unambiguous messages stating: the user
identifiers upon which it was registered (RPL_WELCOME), the server
name and version (RPL_YOURHOST), the server birth information
(RPL_CREATED), available user and channel modes (RPL_MYINFO), and it
MAY send any introductory messages which may be deemed appropriate.

 

Kalt Informational [Page 16]

RFC 2813 Internet Relay Chat: Server Protocol April 2000


In particular the server SHALL send the current user/service/server
count (as per the LUSER reply) and finally the MOTD (if any, as per
the MOTD reply).

After dealing with registration, the server MUST then send out to
other servers the new user's nickname (NICK message), other
information as supplied by itself (USER message) and as the server
could discover (from DNS servers). The server MUST NOT send this
information out with a pair of NICK and USER messages as defined in
"IRC Client Protocol" [IRC-CLIENT], but MUST instead take advantage
of the extended NICK message defined in section 4.1.3.

5.2.2 Services

Upon successfully registering a new service connection, the server is
subject to the same kind of REQUIREMENTS as for a user. Services
being somewhat different, only the following replies are sent:
RPL_YOURESERVICE, RPL_YOURHOST, RPL_MYINFO.

After dealing with this, the server MUST then send out to other
servers (SERVICE message) the new service's nickname and other
information as supplied by the service (SERVICE message) and as the
server could discover (from DNS servers).

5.3 Establishing a server-server connection.

The process of establishing a server-to-server connection is fraught
with danger since there are many possible areas where problems can
occur - the least of which are race conditions.

After a server has received a connection following by a PASS/SERVER
pair which were recognized as being valid, the server SHOULD then
reply with its own PASS/SERVER information for that connection as
well as all of the other state information it knows about as
described below.

When the initiating server receives a PASS/SERVER pair, it too then
checks that the server responding is authenticated properly before
accepting the connection to be that server.

5.3.1 Link options

Server links are based on a common protocol (defined by this
document) but a particular link MAY set specific options using the
PASS message (See Section 4.1.1).

 

 


Kalt Informational [Page 17]

RFC 2813 Internet Relay Chat: Server Protocol April 2000


5.3.1.1 Compressed server to server links

If a server wishes to establish a compressed link with its peer, it
MUST set the 'Z' flag in the options parameter to the PASS message.
If both servers request compression and both servers are able to
initialize the two compressed streams, then the remainder of the
communication is to be compressed. If any server fails to initialize
the stream, it will send an uncompressed ERROR message to its peer
and close the connection.

The data format used for the compression is described by RFC 1950
[ZLIB], RFC 1951 [DEFLATE] and RFC 1952 [GZIP].

5.3.1.2 Anti abuse protections

Most servers implement various kinds of protections against possible
abusive behaviours from non trusted parties (typically users). On
some networks, such protections are indispensable, on others they are
superfluous. To require that all servers implement and enable such
features on a particular network, the 'P' flag is used when two
servers connect. If this flag is present, it means that the server
protections are enabled, and that the server REQUIRES all its server
links to enable them as well.

Commonly found protections are described in sections 5.7 (Tracking
recently used nicknames) and 5.8 (Flood control of clients).

5.3.2 State information exchange when connecting

The order of state information being exchanged between servers is
essential. The REQUIRED order is as follows:

* all known servers;

* all known client information;

* all known channel information.

Information regarding servers is sent via extra SERVER messages,
client information with NICK and SERVICE messages and channels with
NJOIN/MODE messages.

NOTE: channel topics SHOULD NOT be exchanged here because the TOPIC
command overwrites any old topic information, so at best, the two
sides of the connection would exchange topics.

 

 


Kalt Informational [Page 18]

RFC 2813 Internet Relay Chat: Server Protocol April 2000


By passing the state information about servers first, any collisions
with servers that already exist occur before nickname collisions
caused by a second server introducing a particular nickname. Due to
the IRC network only being able to exist as an acyclic graph, it may
be possible that the network has already reconnected in another
location. In this event, the place where the server collision occurs
indicates where the net needs to split.

5.4 Terminating server-client connections

When a client connection unexpectedly closes, a QUIT message is
generated on behalf of the client by the server to which the client
was connected. No other message is to be generated or used.

5.5 Terminating server-server connections

If a server-server connection is closed, either via a SQUIT command
or "natural" causes, the rest of the connected IRC network MUST have
its information updated by the server which detected the closure.
The terminating server then sends a list of SQUITs (one for each
server behind that connection). (See Section 4.1.6 (SQUIT)).

5.6 Tracking nickname changes

All IRC servers are REQUIRED to keep a history of recent nickname
changes. This is important to allow the server to have a chance of
keeping in touch of things when nick-change race conditions occur
with commands manipulating them. Messages which MUST trace nick
changes are:

* KILL (the nick being disconnected)

* MODE (+/- o,v on channels)

* KICK (the nick being removed from channel)

No other commands need to check nick changes.

In the above cases, the server is required to first check for the
existence of the nickname, then check its history to see who that
nick now belongs to (if anyone!). This reduces the chances of race
conditions but they can still occur with the server ending up
affecting the wrong client. When performing a change trace for an
above command it is RECOMMENDED that a time range be given and
entries which are too old ignored.

 

 


Kalt Informational [Page 19]

RFC 2813 Internet Relay Chat: Server Protocol April 2000


For a reasonable history, a server SHOULD be able to keep previous
nickname for every client it knows about if they all decided to
change. This size is limited by other factors (such as memory, etc).

5.7 Tracking recently used nicknames

This mechanism is commonly known as "Nickname Delay", it has been
proven to significantly reduce the number of nickname collisions
resulting from "network splits"/reconnections as well as abuse.

In addition of keeping track of nickname changes, servers SHOULD keep
track of nicknames which were recently used and were released as the
result of a "network split" or a KILL message. These nicknames are
then unavailable to the server local clients and cannot be re-used
(even though they are not currently in use) for a certain period of
time.

The duration for which a nickname remains unavailable SHOULD be set
considering many factors among which are the size (user wise) of the
IRC network, and the usual duration of "network splits". It SHOULD
be uniform on all servers for a given IRC network.

5.8 Flood control of clients

With a large network of interconnected IRC servers, it is quite easy
for any single client attached to the network to supply a continuous
stream of messages that result in not only flooding the network, but
also degrading the level of service provided to others. Rather than
require every 'victim' to provide their own protection, flood
protection was written into the server and is applied to all clients
except services. The current algorithm is as follows:

* check to see if client's `message timer' is less than current time
(set to be equal if it is);

* read any data present from the client;

* while the timer is less than ten (10) seconds ahead of the current
time, parse any present messages and penalize the client by two (2)
seconds for each message;

* additional penalties MAY be used for specific commands which
generate a lot of traffic across the network.

This in essence means that the client may send one (1) message every
two (2) seconds without being adversely affected. Services MAY also
be subject to this mechanism.

 


Kalt Informational [Page 20]

RFC 2813 Internet Relay Chat: Server Protocol April 2000


5.9 Non-blocking lookups

In a real-time environment, it is essential that a server process
does as little waiting as possible so that all the clients are
serviced fairly. Obviously this requires non-blocking IO on all
network read/write operations. For normal server connections, this
was not difficult, but there are other support operations that may
cause the server to block (such as disk reads). Where possible, such
activity SHOULD be performed with a short timeout.

5.9.1 Hostname (DNS) lookups

Using the standard resolver libraries from Berkeley and others has
meant large delays in some cases where replies have timed out. To
avoid this, a separate set of DNS routines were written for the
current implementation. Routines were setup for non-blocking IO
operations with local cache, and then polled from within the main
server IO loop.

5.9.2 Username (Ident) lookups

Although there are numerous ident libraries (implementing the
"Identification Protocol" [IDENT]) for use and inclusion into other
programs, these caused problems since they operated in a synchronous
manner and resulted in frequent delays. Again the solution was to
write a set of routines which would cooperate with the rest of the
server and work using non-blocking IO.

6. Current problems

There are a number of recognized problems with this protocol, all of
which are hoped to be solved sometime in the near future during its
rewrite. Currently, work is underway to find working solutions to
these problems.

6.1 Scalability

It is widely recognized that this protocol does not scale
sufficiently well when used in a large arena. The main problem comes
from the requirement that all servers know about all other servers
and clients and that information regarding them be updated as soon as
it changes. It is also desirable to keep the number of servers low
so that the path length between any two points is kept minimal and
the spanning tree as strongly branched as possible.

 

 

 

Kalt Informational [Page 21]

RFC 2813 Internet Relay Chat: Server Protocol April 2000


6.2 Labels

The current IRC protocol has 4 types of labels: the nickname, the
channel name, the server name and the service name. Each of the four
types has its own domain and no duplicates are allowed inside that
domain. Currently, it is possible for users to pick the label for
any of the first three, resulting in collisions. It is widely
recognized that this needs reworking, with a plan for unique names
for nicks that don't collide being desirable as well as a solution
allowing a cyclic tree.

6.2.1 Nicknames

The idea of the nickname on IRC is very convenient for users to use
when talking to each other outside of a channel, but there is only a
finite nickname space and being what they are, it's not uncommon for
several people to want to use the same nick. If a nickname is chosen
by two people using this protocol, either one will not succeed or
both will be removed by use of KILL (See Section 3.7.1 of "IRC Client
Protocol" [IRC-CLIENT]).

6.2.2 Channels

The current channel layout requires that all servers know about all
channels, their inhabitants and properties. Besides not scaling
well, the issue of privacy is also a concern. A collision of
channels is treated as an inclusive event (people from both nets on
channel with common name are considered to be members of it) rather
than an exclusive one such as used to solve nickname collisions.

This protocol defines "Safe Channels" which are very unlikely to be
the subject of a channel collision. Other channel types are kept for
backward compatibility.

6.2.3 Servers

Although the number of servers is usually small relative to the
number of users and channels, they too are currently REQUIRED to be
known globally, either each one separately or hidden behind a mask.

6.3 Algorithms

In some places within the server code, it has not been possible to
avoid N^2 algorithms such as checking the channel list of a set of
clients.

 

 


Kalt Informational [Page 22]

RFC 2813 Internet Relay Chat: Server Protocol April 2000


In current server versions, there are only few database consistency
checks, most of the time each server assumes that a neighbouring
server is correct. This opens the door to large problems if a
connecting server is buggy or otherwise tries to introduce
contradictions to the existing net.

Currently, because of the lack of unique internal and global labels,
there are a multitude of race conditions that exist. These race
conditions generally arise from the problem of it taking time for
messages to traverse and effect the IRC network. Even by changing to
unique labels, there are problems with channel-related commands being
disrupted.

7. Security Considerations

7.1 Authentication

Servers only have two means of authenticating incoming connections:
plain text password, and DNS lookups. While these methods are weak
and widely recognized as unsafe, their combination has proven to be
sufficient in the past:

* public networks typically allow user connections with only few
restrictions, without requiring accurate authentication.

* private networks which operate in a controlled environment often
use home-grown authentication mechanisms not available on the
internet: reliable ident servers [IDENT], or other proprietary
mechanisms.

The same comments apply to the authentication of IRC Operators.

It should also be noted that while there has been no real demand over
the years for stronger authentication, and no real effort to provide
better means to safely authenticate users, the current protocol
offers enough to be able to easily plug-in external authentication
methods based on the information that a client can submit to the
server upon connection: nickname, username, password.

7.2 Integrity

Since the PASS and OPER messages of the IRC protocol are sent in
clear text, a stream layer encryption mechanism (like "The TLS
Protocol" [TLS]) could be used to protect these transactions.

 

 

 

Kalt Informational [Page 23]

RFC 2813 Internet Relay Chat: Server Protocol April 2000


8. Current support and availability

Mailing lists for IRC related discussion:
General discussion: Diese E-Mail-Adresse ist vor Spambots geschützt! Zur Anzeige muss JavaScript eingeschaltet sein!
Protocol development: Diese E-Mail-Adresse ist vor Spambots geschützt! Zur Anzeige muss JavaScript eingeschaltet sein!

Software implementations:
ftp://ftp.irc.org/irc/server
ftp://ftp.funet.fi/pub/unix/irc
ftp://coombs.anu.edu.au/pub/irc

Newsgroup: alt.irc

9. Acknowledgements

Parts of this document were copied from the RFC 1459 [IRC] which
first formally documented the IRC Protocol. It has also benefited
from many rounds of review and comments. In particular, the
following people have made significant contributions to this
document:

Matthew Green, Michael Neumayer, Volker Paulsen, Kurt Roeckx, Vesa
Ruokonen, Magnus Tjernstrom, Stefan Zehl.

10. References

[KEYWORDS] Bradner, S., "Key words for use in RFCs to Indicate
Requirement Levels", BCP 14, RFC 2119, March 1997.

[ABNF] Crocker, D. and P. Overell, "Augmented BNF for Syntax
Specifications: ABNF", RFC 2234, November 1997.

[IRC] Oikarinen, J. and D. Reed, "Internet Relay Chat
Protocol", RFC 1459, May 1993.

[IRC-ARCH] Kalt, C., "Internet Relay Chat: Architecture", RFC 2810,
April 2000.

[IRC-CLIENT] Kalt, C., "Internet Relay Chat: Client Protocol", RFC
2812, April 2000.


[IRC-CHAN] Kalt, C., "Internet Relay Chat: Channel Management", RFC
2811, April 2000.

[ZLIB] Deutsch, P. and J-L. Gailly, "ZLIB Compressed Data
Format Specification version 3.3", RFC 1950, May 1996.

 


Kalt Informational [Page 24]

RFC 2813 Internet Relay Chat: Server Protocol April 2000


[DEFLATE] Deutsch, P., "DEFLATE Compressed Data Format
Specification version 1.3", RFC 1951, May 1996.

[GZIP] Deutsch, P., "GZIP file format specification version
4.3", RFC 1952, May 1996.

[IDENT] St. Johns, M., "The Identification Protocol", RFC 1413,
February 1993.

[TLS] Dierks, T. and C. Allen, "The TLS Protocol", RFC 2246,
January 1999.

11. Author's Address

Christophe Kalt
99 Teaneck Rd, Apt #117
Ridgefield Park, NJ 07660
USA

EMail: Diese E-Mail-Adresse ist vor Spambots geschützt! Zur Anzeige muss JavaScript eingeschaltet sein!

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

Kalt Informational [Page 25]

RFC 2813 Internet Relay Chat: Server Protocol April 2000


12. Full Copyright Statement

Copyright (C) The Internet Society (2000). All Rights Reserved.

This document and translations of it may be copied and furnished to
others, and derivative works that comment on or otherwise explain it
or assist in its implementation may be prepared, copied, published
and distributed, in whole or in part, without restriction of any
kind, provided that the above copyright notice and this paragraph are
included on all such copies and derivative works. However, this
document itself may not be modified in any way, such as by removing
the copyright notice or references to the Internet Society or other
Internet organizations, except as needed for the purpose of
developing Internet standards in which case the procedures for
copyrights defined in the Internet Standards process must be
followed, or as required to translate it into languages other than
English.

The limited permissions granted above are perpetual and will not be
revoked by the Internet Society or its successors or assigns.

This document and the information contained herein is provided on an
"AS IS" basis and THE INTERNET SOCIETY AND THE INTERNET ENGINEERING
TASK FORCE DISCLAIMS ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING
BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION
HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF
MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.

Acknowledgement

Funding for the RFC Editor function is currently provided by the
Internet Society.

 

 

 

 

 

 

 

 

 

Kalt Informational [Page 26]

 

 

Stern inaktivStern inaktivStern inaktivStern inaktivStern inaktiv

IRC Paranoia

Bist Du Paranoid ?
Wenn Du diese Frage mit einem kräftigen NEIN und ggf. nem' witzigen Unterton beantworten kannst, dann bist Du echt planlos.

Denn Du hast die besten Gründe praranoid zusein/zu werden. 
Was heisst das denn schon paranoid zusein ?
Ist es eine Krankheit? 
Oder nur eine Vorsichtsmaßnahme zum EigenSchutz.

Wer sowas nur mit dem Lauschangriffen der Regierung ect in Einklang bringt, ist weit von der Realität entfernt. 
Man koennte tagelang X Dinge verschriftlichen, wo wir durchleuchtet und verfolgt werden.
Angefangem vom Supermarkt, wo unser Kaufverhalten anylysiert wird und wo dann Jagt auf uns gemacht wird. Und wir gehen drauf ein, denn die Bedrohung wird nicht erkannt.
Bishin zu den Cookies im Internet, die alles über Dich verraten koennen . Denen Du ausgeliefert bist. 

Nut hier moechte ich mich mit IRC,dem Internet Relay Chat, beschäftigen.

Wie oft bist Du im IRC ?
Wie oft führst Du dort sehr persönliche Gespräche?
Wie oft hast Du wichtige Passwörter oder andere Vertrauendaten weitergeben?

Natürlich, Du bist nicht dumm und hast dies nur im im Query getätigt.
Nun, sollte man eher die Frage stellen, warum Du Depp nicht paranoid bist!
Fällt Dir diese Antwort ebenfalls sooo leicht, wie die ob Du paranoid bist, eh ?

In ca 80% aller Fällen loggt mindestens 1 Gespächspartner mit. Wie sicher ist sein PC ?
Hat er eine Firewall ? Ja? Kann er auch damit umgehen ? Oder gibt er aus Unwissenheit eh jedem Programm das Recht aufs I-Net zuzugreifenm, nur weil er mit namen wie IEWinPortant.exe ect nichts anfangen kann und meint dies wäre für Windows wichtig.
Oder er lässt tausend Sharewaretools laufen. 
Naja. Die Gefahr siehst Du nicht, ggf bist Du selbst ein Grund paranoid zu werden zu muessen.

Aber Okay, Du bist Dir sicher, dass Du und Dein GessprächsPartner zuverlässige SicherheitsPunkte sind. Kein Problem.

 

 

Doch das ist IRC - Im IRC ist grundsätzlich alles moeglich. 
Was meinst Du wie sicher Dein Query ist?

Alles was im ChatRaum oder im PrivatChat abläuft geht über den Server. 
Einige kleine Sourceveränderungen und alles kann auspsioniert werden, alles kann geloggt werden. HauptSache Du fühlst Dich sicher.
Es ist ein beschissenes Gefühl zu wissen , das man ein offenes Buch ist. 

Im Laufe der letzten 2 , 3 Jahre habe ich unmengen an eMails bekommen, wo sich Leute gefragt haben, ob ihr Netz, Ihre IRC-Admins sie ggf belauschen würden. Sie fragten mich, wie einfach dies doch wäre. 
Nun , ich konnte mir bei den meisten Netzen nicht vorstellen, das sich jemand die Muehe macht den Source zu ändern, für billige Logs und da ich nicht ein Netz "zerstören" wollte, habe ich diejenigen als paranoid abgestempelt und sie zugleich beruhigt, indem ich allen versicherte,das dies nicht der Fall sein wird. 
Habe den meisten Admins auch nicht zugetraut zu wissen was "C" ist ;) 

Was fällt mir ein ?!

Wie oft war ich in Netzen, wo dies sehr wahrscheinlich war. Man wusste es nicht genau, aber vieles sprach dafür. 
Najo , wenn sich Coder für ihr eignes Netz n' bissl Muehe geben.... Schlimm aber naja.
Sie muessen wissen, was dies für ein Risiko ist.

In diesen Tagen diskutiere ich viel mit einigen Codern, Grund ist ein Spy und LogModul für einen sehr bekannten IRCD.

Ein Modul , welches es jedem dummen ScriptKiddie erlaubt zu spionieren.
Und irgendwie fühle ich mich derzeit recht mies, weils mich ärgert und ich nichts dagegen tun kann. Es macht mir keinen Spass mehr in anderen Netzen zu chatten.
Permanent die VersionsFlags zu Überprüfen, um zu schauen ob ein derartiges Modul exitsiert.
Und selbst dann weiss ich es nicht.

Es ist so bedrückend, machtlos zu sein.
So geil IRC auch ist, es hat viele Seiten.

Im Laufe der letzten 2,5 Jahren in dem es das IRC-Mania-Netz gibt, gab es unzählige Momente, wo ich mich gefragt habe, ob es sich überhaupt lohnt ein solches Netz ins Inet zustellen. 
In Zeiten der DDOS-Attacken, FloodBots, Spybots, ect. 

Wo man sich selbst nichts vorzuwerfen hat und sich doch mies und mitschuldig fühlt. 

"Nichts ist für immer da, denn es gibt nen neuen Morgen, n' neuen Tag, n' neues Jahr,
der Schmerz hat Dich belogen, nichts ist für immer da"

" ... Selbst die grösste Scheisse geht mal vorbei.." (Böhsen Onkelz) 

 

 

Und so sehe ich es auch. 
Irgendwann ist Ende. Auch das IRC-Mania.de Netz wird irgendwann verblasst sein und sein Ende finden. Auch wenns prall gefüllt sein sollte.
Es wird ein guter Tag werden. 
Für alle.

Das IRC-ManiaNetz nutzt keine SpyTools und solange es das Netz gibt wird es dies auch nicht tun. Jedoch loggt der ServiceBot die ChannelEreignisse mit, um daraus die Stats wie auf http://IRC-Mania.Chanstats.de zu erstellen.
Jeder ChannelFounder, hat diese zuvor ANGEFORDERT.

Wieviele Unwissende gibt es bei uns ?
Die davon nichts wissen, trotz MOTD-Einträge die darauf hinweisen?
Solche StatsBots sind nichts ungewöhnliches mehr. 
Es stellt sich mir im Moment nur die Frage, ob wir, als IRCNetzBetreiber dieses anbieten "dürfen". 
Selbst kann ich mir versichern das diese Daten nicht im kompletten Zusammenhang an zweite oder Dritte weitergegeben werden.
Jedoch sind auch diese einzelnen Zeilenmitschnitte suckig.

Denn der Bot wird neutral angesehen und es passiert schnell, das man in der Gegenwart des Bots mal was persönliches loswird, was dann "ungefragt" in den stats vorkommt.
Oft fehlt dort der Zusammenhang, damit ist es kein Problem.
Der, der ausgeplappert hat, hat selbst Schuld, klar, er kennt die Stats und muss auspassen.
Zudem müssen die Operator des Raumes darauf hinweisen, denn die haben den Bot und die Stats angefordert.

 

 

 

Also nocheinmal die Frage. 
Bist Du paranoid? 
Wie viele Sitution fallen Dir nun ein, wo Du es hättest sein sollen ?
Wie fühlst Du Dich ? 
Warum verachtest Du paranoia, die Du doch so sehr bräuchtest ? ;)

Nun, was kann man dennoch tun, um sich ein wenig sicherer zu fühlen ? 

1) Wichtige Dinge sollten im IRC definitv nur im DCC-Chat besprochen werden.

Egal in welchem Netz ihr auch seid !
Doch vorsicht ! DCC ist ein DirectConnect(p2p) d.h, das eine direkte Verbindung vom Quell- zum ZeilComputer hergstellt wird.
Bis auf die Anfrage läuft dann nichts mehr über den IRCDaemon.
Jeder Teilnehmer kann nun also die IP des anderen sehen,welche im Query meist verdeckt wird.

2) Schafft Euch Eggdrops, Bots an, richtet Euch dort PartyLines ein, die über DCC aufbauen. 
Auch hier gilt die oben genannte Warnung. 

3) Wichtige Passwörter ect sollten definitiv nicht über IRC übermittelt werden.
Email, najo , PGPverschluesselt ggf.

4) Achtet bei Eurem IRCNetzProvider darauf, das dieser einen SSL-Verschluesselten Zugang anbietet. Nutzt diesen bei bedarf !

 

 

5) Schaut Euch die VersionsFlags des IRCDs an
Der Befehl /version 
liefert folgende BeispielsZeile
Unreal3.2-beta15cvs20030322. irc.NoNSeNSe.IRC-Mania.de FhiIXOo [Linux .... 
Sollte sich hinter FhiIXOo noch ein S befinden , also FhiIXOoS , dann ist dies ein typisches Zeichen eines der bekanntesten SpyModules, sollte dies nicht vorhanden sein, ist kein Grund gegeben sich sicherer zu fühlen.

6) Meidet kontakte mit dem AdminTeam. 
Ein Admin zu dem man keinen Bezug hat, hat auch in der Regel kein persönliches Interesse Eure Privatangelegenheiten zu lesen. So toll, wie es auch für einige ist, mal mit dem Admin oder so zu chatten, genauso unnötig ist es. Nehmt Abstand !

 

 7) Sucht euch VerschluesselungsProgramme im IRC zusammen.
Durch einfaches Scripting koennte man bei mIRC einen sehr gutes Input/OutPut Verschluesselungscript einbauen. Ggf wird man bald einige in unserer DownloadEcke finden.

8)Meidet IRC, meidet das Internet, schliesst Euch zu Hause ein !

 

 

DS
Schutzgeist 

 

Stern inaktivStern inaktivStern inaktivStern inaktivStern inaktiv

RFC2810


RFC 2810 IRC Internet Relay Chat

 

Vorwort:

Was sind RFC's ? (Quelle: http://www1.tfh-berlin.de/~s715053/vsg_ub2.html )

Zunächst ist RFC eine Abkürzung für den englischen Begriff "Request for Comments", also eine Kommentar-Anforderung. RFCs sind eine Form von Diskussionspapieren, in denen technische Komponenten wie zum Beispiel die Architektur des Internets, der Aufbau von Protokollen, die Form von eMail-Headern usw. erklärt werden. Unter anderem werden alle verfügbaren Internet-Standards in RFC-Dokumenten veröffentlicht. Prinzipiell kann jeder Autor RFC-Dokumente schreiben. 
Alle so genannten Internet Standards sind zwar als RFCs veröffentlicht, aber nur ein kleiner Teil der RFCs sind echte Standards. RFCs sind eine durchnummerierte Serie von Dokumenten, die verschiedene tatsächliche und vorgeschlagene Gewohnheiten beschreiben, die einen Bezug zum Internet haben und von der IETF herausgegeben werden. Die Sammlung ist sowohl hinsichtlich des Themas, als auch des so genannten Status, uneinheitlich. Viele RFCs behandeln technische Festsetzungen und Übereinkommen - die Protokolle.
Protokolle sind für die Zusammenarbeit der Systeme unentbehrlich; Programme, die untereinander Daten austauschen, müssen auf einigen Übereinstimmungen hinsichtlich des Datenformates und verwandten Themen beruhen.
• geschichtliche Informationen zu den RFCs: RFC 2555

Wozu werden RFC-Dokumente gebraucht (Quelle: http://www1.tfh-berlin.de/~s715053/vsg_ub2.html )

RFC-Dokumente können gebraucht werden, um zum Beispiel festzustellen, ob eine Anwendung, ein Protokoll oder eine Funktion einem der in den RFCs veröffentlichten Internet-Standards entspricht. Auf die Weise kann zum Beispiel festgestellt werden, ob ein eMail-Client sich an die Vorgaben der RFC hält oder nicht. Die Erarbeitung dieser Standards liegt in der Verantwortung der ISOC. Das heißt, es werden Vorgaben erarbeitet, die für Implementierungen benutzt werden können und sollen.
Aufgaben der ISOC unter: ISOC

Wo finde ich weitere RFC-Dokumente ?
http://www.rfc-editor.org/

 

RFC 2810 - Internet Relay Chat: Architecture

 

 

Network Working Group C. Kalt
Request for Comments: 2810 April 2000
Updates: 1459
Category: Informational


Internet Relay Chat: Architecture

Status of this Memo

This memo provides information for the Internet community. It does
not specify an Internet standard of any kind. Distribution of this
memo is unlimited.

Copyright Notice

Copyright (C) The Internet Society (2000). All Rights Reserved.

Abstract

The IRC (Internet Relay Chat) protocol is for use with text based
conferencing. It has been developed since 1989 when it was originally
implemented as a mean for users on a BBS to chat amongst themselves.

First formally documented in May 1993 by RFC 1459 [IRC], the protocol
has kept evolving. This document is an update describing the
architecture of the current IRC protocol and the role of its
different components. Other documents describe in detail the
protocol used between the various components defined here.

Table of Contents

1. Introduction ............................................... 2
2. Components ................................................. 2
2.1 Servers ................................................ 2
2.2 Clients ................................................ 3
2.2.1 User Clients ...................................... 3
2.2.2 Service Clients ................................... 3
3. Architecture ............................................... 3
4. IRC Protocol Services ...................................... 4
4.1 Client Locator ......................................... 4
4.2 Message Relaying ....................................... 4
4.3 Channel Hosting And Management ......................... 4
5. IRC Concepts ............................................... 4
5.1 One-To-One Communication ............................... 5
5.2 One-To-Many ............................................ 5
5.2.1 To A Channel ...................................... 5
5.2.2 To A Host/Server Mask ............................. 6

 

Kalt Informational [Page 1]

RFC 2810 Internet Relay Chat: Architecture April 2000


5.2.3 To A List ......................................... 6
5.3 One-To-All ............................................. 6
5.3.1 Client-to-Client .................................. 6
5.3.2 Client-to-Server .................................. 7
5.3.3 Server-to-Server .................................. 7
6. Current Problems ........................................... 7
6.1 Scalability ............................................ 7
6.2 Reliability ............................................ 7
6.3 Network Congestion ..................................... 7
6.4 Privacy ................................................ 8
7. Security Considerations .................................... 8
8. Current Support And Availability ........................... 8
9. Acknowledgements ........................................... 8
10. References ................................................ 8
11. Author's Address .......................................... 9
12. Full Copyright Statement .................................. 10

1. Introduction

The IRC (Internet Relay Chat) protocol has been designed over a
number of years for use with text based conferencing. This document
describes its current architecture.

The IRC Protocol is based on the client-server model, and is well
suited to running on many machines in a distributed fashion. A
typical setup involves a single process (the server) forming a
central point for clients (or other servers) to connect to,
performing the required message delivery/multiplexing and other
functions.

This distributed model, which requires each server to have a copy
of the global state information, is still the most flagrant problem
of the protocol as it is a serious handicap, which limits the maximum
size a network can reach. If the existing networks have been able to
keep growing at an incredible pace, we must thank hardware
manufacturers for giving us ever more powerful systems.

2. Components

The following paragraphs define the basic components of the IRC
protocol.

2.1 Servers

The server forms the backbone of IRC as it is the only component
of the protocol which is able to link all the other components
together: it provides a point to which clients may connect to talk to

 


Kalt Informational [Page 2]

RFC 2810 Internet Relay Chat: Architecture April 2000


each other [IRC-CLIENT], and a point for other servers to connect to
[IRC-SERVER]. The server is also responsible for providing the basic
services defined by the IRC protocol.

2.2 Clients

A client is anything connecting to a server that is not another
server. There are two types of clients which both serve a different
purpose.

2.2.1 User Clients

User clients are generally programs providing a text based
interface that is used to communicate interactively via IRC. This
particular type of clients is often referred as "users".

2.2.2 Service Clients

Unlike users, service clients are not intended to be used manually
nor for talking. They have a more limited access to the chat
functions of the protocol, while optionally having access to more
private data from the servers.

Services are typically automatons used to provide some kind of
service (not necessarily related to IRC itself) to users. An example
is a service collecting statistics about the origin of users
connected on the IRC network.

3. Architecture

An IRC network is defined by a group of servers connected to each
other. A single server forms the simplest IRC network.

The only network configuration allowed for IRC servers is that of
a spanning tree where each server acts as a central node for the rest
of the network it sees.

1--\
A D---4
2--/ \ /
B----C
/ \
3 E

Servers: A, B, C, D, E Clients: 1, 2, 3, 4

[ Fig. 1. Sample small IRC network ]

 


Kalt Informational [Page 3]

RFC 2810 Internet Relay Chat: Architecture April 2000


The IRC protocol provides no mean for two clients to directly
communicate. All communication between clients is relayed by the
server(s).

4. IRC Protocol Services

This section describes the services offered by the IRC protocol. The
combination of these services allow real-time conferencing.

4.1 Client Locator

To be able to exchange messages, two clients must be able to locate
each other.

Upon connecting to a server, a client registers using a label which
is then used by other servers and clients to know where the client is
located. Servers are responsible for keeping track of all the labels
being used.

4.2 Message Relaying

The IRC protocol provides no mean for two clients to directly
communicate. All communication between clients is relayed by the
server(s).

4.3 Channel Hosting And Management

A channel is a named group of one or more users which will all
receive messages addressed to that channel. A channel is
characterized by its name and current members, it also has a set of
properties which can be manipulated by (some of) its members.

Channels provide a mean for a message to be sent to several clients.
Servers host channels, providing the necessary message multiplexing.
Servers are also responsible for managing channels by keeping track
of the channel members. The exact role of servers is defined in
"Internet Relay Chat: Channel Management" [IRC-CHAN].

5. IRC Concepts

This section is devoted to describing the actual concepts behind the
organization of the IRC protocol and how different classes of
messages are delivered.

 

 

 


Kalt Informational [Page 4]

RFC 2810 Internet Relay Chat: Architecture April 2000


5.1 One-To-One Communication

Communication on a one-to-one basis is usually performed by clients,
since most server-server traffic is not a result of servers talking
only to each other. To provide a means for clients to talk to each
other, it is REQUIRED that all servers be able to send a message in
exactly one direction along the spanning tree in order to reach any
client. Thus the path of a message being delivered is the shortest
path between any two points on the spanning tree.

The following examples all refer to Figure 1 above.

Example 1: A message between clients 1 and 2 is only seen by server
A, which sends it straight to client 2.

Example 2: A message between clients 1 and 3 is seen by servers A &
B, and client 3. No other clients or servers are allowed see the
message.

Example 3: A message between clients 2 and 4 is seen by servers A, B,
C & D and client 4 only.

5.2 One-To-Many

The main goal of IRC is to provide a forum which allows easy and
efficient conferencing (one to many conversations). IRC offers
several means to achieve this, each serving its own purpose.

5.2.1 To A Channel

In IRC the channel has a role equivalent to that of the multicast
group; their existence is dynamic and the actual conversation carried
out on a channel MUST only be sent to servers which are supporting
users on a given channel. Moreover, the message SHALL only be sent
once to every local link as each server is responsible to fan the
original message to ensure that it will reach all the recipients.

The following examples all refer to Figure 2.

Example 4: Any channel with 1 client in it. Messages to the channel
go to the server and then nowhere else.

Example 5: 2 clients in a channel. All messages traverse a path as if
they were private messages between the two clients outside a
channel.

 

 


Kalt Informational [Page 5]

RFC 2810 Internet Relay Chat: Architecture April 2000


Example 6: Clients 1, 2 and 3 in a channel. All messages to the
channel are sent to all clients and only those servers which must
be traversed by the message if it were a private message to a
single client. If client 1 sends a message, it goes back to
client 2 and then via server B to client 3.

5.2.2 To A Host/Server Mask

To provide with some mechanism to send messages to a large body of
related users, host and server mask messages are available. These
messages are sent to users whose host or server information match
that of the mask. The messages are only sent to locations where
users are, in a fashion similar to that of channels.

5.2.3 To A List

The least efficient style of one-to-many conversation is through
clients talking to a 'list' of targets (client, channel, mask). How
this is done is almost self explanatory: the client gives a list of
destinations to which the message is to be delivered and the server
breaks it up and dispatches a separate copy of the message to each
given destination.

This is not as efficient as using a channel since the destination
list MAY be broken up and the dispatch sent without checking to make
sure duplicates aren't sent down each path.

5.3 One-To-All

The one-to-all type of message is better described as a broadcast
message, sent to all clients or servers or both. On a large network
of users and servers, a single message can result in a lot of traffic
being sent over the network in an effort to reach all of the desired
destinations.

For some class of messages, there is no option but to broadcast it to
all servers so that the state information held by each server is
consistent between servers.

5.3.1 Client-to-Client

There is no class of message which, from a single message, results in
a message being sent to every other client.

 

 

 


Kalt Informational [Page 6]

RFC 2810 Internet Relay Chat: Architecture April 2000


5.3.2 Client-to-Server

Most of the commands which result in a change of state information
(such as channel membership, channel mode, user status, etc.) MUST be
sent to all servers by default, and this distribution SHALL NOT be
changed by the client.

5.3.3 Server-to-Server

While most messages between servers are distributed to all 'other'
servers, this is only required for any message that affects a user,
channel or server. Since these are the basic items found in IRC,
nearly all messages originating from a server are broadcast to all
other connected servers.

6. Current Problems

There are a number of recognized problems with this protocol, this
section only addresses the problems related to the architecture of
the protocol.

6.1 Scalability

It is widely recognized that this protocol does not scale
sufficiently well when used in a large arena. The main problem comes
from the requirement that all servers know about all other servers,
clients and channels and that information regarding them be updated
as soon as it changes.

6.2 Reliability

As the only network configuration allowed for IRC servers is that of
a spanning tree, each link between two servers is an obvious and
quite serious point of failure. This particular issue is addressed
more in detail in "Internet Relay Chat: Server Protocol" [IRC-
SERVER].

6.3 Network Congestion

Another problem related to the scalability and reliability issues, as
well as the spanning tree architecture, is that the protocol and
architecture for IRC are extremely vulnerable to network congestions.
This problem is endemic, and should be solved for the next
generation: if congestion and high traffic volume cause a link
between two servers to fail, not only this failure generates more
network traffic, but the reconnection (eventually elsewhere) of two
servers also generates more traffic.

 


Kalt Informational [Page 7]

RFC 2810 Internet Relay Chat: Architecture April 2000


In an attempt to minimize the impact of these problems, it is
strongly RECOMMENDED that servers do not automatically try to
reconnect too fast, in order to avoid aggravating the situation.

6.4 Privacy

Besides not scaling well, the fact that servers need to know all
information about other entities, the issue of privacy is also a
concern. This is in particular true for channels, as the related
information is quite a lot more revealing than whether a user is
online or not.

7. Security Considerations

Asides from the privacy concerns mentioned in section 6.4 (Privacy),
security is believed to be irrelevant to this document.

8. Current Support And Availability

Mailing lists for IRC related discussion:
General discussion: Diese E-Mail-Adresse ist vor Spambots geschützt! Zur Anzeige muss JavaScript eingeschaltet sein!
Protocol development: Diese E-Mail-Adresse ist vor Spambots geschützt! Zur Anzeige muss JavaScript eingeschaltet sein!

Software implementations:
ftp://ftp.irc.org/irc/server
ftp://ftp.funet.fi/pub/unix/irc
ftp://coombs.anu.edu.au/pub/irc

Newsgroup: alt.irc

9. Acknowledgements

Parts of this document were copied from the RFC 1459 [IRC] which
first formally documented the IRC Protocol. It has also benefited
from many rounds of review and comments. In particular, the
following people have made significant contributions to this
document:

Matthew Green, Michael Neumayer, Volker Paulsen, Kurt Roeckx, Vesa
Ruokonen, Magnus Tjernstrom, Stefan Zehl.

 

 

 

 

 

Kalt Informational [Page 8]

RFC 2810 Internet Relay Chat: Architecture April 2000


10. References

[KEYWORDS] Bradner, S., "Key words for use in RFCs to Indicate
Requirement Levels", BCP 14, RFC 2119, March 1997.

[IRC] Oikarinen, J. and D. Reed, "Internet Relay Chat
Protocol", RFC 1459, May 1993.

[IRC-CLIENT] Kalt, C., "Internet Relay Chat: Client Protocol", RFC
2812, April 2000.

[IRC-SERVER] Kalt, C., "Internet Relay Chat: Server Protocol", RFC
2813, April 2000.

[IRC-CHAN] Kalt, C., "Internet Relay Chat: Channel Management", RFC
2811, April 2000.

11. Author's Address

Christophe Kalt
99 Teaneck Rd, Apt #117
Ridgefield Park, NJ 07660
USA

EMail: Diese E-Mail-Adresse ist vor Spambots geschützt! Zur Anzeige muss JavaScript eingeschaltet sein!

 

 

 

 

 

 

 

 

 

 

 

 


Kalt Informational [Page 9]

RFC 2810 Internet Relay Chat: Architecture April 2000


12. Full Copyright Statement

Copyright (C) The Internet Society (2000). All Rights Reserved.

This document and translations of it may be copied and furnished to
others, and derivative works that comment on or otherwise explain it
or assist in its implementation may be prepared, copied, published
and distributed, in whole or in part, without restriction of any
kind, provided that the above copyright notice and this paragraph are
included on all such copies and derivative works. However, this
document itself may not be modified in any way, such as by removing
the copyright notice or references to the Internet Society or other
Internet organizations, except as needed for the purpose of
developing Internet standards in which case the procedures for
copyrights defined in the Internet Standards process must be
followed, or as required to translate it into languages other than
English.

The limited permissions granted above are perpetual and will not be
revoked by the Internet Society or its successors or assigns.

This document and the information contained herein is provided on an
"AS IS" basis and THE INTERNET SOCIETY AND THE INTERNET ENGINEERING
TASK FORCE DISCLAIMS ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING
BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION
HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF
MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.

Acknowledgement

Funding for the RFC Editor function is currently provided by the
Internet Society.

 

 

 

 

 

 

 

 

 

Kalt Informational [Page 10]

 

Stern inaktivStern inaktivStern inaktivStern inaktivStern inaktiv

#IRC-Mania Chatraumregeln

Channel Regeln von #IRC-Mania

IRC Kein Platz für Lamer IRC inoffizieller Spackentreffpunkt IRC Land der NickParker IRC Ort der Scheinheiligen IRC DummSchwallerDiskusionsErlebnis IRC PsychoKrieg IRC Meine Welt IRC Mein Untergang IRC DEINE NEUE Familie!
GrundSatz

Der Raum #IRC-Mania sieht sich in erster Linie als Support-Channel für NetzwerkInterne Fragen.
Jegliche Fragen haben im HauptRaum gestellt zu werden. DAU-Fragen sind willkommen, sofern von der NetzBetreiberSeite, keine gescheite FAQ vorliegt, auf die verwiesen wird.
Wer nach einer gescheiten DAU-Frage mit virtuellen Steinen oder Gelächter beschmissen wird, bemerkt hoffentlich in was für einer Umgebung er sich befindet - ! Armen !

#IRCMania steht ! nicht ! für dass gesamte NetzWerk! 
Denn hier ist von Beginn an niemand willkommen, sämtliche RaumBesucher werden nur geduldet !
Solltest Du wegen einer RegelMissachtung vom Channel gekickt werden, hat das nichts mit dem Netzwerk zutun ! Jedoch sollstest Du Dich glücklich schätzen und den Raum von 'da' an nicht mehr betreten. Denn Du bist bekanntlich nicht willkommen !

Siehe auch unsere Netzwerk-RegelnChannel-RegelnProxy-Regelung sowie Bot-Regeln

Verhaltens-Regeln
  1. Wenn Du den Raum betrittst , hast Du zu Grüssen ;)

  2. Fragen werden grundsätzlich nur im HauptRaum verfasst - Queries werden nicht akzeptiert !

  3. Wer Fragen hat, sollte nicht erst nachfragen ob er eine stellen darf !
    Denn das suckt und koennte zu nem' Ignore führen!

  4. Spam ist auch *hier* nicht willkommen.
    Seiten die tausendmal hintereinander geschrieben werden, kommen auf die SpammListe.
    Zudem sei drauf hingewiesen, das der WebMaster der jeweiligen Seite kein geniales
    Konzept haben kann, daher werden solche WebAngebote von den Usern ignoriert. 

  5. Gleiche gilt für sämtliche TimerScripte wie MP3-Away und sonstige ZeitScripte !
    Denn uns geht es am Ar~m vorbei, was Du gerade für Musik hoerst
    oder warum Du away bist. Wenn wir das wissen wollen, lassen wir Dich an
    unsere Neugierde teilhaben !

  6. Wie auch TimerScripte werden bunte KiddyScripte ungern gesehen.
    Der Chat soll zu Kommunikationzwecken eingesetzt werden. 
    Es ist kein MalWettbewerb, wenn Du einzelne Passagen deutlich hervorheben moechtest, sind 
    Farben natürlich erlaubt. Doch spare in der Hinsicht !

  7. #IRCMania ist kein BotChannel 
    Bots, die dort abgelegt werden haben nicht rumzuseenen, 
    oder andere Remoteaktivitäten zu handlen.

  8. Ebenfalls ist dies kein PoppTreffen
    Wenn Du einsam und allein bist - pech - wird schon seine Gründe haben.
    Versuche nicht 'übern' Raum dumm rumzuflirten ! Dies sei ausschliesslich den
    OPs gegönnt! Da es sich um einen SupportChannel handelt, ist es recht wurscht, wie
    alt die beteiligten sind, bzw woher sie kommen. 
    Solltest Du diese Frage sofort nach/vor der Begrüssung stellen, kann dies
    einen Ban/Kick nachsich ziehen

  9. Mache nur einmal auf ein NetzWerkProblem aufmerksam!
    Solltest Du bemerken, dass einige IRC-Mania-Services nicht funktionieren,
    dann kannst Du dies gerne im Channel anmerken. Sollte dieses Thema aber schon
    behandelt werden, dann hat sich das ;) Mecker nicht rum, vermeide weiterhin Queries
    und das wichtigste DROHE net ;) Wir bieten alles kostenlos an, wir sch***** auf
    jeden einzeln Channel/Benutzer der dies nicht berücksichtigt.
    Es gibt sau viele IRCNetze mit mind. den selben Service. 
    - Geh' oder lass es -

Im Falle einer Belästigung

Wer sich von einem User oder Benutzergruppe arghe belästigt fühlt, kann dies unter umständen gerne melden. Wir weisen jedoch darauf hin, das die Benutzer selbst für die Inhalte verantwortlich sind !
Siehe auch Netzwerk-Regeln . Unser Netzwerk unterstützt eine ignore-Funktion. Diese ermöglicht es, Benutzer oder benutzergruppen ignorieren zulassen. Wir bitten und verlangen auch diese, im Falle einer Belästigung, zu benutzen !