the SAs can be discarded, and the value of this DDA is the desired
RFC822 address (NB. Some characters in the DDA value must be decoded
first. See chapter 3.3.1.2.). For example, the gateway
DD.RFC-822=bush(a)dole.us; C=nl; ADMD=tlec; PRMD=GW
->
bush@dole.us
3.3.1.2. RFC822 -> X.400
There are also two kinds of default address mapping from RFC822 to
X.400: one to map a real RFC822 address to X.400, and another to
decode an X.400 address that was mapped to RFC822 (i.e., to reverse
the default X.400 -> RFC822 mapping).
To map a real RFC822 address to X.400, the RFC822 address is
encoded in a DDA of type RFC-822 , and the SAs of the local gateway
performing the mapping are added to form the complete X.400 address.
This mapping is generally referred to as 'DDA mapping'. As an
example, the gateway 'C=nl; ADMD=tlec; PRMD=GW' would perform the
following mapping:
bush@dole.us ->
DD.RFC-822=bush(a)dole.us; C=nl; ADMD=tlec; PRMD=GW
As for the encoding/decoding of RFC822 addresses in DDAs, it is
noted that RFC822 addresses may contain characters (@ ! % etc.) that
cannot directly be represented in a DDA. DDAs are of the restricted
character set type 'PrintableString', which is a subset of IA5
(=ASCII). Characters not in this set need a special encoding. Some
examples (For details, refer to RFC1327, chapter 3.4.):
100%name@address -> DD.RFC-822;=100(p)name(a)address
u_ser!name@address -> DD.RFC-822;=u(u)ser(b)name(a)address
To decode an X.400 address that was mapped to RFC822: if the RFC822
address has a slash separated representation of a complete X.400
mnemonic O/R address in its localpart, that address is the result of
the mapping. As an example, the gateway 'gw.switch.ch' would perform
the following mapping:
/C=zz/ADMD=ade/PRMD=fhbo/O=tlec/S=plork/G=mary/@gw.switch.ch
->
C=zz; ADMD=ade; PRMD=fhbo; O=tlec; S=plork; G=mary
3.3.2. Exception mapping according to mapping tables
Chapter 3.3.1. showed that it is theoretically possible to use RFC
1327 with default mapping only. Although this provides a very simple,
straightforward way to map addresses, there are some very good
reasons not to use RFC1327 this way:
- RFC822 users are used to writing simple addresses of the
form 'localpart@domainpart'. They often consider X.400
addresses, and thus also the left-hand-side encoded
equivalents, as unnecessarily long and complicated. They
would rather be able to address an X.400 user as if she had a
'normal' RFC822 address. For example, take the mapping
C=zz; ADMD=ade; PRMD=fhbo; O=tlec; S=plork; ->
/C=zz/ADMD=ade/PRMD=fhbo/O=tlec/S=plork/@gw.switch.ch
from chapter 3.3.1.1. RFC822 users would find it much more
'natural' if this address could be expressed in RFC822 as:
plork@tlec.fhbo.ade.nl
- X.400 users are used to using X.400 addresses with SAs only.
They often consider DDA addresses as complicated, especially
if they have to encode the special characters, @ % ! etc,
manually. They would rather be able to address an RFC822
user as if he had a 'normal' X.400 address. For example, take
the mapping
bush@dole.us
->
DD.RFC-822=bush(a)dole.us;
C=nl; ADMD= ; PRMD=tlec; O=gateway
from chapter 3.3.1.2. X.400 users would find it much more
'natural' if this address could be expressed in X.400 as:
C=us; ADMD=dole; S=bush
- Many organisations are using both RFC822 and X.400
internally, and still want all their users to have a simple,
unique address in both mail worlds. Note that in the default
mapping, the mapped form of an address completely depends on
which gateway performed the mapping. This also results in a
complication of a more technical nature:
- The tricky 'third party problem'. This problem need not
necessarily be understood to read the rest of this chapter.
If it looks too complicated, please feel free to skip it
until you are more familiar with the basics.
The third party problem is a routing problem caused by
mapping. As an example for DDA mappings (the example holds
just as well for left-hand-side encoding), consider the
following situation (see Fig. 3.1.): RFC822 user X in
country A sends a message to two recipients: RFC822 user Y,
and X.400 user Z, both in country B:
From: X@A
To: Y@B ,
/C=B/.../S=Z/@GW.A
Since the gateway in country A maps all addresses in the
message, Z will see both X's and Y's address as DDA-encoded
RFC822 addresses, with the SAs of the gateway in country A:
From: DD.RFC-822=X(a)A; C=A;....;O=GW
To: DD.RFC-822=Y(a)B; C=A;....;O=GW ,
C=B;...;S=Z
| ------------ ---------
| |X: RFC822|<------->|gateway|
| ------------ ---------
| A | ^
\ | |
\---------------------------------------------
| |
/---------------------------------------------
/ | |
| B | v
| | -----------
| | |Z: X.400 |
| | -----------
| | .
| | .
| | .
| | .
| | .
| v v
| ------------ ---------
| |Y: RFC822|<........|gateway|
| ------------ ---------
Fig. 3.1 The third party problem
Now if Z wants to 'group reply' to both X and Y, his reply to Y
will be routed over the gateway in country A, even though Y is
located in the same country:
From: C=B;...;S=Z
To: DD.RFC-822=Y(a)B; C=A;....;O=GW ,
DD.RFC-822=X(a)A; C=A;....;O=GW
The best way to travel for a message from Z to Y would of
course have been over the gateway in country B:
From: C=B;...;S=Z
To: DD.RFC-822=Y(a)B; C=B;....;O=GW ,
DD.RFC-822=X(a)A; C=A;....;O=GW
The third party problem is caused by the fact that routing
information is mapped into addresses.
Ideally, the third party problem shouldn't exist. After all,
address mapping affects addresses, and an address is not a
route.... The reality is different however. For instance, very
few X.400 products are capable to route messages on the
contents of a DDA (actually, only RFC1327 gateways will be
able to interpret this type of DDA, and who says that the reply
will pass a local gateway on its route back?). Similar
limitations hold for the other direction: an RFC822 based
mailer is not even allowed (see [5]) to make routing decisions
of the content of a left-hand-side encoded X.400 address if the
domain part is not its own. So in practice, addressing and
(thus also mapping) will very well affect routing.
To make mapping between addresses more user friendly, and to avoid
the problems shown above, RFC1327 allows for overruling the default
left-hand-side encoding and DDA mapping algorithms. This is done by
specifying associations (mapping rules) between certain domainparts
and X.400 domains. An X.400 domain (for our purposes; CCITT has a
narrower definition...) consists of the domain-related SAs of a
Mnemonic O/R address (i.e., all SAs except PN and CN). The idea is to
use the similarities between both address spaces, and directly map
similar address parts onto each other. If, for the domain in the
address to be mapped, an explicit mapping rule can be found, the
mapping is performed between:
localpart <-> PersonalName
domainpart <-> X.400 domain
The address information of the gateway is only used as an input
parameter if no mapping rule can be found, i.e., if the address
mapping must fall back to its default algorithm.
The complete mapping function can thus be visualised as follows:
address information of the gateway performing the mapping
|
v
+-----------------+
RFC822 address <--->| address mapping | <---> X.400 address
+-----------------+
^
|
domain associations (mapping rules)
3.3.2.1. PersonalName and localpart mapping
Since the mapping between these address parts is independent of the
mapping rules that are used, and because it follows a simple, two-
way algorithmic approach, this subject is discussed in a separate
sub-chapter first.
The X.400 PersonalName consists of givenName, initials, and surName.
RFC1327 assumes that generationQualifier is not used.
To map a localpart to an X.400 PN, the localpart is scanned for dots,
which are considered delimiters between the components of PN, and
also between single initials. In order not to put too much detail in
this tutorial, only a few examples are shown here. For the detailed
algorithm, see RFC1327, chapter 4.2.1.
Marshall.Rose <-> G=Marshall;S=Rose
M.T.Rose <-> I=MT;S=Rose
Marshall.M.T.Rose <-> G=Marshall;I=MT;S=Rose
To map an X.400 PN to an RFC822 localpart, take the non-empty PN
attributes, put them into their hierarchical order (G I* S), and
connect them with periods.
Some exceptions are caused by the fact that left-hand-side encoding
can also be mixed with exception mapping. This is shown in more
detail in the following sub-chapters.
3.3.2.2. X.400 domain and domainpart mapping
A mapping rule associates two domains: an X.400 domain and an RFC822
domain. The X.400 domain is written in the RFC1327 domain notation
(See 3.1.3.), so that both domains have the same hierarchical order.
The domains are written on one line, separated by a '#' sign. For
instance:
arcom.ch#ADMD$arcom.C$ch#
PRMD$tlec.ADMD$ade.C$nl#tlec.nl#
A mapping rule must at least contain a top level domain and a country
code. If an address must be mapped, a mapping rule with the longest
domain match is sought. The associated domain in the mapping rule is
used as the domain of the mapped address. The remaining domains are
mapped one by one following the natural hierarchy. Concrete examples
are shown in the following subchapters.
3.3.2.2.1. X.400 -> RFC822
As an example, assume the following mapping rule is defined:
PRMD$tlec.ADMD$ade.C$nl#tlec.nl#
Then the address C=nl; ADMD=ade; PRMD=tlec; O=you; OU=owe; S=plork
S OU O PRMD ADMD Country
| | | | | |
plork owe you tlec ade nl
would be mapped as follows. The Surname 'plork' is mapped to the
localpart 'plork', see chapter 3.3.2.1. The domain
localpart
| sdom3
| | sdom2
| | | sdom1
| | | | top-level-domain
| | | | |
plork@ tlec.nl
The remaining SAs (O and one OU) are mapped one by one following the
natural hierarchy: O is mapped to sdom2, OU is mapped to sdom3:
localpart
| sdom3
| | sdom2
| | | sdom1
| | | | top-level-domain
| | | | |
plork@owe.you.tlec.nl
Thus the mapped address is:
plork@owe.you.tlec.nl
The table containing the listing of all such mapping rules, which is
distributed to all gateways world-wide, is normally referred to as
'mapping table 1'. Other commonly used filenames (also depending on
which software your are using) are:
'or2rfc'
'mapping 1'
'map1'
'table 1'
'X2R'
As already announced, there is an exceptional case were localpart and
PN are not directly mapped onto each other: sometimes it is necessary
to use the localpart for other purposes. If the X.400 address
contains attributes that would not allow for the simple mapping:
localpart <-> PersonalName
domainpart <-> X.400 domain
(e.g., spaces are not allowed in an RFC822 domain, GQ and CN cannot
be directly mapped into localpart, DDAs of another type than RFC-
822), such attributes, together with the PN, are left-hand-side
encoded. The domainpart must still be mapped according to the mapping
rule as far as possible. This probably needs some examples:
C=nl; ADMD=ade; PRMD=tlec; O=owe; OU=you; S=plork; GQ=jr
->
/S=plork/GQ=jr/@you.owe.tlec.nl
C=nl; ADMD=ade; PRMD=tlec; O=owe; OU=spc ctr; OU=u; S=plork
->
"/S=plork/OU=u/OU=spc ctr/"@owe.tlec.nl
Note that in the second example, 'O=owe' is still mapped to a
subdomain following the natural hierarchy. The problems start with
the space in 'OU=spc ctr'.
3.3.2.2.2. RFC822 -> X.400
As an example, assume the following mapping rule is defined:
tlec.nl#PRMD$tlec.ADMD$ade.C$nl#
Then the address 'plork@owe.you.tlec.nl' :
localpart
| sdom3
| | sdom2
| | | sdom1
| | | | top-level-domain
| | | | |
plork@owe.you.tlec.nl
would be mapped as follows.
The localpart 'plork' is mapped to 'S=plork', see chapter 3.3.2.1.
The domain 'tlec.nl' is mapped according to the mapping rule:
S OU OU O PRMD ADMD Country
| | | |
plork tlec ade nl
The remaining domains (owe.you) are mapped one by one following the
natural hierarchy: sdom2 is mapped to O, sdom3 is mapped to OU:
S OU OU O PRMD ADMD Country
| | | | | |
plork | | tlec ade nl
owe you
Thus the mapped address is (in a readable notation):
C=nl; ADMD=ade; PRMD=tlec; O=you; OU=owe; S=plork
Had there been any left-hand-side encoded SAs in the localpart that
didn't represent a complete mnemonic O/R address, the localpart would
be mapped to those SAs. E.g.,
"/S=plork/GQ=jr/OU=u/OU=spc ctr/"@owe.tlec.nl
->
C=nl; ADMD=ade; PRMD=tlec; O=owe; OU=space ctr;
OU=u; S=plork; GQ=jr
This is necessary to reverse the special use of localpart to left-
hand-side encode certain attributes. See 3.3.2.2.1.
You might ask yourself by now why such rules are needed at all. Why
don't we just use map1 in the other direction? The problem is that a
symmetric mapping function (a bijection) would indeed be ideal, but
it's not feasible. Asymmetric mappings exist for a number of reasons:
- To make sure that uucp addresses etc. get routed over local
gateways.
- Preferring certain address forms, while still not forbidding
others to use another form. Examples of such reasons are:
- Phasing out old address forms.
- If an RFC822 address is mapped to ADMD= ; it means that
the X.400 mail can be routed over any ADMD in that
country. One single ADMD may of course send out an
address containing: ADMD=ade; . It must also be possible
to map such an address back.
So we do need mapping rules from RFC822 to X.400 too. The table
containing the listing of all such mapping rules, which is
distributed to all gateways world-wide, is normally referred to as on
which software your are using) are:
'rfc2or'
'mapping 2'
'map2'
'table 2'
'R2X'
If the RFC822 localpart and/or domainpart contain characters that
would not immediately fit in the value of a PN attribute (! % _), the
mapping algorithm falls back to DDA mapping. In this case, the SAs
that will be used are still determined by mapping the domainpart
according to the mapping rule. In our case:
100%user@work.tlec.nl
->
DD.RFC-822=100(p)user(a)work.tlec.nl;
C=nl; ADMD=ade; PRMD=tlec; O=work
If no map2 rule can be found, a third table of rules is scanned: the
gateway table. This table has the same syntax as mapping table 2, but
its semantics are different. First of all, a domain that only has an
entry in the gateway table is always mapped into an RFC822 DDA. For
a domain that is purely RFC822 based, but whose mail may be relayed
over an X.400 network, the gateway table associates with such a
domain the SAs of the gateway to which the X.400 message should be
routed. That gateway will then be responsible for gatewaying the
message back into the RFC822 world. E.g., if we have the gateway
table entry:
gov#PRMD$gateway.ADMD$Internet.C$us#
(and we assume that no overruling map2 rule for the top level domain
'gov' exists), this would force all gateways to perform the following
mapping:
bush@dole.gov
->
DD.RFC-822=bush(a)dole.gov;
C=us; ADMD=Internet; PRMD=gateway
This is very similar to the default DDA mapping, except the SAs are
those of a gateway that has declared to be responsible for a certain
RFC822 domain, not those of the local gateway. And thus, this
mechanism helps avoid the third party problem discussed in chapter
3.2.2.
The table containing the listing of all such gateway rules, which is
distributed to all gateways world-wide, is normally referred to as
the 'gateway table'. Other commonly used filenames (also depending on
which software your are using) are:
'rfc1148gate' {From the predecessor of RFC1327, RFC1148}
'gate table'
'GW'
Only when no rule at all (map2 or gateway rule) is defined for a
domain, the algorithm falls back to the default DDA mapping as
described in 3.3.1.2.
3.4. Table co-ordination
As already stated, the use of mapping tables will only function
smoothly if all gateways in the world use the same tables. On the
global level, the collection and distribution of RFC1327 address
mapping tables is co-ordinated by the MHS Co-ordination Service:
SWITCH Head Office
MHS Co-ordination Service
Limmatquai 138
CH-8001 Zurich, Europe
Tel. +41 1 268 1550
Fax. +41 1 268 1568
RFC822: project-team@switch.ch
X.400: C=ch;ADMD=arcom;PRMD=switch;O=switch;S=project-team;
The procedures for collection and distribution of mapping rules can
be found on the MHS Co-ordination Server, in the directory
"/procedures". Appendix D describes how this server can be accessed.
If you want to define mapping rules for your own local domain, you
can find the right contact person in your country or network (the
gateway manager) on the same server, in the directory "/mhs-
services".
3.5. Local additions
Since certain networks want to define rules that should only be used
within their networks, such rules should not be distributed world-
wide. Consider two networks that both want to reach the old top-
level-domain 'arpa' over their local gateway. They would both like to
use a mapping 2 rule for this purpose:
TLec in NL: arpa#PRMD$gateway.ADMD$tlec.C$nl#
SWITCH in CH: arpa#PRMD$gateway.ADMD$switch.C$ch#
(You may have noticed correctly that they should have defined such
rules in the gateway table, but for the sake of the example, we
assume they defined it in mapping table 2. This was the way things
were done in the days of RFC987, and many networks are still doing
it this way these days.)
Since a mapping table cannot contain two mapping rules with the same
domain on the left hand side, such 'local mappings' are not
distributed globally. There exists a RARE draft proposal [13] which
defines a mechanism for allowing and automatically dealing with
conflicting mapping rules, but this mechanism has not been
implemented as to date. After having received the global mapping
tables from the MHS Co-ordination Service, many networks add 'local'
rules to map2 and the gateway table before installing them on their
gateways. Note that the reverse mapping 2 rules for such local
mappings _are_ globally unique, and can thus be distributed world-
wide. This is even necessary, because addresses that were mapped with
a local mapping rule may leak out to other networks (here comes the
third party problem again...). Such other networks should at least be
given the possibility to map the addresses back. So the global
mapping table 1 would in this case contain the two rules:
PRMD$gateway.ADMD$tlec.C$nl#arpa#
PRMD$gateway.ADMD$switch.C$ch#arpa#
Note that if such rules would have been defined as local gate table
entries instead of map2 entries, there would have been no need to
distribute the reverse mappings world-wide (the reverse mapping of a
DDA encoded RFC822 address is simply done by stripping the SAs, see
3.3.1.1.).
3.6. Product specific formats
Not all software uses the RFC1327 format of the mapping tables
internally. Almost all formats allow comments on a line starting with
a # sign. Some examples of different formats:
RFC1327
# This is pure RFC1327 format
# table 1: X.400 -> RFC822
#
PRMD$tlec.ADMD$ade.C$nl#tlec.nl#
# etc.
# table 2: RFC822 -> X.400
#
arcom.ch#ADMD$arcom.C$ch#
# etc.
EAN
# This is EAN format
# It uses the readable format for X.400 domains and TABs
# to make a 'readable mapping table format'.
# table 1: X.400 -> RFC822
#
P=tlec; A=ade; C=nl; # tlec.nl
# etc.
# table 2: RFC822 -> X.400
#
arcom.ch # A=arcom; C=ch;
# etc.
PP
# This is PP format
# table 1: X.400 -> RFC822
#
PRMD$tlec.ADMD$ade.C$nl:tlec.nl
# etc.
# table 2: RFC822 -> X.400
#
arcom.ch:ADMD$arcom.C$ch
# etc.
Most R&D networks have tools to automatically generate these formats
from the original RFC1327 tables;, some even distribute the tables
within their networks in several formats. If you need mapping tables
in a specific format, please contact your national or R&D network's
gateway manager. See chapter 3.4.
3.7. Guidelines for mapping rule definition
Beware that defining mapping rules without knowing what you are doing
can be disastrous not only for your network, but also for others. You
should be rather safe if you follow at least these rules:
- First of all, read this tutorial;.
- Avoid local mappings; prefer gate table entries. (See chapter
3.5)
- Make sure any domain you map to can also be mapped back;.
- Aim for symmetry.
- Don't define a gateway table entry if the same domain already
has a map2 entry. Such a rule would be redundant.
- Map to "ADMD=0;" if you will not be connected to any ADMD for
the time being.
- Only map to "ADMD= ;" if you are indeed reachable through
_any_ ADMD in your country.
- Mind the difference between "PRMD=;" and "PRMD=@;" and make
sure which one you need. (Try to avoid empty or unused
attributes in the O/R address hierarchy from the beginning!)
- Don't define mappings for domains over which you have no
naming authority.
- Before defining a mapping rule, make sure you have the
permission from the naming authority of the domain you want
to map to. Normally, this should be the same organisation as
the mapping authority of the domain in the left hand side of
the mapping rule. This principle is called 'administrative
equivalence'.
- Avoid redundant mappings. E.g., if all domains under 'tlec.nl'
are in your control, don't define:
first.tlec.nl#O$first.PRMD$tlec.ADMD$ade.C$nl#
last.tlec.nl#O$last.PRMD$tlec.ADMD$ade.C$nl#
always.tlec.nl#O$always.PRMD$tlec.ADMD$ade.C$nl#
but rather have only one mapping rule:
tlec.nl#PRMD$tlec.ADMD$ade.C$nl#
- Before introducing a new mapped version of a domain, make
sure the world can route to that mapped domain;.
E.g., If you are operating a PRMD: C=zz; ADMD=ade; PRMD=ergo;
and you want to define the mapping rules:
map1: PRMD$ergo.ADMD$ade.C$zz#ergo.zz#
map2: ergo.zz#PRMD$ergo.ADMD$ade.C$zz#
Make sure that ergo.zz (or at least all of its subdomains) is
DNS routeable (register an MX or A record) and will be routed
to a gateway that agreed to route the messages from the
Internet to you over X.400.
In the other direction, if you are operating the Internet
domain cs.woodstock.edu, and you want to define a mapping for
that domain:
map2: cs.woodstock.edu#O$cs.PRMD$woodstock.ADMD$ .C$us#
map1: O$cs.PRMD$woodstock.ADMD$ .C$us#cs.woodstock.edu#
Make sure that C=us; ADMD= ; PRMD=woodstock; O=cs; (or at
least all of its subdomains) is routeable in the X.400 world,
and will be routed to a gateway that agreed to route the
messages from X.400 to your RFC822 domain over SMTP. Within
the GO-MHS community, this would be done by registering a
line in a so-called domain document, which will state to
which mail relay this domain should be routed.
Co-ordinate any such actions with your national or MHS'
gateway manager. See chapter 3.4.
4. Conclusion
Mail gatewaying remains a complicated subject. If after reading this
tutorial, you feel you understand the basics, try solving some real-
life problems. This is indeed a very rewarding area to work in: even
after having worked with it for many years, you can make amazing
discoveries every other week........
Appendix A. References
[1] Postel, J., "Simple Mail Transfer Protocol", STD 10, RFC821,
USC/Information Sciences Institute, August 1982.
[2] Crocker, D., "Standard for the Format of ARPA Internet Text
Messages", STD 11, RFC822, University of Delaware, August 1982.
[3] Mockapetris, P., "Domain Names - Concepts and Facilities", and
"Domain Names - Implementation and Specification", STD 13, RFCs
1034 and 1035, USC/Information Sciences Institute, November
1987.
[4] Kille, S., "Mapping Between X.400 and RFC822", RFC987, UK
Academic Community Report (MG.19), UCL, June 1986.
[5] Braden, R., Editor, "Requirements for Internet Hosts --
Application and Support", STD 3, RFC1123, USC/Information
Sciences Institute, October 1989.
[6] Postel, J., Editor, "Internet Official Protocol Standards", STD
1, RFC1500, USC/Information Sciences Institute, August 1993.
[7] Chapin, L., Chair, "The Internet Standards Process", RFC1310,
Internet Activities Board, March 1992.
[8] Kille, S., "Mapping between X.400(1988) / ISO 10021 and RFC
822", RFC1327 / RARE RTR 2, University College London, May
1992.
[9] Kille, S., "X.400 1988 to 1984 downgrading", RFC1328 / RARE RTR
3, University College London, May 1992.
[10] Plattner, B., and H. Lubich, "Electronic Mail Systems and
Protocols Overview and Case Study", Proceedings of the IFIP WG
6.5 International working conference on message handling systems
and distributed applications; Costa Mesa 1988; North-Holland,
1989.
[11] Houttuin, J., "@route:100%name@address, a practical guide to MHS
configuration", Top-Level EC, 1993, (not yet published).
[12] Alvestrand, H., "Frequently asked questions on X.400", regularly
posted on USEnet in newsgroup comp.protocols.iso.x400.
[13] Houttuin, J., Hansen, K., and S. Aumont, "RFC1327 Address
Mapping Authorities", RARE WG-MSG Working Draft, Work in
Progress, May 1993.
[14] "COSINE MHS Pocket User Guide", COSINE MHS Project Team 1992.
Also available in several languages from the MHS Co-ordination
Server:/user-guides. See Appendix D.
[15] Grimm, R., and S. Haug, "A Minimum Profile for RFC987", GMD,
November 1987; RARE MHS Project Team; July 1990. Also available
from the MHS Co-ordination Server:/procedures/min-rfc987-
profile. See Appendix D.
[16] CCITT Recommendations X.400 - X.430. Data Communication
Networks: Message Handling Systems. CCITT Red Book, Vol. VIII -
Fasc. VIII.7, Malaga-Torremolinos 1984.
[17] CCITT Recommendations X.400 - X.420. Data Communication
Networks: Message Handling Systems. CCITT Blue Book, Vol. VIII
- Fasc. VIII.7, Melbourne 1988.
Appendix B. Index
<<Only available in the Postscript version>>
Appendix C. Abbreviations
ADMD Administration Management Domain
ARPA Advanced Research Projects Agency
ASCII American Standard Code for Information Exchange
ASN.1 Abstract Syntax Notation One
BCD Binary-Coded Decimal
BITNET Because It's Time NETwork
CCITT Comite Consultatif International de Telegraphique et
Telephonique
COSINE Co-operation for OSI networking in Europe
DFN Deutsches Forschungsnetz
DL Distribution List
DNS Domain Name System
DoD Department of Defense
EBCDIC Extended BCD Interchange Code
IAB Internet Architecture Board
IEC International Electrotechnical Commission
IESG Internet Engineering Steering Group
IETF Internet Engineering Task Force
IP Internet Protocol
IPM Inter-Personal Message
IPMS Inter-Personal Messaging Service
IPN Inter-Personal Notification
ISO International Organisation for Standardisation
ISOC Internet Society
ISODE ISO Development Environment
JNT Joint Network Team (UK)
JTC Joint Technical Committee (ISO/IEC)
MHS Message Handling System
MOTIS Message-Oriented Text Interchange Systems
MTA Message Transfer Agent
MTL Message Transfer Layer
MTS Message Transfer System
MX Mail eXchanger
OSI Open Systems Interconnection
OU(s) Organizational Unit(s)
PP Mail gatewaying software (not an abbreviation)
PRMD Private Management Domain
RARE Reseaux Associes pour la Recherche Europeenne
RFCRequest for comments
RTC RARE Technical Committee
RTR RARE Technical Report
SMTP simple mail transfer protocol
STD Internet Standard
TCP Transmission Control Protocol
UUCP Unix to Unix CoPy
Appendix D. How to access the MHS Co-ordination Server
Here is an at-a-glance sheet on the access possibilities of the MHS
Co-ordination server:
address:
RFC822: mhs-server@nic.switch.ch
X.400: S=mhs-server; OU1=nic; O=switch; P=switch; A=arcom;
C=CH
body
help # you receive this document
index ['directory'] # you receive a directory listing
send 'directory''filename' # you receive the specified file
FTP
address: Internet: nic.switch.ch
account: cosine
password: 'your email address'
Interactive
address: Internet: nic.switch.ch
address: PSPDN: +22847971014540
address: EMPB/IXI: 20432840100540
account: info
directory: e-mail/COSINE-MHS/
FTAM
address: Internet: nic.switch.ch
address: PSPDN : +22847971014540
address: EMPB/IXI: 20432840100540
address: ISO CLNS: NSAP=39756f11112222223333aa0004000ae100,
TSEL=0103Hex
account: ANON
gopher
address: Internet: nic.switch.ch
Security Considerations
Security issues are not discussed in this memo.
Author's Address
Jeroen Houttuin
RARE Secretariat
Singel 466-468
NL-1017 AW Amsterdam
Europe
Tel. +31 20 6391131
Fax. +31 20 6393289
RFC822: houttuin@rare.nl
X.400: C=nl;ADMD=400net;PRMD=surf;O=rare;S=houttuin