RFC2476 日本語訳
2476 Message Submission. R. Gellens, J. Klensin. December 1998. (Format: TXT=30050 bytes) (Obsoleted by RFC4409) (Status: PROPOSED STANDARD)
プログラムでの自動翻訳です。
英語原文
Network Working Group R. Gellens
Request for Comments: 2476 QUALCOMM
Category: Standards Track J. Klensin
MCI
December 1998
Gellensがコメントのために要求するワーキンググループR.をネットワークでつないでください: 2476年のクアルコムカテゴリ: 標準化過程J.Klensin MCI1998年12月
Message Submission
メッセージ提案
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)の現行版を参照してください。 このメモの分配は無制限です。
Copyright Notice
版権情報
Copyright (C) The Internet Society (1998). All Rights Reserved.
Copyright(C)インターネット協会(1998)。 All rights reserved。
Table of Contents
目次
1. Abstract . . . . . . . . . . . . . . . . . . . . . . . . . . 2
2. Document Information . . . . . . . . . . . . . . . . . . . 3
2.1. Definitions of Terms Used in this Memo . . . . . . . . . 3
2.2. Conventions Used in this Document . . . . . . . . . . . 4
3. Message Submission . . . . . . . . . . . . . . . . . . . . . 4
3.1. Submission Identification . . . . . . . . . . . . . . . 4
3.2. Message Rejection and Bouncing . . . . . . . . . . . . . 4
3.3. Authorized Submission . . . . . . . . . . . . . . . . . 5
3.4. Enhanced Status Codes . . . . . . . . . . . . . . . . . 6
4. Mandatory Actions . . . . . . . . . . . . . . . . . . . . . 6
4.1. General Submission Rejection Code . . . . . . . . . . . 6
4.2. Ensure All Domains are Fully-Qualified . . . . . . . . 6
5. Recommended Actions . . . . . . . . . . . . . . . . . . . . 7
5.1. Enforce Address Syntax . . . . . . . . . . . . . . . . 7
5.2. Log Errors . . . . . . . . . . . . . . . . . . . . . . . 7
6. Optional Actions . . . . . . . . . . . . . . . . . . . . . 7
6.1. Enforce Submission Rights . . . . . . . . . . . . . . . 7
6.2. Require Authentication . . . . . . . . . . . . . . . . 8
6.3. Enforce Permissions . . . . . . . . . . . . . . . . . . 8
6.4. Check Message Data . . . . . . . . . . . . . . . . . . 8
7. Interaction with SMTP Extensions . . . . . . . . . . . . . . 8
8. Message Modifications . . . . . . . . . . . . . . . . . . . 9
8.1. Add 'Sender' . . . . . . . . . . . . . . . . . . . . . . 9
8.2. Add 'Date' . . . . . . . . . . . . . . . . . . . . . . 10
8.3. Add 'Message-ID' . . . . . . . . . . . . . . . . . . . . 10
1. 要約. . . . . . . . . . . . . . . . . . . . . . . . . . 2 2。 情報. . . . . . . . . . . . . . . . . . . 3 2.1を記録してください。 このMemo. . . . . . . . . 3 2.2とのTerms Usedの定義。 このDocument. . . . . . . . . . . 4 3のコンベンションUsed。 メッセージ提案. . . . . . . . . . . . . . . . . . . . . 4 3.1。 服従識別. . . . . . . . . . . . . . . 4 3.2。 メッセージ拒絶と弾. . . . . . . . . . . . . 4 3.3み。 認可された服従. . . . . . . . . . . . . . . . . 5 3.4。 高められた状態は.6 4をコード化します。 義務的な動作. . . . . . . . . . . . . . . . . . . . . 6 4.1。 一般服従拒絶コード. . . . . . . . . . . 6 4.2。 All DomainsがFullyが適切な.6 5であることを確実にしてください。 お勧めの動作. . . . . . . . . . . . . . . . . . . . 7 5.1。 アドレス構文. . . . . . . . . . . . . . . . 7 5.2を実施してください。 誤り. . . . . . . . . . . . . . . . . . . . . . . 7 6を登録してください。 任意の動作. . . . . . . . . . . . . . . . . . . . . 7 6.1。 服従権利. . . . . . . . . . . . . . . 7 6.2を実施してください。 認証. . . . . . . . . . . . . . . . 8 6.3を必要としてください。 許容. . . . . . . . . . . . . . . . . . 8 6.4を実施してください。 メッセージデータ. . . . . . . . . . . . . . . . . . 8 7をチェックしてください。 SMTP拡張子. . . . . . . . . . . . . . 8 8との相互作用。 メッセージ変更. . . . . . . . . . . . . . . . . . . 9 8.1。 '送付者'. . . . . . . . . . . . . . . . . . . . . . 9 8.2を加えてください。 '日付'. . . . . . . . . . . . . . . . . . . . . . 10 8.3を加えてください。 'Message ID'.10を加えてください。
Gellens & Klensin Standards Track [Page 1] RFC 2476 Message Submission December 1998
Gellens&Klensin規格はメッセージ服従1998年12月にRFC2476を追跡します[1ページ]。
8.4. Transfer Encode . . . . . . . . . . . . . . . . . . . . 10
8.5. Sign the Message . . . . . . . . . . . . . . . . . . . . 10
8.6. Encrypt the Message . . . . . . . . . . . . . . . . . . 10
8.7. Resolve Aliases . . . . . . . . . . . . . . . . . . . . 10
8.8. Header Rewriting . . . . . . . . . . . . . . . . . . . 10
9. Security Considerations . . . . . . . . . . . . . . . . . . 11
10. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . 11
11. References . . . . . . . . . . . . . . . . . . . . . . . . . 12
12. Authors' Addresses . . . . . . . . . . . . . . . . . . . . . 14
13. Full Copyright Statement . . . . . . . . . . . . . . . . . 15
8.4. エンコード. . . . . . . . . . . . . . . . . . . . 10 8.5を移してください。 メッセージ. . . . . . . . . . . . . . . . . . . . 10 8.6にサインしてください。 メッセージ. . . . . . . . . . . . . . . . . . 10 8.7をコード化してください。 別名. . . . . . . . . . . . . . . . . . . . 10 8.8を決議してください。 ヘッダーの書き直. . . . . . . . . . . . . . . . . . . 10 9し。 セキュリティ問題. . . . . . . . . . . . . . . . . . 11 10。 承認. . . . . . . . . . . . . . . . . . . . . . 11 11。 参照. . . . . . . . . . . . . . . . . . . . . . . . . 12 12。 作者のアドレス. . . . . . . . . . . . . . . . . . . . . 14 13。 完全な著作権宣言文. . . . . . . . . . . . . . . . . 15
1. Abstract
1. 要約
SMTP was defined as a message *transfer* protocol, that is, a means to route (if needed) and deliver finished (complete) messages. Message Transfer Agents (MTAs) are not supposed to alter the message text, except to add 'Received', 'Return-Path', and other header fields as required by [SMTP-MTA].
SMTPはメッセージ*転送*プロトコル(すなわち、終わっている(完全な)メッセージを発送して(必要であるなら)、送る手段)と定義されました。 メッセージTransferエージェント(MTAs)はメッセージ・テキストを変更するべきではありません、必要に応じて[SMTP-MTA]で'受け取られていてい'て、'リターン経路'の、そして、他のヘッダーフィールドを加えるのを除いて。
However, SMTP is now also widely used as a message *submission* protocol, that is, a means for message user agents (MUAs) to introduce new messages into the MTA routing network. The process which accepts message submissions from MUAs is termed a Message Submission Agent (MSA).
しかしながら、また、SMTPは現在、メッセージ*服従*プロトコル(すなわち、メッセージユーザエージェント(MUAs)がMTAルーティングネットワークに新しいメッセージを取り入れる手段)として広く使用されます。 MUAsからメッセージ差出を受け入れる過程はMessage Submissionエージェント(MSA)と呼ばれます。
Messages being submitted are in some cases finished (complete) messages, and in other cases are unfinished (incomplete) in some aspect or other. Unfinished messages need to be completed to ensure they conform to [MESSAGE-FORMAT], and later requirements. For example, the message may lack a proper 'Date' header field, and domains might not be fully qualified. In some cases, the MUA may be unable to generate finished messages (for example, it might not know its time zone). Even when submitted messages are complete, local site policy may dictate that the message text be examined or modified in some way. Such completions or modifications have been shown to cause harm when performed by downstream MTAs -- that is, MTAs after the first-hop submission MTA -- and are in general considered to be outside the province of standardized MTA functionality.
提出されるメッセージは、他の場合でいくつかの場合終わっている(完全な)メッセージであり、何らかの局面で未完成であるか(不完全な)、または他です。 未完成のメッセージは、それらが[MESSAGE-FORMAT]、および後の要件に従うのを保証するために完成される必要があります。 例えば、メッセージは適切な'日付'ヘッダーフィールドを欠くかもしれません、そして、ドメインは完全に資格があるかもしれないというわけではありません。 いくつかの場合、MUAは終わっているメッセージを発生させることができないかもしれません(例えば、それは時間帯を知らないかもしれません)。 提出されたメッセージが完全であるときにさえ、ローカル・サイト方針は、メッセージ・テキストが何らかの方法で調べられるか、または変更されると決めるかもしれません。 そのような落成か変更が、川下のMTAs(すなわち、最初に、ホップ服従MTAの後のMTAs)によって実行されると害を引き起こすために示されて、一般に、標準化されたMTAの機能性の州の外にあると考えられました。
Separating messages into submissions and transfers allows developers and network administrators to more easily:
差出と転送にメッセージを切り離すと、開発者とネットワーク管理者は、より容易に許容されます:
* Implement security policies and guard against unauthorized mail
relaying or injection of unsolicited bulk mail
* 求められていない料金別納郵便の権限のないメールリレーか注射に対して安全保障政策と警備を実行してください。
* Implement authenticated submission, including off-site submission
by authorized users such as travelers
* 旅行者などの認定ユーザによるオフサイト服従を含む認証された服従を実行してください。
Gellens & Klensin Standards Track [Page 2] RFC 2476 Message Submission December 1998
Gellens&Klensin規格はメッセージ服従1998年12月にRFC2476を追跡します[2ページ]。
* Separate the relevant software code differences, thereby making
each code base more straightforward and allowing for different
programs for relay and submission
* 関連ソフトウェアコード差を切り離してください、その結果、それぞれのコードベースをより簡単にして、リレーと服従のための異なったプログラムを考慮して
* Detect configuration problems with a site's mail clients
* サイトのメールクライアントに関する設定問題を検出してください。
* Provide a basis for adding enhanced submission services in the
future
* 将来高められた服従サービスを加える基礎を提供してください。
This memo describes a low cost, deterministic means for messages to be identified as submissions, and specifies what actions are to be taken by a submission server.
このメモは、差出として特定されるべきメッセージのために低価格、決定論的な手段を説明して、どんな動作が服従サーバによって取られるかことであるかと指定します。
Public comments should be sent to the IETF Submit mailing list, <ietf-submit@imc.org>. To subscribe, send a message containing SUBSCRIBE to <ietf-submit-request@imc.org>. Private comments may be sent to the authors.
IETF Submitメーリングリスト、 <ietf-submit@imc.org にパブリックコメントを送るべきである、gt。 申し込むために、登録、 to <ietf-submit-request@imc.org を含むメッセージを送ってください、gt。 個人的なコメントを作者に送るかもしれません。
2. Document Information
2. 文書情報
2.1. Definitions of Terms Used in this Memo
2.1. このMemoとのTerms Usedの定義
Fully-Qualified
完全に資格を得ます。
Containing or consisting of a domain which can be globally resolved using the global Domain Name Service; that is, not a local alias or partial specification.
グローバルなDomain Name Serviceを使用することでグローバルに決議できるドメインから含んでいるか、または成ります。 すなわち、ローカルの別名でない部分的な仕様でない。
Message Submission Agent (MSA)
メッセージ服従エージェント(MSA)
A process which conforms to this specification, which acts as a submission server to accept messages from MUAs, and either delivers them or acts as an SMTP client to relay them to an MTA.
MUAsからメッセージを受け入れるために服従サーバとして機能するこの仕様とどちらかに従う過程は、MTAに彼らをリレーするためにSMTPクライアントとして彼らを渡すか、または機能します。
Message Transfer Agent (MTA)
メッセージ転送エージェント(MTA)
A process which conforms to [SMTP-MTA], which acts as an SMTP server to accept messages from an MSA or another MTA, and either delivers them or acts as an SMTP client to relay them to another MTA.
MSAか別のMTAからメッセージを受け入れるためにSMTPサーバーとして機能する[SMTP-MTA]とどちらかに従う過程は、別のMTAにそれらをリレーするためにSMTPクライアントとしてそれらを渡すか、または機能します。
Message User Agent (MUA)
メッセージユーザエージェント(MUA)
A process which acts (usually on behalf of a user) to compose and submit new messages, and process delivered messages. In the split- MUA model, POP or IMAP is used to access delivered messages.
新しいメッセージを構成して、提出して、渡されたメッセージを処理するために行動する(通常ユーザを代表して)過程。 分裂MUAモデルでは、POPかIMAPが、渡されたメッセージにアクセスするのに使用されます。
Gellens & Klensin Standards Track [Page 3] RFC 2476 Message Submission December 1998
Gellens&Klensin規格はメッセージ服従1998年12月にRFC2476を追跡します[3ページ]。
2.2. Conventions Used in this Document
2.2. このDocumentのコンベンションUsed
In examples, "C:" is used to indicate lines sent by the client, and "S:" indicates those sent by the server. Line breaks within a command example are for editorial purposes only.
例で「C:」 そして、クライアントによって送られた線を示すのに使用される、「S:」 ものはサーバで発信しました。コマンドの例の中のラインブレイクが編集の目的だけのためのものであることを示します。
Examples use the 'example.net' domain.
例は'example.net'ドメインを使用します。
The key words "MUST", "MUST NOT", "SHOULD", "SHOULD NOT", and "MAY" in this document are to be interpreted as defined in [KEYWORDS].
キーワード“MUST"、「必須NOT」“SHOULD"、「」 「5月」は中[キーワード]で定義されるように本書では解釈されることになっているべきです。
3. Message Submission
3. メッセージ提案
3.1. Submission Identification
3.1. 服従識別
Port 587 is reserved for email message submission as specified in this document. Messages received on this port are defined to be submissions. The protocol used is ESMTP [SMTP-MTA, ESMTP], with additional restrictions as specified here.
ポート587はこのドキュメントにおける指定されるとしてのメールメッセージ提案のために予約されます。 このポートの上に受け取られたメッセージは、差出になるように定義されます。 使用されるプロトコルがそうである、ESMTP、[SMTP-MTA、ESMTP]、ここで指定されるとしての追加制限で。
While most email clients and servers can be configured to use port 587 instead of 25, there are cases where this is not possible or convenient. A site MAY choose to use port 25 for message submission, by designating some hosts to be MSAs and others to be MTAs.
25の代わりにポート587を使用するためにほとんどのメールクライアントとサーバを構成できますが、ケースがこれが可能でもなくて、また便利でもないところにあります。 サイトは、MTAsになるようにメッセージ提案にMSAsと他のものになるように何人かのホストを任命することによってポート25を使用するのを選ぶかもしれません。
3.2. Message Rejection and Bouncing
3.2. メッセージ拒絶と弾み
MTAs and MSAs MAY implement message rejection rules that rely in part on whether the message is a submission or a relay.
MTAsとMSAsはメッセージが服従であるか、そして、リレーに一部依存するメッセージ拒絶規則を実行するかもしれません。
For example, some sites might configure their MTA to reject all RCPT TOs for messages that do not reference local users, and configure their MSA to reject all message submissions that do not come from authorized users, based on IP address, or authenticated identity.
例えば、いくつかのサイトが、地元のユーザを参照でないのにするメッセージのためにすべてのRCPT TOsを拒絶するためにそれらのMTAを構成して、認定ユーザから来ないすべてのメッセージ差出を拒絶するために彼らのMSAを構成するかもしれません、IPアドレス、または認証されたアイデンティティに基づいて。
NOTE: It is better to reject a message than to risk sending one that is damaged. This is especially true for problems that are correctable by the MUA, for example, an invalid 'From' field.
以下に注意してください。 破損しているものを送る危険を冒すよりメッセージを拒絶するのは良いです。 MUAで修正可能な問題、例えば、無効の'From'分野に、これは特に本当です。
If an MSA is not able to determine a return path to the submitting user, from a valid MAIL FROM, a valid source IP address, or based on authenticated identity, then the MSA SHOULD immediately reject the message. A message can be immediately rejected by returning a 550 code to the MAIL FROM command.
MSAがリターンパスを有効なMAIL FROM、有効なソースIPアドレスから提出しているユーザに決定できないで、認証されたアイデンティティに基づかないなら、MSA SHOULDはすぐに、メッセージを拒絶します。 すぐに、550コードをMAIL FROMコマンドに返すことによって、メッセージを拒絶できます。
Gellens & Klensin Standards Track [Page 4] RFC 2476 Message Submission December 1998
Gellens&Klensin規格はメッセージ服従1998年12月にRFC2476を追跡します[4ページ]。
Note that a null return path, that is, MAIL FROM:<>, is permitted and MUST be accepted. (MUAs need to generate null return-path messages for a variety of reasons, including disposition notifications.)
ヌルリターンパス(すなわち、メールFROM:<>)を受入れられて、受け入れなければならないことに注意してください。 (気質通知を含んで、MUAsは、さまざまな理由でヌルリターンパスメッセージを発生させる必要があります。)
Except in the case where the MSA is unable to determine a valid return path for the message being submitted, text in this specification which instructs an MSA to issue a rejection code MAY be complied with by accepting the message and subsequently generating a bounce message. (That is, if the MSA is going to reject a message for any reason except being unable to determine a return path, it can optionally do an immediate rejection or accept the message and then mail a bounce.)
MSAが提出されるメッセージのために有効なリターンパスを決定できないケースの中を除いて、メッセージを受け入れて、次に弾みのメッセージを発生させることによって、拒絶コードを発行するようMSAに命令するこの仕様によるテキストは従われるかもしれません。 (すなわち、MSAがリターンパスを決定できないのを除いたどんな理由でもメッセージを拒絶するなら、それは、任意に即座の拒絶をするか、メッセージを受け入れて、または次に、弾みを郵送できます。)
NOTE: In the normal case of message submission, immediately rejecting the message is preferred, as it gives the user and MUA direct feedback. To properly handle delayed bounces the client MUA must maintain a queue of messages it has submitted, and match bounces to them.
以下に注意してください。 メッセージ提案の正常な場合では、すぐにメッセージを拒絶するのは好まれます、ダイレクトフィードバックをユーザとMUAに与えるとき。 クライアントMUAは、適切に遅れた弾みを扱うために、それが提出したメッセージの待ち行列を維持して、それらへの弾みに合わなければなりません。
3.3. Authorized Submission
3.3. 認可された服従
Numerous methods have been used to ensure that only authorized users are able to submit messages. These methods include authenticated SMTP, IP address restrictions, secure IP, and prior POP authentication.
多数の方法は、認定ユーザだけがメッセージを提出できるのを保証するのに使用されました。 これらの方法は認証されたSMTP、IPアドレス制限、安全なIP、および先のPOP認証を含んでいます。
Authenticated SMTP [SMTP-AUTH] has been proposed. It allows the MSA to determine an authorization identity for the message submission, which is not tied to other protocols.
認証されたSMTP[SMTP-AUTH]は提案されました。 それで、MSAはメッセージ提案のために認可のアイデンティティを決定できます。(それは、他のプロトコルに結ばれません)。
IP address restrictions are very widely implemented, but do not allow for travellers and similar situations, and can be spoofed.
IPアドレス制限を旅行者と同様の状況を考慮しないのを除いて、非常に広く実行して、だますことができます。
Secure IP [IPSEC] can also be used, and provides additional benefits of protection against eavesdropping and traffic analysis.
安全なIP[IPSEC]は雨垂れとトラヒック分析に対してまた、使用できて、保護の付加的な利益を提供します。
Requiring a POP [POP3] authentication (from the same IP address) within some amount of time (for example, 20 minutes) prior to the start of a message submission session has also been used, but this does impose restrictions on clients as well as servers which may cause difficulties. Specifically, the client must do a POP authentication before an SMTP submission session, and not all clients are capable and configured for this. Also, the MSA must coordinate with the POP server, which may be difficult. There is also a window during which an unauthorized user can submit messages and appear to be a prior authorized user.
また、メッセージ服従セッションの始まりの(例えば、20分)前にいつかの時間以内にPOP[POP3]認証(同じIPアドレスからの)を必要とするのは使用されましたが、これは困難を引き起こすかもしれないサーバと同様にクライアントに制限を課します。 明確に、すべてのクライアントではなく、SMTP服従セッションができるのとこれのために構成するようになる前にクライアントはPOP認証をしなければなりません。 また、MSAはPOPサーバで調整しなければなりません。(それは、難しいかもしれません)。 また、権限のないユーザがメッセージを提出して、先の認定ユーザであるように見えることができる窓があります。
Gellens & Klensin Standards Track [Page 5] RFC 2476 Message Submission December 1998
Gellens&Klensin規格はメッセージ服従1998年12月にRFC2476を追跡します[5ページ]。
3.4. Enhanced Status Codes
3.4. 高められたステータスコード
This memo suggests several enhanced status codes [SMTP-CODES] for submission-specific rejections. The specific codes used are:
このメモは服従特有の拒絶のために、いくつかの高められたステータスコード[SMTP-CODES]を示します。 使用される特定のコードは以下の通りです。
5.6.0 Bad content. The content of the header or text is
improper.
5.6.0 悪い内容。 ヘッダーかテキストの中身は不適当です。
5.6.2 Bad domain or address. Invalid or improper domain or address
in MAIL FROM, RCPT TO, or DATA.
5.6.2 悪いドメインかアドレス。 無効の、または、不適当なドメインかMAIL FROM、RCPT TO、またはDATAのアドレス。
5.7.1 Not allowed. The address in MAIL FROM appears to have
insufficient submission rights, or is invalid, or is not
authorized with the authentication used; the address in a
RCPT TO command is inconsistent with the permissions given to
the user; the message data is rejected based on the
submitting user.
5.7.1 許容されていません。 MAIL FROMのアドレスは、不十分な服従権利を持っているように見えるか、無効である、または認証が使用されている状態で、認可されません。 RCPT TOコマンドにおけるアドレスはユーザに与える許容に反しています。 メッセージデータは提出しているユーザに基づいて拒絶されます。
5.7.0 Site policy. The message appears to violate site policy in
some way.
5.7.0 サイト方針。 メッセージは何らかの方法でサイト方針に違反するように見えます。
4. Mandatory Actions
4. 義務的な動作
An MSA MUST do all of the following:
MSA MUSTは以下のすべてをします:
4.1. General Submission Rejection Code
4.1. 一般服従拒絶コード
Unless covered by a more precise response code, response code 554 is to be used to reject a MAIL FROM, RCPT TO, or DATA command that contains something improper. Enhanced status code 5.6.0 is to be used if no other code is more specific.
より正確な応答コードで覆われない場合、応答コード554は不適当な何かを含むMAIL FROM、RCPT TO、またはDATAコマンドを拒絶するのに使用されることです。 高められたステータスコード5.6.0は他のどんなコードもより特定でないなら使用されていることです。
4.2. Ensure All Domains are Fully-Qualified
4.2. All Domainsが確実にFullyが適切になるようにしてください。
The MSA MUST ensure that all domains in the envelope are fully- qualified.
MSA MUSTは、封筒のすべてのドメインが完全に資格があるのを確実にします。
If the MSA examines or alters the message text in way, except to add trace header fields [SMTP-MTA], it MUST ensure that all domains in address header fields are fully-qualified.
MSAが方法でメッセージ・テキストを調べるか、または変更するなら、跡のヘッダーフィールド[SMTP-MTA]を加えるのを除いて、それはアドレスヘッダーフィールドにおけるすべてのドメインが確実に完全に適切になるようにしなければなりません。
Reply code 554 is to be used to reject a MAIL FROM, RCPT TO, or DATA command which contains improper domain references.
回答コード554は不適当なドメイン参照を含むMAIL FROM、RCPT TO、またはDATAコマンドを拒絶するのに使用されることです。
NOTE: A frequent local convention is to accept single-level domains (for example, 'sales') and then to expand the reference by adding the remaining portion of the domain name (for example, to
以下に注意してください。 頻繁な地方のコンベンションがただ一つのレベルドメイン(例えば、'販売')を受け入れて、そして、ドメイン名の残存部分を加えることによって参照を広げることになっている、(例えば。
Gellens & Klensin Standards Track [Page 6] RFC 2476 Message Submission December 1998
Gellens&Klensin規格はメッセージ服従1998年12月にRFC2476を追跡します[6ページ]。
'sales.example.net'). Local conventions that permit single-level domains SHOULD reject, rather than expand, incomplete multi-level domains, since such expansion is particularly risky.
'sales.example.net') そのような拡大が特に危険であるので、ただ一つのレベルドメインSHOULDを可能にする地方のコンベンションが広げるよりむしろ不完全なマルチレベルドメインを拒絶します。
5. Recommended Actions
5. お勧めの動作
The MSA SHOULD do all of the following:
MSA SHOULDは以下のすべてをします:
5.1. Enforce Address Syntax
5.1. アドレス構文を実施してください。
An MSA SHOULD reject messages with illegal syntax in a sender or recipient envelope address.
不法な構文が送付者か受取人封筒にあるメッセージが記述するMSA SHOULD廃棄物。
If the MSA examines or alters the message text in way, except to add trace header fields, it SHOULD reject messages with illegal address syntax in address header fields.
MSAが方法でメッセージ・テキストを調べるか、または変更する加えるのを除いて、ヘッダーフィールドをたどってください、それ。SHOULDはアドレスヘッダーフィールドにおける不法なアドレス構文でメッセージを拒絶します。
Reply code 501 is to be used to reject a MAIL FROM or RCPT TO command that contains a detectably improper address.
回答コード501はdetectablyに不適当なアドレスを含むMAIL FROMかRCPT TOコマンドを拒絶するのに使用されることです。
When addresses are resolved after submission of the message body, reply code 554 with enhanced status code 5.6.2 is to be used after end-of-data, if the message contains invalid addresses in the header.
アドレスがメッセージ本体の服従、回答コード554の後にいつ高められたステータスコードで決心しているか、5.6、.2、メッセージがヘッダーに無効のアドレスを含んでいるなら、データの終わり以降に使用されることになっています。
5.2. Log Errors
5.2. ログ誤り
The MSA SHOULD log message errors, especially apparent misconfigurations of client software.
MSA SHOULDはメッセージ誤り、クライアントソフトウェアの特に見かけのmisconfigurationsを登録します。
Note: It can be very helpful to notify the administrator when problems are detected with local mail clients. This is another advantage of distinguishing submission from relay: system administrators might be interested in local configuration problems, but not in client problems at other sites.
以下に注意してください。 問題が地元のメールクライアントと共に検出されるとき、管理者に通知するのは非常に役立っている場合があります。 これはリレーと服従を区別する別の利点です: システム管理者は、他のサイトでローカルの設定問題に関心がありますが、クライアント問題では興味を持たないかもしれません。
6. Optional Actions
6. 任意の動作
The MSA MAY do any of the following:
MSA MAYは以下のどれかをします:
6.1. Enforce Submission Rights
6.1. 服従権利を実施してください。
The MSA MAY issue an error response to the MAIL FROM command if the address in MAIL FROM appears to have insufficient submission rights, or is not authorized with the authentication used (if the session has been authenticated).
MAIL FROMのアドレスが不十分な服従権利を持っているように見えるか、または認証が使用されている状態で認可されないなら(セッションが認証されたなら)、MSA MAYはMAIL FROMコマンドへの誤り応答を発行します。
Reply code 550 with enhanced status code 5.7.1 is used for this purpose.
高められたステータスコード5.7.1がある回答コード550はこのために使用されます。
Gellens & Klensin Standards Track [Page 7] RFC 2476 Message Submission December 1998
Gellens&Klensin規格はメッセージ服従1998年12月にRFC2476を追跡します[7ページ]。
6.2. Require Authentication
6.2. 認証を必要としてください。
The MSA MAY issue an error response to the MAIL FROM command if the session has not been authenticated.
セッションが認証されていないなら、MSA MAYはMAIL FROMコマンドへの誤り応答を発行します。
Section 3.3 discusses authentication mechanisms.
セクション3.3は認証機構について論じます。
Reply code 530 [SMTP-AUTH] is used for this purpose.
回答コード530[SMTP-AUTH]はこのために使用されます。
6.3. Enforce Permissions
6.3. 許容を実施してください。
The MSA MAY issue an error response to the RCPT TO command if inconsistent with the permissions given to the user (if the session has been authenticated).
ユーザに与える許容に矛盾しているなら(セッションが認証されたなら)、MSA MAYはRCPT TOコマンドへの誤り応答を発行します。
Reply code 550 with enhanced status code 5.7.1 is used for this purpose.
高められたステータスコード5.7.1がある回答コード550はこのために使用されます。
6.4. Check Message Data
6.4. メッセージデータをチェックしてください。
The MSA MAY issue an error response to the DATA command or send a failure result after end-of-data if the submitted message is syntactically invalid, or seems inconsistent with permissions given to the user (if known), or violates site policy in some way.
提出されたメッセージがシンタクス上無効であるか、ユーザ(知られているなら)に与える許容に矛盾しているように見えるか、または何らかの方法でサイト方針に違反するなら、MSA MAYはDATAコマンドへの誤り応答を発行するか、またはデータの終わりの後に失敗結果を送ります。
Reply code 554 is used for syntactic problems in the data. Reply code 501 is used if the command itself is not syntactically valid. Reply code 550 with enhanced status code 5.7.1 is used to reject based on the submitting user. Reply code 550 with enhanced status code 5.7.0 is used if the message violates site policy.
回答コード554はデータの構文の問題に使用されます。 コマンド自体がシンタクス上有効でないなら、回答コード501は使用されています。 高められたステータスコード5.7.1がある回答コード550は提出しているユーザに基づいて拒絶するのにおいて使用されています。 メッセージがサイト方針に違反するなら、高められたステータスコード5.7.0がある回答コード550は使用されています。
7. Interaction with SMTP Extensions
7. SMTP拡張子との相互作用
The following table lists the current standards-track and Experimental SMTP extensions. Listed are the RFC, name, an indication as to the use of the extension on the submit port, and a reference:
以下のテーブルは現在の標準化過程とExperimental SMTP拡張子を記載します。 記載されていて、RFC、名前、拡張子の使用に関する指示が進行中、ポート、および参照を提出してください:
RFC Name Submission Reference ---- --------------- ---------- ------------------ 2197 Pipelining SHOULD [PIPELINING] 2034 Error Codes SHOULD [CODES-EXTENSION] 1985 ETRN MUST NOT [ETRN] 1893 Extended Codes SHOULD [SMTP-CODES] 1891 DSN SHOULD [DSN] 1870 Size MAY [SIZE] 1846 521 MUST NOT [521REPLY] 1845 Checkpoint MAY [Checkpoint]
RFC名前服従参照---- --------------- ---------- ------------------ 2197年のパイプライン処理がそうするべきである、[パイプライン処理]2034エラーコードがそうするべきである、1893の[拡大をコード化します]の1985ETRN必須NOT[ETRN]の拡張コードが1891DSNがそうするべきである[SMTP-コード]1870年の[DSN]サイズ[サイズ]1846 521必須NOT[521REPLY]1845年5月にそうするべきである、チェックポイント5月[チェックポイント]
Gellens & Klensin Standards Track [Page 8] RFC 2476 Message Submission December 1998
Gellens&Klensin規格はメッセージ服従1998年12月にRFC2476を追跡します[8ページ]。
1830 Binary MAY [CHUNKING] 1652 8-bit MIME SHOULD [8BITMIME] ---- Authentication ------ [SMTP-AUTH]
1830 2進の5月に、[分魂化]1652 8ビットのMIMEはことであるべきです[8BITMIME]。---- 認証------ [SMTP-AUTH]
Future SMTP extensions should explicitly specify if they are valid on the Submission port.
将来のSMTP拡張子は、それらがSubmissionポートで有効であるかどうか明らかに指定するべきです。
Some SMTP extensions are especially useful for message submission:
いくつかのSMTP拡張子が特にメッセージ提案の役に立ちます:
Extended Status Codes [SMTP-CODES], SHOULD be supported and used according to [CODES-EXTENSION]. This permits the MSA to notify the client of specific configuration or other problems in more detail than the response codes listed in this memo. Because some rejections are related to a site's security policy, care should be used not to expose more detail than is needed to correct the problem.
拡張Status Codes[SMTP-CODES]、[CODES-EXTENSION]に従って、支持されて、使用されるSHOULD。 これは、MSAが特定の構成かさらに詳細に応答コードがこのメモに記載したこと以外の問題についてクライアントに通知することを許可します。 いくつかの拒絶がサイトの安全保障政策に関連するので、問題を修正するのが必要であるというよりも注意はその他の詳細を露出しないように働くべきです。
[PIPELINING] SHOULD be supported by the MSA.
[PIPELINING]SHOULD、MSAによって支持されてください。
[SMTP-AUTH] allows the MSA to validate the authority and determine the identity of the submitting user.
[SMTP-AUTH]は、MSAに権威を有効にして、提出しているユーザのアイデンティティを決定させます。
Any references to the DATA command in this memo also refer to any substitutes for DATA, such as the BDAT command used with [CHUNKING].
また、このメモにおけるDATAコマンドのどんな参照もDATAのどんな代用品についても言及します、[CHUNKING]と共に使用されるBDATコマンドなどのように。
8. Message Modifications
8. メッセージ変更
Sites MAY modify submissions to ensure compliance with standards and site policy. This section describes a number of such modifications that are often considered useful.
サイトは、規格とサイト方針へのコンプライアンスを確実にするように差出を変更するかもしれません。 このセクションは役に立つとしばしば考えられるそのような多くの変更について説明します。
NOTE: As a matter of guidance for local decisions to implement message modification, a paramount rule is to limit such actions to remedies for specific problems that have clear solutions. This is especially true with address elements. For example, indiscriminately appending a domain to an address or element which lacks one typically results in more broken addresses. An unqualified address must be verified to be a valid local part in the domain before the domain can be safely added.
以下に注意してください。 メッセージ変更を実行するというローカルの決定のための指導の問題として、最高の規則はそのような動作を明確な解決策を持っている特定の問題のための療法に制限することです。 これはアドレス要素で特に本当です。 例えば、無差別に1つを欠いているアドレスか要素にドメインを追加すると、より壊れているアドレスは通常もたらされます。 安全にドメインを加えることができる前のそのドメインの有効な地方の部分になるように資格のないアドレスについて確かめなければなりません。
8.1. Add 'Sender'
8.1. '送付者'を加えてください。
The MSA MAY add or replace the 'Sender' field, if the identity of the sender is known and this is not given in the 'From' field.
MSA MAYは'送付者'野原を加えるか、または取り替えます、送付者のアイデンティティが知られていて、これが'From'分野で与えられないなら。
The MSA MUST ensure that any address it places in a 'Sender' field is in fact a valid mail address.
MSA MUSTは、事実上、それが'送付者'分野に置くどんなアドレスも有効な郵便の宛先であることを確実にします。
Gellens & Klensin Standards Track [Page 9] RFC 2476 Message Submission December 1998
Gellens&Klensin規格はメッセージ服従1998年12月にRFC2476を追跡します[9ページ]。
8.2. Add 'Date'
8.2. 'デートしてください'と言い足してください。
The MSA MAY add a 'Date' field to the submitted message, if it lacks it, or correct the 'Date' field if it does not conform to [MESSAGE- FORMAT] syntax.
MSA MAYはそれを欠いているなら'日付'分野を提出されたメッセージに追加するか、または[MESSAGE- FORMAT]構文に従わないなら、'日付'分野を修正します。
8.3. Add 'Message-ID'
8.3. 'Message ID'を加えてください。
The MSA MAY add or replace the 'Message-ID' field, if it lacks it, or it is not valid syntax (as defined by [MESSAGE-FORMAT]).
MSA MAYは'Message ID'野原を加えるか、または取り替えます、それを欠いているか、それが有効な構文([MESSAGE-FORMAT]によって定義されるように)でないなら。
8.4. Transfer Encode
8.4. 転送エンコード
The MSA MAY apply transfer encoding to the message according to MIME conventions, if needed and not harmful to the MIME type.
MIMEコンベンションによると、MSA MAYはメッセージへの転送コード化を適用します、MIMEの種類に必要であって、有害でないなら。
8.5. Sign the Message
8.5. メッセージにサインしてください。
The MSA MAY (digitally) sign or otherwise add authentication information to the message.
MSA MAYは認証情報をメッセージにサインするか、またはそうでなければ、(デジタルに)追加します。
8.6. Encrypt the Message
8.6. メッセージをコード化してください。
The MSA MAY encrypt the message for transport to reflect organizational policies.
MSA MAYは輸送が組織的な方針を反映するメッセージをコード化します。
NOTE: To be useful, the addition of a signature and/or encryption by the MSA generally implies that the connection between the MUA and MSA must itself be secured in some other way, e.g., by operating inside of a secure environment, by securing the submission connection at the transport layer, or by using an [SMTP-AUTH] mechanism that provides for session integrity.
以下に注意してください。 役に立ちます、一般に、MSAによる署名、そして/または、暗号化の添加自体がMUAとMSAとの接続がそうしなければならないのを含意するということになるようにある他の方法で安全にしてください、例えば、安全な環境の内部を操作することによって、トランスポート層において、または、セッション保全に備える[SMTP-AUTH]メカニズムを使用することで服従接続を保証することによって。
8.7. Resolve Aliases
8.7. 別名を決議してください。
The MSA MAY resolve aliases (CNAME records) for domain names, in the envelope and optionally in address fields of the header, subject to local policy.
MSA MAYはヘッダーのアドレス・フィールドで封筒に任意に、ローカルの方針を条件としてドメイン名のための別名(CNAME記録)を決議します。
NOTE: Unconditionally resolving aliases could be harmful. For example, if www.example.net and ftp.example.net are both aliases for mail.example.net, rewriting them could lose useful information.
以下に注意してください。 無条件に別名を決議するのは有害であるかもしれません。 例えば、www.example.netとftp.example.netがmail.example.netのための両方の別名であるなら、それらを書き直すと、役に立つ情報は失われるかもしれません。
8.8. Header Rewriting
8.8. ヘッダーの書き直し
The MSA MAY rewrite local parts and/or domains, in the envelope and optionally in address fields of the header, according to local policy. For example, a site may prefer to rewrite 'JRU' as '
MSA MAYはヘッダーのアドレス・フィールドで封筒に任意に地方の部分、そして/または、ドメインを書き直します、ローカルの方針によると。 '例えば、'JRU'を書き直しますサイトが、好むかもしれない'
Gellens & Klensin Standards Track [Page 10] RFC 2476 Message Submission December 1998
Gellens&Klensin規格はメッセージ服従1998年12月にRFC2476を追跡します[10ページ]。
J.Random.User' in order to hide logon names, and/or to rewrite ' squeeky.sales.example.net' as 'zyx.example.net' to hide machine names and make it easier to move users.
ログオン名を隠して、隠れるために'zyx.example.net'として'squeeky.sales.example.net'を書き直す'J.Random.User'で、名前を機械加工して、ユーザを動かすのは、より簡単になります。
However, only addresses, local-parts, or domains which match specific local MSA configuration settings should be altered. It would be very dangerous for the MSA to apply data-independent rewriting rules, such as always deleting the first element of a domain name. So, for example, a rule which strips the left-most element of the domain if the complete domain matches '*.foo.example.net' would be acceptable.
しかしながら、アドレス、地方の部分、または特定の地方のMSA構成設定に合っているドメインだけが変更されるべきです。 MSAがデータから独立している書換規則を適用するのは、非常に危険でしょう、いつもドメイン名の最初の要素を削除するのなどように。 'そのように、例えば、完全なドメインが'*.foo.example.net'に合っているなら最も左の要素からドメインを奪い取る規則は許容できるでしょう。
9. Security Considerations
9. セキュリティ問題
Separation of submission and relay of messages can allow a site to implement different policies for the two types of services, including requiring use of additional security mechanisms for one or both. It can do this in a way which is simpler, both technically and administratively. This increases the likelihood that policies will be applied correctly.
サイトは服従の分離とメッセージのリレーで2つのタイプのサービスのための異なった政策を実施できます、追加担保メカニズムの1か両方の使用を必要とするのを含んでいて。 それは、より簡単な道に、技術的に行政上これができます。 これは方針が正しく適用される可能性を広げます。
Separation also can aid in tracking and preventing unsolicited bulk email.
分離も求められていない大量のメールを追跡して、防ぐ際に支援されることができます。
For example, a site could configure its MSA to require authentication before accepting a message, and could configure its MTA to reject all RCPT TOs for non-local users. This can be an important element in a site's total email security policy.
例えば、サイトは、メッセージを受け入れる前に認証を必要とするようにMSAを構成できて、非地元のユーザのためにすべてのRCPT TOsを拒絶するためにMTAを構成するかもしれません。 サイトの総メール安全保障政策でこれは重要な要素であるかもしれません。
If a site fails to require any form of authorization for message submissions (see section 3.3 for discussion), it is allowing open use of its resources and name; unsolicited bulk email can be injected using its facilities.
サイトがメッセージ差出のためのどんな形式の認可も必要としないなら(議論に関してセクション3.3を見てください)、そのリソースと名前の開いている使用を許しています。 施設を使用することで求められていない大量のメールを注入できます。
10. Acknowledgments
10. 承認
This updated memo has been revised in part based on comments and discussions which took place on and off the IETF-Submit mailing list. The help of those who took the time to review the draft and make suggestions is appreciated, especially that of Dave Crocker, Ned Freed, Keith Moore, John Myers, and Chris Newman.
このアップデートされたメモはコメントに基づいて一部改訂されました、そして、取った議論は時々IETF提出しているメーリングリストを置きます。 草稿を見直して、提案をするのに感謝するとき取った人の助け、特にデーヴ・クロッカーのもの、ネッド・フリード、キース・ムーア、ジョン・マイアーズ、およびクリス・ニューマン。
Special thanks to Harald Alvestrand, who got this effort started.
ハラルドAlvestrandのおかげで、特別です。Alvestrandはこの努力を開始させました。
Gellens & Klensin Standards Track [Page 11] RFC 2476 Message Submission December 1998
Gellens&Klensin規格はメッセージ服従1998年12月にRFC2476を追跡します[11ページ]。
11. References
11. 参照
[521REPLY] Durand, A. and F. Dupont, "SMTP 521 Reply Code",
RFC 1846, September 1995.
[521REPLY] ジュランドとA.とF.デュポン、「SMTP521回答コード」、RFC1846、1995年9月。
[8BITMIME] Klensin, J., Freed, N., Rose, M., Stefferud, E. and
D. Crocker, "SMTP Service Extension for 8bit-
MIMEtransport", RFC 1652, July 1994.
[8BITMIME]Klensin、J.、解放されています、N.、ローズ、M.、Stefferud、E.、およびD.クロッカー、「SMTPは8ビット-MIMEtransportのために拡大を修理します」、RFC1652、1994年7月。
[ABNF] Crocker, D., Ed. and P. Overell, "Augmented BNF for
Syntax Specifications: ABNF", RFC 2234, November
1997.
エド[ABNF]クロッカー、D.、P.Overell、「構文仕様のための増大しているBNF:」 "ABNF"、1997年11月のRFC2234。
[CHECKPOINT] Crocker, D., Freed, N. and A. Cargille, "SMTP
Service Extension for Checkpoint/Restart", RFC
1845, September 1995.
クロッカー(D.)が解放した[チェックポイント]とN.とA.Cargille、「チェックポイント/再開のためのSMTPサービス拡張子」、RFC1845、1995年9月。
[CHUNKING] Vaudreuil, G., "SMTP Service Extensions for
Transmission of Large and Binary MIME Messages",
RFC 1830, August 1995.
[分魂化] ボードルイ、G.、「大きくて2進のMIMEメッセージの伝達のためのSMTPサービス拡張子」、RFC1830、1995年8月。
[CODES-EXTENSION] Freed, N., "SMTP Service Extension for Returning
Enhanced Error Codes", RFC 2034, October 1996.
解放された[コード拡大]、N.、「戻るためのSMTPサービス拡張子はエラーコードを高めた」RFC2034、1996年10月。
[DSN] Moore, K., "SMTP Service Extension for Delivery
Status Notifications", RFC 1891, January 1996.
[DSN] ムーア、K.、「配送状態通知のためのSMTPサービス拡張子」、RFC1891、1996年1月。
[ESMTP] Klensin, J., Freed, N., Rose, M., Stefferud, E. and
D. Crocker, "SMTP Service Extensions", STD 10, RFC
1869, November 1995.
[ESMTP]Klensin、J.、解放されています、N.、ローズ、M.、Stefferud、E.、およびD.クロッカー、「SMTPは拡大を修理します」、STD10、RFC1869、1995年11月。
[ETRN] De Winter, J., "SMTP Service Extension for Remote
Message Queue Starting", RFC 1985, August 1996.
[ETRN] De冬、J.、「リモートメッセージキュー始めのためのSMTPサービス拡張子」、RFC1985、1996年8月。
[HEADERS] Palme, J., "Common Internet Message Headers", RFC
2076, February 1997.
[ヘッダー]パルメ、J.、「一般的なインターネットメッセージヘッダー」、RFC2076、1997年2月。
[IPSEC] Atkinson, R., "Security Architecture for the
Internet Protocol", RFC 1825, August 1995.
[IPSEC] アトキンソン、R.、「インターネットプロトコルのためのセキュリティー体系」、RFC1825、1995年8月。
[KEYWORDS] Bradner, S., "Key words for use in RFCs to Indicate
Requirement Levels", BCP 14, RFC 2119, March 1997.
[KEYWORDS]ブラドナー、S.、「Indicate Requirement LevelsへのRFCsにおける使用のためのキーワード」、BCP14、RFC2119、1997年3月。
Gellens & Klensin Standards Track [Page 12] RFC 2476 Message Submission December 1998
Gellens&Klensin規格はメッセージ服従1998年12月にRFC2476を追跡します[12ページ]。
[MESSAGE-FORMAT] Crocker, D., "Standard for the format of ARPA
Internet text messages", STD 11, RFC 822, August
1982;
[MESSAGE-FORMAT] クロッカー、D.、「ARPAインターネット・テキスト・メッセージの形式の規格」、STD11、RFC822、1982年8月。
Braden, R., Editor, "Requirements for Internet
Hosts -- Application and Support", STD 3, RFC 1123,
October 1989.
ブレーデン、R.、エディタ、「インターネットホストのための要件--、アプリケーションとサポート、」、STD3、RFC1123、10月1989日
[PIPELINING] Freed, N., "SMTP Service Extension for Command
Pipelining", RFC 2197, September 1997.
解放された[パイプライン処理]、N.、「コマンド連続送信のためのSMTPサービス拡張子」、RFC2197、1997年9月。
[POP3] Myers, J. and M. Rose, "Post Office Protocol --
Version 3", STD 53, RFC 1939, May 1996.
[POP3] マイアーズ、J.、およびM.ローズ、「郵便局は議定書を作ります--バージョン3インチ、STD53、RFC1939、1996年5月。」
[SIZE] Klensin, J., Freed, N. and K. Moore, "SMTP Service
Extension for Message Size Declaration", STD 10,
RFC 1870, November 1995.
Klensin(J.)が解放した[サイズ]、N.、およびK.ムーア、「SMTPはメッセージサイズ宣言のための拡大を修理します」、STD10、RFC1870、1995年11月。
[SMTP-AUTH] Myers, J., "SMTP Service Extension for
Authentication", Work in Progress.
[SMTP-AUTH] マイアーズ、J.、「認証のためのSMTPサービス拡張子」が進行中で働いています。
[SMTP-CODES] Vaudreuil, G., "Enhanced Mail System Status Codes",
RFC 1893, January 1996.
「高められたメールシステム状態はコード化する」[SMTP-コード]ボードルイ、G.、RFC1893、1996年1月。
[SMTP-MTA] Postel, J., "Simple Mail Transfer Protocol", STD
10, RFC 821, August 1982.
[SMTP-MTA] ポステル、J.、「簡単なメール転送プロトコル」、STD10、RFC821、1982年8月。
Partridge, C., "Mail Routing and the Domain
System", STD 14, RFC 974, January 1986.
ヤマウズラ、C.が「ルート設定とドメインシステムを郵送する」、STD14、RFC974、1月1986日
Braden, R., Editor, "Requirements for Internet
Hosts -- Application and Support", STD 3, RFC 1123,
October 1989.
ブレーデン、R.、エディタ、「インターネットホストのための要件--、アプリケーションとサポート、」、STD3、RFC1123、10月1989日
Gellens & Klensin Standards Track [Page 13] RFC 2476 Message Submission December 1998
Gellens&Klensin規格はメッセージ服従1998年12月にRFC2476を追跡します[13ページ]。
12. Authors' Addresses
12. 作者のアドレス
Randall Gellens QUALCOMM Incorporated 6455 Lusk Blvd. San Diego, CA 92121-2779 U.S.A.
ランドルGellensのクアルコムの法人組織の6455ラスクBlvd. サンディエゴ、カリフォルニア92121-2779米国
Phone: +1 619 651 5115 Fax: +1 619 651 5334 EMail: Randy@Qualcomm.Com
以下に電話をしてください。 +1 619 651、5115Fax: +1 5334年の619 651メール: Randy@Qualcomm.Com
John C. Klensin MCI Telecommunications 800 Boylston St, 7th floor Boston, MA 02199 USA
ジョンC.Klensin MCI Telecommunications800Boylston通り、7階のボストン、MA02199米国
Phone: +1 617 960 1011 EMail: klensin@mci.net
以下に電話をしてください。 +1 1011年の617 960メール: klensin@mci.net
Gellens & Klensin Standards Track [Page 14] RFC 2476 Message Submission December 1998
Gellens&Klensin規格はメッセージ服従1998年12月にRFC2476を追跡します[14ページ]。
13. Full Copyright Statement
13. 完全な著作権宣言文
Copyright (C) The Internet Society (1998). All Rights Reserved.
Copyright(C)インターネット協会(1998)。 All rights reserved。
This document and translations of it may be copied and furnished to others, and derivative works that comment on or otherwise explain it or assist in its implementation may be prepared, copied, published and distributed, in whole or in part, without restriction of any kind, provided that the above copyright notice and this paragraph are included on all such copies and derivative works. However, this document itself may not be modified in any way, such as by removing the copyright notice or references to the Internet Society or other Internet organizations, except as needed for the purpose of developing Internet standards in which case the procedures for copyrights defined in the Internet Standards process must be followed, or as required to translate it into languages other than English.
それに関するこのドキュメントと翻訳は、コピーして、それが批評するか、またはそうでなければわかる他のもの、および派生している作品に提供するか、または準備されているかもしれなくて、コピーされて、発行されて、全体か一部広げられた実現を助けるかもしれません、どんな種類の制限なしでも、上の版権情報とこのパラグラフがそのようなすべてのコピーと派生している作品の上に含まれていれば。 しかしながら、このドキュメント自体は何らかの方法で変更されないかもしれません、インターネット協会か他のインターネット組織の版権情報か参照を取り除くのなどように、それを英語以外の言語に翻訳するのが著作権のための手順がインターネットStandardsの過程で定義したどのケースに従わなければならないか、必要に応じてさもなければ、インターネット標準を開発する目的に必要であるのを除いて。
The limited permissions granted above are perpetual and will not be revoked by the Internet Society or its successors or assigns.
上に承諾された限られた許容は、永久であり、インターネット協会、後継者または案配によって取り消されないでしょう。
This document and the information contained herein is provided on an "AS IS" basis and THE INTERNET SOCIETY AND THE INTERNET ENGINEERING TASK FORCE DISCLAIMS ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.
このドキュメントとそして、「そのままで」という基礎とインターネットの振興発展を目的とする組織に、インターネット・エンジニアリング・タスク・フォースが速達の、または、暗示しているすべての保証を放棄するかどうかというここにことであり、他を含んでいて、含まれて、情報の使用がここに侵害しないどんな保証も少しもまっすぐになるという情報か市場性か特定目的への適合性のどんな黙示的な保証。
Gellens & Klensin Standards Track [Page 15]
Gellens&Klensin標準化過程[15ページ]
一覧
スポンサーリンク
