25
サーバー間でメールを中継するためのポート。アプリから直接叩くべきではない番号であり、クラウドの VM でタイムアウトするのはメールサーバーが落ちているからではなく、事業者が塞いでいるからです。
自分の環境の行をそのまま実行してください。ポートを掴んでいるプロセス名と、バインドしているアドレスが出ます。たいていはそれだけで答えが分かります。
sudo lsof -nP -iTCP:25 -sTCP:LISTEN`-n` と `-P` でホストもポートも数値のままにするので、行は `:smtp` ではなく `:25` と読めます。NAME の列がバインド先で、`127.0.0.1:25` なら cron の出力を配送するためだけに入っている既定の Postfix によくあるローカル専用のメーラー、`*:25` ならこのマシンはネットワークからメールを受け付けています。COMMAND は Postfix だと `master` なので、無関係な何かと見間違えやすいところです。何も出ず終了コードが 1 なら誰も待ち受けていません。`sudo` なしでは root 所有のデーモンはまったく見えません。
sudo ss -tlnp 'sport = :25'`-t` で TCP、`-l` で待ち受けソケットのみ、`-n` でポートを数値のまま、`-p` で所有プロセスを出します。`127.0.0.1:25` はたいていのディストリビューションが出荷しているローカル配送だけの既定で、`0.0.0.0:25` や `[::]:25` はネットワークから届く状態なので、そうなっているなら意図した設定であるべきです。プロセスの列は `users:(("master",pid=812,fd=13))` のように出ます。`sudo` なしでもソケット自体は見えますが、プロセスは空欄になります。
sudo netstat -tlnp | grep ':25 '`ss` のないホスト向けの net-tools 版です。フラグの意味は同じで、最後の PID/Program name の列は自分の所有でないソケットについては特権が必要ですし、man ページ自身がこの値は信用できないと注意しています。パターン末尾の空白には意味があります。ないと `:25` が、代替の submission ポートとして非常によく使われる `:2525` や `:25000` にも当たります。
netstat -ano | findstr :25`-a` で待ち受けポートも含め、`-n` ですべて数値のまま、`-o` で最後の列に所有 PID が付きます。名前にするには `tasklist /FI "PID eq 1234"`。`findstr` は部分一致なので `:25` は `:2525` や `:25565` にも当たります。行動する前に Local Address 全体を読んでください。ワークステーションでここに見覚えのないリスナーがいたら、kill するより先に何なのかを調べる価値があります。
`nmap -Pn -p 25 mx.example.com` は、いま自分が立っている場所からそのポートがどう見えるかを教えてくれます。`open` はハンドシェイクが成立、`closed` はホストがリセットを返した、つまり到達はできるが誰も待ち受けていない状態、`filtered` は何も返ってこなかったということです。ただし 25 番に限っては、`filtered` は相手のメールサーバーが拒んでいるのではなく、自分側のネットワークが外向きのパケットを塞いでいることが非常に多いです。相手を疑う前に、別のネットワークからもう一度スキャンしてください。`--reason` で実際に観測されたのがどれかが分かり、`-sV` を付ければ SMTP のバナーを読んで、サーバーソフトウェアと、そのサーバーが自分をどの名前だと思っているかまで出してくれます。スキャンは自分が責任を持つホストにだけ。
| 出ているもの | 意味 |
|---|---|
The send hangs, then: Connection timed out / ETIMEDOUT connecting to mx.example.com:25 | SYN に誰も答えていません。クラウドの VM や家庭の回線では、これは宛先の問題ではなく、自分側で 25 番の外向きが塞がれているケースがほとんどです。Google Cloud は既定で塞いでいますし、消費者向け ISP も同様です。同じホストの 587 番を試せば切り分けられます。587 がつながって 25 がつながらないなら、塞いでいるのはあなたの側です。587 か 465 の認証つき submission に切り替えてください。 |
Connection refused connecting to mail.example.com:25 | ホストには届いていて、カーネルが明示的に接続を拒否しました。つまりあなたが叩いたアドレスでは MTA が待ち受けていません。ドメインの A レコードではなく MX レコードを引いたか確認してください。Web サーバーとメールサーバーはたいてい別のホストです。そのうえでメールサーバー自身の上でコマンドを実行してください。 |
550 5.7.1 Relaying denied / 554 5.7.1 <you@example.net>: Relay access denied | そもそもポートの問題ではありません。接続は成功し、サーバーはエンベロープを読んだうえで断っています。自分のドメイン宛のメールは受けるが、あなたのドメインのメールを転送する気はない、ということです。相手のサーバーを間違えているか、本当は認証つきの submission ポートを使うべきだったかのどちらかです。これをきちんと返すサーバーは、オープンリレーではないサーバーです。 |
bind: Address already in use when starting Postfix, Exim or a test SMTP server | 別のメールデーモンが既に 25 番を持っています。依存パッケージとして入った挙げ句ループバックにバインドしている、ディストリビューション既定の Postfix や Exim であることが非常に多いです。自分の環境のコマンドを実行してバインドアドレスを確認し、張り合うのではなく先住のほうを止めてください。`0.0.0.0:25` のリスナーがいると、特定のアドレスへの二度目の bind も塞がれます。 |
bind: Permission denied on port 25 as a normal user | 1024 未満は特権ポートなので、カーネルはメールの話に入る前に EACCES を返します。init システム経由でデーモンを起動するか、ローカルのテスト用リスナーなら 2525 のような高い番号を使ってクライアントをそちらに向けてください。 |
Mail is delivered but arrives unencrypted, or a STARTTLS negotiation fails mid-session | 25 番の STARTTLS は設計からして日和見的です。セッションは平文で始まり、サーバーが拡張を広告したときだけ昇格します。広告がない、経路で削られている、あるいは送信側が受け入れない証明書だった場合、送信側のポリシー次第で平文のまま配送されるか、セッションが切れるかのどちらかになります。秘匿性が要件なら、SMTP のコマンドを送る前に接続そのものが暗号化される 465 番の暗黙 TLS を使ってください。 |
IANA は 25 番を TCP・UDP 両方で `smtp` に割り当てていて、根拠は RFC 5321 系列ですが、使われるのは TCP だけです。RFC 5321 は、受信側のメールサーバーが「IANA がポート 25 として指定したポート」で常時待ち受けることを要求しています。うまくいかない連携がほぼ例外なく取り違えるのは、25 番が誰のためのものかという点です。これは MTA どうしがメールを受け渡すための経路で、ある組織のサーバーが別の組織のサーバーにメッセージを手渡す場所です。アプリケーションがプロバイダ経由でメールを送るためのポートではありません。その役目は submission 側の番号、つまり RFC 6409 が `submission` として登録した 587 と、RFC 8314 が暗黙 TLS 用に `submissions` として登録した 465 が担います。submission のポートは送信者を認証しますが、25 番は基本的に認証しません。送ってくるサーバーは見ず知らずの相手だからです。25 番の暗号化は日和見的です。RFC 3207 の STARTTLS は既に開いている平文セッションを昇格させる拡張なので、相手が広告していなければ、あるいは経路上の機器が広告を削り取っていれば、メールは平文のまま出ていき、どこも派手には失敗しません。手元で 25 番を持っているのは Postfix なら `master`、あるいは `exim4` や `sendmail` で、多くの Linux イメージは `cron` が出力をメールできるようにするためだけに、ループバックへバインドした状態でこれを起動します。あの待ち受けは無害で、`netstat` に見慣れない行が出る定番の理由です。
ここには別々の二つの問いが同居しています。受信側。ドメインのメールサーバーを本当に運用しているのでなければ、25 番でリスナーを立てないでください。誰にでも中継してしまう設定ミスのサーバーは数時間でスキャナーに見つかり、大量のスパム送信に使われ、抜けるより載るほうがずっと簡単なブロックリストにアドレスが載ります。運用するなら、自分のドメインと認証済みユーザーにしか中継しないことを確認し、流量を制限し、SPF・DKIM・DMARC を公開して、なりすましメールが他所で弾かれるようにしてください。送信側。25 番は塞がれている前提で設計してください。Google Cloud は「外部 IP アドレスの TCP 宛先ポート 25 に送られる下りパケットをブロックする」と明記したうえで、内部宛先と 465・587 には適用されないと注記していますし、家庭向け ISP も同じスパム対策の理由で何年も前から外向きの 25 番を塞いでいます。ノート PC では動くメール送信が VM では永遠に固まるのはこのためです。宛先のサーバーを直接叩くのではなく、認証情報と TLS を使って 587 か 465 でプロバイダ経由で送ってください。ついでに相手の配信レピュテーションも借りられます。あなたのメールが実際に届くかどうかを決めているのは、結局そこです。
どれもブラウザ内で完結します。アップロードは発生しません。
25 を調べているとき、ついでに確認することになりがちなポートです。
ほぼ権限の問題です。lsof や ss はソケット自体は出しますが、他ユーザーのプロセスは所有者の列を伏せるので、システムアカウントやコンテナランタイム、launchd が起動したサーバーは sudo を付け直すまで持ち主不明のリスナーに見えます。Windows は逆で、netstat には何も出ないのに bind だけ失敗します。これは Hyper-V や WSL2、Docker Desktop が起動時に予約したポート帯に当たっている状態です。
何なのかを先に見てください。取り残された開発サーバーなら問題ありませんが、書き込み中のデータベースは別ですし、他が依存しているシステムサービスも同様です。持ち主がコンテナならコンテナごと停止してください。ホストから見えるプロセスを kill してもランタイムが再起動するだけです。どうしても止められないものなら、自分のサービスを別のポートへ移すほうが早く片付きます。
0.0.0.0 ではなく 127.0.0.1 にバインドしているからです。各ページのコマンドがプロセス名と並べてバインド先アドレスを出しているのはこのためで、ループバックにバインドしたものはファイアウォールの設定に関係なく自分のマシンからしか届きません。最近は意図的にそれを既定にしているフレームワークも多いので、たいていはバグではなくフラグの問題です。すでに 0.0.0.0 なのに届かないなら、次に疑うのはホストのファイアウォールかクラウドのセキュリティグループです。
ほとんどなりません。インターネット全体を舐めるスキャナーはポート範囲を丸ごと走査し続けているので、稼げるのは数時間であって安全ではなく、代わりに関係者全員がその番号を覚える羽目になります。既定ポートを狙う無差別スキャンのログが減るという効果は確かにありますが、それだけです。結果を変えるのは認証と、送信元アドレスを絞ったファイアウォールと、そもそも外に出さないことです。
ポート 25 でまだ詰まっていますか。ポート一覧をすべて見る。あるいは上に戻って、実際に出たエラー文から追ってください。