INTERNET-DRAFT Jeroen Houttuin
Mail Applicability Design Team RARE Secretariat
rev. 4.0 Sept. 1993
Header Behaviour of Mail Based Servers
(H-bombs)
Abstract
This document defines recommendations to be implemented in mail based
servers in the Internet and GO-MHS e-mail communities. The
requirements only affect the basic behaviour of servers, i.e. it
mainly deals with how header fields are handled. Although there is
also a clear need for recommendations in the field of end user
requirements, such as command syntaxes for archive servers, automatic
distribution list subscription, etc., such issues are considered more
suitable to be dealt with in a separate document.
It is highly desirable that other e-mail networks connected to the
Internet also implement these recommendations.
Discussion group
This document 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 Mail Management Group. It is now being finalised by the IETF
solicited "Mail Applicability Statement" design team. 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
Status of this Memo
This document is an Internet Draft. Internet Drafts 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.
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.
Houttuin Expires March 1994 [Page 1]
INTERNET-DRAFT Header Behaviour Of Mail Based Servers Sept. 1993
Contents [approximate page numbers......]
1. Introduction 1
2. Approach 2
3. Protocols 3
4. How to use this document 4
5. Definitions 4
5.1. Mail Based Server 4
5.2. Dedicated and non-dedicated MBSs 5
5.3. MBS administrator 5
5.4. Input- and output messages 5
5.5. MBS Submit Permission 6
5.6. Message originator (necessary?) 6
6. Mail based server types 6
6.1. Repliers 6
6.1.1. Echo server 7
6.1.2. Mailer demon 7
6.1.3. Command server 7
6.1.4. Auto-replier 8
6.2. Forwarders 8
6.2.1. Distribution List 8
6.2.2. Redirector 8
6.2.2. Auto-forwarder 9
7. Rules 9
7.1. Attribute/header restrictions (AR) 9
7.2. Attribute/header values (AV) 12
7.3. Attribute/header conservation (AC) 14
7.4. Addresses (AD) 15
7.5. Body (B) 16
7.6. Exceptions (E) 17
7.7. Logging (L) 18
7.8. Implementation options (I) 18
8. Summary table 19
8. Reference implementations 21
9. Further work 21
10. Acknowledgements 21
11. Bibliography 22
12. Abbreviations 23
13. Author's Address 23
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:
Houttuin Expires March 1994 [Page 2]
INTERNET-DRAFT Header Behaviour Of Mail Based Servers Sept. 1993
- 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.
- 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.
A more complicated example of the need for strong requirements for
MBSs is the following: suppose a distributed tool will check the
connectivity of mailers by sending a message to an echo-server. The
connectivity tool could request the echo to be sent to a remote
component of the tool instead of to itself. If for some reason the
address of that other component cannot be routed to, an automatically
generated non-delivery message could be sent back to the echo server,
which results in an echo loop.
As far as appropriate, the recommendations defined in this document
will be aligned with comparable rules that either have already been
used for a long time (X.400(84) Status Reports; distribution lists in
the Internet; Internet host requirements), or are already defined in
other documents (X.400(88) DLs; Internet host requirements).
2. Approach
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:
- 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
Houttuin Expires March 1994 [Page 3]
INTERNET-DRAFT Header Behaviour Of Mail Based Servers Sept. 1993
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 a near RFC 822 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, this document
recommends the 'unilateral safety approach'. The idea is that any MBS
that implements the complete set of recommendations will be safe from
harm, regardless of what other 'dumb' MBSs it is interacting with.
This 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. As for the programming
overhead caused by this document, there is at least one example of an
echo server (Echoput) that implements all recommendations proposed in
this document; the size of the (perl) code fits on two pages.
In addition to the rules that should protect against loops and
explosions, there are also some recommendations reflecting common
sense. For instance, if a user sends a message flagged 'urgent' to a
mail based file server, he would not only expect his request message
to be handled with extra priority, but also the reply message.
3. Protocols
For many MBSs, it is not known beforehand in which protocol world
they are located. In order to come to a consistent MBS behaviour
regardless of this location, this document describes recommendations
for both RFC mail and X.400 MBSs. Note that a one hundred percent
transparency cannot be reached, because there exists no one-to-one
mapping between all RFC mail and X.400 service elements. Apart from
that, applying RFC 1327 mapping to a service element from X.400 may
clash with a host requirement for the RFC mail service element. In
this case, there will have to be functionally different
recommendations depending in which protocol world the MBS is located.
More concrete; depending on the implementation of the MBS, different
recommendations must be used. E.g. a P1 MBS cannot follow all
recommendations for RFC 822 based MBSs and vice versa.
Houttuin Expires March 1994 [Page 4]
INTERNET-DRAFT Header Behaviour Of Mail Based Servers Sept. 1993
4. How to use this document
For the reader's convenience, the rules for different MBS
implementations are explicitly stated in the appropriate
terminologies. The rules are labelled as follows:
#RFC# Applies to RFC 822 on top of RFC 821 (SMTP) based MBSs
#821# Applies to RFC 821 based MBSs
#822# Applies to RFC 822 based MBSs
#1327# Rules visible in RFC 822 message due to RFC 1327
mappings
#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 based MBSs
#P2# Applies to P2 based MBSs
#P3# Applies to P3 based MBSs
Terms such as 'P1 based' and 'RFC 822 on top of RFC 821' may need
some further explanation. P1 based MBSs operate as MTA functions
(e.g. they process envelope information only), whereas P2 and RFC 822
MBSs assume UA functionality (e.g. they process mail headers). P3
based MBSs use the MTS, and may additionally interpret the contents
of messages (if this message is P2, we're back at the definition of a
P2 MBS). The distinction between P1 and P3 based MBSs is mostly
conceptual. In the Internet, this distinction cannot even be made.
Note that some the RFC 822 recommendations listed here deal with non-
standard headers as described in RFC 1327. This is needed to provide
protection across gateways.
Implementors can use the summary table in chapter 8, and check all
'+' entries for the type of MBS and protocol suite they want to
implement.
5. Definitions
5.1. Mail Based Server
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). An MBS can be modelled and/or implemented in one of the
following ways:
- #RFC#: As a process sitting 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.
Houttuin Expires March 1994 [Page 5]
INTERNET-DRAFT Header Behaviour Of Mail Based Servers Sept. 1993
- #400#: within the MTS, in which case it can be considered an
enhancement of the X.400 message dispatcher. This is called a P1
MBS.
- #400#: 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. P7 based MBSs are not considered in this
document.
The number of output messages and its contents depend on the kind of
server and on the contents of the input message.
Our definition rules out a number of mail based applications:
- A proces 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
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.
5.2. 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
(auto-repliers). 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 (see below) for
every stand-alone UA. Also, non-dedicated MBSs often have a more
limited life time, which results in some extra recommendations.
5.3. MBS administrator
For every dedicated MBS, there exists an MBS administrator who is
responsible for managing the MBS. This person, or group of persons,
Houttuin Expires March 1994 [Page 6]
INTERNET-DRAFT Header Behaviour Of Mail Based Servers Sept. 1993
must be informed about possible malbehaviour of the server, such as
loops, unreachable addresses on mailing lists and rejected messages.
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 only role that is important in this document is
that of the MBS adminstrator.
5.4. 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.
If an MBS encounters an error (as defined in the recommendations
below), one exception output message is generated instead of a
regular output message. This message is sent to the MBS
administrator.
If a non-dedicated MBS does not have an MBS administrator, the
exception output message may either be sent to the originator (see
below) of the input message. If by sending the exception message to
the originator of the input message, the MBS would encounter a
situation that would normally lead to an exception situation (e.g.
the originator of the input message is known to be an automatic
replier), it does not generate an output message at all.
5.5. MBS Submit Permission
Associated with an MBS is a number of addresses that are allowed to
use the MBS (I.e. have the MBS send output messages). Implementation
of MBS Submit 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.
Houttuin Expires March 1994 [Page 7]
INTERNET-DRAFT Header Behaviour Of Mail Based Servers Sept. 1993
5.6. Message originator (necessary?)
#RFC# The originator of an input message is defined as the MAIL FROM:
address. This is the definition of 'originator' and MUST be used
whenever possible. For RFC 822 based MBSs that, for some reason,
cannot access envelope attributes, the originator of an input message
is defined as the RFC 822 Return-Path: . If this header is not
available either, the originator of an input message is defined as
the RFC 822 Sender: , and in the absence of that header, the RFC 822
From: .
#400# The originator of an input message is defined as the P1 or P3
originator. For P2 based MBSs that cannot access P3 attributes, the
originator of an input message is defined as the P2.originator, or if
this attribute is not present, the P2.authorizingUsers.
6. Mail based server types
This chapter defines the different types of MBSs. Two main types are
identified: repliers and forwarders.
6.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
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.
Most existing repliers operate at UA level.
6.1.1. Echo server
An echo server is a dedicated replier that will generate exactly one
output message, containing at least the input message.
6.1.2. Mailer demon
This document does not consider the behaviour of X.400 delivery
reports and notifications, which is assumed to be well defined in
X.400 already. 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.
Houttuin Expires March 1994 [Page 8]
INTERNET-DRAFT Header Behaviour Of Mail Based Servers Sept. 1993
For mailer demons, the behaviour is well defined in other documents,
such as RFC 821 and RFC 1123. The MBS administrator is the
administrator of the mailer/gateway.
Ideally a gateway should behave as a normal mailer 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.
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.
6.1.3. Command server
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.
Although it is beyond the scope of this document to define detailed
requirements for the command syntax used by command servers, some
general recommendations concerning header fields are described here.
Note that an echo server can be regarded as a special type of command
server, namely one that ignores all commands.
6.1.4. Auto-replier
Some UAs have an auto-reply feature that will temporarily and/or
conditionally turn the UA into an MBS. Thus an auto-replier is a non-
dedicated replier. The content of the output message is often a note
such as 'I am on holidays.' An auto-replier has a certain lifetime,
which is defined as the time span between switching the auto-replier
on and back off again.
6.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.
Houttuin Expires March 1994 [Page 9]
INTERNET-DRAFT Header Behaviour Of Mail Based Servers Sept. 1993
6.2.1. Distribution List
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.
Although a moderateddistribution list does not fit into our
definition of an MBS, a moderated DL ican be modelled as a normal DL
with an extra filtering of the input messages. In case of message
rejection by the moderator, it is considered good manners for the
moderator to follow, in a rejection message, the header
recommendations that this document describes for mailer demons. If
the message is accepted for distribution, the moderator should
ideally transparently pass through all MBS control information
(headers and envelope) to the actual DL. The moderation process
itself (editing of the contents) is considered a local matter.
6.2.2. Redirector
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), which is managed.....
Although a redirector often has a certain lifetime, like an auto-
replier, this has no implications for the requirements for auto-
forwarders.
6.2.2. Auto-forwarder
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
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 an auto-
replier, 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.
Houttuin Expires March 1994 [Page 10]
INTERNET-DRAFT Header Behaviour Of Mail Based Servers Sept. 1993
7. Rules
Depending on the implementation, MBSs follow the requirements defined
in RFC 822, RFC 821, RFC 1123, X.411, X.420 and X.435 as a minimum.
This chapter describes additional requirements in terms of RFC 821,
RFC 822, P1, P3, and P2 for the MBS types distinguished above.
7.1. Attribute/header restrictions (AR)
AR1 Avoiding replies to 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 must
be avoided at all cost, or to the MBS administrator, which is highly
undesirable. This leads to rules AR1.1-AR1.5.
ORIGIN: This memo
AFFECTED: Repliers
AR1.1
RULE: The following attribute is not used in the output message:
#P2# Recipient.replyRequest
I.e. the value of this argument defaults to FALSE
AR1.2
RULE: The following attribute is not used in the output message:
#1327# Reply-By:
#84#P2# replyBy
#88#P2# reply-time
AR1.3
RULE: The following attribute is not used in the output message:
#84#P2# expiryDate
#88#P2# Expiry Time
#1327# Expiry-Date:
Houttuin Expires March 1994 [Page 11]
INTERNET-DRAFT Header Behaviour Of Mail Based Servers Sept. 1993
AR1.4
RULE: The following attribute is not used in the output message:
#88#P1#P3# Proof-of-delivery-request
I.e. the value of this argument defaults to proof-of-delivery-not-
requested.
AR1.5
RULE: The following attribute is not used in the output message:
#84#P2# replyToUsers
#88#P2# reply-recipients
#822# Reply-To:
AR2
DISCUSSION: There is no need for a user to automatically forward his
incoming messages through another MBS, which would introduce one
superfluous hop. The only case where this might make sense is if the
mail would be autoforwarded to support old addresses. But even in
this case, auto redirection is preferred. 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.
ORIGIN: This memo.
AFFECTED: All MBSs except distribution lists.
RULE: #P2# An auto-forwarded message is not valid as an input
message. The result is the generation of an exception output message.
AR3
DISCUSSION: A user of a UA level replier may request the output
message to be sent to another address.
AFFECTED: UA level repliers, mailer demons.
ORIGIN: Common practice, RFC 821, RFC 822, RFC 1123, X.400.
RULE: The output message is sent to the originator of the input
message. If the input message contains the following field, a UA-
level replier sends the output message to the address in that field
instead. If this field contains more than one address, an output
Houttuin Expires March 1994 [Page 12]
INTERNET-DRAFT Header Behaviour Of Mail Based Servers Sept. 1993
message is sent to at least the first address of this field. (Sending
to the others is not recommended.)
#84#P2# replyToUsers
#88#P2# reply-recipients
#822# Reply-To:
AR4
DISCUSSION: A user who receives mail from an MBS, wihtout 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.
ORIGIN: This document, RFC 822, RFC 1327, X.400.
AFFECTED: command and echo servers.
RULE: #822# If the output message is not sent to the originator of
the input message, its From: field 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.
RULE: #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.
AR5
RULE: An exception output message is generated if the input message
contains either of the following attributes:
#822# In-Reply-To:
References:
#P2# In-Reply-To
crossReferences
Houttuin Expires March 1994 [Page 13]
INTERNET-DRAFT Header Behaviour Of Mail Based Servers Sept. 1993
7.2. Attribute/header values (AV)
AV1
RULE: If the following field is used in the output message, it does
not contain the address of the MBS.
#84#P2# replyToUsers
#88#P2# reply-recipients
#822# Reply-To:
AV2.1
DISCUSSION: Repliers should not send output messages to addresses
which are likely to be repliers themselves, to avoid loops.
RULE: Repliers do not send output messages to addresses with the
following values in the local address designator (S, CN, localpart):
autoanswer
echo
listserv
mailerdaemon
mirror
netserv
server
These values must be matched in any combination of upper case and
lower case. Instead, an exception output message is generated. This
list is subject to change; an up-to-date version of this list is
available in [Noreply]
**** NOTE: I agree with John that this is a yuckt sort of rule.
however, it seems to be common practice. Should we discourage it?
Don't know, many loops have been avoided this way..... Should we just
document it as a not recommended possibility? ****
AV2.2
DISCUSSION: In the Internet, non-delievry messages are recognised by
the fact that teh MAIL FROM: has an empty address.
RULE: #RFC# Repliers generate an exception output message if the
input message has an empty MAIL FROM: address.
AV3
RULE: The following attribute of the output message has the value:
#84#P2# inReplyTo : IPMessageID of input message
#88#P2# replied-to-IPM : this-IPM of input message
#822# In-Reply-To: : Message-ID of input message
Houttuin Expires March 1994 [Page 14]
INTERNET-DRAFT Header Behaviour Of Mail Based Servers Sept. 1993
AV4
RULE: The following attributes are optional in an output message. If
used, they contain the value:
#84#P2# crossReferences : IPMessageID of input message
#88#P2# related-IPMs : this-IPM of input message
#822# References: : Message-ID of input message
AV5
RULE: #P2# The P1.originator of the output message contains the
address of the MBS administrator.
DISCUSSION: Note that this 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 may
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: #821# The MAIL FROM: line of the output message contains the
address of the MBS administrator.
AV6
RULE: #P2# The P2.originator of the output message contains the
address of the MBS administrator.
RULE: #822# The From: field of the output message contains the
address of the MBS administrator.
AV7
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.
AV8
RULE: The following argument is empty in the output message:
#84#P2# Recipient.reportRequest
#88#P2# NotificationRequests
Houttuin Expires March 1994 [Page 15]
INTERNET-DRAFT Header Behaviour Of Mail Based Servers Sept. 1993
AV9
RULE: The following attribute of the output message has as value the
string 'Re: ', concatenated with the subject of the input message.
#822# Subject:
#P2# subject
AV10
RULE: The following attribute of the output message has as value the
subject of the input message, concatenated with the string '(for)'.
#822# Subject:
#P2# subject
AV11
RULE: #P1#P3# The P1.recipient of a (non-)DM equals the P1.originator
of the input message.
RULE: #821# The RCPT TO: field of a (non-)DM equals the MAIL FROM: of
the input message.
AV12
RULE: #P2# The P2.recipient of a (non-)DM equals the P1.originator of
the input message.
RULE: #822# The To: field of a (non-)DM equals the originator of the
input message.
AV13
RULE: #P1# All P1.ExtensionIdentifiers in an output message are
distinct.
AV14
RULE: #P2# The output message(s) have the P2.autoForwarded flag set
to true.
7.3. Attribute/header conservation (AC)
DISCUSSION: Thre are a number of attributes, set by the originator of
the input message, that should also be set in the output message. For
instance, a user will expect a high priority request to be handled
with high priority. The output message should in this case also be
sent with the same priority. Note that an MBS may, as a local
decission, choose to spool all requests in order to spread the MBS
load. As long as the local processing of high priority request can be
Houttuin Expires March 1994 [Page 16]
INTERNET-DRAFT Header Behaviour Of Mail Based Servers Sept. 1993
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.
RULE: The following attributes have the same value in the output
message as in the input message
AC1
In order to propagate the originator's request for privacy to the
output message(s):
#822# Sensitivity:
#P2# P2.sensitivity
AC2
#822# Importance:
#P2# Importance
AC3
#822# Priority:
#P1#P3# Priority
AC4
#84#P1#P3# ContentType
AC5
#P1#P3# contents
7.4. Addresses (AD)
Please note that all recommendations for names of MBSs and MBS
administrators concern internationally used MBSs. Local MBSs can use
similar mechanisms in their local language.
AD1
RULE: The address of the MBS administrator is the same as that of the
MBS, except for the
#RFC# localpart
#400# Personal Name
Houttuin Expires March 1994 [Page 17]
INTERNET-DRAFT Header Behaviour Of Mail Based Servers Sept. 1993
AD2
RULE: The MBS administrator of a mailer demon has an address with the
following local address designation:
#RFC# localpart=postmaster
AD3
RULE: The following attribute of the echo server address has the
value "echo".
#RFC# localpart
#400# Surname
AD4
RULE: The following attribute in the address of the administrator of
a dedicated replier is that of the replier, concatenated with
"-reply".
#RFC# localpart
#400# Surname
AD5
RULE: A message addressed to an address with the following local
address designation results in an NRN or a non-DM being generated.
#RFC# localpart = nosuchuser
#84# Surname=nosuchuser
#88# Surname=nosuchuser
#88# CN=nosuchuser
AD6
RULE: The following attribute in the address of the administrator of
a dedicated replier is that of the replier, concatenated with
"-request".
#RFC# localpart
#400# Surname
7.5. Body (B)
B1
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.
Houttuin Expires March 1994 [Page 18]
INTERNET-DRAFT Header Behaviour Of Mail Based Servers Sept. 1993
B2
RULE: Additional information is included in separate bodyparts of the
output message.
B3
RULE: Commands are only specified in the body of the input message.
Especially, a command server ignores the Subject field of the input
message.
B4
RULE: The recipient of the output message can be uniquely identified
from the heading of the input message. That is, alternate recipients
are not negotiated in the body of the input message. This ensures
that the recipients can still be uniquely identified after the input
message has traversed a protocol gateway.
B5
RULE: The output message body consists only of the complete input
message, encoded as a MIME message bodypart or an
IPMS.ForwardedIPMessage bodypart.
7.6. Exceptions (E)
E1
RULE: In case of an MBS Submit Permission violation
#822#P2# a non delivery message is sent to the originator of the
input message. The non delivery message has the following text in the
message body:
"Originator not allowed to send to this address"
#84#P1# a P1.DeliveryReportMPDU will be sent to the P1.originator of
the input message. The P1.DeliveryReportMPDU will have the following
values:
ReasonCode: unableToTransfer(1)
DiagnosticCode:uaUnavailable(4)
SupplementaryInformation:
"Originator not allowed to send to this address"
E2
RULE: Only the types of input messages listed below are valid as
input messages. Any other type of input message (reports, receipt
Houttuin Expires March 1994 [Page 19]
INTERNET-DRAFT Header Behaviour Of Mail Based Servers Sept. 1993
notifications) leads to the generation of an exception output
message.
#84#P1# UserMPDU
#84#P2# IM-UAPDU
#88#P1# Message
#88#P2# IPM
#822# No restrictions
#400# P1.Probes are expected to be handled by the MTS and are thus
not interpreted by the MBS.
7.7. Logging (L)
L1
RULE: The MBS logs the originator of the input message and all
recipient(s) of the output/exception message(s).
DISCUSSION: This allows the MBS administrator to track down malicious
behaviour.
L2
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.
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.
ORIGIN: This document. Similar techniques are already being used in
Netnews.
AFFECTED: All MBSs.
Any further logging is optional.
7.8. Implementation options (I)
I1
RULE: MBS Submit Permission implementation is 'implicit'. This means
that MBSs that have not explicitly implemented this function can
still claim to be implicitly open to anyone.
Houttuin Expires March 1994 [Page 20]
INTERNET-DRAFT Header Behaviour Of Mail Based Servers Sept. 1993
I2
RULE: Auto-repliers at least log the originator of the input message.
During the lifetime of an auto-replier, at most one output message
per input message originator is generated.
I3
RULE: #P2# Even if a DL is used for distribution of P2 messages, we
still recommend to implement it at MTS level. This has some important
advantages over P3/P2 based implementations (see also [SHK 92]):
- Using P3 would result in loosing P1.TraceInformation
- Better alignment with X.400(88), which also defines DLs within
the MTS
- An MTS DL distributes P1.UMPDUContent transparently, and will
thus implicitly implement one of the requirements for DLs.
8. Summary table
auto- comm. mail. echo auto- dist. affected
answ. serv. demon serv. forw. list
AR1.1 + + + + . . P2
AR1.2 + + + + . . 822 P2
AR1.3 + + + + . . 822 P2
AR1.4 + + + + . . 88.P1 88.P3
AR1.5 + d + d d . 822 P2
AR2 + + + + + . all
AR3 o + - + n/a n/a 822 P2
AR4 o + - + n/a n/a 822 P2
AR5 o + . + n/a n/a 822 P2
AV1 o + - + . . 822 P2
AV2 s + + + . . all
AV3 + + + + n/a n/a 822 P2
AV4 + + + + n/a n/a 822 P2
AV5 o + + + . . 821 P1 P3
AV6 o + + + . . 822 P2
AV7 + + + + . . P1 P3
AV8 + + + + . . P2
AV9 s s o + - - 822 P2
AV10 - - - - s - 822 P2
AV11 . . + . n/a n/a 821 P1 P3
AV12 . . + . n/a n/a 822 P2
AV13 + + + + + + P1
AV14 - - - - + - 822 P2
AC1 + + + + + + 822 P2
AC2 + + + + + + 822 P2
AC3 + + + + + + 822 P1 P3
AC4 . . . s + + P1 P3
Houttuin Expires March 1994 [Page 21]
INTERNET-DRAFT Header Behaviour Of Mail Based Servers Sept. 1993
AC5 - - - - - + P1 P3
AD1 + + + + + + all
AD2 o - + - o - all
AD3 n/a n/a n/a + n/a n/a all
AD4 n/a s n/a s n/a n/a all
AD5 n/a n/a + n/a n/a n/a all
AD6 n/a n/a n/a n/a n/a s all
B1 - o s + - - 822 P2
B2 o o o o - o 822 P2
B3 n/a + n/a n/a n/a n/a 822 P2
B4 n/a + n/a n/a n/a n/a 822 P2
B5 - - - - + - 822 P2
E1 + + + + + + 822 P2
E2 + + + + + + all
L1 o + + + o o all
L2 + + + + + + all
I1 n/a s n/a s n/a s all
I2 s n/a n/a n/a n/a n/a all
I3 n/a n/a n/a n/a n/a s n/a
Table 1. Table of recommendations
Key to symbols in table 1:
+ Recommended
s Suggested
o Optional
d Don't care
n/a Not applicable
. Depends on other factors
- Not recommended
8. Reference implementations
There are a number of MBS implementations that follow most of the
recommendations listed in this document. They include:
Echoput (echo server)
Concord (echo server, DLs)
AUSSIE (echo server)
Squirrel (command server)
EAN (DLs, auto-forwarding, auto-answer, echo)
PP (DLs, auto-answer, echo)
Developers of other MBS software (mailbase, explode) have indicated
they will also implement the requirements in future versions.
Houttuin Expires March 1994 [Page 22]
INTERNET-DRAFT Header Behaviour Of Mail Based Servers Sept. 1993
9. Further work
An idea would be to write a modular MBS system, which can be
cofigured as an echo server, distribution list, etc. A protocol
conversion module can be used to allow the MBS to plug in to
different implemenations and protocols.
10. Acknowledgements
Within the context of the connectivity testing tool 'concord',
initial work on the requirements for echo servers and distribution
lists was done within COSINE MHS and XNREN ([Concord], [Concreqs]).
The document was then integrated in the work of the IETF Mail
Applicability Design Team, consisting of: Ned Freed (INNOsoft),
Jeroen Houttuin (RARE), John Klensin (INfoods, UN), Keith Moore
(University of Tennessee).
Thanks for ideas, comments, flames and corrections: Harald Alvestrand
(SINTEF), Allan Cargille (XNREN), Urs Eppenberger (SWITCH), Paul
Klarenberg (NetConsult AG), Ignacio Martinez (redIRIS), Juan Pizzorno
(DFN), Eric Thomas (SUNET), Johan Vromans (Multihouse), Jan van der
Weele (Du Pont).
11. Bibliography
821 Jonathan B. Postel, "Simple Mail Transfer Protocol",
RFC 821, University of Southern California, Sept.
1982
822 Crocker, D., "Standard of the Format of ARPA Internet
Text Messages", RFC 822, UDEL, Sept. 1982.
1123 R. Braden, Editor, "Requirements for Internet Hosts -
- Application and Support", RFC 1123, USC/Information
Sciences Institute, October 1989.
1211 Westine, A. & Postel, J., "Problems with the
Maintenance of Large Mailing Lists", RFC 1211, March
1991.
1327 Kille, S., "Mapping between X.400(1988) / ISO 10021
and RFC 822", RFC 1327, UCL, May 1992.
1328 Kille, S., "X.400 1988 to 1984 downgrading", RFC
1328, UCL, May 1992
Houttuin Expires March 1994 [Page 23]
INTERNET-DRAFT Header Behaviour Of Mail Based Servers Sept. 1993
1341 N. Borenstein, N. Freed, MIME (Multipurpose Internet
Mail Extensions), RFC 1341, June 1992
Concord 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
Concreqs 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
Noreply "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
X.4xx(84) CCITT Recommendations X.400 - X.430. Data
Communication Networks: Message Handling Systems.
CCITT Red Book, Vol. VIII - Fasc. VIII.7, Malaga-
Torremolinos 1984
X.4xx(88) CCITT Recommendations X.400 - X.420. Data
Communication Networks: Message Handling Systems.
CCITT Blue Book, Vol. VIII - Fasc. VIII.7, Melbourne
1988
SK92 Kille, S., "MHS use of the Directory to support
distribution lists", Internet-Draft draft-ietf-mhsds-
mhsuse-02.txt, November 1992
12. 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 MHS 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
MOTIS Message-Oriented Text Interchange Systems
MTA Message Transfer Agent
MTL Message Transfer Layer
MTS Message Transfer System
Houttuin Expires March 1994 [Page 24]
INTERNET-DRAFT Header Behaviour Of Mail Based Servers Sept. 1993
NJE Network Job Entry
NRN Non-Receipt Notification
PP MHS software (not an abbreviation)
RARE Reseaux Associes pour la Recherche Europeenne
RN Receipt Notification
SMTP simple mail transfer protocol
UA User Agent
13. Author's Address
Jeroen Houttuin
RARE Secretariat
Singel 466-468
NL-1017 AW Amsterdam
Europe
Tel +31 20 6391131
Fax +31 20 6393289
houttuin@rare.nl
/S=houttuin/O=rare/PRMD=surf/ADMD=400net/C=nl/
Houttuin Expires March 1994 [Page 25]