RFC1648 日本語訳

Network Working Group                                        A. Cargille
Request for Comments: 1648                       University of Wisconsin
Category: Standards Track                                      July 1994

Cargilleがコメントのために要求するワーキンググループA.をネットワークでつないでください: 1648年のウィスコンシン大学カテゴリ: 標準化過程1994年7月

               Postmaster Convention for X.400 Operations

X.400操作のための郵便局長コンベンション

Status of this Memo

この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.

このドキュメントは、インターネットコミュニティにインターネット標準化過程プロトコルを指定して、改良のために議論と提案を要求します。 このプロトコルの標準化状態と状態への「インターネット公式プロトコル標準」(STD1)の現行版を参照してください。 このメモの分配は無制限です。

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 registered RFC 1327 mapping rules, and which therefore appear to
   have normal RFC822-style addresses.

STD11、RFC822[1]とSTD3の両方、RFC1123[2](ホストRequirements)は「郵便局長」というEメールアドレスがすべてのホストでサポートされるのを必要とします。 この紙はRFC1327配置規則を登録して、したがって正常なRFC822-スタイルアドレスを持っているように見えるX.400メール・ドメインにこの概念について敷衍しています。

1.  Postmaster Convention in RFC822

1. RFC822の郵便局長コンベンション

   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.

信頼できて、大規模な電子メール(メール)ネットワークを経営するのは多くのメールマネージャとシステム管理者との協力を必要とします。 RFC822[1]に述べられるように、しばしば、メールかシステム・マネージャが、リモートホストでそのホストでどんな特定のユーザ名やアドレスも知らないで責任者に連絡できる必要があります。 その理由で、RFC822とインターネットHost Requirements[2]の両方が、アドレス「郵便局長」がすべてのインターネット・ホストでサポートされるのを必要とします。

2.  Postmaster Convention and X.400

2. 郵便局長コンベンションと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 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.

しかしながら、RFC822はインターネットで使用される唯一のメールプロトコルではありません。 また、いくつかのインターネット・サイトがX.400(1984)[3]とX.400(1988)[4]メールプロトコルを実行しています。 RFC1327はX.400とRFCの間で822のアドレス[5]を写像する方法を指定します。 配置規則が使用されているとき、アドレスはX.400とRFCの間で清潔に822を写像します。 事実上、それは受取人がRFC822メールユーザかX.400メールユーザであることにかかわらずアドレスを点検しながら自決するのが不可能です。

   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

ロブHagensとアルフ・ハンセンによる論文は「グローバルな開いているMHS共同体」(GO-MHS)[6]として知られているX.400共同体について説明します。 GO-MHS Communityの多くのメール・ドメインがRFC1327配置規則を登録しました。 したがって、それらのドメインのユーザには、RFCの822スタイルのメールがあります。

Cargille                                                        [Page 1]

RFC 1648              X.400 Postmaster Convention              July 1994

Cargille[1ページ]RFC1648X.400郵便局長コンベンション1994年7月

   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.

アドレス、およびこれらのメールドメインはそうです。RFC822インターネットの論理的な拡大。 ユーザがRFC822メールかX.400メールを受け取るかどうかユーザのアドレスを点検することによって言うのは不可能です。

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

