　こんにちは。技術開発室の伊藤です。ハートビーツではメールサーバを自社で運用しています。そのメールサーバの移設を実施するにあたり、移設を対応するチームでさまざまなメールの仕様を理解しておく必要がありました。メールプロトコルの仕様についてはRFC（Request For Comments）が発行されているため、メールに関するRFCを読んでまとめる勉強会を行いました。その際にRFCを読むにあたって知っておくとよいことがいくつかあったので紹介します。

RFCとは

　RFCとはIETF（Internet Engineering Task Force）というインターネット技術の標準化を推進する団体やその他の団体が発行している、インターネット標準や技術提供の文書です。もともとは非公式な文書であることを明確にするため、Request For Comments（コメント募集）という名前にしていたようです。

一番最初のRFCは1969年に発行されており、もう50年以上続けられています。 50年を記念して発行された『RFC 8700 Fifty Years of RFCs』で歴史的背景など触れられているため、興味があれば読んでみてください。

ではRFCを見てみましょう。次の図は『RFC 5322 Internet Message Format』のRFCです。様々な仕様やベストプラクティスなどが下記のような文書として発行されています。

RFCの検索方法

　RFCを読むために活用できるウェブサイトはたくさんあります。ここでは公式が提供しているIETF Datatrackerをご紹介します。

Document Searchの欄に対象のRFCの番号やタイトルなどを入力して検索すると、当該のRFCや関連するRFCなどを検索できます。次の図は5322のRFCを検索した結果です。

検索結果のRFCsを選択しフォーマットを選択することでRFCを閲覧できます。 htmlの形式で表示すると追加のメタ情報が表示されるため、特に理由がなければFormatsのhtmlを選択して読むことをおすすめします。

RFCの構造

　RFCの構造については『RFC 7322 RFC Style Guide 4. Structure of an RFC』のセクション4に説明があります。

RFCは下記の要素で構成されています。

First-page header（ヘッダー）
Title（タイトル）
Abstract（要約）
Status of this Memo（RFCのステータスのメモ）
Copyright Notice（著作権表記）
Table of Contents（目次）
Body of the Memo（本文）

これらのRFCの要素についてそれぞれ説明します。

First-page header（ヘッダー）

　ヘッダーの詳細については『RFC 7841 RFC Streams, Headers, and Boilerplates』のセクション3.1に説明があります。

ドキュメントソース

　ヘッダーの左上にはこの文書を発行したRFCストリームが書かれています。もともとは「Network Working Group」というRFCストリームがすべてのRFCを発行していましたが、現在では下記の4つのRFCストリームが発行しています。

Internet Engineering Task Force
Internet Architecture Board
Internet Research Task Force
Independent Submission

RFCストリームについては『RFC 4844 The RFC Series and RFC Editor』のセクション5を参照してください。

RFC 番号

　"Request For Comments"にはこの文書が発行された際に割り当てられたRFCの番号が記述されています。この例では5322が割り当てられています。

Updates/Obsoletes

　"Obsoletes"および"Updates"にはこのRFCがどのRFCを更新・廃止したか書かれています。RFCとして発行された文書は一度発行された後に修正できません。大きな修正が必要であれば後から発行されたRFCで内容をアップデート・廃止したりします。

"Obsoletes"はこのRFCによって廃止されたRFCを、"Updates"はこのRFCによって一部更新されたRFCを示しています。"Updates"は元のすべてが更新されているわけではなく部分的に更新されているため、どこが更新されたかは"Updates"として記載されているRFCを読まなければわからないということに注意してください。

例えばRFC 5322では、このRFCによってRFC 2822が廃止され、RFC 4021の内容を一部更新していることがわかります。

なお、先程紹介したIETF DatatrackerのサイトではRFCの文書に加え、"Updated by"と"Obsolated by"というメタ情報がヘッダーの上に表示されています。"Updated by"や"Obsolated by"はこのRFCを更新・廃止したRFCの番号を表示してくれるため、読むときに注意しておくとよいでしょう。次の図の例ではRFC 5322はRFC 6854によってさらに一部更新がされていることがわかるようになっています。

　また軽微な修正が必要な場合はErrataという正誤表を発行します。Errataが存在する場合はIETF Datatrackerのウェブサイトでは次の図のように"Errata Exist"と記載されます。

メタ情報にある"Errata"を選択することでErrataの一覧を表示できます。

RFC 5322のErrataであるeid3048の例を見てみましょう。"set"を"sent"と書き間違えていたことが訂正されています。

（誤）

When resent fields are used, the "Resent-From:" and "Resent-Date:" fields MUST be sent. The "Resent-Message-ID:" field SHOULD be sent.

（正）

