RARE-DRAFT Jeroen Houttuin IESG Mail Applicability Design Team RARE Secretariat <draft-rare-msg-a-bombs-00.txt> April 1994 Bombs series: Behaviour of Mail Based Servers Part 2: A-bombs Answering servers Abstract This document defines rules for the behaviour of Mail Based Echo Servers and Vacation Servers in the Internet. It is highly desirable that other e-mail networks connected to the Internet also implement these rules. Status of this Memo This document is a RARE Draft. RARE Drafts form a subseries of the Internet Drafts, which are working documents of the Internet Engineering Task Force (IETF), its Areas, and its Working Groups. Note that other groups may also distribute working documents as Internet Drafts. For example, RARE Drafts are produced by the RARE Working Groups. Internet Drafts are draft documents valid for a maximum of six months. Internet Drafts may be updated, replaced, or obsoleted by other documents at any time. It is not appropriate to use Internet Drafts as reference material or to cite them other than as a "working draft" or "work in progress." Please check the I-D abstract listing contained in each Internet Draft directory to learn the current status of this or any other Internet Draft. Distribution of this memo is unlimited. This document builds upon the classification of MBS types, which can be found in the Bombs series, part1: C-bombs [13]. Within the context of the connectivity testing tool 'concord', initial work on the requirements for echo servers was done within SWITCH and XNREN ([7], [8]). The document was then integrated in the work of the IESG solicited Mail Applicability Design Team, consisting of: Ned Freed (INNOsoft), Jeroen Houttuin (RARE), John Klensin (INfoods, UN), Keith Moore (University of Tennessee). RARE WG-MSG Expires October 1994 [Page 1]
INTERNET-DRAFT C-bombs April 1994 Depending on the nature of your comments, please respond to one of the following addresses: The main discussion group: wg-msg@rare.nl The design team: mail-as@infoods.unu.edu The author: houttuin@rare.nl Contents 1. Introduction 2 2. General approach 2 3. Implementation levels and protocols 4 4. Rules 4 4.1. Input message restrictions 5 4.2. Output messages 6 4.2.1. Relation to the input message 6 4.2.2. Restrictions 10 4.3. Logging 14 4.4. Access permissions 16 5. Reference implementations 17 6. Acknowledgements 17 7. Security considerations 17 8. Bibliography 17 9. Abbreviations 19 10. Author's Address 19 1. Introduction Mail Based Servers (MBSs) are defined in C-bombs [13] as follows: An MBS is a process that automatically generates one or more messages (the output messages) as a result of receiving a message (the input message). Two main types are identified: repliers and forwarders. This documents deals only with the basic behaviour of a subclass of repliers: echo servers and vacation servers (jointly referred to as 'answering servers'). 2. General approach The overall approach for all MBS header requirements based upon C- bombs [13] is as follows. If all MBSs would agree to implement a common set of behaviour rules, this set could be fairly small. In practice however, there are some reasons why such a 'minimum approach' will not work: RARE WG-MSG Expires October 1994 [Page 2]
INTERNET-DRAFT C-bombs April 1994 - The most obvious reason is that one cannot realistically expect all networks and software developers to implement one common strict set of rules. In different mail communities, different MBS conventions have already been used for a long time. Some of these conventions can be unacceptable for other communities to implement. - MBSs can be built upon different underlying protocols. For instance, it is almost impossible to have a small set of rules that will prevent problems between any combination of MBSs, e.g. between an RFC 822-like MBS running over NJE and a P1 based MBS. More problems can be expected because header fields are crucial for the properly functioning of MBSs, and protocol gateways will not always map header fields bijectively. - Not all MBSs are controlled by software developers or network operators. Any user can write a simple program that will have the functionality of an MBS. Because the 'minimum approach' is not feasible, the bombs series follows the 'unilateral safety approach'. This means that any MBS that implements the complete set of rules should be safe from harm, regardless of what other 'dumb' MBSs it is interacting with. This approach results in quite a large number of recommendations, of which not every single one is strictly necessary to prevent problems, but none of them will 'hurt' the functioning of an MBS. From the previous paragraphs it follows that MBSs do not operate in a vacuum; they interact with other types of MBSs. As a result, the requirements in this document may sometimes look like an overkill when not seen in the light of the behaviour of other types of MBSs. To get an idea of the requirements for other MBSs, please refer to the H-bombs document [12] (which is the predecessor of the bombs series). As for the programming overhead caused by the recommendations, there is at least one example of an echo server (Echoput) that implements all a-bombs rules in two pages of (perl) code. In addition to the rules that protect against loops and explosions, there are also some rules reflecting common sense. For instance, if a user sends a message flagged 'urgent' to an echo server, he would expect not only his request message, but also the reply message to be handled with extra priority. The rules for vacation servers are the same as for echo servers, but due to the lifetime attribute and a vacation server not normally having a separate administrator, these servers have some additional/exceptional rules. RARE WG-MSG Expires October 1994 [Page 3]
INTERNET-DRAFT C-bombs April 1994 3. Implementation levels and protocols Answering servers are normally implemented at UA level. If one wants to test connectivity at a lower level, a message can be sent to a 'nosuchuser' address, which will result in an MTA-generated non- delivery message or report. To a user, it is often not known beforehand in which protocol world (RFC 822, X.400, others) an MBS is located. Also an MBS doesn't normally 'know' in which world a user lives. In order to come to a consistent echo server behaviour regardless of used protocols, this document describes recommendations for both RFC mail and X.400 echo servers. Note that a one hundred percent transparency cannot be reached (yet), because there exists no one-to-one mapping between all RFC mail and X.400 service elements. For the reader's convenience, the rules for MBSs in different implementation levels and protocols are explicitly stated in the appropriate terminologies. The rules are labelled as follows: For Internet mail: #RFC# Applies to RFC 822 on top of RFC 821 (SMTP) based MBSs #1327# Some the RFC 822 rules deal with non-standard headers as described in RFC 1327 For X.400: #400# Applies to X.400 (both 84 and 88) based MBSs #84# Applies to X.400(84) based MBSs #88# Applies to X.400(88) based MBSs #P1# Applies to P1 (MTS) based MBSs #P2# Applies to P2 (UA) based MBSs #P3# Applies to P3 (MTA) based MBSs 4. Rules Depending on implementation level and protocol, answering servers follow, as a minimum, the requirements defined in RFC 822, RFC 821, RFC 1123, X.411, X.420, X.435 etc. For those requirements, the MBS must behave as an automated user or UA, depending on whether it is implemented at UA- or MTS-level, respectively. This chapter describes additional rules for answering servers in terms of RFC 821, RFC 822, P1, P3, and P2. RARE WG-MSG Expires October 1994 [Page 4]
INTERNET-DRAFT C-bombs April 1994 4.1. Input message restrictions 4.1.1. Don't reply to automatically forwarded messages DISCUSSION: There is no need for a user to automatically forward his incoming messages to an echo server or a vacation server. Note that non-auto-forwarded messages can only be unambiguously identified in P2, Internet mail has no standard headers for this purpose. RFC 1327 gateways map this attribute to a new RFC 822 header "Auto- Forwarded:". In the presence of this header, RFC based MBSs can safely assume that the message was indeed auto-forwarded. RULE: An auto-forwarded message is not valid as an input message. The result is the generation of an exception output message. ORIGIN OF RULE: This document. 4.1.2. Don't reply to threads DISCUSSION: It is very unlikely that a user will send a reply to another message as an input message to an answering server. Such a reply or follow-up should either have gone to the MBS administrator (due to the rules in this document) or to any other address that is not an answering server. RULE: An exception output message is generated if the input message contains either of the following headers or attributes: #RFC# In-Reply-To: References: #P2# In-Reply-To crossReferences ORIGIN OF RULE: This document. APPLICABILITY: should. 4.1.3. Valid input message types DISCUSSION #RFC#: An answering server is not to send automatic replies to (automatically generated) non-delivery messages, to avoid loops. In RFC mail, non-delivery messages can be recognised by the empty MAIL FROM: line. RARE WG-MSG Expires October 1994 [Page 5]
INTERNET-DRAFT C-bombs April 1994 RULE: Only the following types of input messages are valid as input messages. Any other type of input message (report, receipt notification) leads to the generation of an exception message. #RFC# Any message that does not have an empty MAIL FROM: line. #84#P1# UserMPDU #84#P2# IM-UAPDU #88#P1# Message #88#P2# IPM #400# P1.Probes are expected to be handled by the MTS and are thus not interpreted by the MBS. 4.2. Output messages 4.2.1. Relation to the input message 4.2.1.1. User can specify alternate output message recipient DISCUSSION: The user may decide that the output message should be sent to another address than his own. This is especially useful when the user is an automated process, e.g. a connectivity checker, with a complex distributed configuration. RULE: If the input message contains the following header or attribute, the output message is sent to that address. If this field contains more than one address, an output message is sent to at least the first address of this field. (Sending to the others is not recommended.) #RFC# Reply-To: #84#P2# replyToUsers #88#P2# reply-recipients ORIGIN OF RULE: Common practice, RFC 821, RFC 822, RFC 1123, X.400. APPLICABILITY: must. 4.2.1.2. Make output messages traceable DISCUSSION: This rule allows the user to find know exactly to which message this output message belongs. RARE WG-MSG Expires October 1994 [Page 6]
INTERNET-DRAFT C-bombs April 1994 ORIGIN OF RULE: RFC 822, X.400, common practice, this document. 4.2.1.2.1. In reply to RULE: The following header or attribute of the output message has the value: #RFC# In-Reply-To: : Message-ID of input message #84#P2# inReplyTo : IPMessageID of input message #88#P2# replied-to-IPM : this-IPM of input message APPLICABILITY: must. 4.2.1.2.2. Subject The following header or attribute of the output message has as value the string 'Re: ', concatenated with the subject of the input message. #RFC# Subject: #P2# subject APPLICABILITY: should. 4.2.1.2.3. References RULE: If the following header or attribute is used in the output message, it has the value: #RFC# References: : Message-ID of input message #84#P2# crossReferences : IPMessageID of input message #88#P2# related-IPMs : this-IPM of input message APPLICABILITY: may. RARE WG-MSG Expires October 1994 [Page 7]
INTERNET-DRAFT C-bombs April 1994 4.2.1.2.4. Alternate recipient can trace originator of the input message DISCUSSION: A user who receives mail from an MBS, without having ordered this information himself, has the right to know who was responsible for having messages sent to his mailbox. The semantics of both RFC 822 and X.400 header fields allow to specify that a message was sent from a certain address, but was authorised by someone else. This matches the semantics needed here. Another reason for using header fields for carrying this information is that the addresses will still be readable for the end-user after the message has crossed a protocol gateway. RULE: #RFC# If the output message is not sent to the originator of the input message, its From: field contains the addresses of the From: and the Sender: fields of the input message. In this case the Sender: field of the output message contains the address of the MBS administrator. #P2# If the output message is not sent to the P2.originator of the input message, its P2.authorizingUsers field contains the addresses of the P2.originator and the P2.authorizingUsers of the input message. ORIGIN OF RULE: This document, RFC 822, RFC 1327, X.400. APPLICABILITY: shall. 4.2.1.4. Body contents DISCUSSION: In order for the user to see what happened to his original input message on its way to the answering server (format, timing etc), the input message is reflected back to the user. Further info- and advertainment about the server can be included as well. See also 4.2.2. ORIGIN OF RULE: Common practice, this document. RULE: The input message (all headers and an optionally truncated part of the body) is included in the output message in an end user readable format, preferably as a MIME message body-part, an IPMS.ForwardedIPMessage bodypart, or in plain ASCII text. APPLICABILITY: must. RARE WG-MSG Expires October 1994 [Page 8]
INTERNET-DRAFT C-bombs April 1994 4.2.1.5. Conservation DISCUSSION: There are a number of headers or attributes, set by the originator of the input message, that are to be set to the same value in the output message. For instance, a user will expect a high priority request to be handled with high priority. The output message will in this case have the same priority. Note that an MBS can, as a local decision, choose to spool all requests in order to spread the MBS load. As long as the local processing of high priority request can be guaranteed to be no slower than that of normal requests, and the following rules for the output messages are followed, these local processing delays will be transparent for the MBS users. 4.2.1.5.1. Retain privacy requests DISCUSSION: The server is to respect the originator's request for privacy. RULE: The following headers or attributes have the same value in the output message as in the input message: #1327# Sensitivity: #1327# Importance: #1327# Priority: #P2# P2.sensitivity #P2# Importance #P1#P3# Priority ORIGIN OF RULE: this document. APPLICABILITY: must. 4.2.1.5.2. Answer in same type of content DISCUSSION: To minimise the chance of UAs not being able to handle a certain message content type, the content type of the output message is the same as that of the input message. RULE: The following headers or attributes have the same value in the output message as in the input message #RFC# MIME-Version: #RFC# Content-Transfer-Encoding: #84#P1#P3# ContentType RARE WG-MSG Expires October 1994 [Page 9]
INTERNET-DRAFT C-bombs April 1994 ORIGIN OF RULE: this document. APPLICABILITY: should. 4.2.2. Restrictions 4.2.2.1. Don't ask for replies DISCUSSION: If an MBS would request some form of reply or report for an output message, other MBSs might as a result automatically send a message, report or (non)delivery message back to the MBS, which is to be avoided at all cost, or to the MBS administrator, which is highly undesirable. ORIGIN OF RULE: This document. 4.2.2.1.1. Don't give incentive to reply to output message DISCUSSION: Replies to the output message should be avoided, especially because they might be generated automatically. RULE: The following headers or attributes are not used in the output message: #RFC#1327# Reply-By: #RFC#1327# Expiry-Date: #P2# Recipient.replyRequest (defaults to FALSE) #84#P2# replyBy #84#P2# expiryDate #88#P2# reply-time #88#P2# Expiry Time #88#P1#P3# Proof-of-delivery-request (defaults to proof-of-delivery-not- requested) APPLICABILITY: shall RARE WG-MSG Expires October 1994 [Page 10]
INTERNET-DRAFT C-bombs April 1994 4.2.2.1.2. Use of Reply-To functionality DISCUSSION: It is redundant to explicitly attract replies to the output message to the MBS administrator, as the other rules in this document will ensure such behaviour. If an MBS decides to explicitly attract replies to the output message to a certain address, that address is not to be the server's address, but preferably the administrators. Since this rule contains three different applicability levels, it is subdivided into 3 rules. A. Don't use Reply-To functionality DISCUSSION: Other rules in this document will ensure that replies to the output message will automatically be sent to the right address (the administrator's). RULE: The following headers or attributes are not used in the output message: #RFC# Reply-To: #84#P2# replyToUsers #88#P2# reply-recipients ORIGIN OF RULE: This document. APPLICABILITY: shall B. Don't attract replies towards the server itself DISCUSSION: If the MBS decides, despite rule A, to attract replies to a certain address, that address is not this (or any other) answering server's. RULE: If the following field is used in the output message, it does not contain the address of the answering server. #RFC# Reply-To: #84#P2# replyToUsers #88#P2# reply-recipients ORIGIN OF RULE: This document. APPLICABILITY: must. RARE WG-MSG Expires October 1994 [Page 11]
INTERNET-DRAFT C-bombs April 1994 C. Attract replies towards the administrator DISCUSSION: If the MBS decides, despite rule A, to attract replies to a certain address, that address is the MBS administrator's. RULE: If the following field is used in the output message, it contains the address of the answering server's administrator. #RFC# Reply-To: #84#P2# replyToUsers #88#P2# reply-recipients ORIGIN OF RULE: This document. APPLICABILITY: should. 4.2.2.2. Avoid non deliverable output messages to cause loops DISCUSSION: If the output message has an MTS-level originator with the address of the answering server itself, a loop can occur if the output message is undeliverable. Note that for X.400 answering servers, this rule affects a P1 attribute, but only when the output message is P2. For instance, consider a P1 distribution list that distributes another content type than P2, say Pc. Since Pc can be completely unstructured, changing the P1.originator would make it impossible to reply to the originator of the input message. Changing the P1.originator will also make sense for content types that have P2 like header fields, e.g. for P35 messages. RULE: The following line or attribute of the output message has the value: #RFC# MAIL FROM: : address of the MBS administrator #P2# P1.originator : address of the MBS administrator ORIGIN OF RULE: Common practice, this document. APPLICABILITY: must. RARE WG-MSG Expires October 1994 [Page 12]
INTERNET-DRAFT C-bombs April 1994 4.2.2.3. Avoid replies to the output message to go back to the server RULE: The following line or attribute of the output message has the value: #RFC# From: : address of the MBS administrator #P2# P2.originator : address of the MBS administrator ORIGIN OF RULE: This document. APPLICABILITY: must. 4.2.2.4. Avoid reports about the output message DISCUSSION: We don't want anything automatically generated in reply to the output message, to avoid loops. A. PerRececipientFlags RULE: #84#P1#P3# Every PerRececipientFlag in the output message has the following bits set: Report Request: 01 User Report Request: 00 (I.e. the Non-delivery Notification service will be prevented) ORIGIN OF RULE: this document. APPLICABILITY: must. B. Don't request Reports or Notifications to the output message RULE: The following attribute is empty in the output message: #84#P2# Recipient.reportRequest #88#P2# NotificationRequests ORIGIN OF RULE: this document. APPLICABILITY: must. RARE WG-MSG Expires October 1994 [Page 13]
INTERNET-DRAFT C-bombs April 1994 4.2.2.5. Extension Identifiers DISCUSSION: There is at least one case where not all P1.ExtensionIdentifiers being different has caused a mailing loop. Although this was due to a software bug, there is no good reason for not using different P1.ExtensionIdentifiers. RULE #P1#: All P1.ExtensionIdentifiers in the output message are distinct. ORIGIN OF RULE: Common practice, common sense, this document. APPLICABILITY: shall. 4.2.2.6. Body contents DISCUSSION: In order for the user to see what happened to his original input message on its way to the answering server (format, timing etc), the input message is reflected back to the user. Further info- and advertainment about the server can be included as well. See also under 4.2.1. ORIGIN OF RULE: Common practice, this document. RULE: Additional information is included in separate bodyparts of the output message. APPLICABILITY: may. 4.3. Logging 4.3.1. Logging for the administrator DISCUSSION: This rule allows the MBS administrator to track down malicious behaviour. RULE: The MBS logs the originator of the input message and all recipient(s) of the output/exception message(s). ORIGIN OF RULE: this document. APPLICABILITY: shall. RARE WG-MSG Expires October 1994 [Page 14]
INTERNET-DRAFT C-bombs April 1994 4.3.2. Log output message IDs DISCUSSION: This will prevent all routing and MTS-redirection loops amongst MBSs. UA level MBSs, which create a new output message for each input message, will at least be safeguarded against mail storms from other MTS based MBSs. RULE: The MBS logs the message ID of every input message and every output message. It generates an exception message if the same message ID is encountered in the input message more than once. ORIGIN OF RULE: This document. Similar techniques are already being used in Netnews. APPLICABILITY: should. 4.3.3. Vacation logging DISCUSSION: Users of vacation servers don't normally want to use a server, but to reach another person. One output message stating that this person is on vacation will be enough. RULE: Vacation servers at least log the originator of the input message. During the lifetime of an vacation server, only one output message per input message originator is generated. ORIGIN OF RULE: This document. Similar techniques are already being used in Netnews. APPLICABILITY: must. 4.3.4. Black list DISCUSSION: Repliers are not to send output messages to addresses which are likely to be repliers themselves, to avoid loops. RULE: Repliers keep a list of loop-suspicious addresses, containing at least the following values for the local address designator (localpart, Surname, CommonName): autoanswer echo listserv mailerdaemon mirror netserv server In this respect, also echo servers can be thought to have a limited lifetime, during which a normal output message (with an extra RARE WG-MSG Expires October 1994 [Page 15]
INTERNET-DRAFT C-bombs April 1994 bodypart containing a warning) will be sent to loop-suspicious addresses only once. This can be implemented by automatically adding the exact suspicious address to a negative access control list. Whenever this list is cleared, the replier can be thought to start a new lifetime. The loop suspicious addresses are matched in any combination of upper and lower case. ORIGIN OF RULE: Tradition, this document. APPLICABILITY: shall. 4.4. Access permissions DISCUSSION: The user is is to be informed whether and why he has not been granted access to the server. ORIGIN OF RULE: Tradition, this document. DISCUSSION #RFC#: Note that in this case the not granted access is to be reported from MTS level, i.e. by the MBS administrator, owner or operator - and not by the MBS itself. RULE: #RFC# In case of an Access Permission violation an exception message is generated with the following text in the message body: "Originator not allowed to send to this address" APPLICABILITY: shall. DISCUSSION #84#: Note that also here the not granted access is to be reported from MTS level, i.e. by the MBS administrator, owner or operator - and not by the MBS itself. This holds for both options: RULE option 1: #84#: In case of an Access Permission violation a P1.DeliveryReportMPDU is generated with the following values: ReasonCode: unableToTransfer(1) DiagnosticCode:uaUnavailable(4) SupplementaryInformation: "Originator not allowed to send to this address" APPLICABILITY: shall. DISCUSSION: This option is preferred, but a P2 server may choose to respond more in line with RFC servers as follows: RARE WG-MSG Expires October 1994 [Page 16]
INTERNET-DRAFT C-bombs April 1994 RULE option 2: #84#P2# In case of an Access Permission violation an exception message is generated with the following text in the message body: "Originator not allowed to send to this address" APPLICABILITY: may. 5. Reference implementations There are a number of MBS implementations that follow most of the recommendations listed in this document. They include the following, all operating at UA level: Name Protocols Contact ---------------------------------------------------------------- Concord RFC, X.400(84) klarenberg@netconsult.ch EAN echo serverX.400 martinez@fundesco.es Echoput RFC, MIME klarenberg@netconsult.ch PP echo server X.400(84 and 88) onions@xtel.co.uk 6. Acknowledgements Thanks for ideas, comments, flames and corrections: Harald Alvestrand (SINTEF), Allan Cargille (XNREN), Urs Eppenberger (SWITCH), Paul Klarenberg (NetConsult AG), Ignacio Martinez (Fundesco), Juan Pizzorno (DFN), Eric Thomas (SUNET), Johan Vromans (Multihouse), Jan van der Weele (Du Pont). 7. Security considerations Security issues are not discussed in this memo. 8. Bibliography [1] Jonathan B. Postel, "Simple Mail Transfer Protocol", RFC 821, University of Southern California, August 1982 [2] Crocker, D., "Standard of the Format of ARPA Internet Text Messages", RFC 822, UDEL, August 1982. RARE WG-MSG Expires October 1994 [Page 17]
INTERNET-DRAFT C-bombs April 1994 [3] R. Braden, Editor, "Requirements for Internet Hosts - - Application and Support", RFC 1123, USC/Information Sciences Institute, October 1989. [4] Kille, S., "Mapping between X.400(1988) / ISO 10021 and RFC 822", RFC 1327, UCL, May 1992. [5] Kille, S., "X.400 1988 to 1984 downgrading", RFC 1328, UCL, May 1992 [6] N. Borenstein, N. Freed, MIME (Multipurpose Internet Mail Extensions), RFC 1341, June 1992 [7] J. Houttuin, "Concord functional specification", COSINE MHS server, Mail: cosine-mhs- server@nic.switch.ch, FTP: nic.switch.ch, Username: cosine , File: tools/operational/concord/xxxxxxxx [8] J. Houttuin, Allan Cargille, "Requirements for concord echo servers and distribution lists", COSINE MHS server, Mail: cosine-mhs-server@nic.switch.ch, FTP: nic.switch.ch, Username: cosine, File: procedures/echo-server-reqs [9] "list of surnames/usernames not to automatically reply to", RARE server, Mail: server@rare.nl, FTP: ftp.rare.nl, File: working-groups/wg-msg/div/dontreply [10] CCITT Recommendations X.400 - X.430. Data Communication Networks: Message Handling Systems. CCITT Red Book, Vol. VIII - Fasc. VIII.7, Malaga- Torremolinos 1984 [11] CCITT Recommendations X.400 - X.420. Data Communication Networks: Message Handling Systems. CCITT Blue Book, Vol. VIII - Fasc. VIII.7, Melbourne 1988 [12] Houttuin, J., "H-bombs: Header Behaviour of MBSs", work in progress, November 1993. [13] Houttuin, J., "C-bombs: Classification of Breeds of MBSs", work in progress, April 1994. RARE WG-MSG Expires October 1994 [Page 18]
INTERNET-DRAFT C-bombs April 1994 9. Abbreviations ASCII American Standard Code for Information Exchange CCITT Comite Consultatif International de Telegraphique et Telephonique COSINE Co-operation for OSI networking in Europe EAN MHS software (not an abbreviation) IESG Internet Engineering Steering Group IETF Internet Engineering Task Force IPM Inter-Personal Message IPN Inter-Personal Notification MHS Message Handling System MBS Mail based server MTA Message Transfer Agent MTL Message Transfer Layer MTS Message Transfer System NJE Network Job Entry PP MHS software (not an abbreviation) RARE Reseaux Associes pour la Recherche Europeenne SMTP simple mail transfer protocol UA User Agent 10. Author's Address Jeroen Houttuin RARE Secretariat Singel 466-468 NL-1017 AW Amsterdam Europe Tel +31 20 6391131 Fax +31 20 6393289 RFC 822 houttuin@rare.nl X.400 /S=houttuin/O=rare/PRMD=surf/ADMD=400net/C=nl/ RARE WG-MSG Expires October 1994 [Page 19]
