locked
Exchangeでメール転送のループ RRS feed

  • 質問

  • ExchangeServer2007-SP11Rollup7を使用しています。

    1.Outlookから組織内ユーザのメールアドレス(以下、test@test.com)
     に対して、添付ファイル付のメール(約20MB)を送信
    2.test@test.comアカウントの転送設定(仕分ウィザードから設定)により、
     設定された外部メールサーバのメールアドレス(以下、test@sample.com)
     に対して、添付ファイル付きのメールをそのまま転送。
    3.外部メールサーバの容量制限に抵触し、test@sample.comから転送元の
     test@test.comに対してエラーメール(添付ファイル自体も付いたまま)
     が返信される。
    4.エラーメールを受信した転送元のtest@test.comでは、
     エラーメール自体も転送してしまう。

     →1時間/100回程、2~4が繰り返された時点で、エラーメールの転送を
      停止して終了。

    という現象が発生しました。
    2~4が繰り返されている1時間程の間に、イベントID:15004が発生して
    リソースが非常に圧迫され、いくつかのコンポーネントが停止してしまう
    状態になってしまいましたがエラーメールの転送が停止された時点で回復
    しました。

    今後、このようなことが無いように対策を施したいのですが、
    Exchange側の設定で、転送のループを回避する方法は無いでしょうか?
    (エラーメールを転送しないような設定をすれば良いと思うのですが、方法が分かりません。。。)

    正直、1時間/100回程度で転送のループが停止してくれた理由も分からないのですが、、、
    exchangeのどこかに再試行の設定があるのでしょうか?

    2009年5月13日 1:48

回答

  • uraraさん、こんにちは。

    まず、今回の現象とは少し離れまして、SMTPの通信についてなのですが、ごく簡略化して言えば、以下のようなコマンドを送信元のサーバーが順に送信側に送って通信をしています。
    helo
    Mail From: 送信元アドレス
    Rcpt To: 送信先アドレス
    Data
    ...

    このDataコマンドの後に実際のメッセージのデータがはいるわけですが、ここでFrom:を使って実際にメッセージ上で送信元として表示される情報を指定できます。そのため、今回uraraさんのエラーメールでFrom: <MAILER-DAEMON@sample.com>となっている状態は、Dataコマンドの後にFrom: <MAILER-DAEMON@sample.com>が送られているためとなります。
    一方、今回のサポート技術情報のレジストリは、heloの後にくるMail From:の引数が<>かnullであれば有効になるはずです。
    メッセージ上でFrom:になにかアドレスが入っていても、SMTP通信時にMail From:がどうなっていたかはわかりません。確実にMail Fromがどうだったか確認するには、そのときのSMTP Receiveログをみてみるとよいと思います。

    説明がまどろこしくてすいません。。お役にたてれば幸いです。


    • 回答としてマーク urara 2009年5月21日 3:03
    2009年5月15日 16:28

