RFC2142-JP.txt 2000/09/27 (initial version)
(C)JPNIC RFC-JP project, 2000. All rights reserved.
Network Working Group D. Crocker
Request for Comments: 2142 Internet Mail Consortium
Category: Standards Track May 1997
一般的なサービス、役割、機能に対するメールボックス名
本文書の位置づけ
本文書では、インターネットコミュニティに対するインターネット標準化過
程プロトコルを定義し、改良のための議論と提案を求めている。標準化の状
態と本プロトコルの状態については"Internet Official Protocol
Standards" (STD 1)の最新版を参照してほしい。本文書の配布は制限されな
い。
要約
本仕様は、組織内の担当部門とインターネットの電子メールで連絡する場合
に利用するメールアドレス(メールボックス名@ホスト参照)群について説明
している。メールボックスの名前は「管理上の機能」と「業務上の機能」の
双方を示している。ここで提示されているメールボックス名やエイリアス以
外の名前を追加するのは自由だが、インターネット上で電子メールの交換を
行う組織は"少なくとも"組織内に存在する各機能に関しては対応するメール
ボックスを利用できるようにすることがとても望ましい。
1. 解釈と適用範囲
インターネット上で新しいサービスを定義する文書にはそのサービスの管理
者に連絡するために利用するメールボックス名を定義しているものがいろい
ろと存在する。たとえば [RFC822 6.3, C.6] では、SMTPサーバが動いてい
るのすべてのホストで<POSTMASTER@domain>というメールボックス名を作る
ことを要求している。他のプロトコルでもNNTP用の<USENET@domain>
([RFC977]参照)やHTTP用の<WEBMASTER@domain>([HTTP]参照)のように、"良
く知られた"メールボックス名が事実上の標準となっていることもある。ま
た、<ABUSE@domain>や<TROUBLE@domain>などのように特定のプロトコルに依
存しないが事実上の標準になっているメールボックス名も存在している。
本文書は組織がサポートしなければならないメールボックス名を集約して基
本的なメールボックスの集合として定義することである。ここで定義されて
いるメールボックス名の全部をひとつの組織でサポートすることはあり得な
いので、ここで挙げられているメールアドレスを全部サポートする必要はな
い。しかし、本文書で挙げているサービスを提供する場合は、対応するメー
ルボックス名をサポートし、関連するサービスや役割にあった受信者に配送
するようにしなければならない。
Crocker Standards Track [Page 1]
RFC 2142 Mailbox Names May 1997
あるホストが電子メールを直接受け取れるようにはなっていないけれども本
仕様で定義しているメールボックス名に関連するサービスを提供している場
合、そのホストにはMX RR([RFC974]参照)を設定しなければならない。また、
このRRで指定されているメール交換ホスト(mail exchanger)では対応するメー
ルボックス名宛に戻ってくる失敗通知(bounce)メッセージを受け取れるよう
に、参照元のホストのドメイン名を「local」として認識する必要がある。
広告されているドメイン名がそのホストのドメイン名と異なる場合もこの規
定は適用される。たとえば、NNTPサーバのホスト名はDATA.RAMONA.VIX.COM
だが"Path:"ヘッダで通知するドメイン名はVIX.COMである場合は、
<USENET@VIX.COM>と<USENET@DATA.RAMONA.VIX.COM>の双方に対してメールを
配送できるようになっていなければならない。このとき、上記のふたつのア
ドレスは最終的には別の宛先に配送されても構わない。
良く知られているメールボックス名のスコープはドメイン名である。あるド
メインの代りに電子メールを受け取るサーバは、そのドメインのメールボッ
クスへの電子メールを受け取って正しく処理しなければならない。これはそ
のサーバ自体はそのサービスを提供していない場合も同様である。そのため、
たとえばNNTPサーバが"Path:"ヘッダ([RFC977]参照)中でその組織の最上位
レベルのドメインを通知している場合、最上位ドメインに対する電子メール
交換ホストは、そのホスト自身がNNTPプロトコルを提供していなくても
<USENET@domain>宛ての電子メールを受け取らなければならない。
2. 一様性
良く知られているが特定のプロトコルに依存しないメールボックス名に対し
ては、組織の最上位レベルのドメイン名だけで利用できればよい。たとえば、
ドメイン名がCOMPANY.COMのインターネットサービスプロバイダ(ISP)では
<ABUSE@COMPANY.COM> アドレスを有効にして利用できるようにしなければな
らない。たとえ苦情の元になった顧客がSHELL1.COMPANY.COMのようなより詳
細なドメイン名を使っていた場合でもこのアドレスが利用される。さらにい
えば、これらのサブドメインに専用のメールボックスを利用することも正し
くかつ推奨される行動である。
メールボックス名の認識は大文字/小文字を区別してはならない。たとえば、
POSTMASTER, postmaster, Postmaster, PostMasterは同じメールボックス名
を示しており、さらにはPoStMaStErでさえ同じ名前として扱われる。これら
のアドレスはどれも同じメールボックスに配送される。
このような"良く知られた"メールボックス名を実装する場合には、それらの
メールボックス名を使うであろう送信者の予想を考慮する必要がある。大抵
の場合は、自動的に電子メール受取通知を送り返すことが有用だろう(もっ
とも"メールロボットの決闘"とその結果としてのメールループの可能性には
注意する必要がある)。
Crocker Standards Track [Page 2]
RFC 2142 Mailbox Names May 1997
3. 業務に関連するメールボックス名
以下に組織の業務分野ごとの活動に関連するメールボックス名を示す。
「INFO」は多くの場合自動応答ソフトウェア宛に届いて用意されている適当
なファイルが渡されるようになっている。
メールボックス 分野 利用法
-------------- --------------- ---------------------------
INFO マーケティング 組織、製品および/またはサービス
を適切に組み合わせた情報
MARKETING マーケティング 製品のマーケティングおよび
マーケティング通信
SALES セールス 製品購入に関する情報
SUPPORT 顧客サービス 製品またはサービスに関する問題
4. ネットワーク運用に関連するメールボックス名
運用に関するアドレスは、その組織のインターネットサービスに対する難点
を経験した顧客やプロバイダなどが連絡を取り合うことを想定している。
メールボックス 分野 取り扱い
-------------- ---------------- ---------------------------
ABUSE 顧客関連 公共における不適当なふるまい
NOC ネットワーク管理 ネットワーク・インフラストラクチャ
SECURITY ネットワーク セキュリティに関する報告
セキュリティ または問い合わせ
5. 特定のインターネットサービスをサポートするメールボックス名
主なインターネットプロトコルによるサービスについては、問い合わせや報
告を受け取るためのメールボックスが定義されている。(以下の例には広範
囲に使われている異名も含まれている。)
メールボックス サービス 仕様
-------------- -------------- ---------------------------
POSTMASTER SMTP [RFC821], [RFC822]
HOSTMASTER DNS [RFC1033-RFC1035]
USENET NNTP [RFC977]
NEWS NNTP USENETの異名
WEBMASTER HTTP [RFC 2068]
WWW HTTP WEBMASTERの異名
UUCP UUCP [RFC976]
FTP FTP [RFC959]
Crocker Standards Track [Page 3]
RFC 2142 Mailbox Names May 1997
6. メーリングリスト管理に関連するメールボックス名
メーリングリストには、加入要求/脱退要求やその他の一般的な問い合わせ
を送付するための管理用メールボックス名がある。
メーリングリスト宛にメッセージを送るためのアドレスが
<LIST@DOMAIN>
の場合、管理用のメールボックス名は
<LIST-REQUEST@DOMAIN>
でなければならない(MUST)。
MajorDomoやListservなどのメーリングリスト管理ソフトウェアには、その
システムで運用されている個別のメーリングリストに対してだけではなくそ
のソフトウェア宛のメールボックス名(通常はソフトウェア名)も用意されて
いる。このようなメールボックス名ではサイトで採用しているメーリングリ
スト用ソフトウェアの種類を知らなければ管理用アドレスにメールを送れな
いので問題である。それゆえ、
全般的なメーリングリスト用ソフトウェアに対するメールボックス名を
利用できるかには関係なくメーリングリスト専用(LIST-REQUEST)の
メールボックス名が必要
ということになる。
7. ドメイン名サービス管理に関連するメールボックス名
DNS([RFC1033]、[RFC1034]、[RFC1035]参照)では、Start Of Authorityレコー
ド(SOA RR)にそのゾーンの管理者のメールボックス名を指定するためのフィー
ルドが用意されている。
このフィールドはメタ文字(「%」、「!」、「::」など)を使わない単語でな
ければならない。また、対応するメール交換ホストではゾーン管理者宛のメー
ルから適切なメールボックスへのエイリアスを作成しておくべきである。
メールボックス名を単純で規則的にするため、HOSTMASTERという"良く知ら
れた"メールボックス名を使って<HOSTMASTER@domain>というアドレスにする
ことが強く推奨される。
Crocker Standards Track [Page 4]
RFC 2142 Mailbox Names May 1997
8. 自律システム(AS)に関したメールボックス名
インターネットレジストリの中には、自律システムに連絡するためのメーリ
ングリストを実装しているものがある。たとえば<AS3557@RA.NET>に電子メー
ルを送ると本文書を書いている時点ではBGP4内の自律システム(AS)3557用の
技術関連の連絡先に配送される([RFC1654]、[RFC1655]、[RFC1656]参照)。
しかし、すべての自律システムがすべてのレジストリに登録されているわけ
ではない。そのため、この機構の下で配送できないメールボックス名があっ
たとしてもエラーや標準違反として扱うのではなく単に不便な状態として扱
うべきである。
9. セキュリティに関する考察
本文書が標準となれば多くのシステムで同一のメールボックス名を利用する
ことになるので、サービス不能攻撃(メールボックスにジャンクメールを多
数送りつけるなど)が容易になってしまう。
10. 参考文献
[RFC821] Postel, J., "Simple Mail Transfer Protocol", STD 10, RFC
821, Information Sciences Institute, August 1982.
[RFC822] Crocker, D., "Standard for the format of ARPA Internet text
messages", STD 11, RFC 822, University of Delaware, August 1982.
[RFC959] Postel, J., and J. Reynolds, "File Transfer Protocol (FTP)",
STD 9, RFC 959, Information Sciences Institute, October 1985.
[RFC974] Partridge, C., "Mail routing and the domain system", STD 14,
RFC 974, CSNET CIC BBN Laboratories Inc, January 1986.
[RFC976] Horton, M., "UUCP mail interchange format standard", RFC
976, Bell Laboratories, February 1986.
[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.
[RFC1033] Lottor, M., "Domain administrators operations guide", RFC
1033, SRI International, November 1987.
[RFC1034] Mockapetris, P., "Domain names - concepts and facilities",
STD 13, RFC 1035, USC/Information Sciences Institute, November 1987.
Crocker Standards Track [Page 5]
RFC 2142 Mailbox Names May 1997
[RFC1035] Mockapetris, P., "Domain Names - Implementation and
Specification" STD 13, RFC 1035, USC/Information Sciences Institute,
November 1987.
[RFC1654] Rekhter, Y., et al, "A Border Gateway Protocol 4 (BGP- 4)",
RFC 1654, T.J. Watson Research Center, IBM Corp., July 1994.
[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.
[RFC1656] Traina, P., "BGP-4 Protocol Document Roadmap and
Implementation Experience", RFC 1656, cisco Systems, July 1994.
[HTTP] Berners-Lee, T., et al, "Hypertext Transfer Protocol --
HTTP/1.0", RFC 1945, May 1996.
11. 謝辞
本仕様の元となった草稿はPaul Vixieによって書かれた。Stan Barber、
Michael Dillon、James Aldridge、J. D. Falk、Peter Kaminski、Brett
Watson、Russ Wright、Neal McBurnett、Ed Morinに対し、この草稿にコメ
ントしてくれたことを感謝する。
12. 著者連絡先
Dave Crocker
Internet Mail Consortium
127 Segre Ave.
Santa Cruz, CA
Phone: +1 408 246 8253
EMail: dcrocker@imc.org
Crocker Standards Track [Page 6]
RFC-JP日本語翻訳物の著作権に関する告知
本文書は、インターネット技術の正しい普及と振興を目的として、社団法人
日本ネットワークインフォメーションセンター(JPNIC)が行っているRFC翻訳
プロジェクト(RFC-JP)の成果物である。rfc-copyright-storyに従い、
RFC2220以降のものについては“Full Copyright Statement”を含め、
RFC2219以前のものについては原著者の了解を得て翻訳している。これによ
り作成された二次的著作物である本文書の著作権はJPNICが保持するが、こ
の権利の設定は原文から新たな翻訳を作成し公開することを妨げるものでは
ない。
また、RFC-JPとしてこの文書に記載された情報の内容が正確であることに努
めているが、正確性を含めいっさいの品質についてこれを保証するものでは
ない。したがって、この文書に記載された情報に基づいて貴方あるいは貴組
織がとられた行動によって引き起こされる結果に対して、JPNICは何ら保証
を与えない。
本文書は、本著作権表示を含めて改変しないことを条件に再配布を許可する。
ただし日本語訳は固定ではなく、誤りの発見や正確性の向上のために必要に
応じて適宜更新される可能性がある。常に最新の版を入手するようにしてい
ただきたい。最新版は<URL:http://rfc-jp.nic.ad.jp/>から入手できる。
JPNICはインターネットの円滑な運営を支えるための組織です
- JPNIC
-
IPアドレス・AS番号
指定事業者向け各種申請手続/お知らせ
一般ユーザーの方
-
JPNIC会員
会員向け情報/各種変更手続
入会のご案内
