FrontPage  Index  Search  Changes  RSS  Login

[network] Message Submission for Mail - SMTP 関連メモ

概要

SMTP を理解していないので、ある程度理解を深めようと思い、RFC などを参考に情報を集めた。

Message Submission for Mail

参考資料

要点

  • submission = 投函
  • メッセージ投函とメッセージ中継を分離する事で、それぞれのサービスを独自の規則に従って運用できる様にする
  • メッセージの中継や最終的な配送には影響がなく、ポート 25 条で SMTP を使い続ける
  • メッセージ投函は、通常、ポート 587 上でこの仕様で定義するプロトコルを用いる

はじめに

  • SMTP はメッセージ「転送」プロトコルとして定義されたが、現在では、メッセージ「投函」プロトコルとしても使われている
  • MUA からのメッセージ投函を受け入れるプログラムがメッセージ投函エージェント(MSA)と呼ばれる
  • ワームやウィルスに感染した機器や、大量のスパムを生成する悪意あるソフトウェアの流行によって、現在では多くのサイトでは標準 SMTP ポート(25)での送出トラフィックを禁止している
    • 代わりに、すべてのメール投函は投函サーバを通じて行われる
  • メッセージを投函と転送に分割すると、開発者やネットワーク管理者にとって以下の事が容易になる
    • セキュリティポリシーを実装し、権限のないメール中継や迷惑メールの注入を防ぐ
    • 認証済み投函を実装する
    • 中継と投函のそれぞれに、もっと単純な別々のプログラムを用意する
    • メールクライアントの設定に関する問題を検出する

メッセージの投函

投函の識別

  • ポート 587 を電子メールメッセージ投函用に予約する
    • このポートで受信されるメッセージは投函であると定義される
    • 使われるプロトコルは ESMTP であり、ここで定義するように追加の制約または容認がある

メッセージの拒否と宛先不明による返送

  • MTA と MSA は、メッセージが投函か中継かに部分的に基づくメッセージ拒否規則を実装してもよい(MAY)
  • 例)
    • MTA:ローカルユーザを参照しないメッセージメッセージに対するすべての RCPT コマンドを拒否するように設定
    • MSA:認証済みアイデンティティか被保護 IP 環境内にある投函終端のいずれかに基づいた権限を用い、権限あるユーザ以外からのメッセージ投函すべてを拒否する様に設定
  • NOTE: 損傷あるメッセージを送るリスクを冒すよりも、メッセージを拒否する方がよい
  • MSA が投函ユーザへの返送経路を、有効な MAIL FROM 、有効な送信元 IP アドレス、認証済みアイデンティティのいずれからも決定できない場合、すぐにメッセージを拒否すべき(SHOULD)
    • メッセージ拒否は MAIL コマンドに対する 550 応答
  • ゼロの返送経路、"MAIL FROM:<>"は許容される
    • ゼロ返送経路がメッセージ拒否の理由であってはならない(MUST NOT)
  • 投函されているメッセージに対して MSA が有効な返送経路を決定できない場合を除き、本仕様中の MSA に拒否コードを発効させる規定に対して、メッセージを受け入れた後で返送メッセージを生成する方法で準拠してもよい(MAY)
    • 通常のメッセージ投函の場合、ユーザと MUA に直接反応が与えられるので、すぐにメッセージを拒否する方法が好ましい
    • 遅延返送メッセージを正しく処理する機能をもった MUA は少ない

権限のある投函

  • 認証済み SMTP (SMTP-AUTH)
  • IP アドレス制限
  • セキュア IP とその他のトンネル
  • 先行 POP 認証

必須の動作

汎用投函拒否コード

  • 不正な MAIL, RCPT, DATA コマンドの拒否にふさわしい応答コードがなければ 554 を使う

すべてのドメインが完全修飾である事を保証する

  • MSA は SMTP エンベロープ中のすべてのドメインが完全修飾であることを保証しなければならない(MUST)
  • 不正なドメイン参照を含む MAIL, RCPT, DATA コマンドの拒否には 554 を使う

認証を要求する

  • MSA は自身が既に個別に認証または権限付与を確立していない限り
    • セッションが SMTP-AUTH を使って認証されていない場合はデフォルトで MAIL コマンドへのエラー応答を発行しなければならない(MUST)

推奨される動作

アドレス文法を強制する

  • MSA は送信または受信 SMTP エンベロープのアドレスに不正な文法があるメッセージを拒否すべき
  • MSA が追跡ヘッダフィールド以外の方法でメッセージテキストを検査または変更する場合は、アドレスヘッダフィールド中に不正なアドレス文法のあるメッセージを拒否すべき(SHOULD)
  • 不正なアドレスが検出された MAIL コマンドや RCPT コマンドの拒否には応答コード 501 を使う
  • アドレスをメッセージ本体の投函後に解決する場合、メッセージがヘッダに不正なアドレスを含むときには、end-of-data(データの終わり)の後に応答コード 554 を使う

エラーをログに記録する

  • MSA はメッセージエラー、特にクライアントソフトウェアの明らかな誤設定をログとして記録すべき(SHOULD)
  • ローカルメールクライアントに問題が検出されたときには、管理者に通知すると役立つ
    • これは、投函と中継を区別する方式の利点
    • システム管理者はローカル設定の問題には興味を持つが、外部のクライアントの問題には興味を持たない
  • ある種のサービス拒否攻撃を防ぐためには、このようなログには制限を課す事が重要

オプションの動作

投稿権を強制する

  • "MAIL FROM:" の中のアドレスの投稿権が不十分に見える場合や、(セッションが認証されているなら)使われた認証で権限が付与されていない場合、MSA は MAIL コマンドにエラー応答を発行してもよい(MAY)
  • 応答コード 550 を返す
    • SMTP-CODES 5.7.1

