☰

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

tag-icon • tag-icon email email-server email-bounces
未配信メールのヘッダーを解析する（バウンスメール）

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

ユーザーにオプトイン メールのみを送信していますが、一部のメール アドレスが古くなることがあります。メールがサーバーに返送された場合、返送された理由 (ソフト/ハード) を調べたいと思います。その後、データベースで適切に処理したり、次回ログイン時にメールを更新するようにユーザーにフラグを設定したりできます。

私はUbuntuとPostfixを使用しています。エイリアスと仮想エイリアスを使用してVERPを実装することに成功しました。そのため、バウンスされたメールのリターンパスは次のようになります。[メールアドレス]、そしてそれをスクリプトにパイプすることができます。

VERP を設定したので、元のメールが誰に送信されたかはわかりますが、返されたメール ヘッダーを解析して、ソフト バウンスかハード バウンスかを判断する必要があります。

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

メール サーバーの評判を守ろうとしているので、どんな助けでも大歓迎です。

答え1

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

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

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

答え2

一般的にバウンスには2つの種類があります

  1. バウンスの原因直接Postfix が電子メールを配信するときにリモート メール サーバーが拒否されます。
  2. リモート サーバー (Postfix の後のネクスト ホップ サーバー) によって発生したバウンスにより、最終受信者にメッセージが配信されません。

最初のケースはすでに素晴らしい答え上記の Esa Jokinen による記事を参照してください。最善策は maillog を解析することです。

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

  • 受信者にメールを送信する[メールアドレス]にメールサーバ。
  • mail.example.comでは、[メールアドレス]別名は[メールアドレス]転送する必要がありますメール。
  • いつかメールあなたのメッセージを拒否するメールサーバーにバウンスを送信する必要があります。
  • 残念ながら、サーバーのメールログには「dsn=2」と表示されます。メールすでにメッセージを受信しましたが、転送できませんでしたメール。

ここでは2番目のタイプのバウンスメールの例を示します。Yahooメールサーバーの転送ルールがあります[メールアドレス]->[メールアドレス]残念ながら、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つ目の機能については、よくある拒否メッセージをGoogleで検索してみてください。例は次のとおりです。バウンス正規表現リスト.xmlによるヤクブ・リスカ。

エサ・ヨキネンが下のコメントに良い点があるこれら2種類のバウンスについて。サーバーの評判を維持することが目的なら、最初のバウンスに対処するだけで十分でしょう。2番目のバウンスはリストをクリーンアップするためのものでした。デッドメールは削除して、いくつかのサーバー内のリソース。

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

関連情報