the X.400 O/R name space in the DNS structure provide a good
repository for MCGAM information. The mapping information is stored
in the DNS tree structure so that it can be easily obtained using the
DNS distributed name service. At the same time the definition of the
appropriate DNS space for X.400 O/R names provide a repository where
to store and distribute some other X.400 MHS information. The use of
the DNS has many known advantages in storing, managing and updating
the information. A successful number of tests were been performed
under the provisional top level domain "X400.IT" when RFC1664 was
developed, and their results confirmed the advantages of the method.
Operational exeprience for over 2 years with RFC1664 specification
confirmed the feasibility of the method, and helped identifying some
operational procedures to deploy the insertion of MCGAM into DNS.
Software to query the DNS and then to convert between the textual
representation of DNS resource records and the address format defined
in MIXER was developed with RFC1664. This software also allows a
smooth implementation and deployment period, eventually taking care
of the transition phase. This software can be easily used (with
little or null modification) also for this updated specification,
supporting the new 'gate1' MIXER table. DNS software implementations
supporting RFC1664 also supports with no modification this memo new
specification.
A further informational document describing operational and
implementation of the service is expected.
8. Acknowledgements
We wish to thanks all those who contributed to the discussion and
revision of this document: many of their ideas and suggestions
constitute essential parts of this work. In particular thanks to Jon
Postel, Paul Mockapetris, Rob Austin and the whole IETF x400ops,
TERENA wg-msg and IETF namedroppers groups. A special mention to
Christian Huitema for his fundamental contribution to this work.
This document is a revision of RFC1664, edited by one of its authors
on behalf of the IETF MIXER working group. The current editor wishes
to thank here also the authors of RFC1664:
Antonio Blasco Bonito RFC822: bonito@cnuce.cnr.it
CNUCE - CNR X.400: C=it;A=garr;P=cnr;
Reparto infr. reti O=cnuce;S=bonito;
Viale S. Maria 36
I 56126 Pisa
Italy
Bruce Cole RFC822: bcole@cisco.com
Cisco Systems Inc. X.400: C=us;A= ;P=Internet;
P.O. Box 3075 DD.rfc-822=bcole(a)cisco.com;
1525 O'Brien Drive
Menlo Park, CA 94026
U.S.A.
Silvia Giordano RFC822: giordano@cscs.ch
Centro Svizzero di X.400: C=ch;A=arcom;P=switch;O=cscs;
Calcolo Scientifico S=giordano;
Via Cantonale
CH 6928 Manno
Switzerland
Robert Hagens RFC822: hagens@ans.net
Advanced Network and Services X.400: C=us;A= ;P=Internet;
1875 Campus Commons Drive DD.rfc-822=hagens(a)ans.net;
Reston, VA 22091
U.S.A.
9. References
[CCITT] CCITT SG 5/VII, "Recommendation X.400, Message Handling
Systems: System Model - Service Elements", October 1988.
[RFC1327] Kille, S., "Mapping between X.400(1988)/ISO 10021 and RFC
822", RFC1327, March 1992.
[RFC1034] Mockapetris, P., "Domain Names - Concepts and Facilities",
STD 13, RFC1034, USC/Information Sciences Institute, November
1987.
[RFC1035] Mockapetris, P., "Domain names - Implementation and
Specification", STD 13, RFC1035, USC/Information Sciences
Institute, November 1987.
[RFC1033] Lottor, M., "Domain Administrators Operation Guide", RFC
1033, SRI International, November 1987.
[RFC2156] Kille, S. E., " MIXER (Mime Internet X.400 Enhanced
Relay): Mapping between X.400 and RFC822/MIME", RFC2156,
January 1998.
[Costa] Costa, A., Macedo, J., and V. Freitas, "Accessing and
Managing DNS Information in the X.500 Directory", Proceeding of
the 4th Joint European Networking Conference, Trondheim, NO, May
1993.
10. Security Considerations
This document specifies a means by which DNS "PX" records can direct
the translation between X.400 and Internet mail addresses.
This can indirectly affect the routing of mail across an gateway
between X.400 and Internet Mail. A succesful attack on this service
could cause incorrect translation of an originator address (thus
"forging" the originator address), or incorrect translation of a
recipient address (thus directing the mail to an unauthorized
recipient, or making it appear to an authorized recipient, that the
message was intended for recipients other than those chosen by the
originator) or could force the mail path via some particular gateway
or message transfer agent where mail security can be affected by
compromised software.
There are several means by which an attacker might be able to deliver
incorrect PX records to a client. These include: (a) compromise of a
DNS server, (b) generating a counterfeit response to a client's DNS
query, (c) returning incorrect "additional information" in response
to an unrelated query.
Clients using PX records SHOULD ensure that routing and address
translations are based only on authoritative answers. Once DNS
Security mechanisms [RFC2065] become more widely deployed, clients
SHOULD employ those mechanisms to verify the authenticity and
integrity of PX records.
11. Author's Address
Claudio Allocchio
Sincrotrone Trieste
SS 14 Km 163.5 Basovizza
I 34012 Trieste
Italy
RFC822: Claudio.Allocchio@elettra.trieste.it
X.400: C=it;A=garr;P=Trieste;O=Elettra;
S=Allocchio;G=Claudio;
Phone: +39 40 3758523
Fax: +39 40 3758565
12. Full Copyright Statement
Copyright (C) The Internet Society (1998). All Rights Reserved.
This document and translations of it may be copied and furnished to
others, and derivative works that comment on or otherwise explain it
or assist in its implementation may be prepared, copied, published
and distributed, in whole or in part, without restriction of any
kind, provided that the above copyright notice and this paragraph are
included on all such copies and derivative works. However, this
document itself may not be modified in any way, such as by removing
the copyright notice or references to the Internet Society or other
Internet organizations, except as needed for the purpose of
developing Internet standards in which case the procedures for
copyrights defined in the Internet Standards process must be
followed, or as required to translate it into languages other than
English.
The limited permissions granted above are perpetual and will not be
revoked by the Internet Society or its successors or assigns.
This document and the information contained herein is provided on an
"AS IS" basis and THE INTERNET SOCIETY AND THE INTERNET ENGINEERING
TASK FORCE DISCLAIMS ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING
BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION
HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF
MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.