draft-ietf-x400ops-postmaster-05.txt (ready for RFC submission)

Allan Cargille <cargille@calypso.cs.wisc.edu> Thu, 19 May 1994 19:02 UTC

Received: from ietf.nri.reston.va.us by IETF.CNRI.Reston.VA.US id aa09747; 19 May 94 15:02 EDT
Received: from CNRI.RESTON.VA.US by IETF.CNRI.Reston.VA.US id aa09743; 19 May 94 15:02 EDT
Received: from mhs-relay.cs.wisc.edu by CNRI.Reston.VA.US id aa16273; 19 May 94 15:02 EDT
Received: from calypso.cs.wisc.edu by mhs-relay.cs.wisc.edu with SMTP (PP) id <01516-0@mhs-relay.cs.wisc.edu>; Thu, 19 May 1994 14:00:11 +0000
Sender: ietf-archive-request@IETF.CNRI.Reston.VA.US
From: Allan Cargille <cargille@calypso.cs.wisc.edu>
Message-Id: <9405191859.AA14846@calypso.cs.wisc.edu>
Received: by calypso.cs.wisc.edu; Thu, 19 May 94 13:59:30 -0500
Subject: draft-ietf-x400ops-postmaster-05.txt (ready for RFC submission)
To: Internet Drafts <internet-drafts@CNRI.Reston.VA.US>, erik.huizer@surfnet.nl, klensin@infoods.unu.edu
Date: Thu, 19 May 1994 13:59:29 -0500
Cc: ietf-osi-x400ops@calypso.cs.wisc.edu, scoya@CNRI.Reston.VA.US
Organization: Univ of Wisconsin
Phone: +1 608 262-5084
Fax: +1 608 262-9777
X-Mailer: ELM [version 2.4 PL23]
Mime-Version: 1.0
Content-Type: text/plain; charset="US-ASCII"
Content-Transfer-Encoding: 7bit
Content-Length: 11466

Hello everyone,

Here is the final copy of the postmaster RFC.

I-D person, please install as draft-ietf-x400ops-postmaster-05.txt.

Erik and John, the document is ready to be submitted as a
standards-track RFC.

People can still send me editorial comments and I will incorporate
them as I work with the RFC editor.

Thanks for your help, everyone.

allan

======================================================================







          draft-ietf-x400ops-postmaster-05.txt        x400ops Working Group
          INTERNET DRAFT                                           May 1994



                     Postmaster Convention for X.400 Operations

                            Thu May 19 13:48:20 CDT 1994


                                  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
          <ietf-osi-x400ops@cs.wisc.edu>.

          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 which therefore appear
               to have normal RFC822-style addresses.





          Cargille             Expires November, 1994              [Page 1]





          DRAFT              X.400 Postmaster Convention           May 1994


          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)
          [3] and X.400 (1988) [4] email protocols.  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 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 Internet
          RFC822 mail world and the mapped X.400 domain has not been
          achieved.



          Cargille             Expires November, 1994              [Page 2]





          DRAFT              X.400 Postmaster Convention           May 1994


          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 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; <Other X.400 Address Elements>

          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 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."
          [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


          Cargille             Expires November, 1994              [Page 3]





          DRAFT              X.400 Postmaster Convention           May 1994


          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.

          5.  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

          6.  References

          [1]  Crocker, D., "Standard of the Format of ARPA Internet Text
               Messages," RFC 822, UDEL, August 1982.  Email
               DCrocker@mordor.stanford.edu.

          [2]  Braden, R., "Requirements for Internet Hosts -- Application
               and Support," RFC 1123, USC, October 1989.  Email
               Braden@isi.edu.

          [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]  RFC1327 Kille, S., "Mapping between X.400(1988) / ISO 10021
               and RFC 822," RFC 1327, University College London, May 1992.
               Email S.Kille@isode.com.

          [6]  [presently draft-ietf-x400ops-mgtdomains-ops-06.txt] Hagens,
               R. and A. Hansen, "Operational Requirements for X.400
               Management Domains in the GO-MHS Community," RFC *xxxx*,


          Cargille             Expires November, 1994              [Page 4]





          DRAFT              X.400 Postmaster Convention           May 1994


               *month* 1994.  Email Hagens@ans.net,
               Alf.Hansen@Delab.Sintef.no.

          [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]  RFC 822, page 33.











































          Cargille             Expires November, 1994              [Page 5]