web-dev-qa-db-ja.com

未配信のメールヘッダー（バウンスメール）を解析する

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

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

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

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

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

私はメールサーバーの評判を保護するつもりですので、どんな助けでも大歓迎です！

emailemail-serveremail-bounces
8
Richard

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

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

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

8
Esa Jokinen

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

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

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

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

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

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

From MAILER-DAEMON  Thu Mar  5 05:07:26 2015
Return-Path: <>
X-Original-To: [email protected]
Delivered-To: [email protected]
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 <[email protected]>; 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: [email protected]
To: [email protected]
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.

<[email protected]>:
Remote Host said:
550 5.1.1 User unknown
 [RCPT_TO]

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

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

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

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

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

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

8
masegaloeh