draft-ietf-x400ops-postmaster-02.txt x400ops Working Group INTERNET DRAFT July 1993 Postmaster Convention for X.400 Operations Thu Jul 15 09:50:14 CDT 1993 C. Allan Cargille University of Wisconsin Allan.Cargille@cs.wisc.edu This draft document is being circulated for comment. If consensus is reached it may be submitted to the RFC editor as a Proposed Standard protocol specification, for use in X.400 in the Internet. Please send comments to the author, or to the IETF OSI X.400 Operations Working Group mailing list . This document is an Internet Draft. Internet Drafts are working documents of the Internet Engineering Task Force (IETF), its Areas, and its Working Groups. Note that other groups may also distribute working documents as Internet Drafts. Internet Drafts are draft documents valid for a maximum of six months. Internet Drafts may be updated, replaced, or obsoleted by other documents at any time. It is not appropriate to use Internet Drafts as reference material or to cite them other than as a "working draft" or "work in progress." Please check the I-D abstract listing contained in each Internet Draft directory to learn the current status of this or any other Internet Draft. Abstract: Both RFC822 and RFC1123 (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 RFC1327 mapping rules (and therefore which appear to have normal RFC822-style addresses). It also requires supporting a postmaster address at the ADMD and PRMD levels. Cargille Expires January, 1994 [Page 1] DRAFT X.400 Postmaster Convention July 1993 1. Postmaster Convention in RFC822 Operating a reliable, large-scale electronic mail (email) network requires cooperation between many mail managers and system administrators. As noted in RFC822 [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 RFC822 and the Internet Host Requirements [2] require that the address "postmaster" be supported at every Internet host. 2. Postmaster Convention and X.400 However, RFC822 is not the only email protocol being used in the Internet. Some Internet sites are also running the X.400 (1984) email protocol [3]. In the near future, the 1988 X.400 protocol is also expected to be in use [4]. RFC1327 specifies how to map between X.400 and RFC822 addresses [5]. When mapping rules are used, addresses map cleanly between X.400 and RFC822. In fact, it is impossible to determine by inspecting the address whether the recipient is an RFC822 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 registered RFC1327 mapping rules. Therefore, users in those domains have RFC822-style email addresses, and these email domains are a logical extension of the RFC822 Internet. It is impossible to tell by inspecting a user's address whether the user receives RFC822 mail or X.400 mail. Since these addresses appear to be standard RFC822 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 RFC1327 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 European X.400 Implementor's Agreements [8] 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 Internet RFC822 mail world and the mapped X.400 domain has not been achieved. Cargille Expires January, 1994 [Page 2] DRAFT X.400 Postmaster Convention July 1993 The X.400 mail managers participating in the Cosine MHS Project discussed this problem in a meeting in June 1992 [9]. 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 which RFC1327 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 an RFC1327 mapping rule exists, if any address of the form Surname=User; is a valid address, then the address Surname=Postmaster; must also be a valid address. If the X.400 system is running X.400(1988), then the address CommonName=Postmaster; must also be supported. (Note that CommonName=Postmaster will not be generated by RFC1327 mappings, but it is recommended in the 1988 X.400 standard). To remain consistent with RFC822, "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." [10] 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 workaround solutions. For example, some packages support creating a mailing list for "postmaster" which Cargille Expires January, 1994 [Page 3] DRAFT X.400 Postmaster Convention July 1993 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. Postmaster Support at the MD level Section 3 discusses the X.400 postmaster convention in terms of X.400 addresses that map into the RFC822 mail world. It is also desirable to introduce an X.400 postmaster convention that is based on the X.400 model. This convention is as follows: If addresses of the form C=xx; ADMD=yy; PRMD=zz; ... are documented in a GO-MHS Domain Document (see [11]), and if the PRMD is under the administrative control of an organization in the GO-MHS community, then the address C=xx; ADMD=yy; PRMD=zz; S=postmaster must be valid and supported. Similarly, if addresses of the form C=xx; ADMD=yy; ... are documented in a GO-MHS Domain Document, and if the ADMD is under the administrative control of an organization in the GO-MHS community, then the address C=xx; ADMD=yy; S=postmaster must be valid and supported. If the PRMD or ADMD is running X.400(88), then the address CN=Postmaster must also be valid and supported. ADMDs and PRMDs that are not under the administrative control of an organization in the GO-MHS community are also encouraged to implement this convention. 5. 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. Thanks to Marko Cargille Expires January, 1994 [Page 4] DRAFT X.400 Postmaster Convention July 1993 Kaittola, who identified software limitations in supporting postmaster. 6. Author's Information 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; Voice +1 (608) 262-5084 Fax +1 (608) 262-9777 7. References [1] RFC822 [2] RFC1123 [3] X.400 (1984) [4] X.400 (1988) [5] RFC1327 [6] presently draft-ietf-x400ops-mgtdomains-ops-04.txt [7] NIST X.400 Implementors Agreements [8] EWOS X.400 Implementors Agreements [9] Minutes from June 1992 Cosine MHS Managers Meeting [10] RFC822, direct quote [11] RFC 1465 Cargille Expires January, 1994 [Page 5]