元々送信者が複数のメールを出していたというケースもありえます。 この場合メールの Received: や Message-Id: が異なります。 同じメール(たとえば Message-Id: が同一) &fml8; は受信したメールの Message-Id: の記録をとっています。 &fml8; がこれらの Message-Id: が同じメールを受けとった場合、 最初の一通だけが通過します。 メーリングリストからのメールが複数送られてくる、 つまり「再送」されてきた場合、 &fml8; ではなく、 そのあとの MTA による再送の可能性のほうが高いです。 もちろん &fml8; 自体が MTA 化した今では &fml8; による再送もありえます。 が二通届いたという場合、単なる再送かもしれません。 電子メール業界では 「行方不明になるくらいなら重複して届いた方がマシである」 と考えられています。 データを失うくらいなら冗長でも重複して届けてしまう方が良いです。 よって MTA は配送が失敗した可能性のある場合、 重複の可能性があってもあえて再配送を行ないます。 ただ何通も送られてくるようであれば、やはりシステムに何かかの異常があります。 いずれにせよ調べるべきポイントは「だれに同じメールが送られているのか？」です。 ＭＬ受信者の一部にだけ送られているなら &fml8; 以外の配送システムのどこかが犯人です。 一方、ＭＬ受信者全員に送られているなら &fml8; が犯人でしょう。 まずは &fml8; のログを調べて下さい。 どの場合でも、メールヘッダを解析する必要があります。 複数届くというメールのサンプルを手に入れて下さい。 ただし、 メールヘッダが省略されていない完全な形のものを手に入れないと意味がありません。 同じ内容の複数のメールで本文だけでなく From: や Message-ID: や Received: までが同じです。 同じ内容の複数のメールで本文や From: は同じでも Received: が異なります。 メールサーバ A B C を通過してくると次のような Received: がついているはずです。 Received: by サーバC 時刻C Received: by サーバB 時刻B Received: by サーバA 時刻A 再送しているサーバ以降の時刻は各メールで異なるはずですから、 時刻の異なる Received: が現れているところが犯人のサーバです。 たとえば Received: by サーバC 時刻C' Received: by サーバB 時刻B Received: by サーバA 時刻A なら B と C の間で問題があります （まず、まちがいなく B が犯人 ）。 &fml8; から MTA にいって MTA (もしくは配送されていった先のどこか別のサイトの MTA) から &fml8; に再度メールが配送される可能性がないわけではありません。 ループが起こらないように、 受信したメール、 &fml8; が生成して送信したメールの Message-Id: はキャッシュされているので、 そのメールが回り回って返ってきても &fml8; はループとみなして配送しません。 なんにせよ、 その再送されてくるというメールの完全なヘッダを手に入れて、 それを分析する必要があります。