RFC2645 日本語訳
2645 ON-DEMAND MAIL RELAY (ODMR) SMTP with Dynamic IP Addresses. R.Gellens. August 1999. (Format: TXT=16302 bytes) (Status: PROPOSED STANDARD)
プログラムでの自動翻訳です。
英語原文
Network Working Group R. Gellens Request for Comments: 2645 Qualcomm Category: Standards Track August 1999
Gellensがコメントのために要求するワーキンググループR.をネットワークでつないでください: 2645年のクアルコムカテゴリ: 標準化過程1999年8月
ON-DEMAND MAIL RELAY (ODMR)
SMTP with Dynamic IP Addresses
ダイナミックなIPアドレスがある要求次第のメール中継(ODMR)SMTP
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 (1999). All Rights Reserved.
Copyright(C)インターネット協会(1999)。 All rights reserved。
Table of Contents
目次
1. Abstract . . . . . . . . . . . . . . . . . . . . . . . . . . 1
2. Conventions Used in this Document . . . . . . . . . . . . . . 2
3. Comments . . . . . . . . . . . . . . . . . . . . . . . . . . 2
4. Description . . . . . . . . . . . . . . . . . . . . . . . . . 2
5. States . . . . . . . . . . . . . . . . . . . . . . . . . . . 3
5.1. Initial State . . . . . . . . . . . . . . . . . . . . . . 4
5.1.1. EHLO . . . . . . . . . . . . . . . . . . . . . . . . 4
5.1.2. AUTH . . . . . . . . . . . . . . . . . . . . . . . . 4
5.1.3. QUIT . . . . . . . . . . . . . . . . . . . . . . . . 4
5.2. Authenticated State . . . . . . . . . . . . . . . . . . . 4
5.2.1. ATRN (Authenticated TURN) . . . . . . . . . . . . . 4
5.3. Reversed State . . . . . . . . . . . . . . . . . . . . . 5
5.4. Other Commands . . . . . . . . . . . . . . . . . . . . . 6
6. Example On-Demand Mail Relay Session: . . . . . . . . . . . . 6
7. Response Codes . . . . . . . . . . . . . . . . . . . . . . . 6
8. Security Considerations . . . . . . . . . . . . . . . . . . . 6
9. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . 7
10. References . . . . . . . . . . . . . . . . . . . . . . . . . 7
11. Author's Address . . . . . . . . . . . . . . . . . . . . . 8
12. Full Copyright Statement . . . . . . . . . . . . . . . . . . 9
1. 要約. . . . . . . . . . . . . . . . . . . . . . . . . . 1 2。 このDocument. . . . . . . . . . . . . . 2 3のコンベンションUsed。 コメント. . . . . . . . . . . . . . . . . . . . . . . . . . 2 4。 記述. . . . . . . . . . . . . . . . . . . . . . . . . 2 5。 州. . . . . . . . . . . . . . . . . . . . . . . . . . . 3 5.1。 州. . . . . . . . . . . . . . . . . . . . . . 4 5.1の.1に頭文字をつけてください。 EHLO. . . . . . . . . . . . . . . . . . . . . . . . 4 5.1.2。 AUTH. . . . . . . . . . . . . . . . . . . . . . . . 4 5.1.3。 .45.2をやめてください。 州. . . . . . . . . . . . . . . . . . . 4 5.2の.1を認証しました。 ATRN(回転を認証する).45.3。 状態. . . . . . . . . . . . . . . . . . . . . 5 5.4を逆にしました。 他のコマンド. . . . . . . . . . . . . . . . . . . . . 6 6。 例の要求次第のメール中継セッション: . . . . . . . . . . . . 6 7. 応答は.6 8をコード化します。 セキュリティ問題. . . . . . . . . . . . . . . . . . . 6 9。 承認. . . . . . . . . . . . . . . . . . . . . . 7 10。 参照. . . . . . . . . . . . . . . . . . . . . . . . . 7 11。 作者のアドレス. . . . . . . . . . . . . . . . . . . . . 8 12。 完全な著作権宣言文. . . . . . . . . . . . . . . . . . 9
1. Abstract
1. 要約
With the spread of low-cost computer systems and Internet connectivity, the demand for local mail servers has been rising. Many people now want to operate a mail server on a system which has
安価のコンピュータ・システムとインターネットの接続性の普及で、ローカルのメールサーバの需要は高まっています。 多くの人々が現在、そうしたシステムの上でメールサーバを操作したがっています。
Gellens Standards Track [Page 1] RFC 2645 On-Demand Mail Relay August 1999
メール中継1999年8月の要求次第のGellens標準化過程[1ページ]RFC2645
only an intermittent connection to a service provider. If the system has a static IP address, the ESMTP ETRN command [ETRN] can be used. However, systems with dynamic IP addresses (which are very common with low-cost connections) have no widely-deployed solution.
サービスプロバイダーとの間欠接続だけ。 システムに静的IPアドレスがあるなら、ESMTP ETRNコマンド[ETRN]を使用できます。 しかしながら、動的IPアドレス(安価の接続について非常に一般的である)があるシステムには、広く配備された解決策が全くありません。
This memo proposes a new service, On-Demand Mail Relay (ODMR), which is a profile of SMTP [SMTP, ESMTP], providing for a secure, extensible, easy to implement approach to the problem.
このメモは新しいサービス、On-要求メールRelay(ODMR)を提案します、問題へのアプローチを実行するために安全で、広げることができる小休止に備えて。(RelayはSMTP[SMTP、ESMTP]のプロフィールです)。
2. Conventions Used in this Document
2. このDocumentのコンベンションUsed
Because the client and server roles reverse during the session, to avoid confusion, the terms "customer" and "provider" will be used in place of "client" and "server", although of course this protocol may be useful in cases other than commercial service providers and customers.
クライアントとサーバーの役割が混乱を避けるためにセッションの間、逆になるので、用語「顧客」と「プロバイダー」は「クライアント」と「サーバ」に代わって使用されるでしょう、このプロトコルはもちろん商業サービスプロバイダーと顧客以外の場合で役に立つかもしれませんが。
In examples, "P:" is used to indicate lines sent by the provider, and "C:" indicates those sent by the customer. Line breaks within a command are for editorial purposes only.
例で「P:」 そして、プロバイダーによって送られた線を示すのに使用される、「C:」 顧客によって送られたものを示します。 コマンドの中のラインブレイクは編集の目的だけのためのものです。
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月」は中[キーワード]で定義されるように本書では解釈されることになっているべきです。
Examples use 'example.net' as the provider, and 'example.org' and ' example.com' as the customers.
例は、プロバイダーとして'example.net'を使用して、顧客として'example.org'と'example.com'を使用します。
3. Comments
3. コメント
Private comments should be sent to the author. Public comments may be sent to the IETF Disconnected SMTP mailing list, <ietf-disconn-smtp@imc.org>. To subscribe, send a message to <ietf-disconn-smtp-request@imc.org> containing the word SUBSCRIBE as the body.
個人的なコメントを作者に送るべきです。 IETF Disconnected SMTPメーリングリスト、 <ietf-disconn-smtp@imc.org にパブリックコメントを送るかもしれない、gt。 申し込むために、メッセージ to <ietf-disconn-smtp-request@imc.org を送ってください、gt;、含有、ボディーとして登録と言い表してください。
4. Description
4. 記述
On-Demand Mail Relay is a restricted profile of SMTP [SMTP, ESMTP]. Port 366 is reserved for On-Demand Mail Relay. The initial client and server roles are short-lived, as the point is to allow the intermittently-connected host to request mail held for it by a service provider.
要求でのメールRelayはSMTP[SMTP、ESMTP]の制限されたプロフィールです。 ポート366はOn-要求メールRelayのために予約されます。 初期のクライアントとサーバーの役割は短命です、ポイントが断続的に接続されたホストがそれのためにサービスプロバイダーによって保持されたメールを要求するのを許容することであるので。
The customer initiates a connection to the provider, authenticates, and requests its mail. The roles of client and server then reverse, and normal SMTP [SMTP, ESMTP] proceeds.
メールは、顧客がプロバイダーに接続を開始するよう認証して、要求します。 次に、クライアントとサーバの役割は逆になります、そして、正常なSMTP[SMTP、ESMTP]は続きます。
Gellens Standards Track [Page 2] RFC 2645 On-Demand Mail Relay August 1999
メール中継1999年8月の要求次第のGellens標準化過程[2ページ]RFC2645
The provider has an On-Demand Mail Relay process listening for connections on the ODMR port. This process does not need to be a full SMTP server. It does need to be an SMTP client with access to the outgoing mail queues, and as a server implement the EHLO, AUTH, ATRN, and QUIT commands.
プロバイダーには、ODMRポートの上で接続の聞こうとするOn-要求メールRelayの過程があります。 この過程は、完全なSMTPサーバーである必要がありません。それは、外向的なメール待ち行列、サーバの道具のEHLO、AUTH、ATRN、およびQUITが命令するようにアクセスのSMTPクライアントである必要があります。
An MTA normally has a mail client component which processes the outgoing mail queues, attempting to send mail for particular domains, based on time or event (such as new mail being placed in the queue, or receipt of an ETRN command by the SMTP server component). The On-Demand Mail Relay service processes the outgoing queue not on a timer or new mail creation, but on request.
MTAには、通常、外向的なメール待ち行列を処理するメールクライアントコンポーネントがあります、特定のドメインのためのメールを送るのを試みて、時間か出来事(待ち行列に置かれる、新しいメール、またはSMTPサーバーコンポーネントによるETRNコマンドの領収書などの)に基づいて。 On-要求メールRelayサービスはタイマか新しいメール創造に処理するのではなく、要求に応じて外向的な待ち行列を処理します。
The provider side has normal SMTP server responsibilities [SMTP], including generation of delivery failure notices, etc. as needed.
プロバイダー側には、必要に応じて配信障害通知などの世代を含む正常なSMTPサーバー責任[SMTP]があります。
5. States
5. 状態
The On-Demand Mail Relay service has three states: an initial state, an authenticated state, and a reversed state. The state progression is illustrated in the following diagram:
On-要求メールRelayサービスには、3つの州があります: 初期状態、認証された州、および逆にされた状態。 州の進行は以下のダイヤグラムで例証されます:
---------------------------
! initial state !
---------------------------
! !
QUIT AUTH
! !
! V
! -----------------------
! ! authenticated state !
! -----------------------
! ! !
! QUIT ATRN
! ! !
! ! V
! ! ------------------
! ! ! reversed state !
! ! ------------------
! ! !
! ! QUIT
! ! !
V V V
---------------------
! termination !
---------------------
--------------------------- ! 初期状態!--------------------------- ! ! AUTH V!をやめてください!----------------------- ! ! 認証された状態!----------------------- ! ! ! ! ATRN V!をやめてください!------------------ ! ! ! 逆にされた状態!------------------ ! ! ! ! ! やめてください、!V V V--------------------- ! 終了!---------------------
Gellens Standards Track [Page 3] RFC 2645 On-Demand Mail Relay August 1999
メール中継1999年8月の要求次第のGellens標準化過程[3ページ]RFC2645
(Note that in the reversed state, commands are sent by the provider, not the customer.)
(逆にされた状態では、コマンドが顧客ではなく、プロバイダーによって送られることに注意してください。)
5.1. Initial State
5.1. 初期状態
In the initial state, the provider is the server and the customer is the client. Three commands are valid: EHLO, AUTH, and QUIT.
初期状態では、プロバイダーがサーバです、そして、顧客がクライアントです。 3つのコマンドが有効です: そして、EHLO、AUTH、やめてください。
5.1.1. EHLO
5.1.1. EHLO
The EHLO command is the same as in [ESMTP]. The response MUST include AUTH and ATRN.
EHLOコマンドは[ESMTP]と同じです。 応答はAUTHとATRNを含まなければなりません。
5.1.2. AUTH
5.1.2. AUTH
The AUTH command is specified in [AUTH]. The AUTH command uses a [SASL] mechanism to authenticate the session. The session is not considered authenticated until a success response to AUTH has been sent.
AUTHコマンドは[AUTH]で指定されます。 AUTHコマンドは、セッションを認証するのに[SASL]メカニズムを使用します。 セッションは認証されているとAUTHへの成功応答を送るまで考えられません。
For interoperability, implementations MUST support the CRAM-MD5 mechanism [CRAM]. Other SASL mechanisms may be supported. A site MAY disable CRAM-MD5 support if it uses more secure methods. The EXTERNAL mechanism [SASL] might be useful in some cases, for example, if the provider has already authenticated the client, such as during a PPP connection.
相互運用性のために、実現はCRAM-MD5メカニズム[CRAM]をサポートしなければなりません。 他のSASLメカニズムはサポートされるかもしれません。 より安全な方法を使用するなら、サイトはCRAM-MD5サポートを無効にするかもしれません。 例えば、プロバイダーが既にクライアントを認証したなら、いくつかの場合、EXTERNALメカニズム[SASL]は役に立つかもしれません、PPP接続などのように。
5.1.3. QUIT
5.1.3. やめてください。
The QUIT command is the same as in [SMTP].
QUITコマンドは[SMTP]と同じです。
5.2. Authenticated State
5.2. 認証された状態
The authenticated state is entered after a successful AUTH command. Two commands are valid in the authenticated state: ATRN and QUIT.
認証された状態はうまくいっているAUTHコマンドの後に入られます。 2つのコマンドが認証された状態で有効です: そして、ATRN、やめてください。
5.2.1. ATRN (Authenticated TURN)
5.2.1. ATRN(認証された回転)
Unlike the TURN command in [SMTP], the ATRN command optionally takes one or more domains as a parameter. The ATRN command MUST be rejected if the session has not been authenticated. Response code 530 [AUTH] is used for this.
[SMTP]のTURNコマンドと異なって、ATRNコマンドはパラメタとして任意に1つ以上のドメインをみなします。 セッションが認証されていないなら、ATRNコマンドを拒絶しなければなりません。 応答コード530[AUTH]はこれに使用されます。
The timeout for this command MUST be at least 10 minutes to allow the provider time to process its mail queue.
このコマンドのためのタイムアウトは、メール待ち行列を処理するプロバイダー時間を許容するためには少なくとも10分でなければなりません。
An ATRN command sent with no domains is equivalent to an ATRN command specifying all domains to which the customer has access.
ドメインなしで送られたATRNコマンドは顧客がアクセサリーを持っているすべてのドメインを指定するATRNコマンドに同等です。
Gellens Standards Track [Page 4] RFC 2645 On-Demand Mail Relay August 1999
メール中継1999年8月の要求次第のGellens標準化過程[4ページ]RFC2645
If the authentication used by the customer does not provide access to all of the domains specified in ATRN, the provider MUST NOT send mail for any domains to the customer; the provider MUST reject the ATRN command with a 450 code.
顧客によって使用された認証がATRNで指定されたドメインのすべてへのアクセスを提供しないなら、プロバイダーはどんなドメインのためのメールも顧客に送ってはいけません。 プロバイダーは450コードでATRNコマンドを拒絶しなければなりません。
If the customer does have access to all of the specified domains, but none of them have any queued mail, the provider normally rejects the ATRN command with response code 453. The provider MAY instead issue a 250 success code, and after the roles are reversed, send a QUIT following the EHLO.
顧客が指定されたドメインのすべてに近づく手段を持っていますが、それらのいずれではも何か列に並ばせられたメールがないなら、通常、プロバイダーは応答コード453でATRNコマンドを拒絶します。 プロバイダーは代わりに250成功コードを発行するかもしれません、そして、役割が逆にされた後にQUITをEHLOに続かせてください。
The provider MAY also reject the ATRN command with a 450 response to indicate refusal to accept multiple requests issued within a particular time interval.
また、プロバイダーは、特定の時間間隔以内に出された複数の要求を受け入れることへの拒否を示すために450応答でATRNコマンドを拒絶するかもしれません。
If the customer has access to all of the specified domains and mail exists in at least one of them, the provider issues a 250 success code.
顧客が指定されたドメインのすべてに近づく手段を持っていて、メールが少なくともそれらの1つに存在しているなら、プロバイダーは250成功コードを発行します。
If the server is unable to verify access to the requested domains (for example, a mapping database is temporarily unavailable), response code 451 is sent.
サーバが要求されたドメインへのアクセスについて確かめることができないなら(例えば、マッピングデータベースは一時入手できません)、応答コード451を送ります。
[ABNF] for ATRN:
[ABNF] ATRNのために:
atrn = "ATRN" [SP domain *("," domain)]
atrnは"ATRN"と等しいです。[SPドメイン*、(「」、ドメイン]
domain = sub-domain 1*("." sub-domain)
ドメイン=サブドメイン1*(「. 」 サブドメイン、)
sub-domain = (ALPHA / DIGIT) *(ldh-str)
サブドメイン=(アルファー/DIGIT)*(ldh-str)
ldh-str = *(ALPHA / DIGIT / "-") (ALPHA / DIGIT)
ldh-strは*(ALPHA / DIGIT /「-」)と等しいです。(アルファー/ケタ)
5.3. Reversed State
5.3. 逆にされた状態
After the provider has sent a success reply to the ATRN command, the roles reverse, and the customer becomes the server, and the provider becomes the client.
プロバイダーが成功回答をATRNコマンドに送った後に、役割は逆になります、そして、顧客はサーバになります、そして、プロバイダーはクライアントになります。
After receiving the success response to ATRN, the customer sends a standard SMTP initial greeting line. At this point normal SMTP [SMTP, ESMTP] commands are used. Typically the provider sends EHLO after seeing the customer's greeting, to be followed by MAIL FROM and so on.
ATRNへの成功応答を受けた後に、顧客は標準のSMTP初期の挨拶線を送ります。 ここに、正常なSMTP[SMTP、ESMTP]コマンドは使用されています。 MAIL FROMなどが支えるように顧客の挨拶を見た後に、通常、プロバイダーはEHLOを送ります。
Gellens Standards Track [Page 5] RFC 2645 On-Demand Mail Relay August 1999
メール中継1999年8月の要求次第のGellens標準化過程[5ページ]RFC2645
5.4. Other Commands
5.4. 他のコマンド
The provider MAY reject all commands other than EHLO, AUTH, ATRN, and QUIT with response code 502.
プロバイダーは応答コード502でEHLO、AUTH、ATRN、およびQUIT以外のすべてのコマンドを拒絶するかもしれません。
6. Example On-Demand Mail Relay Session
6. 例の要求次第のメール中継セッション
P: 220 EXAMPLE.NET on-demand mail relay server ready
C: EHLO example.org
P: 250-EXAMPLE.NET
P: 250-AUTH CRAM-MD5 EXTERNAL
P: 250 ATRN
C: AUTH CRAM-MD5
P: 334 MTg5Ni42OTcxNzA5NTJASVNQLkNPTQo=
C: Zm9vYmFyLm5ldCBiOTEzYTYwMmM3ZWRhN2E0OTViNGU2ZTczMzRkMzg5MAo=
P: 235 now authenticated as example.org
C: ATRN example.org,example.com
P: 250 OK now reversing the connection
C: 220 example.org ready to receive email
P: EHLO EXAMPLE.NET
C: 250-example.org
C: 250 SIZE
P: MAIL FROM: <Lester.Tester@dot.foo.bar>
C: 250 OK
P: RCPT TO: <l.eva.msg@example.com>
C: 250 OK, recipient accepted
...
P: QUIT
C: 221 example.org closing connection
P: 220 EXAMPLE.NETの要求次第のメール中継サーバ持ち合わせのC: EHLO example.org P: 250-EXAMPLE.NET P: 250-AUTHの一夜漬け-MD5の外部のP: 250 ATRN C: AUTH一夜漬け-MD5P: 334 MTg5Ni42OTcxNzA5NTJASVNQLkNPTQoはCと等しいです: Zm9vYmFyLm5ldCBiOTEzYTYwMmM3ZWRhN2E0OTViNGU2ZTczMzRkMzg5MAo= P: 235は今や、example.orgとしてCを認証しました: ATRN example.org、example.com P: 250 現在接続Cを逆にするOK: 220 メールPを受け取る準備ができているexample.org: EHLO EXAMPLE.NET C: 250-example.org C: 250 サイズP: メールFROM: <Lester.Tester@dot.foo.bar>C: 250 OK P: RCPT TO: <l.eva.msg@example.com>C: 250 OK、受取人は受け入れました… P: Cをやめてください: 221 接続を終えるexample.org
7. Response Codes
7. 応答コード
The response codes used in this document are:
本書では使用される応答コードは以下の通りです。
250 Requested mail action okay, completed 450 ATRN request refused 451 Unable to process ATRN request now 453 You have no mail 502 Command not implemented 530 Authentication required [AUTH]
250の要求されたメール動作承認、完成した450ATRNはATRNを処理する拒否された451Unableが、現在あなたがいいえを502Commandに郵送させる453がAuthenticationが必要とした530を実行しなかったよう要求するよう要求します。[AUTH]
8. Security Considerations
8. セキュリティ問題
Because access to the On-Demand Mail Relay server is only useful with a prior arrangement between the parties (so the provider is the target of MX records for the customer's domains and thus has mail to relay), it may be useful for the provider to restrict access to the On-Demand Mail Relay port. For example, the ODMR server could be
パーティーの間には、先の配置がある状態でOn-要求メールRelayサーバへのアクセスが役に立つだけであるので(したがって、プロバイダーは、顧客のドメインのためのMX記録の目標であり、その結果、リレーするメールを持っています)、プロバイダーがアクセスをOn-要求メールRelayポートに制限するのは、役に立つかもしれません。 例えば、ODMRサーバはそうであるかもしれません。
Gellens Standards Track [Page 6] RFC 2645 On-Demand Mail Relay August 1999
メール中継1999年8月の要求次第のGellens標準化過程[6ページ]RFC2645
configurable, or a TCP wrapper or firewall could be used, to block access to port 366 except within the provider's network. This might be useful when the provider is the customer's ISP. Use of such mechanisms does not reduce the need for the AUTH command, however, but can increase the security it provides.
プロバイダーのネットワークを除いて、366を移植するためにアクセスを妨げるのに構成可能であるかa TCP包装紙かファイアウォールを使用できました。 プロバイダーが顧客のISPであるときに、これは役に立つかもしれません。 しかしながら、そのようなメカニズムの使用はAUTHコマンドの必要性を減少させませんが、それが提供するセキュリティを上げることができます。
Use of SASL in the AUTH command allows for substitution of more secure authentication mechanisms in the future.
AUTHコマンドにおけるSASLの使用は将来、より安全な認証機構の代替を考慮します。
See sections 5.1.2 and 5.2.1 for additional security details.
セクション5.1.2と追加担保のための.1が詳しく述べる5.2を見てください。
9. Acknowledgments
9. 承認
This memo has been developed in part based on comments and discussions which took place on and off the IETF-disconn-smtp mailing list. Special thanks to Chris Newman and Ned Freed for their comments.
このメモはコメントに基づいて一部開発されました、そして、取った議論は時々IETF-disconn-smtpメーリングリストを置きます。 クリス・ニューマンとネッド・フリードのおかげで、彼らのコメントにおいて、特別です。
10. References
10. 参照
[ABNF] Crocker, D. and P. Overell, "Augmented BNF for Syntax
Specifications: ABNF", RFC 2234, November 1997.
[ABNF] クロッカー、D.、およびP.Overell、「構文仕様のための増大しているBNF:」 "ABNF"、1997年11月のRFC2234。
[AUTH] Myers, J., "SMTP Service Extension for Authentication",
RFC 2554, March 1999.
[AUTH] マイアーズ、J.、「認証のためのSMTPサービス拡張子」、RFC2554、1999年3月。
[CRAM] Klensin, J., Catoe, R. and P. Krumviede, "IMAP/POP
AUTHorize Extension for Simple Challenge/Response", RFC
2195, September 1997.
[すし詰めにします] KlensinとJ.とCatoeとR.とP.Krumviede、「/が飛び出させるIMAPは簡単な挑戦/応答のための拡大を認可する」RFC2195、1997年9月。
[ESMTP] Klensin, J., Freed, N., Rose, M., Stefferud, E. and D.
Crocker, "SMTP Service Extensions", RFC 1869, November
1995.
[ESMTP]KlensinとJ. N.と解放されて、ローズとM.とStefferudとE.とD.クロッカー、「SMTPサービス拡張子」、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月。
[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月。
[SASL] Myers, J., "Simple Authentication and Security Layer
(SASL)", RFC 2222, October 1997.
[SASL] マイアーズ、J.、「簡易認証とセキュリティは(SASL)を層にする」RFC2222、1997年10月。
[SMTP] Postel, J., "Simple Mail Transfer Protocol", STD 10, RFC
821, August 1982.
[SMTP] ポステル、J.、「簡単なメール転送プロトコル」、STD10、RFC821、1982年8月。
Gellens Standards Track [Page 7] RFC 2645 On-Demand Mail Relay August 1999
メール中継1999年8月の要求次第のGellens標準化過程[7ページ]RFC2645
11. Author's Address
11. 作者のアドレス
Randall Gellens QUALCOMM Incorporated 5775 Morehouse Dr. San Diego, CA 92121-2779 U.S.A.
ランドルサンディエゴ、Gellensクアルコムの法人組織の5775モアハウス博士カリフォルニア92121-2779米国
Phone: +1.619.651.5115 EMail: randy@qualcomm.com
以下に電話をしてください。 +1.619 .651 .5115 メール: randy@qualcomm.com
Gellens Standards Track [Page 8] RFC 2645 On-Demand Mail Relay August 1999
メール中継1999年8月の要求次第のGellens標準化過程[8ページ]RFC2645
12. Full Copyright Statement
12. 完全な著作権宣言文
Copyright (C) The Internet Society (1999). All Rights Reserved.
Copyright(C)インターネット協会(1999)。 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.
このドキュメントとそして、「そのままで」という基礎とインターネットの振興発展を目的とする組織に、インターネット・エンジニアリング・タスク・フォースが速達の、または、暗示しているすべての保証を放棄するかどうかというここにことであり、他を含んでいて、含まれて、情報の使用がここに侵害しないどんな保証も少しもまっすぐになるという情報か市場性か特定目的への適合性のどんな黙示的な保証。
Acknowledgement
承認
Funding for the RFC Editor function is currently provided by the Internet Society.
RFC Editor機能のための基金は現在、インターネット協会によって提供されます。
Gellens Standards Track [Page 9]
Gellens標準化過程[9ページ]
一覧
スポンサーリンク
