メインコンテンツまでスキップ

7. セキュリティに関する考慮事項 (Security Considerations)

7.1. メールセキュリティとスプーフィング (Mail Security and Spoofing)​

SMTPメールは、以下の理由により本質的に安全ではない:

  • 組み込みの認証機能の欠如
  • 送信者アドレスの簡単な偽造
  • 基本プロトコルでの暗号化の欠如

MAIL FROMおよびRCPT TOアドレスは、簡単に偽造できる。SPF、DKIM、およびDMARCなどの追加プロトコルがスプーフィング (spoofing) の軽減に役立つが、これらはコアSMTPの一部ではない。

7.2. 「ブラインド」コピー ("Blind" Copies)​

BCC (Blind Carbon Copy、ブラインドカーボンコピー) 受信者は、メッセージヘッダーに表示されてはならない (MUST NOT)。これは通常、以下の方法で処理される:

  • BCC受信者用に個別のSMTPトランザクションを作成する
  • 送信前にBCCヘッダーフィールドを削除する

7.3. VRFY、EXPN、およびセキュリティ (VRFY, EXPN, and Security)​

VRFY (検証) およびEXPN (展開) コマンドは、有効な電子メールアドレスを収集するために使用される可能性がある。サーバーは以下を行ってもよい (MAY):

  • これらのコマンドを無効にする
  • 使用前に認証を要求する
  • アドレスの有効性を確認しない汎用応答を返す

7.4. 251および551応答コードに基づくメール再ルーティング (Mail Rerouting Based on the 251 and 551 Response Codes)​

応答コード251 (ユーザーがローカルではない、転送する) および551 (ユーザーがローカルではない) は悪用される可能性がある:

  • 転送アドレスを発見するため
  • アドレス収集のため
  • トラフィック分析のため

サーバーは、自動転送とこれらの応答で開示される情報について慎重であるべきである (SHOULD)。

7.5. アナウンスメントにおける情報開示 (Information Disclosure in Announcements)​

サーバーグリーティング (220応答) およびEHLO応答は、以下を開示すべきではない (SHOULD NOT):

  • 詳細なソフトウェアバージョン情報
  • 内部システムアーキテクチャ
  • セキュリティ構成の詳細

攻撃者は、この情報を使用して既知の脆弱性を標的にすることができる。

7.6. トレースフィールドにおける情報開示 (Information Disclosure in Trace Fields)​

Receivedヘッダーフィールドには以下が含まれる:

  • IPアドレス
  • ホスト名
  • タイミング情報
  • 内部ネットワークトポロジー

デバッグに必要であるが、この情報は以下に使用される可能性がある:

  • ネットワークマッピング
  • トラフィック分析
  • セキュリティインフラストラクチャの識別

7.7. メッセージ転送における情報開示 (Information Disclosure in Message Forwarding)​

メッセージを転送する際、サーバーは以下を行うべきである (SHOULD):

  • 内部アドレスの開示を避ける
  • 信頼境界を越える際にトレース情報をサニタイズする
  • 自動転送のプライバシーへの影響を考慮する

7.8. 攻撃への耐性 (Resistance to Attacks)​

SMTPサーバーは、以下に対する保護を実装すべきである (SHOULD):

サービス拒否 (Denial of Service, DoS)​

  • ソースごとの接続制限
  • レート制限
  • リソース消費制限
  • タイムアウトの強制

バッファオーバーフロー​

  • 厳格な入力検証
  • 長さ制限の強制
  • 安全な文字列処理

コマンドインジェクション​

  • コマンドの適切な解析
  • 引数の検証
  • 不正な形式の入力の拒否

ディレクトリハーベスト攻撃​

  • RCPT TOコマンドのレート制限
  • 遅延または汎用応答
  • スキャン動作のログ記録とブロック

7.9. SMTPサーバーの動作範囲 (Scope of Operation of SMTP Servers)​

SMTPサーバーは以下を行うべきである (SHOULD):

  • 動作範囲を明確に定義する
  • 適切なアクセス制御を実装する
  • 以下を区別する:
    • 内部メッセージ送信
    • 外部メッセージリレー
    • 最終メッセージ配信

オープンリレー (open relays) (誰からでも、どこへでもメールを受け入れて転送するサーバー) は、以下の理由により展開してはならない (MUST NOT):

  • スパム配信を可能にする
  • 悪用を促進する
  • インターネットメールインフラストラクチャに害を与える

推奨されるセキュリティプラクティス​

  1. TLS/STARTTLSの使用: 可能な場合は接続を暗号化する
  2. 認証の実装: メッセージ送信にSMTP AUTHを要求する
  3. SPF/DKIM/DMARCの展開: 送信者認証を追加する
  4. レート制限: 悪用とDoS攻撃を防ぐ
  5. アクセス制御: リレーアクセスを適切に制限する
  6. ログ記録: セキュリティ分析のための詳細なログを維持する
  7. 定期的な更新: セキュリティパッチを迅速に適用する
  8. モニタリング: 疑わしい活動を検出して対応する
に最終更新