FrontPage  Index  Search  Changes  RSS  Login

[network] SMTP - SMTP 関連メモ

概要

SMTP のさわりだけでも、まじめにおさえようと思い、RFC などの文書を参考にメモを作成した。

キーワード

  • SMTP mail relaying
  • DNS Mail eXchanger
  • message submission protocol
  • MIME

SMTP (Simple Mail Transfer Protocol)

参考資料

要点

  • SMTP mail relaying
    • 複数のネットワークにまたがってメールを転送する機能
    • ドメインネームサービスのメール交換メカニズムによって、メッセージ転送するために適切な次の宛先が示される

基本モデル

                 +----------+                +----------+
     +------+    |          |                |          |
     | User |<-->|          |      SMTP      |          |
     +------+    |  Client- |Commands/Replies| Server-  |
     +------+    |   SMTP   |<-------------->|    SMTP  |    +------+
     | File |<-->|          |    and Mail    |          |<-->| File |
     |System|    |          |                |          |    |System|
     +------+    +----------+                +----------+    +------+
                  SMTP client                SMTP server
  • SMTP クライアント/SMTP サーバ
  • 両者の間に双方向の通信路が確立される
  • SMTP クライアントの責任は、一つもしくはそれ以上の SMTP サーバにメールメッセージを転送するか、それが失敗した事をレポートする事
  • 完全な SMTP 実装でないクライアントは、メッセージ投函プロトコル(RFC 4409)を使うべき(SHOULD)
  • 転送チャネルが確立され、最初のハンドシェイクが完了したなら、SMTP クライアントはメールトランザクションを開始する
  • トランザクションは、メールの発信者と受信者の指定と、メッセージ内容を送信するための一連のコマンドから構成される
  • 同じメッセージが複数の受信者に送られる場合、同一の宛先ホスト(中間リレー)上のすべての受信者に対し、データのコピーを一つだけ送信する事を推奨する
  • SMTP リレー、または他の通信環境へのゲートウェイとして動作する中継ホストは、DNS の Mail eXchanger メカニズムを使用して選択される

拡張モデル

  • 現代の SMTP 実装は基本的な拡張メカニズムをサポートしなければならない(MUST)
  • 拡張フレームワーク
    • HELO に優先する SMTP コマンド EHLO
    • SMTP の MAIL コマンドおよび RCPT コマンドへの追加パラメータ
    • 本プロトコル(RFC 5321)で定義されるオプションの置き換え(例えば、非 ASCII 通信での DATA コマンド(RFC 3030))

用語

Mail Objects (メールオブジェクト)

エンベロープとコンテンツを含む。

  • SMTP エンベロープは一連の SMTP プロトコルユニットとして送信される
    • 送信者アドレス(エラー報告が向けられるべきアドレス)、一つ以上の受信者アドレス、オプションのプロトコル拡張の要素から構成される
  • SMTP コンテンツは SMTP DATA ユニットの中で送信される
    • ヘッダ部とボディからなる
    • ヘッダ部はヘッダフィールドの集合で、それぞれメッセージフォーマット仕様(RFC 5322)の通りに構造化されている
    • ボディは MIME 仕様(RFC 2045)に従って定義される
    • 事実上テキストで、US-ASCII の範囲で表現される
      • SMTP 拡張によってボディについて制限を緩和する事ができるが、ヘッダフィールドは常に US-ASCII を使用してエンコードされる

Senders and Receivers (送信者と受信者)

  • 送信者を SMTP クライアントと呼び、受信者を SMTP サーバと呼ぶ
  • 中継の仕組み上、サーバとクライアントの両方として振る舞う可能性があるため、受信者および送信者という用語も使われる

Mail Agents and Message Stores (メールエージェントとメッセージストア)

  • SMTP のサーバとクライアントはメール転送サービスを提供するため、メール転送エージェント(Mail Transfer Agent = MTA)として振る舞う
  • メールユーザエージェント(Mail User Agent = MUA)は、メールの送信もとおよび目的地と考えられる
  • 送信元において MUA は送信されるメッセージをユーザから受け取り、それを MTA に引き渡す
  • 最終(配送) MTA はそのメールを MUA に引き渡すかメッセージストアに預ける事で責任を果たすと考えられる

