Too many hops とは何か?

Q. こんな内容のメールがきました。

……(前略)……
The original message was received at Sun, 20 Sep 1998 15:06:57 +0900
from rins.st.ryukoku.ac.jp [133.83.4.1] (may be forged)

   ----- The following addresses had permanent fatal errors -----
<foobar@hogehoge.st.ryukoku.ac.jp>
    (expanded from: <foobar@hogehoge.st.ryukoku.ac.jp>)

   ----- Transcript of session follows -----
554 Too many hops 18 (17 max): from <foobar@rins.ryukoku.ac.jp> via rins.st.ryukoku.ac.jp,
    to <foobar@hogehoge.st.ryukoku.ac.jp>
……(後略)……

Too many hops とは何ですか? 17 という数字は何を意味するのですか?

この現象を理解するには、電子メールの配送形態を理解する必要があります。あなたのコンピュータから送られた電子メールは、相手のコンピュータに直接送られるわけではありません。いくつかのコンピュータ (電子メール配送システム) を中継して送られます。

宅配便や紙の手紙を思いうかべていただければわかりやすいかと思います。あなたがコンビニにあずけた宅配便は、いくつかの配送センターを中継して送られます。典型的な例は次のとおりです:

あなたがコンビニにあずけた宅配便は、
まずコンビニが存在する地域の配送センターへ送られ、
そこから相手先地域の配送センターへ送られ、
相手先地域の配送センターから相手先へ送られます。

電子メールも同様に、いくつかの配送センター (電子メール配送システム) を中継して送られます。中継するとき、電子メール配送システムはメールヘッダに Received: という行を追加して、「このような中継を行った」旨を記載します。以下にメールヘッダの Received: の例を示します。

この例では、

mail433.elec.ryukoku.ac.jp (localhost) から mail433.elec.ryukoku.ac.jp へ
mail433.elec.ryukoku.ac.jp (iota20.elec.ryukoku.ac.jp) から rins.st.ryukoku.ac.jp へ
rins.st.ryukoku.ac.jp から hyperion.st.ryukoku.ac.jp へ

とメールが配送されたことが読みとれます。 Received: 行は下から上へと読むことに注意してください。なお、ここに出てくる「localhost」というのは自分自身のことです。また、上記からは iota20.elec.ryukoku.ac.jp が mail433.elec.ryukoku.ac.jp の本名であることも読みとれます。

さて、現在の電子メール配送システムというのははっきり言っておバカなので、設定に何らかの不具合があると、ある 2 点間で永遠に中継を繰りかえしたりしてしまいます。これを「ピンポン」と言います。典型的な例は次のとおりです:

電子メール配送システム A では「メールを B に送れ」と設定します。
電子メール配送システム B では「メールを A に送れ」と設定します。
何らかの理由で A または B に送られた電子メールは、永遠に A と B の間を行き来してしまいます。

「そんなことふつうしないでしょう」と思われるかもしれませんが、知識不足、不注意などによりこのような設定を行ってしまうことはよくあることです。

しかし実際には、永遠に A と B の間を行き来してしまうことはありません。電子メール配送システムは、電子メールを中継する際に電子メールの Received: 行の行数を数えます。ピンポンを続けるうちに Received: 行が増えつづけ、やがてある一定数以上になると「ピンポンが発生した」と判断してエラーメールとして送り主に送り返してしまうのです。このときのエラーメッセージが 554 Too many hops 18 (17 max) です。 17 という数字はエラーと判断した電子メール配送システムにおいて定義されている定数で、 max hop count と呼ばれます。

Internet において広く利用されている電子メール配送システム「sendmail」の昔のバージョン (5.x) では max hop count = 17 と定義されており、しかも変更できません。最近のバージョン (8.x 以降) では標準で max hop count = 25 であり、もっと大きな値を設定もできますが、昔のバージョンのまま運用しているところもまだまだたくさんあるようです。

現代の Internet においては max hop count = 17 では少なすぎます。 50 以上の数字にしておきましょう。ちなみに、SMTP の規格文書 RFC2821 には「少なくとも 100 とすべき」とあります (セクション 6.2)。古いバージョンの sendmail にはさまざまな不具合も含まれているため、新しいバージョンの sendmail をインストールし、あわせて O MaxHopCount=50 のように設定されることを強く勧めます。

■

Too many hops エラーが発生した場合、どのように対処したらよいでしょう?

まずは送り返されてきたエラーメールをよく読み、何が原因で Too many hops エラーが発生したのかを突きとめる必要があります。

Too many hops エラーが発生した場合、その原因のほとんどはピンポンです。ピンポンの場合、Received: 行に同じ内容がくりかえし現れているので、すぐわかります。典型例を以下に示します:

