リンクはご自由に。訳を他で利用されてもかまいませんが、その際には無保証 であることだけは明記してください。利用する旨メールで連絡していただけたり、ここの サイトから転載した旨表記していただけるとうれしいです(返事できる保証は ありませんが)が、義務ではありません。
これ以外についてはリンク集のRFCあたりが 参考になるかと思います。
Contents:
| RFC 3514 | IPv4ヘッダ中のセキュリティフラグ |
| RFC 3030 | 大きなバイナリのMIMEメッセージを送信するためのSMTPサービスの拡張 |
| RFC 3251 | Electricity over IP |
| RFC 3092 | 「foo」の語源 |
| RFC 2919 | List-Id: メーリングリストを識別するための構築された(Structured)フィー ルドと名前空間 |
| RFC 2822 | インターネットメッセージのフォーマット |
| RFC 2821(1〜3章) | 単純なメール転送プロトコル、1〜3章 |
| RFC 2821(4,5章) | 単純なメール転送プロトコル、4、5章 |
| RFC 2821(6章〜) | 単純なメール転送プロトコル、6章〜 |
| RFC 2645 | 動的IPアドレス環境でのODMR SMTP |
| RFC 2554 | 認証のためのSMTPサービス拡張 |
| RFC 2476 | メッセージの提出(Message submission) |
| RFC 2119 | RFC中で使われる要求レベル表示のキーワード |
| RFC 1893 | 拡張されたメールシステムステータスコード |
大きなバイナリのMIMEメッセージを送信するためのSMTPサービスの拡張
この文書はSMTP(単純なメール転送プロトコル)サービスに2つの拡張を定義す
る。最初の拡張により、DATAコマンドの代わりに、効果的に大きな
MIME(Multipurpose Internet MailExtensions)メッセージを送るための"BDAT"
と呼ばれるものを利用することをSMTPクライアントとサーバが取り決めること
ができる。2つ目の拡張では、バイナリ送信エンコーディングを用いるMIMEメッ
セージ送信が取り決められるようになり、BDATコマンドに優位性を与える。こ
の文書はRFC 1830の更新と無効化を意図する。
Electricity over IP
この文書は、IP上で送電するためのアーキテクチャである「ほとんど接点のな
いランプのスイッチ (MPLampS)」についての動機と高いレベルのコンセプトを
記している。
MPLampSはDVE(不連続の電圧のエンコード)と、配送ネットワークでMPLSコント
ロールプレーンを利用する。この文書の目的は俯瞰の説明なので、我々は
MPLampSの多くの詳細には立ち入らなかった。不幸にも、多くの将来の文書は
これらの詳細を提供しようとするだろう。
とりあえず訳してみましたが、今いち変になってしまいました。
「foo」の語源
RFC269以降の約212のRFCが"foo", "bar", "foobar"といった語句をメタ構文変
数として、特に説明や定義なく用いている。この文書はその不足を解消する。
(いわゆるjoke RFCです。fooの語源について書かれています。)
List-Id: メーリングリストを識別するための構築された(Structured)フィー
ルドと名前空間
電子メーリングリストを扱うソフトウェア(サーバとユーザエージェント)には、
メッセージがどのメーリングリストに属するのかという信頼に足る識別方法が
必要である。リスト管理ヘッダの出現に伴ない、いかなるときにも、リスト処
理をした特定ホストに無関係に、メーリングリストにユニークな識別子を提供
することは、いっそう重要になってきている。
List-Idヘッダは、そのような識別子の標準的な位置を提供する。加えて、
FQDNを基にしたリスト識別子のための名前空間について記す。この名前空間は
リストオーナに求められる唯一性を保証するつもりであり、また実験的、また
個人使用のためのやや正確でない名前空間を許可する。
List-Idフィールドを含めることで、リストサーバは、メールクライアントに
対してユーザのためにリストの機能を実行するための、自動化されたツールを
開発することを容易にする。
このリスト識別子は多くの自動化されたタスク処理を容易にするための鍵を提
供でき、すなわちより広く利用できる。
インターネットメッセージのフォーマット
コンピュータ利用者の間で送られるテキストメッセージの構文を規定したもの
で、E-mailのメッセージが含まれる。この標準は標準であったRFC822
「Standard for the Format of ARPA Internet Text Messages」にとってかわ
るものであり、現在の実装や他のRFCで規定された増加分の変更を組み込み反
映したものである。
単純なメール転送プロトコル
RFC 821のrevised editionで、RFC 821によるSMTPを現在にあうように変更。
RFC821, 974, 1123のおきかえ、アップデートである。
分量が多いので、3分割してある。
動的IPアドレス環境でのODMR SMTP
動的IPアドレスでSMTPを利用するための方法。RFC 821にあるTURNをRFC 2554
のAUTHを用いた認証を利用することで安全にしたATRNを用いる。
認証のためのSMTPサービス拡張
SMTPクライアントはサーバに対する認証のメカニズムを示したり、認証プロト
コルの交換を実行したり、オプションとして、続いて起こるプロトコル相互作
用のためのセキュアレイヤを張るためのSMTPサービスの拡張(ESMTP)をこの文
書で定義する。この拡張はSimple Authentication and Security Layer(SASL)
の輪郭である。
Message submission
SMTPはメッセージの「伝達」プロトコルとして定義されており、つまり、メッ
セージの経路を決めること（必要であれば）と、最終的に（完全に）配達する
ことを意味する。MTAは、「Received」「Return-Path」や他の[SMTP-MTA]で要
求されるヘッダーフィールドを付け加えることを除き、メッセージテキストに
変更を加えることが想定されていない。
にもかかわらず、SMTPは今やメッセージの「サブミッション」プロトコルとし
ても広く使われており、即ちMUAにとって、MTAのルーティングネットワークへ
新しいメッセージを導入することを意味する。MUAからメッセージサブミッショ
ンを受け入れるプロセスは、メッセージサブミッションエージェント(Message
Submission Agent; MSA)と名付ける。
RFC中で使われる要求レベル表示のキーワード
多くの標準規定文書においていくつかの語は詳細な要求を知らせるために使わ
れる。これらの語はしばしば大文字で書かれる。この文書ではこれらの語を
IETF文書に翻訳したものとして定義する。このガイドラインに従う著者は、文
書の始めの方にこのフレーズを入れるべきである。
拡張されたメールシステムステータスコード
X.X.X の形の拡張メールシステムステータスコードの定義です。sendmailでは
8.10.0 以降で使われています。
RFC 3030
RFC 3251
RFC 3092
RFC 2919
RFC 2822
RFC 2821
RFC 2645
RFC 2554
RFC 2476
RFC 2119
RFC 1893
トップへ