Host (ホスト)

  • インターネットかプライベート TCP/IP ネットワークに接続しており、SMTP プロトコルをサポートするコンピュータシステム
  • ホストは名前によって識別される
    • 数値アドレスによって識別されるべきではない

Domain Names (ドメイン名)

  • ドメイン名はホストまたはドメイン名階層内の他のエンティティの名前として使用される
    • ホスト名を示す代わりに、エイリアス(CNAME RR のラベル)や、メールは移送に使用されるメールエクスチェンジャのラベルを参照する事ができる
  • ドメイン名は FQDN
    • FQDN 形式でないドメイン名は、ローカルのエイリアス
    • SMTP トランザクションにはいかなるローカルエイリアスも現れてはならない(MUST NOT)
  • SMTP においてドメイン名が使用される場合、解決可能な FQDN のみ許される
    • MX RR またはアドレス RR に解決できる名前が許可され、最終的に MX またはアドレス RR に解決できる CNAME RR も同様に許可される
    • ローカルのニックネームまたは限定されない名前を使用してはならない(MUST NOT)
    • FQDN を要求するこの規則の例外
      • EHLO コマンド内で与えられるドメイン名は、主要なホスト名(アドレス RR を決定するドメイン名)か、ホストが名前を持たない場合にはアドレスリテラルかのどちらかでなければならない(MUST)
      • 予約済みメールボックス名 postmaster は RCPT コマンドに置いてドメインを限定せずに使用する事が許され、その様に使用された場合は受け入れなければならない(MUST)

Buffer and State Table (バッファと状態テーブル)

  • SMTP セッションはステートフル
  • 両参加者は現在の状態の共通認識を保持する
  • 状態は、サーバ上の仮想のバッファと状態テーブルによってモデル化される

Commands and Replies (コマンドとリプライ)

  • SMTP コマンドおよびメッセージデータは、送信者から受信者へと行形式で通信チャネルを通して転送される
  • SMTP リプライは、行形式のコマンドに対する確認応答(肯定または否定)
  • リプライの一般的な形式は数字の完了コードと、それにテキスト文字列が続く
  • RFC 3463 はリプライ文字列の更なる構造かを規定し、より具体的な追加の完了コードを含む (RFC 5248)

Lines (行)

  • ゼロ文字以上
  • <CRLF>で終了する
    • CR(0D) と LF(0A) の連続
    • これ以外を終端と認識してはならない(MUST NOT)

Message Content and Mail Data (メッセージコンテンツとメールデータ)

  • メッセージコンテンツおよびメールデータは、DATA コマンドが受け入れられた後からデータ終了指示が送信される前までの要素を示す
  • メッセージコンテンツは、メッセージヘッダセクションと、場合によって構造化されるメッセージボディを含む
  • MIME 仕様(RFC 2045)で構造かメセージボディのための標準メカニズムを提供する

Originator, Delivery, Relay, and Gateway System (発信者、配送、リレー、ゲートウェイ)

  • 電子メールの転送においてシステムが果たす役割に基づき、4 種類の SMTP システムを区別する
  • 発信システム(SMTP 発信者)は、メールをインターネット、またはトランスポートサービス環境へと取り込む
  • 配送 SMTP システムは、トランスポートサービス環境からメールを受信し、それを MUA に渡すか、MUA が後にアクセスすると期待されるメッセージストアに入れる
  • リレー SMTP システムは、SMTP クライアントからメールを受信し、更なるリレーまたは配送のために、メッセージにトレース情報を追加する以外の変更を行わずに、それを別の SMTP サーバへと送信する
  • ゲートウェイ SMTP システムは、あるトランスポート環境内のクライアントシステムからメールを受信し、それを別のトランスポート環境内のサーバシステムへと送信する
    • ゲートウェイの両側のトランスポート環境間のプロトコルまたはメッセージのセマンティクスの違いで、メッセージに対してリレーには許されない変換を行うことが許される
    • 本仕様では、アドレスを書き換えるファイアーウォールは、たとえその両側が SMTP であったとしても、ゲートウェイと呼ぶ

Mailbox and Address (メールボックスとアドレス)

  • アドレスは、メールを送信されるユーザ、またはメールが入れられる場所を特定する文字列
  • メールボックスは、その保管場所を表す
  • 標準的なメールボックスの命名規則は "local-part@domain" と定義されている