これらのアドレスが標準のRFC822アドレスであるように見えるので、メールマネージャ、メーリングリストマネージャ、ホスト管理者、およびユーザは、単に" postmaster@domain "にメールを送ることができて、責任があるパーティーにメッセージを提供させると予想します。 1327年のRFC配置規則が存在するとき、左側「郵便局長」において、対応するX.400アドレス要素は「姓=郵便局長」(1984と1988年の両方)です。 しかしながら、どちらもX.400プロトコル、X.400 Implementorの北アメリカAgreements[7]、およびもう片方の地方のX.400作成者の協定は、「姓=郵便局長」と「CommonNameは郵便局長と等しいこと」がサポートされるのを必要とします。 (これらのアドレスをサポートするのは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 RFC 822 mail world and the mapped X.400
   domain has not been achieved.

郵便局長アドレスが(es)であるとサポートしない写像しているX.400ドメインに、これは、" user@some.place.zz "などのアドレスが有効であるかもしれないことを意味します、しかし、対応するアドレス" postmaster@some.place.zz "へのメールは失敗します。 これは、リモート管理者とユーザにとっていらだたしく、運転上の問題が伝えられて、決議されているのを防ぐことができます。 この場合、インターネットRFC822メール世界と写像しているX.400ドメインの必要なシームレス統合は達成されていません。

   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.

Cosine MHS Projectに参加するX.400メールマネージャは1992年6月の[8]のミーティングでこの問題について議論しました。 議論はこれらがユーザアドレスであるアドレス階層構造のどんなレベルでも郵便局長アドレスをサポートする必要性を認識しました。 しかしながら、グループは、郵便局長アドレスをO/R Address木のあるレベルまでサポートするのを必要としただけです。 このアプローチはそれのすべてではなく、問題の一部を解決しました。 より完全なソリューションが必要です。

3.  Proposed Solution

3. 提案されたソリューション

   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,

どのRFCのためにメールドメインの必要なシームレス統合を完全に達成するかために、1327の配置規則が定義されて、以下のコンベンションに続かなければなりません。

      If there are any valid addresses of the form "user@domain", then
      the address "postmaster@domain" must also be valid.

また、何かフォーム" user@domain "の有効なアドレスがあれば、アドレス" postmaster@domain "も有効であるに違いありません。

   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

X.400に関してこれを言い表すために: RFC1327配置規則がフォームのどんなアドレスであるならも存在するあらゆるX.400ドメインに

      Surname=User; <Other X.400 Address Elements>

姓はユーザと等しいです。 他のX.400が要素>を扱う<。

Cargille                                                        [Page 2]

RFC 1648              X.400 Postmaster Convention              July 1994

Cargille[2ページ]RFC1648X.400郵便局長コンベンション1994年7月

   is a valid address, then the address

そして、有効なアドレス、アドレスです。

      Surname=Postmaster; <Same X.400 Address Elements>

姓は郵便局長と等しいです。 <の同じX.400アドレス要素>。

   must also be a valid address.  If the X.400 system is running
   X.400(1988), then the address

また、有効なアドレスにならなければならなくなってください。 X.400システムであるなら、次に、X.400(1988)を実行するのは、アドレスですか?

      CommonName=Postmaster; <Same X.400 Address Elements>

CommonNameは郵便局長と等しいです。 <の同じX.400アドレス要素>。

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

また、サポートしなければなりません。 (CommonName=郵便局長がRFC1327マッピングによって生成されませんが、それが1988年のX.400規格でお勧めであることに注意します。)

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

RFC822と一致していたままで残るためには、「そのアドレスに送られたメールはサイトのメールシステムに責任がある人、または、一般的なサイト操作への責任をもっている人に発送されることです」。 [9].

3.1.  Software Limitations

3.1. ソフトウェア制限

   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.

ソフトウェアがこの要件をサポートすることができないなら、それはアップグレードするべきです。 X.400ソフトウェア開発者は、推進がメールであると製品の中の集結された郵便局長メールボックスにサポートするよう強く奨励されて、要求されています。

   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.

推進が郵便局長メールであると回避策ソリューションを適用することによって明らかにそれをサポートしないソフトウェアパッケージの中央のメールボックスにサポートするのは可能であるかもしれません。 例えば、いくつかのパッケージが、作成が「郵便局長」への必要な集結された郵便局長メールボックスを示す1つのエントリーを持っているメーリングリストであるとサポートします。 あるいはまた、X.400 Autoforwardingの特徴を使用する郵便局長アドレスをサポートするのは可能であるかもしれません。 また、ソフトウェアパッケージは、書き直しがアドレスであるとある他の方法でサポートするかもしれません。

4.  Acknowledgements

4. 承認

   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.

このドキュメントはIETF OSI X.400 Operations作業部会からの議論とコメントの成果です。 また、ヨーロッパ人のMHSマネージャから有用な入力を受け取りました。 マルコKaittolaとエリックLawaetzのおかげで、良い批評と役立っている議論において、特別です。

Security Considerations

セキュリティ問題

   Security issues are not discussed in this memo.

このメモで安全保障問題について議論しません。

Cargille                                                        [Page 3]

RFC 1648              X.400 Postmaster Convention              July 1994

Cargille[3ページ]RFC1648X.400郵便局長コンベンション1994年7月

5.  Author's Address

5. 作者のアドレス

   Allan Cargille
   Associate Researcher
   Computer Sciences Department
   University of Wisconsin-Madison
   1210 West Dayton Street
   Madison, WI   53706   USA

アランCargilleはウィスコンシン-マディソン・1210のWestデイトン通りウィスコンシン53706マディソン(米国)の研究者コンピューターサイエンシズ部の大学を関連づけます。

   Internet: cargille@cs.wisc.edu
   X.400: S=Cargille; O=UW-Madison; OU1=cs; PRMD=xnren; ADMD= ; C=us;

インターネット: cargille@cs.wisc.edu X.400: S=Cargille。 O=UW-マディソン。 OU1はCsと等しいです。 PRMD=xnren。 ADMD=。 Cは私たちと等しいです。

   Phone: +1 (608) 262-5084
   Fax:   +1 (608) 262-9777

以下に電話をしてください。 +1 (608) 262-5084Fax: +1 (608) 262-9777

6.  References

6. 参照

   [1] Crocker, D., "Standard of the Format of ARPA Internet Text
       Messages", STD 11, RFC 822, UDEL, August 1982.

[1] クロッカー、D.、「アルパインターネットテキスト・メッセージの形式の規格」、STD11、RFC822、UDEL、1982年8月。

   [2] Braden, R., "Requirements for Internet Hosts -- Application and
       Support", STD 3, RFC 1123, USC/Information Sciences Institute,
       October 1989.

[2] ブレーデン、R.、「インターネットホストのための要件--、アプリケーションとサポート、」、STD3、RFC1123、科学が設けるUSC/情報、10月1989日

   [3] CCITT, "CCITT Recommendations X.400", Message Handling Systems:
       System Model--Service Elements, 1984.

[3]CCITT、「CCITT推薦X.400」メッセージハンドリングシステム: システムモデル--Elements、1984を修理してください。

   [4] CCITT/ISO, "CCITT Recommendations X.400/ ISO IS 10021-1", Message
       Handling: System and Service Overview, December 1988.

[4] CCITT/ISO、「CCITT推薦X.400/ ISOがそうである、100211インチ、メッセージハンドリング:、」 システムとサービス概要、1988年12月。

   [5] Kille, S., "Mapping between X.400(1988) / ISO 10021 and RFC 822",
       RFC 1327, University College London, May 1992.

[5]Kille、S.、「X.400(1988)/ISO10021とRFC822インチ、RFC1327、ユニバーシティ・カレッジロンドンの間で5月1992日を写像すること。

   [6] Hagens, R. and A. Hansen, "Operational Requirements for X.400
       Management Domains in the GO-MHS Community," ANS, UNINETT, RFC
       1649, July 1994.

[6]HagensとR.とA.ハンセン、「碁-MHS共同体のX.400管理ドメインのための操作上の要件」、ANS、UNINETT、RFC1649、1994年7月。

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

[7] 米国商務省、米国商務省標準技術局、開放型システム間相互接続プロトコル、バージョン7、版1、特別な公表500-214(1993年12月)のための安定した実装協定。

   [8] Minutes, Cosine MHS Managers Meeting, June 1992, (unpublished).

[8]分、1992年6月に(未発表)で会うコサインMHSマネージャ。

   [9] Crocker, D., "Standard of the Format of ARPA Internet Text
       Messages", STD 11, RFC 822, UDEL, Pg. 33, August 1982.

[9] クロッカー、D.、「アルパインターネットテキスト・メッセージの形式の規格」、STD11、RFC822、UDEL、Pg。 33 1982年8月。

Cargille                                                        [Page 4]

Cargille[4ページ]