メールデータ中で一番肝のメールヘッダ「Received」属性を検証してみました。以下の過去記事も参照。準拠しているか、どんな構成になっているを分類しているだけです。今回は不正な中継をしていないか等の検証は行っていません。ルール化されているもので、経由したメールサーバの情報が記録されています。基本的に複数のサーバを経由していれば複数記録されています。よれば、「Received」は以下のような書式になっていないといけません。必須ですが、以前の基準では設定されていなくてもよかったようです。日時は曜日部分・秒部分はなくてもよいです。ついては以下等も参照。メールデータ(61,665件)を検証した結果を掲載します。※だから何?と言われそうですが、自分の近い将来のための記録として掲載していますので、ご承知おきください。スクリプトは今までの検証で使用してきたものを流用しています。多数のデータの中には様々な書式のものが存在するため、単純な正規表現では解析不可能です。今回は多数の正規表現を使用しました。参考までにそのうちの1つを紹介します。#{REG_EXP_DATE}$/x何回も使用する日時部分の正規表現を別にしています。正規表現にマッチすることだけを考えず、マッチした際の値を取得することを考えて丸括弧で括っています。“with”)があるため、否定先読みを使用しています。1メール当たりのReceivedの件数1メール当たりのReceivedの件数を集計しました。「Received」が設定されていないものも結構存在しました。どちらかが非設定でもアンマッチとはしませんでした。25“from”も”by”も非設定のものはありませんでした。”(“と”)”で囲まれたものが結構ありました。日時書式では、タイムゾーンの設定が不正なものが殆どでした。)その他の不正なものは、すべて”from”が同レベルで2回設定されているもの。データをデータベースに保存する事が目的ですので、今回はどのような書式のものがどれくらい存在するかを検証しました。本来なら、この「Received」を精査してスパムメール・迷惑メール対策に役立てるのでしょう。(実際、検証中それらしいものが多数見受けられました。)今回で、メールヘッダの主だった属性の検証は一応終了とします。これからは、メールボディ部分の検証をしてみたいと考えています。調査に時間がかかりそう。説明(独立)変数2個、目的(従属)変数1個の「重回帰式」を計算する方法を紹介しました。Coefficient)の計算をしてみました。Coefficient)の計算をしてみました。Coefficient)の計算をしてみました。