一般的な構文規則とトランザクションモデル

  • SMTP のコマンドおよびリプライは厳密な構文を持つ
  • すべてのコマンドはコマンド動詞から始まる
  • すべてのリプライは 3 桁の数値コードから始まる
  • 一部のコマンドおよびリプライにおいては、その動詞またはリプライコードに続けて引数を必要とする
  • 一部のコマンドは引数を受け入れない
  • 一部のリプライコードは(時にオプションで)自由形式のテキストが続く
  • テキストが現れる場合、空白文字によってコマンド動詞またはリプライコードと分離される
  • 動詞と引数の値(例えば RCPT コマンドに置ける "TO:" または "to:" や拡張キーワード)は大文字・小文字を区別されないが、メールボックスの local-part の指定は唯一の例外
    • SMTP 拡張は大文字・小文字を区別する要素を明示的に規定してよい
  • メールボックスの local-part は大文字・小文字を区別されなくてはならない(MUST)
  • メールボックスのドメインは通常の DNS 規則に従い、大文字・小文字を区別しない
  • 一部の SMTP 実装では、コマンド動詞を大文字でエンコードする事を要求する
    • そのようなサーバに適応するために、実装は大文字でのエンコードを採用してもよい
  • 引数は行末(<CRLF>)で終わる可変長文字列から構成される
  • コマンドおよびリプライは ASCII 文字セットの文字から構成される
    • トランスポートサービスが 8 ビットバイトの通信チャネルを提供する場合、上位ビットをゼロにクリアされた右詰めのオクテットとして転送される
    • つまり、拡張されていない SMTP サービスは 7 ビットの通信しかサポートしない
  • リレー SMTP は受信したメッセージ内容を有効だとみなし、内容を検査する事なしに中継すべき(SHOULD)
  • 配送 SMTP は内容が不正であれば、配送するよりも拒否したり配送不可として返送した方がよい(MAY)
  • 発信 SMTP システムは、サーバの提示する拡張が明示的に許可しない限り、US-ASCII 以外の文字セットによるエンベロープコマンドをの送信を許可されない
    • 受信システムはそのようなコマンドを、通常は "500 syntax error - invalid character" リプライを使用して拒否すべき(SHOULD)
  • 拡張 SMTP (特に RFC 1652 の 8BITMIME 拡張)を使用するクライアントは、サーバに 8 ビットのメッセージコンテンツを転送してもよい(MAY)
    • SMTP サーバは 8BITMIME をサポートすべき(SHOULD)
      • ただし、無制限に 8 ビット要素の送信が許可されたと解釈したり、8BITMIME が ASCII 以外の任意のエンベロープ要素の送信を許可するものだと解釈してはならない(MUST NOT)

SMTP の手順:概観

  1. セッション開始
  2. メールトランザクション
  3. メール転送
  4. メールボックス名の検証
  5. メーリングリストの展開
  6. 交換の開始と終了

セッション開始

  • SMTP セッションは、クライアントがサーバへの接続を開き、サーバがオープニングメッセージを応答したときに開始される
  • 220 <domain> Service ready
    • SMTP サーバの実装はこの後の接続グリーティングリプライの中に自身のソフトウェアとバージョンの情報を含めてもよい(MAY)
  • 554 No SMTP service here
    • 初期接続のオープニングメッセージ内で 220 応答の代わりに 554 応答が返されてもよい(MAY)
      • SMTP プロトコルは、サーバが初期接続を許可しながらメールセッションを公式に拒否する事を許可している
      • この場合、接続を閉じるクライアントが QUIT を送信するのを待たなければならない(MUST)
      • 間に入るコマンドに対して 503 応答を返すべき(SHOULD)
      • 503 Bad sequence of commands

クライアントの開始

  • サーバがグリーティング(ウェルカム)メッセージを送信し、クライアントがそれを受信した後、クライアントは通常、サーバに EHLO コマンドを送信し、自身の身元を示す
  • EHLO を使用する事は、クライアントがサービス拡張を処理する能力を持つ事を表し、サーバがサポートするサービス拡張のリストを提供するよう要求する事になる
  • サービス拡張をサポートしないか必要としないクライアントは HELO コマンドを使用してもよい(MAY)
  • サーバは HELO コマンドに対して EHLO 形式の応答を返してはならない(MUST NOT)
  • EHLO に対してサーバが "command not recognized" を返した場合、クライアントはフォールバックし、HELO を送信できるべき(SHOULD)