When resent fields are used, the "Resent-From:" and "Resent-Date:" fields MUST be set. The "Resent-Message-ID:" field SHOULD be set.

カテゴリ	説明
Standerds Track	標準化過程にある文書。Proposed Standard（標準化への提唱）とInternet Standard（標準）が含まれている
Informational	情報提供として書かれた文書
Experimental	実験的機能として提供されている文書
Historic	過去の経緯
Best Current Practice	仕様ではないが、現時点での最適な方法として提供されている文書

著者、発行日

　ヘッダーの右上にはRFCの著者名および所属組織、RFCの発行年月が書かれています。

Title（タイトル）

　このRFCのタイトルが書かれています。

Abstract（要約）

　"Abstract"の段落にはRFCの要約が書かれています。発行された背景などが書かれていることもあります。

Status of this Memo（RFCのステータスのメモ）

　"Status of this Memo"の段落にはこのRFCの状態について書かれています。どのコミュニティが発行したものであるかやカテゴリの説明、文書の現在の状態についての説明が記載されています。

Copyright Notice（著作権表記）

　"Copyright Notice"の段落には著作権についての情報が書かれています。

Table of Contents（目次）

　目次です。特に説明はありません。

Body of the Memo（本文）

　RFCの本文になります。読むうえで知っておくとよいことがいくつかあります。

気を付けて読むべき単語

　RFCの文書の中で注意しなければ行けない単語がいくつかあります。『RFC 2119 Key words for use in RFCs to Indicate Requirement Levels』にて定義されています。

下記の単語が気をつけて読むべき単語になります。

単語	邦訳	意味
MUST	しなければならない	要求事項
REQUIRED	要求される	要求事項
SHALL	するものとする	要求事項
MUST NOT	してはならない	禁止事項
SHALL NOT	しないものとする	禁止事項
SHOULD	すべきである	推奨事項（無視する場合は慎重な判断が必要）
RECOMMENDED	推奨される	推奨事項（無視する場合は慎重な判断が必要）
SHOULD NOT	すべきでない	非推奨事項（容認する場合は慎重な判断が必要）
NOT RECOMMENDED	推奨されない	非推奨事項（容認する場合は慎重な判断が必要）
MAY	してもよい	任意事項
OPTIONAL	任意である	任意事項

この単語が出てくる例を見てみましょう。下記はRFC 5322（Internet Message Format）の1文です。

Lines of characters in the body MUST be limited to 998 characters, and SHOULD be limited to 78 characters, excluding the CRLF.

文字数の制限に関する説明で下記の2つの事項が明記されています。

一行あたり998文字以内にしなければいけない（要求事項）
"CRLF"を除いて78文字に収めるべきである（推奨事項）

ANBF 記法

　RFCで文法を表現する方法としてANBF記法というものがあります。詳しい説明は『RFC 5234 Augmented BNF for Syntax Specifications: ABNF』を参照してください。

ルールについてかんたんに説明します。

ルール名と形式

ルール名 = 要素で構成されます。ルール名はその下の定義で利用可能です。

例)

rulea = "abc"

ruleb = "def"

rule = rulea ruleb

ABNF文字列は大文字と小文字が区別されず、これらの文字列の文字セットはUS-ASCIIです。また、下記の基数が定義されています。

b: 2進数
d: 10進数
x: 16進数

";"以降はコメントとして扱います。

代替

いくつかの要素のいずれかを選択する場合、選択できる要素を"/"で羅列します。グループ化が必要な場合は"()"で表現します。

例)

rule = foo / bar ;fooまたはbar

rule = elem (foo / bar) blat ;elem foo blat または elem bar blat

範囲を示したい場合は-を使って表現します。

例)

DIGIT = %x30-39 ;%x30から%x39まで、つまり、0 〜 9 を指す

繰り返し

繰り返しが必要な場合は<a>*<b>で表現します。aは最小個数、bは最大個数です。指定がない場合のデフォルトの最小個数は0、最大個数は無限です。 "[]"（角括弧）でくくられた要素はその中の要素が一個以上出現することを表しています。

例)

[foo bar] = 1*(foo/bar) ;foo または barが1個以上続く

終わりに

　RFCのルールを知らないまま読んでしまうと、古い情報やErrataが出ている間違った情報に当たることがあるため、今回ご紹介した読み方を意識してから読むとスムーズに読むことができると思います。いざRFCを読んでみると細かくルールが整備されているものや大雑把にしかルールがなく混沌としているものがあるので面白いです。またメール周りについてはインターネット上の情報がRFCと異なっていることや、送信されたメールがRFCに準拠していないこともあります。そういったときに、これどうなってたっけ...と思ったらぜひRFCを読んでみましょう。

RFCの読み方

カテゴリ:

RFCとは

RFCの検索方法

RFCの構造