～あらすじ～
C社の請け負っている案件にて配達不能通知(NDR)が返信されないという本末転倒とも言える事件が発覚し、私が解決を依頼される運びとなった。
第1節 構成 -Configuration-
C社から送られてきた設定内容を記す。
一部企業情報を特定できる内容が含まれていたので、その部分に関しては修正した。
内容の本質は以下のとおりである。
・mailertableの内容
----------------------------------------------------------
bou-kaisha.co.jp procmail:/etc/procmailrc
# bou-kaisha.co.jp宛に送られたメールをprocmailに渡す。
# レシピは/etc/procmailrcを使用する。
----------------------------------------------------------
・procmailrcの内容
----------------------------------------------------------
TO=$2
# 宛先アドレスを変数に格納する。
ACCOUNT=`echo $TO | sed 's/@.*//g' `
# 宛先アドレスからアカウント部だけを取り出して変数に格納する。
EXCHANGE=[172.16.1.1]
# Exchange ServerのIPアドレスを変数に格納する。
:0
* ^From.*@tokutei.com
! $ACCOUNT@$EXCHANGE , dareka@$EXCHANGE
# 特定のドメイン部を持つメールをExchangeの本来の宛先アカウントとdarekaに送信する。
:0
! $ACCOUNT@$EXCHANGE
# 上記の条件にあてはまらないメールはExchangeの本来の宛先アカウントにだけ送信する。
----------------------------------------------------------
第2節 調査 -Investigation-
調査の過程で配達不能通知(NDR)が返信されないのはメールヘッダのReturn-Path:がroot@tyuukei.bou-kaisha.co.jpに変わっている為だということが分かった。
（ドメイン部のtyuukeiは中継させているメールサーバのホスト名）
第3節 推理 -Reasoning-
通常、Return-Path:には送信者のアドレスか送信元のメールサーバのアドレスが入っていなければおかしい。
つまり、このReturn-Path:を書き換えている（またはそのように見えるような動作をしている）部分を特定し、修正してやればいいはずだ。
ログを見る限り、Exchangeサーバが受信した時点でReturn-Path:は変わっていた。
このことからExchangeサーバの可能性は除外できる為、残りはSendmailかProcmailかということになる。
とりあえず擬似環境を構築し、検証を行ってみることとする。
再現性がないと厄介なことになるのだが。
次回はいよいよ解決編。（の予定。すべては解決できるかどうかにかかっている。）