1

RFC1893 は、ステータス コードが以下の形式で提供されると主張しています。詳細については、こちらを参照してください。

しかし、バウンス管理システムは、バウンス メッセージからエラー ステータス コードを解析するのに苦労しています。生のメッセージを取得することはできますが、電子メール サーバーによっては、コードが別の場所に送信される場合があります。このタイプのメッセージを解析してより良い結果を得る方法に関するルールはありますか? 100% の解決策ではなく、少なくとも 80% の解決策を探しています。

このドキュメントは、メール システムの状態を報告するためのステータス コードの新しいセットを定義します。これらのステータス コードは、メディアや言語に依存しないステータス レポートに使用することを目的としています。システム固有の診断用ではありません。

新しいステータス コードの構文は次のように定義されます。

      status-code = class "." subject "." detail
      class = "2"/"4"/"5"
      subject = 1*3digit
      detail = 1*3digit

空白文字とコメントはステータス
コード内では許可されません。ステータスコード内の各数値サブコードは、
先頭のゼロ桁なしで表現する必要があります。

上記の RFC からの引用は 1 つのことを示していますが、バウンス管理に関する主要なツールからの以下のテキストは別のことを示しています。標準ステータス コードの適切なソースを入手できます。

戻りコード 説明
0 UNDETERMINED - (つまり、受信者の返信)
10 HARD BOUNCE - (つまり、ユーザーが不明)
20 SOFT BOUNCE - 一般
21 SOFT BOUNCE - Dns Failure
22 SOFT BOUNCE - メールボックスがいっぱい
23 SOFT BOUNCE - メッセージが大きすぎます
30 BOUNCE - NO電子メールアドレス。激レア！
40 一般的なバウンス
50 メール ブロック - 一般
51 メール ブロック - 既知のスパマー 52 メール
ブロック - スパム検出
53 メール ブロック - 添付ファイルの検出54 メール ブロック - リレー
拒否
60 UNSUBSCRIBE/REMOVE リクエスト



100 チャレンジレスポンス

4

1 に答える 1

2

それが完全な答えかどうかはわかりませんが、バウンスを検出するためのこのアルゴリズムは役立つかもしれません。

于 2009-08-06T14:04:00.877 に答える