Difference between revisions of "RFC1312"
imported>Admin (Created page with " Network Working Group R. Nelson Request for Comments: 1312 Crynwr Software Obsoletes: [[RFC1159|RF...") |
|||
Line 1: | Line 1: | ||
− | |||
Line 7: | Line 6: | ||
Network Working Group R. Nelson | Network Working Group R. Nelson | ||
Request for Comments: 1312 Crynwr Software | Request for Comments: 1312 Crynwr Software | ||
− | Obsoletes: | + | Obsoletes: RFC 1159 G. Arnold |
Sun Microsystems, Inc. | Sun Microsystems, Inc. | ||
April 1992 | April 1992 | ||
− | |||
Message Send Protocol 2 | Message Send Protocol 2 | ||
− | |||
Status of this Memo | Status of this Memo | ||
− | |||
This memo defines an Experimental Protocol for the Internet | This memo defines an Experimental Protocol for the Internet | ||
community. Discussion and suggestions for improvement are requested. | community. Discussion and suggestions for improvement are requested. | ||
Line 21: | Line 17: | ||
Standards" for the standardization state and status of this protocol. | Standards" for the standardization state and status of this protocol. | ||
Distribution of this memo is unlimited. | Distribution of this memo is unlimited. | ||
− | |||
Discussion | Discussion | ||
− | |||
The Message Send Protocol is used to send a short message to a given | The Message Send Protocol is used to send a short message to a given | ||
user on a given terminal on a given host. Unix's write command | user on a given terminal on a given host. Unix's write command | ||
offers a limited form of this service through its host-local write | offers a limited form of this service through its host-local write | ||
command. This service is also known on some hosts as "SEND". | command. This service is also known on some hosts as "SEND". | ||
− | |||
As the Internet grows, more and more people are using hosts that do | As the Internet grows, more and more people are using hosts that do | ||
not run Internet protocols at all times. These hosts may be able to | not run Internet protocols at all times. These hosts may be able to | ||
use a simple protocol that can be implemented using UDP and IP. The | use a simple protocol that can be implemented using UDP and IP. The | ||
Message Send Protocol is one such protocol. | Message Send Protocol is one such protocol. | ||
− | |||
Note that a message sending protocol is already defined using TCP. | Note that a message sending protocol is already defined using TCP. | ||
The SMTP protocol includes a "SEND" command that will direct mail to | The SMTP protocol includes a "SEND" command that will direct mail to | ||
Line 41: | Line 33: | ||
purposes of standardization, we will include a TCP based Message Send | purposes of standardization, we will include a TCP based Message Send | ||
Service. | Service. | ||
− | |||
Message Syntax | Message Syntax | ||
− | |||
The message consists of several parts, all of which must be present | The message consists of several parts, all of which must be present | ||
The first part is a single octet indicating the protocol revision, | The first part is a single octet indicating the protocol revision, | ||
Line 49: | Line 39: | ||
sequences of eight-bit characters in the ISO 8859/1 alphabet. Some | sequences of eight-bit characters in the ISO 8859/1 alphabet. Some | ||
parts may be empty. All comparisons of parts (e.g., recipient, | parts may be empty. All comparisons of parts (e.g., recipient, | ||
+ | |||
+ | |||
Line 59: | Line 51: | ||
cookie, etc.) are case-insensitive. The parts are as follows: | cookie, etc.) are case-insensitive. The parts are as follows: | ||
− | |||
RECIPIENT The name of the user that the message is directed to. | RECIPIENT The name of the user that the message is directed to. | ||
If this part is empty, the message may be delivered to | If this part is empty, the message may be delivered to | ||
any user of the destination system. | any user of the destination system. | ||
− | |||
RECIP-TERM The name of the terminal to which the message is to be | RECIP-TERM The name of the terminal to which the message is to be | ||
delivered. The syntax and semantics of terminal names | delivered. The syntax and semantics of terminal names | ||
Line 77: | Line 67: | ||
place where the message is most likely to be seen by a | place where the message is most likely to be seen by a | ||
human operator or administrator. | human operator or administrator. | ||
− | |||
MESSAGE The actual message. The server need not preserve the | MESSAGE The actual message. The server need not preserve the | ||
formatting and white-space content of the message if | formatting and white-space content of the message if | ||
Line 86: | Line 75: | ||
other end-of-line convention is followed, but a | other end-of-line convention is followed, but a | ||
conforming client must use CR + LF.) | conforming client must use CR + LF.) | ||
− | |||
The message text may only contain printable characters | The message text may only contain printable characters | ||
from the ISO 8859/1 set, which is upward compatible | from the ISO 8859/1 set, which is upward compatible | ||
Line 97: | Line 85: | ||
may reject the entire message.) If the MESSAGE part is | may reject the entire message.) If the MESSAGE part is | ||
empty, the message may be discarded by the server. | empty, the message may be discarded by the server. | ||
− | |||
SENDER The username of the sender. (This and subsequent parts | SENDER The username of the sender. (This and subsequent parts | ||
were not present in version 1 of the Message Send | were not present in version 1 of the Message Send | ||
Line 103: | Line 90: | ||
choose to accept, reject or ignore messages in which | choose to accept, reject or ignore messages in which | ||
the SENDER part is empty. | the SENDER part is empty. | ||
− | |||
SENDER-TERM The name of the sending user's terminal. This part may | SENDER-TERM The name of the sending user's terminal. This part may | ||
be empty. The intention is that a recipient may reply | be empty. The intention is that a recipient may reply | ||
+ | |||
+ | |||
Line 115: | Line 103: | ||
(The sender's hostname should be retrieved from the | (The sender's hostname should be retrieved from the | ||
transport software.) | transport software.) | ||
− | |||
COOKIE A magic cookie. This part must be present in all | COOKIE A magic cookie. This part must be present in all | ||
messages, but is only of significance for the UDP | messages, but is only of significance for the UDP | ||
Line 127: | Line 114: | ||
length of a cookie is 32 octets, excluding the | length of a cookie is 32 octets, excluding the | ||
terminating null. | terminating null. | ||
− | |||
SIGNATURE A token which, if present, may be used by the server | SIGNATURE A token which, if present, may be used by the server | ||
to verify the identity of the sender. The use of the | to verify the identity of the sender. The use of the | ||
SIGNATURE part is discussed further in the section on | SIGNATURE part is discussed further in the section on | ||
Security, below. | Security, below. | ||
− | |||
The total length of the message shall be less than 512 octets. This | The total length of the message shall be less than 512 octets. This | ||
includes all eight parts, and any terminating nulls. UDP packets are | includes all eight parts, and any terminating nulls. UDP packets are | ||
limited to 512 octets. | limited to 512 octets. | ||
− | |||
If this protocol is changed, the revision number will be changed. | If this protocol is changed, the revision number will be changed. | ||
− | |||
TCP Based Message Send Service | TCP Based Message Send Service | ||
− | |||
One Message Send Service is defined as a connection based application | One Message Send Service is defined as a connection based application | ||
on TCP. A server listens for TCP connections on TCP port 18. Once a | on TCP. A server listens for TCP connections on TCP port 18. Once a | ||
connection is established a message is sent by the client over the | connection is established a message is sent by the client over the | ||
connection. | connection. | ||
− | |||
The server replies with a single character indicating positive ("+") | The server replies with a single character indicating positive ("+") | ||
or negative ("-") acknowledgment, immediately followed by an optional | or negative ("-") acknowledgment, immediately followed by an optional | ||
Line 153: | Line 134: | ||
some user/terminal, and that the negative acknowledgement means that | some user/terminal, and that the negative acknowledgement means that | ||
the message was NOT delivered to any terminal. | the message was NOT delivered to any terminal. | ||
− | |||
The positive acknowledgement message can contain information about | The positive acknowledgement message can contain information about | ||
what user and terminal the message was delivered to in the case of | what user and terminal the message was delivered to in the case of | ||
Line 159: | Line 139: | ||
acknowledgement can contain information about WHY the message was not | acknowledgement can contain information about WHY the message was not | ||
delivered (no such user/terminal, system failure, user doesn't accept | delivered (no such user/terminal, system failure, user doesn't accept | ||
+ | |||
+ | |||
Line 165: | Line 147: | ||
messages, etc). | messages, etc). | ||
− | |||
Multiple messages can be sent over the same channel. The client | Multiple messages can be sent over the same channel. The client | ||
should close first (the server may/should not close directly after | should close first (the server may/should not close directly after | ||
Line 173: | Line 154: | ||
close the channel (on the assumption that the sender may have | close the channel (on the assumption that the sender may have | ||
formatted the data incorrectly). | formatted the data incorrectly). | ||
− | |||
UDP Based Message Send Service | UDP Based Message Send Service | ||
− | |||
Another Message Send Service is defined as a datagram based | Another Message Send Service is defined as a datagram based | ||
application on UDP. A server listens for UDP datagrams on UDP port | application on UDP. A server listens for UDP datagrams on UDP port | ||
Line 185: | Line 164: | ||
any user (i.e., the RECIPIENT part is empty), or if the message could | any user (i.e., the RECIPIENT part is empty), or if the message could | ||
not be delivered for some reason, no reply is sent. | not be delivered for some reason, no reply is sent. | ||
− | |||
The reason for this policy is that the UDP service may be used to | The reason for this policy is that the UDP service may be used to | ||
broadcast messages addressed to a particular user on an unknown | broadcast messages addressed to a particular user on an unknown | ||
Line 197: | Line 175: | ||
a broadcast message to a particular recipient. The approach adopted | a broadcast message to a particular recipient. The approach adopted | ||
here provides a reasonable compromise. | here provides a reasonable compromise. | ||
− | |||
Example of Message Encoding | Example of Message Encoding | ||
− | |||
Consider a situation in which the user "sandy" is logged into the | Consider a situation in which the user "sandy" is logged into the | ||
console of system "alpha", and wishes to send a message to the user | console of system "alpha", and wishes to send a message to the user | ||
Line 205: | Line 181: | ||
the exact terminal is unknown. The message consists of two lines of | the exact terminal is unknown. The message consists of two lines of | ||
text, "Hi" followed by "How about lunch?". | text, "Hi" followed by "How about lunch?". | ||
+ | The message would be encoded as follows: | ||
+ | |||
− | |||
Line 250: | Line 227: | ||
56 | <NULL> | | 56 | <NULL> | | ||
+--------+ | +--------+ | ||
− | |||
Note that the RECIP-TERM and SIGNATURE parts are empty. The COOKIE | Note that the RECIP-TERM and SIGNATURE parts are empty. The COOKIE | ||
Line 258: | Line 234: | ||
the message; the server must obtain this information from the | the message; the server must obtain this information from the | ||
transport service. | transport service. | ||
− | |||
Advisories | Advisories | ||
− | |||
Client and server implementations must follow the character set | Client and server implementations must follow the character set | ||
restrictions noted in the MESSAGE part description. Failure to do so | restrictions noted in the MESSAGE part description. Failure to do so | ||
may have undesirable effects on the operation of the receiver's | may have undesirable effects on the operation of the receiver's | ||
terminal; more seriously, it may open up a significant security | terminal; more seriously, it may open up a significant security | ||
+ | |||
+ | |||
Line 278: | Line 254: | ||
reject a message which might be interpreted as an executable | reject a message which might be interpreted as an executable | ||
PostScript program. | PostScript program. | ||
− | |||
The underlying transport, whether TCP or UDP, is expected to provide | The underlying transport, whether TCP or UDP, is expected to provide | ||
checksums for the message and any response. | checksums for the message and any response. | ||
− | |||
The semantics of the various RECIPIENT and RECIP-TERM combinations | The semantics of the various RECIPIENT and RECIP-TERM combinations | ||
may be confusing. The introduction of the "*" wildcard designation in | may be confusing. The introduction of the "*" wildcard designation in | ||
Line 287: | Line 261: | ||
terminals on the designated system (if RECIPIENT is empty), or to all | terminals on the designated system (if RECIPIENT is empty), or to all | ||
terminals at which a particular recipient has logged in. | terminals at which a particular recipient has logged in. | ||
− | |||
A positive acknowledgement may indicate only that the Message Send | A positive acknowledgement may indicate only that the Message Send | ||
server was able to successfully invoke a local message delivery | server was able to successfully invoke a local message delivery | ||
service. It may not be possible for true end-to-end semantics to be | service. It may not be possible for true end-to-end semantics to be | ||
inferred. | inferred. | ||
− | |||
For example, a Message Send server may employ a local delivery | For example, a Message Send server may employ a local delivery | ||
mechanism which calls upon the services of a window system to display | mechanism which calls upon the services of a window system to display | ||
Line 303: | Line 275: | ||
confirmation by the user that the message has been read by, e.g., | confirmation by the user that the message has been read by, e.g., | ||
dismissing the pop-up window. | dismissing the pop-up window. | ||
− | |||
Security Considerations | Security Considerations | ||
− | |||
Those who plan to implement this service must ensure that the | Those who plan to implement this service must ensure that the | ||
following issues are reflected in the documentation of their | following issues are reflected in the documentation of their | ||
Line 311: | Line 281: | ||
configuration controls to allow systems and network administrators to | configuration controls to allow systems and network administrators to | ||
achieve the appropriate levels of usability and security. | achieve the appropriate levels of usability and security. | ||
− | |||
First, this service may allow someone to write on a user's terminal | First, this service may allow someone to write on a user's terminal | ||
without the user giving his or her permission. Where possible, users | without the user giving his or her permission. Where possible, users | ||
should be provided with a mechanism for disabling this. | should be provided with a mechanism for disabling this. | ||
− | |||
Second, it is extremely important for implementors to observe the | Second, it is extremely important for implementors to observe the | ||
rules for filtering message text as discussed under Message Syntax | rules for filtering message text as discussed under Message Syntax | ||
+ | |||
+ | |||
Line 324: | Line 294: | ||
above. Failure to do this may introduce major security holes. | above. Failure to do this may introduce major security holes. | ||
− | |||
The third issue concerns the verification of the sender's identity. | The third issue concerns the verification of the sender's identity. | ||
If the recipient is fooled into believing that a message is from a | If the recipient is fooled into believing that a message is from a | ||
particular user, various security issues may arise. For example, the | particular user, various security issues may arise. For example, the | ||
recipient may send a reply containing confidential material. | recipient may send a reply containing confidential material. | ||
− | |||
This service is primarily intended for "open" environments: | This service is primarily intended for "open" environments: | ||
controlled local area networks used by reasonably trusted | controlled local area networks used by reasonably trusted | ||
Line 336: | Line 304: | ||
it is appropriate to trust the user name and source IP address as | it is appropriate to trust the user name and source IP address as | ||
identifying the actual sender of the message. | identifying the actual sender of the message. | ||
− | |||
Within more security-conscious environments, this assumption is | Within more security-conscious environments, this assumption is | ||
probably unacceptable. As has been widely noted, there is no way | probably unacceptable. As has been widely noted, there is no way | ||
Line 342: | Line 309: | ||
address of an IP datagram is correct. Hence it is entirely possible | address of an IP datagram is correct. Hence it is entirely possible | ||
for someone to spoof the IP address. | for someone to spoof the IP address. | ||
− | |||
The obvious, and simplest, answer is to disallow the use of this | The obvious, and simplest, answer is to disallow the use of this | ||
protocol in such situations. However a more constructive approach is | protocol in such situations. However a more constructive approach is | ||
to incorporate within the protocol some mechanism by which a server | to incorporate within the protocol some mechanism by which a server | ||
can reliably identify the sender. | can reliably identify the sender. | ||
− | |||
In this version of the protocol specification, we define a SIGNATURE | In this version of the protocol specification, we define a SIGNATURE | ||
part within a message. If this part is empty, the identity of the | part within a message. If this part is empty, the identity of the | ||
Line 357: | Line 322: | ||
and privacy issues; at an appropriate time, this RFC will be re- | and privacy issues; at an appropriate time, this RFC will be re- | ||
issued to include references to these RFCs. | issued to include references to these RFCs. | ||
+ | Acknowledgements | ||
+ | PostScript is a trademark of Adobe Systems, Inc. | ||
− | |||
− | |||
Line 377: | Line 342: | ||
Authors' Addresses | Authors' Addresses | ||
− | |||
Russell Nelson | Russell Nelson | ||
Crynwr Software | Crynwr Software | ||
11 Grant St. | 11 Grant St. | ||
Potsdam, NY 13676 | Potsdam, NY 13676 | ||
− | |||
Phone: (315) 268-1925 | Phone: (315) 268-1925 | ||
EMail: [email protected] | EMail: [email protected] | ||
− | |||
Geoff Arnold | Geoff Arnold | ||
Line 391: | Line 353: | ||
2 Federal Street | 2 Federal Street | ||
Billerica, MA 01821 | Billerica, MA 01821 | ||
− | |||
Phone: (508) 671-0317 | Phone: (508) 671-0317 | ||
EMail: [email protected] | EMail: [email protected] |
Revision as of 06:51, 23 September 2020
Network Working Group R. Nelson Request for Comments: 1312 Crynwr Software Obsoletes: RFC 1159 G. Arnold
Sun Microsystems, Inc. April 1992
Message Send Protocol 2
Status of this Memo This memo defines an Experimental Protocol for the Internet community. Discussion and suggestions for improvement are requested. Please refer to the current edition of the "IAB Official Protocol Standards" for the standardization state and status of this protocol. Distribution of this memo is unlimited. Discussion The Message Send Protocol is used to send a short message to a given user on a given terminal on a given host. Unix's write command offers a limited form of this service through its host-local write command. This service is also known on some hosts as "SEND". As the Internet grows, more and more people are using hosts that do not run Internet protocols at all times. These hosts may be able to use a simple protocol that can be implemented using UDP and IP. The Message Send Protocol is one such protocol. Note that a message sending protocol is already defined using TCP. The SMTP protocol includes a "SEND" command that will direct mail to a user's terminal. SMTP's SEND is not useful in this instance because SMTP's SEND is not implemented by the majority of vendors at this time, and is difficult to use by unskilled users. For the purposes of standardization, we will include a TCP based Message Send Service. Message Syntax The message consists of several parts, all of which must be present The first part is a single octet indicating the protocol revision, currently decimal 66, 'B'. The remaining parts are null-terminated sequences of eight-bit characters in the ISO 8859/1 alphabet. Some parts may be empty. All comparisons of parts (e.g., recipient,
cookie, etc.) are case-insensitive. The parts are as follows: RECIPIENT The name of the user that the message is directed to.
If this part is empty, the message may be delivered to any user of the destination system.
RECIP-TERM The name of the terminal to which the message is to be
delivered. The syntax and semantics of terminal names are outside the scope of this specification. If this part is empty, the "right" terminal is chosen. This is a system-dependent function. If this part consists of the string "*", all terminals on the destination system are implied. If the RECIPIENT part is empty but the RECIP-TERM is not, the message is written on the specified terminal. If both the RECIPIENT and RECIP-TERM parts are empty, the message should be written on the "console", which is defined as some place where the message is most likely to be seen by a human operator or administrator.
MESSAGE The actual message. The server need not preserve the
formatting and white-space content of the message if this is necessary to display it. New lines should be represented using the usual Netascii CR + LF. (Following the Internet tradition, a server should probably be prepared to accept a message in which some other end-of-line convention is followed, but a conforming client must use CR + LF.) The message text may only contain printable characters from the ISO 8859/1 set, which is upward compatible from USASCII, plus CR, LF and TAB. No other control codes or escape sequences may be included: the client should strip them from the message before it is transmitted, and the server must check each incoming message for illegal codes. (A server may choose to display the message after stripping out such codes, or may reject the entire message.) If the MESSAGE part is empty, the message may be discarded by the server.
SENDER The username of the sender. (This and subsequent parts
were not present in version 1 of the Message Send Protocol.) This part should not be empty. A server may choose to accept, reject or ignore messages in which the SENDER part is empty.
SENDER-TERM The name of the sending user's terminal. This part may
be empty. The intention is that a recipient may reply
to a message by sending the reply to the user SENDER at terminal SENDER-TERM on the originating system. (The sender's hostname should be retrieved from the transport software.)
COOKIE A magic cookie. This part must be present in all
messages, but is only of significance for the UDP service. The combination of the sender's UDP port number and this cookie should be unique. A client may elect to transmit a particular message several times to increase the chances of its reception; a server may use the cookie and port to identify duplicate messages and discard them. A reasonable cookie is the time of day represented in a readable format. The maximum length of a cookie is 32 octets, excluding the terminating null.
SIGNATURE A token which, if present, may be used by the server
to verify the identity of the sender. The use of the SIGNATURE part is discussed further in the section on Security, below.
The total length of the message shall be less than 512 octets. This includes all eight parts, and any terminating nulls. UDP packets are limited to 512 octets. If this protocol is changed, the revision number will be changed. TCP Based Message Send Service One Message Send Service is defined as a connection based application on TCP. A server listens for TCP connections on TCP port 18. Once a connection is established a message is sent by the client over the connection. The server replies with a single character indicating positive ("+") or negative ("-") acknowledgment, immediately followed by an optional message of explanation, terminated with a null. The positive acknowledgement means that the message was successfully delivered to some user/terminal, and that the negative acknowledgement means that the message was NOT delivered to any terminal. The positive acknowledgement message can contain information about what user and terminal the message was delivered to in the case of incomplete user/terminal fields in the message. The negative acknowledgement can contain information about WHY the message was not delivered (no such user/terminal, system failure, user doesn't accept
messages, etc). Multiple messages can be sent over the same channel. The client should close first (the server may/should not close directly after the acknowledgement is sent) and the server may close after some timeout on the order of minutes. If the sever is unable to decode a message, or no message is received within a suitable timeout, it may close the channel (on the assumption that the sender may have formatted the data incorrectly). UDP Based Message Send Service Another Message Send Service is defined as a datagram based application on UDP. A server listens for UDP datagrams on UDP port 18. When a datagram is received by the server, an answering datagram may be sent back to the client. If the message was addressed to a particular user (i.e., the RECIPIENT part was non-empty) and was successfully delivered to that user, a positive acknowledgement should be sent (as described above). If the message was directed at any user (i.e., the RECIPIENT part is empty), or if the message could not be delivered for some reason, no reply is sent. The reason for this policy is that the UDP service may be used to broadcast messages addressed to a particular user on an unknown system or all users on all systems. In either case, it is inappropriate for all servers to send replies. An alternative approach might have been to require that a server only send a reply if a message was addressed explicitly to that system and was not broadcast. Unfortunately, the most popular network programming API does not provide an easy way for an application to determine this; furthermore such a policy would provide no feedback to the sender of a broadcast message to a particular recipient. The approach adopted here provides a reasonable compromise. Example of Message Encoding Consider a situation in which the user "sandy" is logged into the console of system "alpha", and wishes to send a message to the user "chris". "chris" is known to be logged in on the system "beta" but the exact terminal is unknown. The message consists of two lines of text, "Hi" followed by "How about lunch?". The message would be encoded as follows:
+--------+---------+---------+---------+ 0 | B | c | h | r | +--------+---------+---------+---------+ 4 | i | s | <NULL> | <NULL> | +--------+---------+---------+---------+ 8 | H | i | <CR> | <LF> | +--------+---------+---------+---------+ 12 | H | o | w | | +--------+---------+---------+---------+ 16 | a | b | o | u | +--------+---------+---------+---------+ 20 | t | | l | u | +--------+---------+---------+---------+ 24 | n | c | h | ? | +--------+---------+---------+---------+ 28 | <NULL>| s | a | n | +--------+---------+---------+---------+ 32 | d | y | <NULL> | c | +--------+---------+---------+---------+ 36 | o | n | s | o | +--------+---------+---------+---------+ 40 | l | e | <NULL> | 9 | +--------+---------+---------+---------+ 44 | 1 | 0 | 8 | 0 | +--------+---------+---------+---------+ 48 | 6 | 1 | 2 | 1 | +--------+---------+---------+---------+ 52 | 3 | 2 | 5 | <NULL> | +--------+---------+---------+---------+ 56 | <NULL> | +--------+
Note that the RECIP-TERM and SIGNATURE parts are empty. The COOKIE is the string "910806121325", which in this implementation indicates that the message was sent at 12:13:25 on the 6th of August, 1991. The identity if the sending and receiving systems is not included in the message; the server must obtain this information from the transport service. Advisories Client and server implementations must follow the character set restrictions noted in the MESSAGE part description. Failure to do so may have undesirable effects on the operation of the receiver's terminal; more seriously, it may open up a significant security
"hole". The checks must be made on any part of the message which may be displayed, including the sender's name and terminal. This is one case where the admonition to "be liberal in what you accept" is not applicable. A server may chose to apply additional checks to an incoming message, and to reject any message which may pose a security risk. For example, a system using a PostScript-based display may reject a message which might be interpreted as an executable PostScript program. The underlying transport, whether TCP or UDP, is expected to provide checksums for the message and any response. The semantics of the various RECIPIENT and RECIP-TERM combinations may be confusing. The introduction of the "*" wildcard designation in the RECIP-TERM part makes it possible to send a message to all terminals on the designated system (if RECIPIENT is empty), or to all terminals at which a particular recipient has logged in. A positive acknowledgement may indicate only that the Message Send server was able to successfully invoke a local message delivery service. It may not be possible for true end-to-end semantics to be inferred. For example, a Message Send server may employ a local delivery mechanism which calls upon the services of a window system to display the message in a pop-up window. This process may take some significant time to complete, and it is unclear whether it is useful for the server to wait for an indeterminate period before returning an acknowledgement. Therefore, this specification does not prescribe whether the acknowledgement is associated with delivery of the message to the local service, the display of the message, or confirmation by the user that the message has been read by, e.g., dismissing the pop-up window. Security Considerations Those who plan to implement this service must ensure that the following issues are reflected in the documentation of their products, and that their implementations include sufficient configuration controls to allow systems and network administrators to achieve the appropriate levels of usability and security. First, this service may allow someone to write on a user's terminal without the user giving his or her permission. Where possible, users should be provided with a mechanism for disabling this. Second, it is extremely important for implementors to observe the rules for filtering message text as discussed under Message Syntax
above. Failure to do this may introduce major security holes. The third issue concerns the verification of the sender's identity. If the recipient is fooled into believing that a message is from a particular user, various security issues may arise. For example, the recipient may send a reply containing confidential material. This service is primarily intended for "open" environments: controlled local area networks used by reasonably trusted participants, in which security considerations may be relaxed in the interests of ease of use and administration. In such an environment it is appropriate to trust the user name and source IP address as identifying the actual sender of the message. Within more security-conscious environments, this assumption is probably unacceptable. As has been widely noted, there is no way within the current Internet architecture to ensure that the source address of an IP datagram is correct. Hence it is entirely possible for someone to spoof the IP address. The obvious, and simplest, answer is to disallow the use of this protocol in such situations. However a more constructive approach is to incorporate within the protocol some mechanism by which a server can reliably identify the sender. In this version of the protocol specification, we define a SIGNATURE part within a message. If this part is empty, the identity of the sender cannot be verified, and the server implementation may elect to reject all such requests. If the part is not empty, it is treated as a case-insensitive text encoding of some security token. This RFC does not define the encoding or interpretation of this token. We expect that such matters will form part of future RFCs on security and privacy issues; at an appropriate time, this RFC will be re- issued to include references to these RFCs. Acknowledgements PostScript is a trademark of Adobe Systems, Inc.
Authors' Addresses Russell Nelson Crynwr Software 11 Grant St. Potsdam, NY 13676 Phone: (315) 268-1925 EMail: [email protected]
Geoff Arnold Sun Microsystems, Inc. 2 Federal Street Billerica, MA 01821 Phone: (508) 671-0317 EMail: [email protected]