メールトランザクション

  • SMTP のメールトランザクションには 3 つのステップが存在する
  • トランザクションは送信者の身元を与える MAIL コマンドから始まる
  • 次に DATA コマンドがメールデータの送信を開始し、メール終了インジケータで終了する
MAIL FROM:<reverse-path> [SP <mail-parameters> ] <CRLF>
  • SMTP 受信者に新しいメールトランザクションを開始し、受信者やメールデータを含むすべての状態テーブルとバッファを初期化するように伝える
  • reverse-path はエラーを報告するのに使用される送信もとメールボックス("<" と ">" の間)を含む
  • 受け入れ可能なら SMTP サーバは "250 OK" リプライを返す
  • 何らかの理由でメールボックスの指定が受け入れられない場合、サーバは障害が永続的なものか、一時的なものかを示すリプライを返さなければならない(MUST)
  • RCPT コマンド内の一つ以上の forward-path が検証できるまで、reverse-path の受け入れ可能性を判断できない状況もあり得る
    • その場合、250 リプライで受け入れておき、forward-path を受信し検証した後で問題を報告してもよい(MAY)
    • 通常、失敗は 550 または 553 のリプライを生成する
  • 歴史的には、reverse-path にメールボックス以上の内容を含める事が許可されていた
    • 現在のシステムは、ソースルーティングを使用するべきではない(SHOULD NOT)
RCPT TO:<forward-path> [ SP <rcpt-parameters> ] <CRLF>
  • 一人の受信者を表す forward-path を含む
    • 通常はメールボックスとドメインであり、常に "<" と ">" とで囲まれる
    • 受け入れられるなら "250 OK" リプライを返し、forward-path を保持する
    • 配送不能のアドレスである事がわかっている場合、SMTP サーバは 550 リプライ(典型的には "no such user - ")を返す(他の理由やリプライコードも可能)
  • forward-path はメールボックス以上の情報を含む事ができる
    • 歴史的にはソースルーティングのホストリストと宛先メールボックスを含む事を許可されていたが、現在の SMTP クライアントはソースルーティングを使用すべきでない(SHOULD NOT)
    • サーバは forward-path 内でソースルートのリストに遭遇する用意がなければならない(MUST)が、そのルートを拒否すべき(SHOULD)
    • MAIL コマンドなしに RCPT コマンドが現れた場合、サーバは "503 Bad sequence of commands" を返さなければならない(MUST)
  • MAIL の FROM: と RCPT の TO: について、コロンの直前と直後に空白が許可されない事に注意が必要
DATA <CRLF>
  • 受け入れられると、SMTP サーバは 354 中間リプライを返し、メールデータ終了インジケータの直前までのすべての後続行をメッセージテキストであると見なす
  • テキストの終端が受信され保存されると、SMTP 受信者は "250 OK" リプライを送信する
  • SMTP は "."(ピリオド) のみからなる行を送信することでメールデータの終了を表す
  • メールデータの終了インジケータはメールトランザクションの確認も行い、保存された受信者とメールデータを処理するように SMTP サーバに伝える
    • 受け入れられると、SMTP サーバは "250 OK" リプライを返す
  • MAIL または RCPT がない場合や、それらが拒否された場合、サーバは DATA コマンドに対して 503 または 554 のリプライを返してもよい(MAY)
  • 5xy リプライを受信したクライアントはメッセージデータを送信してはならない(MUST NOT)
    • より一般的に言えば、354 リプライを受信しない限り、メッセージデータを送信してはならない(MUST NOT)