すべての返信

  • uraraさん、こんにちは。

    自動転送によるループが発生したとのことですが、以下のKBにあるレジストリで抑制することができないか確認してみてはいかがでしょうか。

    Messages autoforwarded to an invalid internet address appear to create a looping message in Exchange
    http://support.microsoft.com/kb/238429/en-us

    今回は転送先メールボックスの容量制限に達したためそのNDRがループしていたということでしたが、このKBのレジストリを設定した場合には、MAIL FROM が"<>"または"null"の場合にそのメッセージの転送を禁止できるので、今回ループしていたNDRもそういったものであれば今後の再発防止になるのではと思います。Exchange 2007ではメールボックス サーバーで設定するレジストリです。
    2009年5月14日 19:55

  • DietPepper様 

    ご返信、ありがとうございます。頂いたKBを確認させて頂きました。
    このレジストリの場合、Fromが空白の場合には有効な再発防止になると思いますので、
    設定をしようと思います。

    ただ、今回現象が起きたメールのFromは<MAILER-DAEMON@sample.com>
    となっており空白ではありませんでしたので、このケースでは再発防止がなされそうにありません。

    エラーメールのFromは、MAILER-DAMON@、root@、Postmaster@等であることが多い
    と思うのですが、Fromヘッダがこの場合に
    ・該当のメールボックスに受信はする
    ・自動転送はさせない
    といった設定が出来ないものかと悩んでおります。。。。


    2009年5月15日 0:48
  • uraraさん、おはようございます。
    今回ループしていたメールのFromはMAILER-DAEMON@...だったとのことですが、KBのレジストリは、SMTP コマンドの Mail From の因数が<>またはnullであれば有効になります。この条件に該当していれば、FromにMAILER_DAEMON@..が入っていても、レジストリでループ防止できると思われます。
    実際にこのメールを受信したときのMail Fromがどうだったのかは、SMTP ログが残っていれば確認できると思いますが、いかがですかね。
    2009年5月15日 2:03
  • DietPepper様 

    丁寧な補足、ありがとうございます。
    当時に受信していたエラーメールを確認すると
    From: <MAILER-DAEMON@sample.com>
    となっておりました。
    私の認識不足で見当違いな発言をしておりました。

    ・エラーメールの場合、Fromヘッダが空白以外では下記のように<>を付けた形で返信されると
     規定されている。
      <MAILER-DAEMON@sample.com>
      <root@sample.com>
      <Postmaster@sample.com>

    ・今回の場合、
     From: <MAILER-DAEMON@sample.com>
     の場合にはFromヘッダの中に <>が含まれているため、
     このレジストリでループが防止できる。

    という解釈でよろしいでしょうか?

    2009年5月15日 4:20
  • uraraさん、こんにちは。

    まず、今回の現象とは少し離れまして、SMTPの通信についてなのですが、ごく簡略化して言えば、以下のようなコマンドを送信元のサーバーが順に送信側に送って通信をしています。
    helo
    Mail From: 送信元アドレス
    Rcpt To: 送信先アドレス
    Data
    ...

    このDataコマンドの後に実際のメッセージのデータがはいるわけですが、ここでFrom:を使って実際にメッセージ上で送信元として表示される情報を指定できます。そのため、今回uraraさんのエラーメールでFrom: <MAILER-DAEMON@sample.com>となっている状態は、Dataコマンドの後にFrom: <MAILER-DAEMON@sample.com>が送られているためとなります。
    一方、今回のサポート技術情報のレジストリは、heloの後にくるMail From:の引数が<>かnullであれば有効になるはずです。
    メッセージ上でFrom:になにかアドレスが入っていても、SMTP通信時にMail From:がどうなっていたかはわかりません。確実にMail Fromがどうだったか確認するには、そのときのSMTP Receiveログをみてみるとよいと思います。

    説明がまどろこしくてすいません。。お役にたてれば幸いです。


    • 回答としてマーク urara 2009年5月21日 3:03
    2009年5月15日 16:28
  • DietPepper様 

    お世話になっております。
    丁寧なコメント、ありがとうございました。
    「Mail Fromヘッダ」の意味を取り違えておりました。

    Exchangeのメッセージ追跡ツールから、該当のログを確認しただけでは、
    Mail Fromの情報は確認出来ませんでしたが、
    Return-Path: <>
    となっていることを確認できました。

    Return-Path = heloパケットの後のMail From
    と解釈して良いのであれば、このKBが適用されるものと判断して良いと思うのですが
    そう考えてよいのでしょうか?

    2009年5月18日 4:57
  • uraraさん、こんにちは。
    返信が遅くなって申し訳ありません。
    Return-PathはDataコマンドの後に指定することもできるので、Return-Pathが<>なら、Mail Fromも<>だと100%断言はできないです。が、Return-Pathの指定がなければ、Mail From と同じになると思いますし、今回のようなメッセージの場合Mail Fromが<>だった可能性はきわめて高いのではないでしょうか。
    2009年5月21日 23:40
  • DietPepper様  コメント、有難うございました。 上司にMS-KBの内容を相談したところ、 「正規なメールであっても、Mail Fromが<>の場合がある」 とのことで設定の許可が得られませんでした。 いろいろと有益な情報を頂いたのに、こちらの事情で 中途半端な結論となってしまい申し訳ありません。 本当に有難うございました。
    2009年5月25日 1:11
  • こんにちは、マイクロソフトの中尾です。

     

    DietPepperさん、uraraさん、Forumへのご参加ありがとうございます。

     

    DietPepper さんがご紹介くださったKB238429 ですが、実はご投稿いただいた後、KBの修正が行われています。。

    同様の現象に遭遇してこちらのスレッドをご覧になっている方に、修正後の情報を共有していただければと思いましたので、追加投稿させていただきますね。

     

    修正の内容としては、Exchange 2007 では MailFrom: <> のメールに対しレジストリが動作しないことが確認され、そちらに対応するための解決方法の手順が追加されました。

    配信不能通知がループしてしまう、といった現象に遭遇している方がいらっしゃいましたら、お手数ですが、ぜひ再度、KBをご確認いただけたらと思います。

     

    Exchange で無効なインターネット アドレスに自動転送されたメッセージがループメッセージを作成するように見える

    http://support.microsoft.com/kb/238429/jp

     

    追加されたのは、Exchange 2007 の解決方法の手順 7 以降です。

    Exchange 2007 の解決方法の手順を見ていただくと、おおまかに、つぎの2つに分かれています。

     

      ・レジストリの設定 (手順16)

      Exchange 管理コンソールからトランスポート ルールの設定 (手順 7)

     

    手順 16は、以前のバージョンの Exchange と同様の手順です。

    以前のバージョンは、レジストリの設定で、MailFrom: <> のメールや、メールのヘッダーに "Precedence:bulk" などが設定されているメール( Precedence:bulk は大量送信されたメール) の自動転送を無効にすることができました。

    ところがExchange 2007 では、レジストリの設定では、"Precedence:bulk" などが設定されているメールの自動転送は無効になりますが、MailFrom: <> のメールの自動転送は無効にならないことが確認されまして、そのため、手順 7 以降が追加されました。

    参考までに、手順 7 以降で何をしているかといいますと、送信者が "MAILER-DAEMON" となっているメール (メールシステムから送信されるメール。配信不能通知など) で、かつヘッダーに "Precedence:bulk" などが設定されている (bulk と指定している場合は大量送信メール) メールの自動転送を無効にするトランスポートルールを作成しています。

     

    MAILER-DAEMON から送られてくるメールというのは、メールサーバーのシステムから送られてくるメールで、配信できなかった時の通知メールなどです。

    なので、この解決方法の設定を行っても、実在のユーザーから送られてくるメールの転送を実行しなくなることは、通常はないのでご安心ください。

    同様の現象に遭遇されている方がいらっしゃいましたら、ぜひこちらの解決策の実行をご検討ください。

     

    DietPepperさんには、せっかく情報を提供していただいたのに、申し訳ないです。。。

    これからも、技術者の皆様の情報交換の場として、ぜひTechNetフォーラムをご活用ください。ご参加お待ちしております。


    CSS PQO
    2009年8月25日 8:39