半角カナはiso-2022-jpの規格外のため、利用できない。メーラーで全角カナに変換すべき。携帯では携帯同士の場合独自仕様で半角カナを使っているがPCを送信対象とする場合(おそらくはサーバーで)全角カナに自動変換される。CRLFを除き1行は998バイト以下が必須、78バイト以下が推奨されている。1つのヘッダについて複数行記述可能。1行は末尾のCRLFを除いて76バイトまでという制約がある。エンコードは=?文字コード?符号化方式?データ?=のようにする。ヘッダにおける符号化の規約として'”‘の間の文字列はエンコード/デコードしてはならない。“”の意味はそれ以上でもそれ以下でもないため、如何なる場合でも省略が可能。Expressは余裕で規約違反をして、逐一””を使い、かつその中で符号化していますが。<Mail-address>}あて先。その場合’,’で区切る(改行する場合’,’の後が推奨される)名前に’,’など特殊文字を使いたい場合は'”‘で囲まなければならないあとどうでもいい仕様。グループ名:Mail-address,Mail-address,...;とするとメーラーによっては送信時にグループ単位送信を行う。Bcc:隠れコピー送信先。(Bcc自身も含む)全送信者について送信前にBcc:項目を削除する。mail-addressFromと似ているが1つしか指定できない。mail-addressFromとは違うあて先に返信して欲しい場合に指定。受信側メーラーに動作を任せるのでこれだけに対してのみ必ず返信になるという信頼性はない。GMT-Date-and-Time送信時刻。メール固有のID(通例、送信元メールアドレスの前に時間情報と’.’を付加したもの/メールアドレスが省略されることもある)を<>で囲む。メールを返信する際、元のメールのMessage-IDを指定する。GMT-Date-and-Timeメール送信における中継配送システム情報。Receivedは1つ以上存在し、通例として新しいものは古いものの前に付加される。付加を行使するのは受信側サーバ。直近のものほど信頼性はある。version-number省略した場合テキストメール。指定した場合MIMEメールとして扱われる。RFC2045で規定。parameterMIME-version:1.0で対応。これによりメールのデータ形式が定義されるparameterはセミコロンで区切りparam=valueの形で記述。MIME-TYPEはスラッシュで主型、副型に分けられ、不明な副型の場合主型で標準のものを採用。パラメータの種別は主型による。attachmentがあるのでいらないような。Content-Bodyの内容は完全に無視される。boundary:パートの区切り子の名前。”〜”のようにダブルクォートで囲む。終端子にはさらに後ろにも’–‘を付加したものを使う。区切り子の前はヘッダと同様空行にする。多種のパートを混在させるという宣言(デフォルト)。添付ファイル等に使う。同一の内容を複数のMIME-TYPEで記述するという宣言。受信メーラーによってタイプを選択させるためのもの。各パートがリンクしている事を宣言。くのメーラーは連続的に実行。メールの転送・カプセル化(RFC2046-5.2)トップレベルでの利用の場合、Recent-From,Recent-To,Recent-Date等を送信時にFrom,To,Dateの代わりに使うが、その際、受信側の返信先はFromになる。Multipart/Mixedのパートの一部に含めてカプセル化することも可能。パス.(RFC2046-P29)content-transfer-encodingは7bitでなければならない。ファイルパス以下略Content-Bodyの直前にさらに参照先ファイルのためのContent-Headerを書く。第二のContent-HeaderにはContent-IDを含むべき。それ以下のContent-Bodyの意味はaccess-typeにより異なる。local-fileの場合意味なし。content-transfer-encodingは7bitでなければならない。typeMIME-version:1.0で対応。