アドレスの訂正または更新のための転送

  • 企業内もしくはいくつかの企業に関連して、アドレスを統合したり簡素化したりするため、もしくはある人の以前のアドレスを現在のアドレスに紐づけるために必要とされる
  • セキュリティまたは機密保持の目的のため、メッセージの暗黙(サーバが送信者に通知しない)の転送が一般的
  • 転送動作の副作用として SMTP プロトコルにより最終アドレスが公開されることは情報隠蔽(またはセキュリティ)の考慮と相反する
    • 送信者から最終アドレスに連絡可能でない場合、これは特に重要
      • RFC 821 のセクション 3.2 で説明されている転送メカニズム、そして特に RCPT からの 251 リプライおよび 551 リプライは、注意深く評価されなければならない
      • アドレスの変更を知っているサーバはメッセージを転送してもよい(MAY)
      • サーバがメッセージを転送する場合、コード 251 とともにアドレス更新情報を提供するか、暗黙的に転送しコード 250 を返すかしてよい(MAY)
      • コード 251 を使用しても、サーバはクライアントが実際にアドレス情報を更新したり、その情報を利用者に返したりすると仮定してはならない(MUST NOT)
      • 指定された通りのアドレスに配送できない場合、サーバはそのメッセージを配送不能として拒否するか返送してよい(MAY)
      • その場合、サーバは 551 とともにアドレス更新情報を提供してもよい(MAY)し、またはアドレス指定情報を持たない 550 により配送不能としてメッセージを拒否してもよい(MAY)
      • コード 551 を使用しても、サーバはクライアントが実際にアドレス情報を更新したり、その情報を利用者に返したりすると仮定してはならない(MUST NOT)

アドレスのデバッグ作業のためのコマンド

  • SMTP はユーザ名を確認したり、メーリングリストの内容を取得したりするためのコマンドを提供する
    • VRFY コマンドおよび EXPN コマンドで行われ、文字列の引数をとる
    • 実装は両者をサポートすべき(SHOULD)
  • VRFY コマンドの引数はユーザ名か、ユーザ名とドメイン名
    • 通常の応答(250)の場合、その応答はユーザのメールボックスを含まなければならず(MUST)、ユーザのフルネームを含んでもよい(MAY)
    • 2 つ以上のメールボックスが特定される場合、サーバはその不明確さを言及するか、選択肢を提示してよい(MAY)
      • 553
  • EXPN コマンドの引数はメーリングリストを表す
    • 成功を表す(250)複数行応答にはメーリングリスト内のメールボックスを与えなければならず(MUST)、ユーザのフルネームを含んでもよい(MAY)
    • VRFY をメーリングリストに適用する事を要求された場合
      • リスト上の全員にメッセージが配送されるのであれば肯定応答が返されてもよい(MAY)
      • そうでなければエラー(例えば "550 That is a mailing list, not a user" または "242 Unable to verify members of mailing list")が報告されるべき(SHOULD)
    • ユーザ名の展開を要求されたサーバは一つの名前を含むリストから構成される肯定応答を返してもよい(MAY)し、エラー(例えば "550 That is a user name, not a mailing list")を報告してもよい(MAY)
  • 成功を表す複数行リプライの場合、リプライの各行にはただひとつのメールボックスが示される
  • VRFY コマンドと EXPN コマンドの実装は、少なくともローカルメールボックスをユーザ名として認識しなければならない(MUST)
    • ただし、複数のドメインのためのメールを処理する単一ホストでは、"local-part@domain" 形式をユーザ名として受け入れるべき(SHOULD)
  • 実際にアドレスを検証しない限り、サーバは VRFY および EXPN に対して 250 コードを返してはならない(MUST NOT)
    • 特に、構文が妥当である事を確認しただけで 250 を返してはならない(MUST NOT)
    • メールエクスチェンジャとして動作する場合など、リアルタイムでの合理的な検証を行えない場合、代わりに 252 を返すべき(SHOULD)
    • 実装は VRFY のアドレス検証について、多少時間がかかるとしても積極的であるべき(SHOULD)

リレーとメールルーティング

  • ドメインネームシステムのメールエクスチェンジャレコードの利用により、インターネットのメールシステムにおける明示的なソースルートの使用は不要になる
  • 通常、リレー SMTP サーバは最終配送システム絵はなく、それを指定する DNS の MX レコードの対象
    • リレーサーバは、メールをリレーする仕事を受け入れたり拒否したりしてよい
    • サーバがその作業を受け入れる場合、サーバは次に SMTP クライアントになり DNS で指定された次の SMTP サーバへの通信チャネルを確立する
    • ポリシーを理由に特定のアドレスへのメールのリレーを拒否する場合、550 応答が返されるべき(550)
  • MX レコードは、単なる SMTP リレーや最終配送システムではなく、他の環境へのゲートウェイとして振る舞う SMTP サーバを指し示す事ができる事に注意する事が重要
  • SMTP サーバがメールのリレー作業を受け入れた後、その宛先が不正か、何かしらの理由で配送不可能であるとわかった場合、サーバは"undeliverable mail"通知メッセージを構築し、配送不能メールの発信者(reverse-path で示される)にそれを送り返さなければならない(MUST)
    • 可能であれば他の標準(RFC 3461 および RFC 3464)によって配送不能通知用に規定されたフォーマットを使うべき(SHOULD)
    • SMTP サーバは通知メッセージの転送中の問題についての通知メッセージを送信してはならない(MUST)
    • エラー報告におけるループを避ける方法のひとつは、通知メッセージの MAIL コマンドにからの reverse-path を指定する事
  • リレー SMTP はメッセージのヘッダ部やボディを検査したり、それに基づいて動作する必要はなく、ヘッダに自身の "Received:" フィールドを追加する場合と、オプションでメールシステム内のループの検出を試みる場合とを除き、そうしてはならない(MUST NOT)

メールゲートウェイ

  • リレー機能はインターネットの SMTP トランスポートサービス環境内で運用される
  • MX レコードや様々な形式の明示的ルーティングは、あるトランスポートサービスから別のトランスポートサービスへの変換機能を実行する中間 SMTP サービスを必要とする可能性がある
    • ゲートウェイまたはゲートウェイ SMTP と呼ぶ
  • メッセージがメール環境の協会を通過するとき、ヘッダフィールドが書き換えられてもよい(MAY)
    • メッセージボディの検査や宛先アドレスの local-part の解釈が含まれてもよい
  • メールシステムによっては、SMTP エンベロープに相当するものを持たない
    • メッセージがインターネット環境から離れるとき、メッセージのヘッダセクションに SMTP エンベロープの情報を組み入れる必要がある可能性がある
      • 例えば "X-SMTP-MAIL:" と "X-XMTP-RCPT:"
      • これは、別環境のメールプログラムの変更を必要とするかもしれず、機密情報を公開する危険を冒す可能性がある
  • メッセージをインターネット環境の内側または外側へ転送するとき、ゲートウェイは "Received:" 行を追加しなければならない(MUST)
    • すでにヘッダセクションに追加されている "Received:" 行を変更してはならない(MUST NOT)
    • ゲートウェイは、Received ヘッダフィールドの via 節でその環境とプロトコルを示すべき(SHOULD)
  • インターネット側からみたとき、ゲートウェイは、SMTP コマンド内および RFC 822 ヘッダセクション内の有効なすべてのアドレスと有効な RFC 822 メッセージとを、すべて受け入れるべき(SHOULD)
  • ゲートウェイによって生成されたアドレスおよびヘッダフィールドは、適用可能な規格(RFC 5321 および RFC 5322)に従わなければならない(MUST)
  • ゲートウェイはインターネットのメール環境へと転送するメッセージのすべてのヘッダフィールドがインターネットメールのための要求事項に従う事を保証しなければならない(MUST)
    • 特に "From:"・"To:"・"Cc:" などのヘッダフィールド内のすべてのアドレスは、RFC 5322 の標準ヘッダ構文を満たすように、(必要なら)変換されなければならない(MUST)
      • 同時に、完全ドメイン名のみを参照しなければならず(MUST)、返信先として有効でなければならない(MUST)

セッションと接続の終了

  • クライアントが QUIT コマンドを送信したとき、SMTP は終了する
    • サーバは肯定リプライコードで応答した後、接続を閉じる
  • 以下をのぞき、SMTP サーバは通常の運用環境において故意に接続を閉じてはならない(MUST NOT)
    • QUIT コマンドを受信し、221 リプライで応答した後
    • SMTP サービスをシャットダウンする必要性を検出し、応答コード 421 を返した後
    • クライアントのコマンドまたはデータの送信を待機している間にタイムアウトが発生した場合
  • 特に、理解できないコマンドに対して接続を閉じるサーバは仕様に違反する
    • サーバは未知のコマンドに寛容であり、500 リプライをはっこうしてクライアントからの更なる指示を待つ事が期待される
  • 自身のコントロール害の状況により接続の終了、リセット、または他の通信障害に遭遇した SMTP クライアントは、メールシステムの堅牢性を維持するために、451 応答を受け取ったかのようにメールトランザクションを扱い、それに従って動作するべき(SHOULD)

