サブミッションポート詳細

1年以上前の記事です。内容が古い可能性があります。

どうも微妙に勘違いしていたようです。
□突然メールが送信できなくなった（サブミッションポート）

さて、「Outbound Port25 Blocking」を理解する前にメールの仕組みを理解しなければなりません。
□メールの仕組みを理解しよう ― Mizushima Network Service
ポイントとなるのはここです。

POPサーバーというのはメールをダウンロードしてくる受信サーバーを指し、SMTPサーバーというのはメールを転送する送信サーバーを指します。
要するにPOPが受信です。
でもSMTPは送信だと思わないでください、SMTPはあくまでも転送です。

つまり、受信に関してはすでにメールサーバー内にメールが届いているわけですから、
そのサーバーにアクセスして認証させれば受信できるということになります。
イメージとして表現するなら「クライアント（自分のパソコン）をA」、「メールサーバー（プロバイダで用意されているもの）をB」とすると、
「A」→「B」→「A」といった感じです。
ところが、送信に関しては送信ではなく転送だというのはこういうことです。
さらに「送信先のメールアドレスが使っているメールサーバーC」と「送信先のクライアント（相手先のパソコン）D」が加わって、
「A」→「B」→「C」→「D」といった感じになります。
つまり、「B」→「C」の部分が転送だとこういうわけです。
（実際は「C」→「D」の間で上記同様「D」→「C」→「D」のやり取りが生じます）
わかりますでしょうか？

それでは、話を「Outbound Port25 Blocking」に戻します。
これに関してはIPアドレスを考えたほうがわかりやすいでしょう。
上記で説明しますと。
通常は「A」と「B」は同じプロバイダから与えられたIPアドレスになります。
つまり、25番ポートの通過が認められたIPアドレスということになり、
サブミッションポートの設定をする必要がないということになります。
ところが、今回会社で起こった事例では接続業者とサーバー業者が別の会社になっています。
つまり「A」と「B」のマシンのIPアドレスが同じ業者から与えられたものではない、
よって、OP25Bにより「A」から「B」への25番によるリクエストは遮断され、
サブミッションポート587番で行わなければならなくなっていたということです。
図にしてみましょう。
「A」→587→「B」→「C」→「D」
ここで疑問が発生します。何故587番を通ったリクエストが認証を必要とせずに「B」で処理されたのでしょうか？

それに関してのヒントもこちらのサイトにありました。
□サブミッションポート（submission port）とは ― Mizushima Network Service

自宅サーバー的立場からみるとこのOutbound Port25 Blockingとサブミッションポートとはどのようなものでしょう？
発行したアカウントが外からポート25を用いて接続できなくなります。
この問題点を改善するには、当然ながらポート25意外を利用すれば良いことになります。
対応方法その1　サブミッションポート対応SMTPサーバーならば、サブミッションポートを開放すればそれだけで問題なくなるでしょう。
対応方法その2　IPマスカレード対応ルーターを利用します。ルーター外側のポート587を、ルーター内側のポート25に対応させます。
対応方法その3　この方法がもっともオススメです。SSL化することでポート465を利用する、同時にセキュリティ的にも効果があります。

そもそも、現在会社で使っているホスティングサービスは、インターネットサーバー一台丸ごとレンタルの契約なので自宅サーバーにかなり近いのです。
つまり、上記の対策を採っている可能性は十分ありえるかと。
もしも、対応方法その2（もしくはその3）あたりを使っているとしたらポート587がルーター部分でポート25（もしくは465）に変換されているので、
メールサーバー側での認証が不必要になるのではないか？

これに関しては実際うちの自宅サーバー使って実験してみます。
報告は後日。

注）画像はイメージです。決してブログ作者ではありません。