← RFC Reference

RFC 6409 – メール送信のためのメッセージ送信

このRFCが存在する理由

電子メールの初期段階では、ユーザーが新しいメッセージを送信することと、サーバーが別のサーバーからメールをリレーすることの区別がありませんでした。どちらもポート25を使用し、誰でも接続して送信できました。これはオープンリレーの問題につながり、スパマーは認証なしでメールを受け入れて転送するサーバーを悪用しました。

RFC 6409（元々1998年のRFC 2476、2006年にRFC 4409として更新、2011年にRFC 6409として最終化）はメッセージ送信とメッセージリレーを正式に分離します：

• 送信（ポート587）：認証されたユーザーまたはアプリケーションが配信のための新しいメッセージをメールサービスに送信します。サーバーはMSA（RFC 5598）として機能します。
• リレー（ポート25）：メールサーバーが別のメールサーバーにメッセージを転送して、宛先に向かいます。サーバーはMTAとして機能します。

この分離は現代の電子メールセキュリティの基礎です。送信者の認証、ポリシー施行、および認証されていないリレーをブロックしながら正当な送信を受け入れることが可能になります。

仕組み

メッセージ送信はRFC 5321で定義されているのと同じSMTPプロトコルを使用しますが、動作、ポリシー、およびポート番号の重要な違いがあります。

送信プロセス

1. クライアント（MUAまたはアプリケーション）がポート587でMSAに接続します。
2. クライアントがEHLOを発行して利用可能な拡張機能を検出します。
3. クライアントがSTARTTLSを使用してTLSにアップグレードする（またはRFC 8314に従ってポート465でのIPL TLSを使用して接続する）。
4. クライアントがAUTH（RFC 4954）を使用して認証します。通常はPLAINまたはLOGIN over TLS。
5. クライアントがMAIL FROM、RCPT TO、およびDATAを使用してメッセージを送信します。
6. MSAがメッセージを検証し、潜在的に不足しているヘッダー（Date、Message-ID）を追加し、MTAインフラストラクチャ経由で配信用にキューに入れます。

送信対リレー：並べて表示

SMTPの例

ポート587での一般的な送信セッション：

重要な技術的詳細

認証は必須です

RFC 6409は、MSAが認証を要求すべき（SHOULD）ことを述べており、組織ポリシーによる特定の許可がない限り、認証されていないクライアントからのリレー用メッセージを受け入れてはならない（MUST NOT）。実際には、すべての現代的な送信サーバーが認証を要求します。標準的なメカニズムはSMTP AUTH（RFC 4954）で、PLAINまたはLOGINメカニズムをTLS経由で使用します。

MSAによるヘッダー修正

MTA（メッセージコンテンツを変更してはいけない）とは異なり、MSAは送信されたメッセージを検査して修正することが期待されています：

• 不足しているDateヘッダーを追加クライアントが含めなかった場合。
• 不足しているMessage-IDを追加すべてのメッセージが一意の識別子を持つことを保証します。
• Fromアドレスを検証認証されたアイデンティティと一致するか、Sender:ヘッダーを追加して実際の送信エンティティを示します。
• トレースヘッダーを追加。MSAが独自のReceived:ヘッダーを最初のエントリとして追加します。

ポート465：インプリシットTLS

歴史的には、ポート465は一時的に「SMTPS」（インプリシットTLS経由のSMTP）に割り当てられ、その後再割り当てされ、その後2018年のRFC 8314によって再標準化されました。今日、インプリシットTLSを使用したポート465は送信の推奨アプローチです。TLSハンドシェイクは接続時に直ちに行われ、SMTPコマンドの前に行われます。STARTTLS付きのポート587は広くサポートされており有効です。

サイズとレート制限

MSAは通常MTAよりも厳格な制限を施行します：

• メッセージサイズ制限（一般的に10～25MB）
• 認証されたユーザーあたりのレート制限（侵害されたアカウントがスパムするのを防ぐため）
• メッセージあたりおよび期間あたりの受信者数制限
• 送信者アドレス制限（使用を認可されているアドレスからのみ送信可能）

一般的な間違い

• ポート25からアプリケーションを送信します。アプリケーションは常に認証付きでポート587（または465）経由で送信すべきです。受信者のMXに直接ポート25で送信することは、メールサービスの認証、DKIM署名、およびレピュテーション管理をバイパスします。ほとんどのクラウドプラットフォーム（AWS、GCP、Azure）はデフォルトでアウトバウンドポート25をブロックします。
• AUTHの前にTLSを使用しません。暗号化されていない接続経由で認証情報を送信することは、SMTPユーザー名とパスワードを公開します。常にAUTHの前にSTARTTLSを実行するか、ポート465でインプリシットTLSを使用します。
• 送信認証情報とメールボックス認証情報を混同します。一部のサービスはSMTP送信用とIMAP/POPアクセス用に別々の認証情報を使用します。プロバイダーのドキュメントを確認してください。
• MSA拒否応答を無視します。MSAがメッセージを拒否した場合（たとえば、不正な送信者アドレス、メッセージが大きすぎる）、アプリケーションはエラーを正常に処理する必要があり、静かにドロップしません。
• アプリケーションコードでポート25をハードコーディングします。送信用にポート25に接続するレガシーアプリケーションは配信可能性の問題を引き起こし、ISPおよびクラウドプロバイダーがこのポート（非サーバー使用）をブロックするにつれて機能しなくなる可能性があります。
• STARTTLS後にEHLOを再発行しません。TLSハンドシェイクが完了したら、新しいEHLOを送信する必要があります。サーバーの機能リストは変更される可能性があります（認証は通常、暗号化が確立された後にのみアドバタイズされます）。

配信可能性への影響

• 認証はDKIM署名を可能にします。MSAを通じて送信すると、サービスはメッセージにDKIM署名を適用できます。リモートMTAに直接送信することはこれをバイパスします。つまり、メッセージは署名なしで到着し、スパムと見なされる可能性が高くなります。
• 送信者ID検証。MSAは、あなたが主張するアドレスから送信する権限があることを確認します。これにより、アカウントが他のドメインを偽造するのを防ぎ、送信レピュテーションを維持します。
• レピュテーション管理。メールサービス（MSA）は共有IP レピュテーションを維持します。送信経由でメッセージをルーティングすることにより、メッセージは主要なメールボックスプロバイダーとのサービスの確立されたレピュテーションから利益を得ます。
• フィードバックループ処理。メッセージを処理するMSAはバウンス、苦情、および配信ステータスを追跡でき、リスト衛生を維持し送信レピュテーションを保護するために必要なデータを提供します。
• あらゆところのTLS。TLS経由で送信する（送信に必須）ことにより、メッセージはアプリケーションからメールサービスまで暗号化されます。その後、サービスは次のホップの暗号化を処理し、転送中にエンドツーエンドの保護を提供します。

Related RFCs