home *** CD-ROM | disk | FTP | other *** search
/ Internet Info 1997 December / Internet_Info_CD-ROM_Walnut_Creek_December_1997.iso / rfc / rfc1648 < prev    next >
Text File  |  1995-09-15  |  9KB  |  228 lines
  1.  
  2.  
  3.  
  4.  
  5.  
  6.  
  7. Network Working Group                                        A. Cargille
  8. Request for Comments: 1648                       University of Wisconsin
  9. Category: Standards Track                                      July 1994
  10.  
  11.  
  12.                Postmaster Convention for X.400 Operations
  13.  
  14. Status of this Memo
  15.  
  16.    This document specifies an Internet standards track protocol for the
  17.    Internet community, and requests discussion and suggestions for
  18.    improvements.  Please refer to the current edition of the "Internet
  19.    Official Protocol Standards" (STD 1) for the standardization state
  20.    and status of this protocol.  Distribution of this memo is unlimited.
  21.  
  22. Abstract
  23.  
  24.    Both STD 11, RFC 822 [1] and STD 3, RFC 1123 [2] (Host Requirements)
  25.    require that the email address "postmaster" be supported at all
  26.    hosts.  This paper extends this concept to X.400 mail domains which
  27.    have registered RFC 1327 mapping rules, and which therefore appear to
  28.    have normal RFC822-style addresses.
  29.  
  30. 1.  Postmaster Convention in RFC822
  31.  
  32.    Operating a reliable, large-scale electronic mail (email) network
  33.    requires cooperation between many mail managers and system
  34.    administrators.  As noted in RFC 822 [1], often mail or system
  35.    managers need to be able to contact a responsible person at a remote
  36.    host without knowing any specific user name or address at that host.
  37.    For that reason, both RFC 822 and the Internet Host Requirements [2]
  38.    require that the address "postmaster" be supported at every Internet
  39.    host.
  40.  
  41. 2.  Postmaster Convention and X.400
  42.  
  43.    However, RFC 822 is not the only email protocol being used in the
  44.    Internet.  Some Internet sites are also running the X.400 (1984) [3]
  45.    and X.400 (1988) [4] email protocols.  RFC 1327 specifies how to map
  46.    between X.400 and RFC 822 addresses [5].  When mapping rules are
  47.    used, addresses map cleanly between X.400 and RFC 822.  In fact, it
  48.    is impossible to determine by inspecting the address whether the
  49.    recipient is an RFC 822 mail user or an X.400 mail user.
  50.  
  51.    A paper by Rob Hagens and Alf Hansen describes an X.400 community
  52.    known as the "Global Open MHS Community" (GO-MHS) [6].  Many mail
  53.    domains in the GO-MHS Community have registered RFC 1327 mapping
  54.    rules.  Therefore, users in those domains have RFC 822-style email
  55.  
  56.  
  57.  
  58. Cargille                                                        [Page 1]
  59.  
  60. RFC 1648              X.400 Postmaster Convention              July 1994
  61.  
  62.  
  63.    addresses, and these email domains are a logical extension of the RFC
  64.    822 Internet.  It is impossible to tell by inspecting a user's
  65.    address whether the user receives RFC 822 mail or X.400 mail.
  66.  
  67.    Since these addresses appear to be standard RFC 822 addresses, mail
  68.    managers, mailing list managers, host administrators, and users
  69.    expect to be able to simply send mail to "postmaster@domain" and
  70.    having the message be delivered to a responsible party.  When an RFC
  71.    1327 mapping rule exists, the X.400 address element corresponding to
  72.    the left-hand-side "postmaster" is "Surname=Postmaster" (both 1984
  73.    and 1988).  However, neither the X.400 protocols, North America X.400
  74.    Implementor's Agreements [7], nor the other regional X.400
  75.    implementor's agreements require that "Surname=Postmaster" and
  76.    "CommonName=Postmaster" be supported.  (Supporting these addresses is
  77.    recommended in X.400 (1988)).
  78.  
  79.    For mapped X.400 domains which do not support the postmaster
  80.    address(es), this means that an address such as "user@some.place.zz"
  81.    might be valid, yet mail to the corresponding address
  82.    "postmaster@some.place.zz" fails.  This is frustrating for remote
  83.    administrators and users, and can prevent operational problems from
  84.    being communicated and resolved.  In this case, the desired seamless
  85.    integration of the Internet RFC 822 mail world and the mapped X.400
  86.    domain has not been achieved.
  87.  
  88.    The X.400 mail managers participating in the Cosine MHS Project
  89.    discussed this problem in a meeting in June 1992 [8].  The discussion
  90.    recognized the need for supporting the postmaster address at any
  91.    level of the address hierarchy where these are user addresses.
  92.    However, the group only required supporting the postmaster address
  93.    down to certain levels of the O/R Address tree.  This approach solved
  94.    part of the problem, but not all of it.  A more complete solution is
  95.    required.
  96.  
  97. 3.  Proposed Solution
  98.  
  99.    To fully achieve the desired seamless integration of email domains
  100.    for which RFC 1327 mapping rules have been defined, the following
  101.    convention must be followed,
  102.  
  103.       If there are any valid addresses of the form "user@domain", then
  104.       the address "postmaster@domain" must also be valid.
  105.  
  106.    To express this in terms of X.400:  For every X.400 domain for which
  107.    an RFC 1327 mapping rule exists, if any address of the form
  108.  
  109.       Surname=User; <Other X.400 Address Elements>
  110.  
  111.  
  112.  
  113.  
  114. Cargille                                                        [Page 2]
  115.  
  116. RFC 1648              X.400 Postmaster Convention              July 1994
  117.  
  118.  
  119.    is a valid address, then the address
  120.  
  121.       Surname=Postmaster; <Same X.400 Address Elements>
  122.  
  123.    must also be a valid address.  If the X.400 system is running
  124.    X.400(1988), then the address
  125.  
  126.       CommonName=Postmaster; <Same X.400 Address Elements>
  127.  
  128.    must also be supported.  (Note that CommonName=Postmaster will not be
  129.    generated by RFC 1327 mappings, but it is recommended in the 1988
  130.    X.400 standard).
  131.  
  132.    To remain consistent with RFC 822, "Mail sent to that address is to
  133.    be routed to a person responsible for the site's mail system or to a
  134.    person with responsibility for general site operation." [9].
  135.  
  136. 3.1.  Software Limitations
  137.  
  138.    If software is unable to support this requirement, it should be
  139.    upgraded.  X.400 software developers are strongly encouraged and
  140.    requested to support forwarding mail to a centralized postmaster
  141.    mailbox in products.
  142.  
  143.    It may be possible to support forwarding postmaster mail to a central
  144.    mailbox in software packages which do not explicitly support it by
  145.    applying work-around solutions.  For example, some packages support
  146.    creating a mailing list for "postmaster" which has one entry that
  147.    points to the desired centralized postmaster mailbox.  Alternatively,
  148.    it may be possible to support a postmaster address using the X.400
  149.    Autoforwarding feature.  The software package may also support
  150.    rewriting the address in some other way.
  151.  
  152. 4.  Acknowledgements
  153.  
  154.    This document is a product of discussion and comments from the IETF
  155.    OSI X.400 Operations Working Group.  Helpful input was also received
  156.    from the European MHS Managers.  Special thanks to Marko Kaittola and
  157.    Erik Lawaetz for good criticism and helpful discussion.
  158.  
  159. Security Considerations
  160.  
  161.    Security issues are not discussed in this memo.
  162.  
  163.  
  164.  
  165.  
  166.  
  167.  
  168.  
  169.  
  170. Cargille                                                        [Page 3]
  171.  
  172. RFC 1648              X.400 Postmaster Convention              July 1994
  173.  
  174.  
  175. 5.  Author's Address
  176.  
  177.    Allan Cargille
  178.    Associate Researcher
  179.    Computer Sciences Department
  180.    University of Wisconsin-Madison
  181.    1210 West Dayton Street
  182.    Madison, WI   53706   USA
  183.  
  184.    Internet: cargille@cs.wisc.edu
  185.    X.400: S=Cargille; O=UW-Madison; OU1=cs; PRMD=xnren; ADMD= ; C=us;
  186.  
  187.    Phone: +1 (608) 262-5084
  188.    Fax:   +1 (608) 262-9777
  189.  
  190. 6.  References
  191.  
  192.    [1] Crocker, D., "Standard of the Format of ARPA Internet Text
  193.        Messages", STD 11, RFC 822, UDEL, August 1982.
  194.  
  195.    [2] Braden, R., "Requirements for Internet Hosts -- Application and
  196.        Support", STD 3, RFC 1123, USC/Information Sciences Institute,
  197.        October 1989.
  198.  
  199.    [3] CCITT, "CCITT Recommendations X.400", Message Handling Systems:
  200.        System Model--Service Elements, 1984.
  201.  
  202.    [4] CCITT/ISO, "CCITT Recommendations X.400/ ISO IS 10021-1", Message
  203.        Handling: System and Service Overview, December 1988.
  204.  
  205.    [5] Kille, S., "Mapping between X.400(1988) / ISO 10021 and RFC 822",
  206.        RFC 1327, University College London, May 1992.
  207.  
  208.    [6] Hagens, R. and A. Hansen, "Operational Requirements for X.400
  209.        Management Domains in the GO-MHS Community," ANS, UNINETT, RFC
  210.        1649, July 1994.
  211.  
  212.    [7] U.S. Department of Commerce, National Institute of Standards and
  213.        Technology, Stable Implementation Agreements for Open Systems
  214.        Interconnection Protocols, Version 7, Edition 1, Special
  215.        Publication 500-214, December 1993.
  216.  
  217.    [8] Minutes, Cosine MHS Managers Meeting, June 1992, (unpublished).
  218.  
  219.    [9] Crocker, D., "Standard of the Format of ARPA Internet Text
  220.        Messages", STD 11, RFC 822, UDEL, Pg. 33, August 1982.
  221.  
  222.  
  223.  
  224.  
  225.  
  226. Cargille                                                        [Page 4]
  227.  
  228.