事の発端：全ての設定が正しいのにメールサーバ向けに通信出来ない、、、
プロジェクトにて、オンプレミスのメールサーバとAWS上に構築したメールサーバを統合する機会がありました。
アプリのメール機能は作成済みで、必要な作業は以下2点というシンプルな作業の想定でした。
- アプリケーションの環境変数にてメールサーバのDNS名を設定
- アプリケーションサーバのSGにてメールサーバ向けのアウトバウンド通信の許可ルールを追加
(事前にAWS－オンプレ間のルーティングに関しては実装の妥当性が担保されていたため、特に設定は不要）
通信ポートはメールサーバ側の仕様で25が指定されていたので、その通りにSGを設定してメールの送信テストを実施しましたが、結果は失敗。
NACL・SGの設定確認、名前解決、Reachbility Analyzerでの疎通検証はどれもOK。
ですが、VPCフローログでは、アプリケーションサーバのENIからのアウトバウンドがそもそもREJECTされているようで、オンプレとVPCの接点となるTransit Gatewayにすらそもそも到達していない形でした。
なぜ疎通できなかったのか
AWSの仕様でデフォルトではポート25番でのアウトバウンド通信が拒否されていることを把握出来ていませんでした。
ポート25で通信する場合は事前にAWS宛てで許可申請を上げねばなりませんでした。
ちなみに、以下のような申請文で申請を上げました。利用用途及びスパム・誤発信防止のメカニズムを情報として提供するようAWS側から言われます。
Use Case:
本アカウントにて構築している EC2 インスタンスから、社内向けシステムに対しメール通知を送信する必要があります。
（基幹システムからの社内ユーザ宛ての業務メールの送信）
本ユースケースにおいては、外部 SMTP サーバに対して直接 25 番ポートで接続し、メール送信を行う必要があります。
当アカウントは迷惑メール送信には一切利用せず、必要最低限のシステム通知用途に限定されます。
スパム防止メカニズムの概要
1. 送信元の制御
* 25番ポートでのメール送信は、原則特定の サブネットのIP CIDR内のEC2 インスタンス（Applicationサーバ（EKS Node））からのみ行います。
* 25番ポートでのメール送信元 IP はサブネットのCIDR内に限られ、セキュリティグループにより、特定の外部 SMTP サーバへの通信のみが可能であるよう通信を制限しています。
* また、25番ポートへのメール送信は原則社内ネットワーク内のプライベートIPアドレスからのみ実施します。
2. 利用用途の限定
* 本メール送信は、社内通知・顧客システム連携の業務メールのみに利用します。
* 想定送信数は 1 日あたり平均xxx通程度であり、大量送信や広告・宣伝メールには利用しません。
3. 運用上の監視・制御
* メール送信のログを定期的に監視し、異常な送信や大量送信が発生しないことを確認します。
* 不正利用が疑われる場合は即座に対象インスタンスを隔離・停止できるよう運用体制を整えます。
なぜこのような仕様になっているのか。
そもそも25番ポートって何？
25番ポートは、SMTPでメールを配送するための代表的なポートです。SMTPはメール送信に使われるプロトコルで、特に25番ポートは歴史的に、メールサーバ同士がメールを中継・配送するための通信に使われてきました。
ここで大事なのは、25番ポートは「利用者がメールアプリから送信するための口」というより、メールサーバが外部のメールサーバへメールを届けるための口だという点です。
つまり25番ポートは、普通のWebアクセスのような一般的な通信ではなく、メール配送基盤に直接つながるための通信経路と考えられます。
何が危険なのか、なぜ制御しているのか
スパムの防止
25番ポートが問題になりやすい理由は、悪用されるとスパムメールやフィッシングメールの大量送信に直結しやすいからです。
もしクラウド上のサーバから誰でも自由に25番ポートで外部へ送信できると、攻撃者がそのサーバを踏み台にして大量の迷惑メールを送ることが容易になります。AWSがEC2で25番ポートを既定で制限しているのは、まさにこのリスクを抑えるためです。AWS公式にも、25番ポートの outbound 通信制限が明記されています。
送信元IPの信頼性担保
さらに厄介なのは、メールの世界では送信元IPアドレスの信用が非常に重視されるようです。
スパム送信が増えると、受信側はその送信元のIPやネットワークを警戒し、ブロックしたり、迷惑メール判定を強めたりします。すると、不正利用した一部のサーバだけでなく、同じクラウド基盤を使う正当な利用者のメールまで届きにくくなるおそれがあります。
つまり25番ポートの悪用は、単なる1台の問題ではなく、クラウド全体の信頼性やメール到達性に影響しやすいのです。AWSが申請制にしているのは、その影響範囲が大きいからです。
要するに、AWSが25番ポートを制御している理由は、次のように整理できます。
25番ポートはメール配送の中核に使われるため、悪用されると大量スパム送信の踏み台になりやすい。
その結果、AWSのIP帯全体の評判が悪化し、他の正当な利用者にも影響が及ぶ。
そのためAWSは、25番ポートだけを既定で厳しく制限し、正当な用途だけ申請で解除できるようにしている。
587番ポート等との違い
25番ポートとよく比較されるのが、587番ポートや465番ポートです。
587番ポートは、メールサーバ同士の配送用ではなく、クライアントやアプリから認証付きでメールを送るためのポートという位置づけです。TLS暗号化やSMTP認証が必須（推奨）となるみたいです。
以下で分かりやすく解説してくれています。
一方、465番ポートは接続直後からTLS暗号化が強制されるポート番号のようです。587番ポートよりもより安全性が高いポート番号と捉えれば良いと思います。
つまり、25番ポートは「サーバ間の配送・中継用」、587番や465番は「クライアントからの投稿用」と考えると理解しやすいです。
AWSが25番を厳しく見ているのは、メール配送基盤に直接つながるポートだからであり、通常のアプリケーションからのメール送信には、SESや587番・465番のような認証を前提としたポート番号を使ってほしい、という考え方にあると推察されます。
仕様を理解していたら今回のケースではどうなったか
では、今回のケース、仕様を理解していたらどうなったでしょうか。
IFの話なので実際どうなったかは分かりませんが、25番ポートでのメール送信のリスクを踏まえて、こういった制限がベンダ側で実施されている点までトラブルシュートが踏み込めたかもしれません。
これは、単にSGとNACLで通信先を許可、フローログで通信状況を可視化出来る、等クラウドの機能を捉えただけではたどり着かない発想です。
（現に私も考え得る設定値が全て正しかったことで、？？？となっていた）
特にこういったインフラ回りの設計は、セキュリティリスクに直結することが多いため、なおのこと深い知識理解が必要だと感じました。
また、今回は作業者として設定するのみであったため良かったですが、こういった裏側の仕様や背景を踏まえて設定を行わないと、要件定義や設計にてクライアント側にリスクを説明することが出来ません。
この点を踏まえても、クラウドの背景にある仕様理解がとても大事だと気付かされた一件でした。