メーリングリストとエイリアス

  • SMTP 能力を持つホストは、複数配送のためのエイリアスとリストモデルによるアドレス展開を両方サポートすべき(SHOULD)
  • 展開されたリストの各アドレスにメッセージが配送または転送されるとき、エンベロープ内のリターンアドレス("MAIL FROM:")は、そのリストを管理する人物または団体のアドレスに変更されなければならない(MUST)
    • ただし、メッセージのヘッダセクションは変更されてはならない
  • 重要なメール機能は、仮想メールボックスアドレスを宛先メールボックスアドレスのリストに変換(または展開)または拡大することにより、単独のメッセージを複数の宛先に配送するメカニズム
    • そのような仮想メールボックス(時にエクスプローダと呼ばれる)にメッセージが送られたとき、展開されたリスト内の各メールボックスにそのコピーが転送または再配送される
  • サーバはリスト上のアドレスを単純に使用すべき(SHOULD)
    • 一部のアドレス(例えば発信者のアドレス)を削除するために発見的または他のマッチング規則を適用する事は、全く推奨されない
    • 仮想メールボックスをその展開規則に基づき、エイリアスまたはリストと分類する
  • エイリアスを展開するために、受信メーラーはエンベロープ内の仮想メールボックスアドレスを展開された各アドレスへと順々に単純に置き換える
    • エンベロープの残りとメッセージボディは変更されない
    • メッセージは展開された各アドレスに配送または転送される
  • メーリングリストは転送でなく再配送によって動作すると考えられる
    • リストを展開するために、受信メーラーはエンベロープ内の仮想メールボックスアドレスを展開された各アドレスへと順に置き換える
    • 最終配送者によって生成されるすべてのエラーメッセージが、メッセージ発信者ではなくリスト管理者に返されるように、エンベロープ内のリターンアドレス(後方指示アドレス(backward-pointing address))が変更される
    • エイリアスとの重要な違いが後方指示アドレスの変更である事に注意

SMTP 仕様

(略)

アドレス解決のメール処理

宛先ホストの検索

  • SMTP クライアントが処理のために配送されるドメインを特定すると、そのドメイン名を解決するために DNS ルックアップが実行されなければならない(MUST)
  • ルックアップは最初に、名前に対応する MX レコードの検索を試みる
  • CNAME レコードが見つかった場合、その結果として得られた名前が最初の名前であったかのように処理する
  • ドメインが存在しない旨のエラーが返された場合、その状況はエラーとして報告されなければならない(MUST)
  • 一時的エラーが返された場合、メッセージはキューに入れられr、後にリトライされなければならない(MUST)
  • 空の MX リストが返された場合、そのアドレスはそのホストを指す優先度 0 の暗黙的 MX RR に対応するものとして扱われる
  • 指示された MX レコードがどれもしよう不可能な場合、または暗黙的な MX が利用不可能な場合、その状況はエラーとして報告されなければならない
  • ある特定の名前に対しひとつまたは複数の MX RR が見つかった場合、それが MX RR を使用して位置づけられたのではない限り、その名前に対応するアドレス RR を使用してはならない(MUST NOT)
    • 暗黙的 MX の規則は、MX レコードが全くない場合のみ適用される
    • MX レコードはあるが、そのいずれもが使用できない場合、その状況はエラーとして報告されなければならない(MUST)
  • MX RR に対応するドメイン名が見つかり、対応するデータフィールドが取得されたとき、その応答のデータフィールドはドメイン名を含まなければならない(MUST)
  • MX レコードは優先順位を持ち、2 つ以上のレコードが現れた場合のソートに使用されなければならない(MUST)
    • 小さい値は大きい値より優先順位が高い
    • 同じ優先順位で複数の宛先が存在し、どちらかを優先する明確な理由がなければ、それらをランダムに選択しなければならない(MUST)

問題の検出と対応

(メモ略)

セキュリティ考察

(メモ略)

Last modified:2009/11/01 00:49:36
Keyword(s):[network] [SMTP]
References: