RFC2142 日本語訳

2142 Mailbox Names for Common Services, Roles and Functions. D.Crocker. May 1997. (Format: TXT=12195 bytes) (Status: PROPOSED STANDARD)
プログラムでの自動翻訳です。
英語原文

Network Working Group                                        D. Crocker
Request for Comments: 2142                     Internet Mail Consortium
Category: Standards Track                                      May 1997

コメントを求めるワーキンググループD.医者要求をネットワークでつないでください: 2142年のインターネットメール共同体カテゴリ: 標準化過程1997年5月

                             MAILBOX NAMES FOR
                   COMMON SERVICES, ROLES AND FUNCTIONS

共益サービス、役割、および機能のためのメールボックス名

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

要約

   This specification enumerates and describes Internet mail addresses
   (mailbox name @ host reference) to be used when contacting personnel
   at an organization.  Mailbox names are provided for both operations
   and business functions.  Additional mailbox names and aliases are not
   prohibited, but organizations which support email exchanges with the
   Internet are encouraged to support AT LEAST each mailbox name for
   which the associated function exists within the organization.

この仕様は、組織のときに人員に連絡するとき、使用されるために、インターネット郵便の宛先(メールボックス名前@ホスト参照)を列挙して、説明します。 操作とビジネス機能の両方にメールボックス名を提供します。 追加メールボックス名と別名は禁止されていませんが、メールがインターネットとの交換であるとサポートする組織が、AT LEASTが関連機能が組織の中に存在するそれぞれのメールボックス名であるとサポートするよう奨励されます。

1.  RATIONALE AND SCOPE

1. 原理と範囲

   Various Internet documents have specified mailbox names to be used
   when reaching the operators of the new service; for example, [RFC822
   6.3, C.6] requires the presence of a <POSTMASTER@domain> mailbox name
   on all hosts that have an SMTP server.  Other protocols have defacto
   standards for well known mailbox names, such as <USENET@domain> for
   NNTP (see [RFC977]), and <WEBMASTER@domain> for HTTP (see [HTTP]).
   Defacto standards also exist for well known mailbox names which have
   nothing to do with a particular protocol, e.g., <ABUSE@domain> and
   <TROUBLE@domain>.

新しくサービスのオペレータに届くとき、様々なインターネットドキュメントは使用されるためにメールボックス名を指定しました。 例えば、[RFC822 6.3、C.6]が存在に a <POSTMASTER@domain を要求する、gt;、メールボックスがすべてで. 他のプロトコルには事実上の規格があるSMTPサーバーを持っているホストをよく知られているメールボックス名、そのような as <USENET@domain に任命する、gt;、NNTP([RFC977]を見る)、 and <WEBMASTER@domain 、gt;、HTTP([HTTP]を見る)のために。 また、事実上の規格は特定のプロトコルと関係ないよく知られているメールボックス名のために存在しています、例えば、 <ABUSE@domain 、gt;、 and <TROUBLE@domain 、gt。

   The purpose of this memo is to aggregate and specify the basic set of
   mailbox names which organizations need to support.  Most
   organizations do not need to support the full set of mailbox names
   defined here, since not every organization will implement the all of
   the associated services.  However, if a given service is offerred,
   then the associated mailbox name(es) must be supported, resulting in
   delivery to a recipient appropriate for the referenced service or
   role.

このメモの目的は、組織がサポートする必要がある基本的なセットのメールボックス名を集めて、指定することです。 ほとんどの組織はここで定義されたメールボックス名のフルセットをサポートする必要はありません、あらゆる組織が道具を望んでいるというわけではないので関連サービスのすべて。 しかしながら、与えられたサービスがofferredされるなら、関連メールボックス名(es)をサポートしなければなりません、参照をつけられたサービスか役割に、適切な受取人への配送をもたらして。

Crocker                     Standards Track                     [Page 1]

RFC 2142                     Mailbox Names                      May 1997