権限を強制する

  • (セッションが認証されている場合)ユーザに与えられた許可に矛盾があるなら、MSA は RCPT コマンドへのエラーを発行してもよい(MAY)
  • 応答コード 550 を返す
    • SMTP-CODES 5.7.1

メッセージデータを検査する

  • 投函されたメッセージが文法的に無効な場合、またはユーザに与えられた許可に矛盾がみられる場合や、何らかの方法でポリシーに反する場合
    • MSA は DATA コマンドへのエラー応答を発行するか、end-of-data 後に失敗という結果を送っても良い(MAY)
  • データ中の文法問題には応答コード 554 を使う
  • コマンド自体が文法的に無効な場合は応答コード 501 を使う
  • 投稿するユーザに基づく拒否には応答コード 550 を使う
    • SMTP-CODES 5.7.1
  • メッセージがサイトポリシに反する場合には応答コード 550 を使う
    • SMTP-CODES 5.7.0

メール管理者(postmaster)のアドレスをサポートする

  • MSA は 1 個以上のドメインで、他のアドレスに対して強制する要求に比べて postmaster (または同等の別名)宛のメールに対する認証の程度を軽くしてもよい(MAY)
    • ローカルにおいて適切な場合、および SMTP-MTA の postmaster 要求への準拠を容易にするため

SMTP 拡張機能

  • 今後の SMTP 拡張機能は、投函ポートで有効かどうかを明確に定義すべき(SHOULD)
  • SMTP-CODES のサポートおよび使用は CODES-EXTENSION に従うべき(SHOULD)
  • MSA は PIPELINE をサポートすべき (SHOULD)
  • MSA は SMTP-AUTH をサポートしなければならない(MUST)
    • SMTP-AUTH によって、MSA が投函ユーザの権限を検証し、アイデンティティを決定できるようになる
  • 本文書中の DATA コマンドへの参照は、CHUNKING とともに使われる BDAT コマンドなど、DATA コマンドの同等物にも当てはまる

メッセージの修正

  • サイトは標準やサイトポリシへの準拠を保証するために、投函を修正してもよい(MAY)
  • MSA が転送または配送するメッセージは必ず、SMTP-AUTH と MESSAGE-FORMAT の要求に準拠しなければならない(MUST)

"Sender" の追加

  • 送信者のアイデンティティが基地であり、"From" フィールドからとったものでない場合、MSA は "Sender" フィールドを追加または置換してもよい(MAY)
  • MSA は "Sender" フィールドに入れるアドレスが実際に有効なメールアドレスである事を保証しなければならない(MUST)

"Date" の追加

  • MSA は投函されたメッセージに "Date" フィールドが欠けている場合、"Date" フィールドを追加してもよい(MAY)
  • また、投函メッセージの "Date" フィールドが MESSAGE-FORMAT 文法に準拠していない場合、"Date" フィールドを訂正してもよい(MAY)

"Message-ID" の追加

  • "Message-ID" フィールドが欠けている場合や、有効な文法でない場合、MSA は "Message-ID" フィールドを追加または置換すべき(SHOULD)
  • 多くのクライアントは "Message-ID" フィールドを生成しない

転送符号化

  • MSA は、必要でかつ MIME タイプに害を与えない場合、MIME 慣例に従ってメッセージに転送符号化を適用してもよい(MAY)

メッセージの署名

  • MSA はメッセージに署名するか、他の認証情報を追加してもよい(MAY)

メッセージの暗号化

  • MSA は組織のポリシを反映させるため、伝送するメッセージを暗号化してもよい(MAY)
  • MSA による署名や暗号化は通常、MUA と MSA の間の通信自体が、何らかの方法で保護されている事を意味する
    • 安全な環境内で行われている
    • トランスポート層での投函接続が保護されている
    • セッションの一貫性を提供する SMTP-AUTH 機構が使われている

エイリアスの解決

  • MSA はローカルポリシに従って、SMTP エンベロープや場合によってはアドレスヘッダフィールド内で、ドメイン名に対するエイリアス(CNAME レコード)を解決してもよい(MAY)
  • 無条件のエイリアス解決は有害な事がある
    • www.example.net と ftp.example.net のどちらも mail.example.net のエイリアスである場合、それらを置き換えると有用な情報を失うことになる

ヘッダの置き換え

  • MSA はローカルポリシに従って、SMTP エンベロープや場合によってはアドレスヘッダフィールド中のローカル部分やドメインを書き換えてもよい(MAY)
  • 例えば、サイトはログイン名を隠蔽するために "JRU" を "J.Random.User" に、またマシン名を隠蔽し、ユーザの移動を容易にするために "squeaky.sales.example.net" を "zyx.example.net" に置き換えたいなど
  • 特定のローカル MSA 設定に合致する専用アドレス、ローカル部分、ドメインは変更すべき
  • MSA がドメイン名の最初の要素を必ず削除すると行った、データに依存しない書き換え規則を適用する事は非常に危険
  • MSA は、ローカル部分の変更において SMTP-MTA の制約に反する方法で転送先アドレスを書き換えてはならない(MUST NOT)

セキュリティに関する考察

  • メッセージの投函と中継の分離によって、サイトはこの 2 種類のサービスに対し別々のポリシを実装できるようになる
  • サービスの分離は、迷惑メールの追跡や防止に役立つ
    • MSA が受け入れる前に認証を要求し、MTA が非ローカルユーザに対するすべての RCPT コマンドを拒否するように設定できる
    • サイトがメッセージ投稿に何らかの形式での権限を要求しない場合、そのサイトのリソースや名前は誰にでも使えるようになる
    • そのサイトの設備を使って迷惑メールを注入できるということ
Last modified:2009/11/01 00:51:22
Keyword(s):[network] [SMTP]
References: