コンテンツ ディクショナリは、アプライアンスの本文スキャン機能と連携して動作する単語またはエントリのグループであり、コンテンツ フィルタおよびメッセージ フィルタの両方に利用できます。定義したディクショナリを使用し、ディクショナリに含まれる単語に対してメッセージ、メッセージ ヘッダー、およびメッセージの添付ファイルをスキャンすることで、企業のポリシーに沿った適切なアクションを実行できます。たとえば、機密性の高い単語や野卑な単語のリストを作成し、フィルタ ルールを使用してリスト内の単語を含むメッセージをスキャンし、メッセージをドロップ、アーカイブ、または隔離できます。

AsyncOS オペレーティング システムには、GUI（[メール ポリシー（Mail Policies）] > [辞書（Dictionaries）]）または CLI の dictionaryconfig コマンドを使用して、合計 100 個のコンテンツ ディクショナリを定義する能力があります。ディクショナリの作成、削除、および表示、ディクショナリからのエントリの追加または削除、およびディクショナリ全体のインポートまたはエクスポートができます。

コンテンツ ディクショナリを使用して、企業のポリシーに沿った適切なアクションを実行できるようにメッセージまたはコンテンツ フィルタに対してメッセージをスキャンできます。ディクショナリの作成、削除、および表示、ディクショナリからのエントリの追加または削除、およびディクショナリ全体のインポートまたはエクスポートができます。ディクショナリごとに、大文字と小文字の区別および単語の区切りの検出方法を決定することもできます。たとえば、機密性の高い単語や野卑な単語のリストを作成し、フィルタ ルールを使用してリスト内の単語に対してメッセージをスキャンし、一致する単語を含むメッセージをドロップまたはアーカイブできます。また、単語によってフィルタ アクションをより簡単にトリガーできるように、ディクショナリに「重み」の条件を追加できます。

ディクショナリには、非 ASCII 文字を含めることができます。

効率的に処理するため、次のコンテンツ ディクショナリのエントリは単語として処理されることに注意してください。

• 英数字のみを含むエントリ
• 0 ～ 9、A ～ Z、a ～ z、ドット、アンダースコア、ハイフン、アット マークを含む電子メール アドレス
• 0 ～ 9、A ～ Z、a ～ z、ドット、アンダースコア、ハイフン、アット マークを含むドメイン名

このような単語を正規表現としてアプライアンスに処理させる場合は、たとえば (user@example.com) のように、その単語をカッコで囲みます。

テキスト リソースは、免責事項、通知テンプレート、アンチウイルス テンプレートなどのテキスト オブジェクトです。AsyncOS のさまざまなコンポーネントで使用できる新規オブジェクトを作成できます。テキスト リソースをインポートおよびエクスポートできます。

メッセージの免責事項スタンプを使用すると、免責事項のテキスト リソースをメッセージに追加できます。たとえば、企業内から送信される各メッセージに著作権宣言文、宣伝メッセージ、または免責事項を付加できます。

ディクショナリの単語は 1 行につき 1 つのテキスト文字列で作成し、エントリはプレーン テキストまたは正規表現の形式で記載できます。ディクショナリには、非 ASCII 文字を含めることもできます。正規表現のディクショナリを定義すると、より柔軟に単語を照合させることができます。ただし、このためには適切に単語を区切る方法を理解する必要があります。Python スタイルの正規表現の詳細については、次の URL からアクセスできる「Python Regular Expression HOWTO」を参考にしてください。

http://www.python.org/doc/howto/

（注）	ディクショナリのエントリの最初に特殊文字 # を使用すると、文字クラス [#] をコメントとして扱われることなく使用できます。

単語によってフィルタ条件をより簡単にトリガーできるように、各単語に「重み」を指定できます。AsyncOS では、コンテンツ ディクショナリの単語に対してメッセージをスキャンし、単語インスタンスの数に単語の重みを掛けることでメッセージのスコアを付けます。2 つの単語インスタンスに 3 の重みが付いている場合、スコアは 6 になります。AsyncOS は、このスコアをコンテンツ フィルタまたはメッセージ フィルタに関連するしきい値と比較し、メッセージがフィルタ アクションをトリガーするかどうかを決定します。

コンテンツ ディクショナリにスマート ID を追加することもできます。スマート ID は、社会保障番号や ABA ルーティング番号など共通の数字パターンに一致するパターンをデータ内から検索するアルゴリズムです。これらの ID はポリシーの拡張に便利です。正規表現の詳細については、「Using Message Filters to Enforce Email Policies」の章にある「Regular Expressions in Rules」を参照してください。スマート ID の詳細については、「Using Message Filters to Enforce Email Policies」の章にある「Smart Identifiers」を参照してください。

（注）	端末の CLI に非 ASCII 文字を含むディクショナリが正しく表示される場合とされない場合があります。非 ASCII 文字を含むディクショナリを表示および変更する最適な方法は、ディクショナリをテキスト ファイルにエクスポートし、テキスト ファイルを編集して、新しいファイルを再びアプライアンスにインポートする方法です。詳細については、テキスト ファイルとしてディクショナリをインポートおよびエクスポートする方法を参照してください。

コンテンツ ディクショナリ機能には、デフォルトでアプライアンスの configuration ディレクトリに配置されている次のテキスト ファイルが含まれます。

• config.dtd
• profanity.txt
• proprietary_content.txt
• sexual_content.txt

これらのテキスト ファイルは、コンテンツ ディクショナリ機能と組み合わせて使用することで、新規ディクショナリの作成をサポートすることを目的としています。これらのコンテンツ ディクショナリは重み付けされており、スマート ID を使用することでデータ内のパターンを高い精度で検出し、コンプライアンスの問題となるパターンの場合にはフィルタをトリガーします。

（注）	ディクショナリをインポートおよびエクスポートする場合は、完全に一致する単語の設定と大文字と小文字を区別する設定が保持されません。この設定は、設定ファイルにのみ保持されます。

configuration ディレクトリへのアクセスの詳細については、FTP、SSH、および SCP アクセスを参照してください。

ユーザ独自のディクショナリ ファイルを作成して、アプライアンスにインポートすることもできます。非 ASCII 文字をディクショナリに追加する最適な方法は、アプライアンス以外の場所でテキスト ファイルのディクショナリに単語を追加し、アプライアンス上にファイルを移動してから新しいディクショナリとしてファイルをインポートする方法です。ディクショナリのインポートの詳細については、ディクショナリのインポートを参照してください。ディクショナリのエクスポートについては、ディクショナリのエクスポートを参照してください。

注意	これらのテキスト ファイルには、一部の人の間では卑猥、下品または不快に感じられる単語が含まれています。これらのファイルからコンテンツ ディクショナリに単語をインポートした場合、アプライアンスに設定したコンテンツ ディクショナリを後で閲覧する際にこれらの単語が表示されます。

dictionary-match(<dictionary_name>) という名前のメッセージ フィルタ ルール（および同様のルール）は、メッセージの本文にコンテンツ ディクショナリ（dictionary_name）に存在するいずれかの正規表現が含まれる場合に有効と判断されます。該当のディクショナリが存在しない場合は、ルールは無効と判断されます。

dictionary-match() ルールは、body-contains() 本文スキャン ルールと同様にメッセージ本文と添付ファイルのみをスキャンし、ヘッダーをスキャンしないことに注意してください。

ヘッダーのスキャンには、適切な *-dictionary-match() タイプのルールを使用できます（subject-dictionary-match() や、より一般的なルールでカスタム ヘッダーを含むすべてのヘッダーを指定できる header-dictionary-match() など、特定のヘッダーに対するルールが存在します）。ディクショナリの照合の詳細については、「Using Message Filters to Enforce Email Policies」の章にある「Dictionary Rules」を参照してください。

dictionary-match
(<dictionary_name>)

次の例では dictionary-match() ルールを使用して、アプライアンスが（前回の例で作成した）「secret_words」という名前のディクショナリ内の単語を含むメッセージをスキャンした際に、管理者にメッセージをブラインド カーボン コピーで送信する新規メッセージ フィルタが作成されます。設定値によっては、大文字/小文字も含めて「codename」と完全に一致する単語を含むメッセージのみが、このフィルタで有効と判断されることに注意してください。

bcc_codenames:

if (dictionary-match ('secret_words'))

{

bcc('administrator@example.com');

}

この例では、ポリシー隔離にメッセージを送信します。

quarantine_codenames:

if (dictionary-match ('secret_words'))

{

quarantine('Policy');


}

アプライアンスの configuration ディレクトリに対するアクセス権を持っている必要があります。インポートするテキスト ファイルは、アプライアンス上の configuration ディレクトリに存在する必要があります。エクスポートされたテキスト ファイルは、configuration ディレクトリに配置されます。

configuration ディレクトリへのアクセスの詳細については、FTP、SSH、および SCP アクセスを参照してください。

非 ASCII 文字をテキスト リソースに追加するには、アプライアンス以外の場所でテキスト ファイルのテキスト リソースに単語を追加し、アプライアンス上にファイルを移動し、新しいテキスト リソースとしてファイルをインポートします。テキスト リソースのインポートの詳細については、テキスト リソースのインポートを参照してください。テキスト リソースのエクスポートについては、テキスト リソースのエクスポートを参照してください。

免責事項などの一部のテキスト リソースは、HTML ベースのメッセージおよびプレーン テキスト メッセージの両方を使用して作成できます。HTML ベースのメッセージとプレーン テキスト メッセージの両方を含むテキスト リソースが電子メール メッセージに適用された場合、HTML ベースのテキスト リソース メッセージは電子メール メッセージのテキストまたは HTML 部分に適用され、プレーン テキスト メッセージは電子メール メッセージのテキストまたはプレーン部分に適用されます。

HTML ベースのテキスト リソースを追加または編集する場合、GUI には、HTML コードを手動で記述せずにリッチ テキストの入力を可能にするリッチ テキスト編集が含まれます。

HTML ベースのテキスト リソースを追加および編集する場合は、次の点に留意してください。

• HTML バージョンに基づいて、メッセージのプレーン テキスト バージョンを自動的に生成するよう選択できます。または、プレーン テキスト バージョンを個別に定義できます。
• [コードビュー（Code View）] ボタンをクリックすることにより、リッチ テキスト エディタと HTML コード間を切り替えることができます。
• リッチ テキスト エディタでサポートされない HTML コードを GUI で入力するには、コード ビューに切り替え、HTML コードを手動で入力します。たとえば、これは、<img src> HTML タグを使用して外部サーバにあるイメージ ファイルへの参照を挿入する場合に行います。

アプライアンスは、リスナーが受信した一部またはすべてのメッセージのテキストの上または下（ヘッダーまたはフッター）にデフォルトの免責事項を追加できます。次の方法を使用して、アプライアンスでメッセージに免責事項を追加できます。

• リスナーから、GUI または listenerconfig コマンドを使用する方法（リスナーからの免責事項テキストの追加を参照）。
• コンテンツ フィルタ アクション Add Disclaimer Text を使用する方法（コンテンツ フィルタのアクションを参照）。
• メッセージ フィルタ アクション add-footer() を使用する方法（の「Using Message Filters to Enforce Email Policies」の章を参照）。
• データ消失防止プロファイルを使用する方法（データ損失の防止を参照）。
• メッセージの目的がフィッシングまたはマルウェアの配布である可能性があることをユーザに通知するようアウトブレイク フィルタに対してメッセージの修正を使用する方法（メッセージの変更を参照）。このタイプの通知に追加される免責事項は、テキストの上に追加されます。

たとえば、企業内から送信される各メッセージに著作権宣言文、宣伝メッセージ、または免責事項を付加できます。

免責事項テキストを使用する前に、免責事項テンプレートを作成する必要があります。GUI で [テキストリソース（Text Resources）] ページを使用（テキスト リソースの追加を参照）または textconfig コマンドを使用（『CLI Reference Guide for AsyncOS for Cisco Email Security Appliances』を参照）して、使用するテキスト文字列のセットを作成および管理します。

AsyncOS には、異なる文字エンコード方式を含む免責事項スタンプの動作を変更するために使用される設定値が存在します。デフォルトでは、AsyncOS は電子メール メッセージの本文パート内に添付されるように、免責事項を配置します。localeconfig コマンド内で設定した設定値を使用して、本文パートと免責事項のエンコード方式が異なる場合の動作を設定できます。数個のパートから構成される電子メール メッセージを確認することで、この設定が理解しやすくなります。

最初の空白行に続くメッセージの本文には、多くの MIME パートが含まれている場合があります。多くの場合、最初のパートは「本文」または「テキスト」と呼ばれ、2 番目以降のパートは「アタッチメント」と呼ばれます。

免責事項は「アタッチメント」（上記の例）または本文の一部として、電子メールに含めることができます。

一般的に、メッセージの本文と免責事項の間でエンコード方式の不一致が起こると、免責事項が本文に含まれ（インライン）個別のアタッチメントとして含まれないように、AsyncOS はメッセージ全体をメッセージの本文と同じエンコード方式でエンコードしようとします。つまり、免責事項と本文のエンコード方式が一致する場合、または免責事項のテキストに（本文の）インラインに表示できる文字が含まれている場合は、免責事項はインラインに含められます。たとえば、US-ASCII 文字のみを含む ISO-8859-1 エンコードされた免責事項が生成される可能性があります。結果的に、この免責事項は問題なく「インライン」に表示されます。

ただし、免責事項が本文と組み合わせられない場合、localeconfig コマンドを使用し、本文テキストを昇格または変換して免責事項のエンコード方式と一致させるように AsyncOS を設定することで、免責事項をメッセージの本文に含めることができます。

example.com> localeconfig

Behavior when modifying headers: Use encoding of message body
Behavior for untagged non-ASCII headers: Impose encoding of message body
Behavior for mismatched footer or heading encoding: Try both body and footer or heading encodings
Behavior when decoding errors found: Disclaimer is displayed as inline content and the message body is added as an attachment.

Choose the operation you want to perform:
- SETUP - Configure multi-lingual settings.
[]> setup