医者規格は1997年5月にRFC2142メールボックス名を追跡します[1ページ]。

   If a host is not configured to accept mail directly, but it
   implements a service for which this specification defines a mailbox
   name, that host must have an MX RR set (see [RFC974]) and the mail
   exchangers specified by this RR set must recognize the referenced
   host's domain name as "local" for the purpose of accepting mail bound
   for the defined mailbox name.  Note that this is true even if the
   advertised domain name is not the same as the host's domain name; for
   example, if an NNTP server's host name is DATA.RAMONA.VIX.COM yet it
   advertises the domain name VIX.COM in its "Path:" headers, then mail
   must be deliverable to both <USENET@VIX.COM> and
   <USENET@DATA.RAMONA.VIX.COM>, even though these addresses might be
   delivered to different final destinations.

ホストが直接メールを受け入れるために構成されませんが、この仕様がメールボックス名を定義するサービスを実装するなら、そのホストはMX RRを用意ができさせなければなりません、そして、([RFC974]を見てください)このRRセットによって指定されたメール交換器は定義されたメールボックス名のためのメールが制限されていると受け入れる目的のための「地方」として参照をつけられたホストのドメイン名を認めなければなりません。 広告を出しているドメイン名がホストのドメイン名と同じでなくてもこれが本当であることに注意してください。 例えば、ドメイン名VIX.COMの広告を出す、それ、「経路:」 そして、ヘッダー、次に、メールが both <USENET@VIX.COM への提出物であるに違いない、gt;、<USENET@DATA.RAMONA.VIX.COM>、これらのアドレスは提供するかもしれませんが、異なった最終的な送付先に提供されてください。

   The scope of a well known mailbox name is its domain name.  Servers
   accepting mail on behalf of a domain must accept and correctly
   process mailbox names for that domain, even if the server, itself,
   does not support the associated service.  So, for example, if an NNTP
   server advertises the organization's top level domain in "Path:"
   headers (see [RFC977]) the mail exchangers for that top level domain
   must accept mail to <USENET@domain> even if the mail exchanger hosts
   do not, themselves, serve the NNTP protocol.

よく知られているメールボックス名の範囲はそのドメイン名です。 ドメインを代表してメールを受け入れるサーバは、受け入れて、正しくそのドメインにメールボックス名を処理しなければなりません、サーバ(それ自体)が関連サービスをサポートしないでも。 NNTPサーバがそのように、例えば中に組織のトップ・レベル・ドメインの広告を出す、「経路:」 そのトップ・レベル・ドメインへのメール交換器が受け入れなければならないヘッダー([RFC977]を見る)が to <USENET@domain に郵送する、gt;、ホストがそうしないメール交換器(自分たち)が役立っても、NNTPは議定書を作ります。

2.  INVARIANTS

2. 不変式

   For well known names that are not related to specific protocols, only
   the organization's top level domain name are required to be valid.
   For example, if an Internet service provider's domain name is
   COMPANY.COM, then the <ABUSE@COMPANY.COM> address must be valid and
   supported, even though the customers whose activity generates
   complaints use hosts with more specific domain names like
   SHELL1.COMPANY.COM.  Note, however, that it is valid and encouraged
   to support mailbox names for sub-domains, as appropriate.

関連しないよく知られている名前において、特定のプロトコル、組織だけの最上位ドメイン名が、有効になるのに必要です。 例えば、次に、 the <ABUSE@COMPANY.COM 、インターネット接続サービス業者のドメイン名がCOMPANY.COMであるならgt;、アドレスは、有効でサポートしなければなりません、活動が、より特定のドメイン名で苦情使用にホストを生成する顧客はSHELL1.COMPANY.COMが好きですが。 しかしながら、サブドメインのためにメールボックス名をサポートするのが適宜有効で奨励されていることに注意してください。

   Mailbox names must be recognized independent of character case.  For
   example, POSTMASTER, postmaster, Postmaster, PostMaster, and even
   PoStMaStEr are to be treated the same, with delivery to the same
   mailbox.

キャラクタ事件の如何にかかわらずメールボックス名を認識しなければなりません。 例えば、POSTMASTER、郵便局長(Postmaster)PostMaster、およびPoStMaStErさえ同じように扱われることになっています、同じメールボックスへの配送で。

   Implementations of these well known names need to take account of the
   expectations of the senders who will use them.  Sending back an
   automatic mail acknowledgement is usually helpful (though we suggest
   caution against the possibility of "duelling mail robots" and the
   resulting mail loops).

これらのよく知られている名前の実装は、彼らを使用する送付者への期待を考慮に入れる必要があります。 通常、自動メール承認を返送するのは役立っています(私たちが「メールロボットを決闘させます」可能性と結果として起こるメール輪に対して警告を勧めますが)。

Crocker                     Standards Track                     [Page 2]

RFC 2142                     Mailbox Names                      May 1997

医者規格は1997年5月にRFC2142メールボックス名を追跡します[2ページ]。

3.  BUSINESS-RELATED MAILBOX NAMES

3. ビジネス関連のメールボックス名

   These names are related to an organization's line-of-business
   activities.  The INFO name is often tied to an autoresponder, with a
   range of standard files available.

これらの名前は組織の業種活動に関連します。 さまざまな標準ファイルが利用可能な状態でINFO名はしばしばautoresponderに結ばれます。

   MAILBOX        AREA                USAGE
   -----------    ----------------    ---------------------------
   INFO           Marketing           Packaged information about the
                                      organization, products, and/or
                                      services, as appropriate
   MARKETING      Marketing           Product marketing and
                                      marketing communications
   SALES          Sales               Product purchase information
   SUPPORT        Customer Service    Problems with product or
                                      service

メールボックス領域用法----------- ---------------- --------------------------- 適切なマーケティングマーケティングProductマーケティングとマーケティング・コミュニケーションSALES Sales Product購買情報SUPPORT顧客サービスProblemsとしての製品かサービスによる組織、製品、そして/または、サービスのINFOマーケティングPackaged情報

4.  NETWORK OPERATIONS MAILBOX NAMES

4. ネットワークオペレーションメールボックス名

   Operations addresses are intended to provide recourse for customers,
   providers and others who are experiencing difficulties with the
   organization's Internet service.

操作アドレスが組織のインターネットのサービスにおける苦境に陥っている顧客、プロバイダー、および他のものに償還請求を提供することを意図します。

   MAILBOX        AREA                USAGE
   -----------    ----------------    ---------------------------
   ABUSE          Customer Relations  Inappropriate public behaviour
   NOC            Network Operations  Network infrastructure
   SECURITY       Network Security    Security bulletins or queries

メールボックス領域用法----------- ---------------- --------------------------- 公共のABUSEのNOCネットワークオペレーションNetworkインフラストラクチャSECURITY Network Security Security苦情処理係Inappropriateふるまい報告か質問

5.  SUPPORT MAILBOX NAMES FOR SPECIFIC INTERNET SERVICES

5. 特定のインターネットサービスのためにメールボックス名をサポートしてください。

   For major Internet protocol services, there is a mailbox defined for
   receiving queries and reports.  (Synonyms are included, here, due to
   their extensive installed base.)

主要なインターネットプロトコルサービスのために、質問とレポートを受け取るために定義されたメールボックスがあります。 (同義語はそれらの大規模なインストールされたベースのためここに含まれています。)

   MAILBOX        SERVICE             SPECIFICATIONS
   -----------    ----------------    ---------------------------
   POSTMASTER     SMTP                [RFC821], [RFC822]
   HOSTMASTER     DNS                 [RFC1033-RFC1035]
   USENET         NNTP                [RFC977]
   NEWS           NNTP                Synonym for USENET
   WEBMASTER      HTTP                [RFC 2068]
   WWW            HTTP                Synonym for WEBMASTER
   UUCP           UUCP                [RFC976]
   FTP            FTP                 [RFC959]

メールボックスサービス仕様----------- ---------------- --------------------------- 郵便局長SMTP[RFC821]、ウェブマスターUUCP UUCP[RFC976]FTP FTPのためのUSENETウェブマスターHTTP[RFC2068]WWW HTTP同義語のための[RFC822]HOSTMASTER DNS[RFC1033-RFC1035]USENET NNTP[RFC977]ニュースNNTP同義語[RFC959]

Crocker                     Standards Track                     [Page 3]

RFC 2142                     Mailbox Names                      May 1997

医者規格は1997年5月にRFC2142メールボックス名を追跡します[3ページ]。

6.  MAILING LIST ADMINISTRATION MAILBOX

6. メーリングリスト管理メールボックス

   Mailing lists have an administrative mailbox name to which add/drop
   requests and other meta-queries can be sent.

メーリングリストには、要求を加えるか、または下げてください。そうすれば、他のメタ質問を送ることができる管理メールボックス名があります。

   For a mailing list whose submission mailbox name is:

服従メールボックス名があるメーリングリストのために:

      <LIST@DOMAIN>

<リスト@DOMAIN>。

   there MUST be the administrative mailbox name:

管理メールボックス名があるに違いありません:

      <LIST-REQUEST@DOMAIN>

<リスト要求@DOMAIN>。

   Distribution List management software, such as MajorDomo and
   Listserv, also have a single mailbox name associated with the
   software on that system -- usually the name of the software -- rather
   than a particular list on that system.  Use of such mailbox names
   requires participants to know the type of list software employed at
   the site.  This is problematic.  Consequently:

また、MajorDomoやリストサーブなどの分配List管理ソフトウェアには、そのシステムの上の特定のリストよりむしろそのシステム(通常ソフトウェアの名前)の上のソフトウェアに関連しているただ一つのメールボックス名があります。 そのようなメールボックス名の使用は、関係者がサイトで使われたリストソフトウェアのタイプを知るのを必要とします。 これは問題が多いです。 その結果:

      LIST-SPECIFIC (-REQUEST) MAILBOX NAMES ARE REQUIRED,
      INDEPENDENT OF THE AVAILABILITY OF GENERIC LIST SOFTWARE
      MAILBOX NAMES.

リスト特有の(要求)メールボックス名がジェネリックリストソフトウェアメールボックス名の有用性の如何にかかわらず必要です。

7.  DOMAIN NAME SERVICE ADMINISTRATION MAILBOX

7. ドメイン名サービス管理メールボックス

   In DNS (see [RFC1033], [RFC1034] and [RFC1035]), the Start Of
   Authority record (SOA RR) has a field for specifying the mailbox name
   of the zone's administrator.

DNS([RFC1033]、[RFC1034]、および[RFC1035]を見る)では、Start Of Authority記録(SOA RR)はゾーンの管理者のメールボックス名を指定するための分野を持っています。

   This field must be a simple word without metacharacters (such as "%"
   or "!" or "::"), and a mail alias should be used on the relevant mail
   exchanger hosts to direct zone administration mail to the appropriate
   mailbox.

