From fd578c1469d6fc183f3f2f67ffb41efbaa7abc94 Mon Sep 17 00:00:00 2001 From: Shivaram Lingamneni Date: Sat, 27 Nov 2021 21:17:48 -0500 Subject: [PATCH 1/3] mention reading RPL_WELCOME to get the assigned nick --- _includes/modern-appendix.md | 2 ++ 1 file changed, 2 insertions(+) diff --git a/_includes/modern-appendix.md b/_includes/modern-appendix.md index f9c9105..c15d8d7 100644 --- a/_includes/modern-appendix.md +++ b/_includes/modern-appendix.md @@ -221,6 +221,8 @@ We do try to note numerics where this is the case with a message like *"The text The first message sent after client registration, this message introduces the client to the network. The text used in the last param of this message varies wildly. +The first parameter of this message is the nickname assigned by the network to the client. Since it may differ from the nickname the client requested with the `NICK` command (due to, e.g. server policy restrictions on nicknames), the client SHOULD use this parameter to determine its effective nickname at the time of connection. (Subsequent nickname changes, client-initiated or not, will be communicated by the server using a [NICK message](#nick-message).) + Servers that implement spoofed hostmasks in any capacity SHOULD NOT include the extended (complete) hostmask in the last parameter of this reply, either for all clients or for those whose hostnames have been spoofed. This is because some clients try to extract the hostname from this final parameter of this message and resolve this hostname, in order to discover their 'local IP address'. Clients MUST NOT try to extract the hostname from the final parameter of this message and then attempt to resolve this hostname. This method of operation WILL BREAK and will cause issues when the server returns a spoofed hostname. From 5348e7662522d681551f797ae314a48531a81200 Mon Sep 17 00:00:00 2001 From: Shivaram Lingamneni Date: Sun, 28 Nov 2021 00:23:49 -0500 Subject: [PATCH 2/3] review fixes --- _includes/modern-appendix.md | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/_includes/modern-appendix.md b/_includes/modern-appendix.md index c15d8d7..20e949d 100644 --- a/_includes/modern-appendix.md +++ b/_includes/modern-appendix.md @@ -221,7 +221,7 @@ We do try to note numerics where this is the case with a message like *"The text The first message sent after client registration, this message introduces the client to the network. The text used in the last param of this message varies wildly. -The first parameter of this message is the nickname assigned by the network to the client. Since it may differ from the nickname the client requested with the `NICK` command (due to, e.g. server policy restrictions on nicknames), the client SHOULD use this parameter to determine its effective nickname at the time of connection. (Subsequent nickname changes, client-initiated or not, will be communicated by the server using a [NICK message](#nick-message).) +The first parameter of this message is the nickname assigned by the network to the client. Since it may differ from the nickname the client requested with the `NICK` command (due to, e.g. length limits or policy restrictions on nicknames), the client SHOULD use this parameter to determine its actual nickname at the time of connection. Subsequent nickname changes, client-initiated or not, will be communicated by the server sending a {% message NICK %} message. Servers that implement spoofed hostmasks in any capacity SHOULD NOT include the extended (complete) hostmask in the last parameter of this reply, either for all clients or for those whose hostnames have been spoofed. This is because some clients try to extract the hostname from this final parameter of this message and resolve this hostname, in order to discover their 'local IP address'. From bf372adb2a424ccfb613a190ff170a07508bf2f3 Mon Sep 17 00:00:00 2001 From: Shivaram Lingamneni Date: Sun, 28 Nov 2021 20:23:05 -0500 Subject: [PATCH 3/3] move note about nick detection to connection registration section --- _includes/modern-appendix.md | 2 -- index.md | 1 + 2 files changed, 1 insertion(+), 2 deletions(-) diff --git a/_includes/modern-appendix.md b/_includes/modern-appendix.md index 20e949d..f9c9105 100644 --- a/_includes/modern-appendix.md +++ b/_includes/modern-appendix.md @@ -221,8 +221,6 @@ We do try to note numerics where this is the case with a message like *"The text The first message sent after client registration, this message introduces the client to the network. The text used in the last param of this message varies wildly. -The first parameter of this message is the nickname assigned by the network to the client. Since it may differ from the nickname the client requested with the `NICK` command (due to, e.g. length limits or policy restrictions on nicknames), the client SHOULD use this parameter to determine its actual nickname at the time of connection. Subsequent nickname changes, client-initiated or not, will be communicated by the server sending a {% message NICK %} message. - Servers that implement spoofed hostmasks in any capacity SHOULD NOT include the extended (complete) hostmask in the last parameter of this reply, either for all clients or for those whose hostnames have been spoofed. This is because some clients try to extract the hostname from this final parameter of this message and resolve this hostname, in order to discover their 'local IP address'. Clients MUST NOT try to extract the hostname from the final parameter of this message and then attempt to resolve this hostname. This method of operation WILL BREAK and will cause issues when the server returns a spoofed hostname. diff --git a/index.md b/index.md index 22ee230..8eff7e3 100644 --- a/index.md +++ b/index.md @@ -448,6 +448,7 @@ Additionally, some servers also send a {% message PING %} and require a matching Upon successful completion of the registration process, the server MUST send, in this order, the {% numeric RPL_WELCOME %}, {% numeric RPL_YOURHOST %}, {% numeric RPL_CREATED %}, {% numeric RPL_MYINFO %}, and at least one {% numeric RPL_ISUPPORT %} numeric to the client. The server SHOULD then respond as though the client sent the {% command LUSERS %} command and return the appropriate numerics. If the user has client modes set on them automatically upon joining the network, the server SHOULD send the client the {% numeric RPL_UMODEIS %} reply. The server MAY send other numerics and messages. The server MUST then respond as though the client sent it the {% message MOTD %} command, i.e. it must send either the successful [Message of the Day](#motd-message) numerics or the {% numeric ERR_NOMOTD %} numeric. +The first parameter of the {% numeric RPL_WELCOME %} message is the nickname assigned by the network to the client. Since it may differ from the nickname the client requested with the `NICK` command (due to, e.g. length limits or policy restrictions on nicknames), the client SHOULD use this parameter to determine its actual nickname at the time of connection. Subsequent nickname changes, client-initiated or not, will be communicated by the server sending a {% message NICK %} message. ---