rfc1506.txt
来自「RFC 的详细文档！」· 文本 代码 · 共 1,552 行 · 第 1/5 页
TXT
1,552 行
Fig. 1.1. X.400 functional model
The Message Transfer system (MTS) transfers messages from an
originating UA to a recipient UA. As implied by the Figure 1.1, data
sent from UA to UA may be stored temporarily in several intermediate
Message Transfer Agents (MTA), i.e., a store-and- forward mechanism
is being used. An MTA forwards received messages to a next MTA or to
the recipient UA.
X.400(84) divides layer 7 of the OSI Reference Model into 2
sublayers, the User Agent Layer (UAL) and the Message Transfer Layer
(MTL) as shown in the Figure 1.2.
The MTL is involved in the transport of messages from UA to UA, using
one or several MTAs as intermediaries. By consequence, routing issues
are entirely dealt with in the MTL. The MTL in fact corresponds to
the postal service that forwards letters consisting of an envelope
and a content. Two protocols, P1 and P3, are used between the MTL
entities (MTA Entity (MTAE), and Submission and Delivery Entity
(SDE)) to reliably transport messages. The UAL embodies peer UA
Entities (UAE), which interpret the content of a message and offer
specific services to the application process. Depending on the
application to be supported on top of the MTL, one of several end-
RARE Working Group on Mail and Messaging (WG-MSG) [Page 6]
RFC 1506 X.400-Internet Mail Gatewaying Tutorial August 1993
to-end protocols (Pc) is used between UAEs. For electronic mail,
X.400(84) defines the protocol P2 as part of the InterPersonal
Messaging Service (IPMS). Conceivably other UAL protocols may be
defined, e.g., a protocol to support the exchange of electronic
business documents.
--------------------------------------------------------------
----- -----
UA layer |UAE|<----- P2, Pc ----------->|UAE|
----- -----
--------------------------------------------------------------
------ ------ -----
MTA layer |MTAE|<-- P1 -->|MTAE|<-- P3-->|SDE|
------ ------ -----
--------------------------------------------------------------
xxxE = xxx Entity ; SDE = Submission & Delivery Entity
--------------------------------------------------------------
Fig. 1.2. X.400 Protocols
The structure of an InterPersonal Message (IPM) can be visualised as
in Figure 1.3. (Note that the envelope is not a part of the IPM; it
is generated by the MTL).
Forwarded
Message IP-message
- ---------- --- ---------- -
| message- |envelope| / | PDI | |
| content IPM ---------- / ---------- |
| - - ---------- / ---------- |
| | | IPM- |heading | / |heading | |
| | | body ---------- / ---------- |
| | | - ----------/ ---------- |
| | | | |bodypart| |bodypart| |
| | | | ----------\ ---------- |
| | | | ---------- \ ---------- |
| | | | |bodypart| \ |bodypart| |
| | | | ---------- \ ---------- |
| | | | . \ |
| | | | . \ |
| | | | ---------- \ ---------- |
| | | | |bodypart| \ |bodypart| |
- - - - ---------- - ---------- -
(PDI = Previous Delivery Info.)
Fig. 1.3. X.400 message structure
An IPM heading contains information that is specific for an
interpersonal message like 'originator', 'subject', etc. Each
bodypart can contain one information type, text, voice or as a
RARE Working Group on Mail and Messaging (WG-MSG) [Page 7]
RFC 1506 X.400-Internet Mail Gatewaying Tutorial August 1993
special case, a forwarded message. A forwarded message consists of
the original message together with Previous Delivery Information
(PDI), which is drawn from the original delivery envelope.
Early experience with X.400(84) showed that the standard had various
shortcomings. Therefore CCITT, in parallel with ISO, corrected and
extended the specification during its 1984 to 1988 study period and
produced a revised standard [17], which was accepted at the 1988
CCITT Plenary Meeting [10]. Amongst others, X.400(88) differs from
X.400(84) in that it defines a Message Store (MS), which can be seen
as a kind of database for messages. An MS enables the end-user to run
a UA locally, e.g., on a PC, whilst the messages are stored in the
MS, which is co-located with the MTA. The MTA can thus always deliver
incoming messages to the MS instead of to the UA. The MS can even
automatically file incoming messages according to certain criteria.
Other enhancements in the 88 version concern security and
distribution lists.
1.2. What is an RFC ?
The Internet, a loosely-organised international collaboration of
autonomous, interconnected networks, supports host-to-host
communication through voluntary adherence to open protocols and
procedures defined by Internet Standards. There are also many
isolated internets, i.e., sets of interconnected networks, that are
not connected to the Internet but use the Internet Standards. The
architecture and technical specifications of the Internet are the
result of numerous research and development activities conducted over
a period of two decades, performed by the network R&D community, by
service and equipment vendors, and by government agencies around the
world.
In general, an Internet Standard is a specification that is stable
and well-understood, is technically competent, has multiple,
independent, and interoperable implementations with operational
experience, enjoys significant public support, and is recognisably
useful in some or all parts of the Internet.
The principal set of Internet Standards is commonly known as the
"TCP/IP protocol suite". As the Internet evolves, new protocols and
services, in particular those for Open Systems Interconnection (OSI),
have been and will be deployed in traditional TCP/IP environments,
leading to an Internet that supports multiple protocol suites.
The following organisations are involved in setting Internet
standards.
Internet standardisation is an organised activity of the Internet
RARE Working Group on Mail and Messaging (WG-MSG) [Page 8]
RFC 1506 X.400-Internet Mail Gatewaying Tutorial August 1993
Society (ISOC). The ISOC is a professional society that is concerned
with the growth and evolution of the world-wide Internet, with the
way in which the Internet is and can be used, and with the social,
political, and technical issues that arise as a result.
The Internet Engineering Task Force (IETF) is the primary body
developing new Internet Standard specifications. The IETF is composed
of many Working Groups, which are organised into areas, each of which
is co-ordinated by one or more Area Directors.
The Internet Engineering Steering Group (IESG) is responsible for
technical management of IETF activities and the approval of Internet
standards specifications, using well-defined rules. The IESG is
composed of the IETF Area Directors, some at-large members, and the
chairperson of the IESG/IETF.
The Internet Architecture Board (IAB) has been chartered by the
Internet Society Board of Trustees to provide quality control and
process appeals for the standards process, as well as external
technical liaison, organizational oversight, and long-term
architectural planning and research.
Any individual or group (e.g., an IETF or RARE working group) can
submit a document as a so-called Internet Draft. After the document
is proven stable, the IESG may turn the Internet-Draft into a
"Requests For Comments" (RFC). RFCs cover a wide range of topics,
from early discussion of new research concepts to status memos about
the Internet. All Internet Standards (STDs) are published as RFCs,
but not all RFCs specify standards. Another sub-series of the RFCs
are the RARE Technical Reports (RTRs).
As an example, this tutorial also started out as an Internet-Draft.
After almost one year of discussions and revisions it was approved by
the IESG as an Informational RFC.
Once a document is assigned an RFC number and published, that RFC is
never revised or re-issued with the same number. Instead, a revision
will lead to the document being re-issued with a higher number
indicating that an older one is obsoleted.
1.3. What is RFC 822 ?
STD 11, RFC 822 defines a standard for the format of Internet text
messages. Messages consist of lines of text. No special provisions
are made for encoding drawings, facsimile, speech, or structured
text. No significant consideration has been given to questions of
data compression or to transmission and storage efficiency, and the
standard tends to be free with the number of bits consumed. For
RARE Working Group on Mail and Messaging (WG-MSG) [Page 9]
RFC 1506 X.400-Internet Mail Gatewaying Tutorial August 1993
example, field names are specified as free text, rather than special
terse codes.
A general "memo" framework is used. That is, a message consists of
some information in a rigid format (the 'headers'), followed by the
main part of the message (the 'body'), with a format that is not
specified in STD 11, RFC 822. It does define the syntax of several
fields of the headers section; some of these fields must be included
in all messages.
STD 11, RFC 822 is used in conjunction with a number of different
message transfer protocol environments (822-MTSs).
- SMTP Networks: On the Internet and other TCP/IP networks,
STD 11, RFC 822 is used in conjunction with two other
standards: STD 10, RFC 821, also known as Simple Mail
Transfer Protocol (SMTP) [1], and RFCs 1034 and 1035
which specify the Domain Name System [3].
- UUCP Networks: UUCP is the UNIX to UNIX CoPy protocol, which
is usually used over dialup telephone networks to provide a
simple message transfer mechanism.
- BITNET: Some parts of Bitnet and related networks use STD
11, RFC 822 related protocols, with EBCDIC encoding.
- JNT Mail Networks: A number of X.25 networks, particularly
those associated with the UK Academic Community, use the JNT
(Joint Network Team) Mail Protocol, also known as Greybook.
STD 11, RFC 822 is based on the assumption that there is an
underlying service, which in RFC 1327 is called the 822-MTS service.
The 822-MTS service provides three basic functions:
1. Identification of a list of recipients.
2. Identification of an error return address.
3. Transfer of an RFC 822 message.
It is possible to achieve 2) within the RFC 822 header. Some 822-
MTS protocols, in particular SMTP, can provide additional
functionality, but as these are neither mandatory in SMTP, nor
available in other 822-MTS protocols, they are not considered here.
Details of aspects specific to two 822-MTS protocols are given in
Appendices B and C of RFC 1327. An RFC 822 message consists of a
header, and content which is uninterpreted ASCII text. The header is
divided into fields, which are the protocol elements. Most of these
fields are analogous to P2 heading fields, although some are
analogous to MTS Service Elements.
RARE Working Group on Mail and Messaging (WG-MSG) [Page 10]
RFC 1506 X.400-Internet Mail Gatewaying Tutorial August 1993
1.4. What is RFC 1327 ?
There is a large community using STD 11, RFC 822 based protocols for
mail services, who will wish to communicate with users of the
InterPersonal Messaging Service (IPMS) provided by X.400 systems, and
the other way around. This will also be a requirement in cases where
RFC 822 communities intend to make a transition to use X.400 (or the
other way around, which also happens), as conversion will be needed
to ensure a smooth service transition.
The basic function of a mail gateway can be described as follows:
receive a mail from one mail world, translate it into the formats of
the other mail world and send it out again using the routing rules
and protocols of that other world.
Especially if a message crosses more than one gateway, it is
important that all gateways have the same understanding of how things
should be mapped. A simple example of what could go wrong otherwise
is the following: A sends a message to B through a gateway and B's
reply to A is being routed through another gateway.
If the two gateways don't use the same mappings, it can be expected
that the From and To addresses in the original mail and in the answer
don't match, which is, to say the least, very confusing for the end-
users (consider what happens if automated processes communicate via
mail). More serious things can happen to addresses if a message
crosses more than one gateway on its way from the originator to the
recipient. As a real-life example, consider receiving a message from:
Mary Plork <MMP_+a_ARG_+lMary_Plork+r%MHS+d_A0CD8A2B01F54FDC-
A0CB9A2B03F53FDC%ARG_Incorporated@argmail.com>
This is not what you would call user-friendly addressing.... RFC 1327
describes a set of mappings that will enable a more transparent
interworking between systems operating X.400 (both 84 and 88) and
systems using RFC 822, or protocols derived from STD 11, RFC 822.
RFC 1327 describes all mappings in term of X.400(88). It defines how
these mappings should be applied to X.400(84) systems in its Appendix
G.
Some words about the history of RFC 1327: It started out in June
1986, when RFC 987 defined for X.400(84) what RFC 1327 defines for
X.400(84 and 88). RFC 1026 specified a number of additions and
corrections to RFC 987. In December 1989, RFC 1138, which had a very
short lifetime, was the first one to deal with X.400(88). It was
obsoleted by RFC 1148 in March 1990. Finally, in May 1992, RFC 1327
obsoleted all of its ancestors.
RARE Working Group on Mail and Messaging (WG-MSG) [Page 11]
RFC 1506 X.400-Internet Mail Gatewaying Tutorial August 1993
⌨️ 快捷键说明
复制代码Ctrl + C
搜索代码Ctrl + F
全屏模式F11
增大字号Ctrl + =
减小字号Ctrl + -
显示快捷键?