または、「この分野がメタキャラクタがなければ簡単な単語であるに違いない、(「%」か“!"、」、:、:、」、)、そして、別名が使用されるべきである関連メール交換器がゾーン管理メールを適切なメールボックスに向けるためにホスティングするaメール。

   For simplicity and regularity, it is strongly recommended that the
   well known mailbox name HOSTMASTER always be used
   <HOSTMASTER@domain>.

簡単さと規則性において、HOSTMASTERというよく知られているメールボックス名がいつも used <HOSTMASTER@domain であることが強く推薦される、gt。

Crocker                     Standards Track                     [Page 4]

RFC 2142                     Mailbox Names                      May 1997

医者規格は1997年5月にRFC2142メールボックス名を追跡します[4ページ]。

8.  AUTONOMOUS SYSTEM MAILBOX

8. 自律システムメールボックス

   Several Internet registries implement mailing lists for Autonomous
   System contacts.  So, for example, mail sent to <AS3557@RA.NET> will
   at the time of this writing reach the technical contact for
   Autonomous System 3557 in the BGP4 (see [RFC1654], [RFC1655] and
   [RFC1656]).

いくつかのインターネット登録が、Autonomous Systemのためのメーリングリストが接触であると実装します。 そのように、例えば、郵便配達人が to <AS3557@RA.NET を送った、gt;、この書くこと時点で、BGP4でAutonomous System3557の技術連絡担当者に届くでしょう([RFC1654]、[RFC1655]、および[RFC1656]を見てください)。

   Not all Autonomous Systems are registered with all registries,
   however, and so undeliverable mailbox names under this scheme should
   be treated as an inconvenience rather than as an error or a standards
   violation.

すべてのAutonomous Systemsがどんなしかしながら、すべての登録に登録されていて非常に「非-提出物」であるというわけではないので、この体系の下におけるメールボックス名は誤りか規格違反としてというよりむしろ不便として扱われるべきです。

9.  SECURITY CONSIDERATIONS

9. セキュリティ問題

   Denial of service attacks (flooding a mailbox with junk) will be
   easier after this document becomes a standard, since more systems
   will support the same set of mailbox names.

このドキュメントが規格になった後にサービス不能攻撃(くずでメールボックスをあふれさせる)は、より簡単になるでしょう、より多くのシステムが同じセットのメールボックス名をサポートするので。

10. REFERENCES

10. 参照

   [RFC821] Postel, J., "Simple Mail Transfer Protocol", STD 10, RFC
   821, Information Sciences Institute, August 1982.

[RFC821] ポステル、J.、「簡単なメール転送プロトコル」、STD10、RFC821、科学が設ける情報、1982年8月。

   [RFC822] Crocker, D., "Standard for the format of ARPA Internet text
   messages", STD 11, RFC 822, University of Delaware, August 1982.

[RFC822] クロッカー、D.、「ARPAインターネット・テキスト・メッセージの形式の規格」、STD11、RFC822、デラウエア大学(1982年8月)。

   [RFC959] Postel, J., and J. Reynolds, "File Transfer Protocol (FTP)",
   STD 9, RFC 959, Information Sciences Institute, October 1985.

[RFC959] ポステル、J.とJ.レイノルズ、「ファイル転送プロトコル(FTP)」、STD9、RFC959、科学が設ける情報、1985年10月。

   [RFC974] Partridge, C., "Mail routing and the domain system", STD 14,
   RFC 974, CSNET CIC BBN Laboratories Inc, January 1986.

[RFC974] ヤマウズラ、C.が「ルーティングとドメインシステムを郵送する」、STD14、RFC974、CSNET CIC BBN研究所Inc、1月1986日

   [RFC976] Horton, M., "UUCP mail interchange format standard", RFC
   976, Bell Laboratories, February 1986.

[RFC976] ホートン、M.、「UUCPメール置き換え形式規格」、RFC976、ベル研究所、1986年2月。

   [RFC977] Kantor, B., et al, "Network News Transfer Protocol: A
   Proposed Standard for the Stream-Based Transmission of News", RFC
   977, University of California, February 1986.

[RFC977] カンター、B.、他、「ネットニュース転送は以下について議定書の中で述べます」。 「ニュースのストリームベースの伝達の提案された標準」、RFC977、カリフォルニア大学、1986年2月。

   [RFC1033] Lottor, M., "Domain administrators operations guide", RFC
   1033, SRI International, November 1987.

[RFC1033] Lottor、M.、「操作が誘導するドメイン管理者」、RFC1033、SRIインターナショナル、1987年11月。

   [RFC1034] Mockapetris, P., "Domain names - concepts and facilities",
   STD 13, RFC 1035, USC/Information Sciences Institute, November 1987.

[RFC1034]Mockapetris、P.、「ドメイン名--、概念と施設、」、STD13、RFC1035、USC/情報Sciences Institute、11月1987日

Crocker                     Standards Track                     [Page 5]

RFC 2142                     Mailbox Names                      May 1997

医者規格は1997年5月にRFC2142メールボックス名を追跡します[5ページ]。

   [RFC1035] Mockapetris, P., "Domain Names - Implementation and
   Specification" STD 13, RFC 1035, USC/Information Sciences Institute,
   November 1987.

[RFC1035]Mockapetris、P.、「ドメイン名--STD13、USC/情報科学が1987年11月に設けるRFC実装と仕様」1035。

   [RFC1654] Rekhter, Y., et al, "A Border Gateway Protocol 4 (BGP- 4)",
   RFC 1654, T.J. Watson Research Center, IBM Corp., July 1994.

[RFC1654] Rekhter、Y.、他、「ボーダ・ゲイトウェイ・プロトコル4(BGP4)」、RFC1654、T.J.ワトソン研究所、IBM社(1994年7月)。

   [RFC1655] Rekhter, Y., et al, "Application of the Border Gateway
   Protocol in the Internet", RFC 1655, T.J. Watson Research Center, IBM
   Corp., July 1994.

[RFC1655] Rekhter、Y.、他、「インターネットでのボーダ・ゲイトウェイ・プロトコルの応用」、RFC1655、T.J.ワトソン研究所、IBM社(1994年7月)。

   [RFC1656] Traina, P., "BGP-4 Protocol Document Roadmap and
   Implementation Experience", RFC 1656, cisco Systems, July 1994.

[RFC1656] Traina、P.、「BGP-4プロトコルは道路地図と実装経験を記録する」RFC1656、コクチマスSystems、1994年7月。

   [HTTP] Berners-Lee, T., et al, "Hypertext Transfer Protocol --
   HTTP/1.0", RFC 1945, May 1996.

[HTTP] バーナーズ・リー、T.、他、「HTTP/1インチ、RFC1945、1996年ハイパーテキスト転送プロトコル--5月。」

11. ACKNOWLEDGEMENTS

11. 承認

   This specification derived from an earlier draft written by Paul
   Vixie.  Thanks to Stan Barber, Michael Dillon, James Aldridge, J.  D.
   Falk, Peter Kaminski, Brett Watson, Russ Wright, Neal McBurnett, and
   Ed Morin for their comments on that draft.

この仕様がポールVixieによって書かれた以前の草稿に由来していました。 その草稿の彼らのコメントをスタン・バーバー、マイケル・ディロン、ジェームス・オルドリッジ、J.D.フォーク、ピーター・カミンスキ、ブレット・ワトソン、ラス・ライト、ニールMcBurnett、およびエド・モーリンをありがとうございます。

12. AUTHOR'S ADDRESS

12. 作者のアドレス

   Dave Crocker
   Internet Mail Consortium
   127 Segre Ave.
   Santa Cruz, CA

デーヴ医者インターネットメール共同体127セグレAve。 サンタクルス(カリフォルニア)

   Phone: +1 408 246 8253
   EMail: dcrocker@imc.org

以下に電話をしてください。 +1 8253年の408 246メール: dcrocker@imc.org

Crocker                     Standards Track                     [Page 6]

医者標準化過程[6ページ]

一覧

 RFC 1〜100  RFC 1401〜1500  RFC 2801〜2900  RFC 4201〜4300 
 RFC 101〜200  RFC 1501〜1600  RFC 2901〜3000  RFC 4301〜4400 
 RFC 201〜300  RFC 1601〜1700  RFC 3001〜3100  RFC 4401〜4500 
 RFC 301〜400  RFC 1701〜1800  RFC 3101〜3200  RFC 4501〜4600 
 RFC 401〜500  RFC 1801〜1900  RFC 3201〜3300  RFC 4601〜4700 
 RFC 501〜600  RFC 1901〜2000  RFC 3301〜3400  RFC 4701〜4800 
 RFC 601〜700  RFC 2001〜2100  RFC 3401〜3500  RFC 4801〜4900 
 RFC 701〜800  RFC 2101〜2200  RFC 3501〜3600  RFC 4901〜5000 
 RFC 801〜900  RFC 2201〜2300  RFC 3601〜3700  RFC 5001〜5100 
 RFC 901〜1000  RFC 2301〜2400  RFC 3701〜3800  RFC 5101〜5200 
 RFC 1001〜1100  RFC 2401〜2500  RFC 3801〜3900  RFC 5201〜5300 
 RFC 1101〜1200  RFC 2501〜2600  RFC 3901〜4000  RFC 5301〜5400 
 RFC 1201〜1300  RFC 2601〜2700  RFC 4001〜4100  RFC 5401〜5500 
 RFC 1301〜1400  RFC 2701〜2800  RFC 4101〜4200 

スポンサーリンク

基本的な特徴

ホームページ製作・web系アプリ系の製作案件募集中です。

上に戻る