One document matched: draft-rare-msg-a-bombs-00.txt
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]
| PAFTECH AB 2003-2026 | 2026-04-24 14:49:45 |