……(前略)……
Received: from rins.st.ryukoku.ac.jp (rins.st.ryukoku.ac.jp [133.83.4.1] (may be forged))
        by hogehoge.st.ryukoku.ac.jp (8.8.8/3.6Wbeta6) with ESMTP id PAA00230
        for <fooabr@hogehoge.st.ryukoku.ac.jp>; Sun, 20 Sep 1998 15:23:06 +0900
Received: from hogehoge.st.ryukoku.ac.jp (hogehoge.st.ryukoku.ac.jp [133.83.xx.x])
        by rins.st.ryukoku.ac.jp (8.8.8/3.6W/RINS-1.9.5) with ESMTP id PAA00116
        for <foobar>; Sun, 20 Sep 1998 15:22:55 +0900 (JST)
Received: from rins.st.ryukoku.ac.jp (rins.st.ryukoku.ac.jp [133.83.4.1] (may be forged))
        by hogehoge.st.ryukoku.ac.jp (8.8.8/3.6Wbeta6) with ESMTP id PAA00218
        for <foobar@hogehoge.st.ryukoku.ac.jp>; Sun, 20 Sep 1998 15:23:05 +0900
Received: from hogehoge.st.ryukoku.ac.jp (hogehoge.st.ryukoku.ac.jp [133.83.xx.x])
        by rins.st.ryukoku.ac.jp (8.8.8/3.6W/RINS-1.9.5) with ESMTP id PAA00113
        for <foobar>; Sun, 20 Sep 1998 15:22:54 +0900 (JST)
……(後略)……

上記からは、 rins.st.ryukoku.ac.jp と hogehoge.st.ryukoku.ac.jp との間でくりかえし転送しあっていることが読みとれます。ユーザ foobar の設定不具合あるいは rins.st.ryukoku.ac.jp、 hogehoge.st.ryukoku.ac.jp どちらか (両方かも) の電子メール配送システム設定不具合が原因です。まずはユーザ foobar の設定不具合がないかどうか確認し、その後電子メール配送システム設定不具合がないかどうかを確認します。ユーザの設定不具合としてありがちなのは、~/.forward ファイルの設定ミスです。じっくり確認してください。

■

これとは別に、ピンポンが発生していなくても Too many hops エラーとなる場合があります。

大きな組織では、組織毎に中継サーバを設置し、組織外へのメールは上部組織の中継サーバに送る、という構成にすることがあります。このような構成の場合、中継サーバの max hop count が小さいものだと「ピンポン」が発生したと誤判断してエラーメールとしてしまうことがあります。

例えば、「A 社大阪支社営業部営業課 PC 係の X さん」から「B 社名古屋支社技術部 PC 開発課メモリー係の Y さん」に電子メールを出すとしましょう。 X さんの電子メールは Y さんに届くまでに次の経路をたどると考えられます。

X さんのパソコンから PC 係の中継サーバへ
PC 係の中継サーバから営業課の中継サーバへ
営業課の中継サーバから営業部の中継サーバへ
営業部の中継サーバから大阪支社の中継サーバへ
大阪支社の中継サーバから東京本社の中継サーバへ
東京本社の中継サーバから A 社の Internet 接続・中継サーバへ
A 社の Internet 接続・中継サーバから B 社の Internet 接続・中継サーバへ
B 社の Internet 接続・中継サーバから B 社東京本社の中継サーバへ
B 社東京本社の中継サーバから B 社名古屋支社の中継サーバへ
B 社名古屋支社の中継サーバから B 社技術部の中継サーバへ
B 社技術部の中継サーバから B 社 PC 開発課の中継サーバへ
B 社 PC 開発課の中継サーバから B 社メモリー係の中継サーバへ
B 社メモリー係の中継サーバから Y さんのパソコンへ

最後の「B 社メモリー係の中継サーバから Y さんのパソコンへ」は通常 POP3 プロトコルなどによって行われますから、上記では中継回数は 12 となります。 max hop count = 17 の中継サーバでもまだなんとかなります。

さてここで、B 社名古屋支社技術部 PC 開発課メモリー係の中継サーバで Mailing List サーバが動作していたとします。 Y さんというのは実は中継サーバにおける Mailing List のアドレスで、 Y さん宛のメールは Mailing List サーバにより List 参加者全員に送られるとします。また、この Mailing List サーバでは Received: ヘッダを残したまま電子メールを送るとします。

すると、往復での中継回数は最大で 12 x 2 = 24 となり、 max hop count = 17 の中継サーバはこれをエラーとみなしてしまいます。筆者は実際にこのような状況に置かれた経験があります。

「まさか、ふつう Received: は残したりせずに削るでしょう」と思われるかもしれませんが、たとえば、 Internet において広く用いられている Mailing List サーバ「majordomo」は、標準設定では Received: は残したまま配送します。 Received: を残しておくと、配送エラー時のエラー原因の探究に便利なため、残しておくことを一概に悪と決めつけるわけにもいきません。どちらかというと、現代 Internet において max hop count = 17 などという運用をしているほうが「悪」と言えます。