配信されなかったメールヘッダー（バウンスされたメール）を解析する

サーバーに返送されるバウンスされた（配信不能）メールのヘッダーを解析し、ソフトバウンスかハードバウンスかを判別する最良の方法は何ですか？

ユーザーにオプトインメールを送信するだけですが、メールアドレスの一部が古くなっていることがあります。メールがサーバーにバウンスするとき、なぜバウンスしたか（ソフト/ハード）を確認します。次に、データベースで適切に処理したり、次回ログイン時にメールを更新するようにユーザーにフラグを付けたりできます。

UbuntuとPostfixを使用しています。エイリアスと仮想エイリアスを使用してVERPを正常に実装しました。したがって、バウンスされた電子メールにはbounce+OrigEmailAddress@example.comのリターンパスがあり、それらをスクリプトにパイプすることができます。

これでVERPセットアップが完了したので、元のメールの送信先はわかりましたが、返されたメールヘッダーを解析して、ソフトバウンスかハードバウンスかを調べる必要があります。

これを処理する最良の方法は何ですか？私の理解では、すべてのメールサーバーが同じルールで動作するわけではなく、ヘッダーにはさまざまな形式があります。これらの種類のことを追跡するオープンソースプロジェクトはありますか？バウンスの大部分を適切に分類する、実装できる簡単なものはありますか？

私はメールサーバーの評判を保護しようとしていますので、どんな助けにも感謝します！

RFC3463が説明し、5で始まるステータスコードは、恒久的な障害と永続的な一時的な障害のために4のために使用されています。異なる形式のいくつかのメッセージを解析する代わりに、サーバーログに依存して次のようなことを試すことができます。

grep " dsn=5." /var/log/mail.log | grep -o -P " to=<(.+?)>" | sort | uniq -c

これにより、mail.log（Postfix形式）から永続的なエラーが検出され、すべてのアドレスのアドレスとバウンスの量が示されます。「dsn = 4」を使用することもできます。一時的なエラーのあるアドレスを取得します。

通常、バウンスには2つのタイプがあります

1. Postfixが電子メールを配信するときのリモートメールサーバーの直接拒否によって引き起こされるバウンス。
2. リモートサーバー（postfixの後のネクストホップサーバー）が原因のバウンスは、最終的な受信者へのメッセージの配信に失敗します。

最初のケースは、上記のEsa Jokinen による優れた回答ですでにカバーされています。あなたの最善の策は、メールログを解析することです。

2番目のケースは、バウンスの特殊なケースでした。シナリオ例：

• 受信者fakemail@example.comのメールをmail.example.comサーバーに送信します。
• mail.example.com、でfakemail@example.comにエイリアスされたrealmail@example.netとに転送されなければならないmail.example.net。
• いつかmail.example.netがメッセージを拒否するため、mail.example.comはサーバーにバウンスを送信する必要があります。
• 残念ながら、サーバーのメールログには「dsn = 2」が含まれます。これは、mail.example.comはすでにメッセージを受け入れましたが、mail.example.netに転送できなかったためです。

ここでは、2番目のタイプの例がメールをバウンスします。転送ルールYahooメールサーバーmyuser@yahoo.com-> myuser@example.netがあります。残念ながらexample.netのメールサーバーはメッセージを拒否します:(

From MAILER-DAEMON  Thu Mar  5 05:07:26 2015
Return-Path: <>
X-Original-To: noreply-myuser=yahoo.com@example.org
Delivered-To: noreply-263462085117-1425506829-myuser=yahoo.com@example.org
Received: from nm21-vm7.bullet.mail.gq1.yahoo.com (nm21-vm7.bullet.mail.gq1.yahoo.com [98.136.217.54])
        (using TLSv1 with cipher ECDHE-RSA-AES128-SHA (128/128 bits))
        (No client certificate requested)
        by mx.example.org (Postfix) with ESMTPS id D6365565FC
        for <noreply-263462085117-1425506829-myuser=yahoo.com@example.org>; Thu,  5 Mar 2015 05:07:25 +0700 (WIT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yahoo.com; s=bounce; t=1425506842; bh=zk/tWZNl6c36dmlPDmakM9ekK8cHVJANXMmSdsbkcWc=; h=From:To:Date:Subject:From:Subject; b=Im95h1qTg6qN3yUI7vF1fXtJ0SbUnzv8rUPwLbpNwxGPN2p8wfosXJzQgJ3nzr4L4ZQ50P2d9E9U4jEUNtnyi7nlFd5kKbtiVuda4H56h1PFnt+7wSpgHcd5Irs/lLODumb6ZZSEpCOWttcB9+JLaDfEUUPjGcbR+xww4XeH5Eo=
From: MAILER-DAEMON@yahoo.com
To: noreply-263462085117-1425506829-myuser=yahoo.com@example.org
Date: Wed, 04 Mar 2015 22:07:22 -0000
Subject: Failure Notice
X-Yahoo-Newman-Property: bmbounce

Sorry, we were unable to deliver your message to the following address.

<myuser@example.net>:
Remote host said:
550 5.1.1 User unknown
 [RCPT_TO]

この場合、唯一の方法はバウンスメッセージを解析することです。残念ながら、標準的なバウンス形式はないため、本文を解析して、拒否の原因を特定する必要があります。

Postfixバウンス解析の機能チェックリスト：

1. VERPアドレスが有効かどうかを確認してください。無効なメッセージを解析したくない。
2. 体を解析し、拒絶反応が柔らかいか硬いかを判断します。

2番目の機能では、いくつかの一般的な拒否メッセージをグーグルできます。例は、Jakub Liskaによるこのbounce-regex-list.xmlです。

Esa Jokinenは、これらの2つのバウンスタイプについて、以下のコメントで良い点を指摘しました。サーバーの評判を維持することが目的の場合は、最初のバウンスタイプを処理するだけで十分です。2番目のバウンスは、リストのクリーニングに関するものでした。したがって、死んだ電子メールを消去して、サーバーの一部のリソースを解放する必要があります。

PHPlistやMailmanなどの一部のメーリングリストマネージャーも、メールログを解析するためのリソースがないため、メール本文の解析に関するこのバウンス問題に対処します。