One document matched: draft-rare-msg-c-bombs-01.txt
Differences from draft-rare-msg-c-bombs-00.txt
Abstract
This document defines a classification of Mail Based Servers (MBSs)
according to their behaviour towards their users. The most important
distinction is between mail responders (e.g. echo servers, file
servers) and mail forwarders (e.g. mailing lists, auto-forwarders).
The document aims at a common understanding of these MBS classes and
other common MBS attributes, such as roles (administrators, owners),
MBS lifetime and restricted MBS use.
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.
The predecessor of this document (H-bombs) has been presented and
discussed in several groups since late 1992: the RARE Working Group
on Mail and Messaging (WG-MSG), The GO-MHS managers group, the IETF
X400ops Working Group and the IFIP E-Mail Management Group. It was
then taken over by the IESG solicited "Mail Applicability Statement"
design team in June 1993. In order to make the subject more
manageable, the design team decided to break down the document into
one base document defining the different classes of MBSs (this
document: C-bombs), which is to become in informational RFC / RTR.
Standard track RFCs defining the behaviour of MBSs (e.g. other parts
RARE WG-MSG Expires October 1994 [Page 1]
INTERNET-DRAFT C-bombs April 1994
of H-bombs describe header behaviour) will be based upon the
definitions of C-bombs.
Depending on the nature of your comments, please send them 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. Definitions 3
2.1. MBS 3
2.2. Implementation levels and protocols 4
2.3. Input- and output messages 4
2.4. Roles 4
2.5. Dedicated and non-dedicated MBSs 5
2.6. Message originator 5
2.7. Exception messages 6
2.8. Access permission 6
3. Mail based server classification 6
3.1. Repliers 6
3.1.1. Echo servers 7
3.1.2. Mailer demons 7
3.1.3. Command servers 8
3.1.4. Vacation servers 8
3.2. Forwarders 9
3.2.1. Distribution Lists 9
3.2.2. Redirectors 9
3.2.3. Auto-forwarders 9
4. Implementations 9
5. Security considerations 10
6. Bibliography 10
7. Abbreviations 12
8. Author's Address 12
1. Introduction
Electronic mail systems are increasingly being used as a basis for so
called Mail Based Servers (MBSs), such as echo servers, distribution
lists, file distribution servers, etc. MBSs are used for a number of
purposes:
- Enhancing the Message Handling Environment. Examples of such
usage are distribution lists (DLs), for group communication, and
e-mail servers, for file and information retrieval.
RARE WG-MSG Expires October 1994 [Page 2]
INTERNET-DRAFT C-bombs April 1994
- Monitoring the status of the MHS. Examples of this usage are
echo servers and forced (non-)delivery messages (E.g. the so-
called nosuchuser test).
Since MBSs deal with automatically receiving, forwarding and replying
to messages, which may themselves have been generated by automated
processes, strong requirements are needed on the one hand to minimise
human effort to manage such servers, and on the other hand to make
the behaviour of mail based servers deterministic enough to build
reliable tools upon them.
A classic example of what can go wrong is when a mailing list
contains an invalid address. The remote mailer generates a non-
delivery message and sends it to the originator of the original
message, which, under some circumstances, could be the list itself,
which then distributes the non-delivery message to the list, and thus
also to the erroneous address, etc. etc. Following strict
recommendations on how mailing lists should deal with message header
fields can avoid such looping-endangered situations.
This document aims to facilitate such standardisation of MBS
behaviour by defining a classification of MBSs and describing which
attributes belong to each MBS class.
2. Definitions
This chapter defines some attributes that are common to all MBSs.
2.1. MBS
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).
The number of output messages and its contents depend on the kind of
server and on the contents of the input message.
Note that our definition rules out a number of mail based
applications:
- A process that is in someway triggered by an input message, but
does not necessarily generate an output message. Think of
process control applications.
- Applications that need more than one input message to trigger
the generation of an output message. For such work flow
management types of applications, it is already nearly
impossible to define globally applicable rules for how the
recipient of the output message(s) should be determined. It is
RARE WG-MSG Expires October 1994 [Page 3]
INTERNET-DRAFT C-bombs April 1994
however possible to treat an MBS as a special subclass of such
systems, namely where the number of input messages is exactly
one. Hopefully this document can be used as a starting point for
later studies on the behaviour of more complex systems.
- Applications that do not completely automatically generate
output messages. This rules out mail based applications that
need (human) intervention, such as moderated distribution lists.
2.2. Implementation levels and protocols
An MBS can be modelled and implemented in one of the following ways:
In Internet terminology: As a process built directly on top of SMTP.
This is called an 821 MBS. If, in addition, the MBS is RFC 822 based,
it is called an 822 MBS.
In X.400 terminology: within the MTS, in which case it can be
considered an enhancement of the X.400 message dispatcher (see [11]).
This is called a P1 MBS. Or, as an MTS service user, in which case it
can be considered an automated User Agent (UA). Per default, this is
called a P3 MBS. If, in addition, the MBS is P2 based, it is called a
P2 MBS.
Regardless whether an MBS is X.400 or RFC based, we will use the
following terms for implementation levels:
UA level: RFC 822, MIME, P2, P22, P7.
MTS level: RFC 821, P3.
MTA level: RFC 821, P1.
2.3. Input- and output messages
An input message is a message that triggers the generation of one or
more output messages by an MBS.
An output message is a message that is being generated by an MBS as a
result of receiving an input message.
2.4. Roles
For every dedicated MBS, there exists an MBS administrator who is
responsible for managing the MBS. This person, or group of persons,
must track down, act upon and be informed about possible malbehaviour
of the server, such as loops, unreachable addresses on mailing lists
and rejected messages.
RARE WG-MSG Expires October 1994 [Page 4]
INTERNET-DRAFT C-bombs April 1994
Other possible roles related to the management of an MBS are:
Owner Has the responsibility for the existence of the
MBS.
Operator Operates the hard- and software.
Moderator Moderates a mailing list.
Other Many other roles can be thought of.
Note that in practice, most of these roles will be played by one and
the same person. The most important role in this document is that of
the MBS administrator.
2.5. Dedicated and non-dedicated MBSs
A dedicated MBS is an MBS that is meant to be used as an MBS only.
Examples of non-dedicated MBSs are temporarily auto-forwarding user
agents (UAs), and UAs that automatically send back vacation notes
(vacation servers). Although software developers are encouraged to
implement such features as if it concerned a dedicated MBS, there are
some differences between the two types. For instance, it is not
realistic to assume a separate MBS administrator for every stand-
alone UA. Also, non-dedicated MBSs often have a limited life time.
2.6. Message originator
A number of definitions and behaviour rules for MBSs require a clear
understanding of the term 'message originator'. In particular, the
originator of the input message must be well defined. Depending on
implementation level and protocols, a message originator is defined
as follows:
- For Internet Mail: The UA-level originator of an input message
is defined as the RFC 822 Sender: , and in the absence of that
header, the RFC 822 From:
- For X.400: The UA-level originator of an input message is
defined as the P2.originator, or if this attribute is not
present, the P2.authorizingUsers
Exception messages are always sent to the MTS-level originator, which
is defined as:
- For Internet Mail: The MTS-level originator of the input message
is defined as the MAIL FROM: address. For RFC 822 based MBSs
that, for some reason, cannot access the MAIL FROM: address, the
MTS-level originator of an input message is defined as the RFC
822 Return-Path: . If this header is not available either, the
MTS-level originator of an input message is defined as the RFC
822 Sender: , and in the absence of that header, the RFC 822
From:
RARE WG-MSG Expires October 1994 [Page 5]
INTERNET-DRAFT C-bombs April 1994
- For X.400: The MTS-level originator of an input message is
defined as the P1 or P3 originator. For P2 based MBSs that
cannot access P3 attributes, the MTS-level originator of an
input message is defined as the P2.originator, or if this
attribute is not present, the P2.authorizingUsers.
These definitions are based on [1], [2], [11] and [12].
In the remainder of this document, the term 'originator' is used to
refer to either a UA- or an MTS-level originator.
2.7. Exception messages
An exception message is a message that is generated by the MBS
instead of a normal output message. It is addressed to the MBS
administrator only and contains in readable format (ASCII, MIME,
IA5Text, ASN.1) both a description of the reason why the exception
message was generated as well as a complete as possible copy of the
original input message. Exceptions messages are normally generated
when some header conditions are violated. The precise rules for this
can be found in the follow up documents in this series (e.g. [9]).
2.8. Access permission
Associated with an MBS is a number of originator addresses that are
allowed to use the MBS (i.e. to have the MBS send output messages).
Implementation of MBS access permission is considered a local matter.
The main implementation options are:
- Implicit: Only those addresses explicitly listed are not allowed
to send messages to the MBS.
- Explicit: Only those addresses explicitly listed are allowed to
send messages to the MBS.
3. Mail based server classification
This chapter defines the different types of MBSs. Two main types are
identified: repliers and forwarders.
3.1. Repliers
Intuitively speaking, a replier is an MBS that will send an output
message to the originator of the input message. There are also
exceptions to this rule, such as replying to a Reply-To: field. More
formally speaking, a replier is characterised by the fact that the
RARE WG-MSG Expires October 1994 [Page 6]
INTERNET-DRAFT C-bombs April 1994
recipient of the output message is uniquely defined in (the heading
of) the input message. The different types of repliers can be
classified by the number and content of the output message.
Implementation level: Most existing repliers operate at UA level.
Associated roles: administrator, owner, operator.
Access permissions: any.
3.1.1. Echo servers
An echo server is a dedicated replier that will generate exactly one
output message, containing at least the input message.
Implementation level: Although most existing echo servers operate at
UA level, this is not a necessity.
Associated roles: administrator, owner, operator.
Access permissions: mostly implicitly public, but any other options
possible.
3.1.2. Mailer demons
This document does not consider X.400 delivery reports and
notifications, which are assumed to be well defined in X.400 already.
The MTA can be thought of as an MBS, whose administrator is the
administrator of the MTA.
RFC 822 mailers and RFC 1327 gateways however can generate a message
explaining the (NON-)Delivery of an input message, a so-called
Delivery Message (DM). In this case the mailer/gateway is acting as
an MBS.
Mailer demon behaviour of is well defined in other documents, such as
RFC 821 and RFC 1123. The MBS administrator is the administrator of
the mailer/gateway.
A gateway should ideally behave as a normal mailer demon or MTA when
a message is not deliverable. In practice however, the following may
occur. The gateway accepts from the Internet mail side a message in
which it recognises an RFC 822 encoded X.400 address. The gateway
performs the gatewaying and then discovers that the X.400 message is
not deliverable. The gateway has two options in this case. Either it
creates an X.400 non-delivery report and gateways it back to the
Internet mail world, or it immediately generates an RFC non-delivery
message (the inverse scenario is also possible).
RARE WG-MSG Expires October 1994 [Page 7]
INTERNET-DRAFT C-bombs April 1994
Implementation level: Internet mailer demons conceptually operate at
MTA or MTS level, although, as usual with Internet mailers, they may
interpret and under circumstances even _add_ UA level information.
This especially holds for mail protocol gateways.
Associated roles: administrator, owner, operator (normally
administrator = owner = operator = 'postmaster').
Access permissions: implicitly public.
3.1.3. Command servers
The contents of an output message generated by a command server
depend on commands that were included in the input message. Concrete
examples are file servers, e-mail archie servers, DL-registration
servers and address conversion servers.
Note that an echo server can in some ways be regarded as a special
type of command server, namely one that echoes the input message.
Implementation level: All known command servers operate at UA level,
but this is not a necessity.
Associated roles: administrator, owner, operator.
Access permissions: any.
3.1.4. Vacation servers
Some UAs have an auto-reply feature that will temporarily and/or
conditionally turn the UA into an MBS. Thus a vacation server is a
non-dedicated replier. The content of the output message is often a
note such as 'I am on holidays.' A vacation server has a certain
lifetime, which is defined as the time span between switching the
vacation server on and back off again.
Implementation level: Mostly at UA level.
Associated roles: administrator, owner, operator (normally
administrator = owner = mailbox-user. On stand-alone UAs often also
operator = mailbox-user).
Access permissions: Implicitly public. During the lifetime a user has
access to the vacation server only once, i.e. a no-access list is
automatically built from the originators of the input-messages.
RARE WG-MSG Expires October 1994 [Page 8]
INTERNET-DRAFT C-bombs April 1994
3.2. Forwarders
A forwarder is an MBS that will send its output messages to a list of
recipients. These recipients are independent of (the heading of) the
input message.
Implementation level: any.
Associated roles: administrator, owner, operator, moderator.
Access permissions: any.
3.2.1. Distribution Lists
Upon receiving an input message, a DL will generate output messages
to a list of DL members, which is managed by the DL administrator.
At the moment many vendor-specific implementations of DLs exist. Some
of these are nothing more than local multi-recipient aliases, others
use local directories for DL expansion. This document defines the
requirements for DLs as well as implementation options.
Implementation level: any.
Associated roles: administrator, owner, operator, moderator.
Access permissions: any.
3.2.2. Redirectors
Some MTAs have a redirection feature that will temporarily and/or
conditionally turn the MTA into an MBS. Thus a redirector can be
considered a non-dedicated forwarder. Upon receiving an input
message, an auto-forwarder will submit an output message to a locally
defined (list of) address(es).
Like a vacation server, a redirector often has a certain lifetime.
Implementation level: MTA.
Associated roles: administrator, owner, operator.
Access permissions: mostly implicitly public.
3.2.3. Auto-forwarders
Some UAs have an auto-forward feature that will temporarily and/or
conditionally turn the UA into an MBS. Thus an auto-forwarder can be
considered a non-dedicated forwarder. Upon receiving an input
RARE WG-MSG Expires October 1994 [Page 9]
INTERNET-DRAFT C-bombs April 1994
message, an auto-forwarder will submit an output message to a locally
defined (list of) address(es), which is managed by the owner of the
UA.
Although an auto-forwarder often has a certain lifetime, like a
vacation server, this has no implications for the requirements for
auto-forwarders.
The main difference with a redirector is that an auto-forwarder
conceptually operates at UA level. In almost all cases redirection is
to be preferred over auto-forwarding.
Implementation level: UA.
Associated roles: administrator, owner, operator (normally
administrator = owner = mailbox-user. On stand-alone UAs often also
operator = mailbox-user).
Access permissions: mostly implicitly public.
4. Implementations
A by no means complete list of implementations follows:
AUSSIE (echo server)
Concord (echo server, DLs)
EAN (DLs, auto-forwarding, auto-answer, echo)
Echoput (echo server)
LISTSERV (DLs, command server, file server)
mailbase (DLs, command server, file server)
majordomo (DLs, command server, file server)
PP (DLs, auto-answer, echo server)
Squirrel (command server)
5. Security considerations
Security issues are not discussed in this memo.
6. 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 10]
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] Westine, A. & Postel, J., "Problems with the
Maintenance of Large Mailing Lists", RFC 1211, March
1991.
[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] Houttuin, J., "H-bombs: Header Behaviour of Mail
Based Servers", work in progress, November 1993.
[9] Houttuin, J., "A-bombs: Answering Servers: Behaviour
of MBSs", work in progress, April 1994.
[10] Houttuin, J., "Classifications in e-mail routing",
Computer Networks for Research in Europe, CNETDP 25
(Suppl. 2), 0169-7552, S72-S81, Elsevier, December
1993.
[11] CCITT Recommendations X.400 - X.430. Data
Communication Networks: Message Handling Systems.
CCITT Red Book, Vol. VIII - Fasc. VIII.7, Malaga-
Torremolinos 1984
[12] CCITT Recommendations X.400 - X.420. Data
Communication Networks: Message Handling Systems.
CCITT Blue Book, Vol. VIII - Fasc. VIII.7, Melbourne
1988
RARE WG-MSG Expires October 1994 [Page 11]
INTERNET-DRAFT C-bombs April 1994
7. Abbreviations
ASCII American Standard Code for Information Exchange
CCITT Comite Consultatif International de Telegraphique et
Telephonique
COSINE Co-operation for OSI networking in Europe
DL Distribution List
DM Delivery Message
EAN X.400 software (not an abbreviation)
IPM Inter-Personal Message
IPN Inter-Personal Notification
ISO International Organisation for Standardisation
MHS Message Handling System
MBS Mail based server
MTA Message Transfer Agent
MTS Message Transfer System
NJE Network Job Entry
NRN Non-Receipt Notification
PP MHS software (not an abbreviation)
RARE Reseaux Associes pour la Recherche Europeenne
RFC Request for Comments
RN Receipt Notification
RTR RARE Technical Report
SMTP simple mail transfer protocol
UA User Agent
8. 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 12]
| PAFTECH AB 2003-2026 | 2026-04-24 16:48:30 |