home *** CD-ROM | disk | FTP | other *** search
/ Handbook of Infosec Terms 2.0 / Handbook_of_Infosec_Terms_Version_2.0_ISSO.iso / text / rfcs / rfc1648.txt < prev    next >
Text File  |  1996-05-07  |  9KB  |  124 lines

  1.  
  2.  
  3.  
  4.  
  5.  
  6.  
  7. Network Working Group                                        A. Cargille Request for Comments: 1648                       University of Wisconsin Category: Standards Track                                      July 1994 
  8.  
  9.                 Postmaster Convention for X.400 Operations 
  10.  
  11. Status of this Memo 
  12.  
  13.    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. 
  14.  
  15. Abstract 
  16.  
  17.    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 registered RFC 1327 mapping rules, and which therefore appear to    have normal RFC822-style addresses. 
  18.  
  19. 1.  Postmaster Convention in RFC822 
  20.  
  21.    Operating a reliable, large-scale electronic mail (email) network    requires cooperation between many mail managers and system    administrators.  As noted in RFC 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, both RFC 822 and the Internet Host Requirements [2]    require that the address "postmaster" be supported at every Internet    host. 
  22.  
  23. 2.  Postmaster Convention and X.400 
  24.  
  25.    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 and RFC 822 addresses [5].  When mapping rules are    used, addresses map cleanly between X.400 and RFC 822.  In fact, it    is impossible to determine by inspecting the address whether the    recipient is an RFC 822 mail user or an X.400 mail user. 
  26.  
  27.    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 registered RFC 1327 mapping    rules.  Therefore, users in those domains have RFC 822-style email 
  28.  
  29.  
  30.  
  31. Cargille                                                        [Page 1] 
  32.  RFC 1648              X.400 Postmaster Convention              July 1994 
  33.  
  34.     addresses, and these email domains are a logical extension of the RFC    822 Internet.  It is impossible to tell by inspecting a user's    address whether the user receives RFC 822 mail or X.400 mail. 
  35.  
  36.    Since these addresses appear to be standard RFC 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 an RFC    1327 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)). 
  37.  
  38.    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 Internet RFC 822 mail world and the mapped X.400    domain has not been achieved. 
  39.  
  40.    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. 
  41.  
  42. 3.  Proposed Solution 
  43.  
  44.    To fully achieve the desired seamless integration of email domains    for which RFC 1327 mapping rules have been defined, the following    convention must be followed, 
  45.  
  46.       If there are any valid addresses of the form "user@domain", then       the address "postmaster@domain" must also be valid. 
  47.  
  48.    To express this in terms of X.400:  For every X.400 domain for which    an RFC 1327 mapping rule exists, if any address of the form 
  49.  
  50.       Surname=User; <Other X.400 Address Elements> 
  51.  
  52.  
  53.  
  54.  Cargille                                                        [Page 2] 
  55.  RFC 1648              X.400 Postmaster Convention              July 1994 
  56.  
  57.     is a valid address, then the address 
  58.  
  59.       Surname=Postmaster; <Same X.400 Address Elements> 
  60.  
  61.    must also be a valid address.  If the X.400 system is running    X.400(1988), then the address 
  62.  
  63.       CommonName=Postmaster; <Same X.400 Address Elements> 
  64.  
  65.    must also be supported.  (Note that CommonName=Postmaster will not be    generated by RFC 1327 mappings, but it is recommended in the 1988    X.400 standard). 
  66.  
  67.    To remain consistent with RFC 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]. 
  68.  
  69. 3.1.  Software Limitations 
  70.  
  71.    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. 
  72.  
  73.    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 
  74.  
  75.    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. 
  76.  
  77. Security Considerations 
  78.  
  79.    Security issues are not discussed in this memo. 
  80.  
  81.  
  82.  
  83.  
  84.  
  85.  
  86.  
  87.  Cargille                                                        [Page 3] 
  88.  RFC 1648              X.400 Postmaster Convention              July 1994 
  89.  
  90.  5.  Author's Address 
  91.  
  92.    Allan Cargille    Associate Researcher    Computer Sciences Department    University of Wisconsin-Madison    1210 West Dayton Street    Madison, WI   53706   USA 
  93.  
  94.    Internet: cargille@cs.wisc.edu    X.400: S=Cargille; O=UW-Madison; OU1=cs; PRMD=xnren; ADMD= ; C=us; 
  95.  
  96.    Phone: +1 (608) 262-5084    Fax:   +1 (608) 262-9777 
  97.  
  98. 6.  References 
  99.  
  100.    [1] Crocker, D., "Standard of the Format of ARPA Internet Text        Messages", STD 11, RFC 822, UDEL, August 1982. 
  101.  
  102.    [2] Braden, R., "Requirements for Internet Hosts -- Application and        Support", STD 3, RFC 1123, USC/Information Sciences Institute,        October 1989. 
  103.  
  104.    [3] CCITT, "CCITT Recommendations X.400", Message Handling Systems:        System Model--Service Elements, 1984. 
  105.  
  106.    [4] CCITT/ISO, "CCITT Recommendations X.400/ ISO IS 10021-1", Message        Handling: System and Service Overview, December 1988. 
  107.  
  108.    [5] Kille, S., "Mapping between X.400(1988) / ISO 10021 and RFC 822",        RFC 1327, University College London, May 1992. 
  109.  
  110.    [6] Hagens, R. and A. Hansen, "Operational Requirements for X.400        Management Domains in the GO-MHS Community," ANS, UNINETT, RFC        1649, July 1994. 
  111.  
  112.    [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. 
  113.  
  114.    [8] Minutes, Cosine MHS Managers Meeting, June 1992, (unpublished). 
  115.  
  116.    [9] Crocker, D., "Standard of the Format of ARPA Internet Text        Messages", STD 11, RFC 822, UDEL, Pg. 33, August 1982. 
  117.  
  118.  
  119.  
  120.  
  121.  
  122. Cargille                                                        [Page 4] 
  123.  
  124.