RFC2442 日本語訳
2442 The Batch SMTP Media Type. N. Freed, D. Newman, J. Belissent, M.Hoy. November 1998. (Format: TXT=18384 bytes) (Status: INFORMATIONAL)
プログラムでの自動翻訳です。
英語原文
Network Working Group N. Freed
Request for Comments: 2442 D. Newman
Category: Informational Innosoft
J. Belissent
Sun Microsystems
M. Hoy
Mainbrace
November 1998
ネットワークワーキンググループN.はコメントを求める要求を解放しました: 2442年のD.ニューマンカテゴリ: 情報のInnosoftのBelissentサン・マイクロシステムズM.ホーイMainbrace J.1998年11月
The
Batch SMTP
Media Type
バッチSMTPメディアタイプ
Status of this Memo
このMemoの状態
This memo provides information for the Internet community. It does not specify an Internet standard of any kind. Distribution of this memo is unlimited.
このメモはインターネットコミュニティのための情報を提供します。 それはどんな種類のインターネット標準も指定しません。 このメモの分配は無制限です。
Copyright Notice
版権情報
Copyright (C) The Internet Society (1998). All Rights Reserved.
Copyright(C)インターネット協会(1998)。 All rights reserved。
Abstract
要約
This document defines a MIME content type suitable for tunneling an ESMTP [RFC-821, RFC-1869] transaction through any MIME-capable transport. This type can be used for a variety of purposes, including: Extending end-to-end MIME-based security services (e.g., [RFC-1847]) to cover message envelope information as well as message content. Making it possible to use specific SMTP extensions such as NOTARY [RFC-1891] over unextended SMTP transport infrastructure. Enabling the transfer of multiple separate messages in a single transactional unit.
このドキュメントはどんなMIMEできる輸送でもESMTP[RFC-821、RFC-1869]トランザクションにトンネルを堀るのに適当なMIME content typeを定義します。 さまざまな目的、包含にこのタイプを使用できます: メッセージ内容と同様にメッセージ封筒情報をカバーするために、終わりから終わりへのMIMEベースのセキュリティー・サービス(例えば、[RFC-1847])を広げています。 unextended SMTP輸送インフラの上のNOTARY[RFC-1891]などの特定のSMTP拡張子を使用するのを可能にします。 単一の取引の単位における、複数の別々のメッセージの転送を可能にします。
Requirements Notation
要件記法
This document occasionally uses terms that appear in capital letters. When the terms "MUST", "MUST NOT", "SHOULD", "SHOULD NOT", and "MAY" appear capitalized, they are being used to indicate particular requirements of this specification. A discussion of the meanings of the terms "MUST", "SHOULD", and "MAY" appears in [RFC-1123]; the terms "MUST NOT" and "SHOULD NOT" are logical extensions of this usage.
このドキュメントは時折大文字で現れる用語を使用します。 “MUST"という用語、「必須NOT」、“SHOULD"である、「」 「5月」は大文字で書かれるように見えて、それらは、この仕様の特定の要件を示すのに使用されるべきです。 用語“MUST"、“SHOULD"、および「5月」の意味の議論は[RFC-1123]に現れます。 そして、「必須NOT」という用語、「」 この用法は論理的な拡大があるべきですか?
Freed, et. al. Informational [Page 1] RFC 2442 Batch SMTP Media Type November 1998
etフリード、アル。 メディアが1998年11月にタイプする情報[1ページ]のRFC2442バッチSMTP
The Application/batch-SMTP Content Type
バッチアプリケーション/SMTP content type
The "application/batch-SMTP" MIME content type is a container for the client side of an SMTP or ESMTP transaction. In keeping with traditional SMTP, the contents are line oriented and CRLF line terminators MUST be used.
「バッチアプリケーション/SMTP」MIME content typeはSMTPかESMTPトランザクションのクライアント側へのコンテナです。 伝統的なSMTPと共に保つ際に、内容は系列指向しています、そして、CRLF系列ターミネータを使用しなければなりません。
The "application/batch-SMTP" type is defined as follows:
「バッチアプリケーション/SMTP」タイプは以下の通り定義されます:
Media type name: application
Media subtype name: batch-SMTP
Required parameters: none
Optional parameters: required-extensions
Encoding considerations:
8bit material may appear, so quoted-printable or base64
encoding may be necessary on transports that do not
support 8bit. While the content of this type is
line-oriented and uses conventional CR/LF terminators,
lines longer than 7bit and 8bit encodings allow (998
octets) may appear, hence quoted-printable or
base64 encoding may be necessary even in conjunction
with 8bit transports.
Security considerations:
Discussed in the Security Considerations Section.
メディア型名: アプリケーションメディア「副-タイプ」は以下を命名します。 バッチSMTP Requiredパラメタ: なにも、Optionalパラメタ: 必要な拡大Encoding問題: とても引用されて印刷可能であるかbase64コード化が8ビットを支えない輸送のときに8ビットの材料が現れるかもしれないのが必要であるかもしれません。 このタイプの内容が系列指向であり、従来のCR/LFターミネータを使用している間、7ビットと8ビットのencodingsが(998の八重奏)を許容するより長い系列は現れるかもしれません、したがって、引用されて印刷可能であるかbase64コード化が8ビットの輸送に関連してさえ必要であるかもしれません。 セキュリティ問題: セキュリティ問題部では、論じられます。
How application/batch-SMTP is used
バッチアプリケーション/SMTPはどう使用されているか。
The following diagram illustrates how the application/batch-SMTP type is intended to be used:
バッチアプリケーション/SMTPタイプが使用されることをどう意図するかを以下のダイヤグラムは例証します:
application/batch-SMTP object
+----------------+
| |
+-----------+ v +----------+ v +-----------+
| batch | | MIME- | | batch |
=> | SMTP | => | capable | => | SMTP | =>
| generator | |transport | | processor |
^ +-----------+ +----------+ +-----------+ ^
| |
+-- conventional SMTP/RFC822 message transaction --+
バッチアプリケーション/SMTPオブジェクト+----------------+ | | +-----------+ +に対して----------+ +に対して-----------+ | バッチ| | MIME| | バッチ| =>| SMTP| =>|、できる。| =>| SMTP| =>| ジェネレータ| |輸送| | プロセッサ| ^ +-----------+ +----------+ +-----------+ ^ | | +--従来のSMTP/RFC822メッセージトランザクション--+
A conventional SMTP message transaction is converted into an application/batch-SMTP object by the batch SMTP generator. This object is then carried over some type of MIME-capable transport. Once the destination is reached the object is presented to a batch SMTP processor, which converts the application/batch-SMTP object back into a conventional SMTP message transaction.
従来のSMTPメッセージトランザクションはバッチSMTPジェネレータによってバッチアプリケーション/SMTPオブジェクトに変換されます。 そして、このオブジェクトはタイプのMIMEできる輸送の上まで運ばれます。 目的地にいったん達していると、バッチSMTPプロセッサにオブジェクトを贈ります。(それは、バッチアプリケーション/SMTPオブジェクトを従来のSMTPメッセージトランザクションに変換して戻します)。
Freed, et. al. Informational [Page 2] RFC 2442 Batch SMTP Media Type November 1998
etフリード、アル。 メディアが1998年11月にタイプする情報[2ページ]のRFC2442バッチSMTP
Generation of application/batch-SMTP material
バッチアプリケーション/SMTPの材料の世代
Application/batch-SMTP material is generated by a specially modified SMTP client operating without a corresponding SMTP server. The client simply assumes a successful response to all commands it issues. The resulting content then consists of the collected output from the SMTP client.
バッチアプリケーション/SMTPの材料は対応するSMTPサーバーなしで働いている特に、変更されたSMTPクライアントによって生成されます。クライアントは単にそれが発行するすべてのコマンドへのうまくいっている応答を仮定します。 そして、結果として起こる内容はSMTPクライアントからの集まっている出力から成ります。
Honoring SMTP restrictions
SMTP制限を光栄に思います。
Most batch SMTP processors will be constructed by modifying and extending existing SMTP servers. As such, all of the restrictions on SMTP constructs imposed by RFC 821, RFC 1123, and RFC 1869 MUST be observed. In particular, restrictions on command and data line lengths, number of recipients, and so on still exist and apply to batch SMTP.
ほとんどのバッチSMTPプロセッサが、既存のSMTPサーバーを変更して、広げることによって、組み立てられるでしょう。 そういうものとして、RFC821、RFC1123、およびRFC1869によって課されたSMTP構造物における制限のすべてを観測しなければなりません。 コマンドの制限とデータラインの長さ、受取人の数などは、特に、まだ存在していて、バッチSMTPに適用されます。
Use of SMTP Extensions
SMTP拡張子の使用
Since no SMTP server is present the client must be prepared to make certain assumptions about which SMTP extensions can be used. The generator MAY assume that ESMTP [RFC-1869] facilities are available, that is, it is acceptable to use the EHLO command and additional parameters on MAIL FROM and RCPT TO. If EHLO is used MAY assume that the 8bitMIME [RFC-1652], SIZE [RFC-1870], and NOTARY [RFC-1891] extensions are available. In particular, NOTARY SHOULD be used. MAY create private bilateral agreements which specify the availability of additional SMTP extensions. Additional SMTP extensions MUST NOT be used in the absence of such an agreement, and, perhaps more importantly, a conformant generation of application/batch-SMTP objects MUST be able to produce objects restricted to use of the extensions listed above.
どんなSMTPサーバーも存在していないので、クライアントはSMTP拡張子を使用できるある仮定をする用意ができていなければなりません。 ジェネレータは、ESMTP[RFC-1869]施設が利用可能であると仮定するかもしれません、すなわち、MAIL FROMとRCPT TOに関するEHLOコマンドと追加パラメタを使用するのは許容できます。 EHLOが中古の5月なら、8bitMIME[RFC-1652]、SIZE[RFC-1870]、およびNOTARY[RFC-1891]拡張子が利用可能であると仮定してください。 特にNOTARY SHOULD、使用されてください。 追加SMTP拡張子の有用性を指定する個人的な二国間条約を作成するかもしれません。 そのような協定がないとき追加SMTP拡張子を使用してはいけません、そして、恐らくより重要に、バッチアプリケーション/SMTPオブジェクトのconformant世代は上に記載された拡張子の使用に制限されたオブジェクトを作り出すことができなければなりません。
The "required-extensions" content type parameter MAY be used to communicate a list of the extensions actually used, specified as a comma-separated list of EHLO responses. If absent it defaults to the list "8bitMIME,SIZE,NOTARY". Any use by private bilateral agreement of additional or different extensions MUST be noted in the "required-extensions" parameter.
「必要な拡大」content typeパラメタは、EHLO応答のコンマで切り離されたリストとして実際に使用されて、指定された拡大のリストを伝えるのに使用されるかもしれません。 休むなら、それは「8bitMIME、サイズ、公証人」というリストをデフォルトとします。 「必要な拡大」パラメタに追加しているか異なった拡大の個人的な二国間条約によるどんな使用も述べなければなりません。
Note that many SMTP extensions simply do not make sense in the context of batch SMTP. For example, the pipelining extension [RFC- 2197] makes no sense in the absence of a network connection.
多くのSMTP拡張子がバッチの文脈でSMTPを絶対に理解できないことに注意してください。 例えば、パイプライン処理拡大[RFC2197]はネットワーク接続がないとき意味をなさないです。
Freed, et. al. Informational [Page 3] RFC 2442 Batch SMTP Media Type November 1998
etフリード、アル。 メディアが1998年11月にタイプする情報[3ページ]のRFC2442バッチSMTP
Handling Multiple Messages
複数のメッセージを扱います。
Generators SHOULD attempt to minimize the number of messages placed in a single application/batch-SMTP object. Ideally a single application/batch-SMTP object will be created for each message. Note, however, that some uses of application/batch-SMTP (e.g., mail bagging) may exist solely to take advantage of the multiple messages in a single container capability of batch SMTP, so requiring one message per container is not possible.
ジェネレータSHOULDは、独身のバッチアプリケーション/SMTPオブジェクトに置かれたメッセージの数を最小にするのを試みます。 理想的に、独身のバッチアプリケーション/SMTPオブジェクトは各メッセージのために作成されるでしょう。 しかしながら、1コンテナあたり1つのメッセージを必要とするのが可能でないようにバッチアプリケーション/SMTP(例えば、メールの膨らみ)のいくつかの用途が唯一バッチSMTPのただ一つのコンテナ能力における複数のメッセージを利用するために存在するかもしれないことに注意してください。
DISCUSSION: The SMTP protocol provides for the transfer of a series of messages over a single connection. This extends in a natural way to batch SMTP. However, the issues in batch SMTP are somewhat different. Suppose, for example, that a batch SMTP processor receives an application/batch-SMTP object containing two messages but is unable to process the second message because of a storage allocation failure. But suppose that not only does this failure preclude processing of the second message, it also precludes recording that the first message has already been processed. Subsequent reprocessing of the application/batch-SMTP could then lead to duplication of the first message.
議論: SMTPプロトコルは単独結合の上に一連のメッセージの転送に備えます。 これはバッチSMTPへの自然な方法で広がっています。 しかしながら、バッチSMTPの問題はいくらか異なっています。 例えば、バッチSMTPプロセッサが2つのメッセージを含むバッチアプリケーション/SMTPオブジェクトを受けますが、記憶領域の割当て失敗のために2番目のメッセージを処理できないと仮定してください。 しかし、また、この失敗は2番目のメッセージの処理を排除するだけではなく、既に最初のメッセージを処理してあるのが録音を排除すると仮定してください。 そして、バッチアプリケーション/SMTPのその後の再処理は最初のメッセージの複製につながるかもしれません。
This issue is not materially different from the well-known problems with SMTP synchronization that in practice often lead to duplicated messages. Since this behavior is inherent in SMTP to begin with it is not incumbent on application/batch-SMTP to completely address the issue. Nevertheless, it seems prudent for application/batch-SMTP to try and not make matters even worse.
この問題は実際にはしばしばコピーされたメッセージにつながるSMTP同期に関するよく知られる問題と物質的に異なっていません。 この振舞いが初めにSMTPに固有であるので、バッチアプリケーション/SMTPでは、問題を完全に扱うのは現職ではありません。 それにもかかわらず、バッチアプリケーション/SMTPが件をさらに悪くしないようにするように慎重に思えます。
Transport of application/batch-SMTP objects
バッチアプリケーション/SMTPオブジェクトの輸送
Application/batch-SMTP objects may be transported by any transport capable of preserving their MIME labelling, e.g., HTTP or SMTP.
バッチアプリケーション/SMTPオブジェクトはそれらのMIMEラベル、例えばHTTPを保存できるどんな輸送かSMTPによっても輸送されるかもしれません。
Transports MUST remain cognizant of the special nature of application/batch-SMTP. An application/batch-SMTP object contains one or more "frozen" SMTP message transactions. SMTP message transactions typically carry with them various assumptions about quality of service, e.g., that messages will either be delivered successfully or a nondelivery notification will be returned, that a nondelivery notification will be returned if delivery cannot be accomplished in a timely fashion, and so on. It is vital that the encapsulation of these objects for carriage over other forms of transport not interfere with these capabilities.
輸送はバッチアプリケーション/SMTPの特別な自然において認識力があるままでなければなりません。 バッチアプリケーション/SMTPオブジェクトは1つ以上の「凍っている」SMTPメッセージトランザクションを含んでいます。 SMTPメッセージトランザクションはそれらと共に例えば、首尾よくメッセージを提供するか、または不着損害通知を返して、直ちに、などに配送を実行できないと不着損害通知を返すというサービスの質に関する様々な仮定を通常運びます。 他の形式の輸送の上のキャリッジのためのこれらのオブジェクトのカプセル化がこれらの能力を妨げないのは、重大です。
Freed, et. al. Informational [Page 4] RFC 2442 Batch SMTP Media Type November 1998
etフリード、アル。 メディアが1998年11月にタイプする情報[4ページ]のRFC2442バッチSMTP
Processing of application/batch-SMTP material
バッチアプリケーション/SMTPの材料の処理
Processing of application/batch-SMTP material is considerably more complex than generating it. As might be expected, a modified SMTP/ESMTP processor is used. However, since it cannot return information to the client, it must handle all error conditions that arise itself. In other words, a batch SMTP processor assumes both the responsibilities of a traditional SMTP server as well as part of the responsibilities of a traditional SMTP client.
バッチアプリケーション/SMTPの材料の処理はそれを生成するよりかなり複雑です。 当然のことだが、変更されたSMTP/ESMTPプロセッサは使用されています。 しかしながら、情報をクライアントに返すことができないので、それはそれ自体で起こるすべてのエラー条件を扱わなければなりません。 言い換えれば、バッチSMTPプロセッサは伝統的なSMTPサーバーの責任と伝統的なSMTPクライアントの責任の一部の両方を仮定します。
As such, a conforming processor: MUST check MIME content type information to insure that the material it has been presented with is labelled as application/batch-SMTP and doesn't specify any extensions the processor doesn't support in the "required-extensions" parameter. Application/batch-SMTP objects that employ an unsupported extension SHOULD be forwarded to the local postmaster for manual inspection and handling. MUST accept any syntactically valid EHLO or HELO command. MUST accept any syntactically valid MAIL FROM command. A conforming processor, MAY, if it so desires, note the unacceptability of some part of a given MAIL FROM command and use this information to subsequently generate non-delivery notifications for any or all recipients. MUST accept any syntactically valid RCPT TO command. A conforming processor SHOULD note the unacceptability of some part of a given RCPT TO command and subsequently use this information to generate a non-delivery notification for this recipient in lieu of actually delivering the message. MUST accept any of the additional parameters defined by the 8bitMIME, SIZE, and NOTARY SMTP extensions on the MAIL FROM and RCPT TO commands. MUST accept the DATA command even when no valid recipients are present. 8bit MIME messages MUST be accepted. MUST accept the RSET command and handle multiple messages in a single application/batch-SMTP object. Processors MUST process each message in an application/batch-SMTP object once and SHOULD take whatever steps are necessary to avoid processing a message more than once. For example, if processing of an application/batch-SMTP object containing multiple messages is interrupted at an intermediate point it should subsequently be restarted at the end of the last message that was completely processed. SHOULD forward any syntactically invalid application/batch-SMTP message to the local postmaster for manual inspection and handling.
そういうものとして従うプロセッサ: それが提示された材料がバッチアプリケーション/SMTPとしてラベルされるのを保障するためにMIME content type情報をチェックしなければならなくて、プロセッサが「必要な拡大」パラメタでサポートしない少しの拡大も指定しません。 手動の点検のために地元の郵便局長に送られて、扱いながらサポートされない拡大SHOULDを使うバッチアプリケーション/SMTPオブジェクト。 どんなシンタクス上有効なEHLOやHELOコマンドも受け入れなければなりません。 どんなシンタクス上有効なMAIL FROMコマンドも受け入れなければなりません。 従うプロセッサ、5月、そう望んでいるなら、与えられたMAIL FROMコマンドの何らかの部分の受容不可能性に注意してください、そして、この情報を使用して、次に、いずれかすべての受取人のために非配送が通知であると生成してください。 どんなシンタクス上有効なRCPT TOコマンドも受け入れなければなりません。 与えられたRCPT TOの何らかの部分の受容不可能性が命令して、次に実際にメッセージを提供することの代わりにこの受取人のために非配送が通知であると生成するのにこの情報を使用するという従っているプロセッサSHOULDメモ。 MAIL FROMとRCPT TOコマンドのときに8bitMIME、SIZE、およびNOTARY SMTP拡張子で定義された追加パラメタのいずれも受け入れなければなりません。 どんな有効な受取人も出席してさえいないとき、DATAコマンドを受け入れなければなりません。 8ビットのMIMEメッセージを受け入れなければなりません。 独身のバッチアプリケーション/SMTPオブジェクトでRSETコマンドを受け入れて、複数のメッセージを扱わなければなりません。 プロセッサがバッチアプリケーション/SMTPオブジェクトで一度各メッセージを処理しなければならなくて、SHOULDは一度よりどんなメッセージをさらに処理するのを避けるのに必要な方法も採ります。 例えば、複数のメッセージを含むバッチアプリケーション/SMTPオブジェクトの処理が中間的ポイントで中断されるなら、それは次に、完全に処理された最後のメッセージの終わりで再開されるべきです。 SHOULDは手動の点検と取り扱いのためにどんなシンタクス上無効のバッチアプリケーション/SMTPメッセージも地元の郵便局長に転送します。
Security Considerations
セキュリティ問題
Application/batch-SMTP implements a tunneling mechanism. In general tunneling mechanisms are prone to abuse because they may provide a means of bypassing existing security restrictions. For example, an application/batch-SMTP tunnel implemented over an existing SMTP transport may allow someone to bypass relay restrictions imposed to block redistribution of spam.
バッチアプリケーション/SMTPはトンネリングメカニズムを実装します。 一般に、既存の安全保障制限を迂回させる手段を提供するかもしれないので、トンネリングメカニズムは乱用に傾向があります。 例えば、既存のSMTP輸送の上で実装されたバッチアプリケーション/SMTPトンネルで、だれかがスパムの再分配を妨げるために課されたリレー制限を迂回させることができるかもしれません。
Freed, et. al. Informational [Page 5] RFC 2442 Batch SMTP Media Type November 1998
etフリード、アル。 メディアが1998年11月にタイプする情報[5ページ]のRFC2442バッチSMTP
Application/batch-SMTP processors SHOULD implement access restrictions designed to limit access to the processor to authorized generators only. (Note that this facility may be provided automatically if application/batch-SMTP is being used to secure message envelope information.)
バッチアプリケーション/SMTPプロセッサSHOULDは、アクセスがアクセスをプロセッサに制限するように設計された制限であると認可されたジェネレータだけに実装します。 (バッチアプリケーション/SMTPがメッセージ封筒情報を保証するのに使用されているならこの施設が自動的に提供されるかもしれないことに注意してください。)
Acknowledgements
承認
The general concept of batch SMTP has been around for a long time. One particular type of batch SMTP was defined by Alan Crosswell and used on BITNET to overcome BITNET's native 8 character limit on user and host names. However, this form of batch SMTP differed from the current proposal in that it envisioned having the server return the status code responses to the client. In this case the client bore the burden of correlating responses with the original SMTP dialogue after the fact.
バッチSMTPに関する一般概念が長い間、周囲にあります。 バッチSMTPの1つの特定のタイプが、ユーザとホスト名におけるBitnetの自然な8キャラクタ限界に打ち勝つのにアランCrosswellによって定義されて、Bitnetの上で使用されました。 しかしながら、サーバを持っているそれが思い描いたSMTPが現在の提案と異なったこのフォームのバッチがクライアントへのステータスコード応答を返します。 この場合、クライアントは事実の後のオリジナルのSMTP対話で応答を関連させる負担を持っていました。
Unfortunately this approach proved not to work well in practice. BITNET eventually switched to the same basic form of batch SMTP that has been defined here. Unfortunately that definition was, to the best of the present authors' knowledge, never captured in a formal specification. It should also be noted that the definition given here also differs in that it takes SMTP extensions into account.
残念ながら、このアプローチは実際にはうまくいかないと判明しました。 Bitnetは結局、同じ基本的なフォームのバッチにここで定義されたSMTPを切り換えました。 残念ながら、現在の作者の知識では、形式仕様でその定義を決して得ませんでした。 また、また、ここに与えられた定義がSMTP拡張子を考慮に入れるという点において異なることに注意されるべきです。
Einar Stefferud had previously considered the problem of carrying extended SMTP messages over unextended SMTP transports. He proposed that some form of "double enveloping" technology be developed to address this problem. The mechanism presented here effectively implements the type of solution he proposed.
Einar Stefferudは以前に、拡張SMTPメッセージをunextended SMTP輸送に伝えるという問題を考えました。 彼は、何らかのフォームの「二重おおう」技術がこのその問題を訴えるために開発されるよう提案しました。 ここに有効に提示されたメカニズムは彼が提案したソリューションのタイプを実装します。
References
参照
[RFC-821] Postel, J., "Simple Mail Transfer Protocol", STD 10,
RFC 821, August 1982.
[RFC-821] ポステル、J.、「簡単なメール転送プロトコル」、STD10、RFC821、1982年8月。
[RFC-822] Crocker, D., "Standard for the Format of ARPA Internet
Text Messages", STD 11, RFC 822 August 1982.
[RFC-822] クロッカー、D.、「アルパインターネットテキスト・メッセージの形式の規格」、STD11、RFC822 1982年8月。
[RFC-1123] Braden, B., "Requirements for Internet Hosts --
Application and Support", STD 3, RFC 1123, October 1989.
[RFC-1123]ブレーデン、B.、「インターネットホストのための要件--、アプリケーションとサポート、」、STD3、RFC1123、10月1989日
[RFC-1652] Klensin, J., Freed, N., Rose, M., Stefferud, E. and D.
Crocker, "SMTP Service Extension for 8bit-MIMEtransport",
RFC 1652, July 1994.
[RFC-1652]Klensin、J.、解放されています、N.、ローズ、M.、Stefferud、E.、およびD.クロッカー、「SMTPは8ビット-MIMEtransportのために拡大を修理します」、RFC1652、1994年7月。
[RFC-1847] Galvin, J., Murphy, S., Crocker, S. and N. Freed,
"Security Multiparts for MIME: Multipart/Signed and
Multipart/Encrypted", RFC 1847, October 1995.
[RFC-1847] ガルビン、J.、マーフィー、S.、クロッカー、S.、および解放されたN.、「MIMEのためのセキュリティMultiparts:」 「署名していて複合の/が暗号化した複合/」、RFC1847、1995年10月。
Freed, et. al. Informational [Page 6] RFC 2442 Batch SMTP Media Type November 1998
etフリード、アル。 メディアが1998年11月にタイプする情報[6ページ]のRFC2442バッチSMTP
[RFC-1869] Klensin, J., Freed, N., Rose, M., Stefferud, E. and D.
Crocker, "SMTP Service Extensions", STD 10, RFC 1869,
November 1995.
[RFC-1869]Klensin、J.、解放されています、N.、ローズ、M.、Stefferud、E.、およびD.クロッカー、「SMTPは拡大を修理します」、STD10、RFC1869、1995年11月。
[RFC-1870] Klensin, J., Freed, N., Moore, K., "SMTP Service Extension
for Message Size Declaration", STD 10, RFC 1870, November,
1995.
J. [RFC-1870]Klensin、N.、ムーア、K.、「メッセージサイズ宣言のためのSMTPサービス拡張子」、STD10、RFC1870、11月、1995解放されて、
[RFC-2045] Freed, N. and N. Borenstein, "Multipurpose Internet Mail
Extensions (MIME) Part One: Format of Internet Message
Bodies", RFC 2045, December 1996.
解放された[RFC-2045]、N.、およびN.Borenstein、「マルチパーパスインターネットメールエクステンション(MIME)は1つを分けます」。 「インターネットメッセージ本体の形式」、RFC2045、1996年12月。
[RFC-2046] Freed, N. and N. Borenstein, "Multipurpose Internet Mail
Extensions (MIME) Part Two: Media Types", RFC 2046,
December 1996.
解放された[RFC-2046]、N.、およびN.Borenstein、「マルチパーパスインターネットメールエクステンション(MIME)は2を分けます」。 「メディアタイプ」、RFC2046、1996年12月。
[RFC-2197] Freed, N. and A. Cargille, "SMTP Service Extension for
Command Pipelining", RFC 2197, September 1997.
解放された[RFC-2197]とN.とA.Cargille、「コマンド連続送信のためのSMTPサービス拡張子」、RFC2197、1997年9月。
Authors' Addresses
作者のアドレス
Ned Freed Innosoft International, Inc. 1050 Lakes Drive West Covina, CA 91790 USA
ネッド解放されたInnosoft国際Inc.1050Lakesはウエストコビナ、カリフォルニア91790米国を運転します。
Phone: +1 626 919 3600 Fax: +1 626 919 3614 EMail: ned.freed@innosoft.com
以下に電話をしてください。 +1 626 919、3600Fax: +1 3614年の626 919メール: ned.freed@innosoft.com
Dan Newman Innosoft International, Inc. 1050 Lakes Drive West Covina, CA 91790 USA
ダンニューマンInnosoftの国際Inc.1050Lakesはウエストコビナ、カリフォルニア91790米国を運転します。
Phone: +1 626 919 3600 Fax: +1 626 919 3614 EMail: dan.newman@innosoft.com
以下に電話をしてください。 +1 626 919、3600Fax: +1 3614年の626 919メール: dan.newman@innosoft.com
Freed, et. al. Informational [Page 7] RFC 2442 Batch SMTP Media Type November 1998
etフリード、アル。 メディアが1998年11月にタイプする情報[7ページ]のRFC2442バッチSMTP
Mark Hoy Mainbrace Corporation 1136 West Evelyn Avenue Sunnyvale, CA 94086
マークホーイMainbrace社1136の西イヴリン・Avenueサニーベル、カリフォルニア 94086
tel: +1 408 774 5265 fax: +1 408 774 5290 email: mark.hoy@mainbrace.com
tel: +1 5265年の408 774ファックス: +1 5290年の408 774メール: mark.hoy@mainbrace.com
Jacques Bellisent SunSoft
ジャックBellisent SunSoft
Phone: +1 650 786 3630 EMail: jacques.belissent@eng.sun.com
以下に電話をしてください。 +1 3630年の650 786メール: jacques.belissent@eng.sun.com
Freed, et. al. Informational [Page 8] RFC 2442 Batch SMTP Media Type November 1998
etフリード、アル。 メディアが1998年11月にタイプする情報[8ページ]のRFC2442バッチSMTP
Full Copyright Statement
完全な著作権宣言文
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.
このドキュメントとそして、「そのままで」という基礎とインターネットの振興発展を目的とする組織に、インターネット・エンジニアリング・タスク・フォースが速達の、または、暗示しているすべての保証を放棄するかどうかというここにことであり、他を含んでいて、含まれて、情報の使用がここに侵害しないどんな保証も少しもまっすぐになるという情報か市場性か特定目的への適合性のどんな黙示的な保証。
Freed, et. al. Informational [Page 9]
etフリード、アル。 情報[9ページ]
一覧
スポンサーリンク