If a header is modified, encode the new header in the same encoding as the message body? 
(Some MUAs incorrectly handle headers encoded in a different encoding than the body. 
However, encoding a modified header in the same encoding as the message body may cause certain 
characters in the modified header to be lost.) [Y]>

If a non-ASCII header is not properly tagged with a character set and is being used or modified, 
impose the encoding of the body on the header during processing and final representation of the message? 
(Many MUAs create non-RFC-compliant headers that are then handled in an undefined way. 
Some MUAs handle headers encoded in character sets that differ from that of the main body in an incorrect way. 
Imposing the encoding of the body on the header may encode the header more precisely. 
This will be used to interpret the content of headers for processing, it will not modify or rewrite the 
header unless that is done explicitly as part of the processing.) [Y]>

Disclaimers (as either footers or headings) are added in-line with the message body whenever possible. 
However, if the disclaimer is encoded differently than the message body, and if imposing a single encoding 
will cause loss of characters, it will be added as an attachment. The system will always try to use the 
message body's encoding for the disclaimer. If that fails, the system can try to edit the message body to 
use an encoding that is compatible with the message body as well as the disclaimer. Should the system try to 
re-encode the message body in such a case? [Y]>

If the disclaimer that is added to the footer or header of the message generates an error when decoding the message body, 
it is added at the top of the message body. This prevents you to rewrite a new message content that must merge with 
the original message content and the header/footer-stamp. The disclaimer is now added as an additional MIME part 
that displays only the header disclaimer as an inline content, and the rest of the message content is split into 
separate email attachments. Should the system try to ignore such errors when decoding the message body? [N]>

Behavior when modifying headers: Use encoding of message body
Behavior for untagged non-ASCII headers: Impose encoding of message body
Behavior for mismatched footer or heading encoding: Try both body and footer or heading encodings
Behavior when decoding errors found: Disclaimer is displayed as inline content and the message body 
is added as an attachment.

Choose the operation you want to perform:
- SETUP - Configure multi-lingual settings.
[]>

localeconfig コマンドの詳細については、「Configuring the Appliance to Receive Mail」の章を参照してください。

通知テンプレートは、notify() および notify-copy() フィルタ アクションで使用されます。通知テンプレートには、アンチウイルス通知により使用されるアンチウイルス関連の変数を含む非 ASCII テキストおよびアクション変数を含めることができます（「Using Message Filters to Enforce Email Policies」の章にある「Action Variables」を参照）。たとえば、$Allheaders アクション変数を使用して、元のメッセージのヘッダーを含めることができます。通知用の From: アドレスを設定できます。アプライアンスに生成されるメッセージの返信アドレスの設定を参照してください。

通知テンプレートを作成したら、コンテンツ フィルタおよびメッセージ フィルタから参照させることができます。次の図は、「grapewatchers@example.com」に「grape_text」通知が送信されるように notify-copy() フィルタ アクションを設定したコンテンツ フィルタを示しています。

アンチウイルス通知テンプレートには、次の 2 つのタイプがあります。

• アンチウイルス通知テンプレート。アンチウイルス通知テンプレートは、元のメッセージがウイルス通知に添付されていない場合に使用されます。
• アンチウイルス コンテナ テンプレート。コンテナ テンプレートは、元のメッセージが添付ファイルとして送信される際に使用されます。

アンチウイルス通知テンプレートは、フィルタの代わりにアンチウイルス エンジンで使用される以外は、基本的に通知テンプレートと同様に使用されます。メール ポリシーの編集中に送信するカスタム通知を指定できます。ウイルス対策通知用の From: アドレスを設定できます。詳細については、アプライアンスに生成されるメッセージの返信アドレスの設定を参照してください。

バウンス通知および暗号化失敗通知テンプレートは、バウンス通知およびメッセージ暗号化失敗通知で使用される以外は、基本的に通知テンプレートと同様に使用されます。暗号化プロファイルを編集中に、バウンス プロファイルおよびカスタム メッセージ暗号化失敗通知を編集していた場合に送信するカスタム バウンス通知を指定できます。

次の図は、バウンス プロファイルで指定されたバウンス通知テンプレートを示しています。

（注）	カスタム テンプレートを使用する場合は、RFC-1891 の DSN を使用してください。

次の図は、暗号化プロファイルで指定された暗号化失敗テンプレートを示しています。

暗号化通知テンプレートは、アウトバウンド電子メールを暗号化するように Cisco 電子メール暗号化を設定した際に使用されます。この通知では、受信者が暗号化されたメッセージを受信したことを通知し、メッセージを読む手順を説明しています。暗号化メッセージと一緒に送信するカスタム暗号化通知を指定できます。暗号化プロファイルを作成する際は、HTML 形式およびテキスト形式の両方の暗号化通知を指定します。このため、カスタム プロファイルを作成する場合は、テキスト形式および HTML 形式の両方の通知を作成する必要があります。