Movatterモバイル変換

Network Working Group                                        A. CargilleRequest for Comments: 1648                       University of WisconsinCategory: Standards Track                                      July 1994Postmaster Convention for X.400 OperationsStatus of this Memo   This document specifies an Internet standards track protocol for the   Internet community, and requests discussion and suggestions for   improvements.  Please refer to the current edition of the "Internet   Official Protocol Standards" (STD 1) for the standardization state   and status of this protocol.  Distribution of this memo is unlimited.Abstract   Both STD 11,RFC 822 [1] and STD 3,RFC 1123 [2] (Host Requirements)   require that the email address "postmaster" be supported at all   hosts.  This paper extends this concept to X.400 mail domains which   have registeredRFC 1327 mapping rules, and which therefore appear to   have normalRFC822-style addresses.1.  Postmaster Convention inRFC822   Operating a reliable, large-scale electronic mail (email) network   requires cooperation between many mail managers and system   administrators.  As noted inRFC 822 [1], often mail or system   managers need to be able to contact a responsible person at a remote   host without knowing any specific user name or address at that host.   For that reason, bothRFC 822 and the Internet Host Requirements [2]   require that the address "postmaster" be supported at every Internet   host.2.  Postmaster Convention and X.400   However,RFC 822 is not the only email protocol being used in the   Internet.  Some Internet sites are also running the X.400 (1984) [3]   and X.400 (1988) [4] email protocols.RFC 1327 specifies how to map   between X.400 andRFC 822 addresses [5].  When mapping rules are   used, addresses map cleanly between X.400 andRFC 822.  In fact, it   is impossible to determine by inspecting the address whether the   recipient is anRFC 822 mail user or an X.400 mail user.   A paper by Rob Hagens and Alf Hansen describes an X.400 community   known as the "Global Open MHS Community" (GO-MHS) [6].  Many mail   domains in the GO-MHS Community have registeredRFC 1327 mapping   rules.  Therefore, users in those domains haveRFC 822-style emailCargille                                                        [Page 1]

RFC 1648              X.400 Postmaster Convention              July 1994   addresses, and these email domains are a logical extension of theRFC822 Internet.  It is impossible to tell by inspecting a user's   address whether the user receivesRFC 822 mail or X.400 mail.   Since these addresses appear to be standardRFC 822 addresses, mail   managers, mailing list managers, host administrators, and users   expect to be able to simply send mail to "postmaster@domain" and   having the message be delivered to a responsible party.  When anRFC1327 mapping rule exists, the X.400 address element corresponding to   the left-hand-side "postmaster" is "Surname=Postmaster" (both 1984   and 1988).  However, neither the X.400 protocols, North America X.400   Implementor's Agreements [7], nor the other regional X.400   implementor's agreements require that "Surname=Postmaster" and   "CommonName=Postmaster" be supported.  (Supporting these addresses is   recommended in X.400 (1988)).   For mapped X.400 domains which do not support the postmaster   address(es), this means that an address such as "user@some.place.zz"   might be valid, yet mail to the corresponding address   "postmaster@some.place.zz" fails.  This is frustrating for remote   administrators and users, and can prevent operational problems from   being communicated and resolved.  In this case, the desired seamless   integration of the InternetRFC 822 mail world and the mapped X.400   domain has not been achieved.   The X.400 mail managers participating in the Cosine MHS Project   discussed this problem in a meeting in June 1992 [8].  The discussion   recognized the need for supporting the postmaster address at any   level of the address hierarchy where these are user addresses.   However, the group only required supporting the postmaster address   down to certain levels of the O/R Address tree.  This approach solved   part of the problem, but not all of it.  A more complete solution is   required.3.  Proposed Solution   To fully achieve the desired seamless integration of email domains   for whichRFC 1327 mapping rules have been defined, the following   convention must be followed,      If there are any valid addresses of the form "user@domain", then      the address "postmaster@domain" must also be valid.   To express this in terms of X.400:  For every X.400 domain for which   anRFC 1327 mapping rule exists, if any address of the form      Surname=User; <Other X.400 Address Elements>Cargille                                                        [Page 2]

RFC 1648              X.400 Postmaster Convention              July 1994   is a valid address, then the address      Surname=Postmaster; <Same X.400 Address Elements>   must also be a valid address.  If the X.400 system is running   X.400(1988), then the address      CommonName=Postmaster; <Same X.400 Address Elements>   must also be supported.  (Note that CommonName=Postmaster will not be   generated byRFC 1327 mappings, but it is recommended in the 1988   X.400 standard).   To remain consistent withRFC 822, "Mail sent to that address is to   be routed to a person responsible for the site's mail system or to a   person with responsibility for general site operation." [9].3.1.  Software Limitations   If software is unable to support this requirement, it should be   upgraded.  X.400 software developers are strongly encouraged and   requested to support forwarding mail to a centralized postmaster   mailbox in products.   It may be possible to support forwarding postmaster mail to a central   mailbox in software packages which do not explicitly support it by   applying work-around solutions.  For example, some packages support   creating a mailing list for "postmaster" which has one entry that   points to the desired centralized postmaster mailbox.  Alternatively,   it may be possible to support a postmaster address using the X.400   Autoforwarding feature.  The software package may also support   rewriting the address in some other way.4.  Acknowledgements   This document is a product of discussion and comments from the IETF   OSI X.400 Operations Working Group.  Helpful input was also received   from the European MHS Managers.  Special thanks to Marko Kaittola and   Erik Lawaetz for good criticism and helpful discussion.Security Considerations   Security issues are not discussed in this memo.Cargille                                                        [Page 3]

RFC 1648              X.400 Postmaster Convention              July 19945.  Author's Address   Allan Cargille   Associate Researcher   Computer Sciences Department   University of Wisconsin-Madison   1210 West Dayton Street   Madison, WI   53706   USA   Internet: cargille@cs.wisc.edu   X.400: S=Cargille; O=UW-Madison; OU1=cs; PRMD=xnren; ADMD= ; C=us;   Phone: +1 (608) 262-5084   Fax:   +1 (608) 262-97776.  References   [1] Crocker, D., "Standard of the Format of ARPA Internet Text       Messages", STD 11,RFC 822, UDEL, August 1982.   [2] Braden, R., "Requirements for Internet Hosts -- Application and       Support", STD 3,RFC 1123, USC/Information Sciences Institute,       October 1989.   [3] CCITT, "CCITT Recommendations X.400", Message Handling Systems:       System Model--Service Elements, 1984.   [4] CCITT/ISO, "CCITT Recommendations X.400/ ISO IS 10021-1", Message       Handling: System and Service Overview, December 1988.   [5] Kille, S., "Mapping between X.400(1988) / ISO 10021 andRFC 822",RFC 1327, University College London, May 1992.   [6] Hagens, R. and A. Hansen, "Operational Requirements for X.400       Management Domains in the GO-MHS Community," ANS, UNINETT,RFC1649, July 1994.   [7] U.S. Department of Commerce, National Institute of Standards and       Technology, Stable Implementation Agreements for Open Systems       Interconnection Protocols, Version 7, Edition 1, Special       Publication 500-214, December 1993.   [8] Minutes, Cosine MHS Managers Meeting, June 1992, (unpublished).   [9] Crocker, D., "Standard of the Format of ARPA Internet Text       Messages", STD 11,RFC 822, UDEL, Pg. 33, August 1982.Cargille                                                        [Page 4]