Remote Write Protocol - Version 1.0
A lightweight network protocol for delivering short interactive messages between users.
Rinne, T., "Remote Write Protocol - Version 1.0", RFC 1756, DOI 10.17487/RFC1756, January 1995, <https://www.rfc-editor.org/info/rfc1756>.
@misc{rfc1756,
series = {Request for Comments},
number = 1756,
howpublished = {RFC 1756},
publisher = {RFC Editor},
doi = {10.17487/RFC1756},
url = {https://www.rfc-editor.org/info/rfc1756},
author = {T. Rinne},
title = {{Remote Write Protocol - Version 1.0}},
pagetotal = 11,
year = 1995,
month = jan,
} RFC text
Contents
Network Working Group T. Rinne
Request for Comments: 1756 HUT
Category: Experimental January 1995
REMOTE WRITE PROTOCOL - VERSION 1.0
Status of this Memo
This memo defines an Experimental Protocol for the Internet
community. This memo does not specify an Internet standard of any
kind. Discussion and suggestions for improvement are requested.
Distribution of this memo is unlimited.
1. Background
It is often convenient to use electronic communication somewhat
lighter than electronic mail. Sometimes even the use of the talk(1)
*) program seems like overkill. We like to offer to user something
like UNIX **) command write(1) ***) except that it can also pass
messages through the network instead of the single host.
There have been few programs offering this kind of service, but they
have either based on SUN-RPC protocol or used a strictly undocumented
protocol.
This document describes a simple Remote Write Protocol (RWP) that
should have been documented at least 10 years ago. But late is
better than never. Version number of the RWP protocol in this
document is 1.0.
2. Overview
RWP is a simple protocol that can be used to relay short messages
through the network to other users. RWP looks pretty much like
Simple Mail Transfer Protocol (SMTP) ****) though it is a bit more
complicated due to the interactive nature of the RWP session.
The idea behind the RWP session is that client program that is
relaying message to the host in which the target user is logged in
opens the tcp or udp connection to the server program running in the
target machine Then the client gives the sender's and recipient's
identification (usually login ids), actual message body and tells the
server to deliver a message to the user. On tcp-connection server
returns a status from each action taken. On udp-connection no
responses are sent. RWP sessions through udp are implemented to
support message broadcasting.
Message delivering methods are not defined within this document, but
the basic method could be a simple write to users terminal. This is
basically what UNIX command write(1) does. Depending on server
implementation, the delivery method could be configurable personally
by each user.
3. Description
Server program answers to each command submitted by a response. All
responses have two parts: three number unique response code and a
short textual explanation of the response. Also whenever the server
is ready to accept new commands a notification is submitted to the
client.
There are three kinds of commands in RWP. The first group is for
querying a status of the server. The second group is actual message
handling commands and the last set of commands are for RWP session
control.
When the server is ready to receive a command from the client, it
sends a message code 100 to the client. This message is for example
as follows:
100 Ready.
Server commands are as follows:
Status Query
HELP Gives a short help message that contains legal
RWP commands. Help lines have code 510. Example RWP
implementation *****) gives a following response to
HELP command:
510 Valid commands are:
510 BYE, DATA, HELP, HELO,
510 RSET, SEND, PROT, QUIT,
510 VRFY, VER
510 FROM senderlogin
510 FHST senderhost
510 TO recipentlogin [tty]
510 FWDS current_hop_count
HELO Says hello to the server. Server response to HELO
command has code 500. For example:
500 Hello remote.host. This is local.host speaking.
PROT Asks the RWP protocol version from the server.
Response code to PROT command is 502. Protocol
version described in this document is RWP 1.0 and the
response is as follows:
502 RWP version 1.0.
VRFY After the recipient of the message is set by to command
described later, the possibility of message delivery
can be queried by VRFY command. If message can be
delivered the response code is 108. If message is
about to be forwarded the response code is 110 and
message is either form:
110 Recipient ok to forward.
or if the server can tell the destination of the
forwarding:
110 Recipient ok to forward <user@host.domain>.
Other possible response codes are 669, 670, 671, 674
and 677 and they all indicate that message delivery is
by one way or another currently impossible.
Description of the codes is later in this document.
After the SEND command the server may also give
autoreply from the remote user before the actual
response code. Autoreply lines are ones of code 300.
VER Asks the version of the server program. Response code
to VER command is 501 and the textual part of the
response is the name and the version number of the RWP
server, for example:
501 Rwrited version 1.0.
Message Handling:
FROM senderlogin
Tells the server the identification information of the
sender of the message. Usually this id information is
user's login id. Response code to successful FROM
command is 105, for example:
105 Sender ok.
TO recipentlogin [tty]
Tells the server the identification information of the
intended recipient of the message. Usually this id
information is user's login id. If tty is submitted,
the message is delivered to that tty. If tty is
submitted between brackets '[]' the tty given is
treated as a hint only. Response code to successful
TO command is 106.
FHST original.host [forwarder1.host forwarder2.host ...]
Tells the server the host name that the message
originates to and the path of the hosts that has
forwarded the message. The host name of the machine
that is currently submitting the message to the server
should not be in the path list.
This information is relevant if message is forwarded
and it is not originally coming from the host that is
forwarding it. Response code to successful FHST
command is 111.
DATA Tells the server to start receive the body of the
message. Response code to DATA command is 200, for
example:
200 Enter message. Single dot '.' on line terminates.
After response 200 the message lines are submitted to
the server one after another. Message is terminated
by the line that contains a single dot '.'. The
termination of the message is acknowledged by the
server with the response code 107. Server does not
notify client about receiving the single message
lines. If empty message is submitted (i.e. single dot
is on the first line) the response code is 672 and
DATA command only cancels possible previous DATA
command. Because of this all dots or at least dots
that are standing alone in the line have to be quoted.
SEND Sends the message. If commands FROM, TO and DATA are
successfully given before SEND command, the message is
delivered to the target user. If delivery is
successful the response code is 103. If message is
not delivered directly to the target user but instead
forwarded to another host the response code is 104.
Response codes 669, 670 and 671, 677 indicate an error
on message delivery and codes 673, 674, 675 indicate
that either command FROM, TO or DATA has not been
successfully given before SEND command. After the
SEND command the server may also give autoreply from
the remote user before the actual response code.
Autoreply lines are ones of code 300.
FWDS n Tells the server that message has been forwarded n
times. If the server forwards the message to the
another server, it increments the counter and tells
the remote server the current count of forwards.
Response code to the FWDS command is 110 if n is less
than the server specific forward limit. If this limit
is exceeded the response code is 676. If the response
code is 676 the client can either quit the session and
fail the message or it can give the message to the
server despite the fact that the forward limit is
exceeded. If the message is given when forward limit
is exceeded, the server tries to deliver it, but does
not forward it to another server. If forward count is
given as -1, the message is considered as a autoreply
and never forwarded.
Session Control:
RSET Resets the RWP session. FROM, TO and DATA -commands
that are given before are canceled and they have to
be given again before SEND command can be used. Also
possible FWDS and FHST commands are canceled.
BYE Terminates the RWP session. Server gives a response
code 101 and closes the connection.
QUIT Is the synonym to bye, but it's a lot more impolite.
Response code is however 101 as in bye.
Server specific command:
QUOTE command
Relay a command to the server. If the QUOTE command
is successfully completed response code 112 is
returned. If QUOTE command is failed the response
code is 678. If RWP server doesn't recognize the
given QUOTE command the response code is 679.
Currently reserved QUOTE commands are AGENT, CHARSET,
IDENT, KEY and KEYID.
4. Response Codes
Here are all legal response codes of RWP server followed by short
textual explanation. Only the numeral codes are important and texts
can contain practically anything, however in response code 110 there
is possibly useful information between '<' and '>' characters. No
characters '<' or '>' should be present in other responses. Also
response 502 has possibly interesting information about the RWP
protocol version the server supports.
100 Ready.
The RWP server is ready to accept next command.
101 Goodbye.
The RWP server is closing connection.
103 Message delivered.
The SEND command is successfully completed and the message is
delivered directly to its destination.
104 Message forwarded.
The SEND command is completed and message is forwarded to the
user.
105 Sender ok.
The FROM command successful.
106 Recipient ok.
The TO command successful.
107 Message ok.
The DATA command successful.
108 Recipient ok to send.
The VRFY command successful and direct message delivery is
possible.
109 RSET ok.
The RWP server has received the RSET command and reset itself.
110 Ok to forward.
or
110 Ok to forward <user@host.domain>.
The VRFY command successful and direct message delivery by
forwarding is possible. If response has also forwarding
address the client can either forward the message itself or
give it to server for forwarding.
111 Original sender host ok.
The FHST command successful and original sender host is set as
given by the client.
200 Enter message. Single dot '.' on line terminates.
The RWP server is ready to receive the message. Single dot on
message line terminates the message.
300 |I'm not in right now but I'll be back tomorrow
300 |at 8 o'clock a.m.
Automatical response to the delivered message. Every line of
this user defined reply message is delivered in its own 300
line. Response code 300 lines may appear only after SEND
command before response code 103 (message delivered). Client
receiving autoreply 300 should show the text of the autoreply
to the user. Actual autoreply line begins after the '|'
-character in the line.
500 Hello remote.host. This is local.host speaking.
Response to the HELO command. This message can also occur in
the beginning of the conversation without the VER command and
it can be ignored.
501 Rwrited version X.X.
Response to the VER command. This message can also occur in
the beginning of the conversation without the VER command and
it can be ignored.
502 RWP version 1.0.
Response to the VER command. This message can also occur in
the beginning of the conversation without the VER command and
it can be ignored.
510 Valid commands are:
510 BYE, DATA, HELP, HELO,
510 RSET, SEND, PROT, QUIT,
510 VRFY, VER
510 FROM senderlogin
510 FHST senderhost
510 TO recipentlogin
510 FWDS current_hop_count
Response to the HELP command.
511 Information to the user.
Server specific informational response. These responses may
occur anytime during the conversation. The client can ignore
them.
512 Debug information to the user.
Server specific informational response. Reserved for server
debugging. These messages may occur anytime during the
conversation. The client can ignore them.
666 FATAL ERROR!
The RWP server got into the fatal error situation and is about
to exit immediately. Client programs are strongly encouraged
to close the connection.
668 Syntax error.
The RWP server has received an invalid command.
669 Permission denied.
The RWP server is unable to deliver the message because the
target user has denied the send permission.
670 User not logged in.
The RWP server is unable to deliver the message because the
target user is not logged in.
671 No such user.
The RWP server is unable to deliver the message because the
target user does not exist. Error code 670 can be used to
replace this message.
672 No message.
The DATA command is terminated with empty message body. No
SEND command can be executed before a new DATA command is
given.
673 FROM command required.
Tried to give the SEND command before FROM.
674 TO command required.
Tried to give the SEND command before TO.
675 DATA command required.
Tried to give the SEND command before DATA.
676 Forward limit exceeded.
Response to the FWDS command that had an argument that
exceeded the server specific limit of message forwarding
steps.
677 Unable to forward message.
or
677 Unable to forward message to <user@host.domain>.
Response to the SEND or VRFY command if message forwarding is
attempted and the server specific limit of message forwarding
steps has been exceeded or if message forwarding has otherwise
failed. If message forwarding fails with message 669, 670 or
671, server will not use response 667 but gives response but
instead it gives the response analogous with the error
occured. If message 677 includes address the message was to
be forwarded, the client may try to deliver it itself.
698 Unknown error.
RWP server has faced an internal error that is not fatal.
699 Unknown error.
RWP server has faced an unknown error that is not fatal.
5. RWP Compliant Software
Simple RWP 1.0 compliant server and client software RWrite-1.1 will
be available during the fall 1994.
6. Security of RWP
RWP version 1.0 does not offer any mean to verify the identity of the
user connecting the RWP server program. It's possible to identify
the sender using ident-service, but not all hosts currently support
that. This vulnerability is analogous with the weakness of the SMTP
protocol. Cryptographic user verification and message hiding method
is under development and is to be defined in RWP version 2.0 during
the year 1995.
RWP server also may offer a way to the intruder to get to know user
ids within the target host by trying the TO and VRFY commands. This
vulnerability is also present in SMTP. It is however possible to
build servers so that they never give message 671 (no such user) but
use response 670 (user not logged in) instead.
Another way to increase security even within RWP-1.0 described in the
document is to design RWP servers so that they do not deliver
messages directly to user but instead connect to some kind of RWP
agent process that is executed by each user willing to receive RWP
messages. This user configurable message agent could then decide
whether to deliver the message to the user and which way of delivery
to use. Message agent is the best way to prevent hostile user from
sending uncontrolled message flood to the user's terminal.
Sample implementation (RWrite-1.0) of the RWP server includes the
support for user configuration files in which each user can either
allow or deny messages from some user(s), host(s) or network
domains(s). Support for message agents is currently under
development.
The user that is receiving the message should be able to define
characters to be stripped from the incoming messages to prevent
terminal mess-up.
7. RWP Connection Type
It is suggested that tcp (and udp) port 18 should be allocated for
rwp in future versions of RFCs listing the reserved tcp/udp/rpc
ports. Currently port 18 is assigned to the service called Message
Send Protocol (msp) that is not known to be implemented. Actually
port 18 is not currently defined at all in the /etc/services -file of
the any common UNIX-like system. Entry for /etc/services -file is as
follows
rwrite 18/udp # RWP rwrite
rwrite 18/tcp # RWP rwrite
Given that RWP compliant daemon program is /usr/sbin/rwrited the
entry for /etc/inetd.conf -file would be:
rwrite stream tcp nowait nobody /usr/sbin/rwrited rwrited
8. Character quotation
To offer a safe method to transfer various character sets RWP defines
a method to quote characters in both message and autoreply. RWP uses
quotation similar to MIME `quoted-printable' encoding. Quoted
character is presented as a '=' -sign followed by a two character hex
code. This means also that all '='-signs have to be quoted.
Quotation is also needed when message contains a line with only a
single dot '.' in it.
For example:
'.' -> =2E
'=' -> =3D
'\a' -> =07
'\t' -> =09
9. Security Considerations
Security issues are not discussed in this memo.
10. Author's Address
Timo J. Rinne
Helsinki University of Technology.
Cirion oy
PO-BOX 250
FIN-00121
Helsinki, Finland
EMail: Timo.Rinne@hut.fi
AI ELI5
On this page
§1Background and Overview
RFC 1756 defines the Remote Write Protocol (RWP), a simple protocol for relaying short messages through a network to other users. It fills a gap between the heaviness of electronic mail and synchronous tools like the UNIX talk program, offering something similar to the UNIX write command but working across networks.
The protocol is designed to be straightforward, resembling SMTP but adapted for the interactive nature of message delivery. A client program connects to an RWP server running on the target machine and exchanges commands and responses to deliver a message to a recipient. RWP supports both TCP (which returns status after each action) and UDP (which broadcasts messages without responses).
RWP is a way to send a short message to someone on another computer, like the write command you can use on one computer but across networks. The server tells you whether it worked.
§2Protocol Commands and Message Flow
An RWP session follows a predictable sequence. When the client connects, the server announces it is ready with response code 100. The client then issues commands to identify the sender, recipient, and message body.
Status query commands help the client learn about the server: HELP lists available commands, HELO greets the server, PROT requests the protocol version, VRFY checks if a recipient exists and can receive messages, and VER requests the server program version.
Message handling commands are the core of the protocol. FROM specifies the sender's login, TO specifies the recipient (optionally with a particular terminal), FHST records the original host and forwarding path for relayed messages, DATA begins message input (terminated by a single dot on a line), and SEND submits the message for delivery. The FWDS command tracks how many times a message has been forwarded, with a server-specific limit to prevent infinite loops.
Session control commands manage the connection: RSET resets the session state, BYE terminates cleanly with response code 101, and QUIT is an impolite synonym for BYE. A QUOTE command allows server-specific extensions.
To send a message, you tell the server who you are (FROM), who to send it to (TO), then give the message (DATA), then say SEND. The server replies after each step to let you know if it worked.
§3Response Codes and Error Handling
Every RWP server action produces a response: a three-digit numeric code and a short text explanation. The code determines what the client should do next.
Success codes in the 100s and 200s indicate successful operations: 100 (Ready), 103 (Message delivered), 104 (Message forwarded), 105-107 (FROM, TO, DATA ok), 108 (Recipient ok to send), and 200 (Enter message). Group 300 carries autoreply messages from the recipient, each line prefixed with 300 and a pipe character.
Error codes 668-699 report failures. Syntax errors produce 668. Delivery failures include 669 (Permission denied), 670 (User not logged in), 671 (No such user), and 672 (Empty message). Operational errors include missing required commands before SEND (673-675), exceeding forwarding limits (676), inability to forward (677), and unknown errors (698-699).
For character set safety, RWP uses MIME-like quoted-printable encoding: special characters are represented as an equals sign followed by two hex digits (e.g., =2E for a dot, =3D for an equals sign). This prevents dots in message bodies from terminating the message prematurely.
The server uses number codes to tell you what happened: numbers like 103 mean success, numbers like 670 mean the person isn't logged in. The codes follow patterns so you can predict what they mean.
§4Deployment and Messaging Delivery
RWP is designed to run on TCP and UDP ports, with port 18 proposed as the standard in the /etc/services file. The protocol is transport-agnostic about how the message is actually presented to the recipient; the basic approach is a write to the user's terminal (matching the UNIX write behavior), but servers can implement configurable delivery methods.
For systems supporting multiple connected networks, an End System may forward a message by adding it to a forwarding path (FHST command) and incrementing a hop counter (FWDS command). This allows RWP messages to traverse multiple networks, though servers enforce a maximum forwarding count to prevent loops. When forwarding is not possible or the limit is exceeded, the server returns an appropriate error and the client may choose to attempt direct delivery despite the restriction.
The reference implementation RWrite-1.0 includes support for user configuration files allowing recipients to permit or deny messages from specific users, hosts, or network domains. Message agents (per-user processes) are under development to provide more sophisticated filtering and delivery options.
RWP runs on a specific port on the remote computer. The message usually appears on the person's screen. If they're not there, the server can forward the message to another server, or tell you the delivery failed.
§5Security and Limitations
RWP version 1.0 has significant security limitations inherited from its design as a simple protocol. The protocol offers no means to verify the identity of connecting users, analogous to SMTP's weakness. While it is possible to identify the sender using the ident service, not all hosts support it. This vulnerability allows any client to claim to be any user.
The server may inadvertently reveal valid user IDs through responses to TO and VRFY commands: responding with 671 (no such user) discloses whether an account exists. Servers can mitigate this by always returning 670 (user not logged in) instead, obscuring the difference between non-existent and offline users.
A hostile sender could flood a user's terminal with unwanted messages. Servers can limit this exposure by delivering messages through a per-user agent process rather than directly to the terminal; such agents can decide whether to accept messages and how to display them.
Cryptographic user verification and message encryption are acknowledged as missing features. RFC 1756 notes that these are under development for RWP version 2.0, planned for 1995. Until then, RWP is suitable only for environments where users trust the network and each other.
The big problem is that RWP doesn't check who you really are before sending a message. Anyone could pretend to be someone else. Also, someone could send you a lot of unwanted messages and mess up your screen. A better version with passwords and encryption was planned but not in version 1.0.