以下は迷惑メールを招き入れてしまう駄目な許可ルールの代表例です。
- 自分のメールアドレスを許可する
※駄目な理由
自分のメアドを詐称する迷惑メールが許可対象となる
※代案(A)
1. メールソフト等で設定した差出人 (自分) の名前を
許可ルールのキーワードに含める
2. 許可対象が "From: myname <sample@ example.jp>" のとき、
許可ルールの対象とキーワードは
[From:]、[myname <sample@ example.jp>] とする
※代案(B)
1. 自らが決めたメアド以外の情報を含む定型の署名を
常に送信メールの本文に含めるようにする
2. 署名に "myname" および
"E-Mail: sample@ example.jp" が含まれる場合、
許可ルールの対象とキーワードは
[<body>]、[myname&&E-Mail: sample@ example.jp]
(論理演算子 ON) とする
※署名にはメアド以外の情報を含める必要があります。
※代案(C)
1. 自らが決めたメアド以外の情報による定型の符号を
常に送信メールの件名に含めるようにする
2. 送信メールの件名に "/myname" を含める場合、
許可ルールの対象とキーワードは
[Subject:]、[/myname] とする
※符号にはメアド以外の情報を使用する必要があります。
- 自社 (自分が所属する組織) のドメインを許可する
(自分のメールアドレスのドメインの許可も同様)
※駄目な理由
自分または同僚のメアドを詐称する迷惑メールが許可対象となる
※代案(A)
1. 自社の送信サーバーのホスト名を許可ルールに利用する
2. 自社の送信サーバーのホスト名が "smtp.example.jp" で、
自社発のメールのヘッダに
"Received: from 〜 by smtp.example.jp 〜" が記録される場合、
許可ルールの対象とキーワードは
[Received:]、[by smtp.example.jp] とする
※送信サーバーと受信サーバーは異なるホスト名で
運用されている必要があります。
※代案(B)
1. 自社が送受信共に送信ドメイン認証に対応している場合、
送信ドメイン認証の結果を許可ルールに利用する
2. 自社のドメインが "example.jp" で、
自社発のメールの送信ドメイン認証の結果が
"Authentication-Results: example.jp;
spf=pass smtp.mailfrom=sample@ example.jp;
sender-id=pass header.From=sample@ example.jp;
dkim=pass header.i=@ example.jp;
dkim-adsp=pass" の場合、
許可ルールの対象とキーワードは
[Authentication-Results:]、
[*spf=pass*smtp.mailfrom=*@ example.jp*]
(ワイルドカード ON) などとする
3. 自社発のメールの送信ドメイン認証の結果が
"Received-SPF: pass" の場合、
許可ルールの対象とキーワードは
[<header>]、
[Return-Path: *@ example.jp&&Received-SPF: pass*]
(ワイルドカード ON、論理演算子 ON) などとする
※受信メールのヘッダに Authentication-Results: または
Received-SPF: などが記録されている必要があります。
※代案(A)(B)で対応できない場合、自社のドメインに加えて、
以下のような補完的な条件の併用を検討して下さい。
1. 社内規定で使用ソフトが厳格に決められているとき、
X-Mailer: や User-Agent: に記載されているメールソフト名
2. 社内の全 PC で共通のセキュリティソフトを利用しているとき、
セキュリティソフトが送信メールに挿入する検査結果
3. その他、自社発のメールに付与される特徴的なフィールド名
※複数の条件を併用する場合、
<header> と論理演算子 && の組み合わせで対応するか、
ユーザーテンプレートでルールを定義する必要があります。