前回2.7.1をリリースして暫く立ってから気がついたバグの修正だけを予定していましたが、週末にbounceHammerを使ってもらっているユーザさんから、解析できないauのバウンスメールをサンプルとして頂いたので、それの対応もリリースに含めました。
データをもらったりパッチをもらったりするのは開発者としては嬉しい限りです、ありがとうございます。 >> ユーザの皆さん
auのMailbox Fullを修正
解析できなかったのは、@ezweb.ne.jpからMailbox Fullで返ってくるバウンスメールでした。auはSMTPセッション中にエラーを返すよりも、一旦auのサーバがメールを受け取ってから、バウンスメールとして返してくるので、他の携帯電話キャリアと比べて特殊な解析処理が必要、という点は少し面倒な宛先です。バウンスメール解析は、エラーの種類が多いのと、メールサーバの種類が多い、の二点でかなり多くのパターンに対応する必要があります。バウンスメール解析のコードを書く立場としては、世の中のMTAが全部Sendmailになったらものすごく楽です。
なぜSendmailのバウンスメールが解析しやすいのか?
Sendmailが作ったバウンスメールは、下記のように配信できなかった宛先(Final-Recipient)やエラー(Diagnostic-Code)は勿論、拡張状態コード(RFC1893)をStatusに書いてくれています。Postfixも同じような感じで書いてくれますがSendmail程細かくない、qmailは殆ど書いてくれない OR 書いていても文章の一部、というようにSendmailが一番詳細です。
Reporting-MTA: dns; mx.example.jp
Received-From-MTA: DNS; [192.0.2.34]
Arrival-Date: Tue, 21 Jun 2011 00:00:00 +0900 (JST)
Final-Recipient: RFC822; hogehoge@example.co.jp
Action: failed
Status: 5.1.1
Remote-MTA: DNS; mail.example.co.jp
Diagnostic-Code: SMTP; 550 : User unknown
Last-Attempt-Date: Tue, 21 Jun 2011 00:00:00 +0900 (JST)
もし世の中にMTAがSendmailしか存在しなかったら、Status:の値を見て、それをRFC1893に従ってエラーの分類を行うだけでよく、Perlで正規表現を大量に書く必要も多分ないでしょう。HTTPやSMTPのステータスコードと同じく2YZ=成功, 4YZ=一時エラー, 5YZ=恒久エラー、というようにXの数値が大きな分類となっている構造化された数値なので、機械的な処理がしやすいのです。
bounceHammerは5種類のMTAに対応
とは言え、Sendmailが最大シェアを持っていても、他のMTA(特にPostfix)もシェアを伸ばしていますし、高速配信サーバ・ASPなどはqmailをベースに改造されたものが使われている事が多いようです。bounceHammerはSendmailをはじめ、Postfix, qmail, Exim, Courier MTAの5種類のオープンソースMTAが作るバウンスメールに対応しています。データはYAML/JSONで吐き出しますし、bounceHammerが知らないパターンのバウンスメールは自前で解析モジュールを書いて、所定のディレクトリに置けば解析してくれます。
おそらく自前で実装するよりは短期間でバウンス解析環境が手に入りますので、バウンスメールで困っている方はbouncehammer使ってみてください。
関連リンク
- bounceHammer | an open source software for handling email bounces
- bounceHammer 2.7.2リリース
- Open Source - Sendmail.com
- RFC 1893 | Enhanced Mail System Status Codes
0 件のコメント:
コメントを投稿