JP2009301559A - プログラム - Google Patents

Abstract

【課題】複数の宛先が指定されている電子メールを配送する場合に、差出人に、電子メールの宛先を見直す機会を与えることが可能な電子メールを配送するためのプログラムを提供すること。
【解決手段】複数の宛先が指定された電子メールを受け付けた場合に、宛先毎に、宛先のドメインが有効か否かを判断し、無効なドメインであると判断された宛先が存在する場合には、電子メールの配送を保留する。
【選択図】図３

Description

本発明は、プログラムに関する。

従来から、電子メールがコミュニケーションツールとして利用されており、ＭＵＡ（Ｍａｉｌ Ｕｓｅｒ Ａｇｅｎｔ）から電子メールを受け付けて、電子メールを配送（配信、送信、転送）する処理を行なうＭＴＡ（Ｍａｉｌ Ｔｒａｎｓｆｅｒ Ａｇｅｎｔ）が存在する。

ここで、ＭＵＡとは、インターネット上の端末において電子メールを送受信するために使用されるクライアントプログラムであり、ＭＴＡとは、ＳＭＴＰ（Ｓｉｍｐｌｅ Ｍａｉｌ Ｔｒａｎｓｆｅｒ Ｐｒｏｔｏｃｏｌ）を通じてネットワーク上で電子メールの受信と配送を行うサーバのことをいう。

従来では、例えば電子メールを所定の区分情報に基づいて区分して、所定の区分に該当する電子メールを保留する機能を備えたＭＴＡが存在していた（特許文献１）。

特開２００６−１８５０９４号公報

通常、電子メールは、エンベロープ（Ｅｎｖｅｌｏｐｅ）とメッセージデータで構成される。エンベロープは、差出元と、宛先のデータで構成されており、ＭＵＡから電子メールを受け取ったＭＴＡは、エンベロープの宛先に基づいて、電子メールを配送する処理を行っている。

そして、従来のＭＴＡは、何らかの理由で、宛先に電子メールを配送できない場合には、配送不能のエラーメッセージを差出元に通知していた。したがって、差出人（送信者）は、どの宛先に送信できなかったのかを検知できた。

しかし、複数の宛先が指定されている電子メールを配送する際に、一方の宛先では電子メールを配送することができ、他方の宛先では電子メールを配送することができない場合には、電子メールが配送された受信者は、他方で配送できなかった宛先があったことを検知することができなかった。

つまり、従来のＭＴＡでは、複数の宛先が指定された電子メールを配送する際に、複数の宛先の相互間において配送不能の宛先が存在している状況を共有することができない問題が発生してしまう。

本願発明は、上述した課題に鑑みたものであり、複数の宛先が指定されている電子メールを配送する場合に、差出人に、電子メールの宛先を見直す機会を与えることが可能な電子メールを配送するためのプログラムを提供することにある。

（１）本発明は、宛先が指定された電子メールを配送するサーバのためのプログラムであって、差出元から送信され、複数の宛先が指定された電子メールを受け付ける受け付け部と、宛先毎に、宛先のドメインが有効か否かを判断するドメイン判断部と、無効なドメインであると判断された宛先が存在する場合には、前記複数の宛先の全てに対する前記電子メールの配送を保留する保留部として、コンピュータを機能させるプログラムに関する。本発明は、上記プログラムを記憶した情報記憶媒体、上記各部として構成するサーバに関係する。本発明によれば、複数の宛先を指定された電子メールの場合、無効なドメインの宛先が存在する場合に、複数の宛先全てに対する電子メールの配送が保留されるので、差出人に、宛先を見直す機会を与えることができる。

（２）また、本発明のプログラム、情報記憶媒体、サーバは、前記電子メールの配送が保留された場合には、保留されたことを通知する通知メールを前記電子メールの差出元に通知する通知部として、コンピュータを更に機能させてもよい。本発明によれば、差出人に、宛先を見直すことを示唆することができる。

（３）また、本発明のプログラム、情報記憶媒体、サーバは、前記通知部が、無効なドメインであると判断された宛先を前記差出元に通知するようにしてもよい。本発明によれば、差出人は、いずれの宛先を見直せばよいのかを瞬時に把握することができる。

本実施形態のサーバの機能ブロックの例。 本実施形態のサーバの処理の概要を示した図。 本実施形態の電子メールの配送の例を示す図。 本実施形態の通知メールの一例。 図５（Ａ）は、本実施形態のフローチャートの一例。 図５（Ｂ）は、本実施形態のフローチャートの一例。 図５（Ｃ）は、本実施形態のフローチャートの一例。 図５（Ｄ）は、本実施形態のフローチャートの一例。 図５（Ｅ）は、本実施形態のフローチャートの一例。 図５（Ｆ）は、本実施形態のフローチャートの一例。 本実施形態のフローチャートの一例。 本実施形態の教育用の通知メールの一例。

以下、本実施形態について説明する。なお、以下に説明する本実施形態は、特許請求の範囲に記載された本発明の内容を不当に限定するものではない。また本実施形態で説明される構成の全てが、本発明の必須構成要件であるとは限らない。

１．構成
図１は、本実施形態のサーバ１０の機能ブロック図の一例である。なお本実施形態のサーバ１０は、図１の各部を全て含む必要はなく、その一部を省略した構成としてもよい。

記憶部１７０は、処理部１００などのワーク領域となるもので、記憶部１７０には、本実施形態の各部としてコンピュータを機能させるためのプログラム（各部の処理をコンピュータに実行させるためのプログラム）を記憶することができる。

記憶部１７０は、プログラムやデータなどを格納するものであり、その機能は、ＲＡＭ（ＶＲＡＭ）、光ディスク（ＣＤ、ＤＶＤ）、光磁気ディスク（ＭＯ）、磁気ディスク、ハードディスク、磁気テープ、或いはメモリ（ＲＯＭ）等、によりコンピュータにより読み取り可能な情報記憶媒体で実現できる。

本実施形態の記憶部１７０には、顧客ＤＢ１７１（ＤＢはデータベースの略、以下同様。）、ユーザＤＢ１７２、保留メール格納領域１７３、アクション履歴ＤＢ１７４、ルールＤＢ１７５が記憶される。

顧客ＤＢ１７１には、顧客識別情報（顧客ＩＤ）に対応付けて顧客の氏名、会社名（名称、略称等）、メールアドレス等が記憶される。ユーザＤＢ１７２には、ユーザ識別情報（ユーザＩＤ）に対応付けてユーザ（社員）のメールアドレス、ユーザ用ユーザインターフェースへのログインパスワード等が記憶される。保留メール格納領域１７３には、保留メール識別情報（保留メールＩＤ）に対応付けて保留された電子メールが記憶される。アクション履歴ＤＢ１７４には、履歴識別情報（履歴ＩＤ）に対応付けて保留処理がなされた電子メールの状態が記憶される。ルールＤＢ１７５には、ルール識別情報（ルールＩＤ）に対応付けて、有効、無効の設定情報、ルールスコア等が記憶される。

処理部１００は、記憶部１７０に格納されるプログラム（データ）に基づいて本実施形態の種々の処理を行う。

処理部１００（プロセッサ）は、記憶部１７０内の主記憶部をワーク領域として各種処理を行う。処理部１００の機能は各種プロセッサ（ＣＰＵ、ＤＳＰ等）などのハードウェアや、プログラムにより実現できる。

処理部１００は、メール処理部（ＭＴＡ）１１０と、Ｗｅｂ処理部１２０と、データベース処理部１３０とを含む。

メール処理部１１０は、ＳＭＴＰを通じてネットワーク上で電子メールの受信と配送を行う。本実施形態のメール処理部１１０は、受け付け部１１２、解析部１１３、評価部１１４、保留判定部１１５、送信部１１６、保留部１１８、保留メール処理部１１９を含む。

受け付け部１１２は、端末２０のＭＵＡ２１１によって、差出元から送信され、エンベロープの宛先が指定された電子メールを受け付ける処理を行う。特に、本実施形態の受け付け部１１２は、電子メールのエンベロープの差出元が、ユーザＤＢに登録されているか否かを判断し、差出元が登録されている場合に、電子メールを受け付ける処理を行う。なお、差出元がユーザＤＢに登録されていない場合には、通知部１１６ａが、差出元に電子メールの受け付けを拒否する内容を通知する拒否通知メールを生成して送信する。

解析部１１３は、受け付けた電子メールを解析する処理を行う。例えば、エンベロープの宛先、エンベロープの差出元、メッセージのヘッダ、メッセージのボディの本文部分を解析する処理を行う。例えば、エンベロープの宛先のうちドメインを抽出したり、メッセージのヘッダのうち、Ｔｏ、Ｃｃ、Ｂｃｃ、Ｓｕｂｊｅｃｔを抽出する処理を行う。また、メッセージのボディ部分のうち、本文を抽出する処理を行う。

評価部１１４は、複数のルールに基づいて電子メールをスコアリングし、スコアとしきい値とに基づいて、電子メールを評価する処理を行う。なお、本実施形態のルールとは、ルールスコアを加点するための加点条件である。

本実施形態の評価部１１４は、ヘッダの宛先（Ｔｏ、Ｃｃ）に対応付けて設定される特定文字列が、電子メールに含まれるか否かに基づいて、電子メールを評価する。例えば、ヘッダの宛先に対応付けて設定される特定文字列とは、顧客の氏名、会社名等である。具体的には、ヘッダのＴｏ、Ｃｃに対応付けて設定される顧客の氏名が、電子メールの本文に含まれているか否かを判断し、判断結果に基づき電子メールをスコアリングしてスコアを算出する処理を行う。

評価する処理とは、電子メールの評価結果を決定する処理である。例えば、評価結果は、スコアリングされた電子メールのスコアの値そのものでもよいし、スコアに基づいて決定される５段階評価（１〜５の数値に基づく評価）、３段階評価（優・良・可）、２段階評価（良い・悪い）等でもよい。

ドメイン判断部１１４ａは、ルールの１つであり、複数のエンベロープの宛先が指定されたメールを受け付けた場合に、エンベロープの宛先毎に、エンベロープの宛先のドメインが有効か否かを判断する。具体的に説明すると、ＤＮＳサーバから、エンベロープの宛先のドメインのＭＸレコードの問い合わせに対する応答を受信した場合、又は、ＤＮＳサーバから、エンベロープの宛先のドメインのＡレコードの問い合わせに対する応答を受信した場合には、エンベロープの宛先のドメインが有効であると判断する。一方、ＤＮＳサーバから、エンベロープの宛先ドメインのＭＸレコード及びＡレコードの問い合わせに対する応答を受信しない場合には、エンベロープの宛先のドメインは無効であると判断する。

保留判定部１１５は、電子メールのスコアに基づいて、電子メールの配送を保留するか否かを判定する。例えば、電子メールのスコアがしきい値より大きい値である場合には電子メールの配送を保留する処理を行い、電子メールのスコアがしきい値以下である場合には電子メールの配送を保留せずに、電子メールを配送する処理を行う。

送信部１１６は、データを端末２０に送信する処理を行う。本実施形態において、送信部１１６は、通知部１１６ａ、配送部１１６ｂを含む。

通知部１１６ａは、電子メールの配送が保留された場合に通知する保留通知メール、拒否通知メール、配送不能エラーメッセージ等を差出元に通知する処理を行う。例えば、保留通知メールの内容は、電子メールの評価結果（スコア等）、特定文字列が電子メールに含まれるか否か、無効なドメインであると判断されたエンベロープの宛先等である。

配送部１１６ｂは、電子メールの評価結果（保留判定結果）に基づいて、電子メールを配送する処理を行う。つまり、配送部１１６ｂは、電子メールの配送を保留しないと判定された場合に、受け付けた電子メールを配送する処理を行う。

保留部１１８は、電子メールの評価結果（保留判定結果）に基づいて、電子メールの配送を保留する処理を行う。つまり、保留部１１８は、電子メールの配送を保留すると判定された場合に、電子メールの配送を保留し、保留された電子メールを記憶部１７０の保留メール格納領域１７３に記憶する処理を行う。

保留部１１８は、複数のエンベロープの宛先が指定された電子メールを受け付けた場合であって、複数のエンベロープの宛先のうち無効なドメインであると判断されたエンベロープの宛先が存在する場合には、電子メールの評価結果（保留判定結果）にかかわらず、複数のエンベロープの宛先の全てに対する電子メールの配送を保留してもよい。

保留メール処理部１１９は、所定条件に基づいて、保留された電子メールを配送又は削除する処理を行う。例えば、保留メール処理部１１９は、端末２０から送信された保留メールを配送する配送指示を受信した場合に、保留メールを配送する処理を行う。また、保留メール処理部１１９は、端末２０から送信された保留メールを削除する削除指示を受信した場合に、保留メールを削除する処理を行う。なお、保留メール処理部１１９は、端末２０から配送・削除の指示を受信せずに、一定期間経過した場合には、自動的に保留メールを配送する処理、自動的に保留メールを削除する処理を行う。

Ｗｅｂ処理部１２０は、ＨＴＴＰ（Ｈｙｐｅｒｔｅｘｔ Ｔｒａｎｓｆｅｒ Ｐｒｏｔｏｃｏｌ）を通じて、端末２０にインストールされているＷｅｂブラウザ２１０などのクライアントソフトウエアの要求に応じてＨＴＭＬ（Ｈｙｐｅｒ Ｔｅｘｔ Ｍａｒｋｕｐ
Ｌａｎｇｕａｇｅ）文書や画像などのデータを送信（提供）する処理、端末のＷｅｂブラウザにおいて受け付けたデータを受信する処理を行う。

管理者用ＵＩ部１２１（ＵＩはユーザインタフェースの略。以下同様。）は、端末２０のＷｅｂブラウザ２１０からのアクセス要求に応じて管理設定用のデータ等を端末２０に送信する処理を行い、端末２０から送信された各ルール（各ルール識別情報）に対応づけてルールの設定情報、各ルールスコアを受信する処理を行う。

ユーザ用ＵＩ部１２２は、端末２０のＷｅｂブラウザ２１０からの要求に応じて、ログインしたユーザに応じた保留メールのＷｅｂページ（ユーザのメールアドレスが差出元となっている保留メールのＷｅｂページ）を送信（提供）する処理を行う。またユーザ用ＵＩ部１２２は、端末２０のＷｅｂブラウザ２１０からの要求に応じて保留メールの送信・削除の指示を受け付けるためのＷｅｂページを送信する処理を行う。ユーザ用ＵＩ部１２２は、端末２０から送信された、保留された電子メールの配送指示、削除指示を受信する処理を行う。

データベース処理部１３０は、データベースに格納されているデータを、登録、更新、削除する処理を行う。例えば、データベース処理部１３０は、管理者用ＵＩ部１２１、ユーザ用ＵＩ部１２２において、端末から受信したデータに基づいて、データベースを更新する処理を行う。

なお、メール処理部１１０、Ｗｅｂ処理部１２０、データベース処理部１３０は１つの装置で実行させてもよいし、処理の用途に応じて異なる装置に分散して各処理を実行させるようにしてもよい。

２．概要
図２は、本実施形態のサーバの処理の流れの概要を示す。本実施形態のサーバは、配送処理に用いるエンベロープの宛先及びエンベロープの差出元、メッセージとからなる電子メールを受け付け、当該電子メールを配送するＭＴＡ機能を有する。

まず、本実施形態のサーバは、端末のＭＵＡから送信された電子メールを受け付け、受け付けた電子メールを解析して、予め定めた複数のルール、各ルールスコアに基づいて、電子メールをスコアリングする。

そして、電子メールのスコアが、しきい値よりも大きいか否かを判断して、電子メールを配送する処理、或いは、電子メールの配送を保留する処理を行い、電子メールが保留された場合には、保留されたことを差出元に通知する処理を行う。

ＭＴＡが、電子メールを配送するとは、ＳＭＴＰを通じて、受け付けた電子メールを他のＭＴＡに配送する処理や、メールサーバが稼動する同一システム内にアカウントを持つユーザ宛に配送するためのローカル配信エージェントＭＤＡ（Ｍａｉｌ Ｄｅｌｉｖｅｒｙ Ａｇｅｎｔ）に配送する処理、ＭＤＡを介せずにメールサーバが稼動する同一システム内にアカウントを持つユーザ宛に配送する場合も含む。

そして、本実施形態のサーバは、所定時間経過した場合や、ユーザからの指示を受け付けて保留メールを配送又は削除する処理を行う。

このように、本実施形態のサーバは、電子メールをルールに基づいてスコアリングを行い、電子メールのスコアに基づいて評価することができる。そして、スコアがしきい値より大きい値である場合には、内容の悪い電子メールとみなして、保留することができる。したがって、差出人に対して、電子メールを見直す機会を与えることができる。

さらに、本実施形態のサーバは、電子メールが保留された場合には、差出元に保留されたことを通知するので、差出人に対して電子メールの内容について注意喚起することができる。

３．電子メールを評価する手法
本実施形態では、ルールに基づいて電子メールのスコアリングを行い、電子メールを評価する。

（１）評価対象
本実施形態の電子メールの評価対象は、電子メールのエンベロープ、電子メールメッセージのヘッダ、ボディの一部又は全部である。

ここで、電子メールのエンベロープとは、ＳＭＴＰセッションにおいて、端末（ＭＵＡ）がサーバに対して送信する、宛先（エンベロープＴｏ）と、差出元（エンベロープＦｒｏｍ）である。つまり、サーバが電子メールを配送する際に使用するメールアドレスである。

本実施形態では、電子メールメッセージのボディの一部又は全部を本文として特定し、本文を評価対象としている。

具体的に説明すると、電子メールのメッセージが、テキスト形式のメッセージである場合には、ボディ全部を本文として扱う。また、電子メールのメッセージがＨＴＭＬ形式のみのメッセージである場合には、ボディのうちＨＴＭＬタグを除去した文字列を本文とする。また、電子メールのメッセージが、テキスト形式と、ＨＴＭＬ形式とからなるマルチパート形式のメッセージである場合には、テキスト形式の部分（テキスト形式のパートのボディ）を本文とする。

また、添付ファイルがある場合には、電子メールのメッセージは、マルチパート形式のメッセージであるので、１つ目のパートのボディを本文とする。例えば、１つ目のパートのボディがテキスト形式である場合には、１つ目のパートのボディを本文とする。１つ目のパートのボディがＨＴＭＬ形式である場合には、１つ目のパートのボディからＨＴＭＬタグを除去した文字列を本文として扱う。また、１つ目のパートのボディがテキスト形式とＨＴＭＬ形式とによるマルチパートの構成である場合には、テキスト形式の部分（テキスト形式のパートのボディ部分）を本文とする。

（２）スコアリング
次に、本実施形態におけるスコアリング（採点手法）について説明する。

本実施形態のＭＴＡは、ＭＵＡから電子メールを受け付けると、まず電子メールのスコアに初期値（例えば０点）を設定し、電子メールが複数のルールそれぞれのルールを満たすか否かを判断する処理を行い、ルールを満たす場合にはそのルールに対応するルールスコア（ルールの配点）を、電子メールのスコアに加点する処理を行う。以下、本実施形態のルールについて説明する。

（Ａ）ドメインチェック
本実施形態は、電子メールのエンベロープの宛先（宛先メールアドレス）のドメインが有効か否かを、ＤＮＳサーバ（ネームサーバ）に問い合わせて判断する処理を行う。つまり、エンベロープの宛先の配送可能性の有無を、予め、エンベロープの宛先のドメインに基づいて判断することになる。

ここで、メールアドレスのドメインとは、メールアドレスの「＠」以降に記載されている文字列であり、例えば、図３の「ａａａ＠ｘｘｘ．ｎｅ．ｊｐ」というメールアドレスのドメインは、「ｘｘｘ．ｎｅ．ｊｐ」である。

例えば、図３に示すように、本実施形態のＭＴＡが、ＭＵＡとＳＭＴＰセッションを確立されると、ＭＴＡはＭＵＡから、エンベロープの差出元（エンベロープＦｒｏｍ）「ａａａ＠ｘｘｘ．ｎｅ．ｊｐ」と、エンベロープの宛先（エンベロープＴｏ）「ｂｂｂ＠ｙｙｙ．ｃｏｍ」、「ｃｃｃ＠ｚｚｚ．ｏｒ．ｊｐ」とを取得する。

そして、ＤＮＳサーバに、各エンベロープの宛先のドメインのＭＸレコードの問い合わせを行い、ＤＮＳサーバからの応答を受信した場合には、エンベロープの宛先のドメインが有効であると判断する。

ＭＸレコードとは、メールアドレスのドメインと、配送先のサーバ名（メールサーバ名、メールエクスチャンジャ）との対応関係を示す情報である。したがって、本実施形態では、ＤＮＳサーバから、エンベロープの宛先のドメインの配送先のサーバ名を取得できた場合には、エンベロープの宛先のドメインが有効であると判断する。

また、ＤＮＳサーバからＭＸレコードの問い合わせの応答を受信しない場合には、ＤＮＳサーバに、エンベロープの宛先のドメインのＡレコードの問い合わせを行う。

Ａレコードは、ドメインと、ＩＰアドレスとの対応関係を示す情報である。そして、ＤＮＳサーバから、エンベロープの宛先のドメインのＩＰアドレスを受信できた場合には、エンベロープの宛先のドメインが有効であると判断する。

また、ＤＮＳサーバに対して、ＭＸレコード及びＡレコードの問い合わせに対する応答を受信しない場合には、エンベロープの宛先のドメインは無効であると判断する。

エンベロープの宛先のドメインが無効であると判断した場合には、ドメインチェックのルールスコアを電子メールのスコアに加点する処理を行う。

また、本実施形態では、複数のエンベロープの宛先が存在する場合には、複数のエンベロープの宛先それぞれにおいてドメインのチェックを行う。例えば、図３の例では、エンベロープの宛先の「ｂｂｂ＠ｙｙｙ．ｃｏｍ」、「ｃｃｃ＠ｚｚｚ．ｏｒ．ｊｐ」それぞれのドメインチェックを行う。

そして、エンベロープの宛先毎に、無効なドメインであると判断されると、ドメインチェックのルールスコアを電子メールのスコアに加点する処理を行う。

なお、ＤＮＳサーバは、エンベロープの宛先のドメインを管理しているＤＮＳサーバに直接問い合わせてもよいし、他のＤＮＳサーバでもよい。例えば、本実施形態のサーバのローカルエリア内のＤＮＳサーバ、もしくはその上位のＤＮＳサーバでもよい。

（Ｂ）機種依存文字チェック
電子メールのメッセージの本文に、機種依存文字が含まれているか否か判断する。具体的には、本文を構成する文字列から、機種依存文字の文字コードが存在するか否かを検索する処理を行う。機種依存文字が本文に存在する場合には、機種依存文字チェックのルールスコアを、電子メールのスコアに加点する処理を行う。

機種依存文字は、例えば、ＪＩＳの拡張文字（例えばＩＳＯ−２０２２−ＪＰ−ＭＳ）、ユーザ定義文字である。

（Ｃ）顔文字チェック
電子メールのメッセージの本文に、いわゆる顔文字（人の顔を文字で表した文字列）が含まれているか否かを判断する。具体的には、本文から顔文字を構成する文字列を検索し、検索された場合には、顔文字チェックのルールスコアを、電子メールのスコアに加点する処理を行う。なお、顔文字は、管理者用ＵＩにおいて、管理者が予め登録することができる。

（Ｄ）不適切用語チェック
電子メールのメッセージの本文に、不適切な用語が含まれているか否かを判断する。具体的には、本文から、予め設定された不適切用語の文字列を検索する処理を行う。不適切用語が検索された場合には、不適切用語チェックルールのスコアを、電子メールのスコアに加点する処理を行う。なお、不適切用語は、管理者用ＵＩにおいて、管理者が予め登録することができる。

（Ｅ）空行チェック
電子メールのメッセージの本文に、空行が存在するか否かを判断する。具体的には、本文から２回以上連続した改行文字からなる文字列を検索する処理を行う。２回以上連続した改行文字からなる文字列が検索されない場合には、空行チェックのルールスコアを、電子メールのスコアに加点する処理を行う。

（Ｆ）改行チェック
電子メールのメッセージの本文に、改行が存在するか否かを判断する。具体的には、本文から改行文字を検索する処理を行う。改行文字が検索されない場合には、改行チェックのルールスコアを、電子メールのスコアに加点する処理を行う。

（Ｇ）署名チェック
電子メールのメッセージの本文の末尾部分に、署名が存在するか否かを判断する。本文の末尾部分とは、本文の末端から遡って空行が発見されるまでの範囲（文字列）としている。そして、本文の末尾部分に、予め設定された署名を構成する文字列が含まれているか否かを判断する。署名が含まれていないと判断された場合には、署名チェックのルールスコアを、電子メールのスコアに加点する処理を行う。

（Ｈ）会社名チェック
電子メールのヘッダの宛先に対応する会社名（略称等）を、顧客ＤＢから取得し、取得した会社名が、電子メールのメッセージの本文の冒頭部分に含まれているか否かを判断する。本文の冒頭部分とは、本文の先頭から空行が発見されるまでの範囲（文字列）としている。そして、本文の冒頭部分に、会社名を構成する文字列が含まれていない場合には、会社名チェックのルールスコアを、電子メールのスコアに加点する処理を行う。

なお、会社名チェックにおけるヘッダの宛先とは、ヘッダのＴｏ、Ｃｃであり、ヘッダのＢｃｃを含まない。通常、ヘッダのＢｃｃは、差出人がヘッダのＴｏ、Ｃｃの受信者に対して秘匿させながら配送する場合に用いる宛先であるので、Ｂｃｃに対応する会社名が本文に記載されることは、通常、有り得ないからである。

（Ｉ）名前・敬称チェック
電子メールのヘッダの宛先に対応する名前（姓・名）を、顧客データベースから取得し、その名前が、電子メールのメッセージの本文の冒頭部分に含まれているか否かを判断する。本文の冒頭部分に、名前が含まれていると判断される場合には、予め定めた敬称（例えば、「様」、「御中」等）の文字、（文字列）が含まれているか否かを判断する。本文の冒頭部分に名前が存在しない場合には、名前・敬称チェックのルールスコアを、電子メールのスコアに加点する処理を行い、本文の冒頭部分に名前が存在する場合であって、敬称を構成する文字列が含まれていない場合にも、名前・敬称チェックのルールスコアを、電子メールのスコアに加点する処理を行う。なお、名前・敬称チェックにおけるヘッダの宛先とは、ヘッダのＴｏ、Ｃｃであり、ヘッダのＢｃｃを含まない。会社名チェックと同様、Ｂｃｃに対応する名前が本文に記載されることは、通常、有り得ないからである。

（Ｊ）未登録顧客チェック
電子メールのエンベロープの宛先が、顧客データベースに登録されているか否かを判断する処理を行う。電子メールのエンベロープの宛先が、顧客データベースに登録されていないと判断される場合には、未登録顧客チェックのルールスコアを、電子メールのスコアに加点する処理を行う。

（Ｋ）社外宛先混入チェック
電子メールのエンベロープの宛先が複数存在する場合には、エンベロープの宛先毎に、エンベロープの宛先のドメインが社内システム（本実施形態のＭＴＡのローカルエリアネットワークシステム）のドメインか否かを判断する。

そして、社内システムのドメインのエンベロープの宛先と、社外システムのドメインのエンベロープの宛先とが混在する場合には、社外宛先混入チェックのルールスコアを、電子メールのスコアに加点する処理を行う。

なお、社内システムのドメインのエンベロープの宛先数が、社外システムのドメインのエンベロープの宛先数よりも多いことを条件に、社外宛先混入チェックのルールスコアを、電子メールのスコアに加点してもよい。具体的には、社内システムのドメインのエンベロープの宛先数が、社外システムのドメインのエンベロープの宛先数よりも、所定数（例えば５）多いことを条件に、社外宛先混入チェックのルールスコアを、電子メールのスコアに加点してもよい。かかる場合には、管理者用ＵＩにおいて、予め管理者からの入力に基づいて、所定数を設定できるようにする。

また、社内システムのドメインのエンベロープの宛先数が、社外システムのドメインのエンベロープの宛先数よりも少ないことを条件に、社外宛先混入チェックのルールスコアを、電子メールのスコアに加点してもよい。具体的には、社内システムのドメインのエンベロープの宛先数が、社外システムのドメインのエンベロープの宛先数よりも、所定数（例えば５）少ないことを条件に、社外宛先混入チェックのルールスコアを、電子メールのスコアに加点してもよい。かかる場合には、管理者用ＵＩにおいて、予め管理者からの入力に基づいて、所定数を設定できるようにする。

４．保留
（１）保留判定処理
本実施形態では、電子メールのスコアに基づいて、電子メールの配送を保留するか否かを決定する。

具体的には、電子メールのスコアがしきい値よりも大きい値である場合に、電子メールの配送を保留する処理を行い、電子メールのスコアがしきい値以下である場合に保留せずに電子メールを配送する処理を行う。なお、保留メールは、記憶部の保留メール格納領域に記憶される。

（２）保留通知
本実施形態では、電子メールが保留された場合には、サーバが保留通知メールを作成し、エンベロープの差出元に送信する保留通知処理を行う。

図４は、保留通知メールの一例を示す。保留通知メールのメッセージはマルチパート形式にし、メッセージには、差出人が保留メールの配送、削除の処理を行うためのＵＲＬ、電子メールのスコア、そして、スコアの内訳が記載される。スコアの内訳は、ルールと、そのルールにおいて加算された点数、ルールにおける電子メールの該当箇所、検索対象となった文字や文字列が記載される。このようにすれば、差出人は、電子メールの、どの記載に問題があったのかを瞬時に把握することができる。また、保留通知メールに、保留メールがｅｍｌ形式で添付される。なお、保留通知メールには、後述する自動配送や自動削除が実行される日時を通知してもよい。

（３）保留メールの処理
本実施形態では、ユーザ毎に対応づけて閲覧できるユーザ用ＵＩの所定のＷｅｂページ（ＵＲＬ）において、差出人であるユーザからの、配送又は削除の指示を受け付け、配送の指示を受け付けた場合に保留メール格納領域に記憶されている保留メールを配送する処理を行い、削除の指示を受け付けた場合に保留メール格納領域に記憶されている保留メールを削除する処理を行う。なお、配送処理の場合も、電子メールの配送と共に保留メール格納領域から保留メールが削除される。

なお、差出人からの配送・削除の指示を受け付けずに、一定期間経過した場合には、サーバが自動的に、保留された電子メールのスコアに基づいて配送或いは削除の処理を行う。つまり、自動配送保留期間、或いは、自動削除保留期間を経過するまでは、ユーザは所定のＷｅｂページにおいて、電子メールの配送或いは削除の処理を行うことができる。

具体的に説明すると、自動配送しきい値、自動削除しきい値（自動削除しきい値＞自動配送しきい値）、保留されてから自動配送するまでの自動配送保留期間、保留されてから自動削除するまでの自動削除保留期間とに基づいて、自動的に保留メールの配送、又は削除の処理を行う。

例えば、保留された電子メールのスコアが自動削除しきい値よりも大きい値である場合には、自動削除保留期間経過後、自動削除を行う。

また、保留された電子メールのスコアが、自動配送しきい値よりも大きい値であって自動削除しきい値以下である場合には、自動配送保留期間経過後、保留された電子メールの自動配送を行う。

５．非通知保留処理
本実施形態のサーバは、電子メールのスコアがしきい値（自動配送しきい値）以下である場合に、保留通知を行わずに保留処理を行う非通知保留処理を行ってもよい。

非通知保留処理は、管理者用ＵＩにおいて、予め有効・無効の設定を管理者が行うことができる。つまり、非通知保留処理が有効に設定されている場合には、電子メールのスコアにかかわらず、一律に全ての電子メールが保留されることになる。このようにすれば、ユーザが配送した電子メールについて、電子メールを見直す機会を与えることができる。

本実施形態では、管理者用ＵＩにおいて、管理者からの入力を受け付けて、非通知保留処理の有効・無効の設定を行う。

また、非通知保留の対象となった電子メールは、非通知保留期間内にユーザから配送或いは削除の指示を受け付けなかった場合には、非通知保留期間経過後、自動的に保留された電子メールの配送処理を行う。

６．保留メールの処理の履歴
本実施形態のサーバは、保留メール処理の履歴を保存している。

つまり、一度保留処理がなされた電子メールの識別情報に対応づけて、その電子メールの状態を履歴として保存する。

電子メールの状態は、現在も保留中である場合には「保留」、ユーザからの配送指示に基づいて配送された「配送」、ユーザからの削除指示に基づいて削除された「削除」、自動的に配送された「自動配送」、自動的に削除された「自動削除」がある。

本実施形態では、ユーザ用ユーザインターフェースにおいて、そのユーザの保留メールを、保留メールの処理履歴用の所定のページにおいて、保留された電子メールの状態、メールの件名、エンベロープ情報、スコアとその内訳、保留メール処理がなされた日時を、ユーザは閲覧することができる。

７．ルールの有効性、ルールスコア、しきい値の設定手法
本実施形態では、上述した複数のルールそれぞれに、有効又は無効の設定をできるようにしてもよい。つまり、有効に設定されたルールに基づいて、ルールを満たすか否かを判断する。

また、本実施形態のルールスコアは予め所定のスコアを決めてもよい。例えば、ルールそれぞれのルールスコアを５点に設定してもよい。また、管理者権限で、ルール毎に、自由にルールスコアを設定してもよい。ルール毎に管理者がスコアを設定できるようにすればルールの重要度を調整することができる。また、ルールスコアは正の数でもよいし、負の数でもよい。例えば、点数が加点されるほど、電子メールの評価が悪くなるが、点数を減点して、電子メールの評価を良くするようにしてもよい。

また、保留判定で用いる自動配送しきい値、自動削除しきい値を、予め所定のしきい値に設定（例えば、自動配送しきい値を５０点、自動削除しきい値を８０点に設定）してもよいし、管理者権限で、しきい値を自由に設定できるようにしてもよい。なお、自動配送しきい値、自動削除しきい値は、自動配送しきい値＜自動削除しきい値の関係になるように設定する。

８．ユーザインターフェース
本実施形態のサーバは、Ｗｅｂサーバを併用しているので、端末のＷｅｂブラウザからの要求に応じて、ＨＴＴＰプロトコルを通じて、以下の情報を端末に送信すると共に、管理者やユーザから入力された情報を受信して、ルールの設定や、保留メールの処理、ＤＢの更新処理等を行うことができる。

（１）管理者用ＵＩ
管理者用ＵＩは、管理者からの入力に基づいて、ルール毎のスコアの設定や、顧客ＤＢ、社員ＤＢの追加、削除、更新処理、アクション履歴ＤＢの管理などを行う。

管理者用ＵＩでは、管理者からの入力に基づいて、ルールの有効、無効の設定、しきい値（自動配送しきい値、自動削除しきい値）の設定や、通知メールの編集、非通知保留処理の有効、無効の設定を行うことができる。

なお、管理者用ＵＩのＷｅｂページ（ＵＲＬ）へのアクセスは、管理者のみに権限が与えられる。つまり、ルール等の設定は管理者のみが行うことができるので、統一したルールに基づいて電子メールの保留処理を行うことができる。

（２）ユーザ用ＵＩ
ユーザ用ＵＩでは、社員ＤＢに登録されているユーザからの入力に基づくＷｅｂブラウザからの要求に応じて、ユーザ本人の保留された電子メールのＷｅｂページをユーザ端末に送信する処理を行う。またユーザ用ＵＩでは、ユーザからの保留メールに対する配送、削除のアクション指示を受け付けて、保留メールの配送、削除を行うことができる。また、ユーザからの入力に基づくＷｅｂブラウザからの要求に応じて、実行された保留メールのアクションの履歴を送信する処理を行う。また、ユーザ用ＵＩでは、ユーザからの入力に基づいて、顧客ＤＢにおいて会社名の新規登録や、署名の編集、ログイン時にパスワードの変更処理を行う。

９．フローチャート
本実施形態のサーバの処理の流れを図５（Ａ）〜（Ｆ）を用いて説明する。

（１）受け付け処理
まず、図５（Ａ）に示すように、電子メールを受け付け（ステップＳ１０）、電子メールのエンベロープの差出元がユーザＤＢに登録されているか否かを判断する（ステップＳ１１）。そして、差出元がユーザＤＢに登録されていると判断される場合には（ステップＳ１１のＹＥＳ）、評価処理へ進み、差出元がユーザＤＢに登録されていないと判断される場合には（ステップＳ１１のＮＯ）、拒否通知メールを通知する処理を行い（ステップＳ１２）、処理を終了する。

（２）評価処理
次に、評価処理について図５（Ｂ）を用いて処理の流れを説明すると、まず、エンベロープの宛先のドメインチェックを行う（ステップＳ２０）。

次に、電子メールの本文に機種依存文字が含まれるか否かを判断し（ステップＳ２１）、機種依存文字が含まれると判断される場合には（ステップＳ２１のＹＥＳ）、機種依存文字チェックのルールスコアを電子メールのスコアに加点する処理を行う（ステップＳ２２）。

次に、電子メールの本文に顔文字が含まれるか否かを判断し（ステップＳ２３）、電子メールの本文に顔文字が含まれると判断される場合には（ステップＳ２３のＹＥＳ）、顔文字文字チェックのルールスコアを電子メールのスコアに加点する処理を行う（ステップＳ２４）。

次に、電子メールの本文に不適切用語が含まれるか否かを判断し（ステップＳ２５）、電子メールの本文に不適切用語が含まれる場合には（ステップＳ２５のＹＥＳ）、不適切用語チェックのルールスコアを電子メールのスコアに加点する処理を行う（ステップＳ２６）。

次に、電子メールの本文に空行が含まれていないか否かを判断する（ステップＳ２７）。電子メールの本文に空行が含まれていない（ステップＳ２７のＹＥＳ）場合には、空行チェックのルールスコアを電子メールのスコアに加点する処理を行う（ステップＳ２８）。

次に、電子メールの本文に改行が含まれていないか否かを判断する（ステップＳ２９）。電子メールの本文に改行が含まれていない（ステップＳ２９のＹＥＳ）場合には、改行チェックのルールスコアを電子メールのスコアに加点する処理を行う（ステップＳ３０）。

次に、電子メールの本文に署名が含まれていないか否かを判断する（ステップＳ３１）。電子メールの本文に署名が含まれていない（ステップＳ３１のＹＥＳ）場合には、署名チェックのルールスコアを電子メールのスコアに加点する処理を行う（ステップＳ３２）。

次に、電子メールの本文の冒頭部分に、ヘッダの宛先に対応する会社名が含まれていないか否かを判断する（ステップＳ３３）。電子メールの本文の冒頭部分にヘッダの宛先に対応する会社名が含まれていない（ステップＳ３３のＹＥＳ）場合には、会社名チェックのルールスコアを電子メールのスコアに加点する処理を行う（ステップＳ３４）。

次に、電子メールの本文の冒頭部分に、ヘッダの宛先に対応する名前、ヘッダの宛先に対応する名前に対する敬称が含まれていないか否かを判断する（ステップＳ３５）。電子メールの本文の冒頭部分にヘッダの宛先に対応する名前が含まれていない場合、電子メールの本文の冒頭部分にヘッダの宛先に対応する名前に対応する敬称が含まれていない場合（ステップＳ３５のＹＥＳ）場合には、名前、敬称チェックのルールスコアを電子メールのスコアに加点する処理を行う（ステップＳ３６）。

次に、電子メールのエンベロープの宛先が、顧客データベースに登録されているか否かを判断する（ステップＳ３７）。電子メールのエンベロープの宛先が、顧客データベースに登録されていない場合には（ステップＳ３７のＹＥＳ）、未登録顧客チェックのルールスコアを電子メールのスコアに加点する処理を行う（ステップＳ３８）。

次に、配送する電子メールの複数のエンベロープの宛先に、社内宛と社外宛とが含まれているか否かを判断する（ステップＳ３９）。配送する電子メールの複数のエンベロープの宛先に、社内宛と社外宛とが含まれている場合には（ステップＳ３９のＹＥＳ）、社外宛先混入チェックのルールスコアを電子メールのスコアに加点する処理を行う（ステップＳ４０）。

（３）保留判定処理
保留判定処理について図５（Ｃ）を用いて説明する。

まず、電子メールのスコアが自動削除しきい値より大きいか否かを判断する（ステップＳ５０）。電子メールのスコアが自動削除しきい値より大きいと判断される場合には（ステップＳ５０のＹＥＳ）、保留メール処理（処理１）に進む。

電子メールのスコアが自動削除しきい値より大きいと判断されない場合には（ステップＳ５０のＮＯ）、電子メールのスコアが自動配送しきい値より大きいか否かを判断する（ステップＳ５１）。電子メールのスコアが自動配送しきい値より大きいと判断される場合には（ステップＳ５１のＹＥＳ）、保留メール処理（処理２）に進む。

電子メールのスコアが自動配送しきい値より大きいと判断されない場合には（ステップＳ５１のＮＯ）、非通知保留が有効か否かを判断する（ステップＳ５２）、非通知保留が有効である場合には（ステップＳ５２のＹＥＳ）、保留メール処理（処理３）に進む。非通知保留が有効でない場合には（ステップＳ５２のＮＯ）、電子メールを配送する処理を行い（ステップＳ５３）、処理が終了する。

（４）保留メール処理（処理１）
次に、保留メール処理（処理１）について図５（Ｄ）を用いて説明する。

まず、差出元に対して、保留通知メールを通知する（ステップＳ６０）。そして、自動削除保留時間が経過したか否かを判断する（ステップＳ６１）。自動削除保留時間が経過したと判断される場合には（ステップＳ６１のＹＥＳ）、保留された電子メールを削除する処理を行い（ステップＳ６２）、処理を終了する。一方、自動削除保留時間が経過していないと判断される場合には（ステップＳ６１のＮＯ）、差出人から処理アクション（配送又は削除の指示）を受け付けたか否かを判断する（ステップＳ６３）。

差出人から処理アクションを受け付けた場合には（ステップＳ６３のＹＥＳ）、処理アクションが削除の場合には、保留された電子メールを削除し、処理アクションが配送の場合には、保留された電子メールを配送する処理を行い（ステップＳ６４）、処理を終了する。一方、差出人から処理アクションを受け付けない場合には（ステップＳ６３のＮＯ）、ステップＳ６１に戻る。

（５）保留メール処理（処理２）
次に、保留メール処理（処理２）について図５（Ｅ）を用いて説明する。

まず、差出元に対して、保留通知メールを通知する（ステップＳ７０）。そして、自動配送保留時間が経過したか否かを判断する（ステップＳ７１）。自動配送保留時間が経過したと判断される場合には（ステップＳ７１のＹＥＳ）、保留された電子メールを配送する処理を行い（ステップＳ７２）、処理を終了する。一方、自動配送保留時間が経過していないと判断される場合には（ステップＳ７１のＮＯ）、差出人から処理アクション（配送又は削除の指示）を受け付けたか否かを判断する（ステップＳ７３）。

差出人から処理アクションを受け付けた場合には（ステップＳ７３のＹＥＳ）、処理アクションが削除の場合には、保留された電子メールを削除し、処理アクションが配送の場合には、保留された電子メールを配送する処理を行い（ステップＳ７４）、処理を終了する。一方、差出人から処理アクションを受け付けない場合には（ステップＳ７３のＮＯ）、ステップＳ７１に戻る。

（６）保留メール処理（処理３）
次に、保留メール処理（処理３）について図５（Ｆ）を用いて説明する。

まず、非通知保留時間が経過したか否かを判断する（ステップＳ８０）。非通知保留時間が経過したと判断される場合には（ステップＳ８０のＹＥＳ）、保留された電子メールを配送する処理を行い（ステップＳ８１）、処理を終了する。一方、非通知保留時間が経過していないと判断される場合には（ステップＳ８０のＮＯ）、差出人から処理アクション（配送又は削除の指示）を受け付けたか否かを判断する（ステップＳ８２）。

差出人から処理アクションを受け付けた場合には（ステップＳ８２のＹＥＳ）、処理アクションが削除の場合には、保留された電子メールを削除し、処理アクションが配送の場合には、保留された電子メールを配送する処理を行い（ステップＳ８３）、処理を終了する。一方、差出人から処理アクションを受け付けない場合には（ステップＳ８２のＮＯ）、ステップＳ８０に戻る。

（７）ドメインチェック処理
次に、図５（Ｂ）でのステップ２０において処理が行われるドメインチェック処理の詳細について、図６を用いて説明する。

まず、エンベロープの宛先メールアドレスのドメインを抽出する（ステップＳ２０１）。ＤＮＳサーバに、ドメインに対するＭＸレコードがあるか否かを判断し（ステップＳ２０２）、ＭＸレコードがないと判断される場合には（ステップＳ２０２のＮＯ）、ＤＮＳサーバにドメインに対するＡレコードがあるか否かを判断する（ステップＳ２０３）。

ドメインのＡレコードがないと判断される場合には、ドメインチェックのルールスコアを電子メールのスコアに加点する処理を行う（ステップＳ２０４）。

そして、全てのエンベロープの宛先メールアドレスの処理を行ったか否かを判断し（ステップＳ２０５）、全てのエンベロープの宛先メールアドレスの処理を行っていない場合には（ステップＳ２０５のＮＯ）、他のエンベロープの宛先メールアドレスの処理を行うためにステップＳ２０１に戻る。一方、全てのエンベロープの宛先メールアドレスの処理を行っている場合には（ステップＳ２０５のＹＥＳ）、処理を終了する。

１０．応用例
（１）ドメインチェックの応用例
本実施形態のサーバは、電子メールのスコアに関係なく、複数のエンベロープの宛先の、ドメインの有効性をチェックし、無効なドメインが存在する場合には、電子メールの配送を一律に保留するようにしてもよい。

例えば、図３の例で仮に「ｙｙｙ．ｃｏｍ」のドメインは有効であると判断され、「ｚｚｚ．ｏｒ．ｊｐ」のドメインは無効と判断されると、「ｂｂｂ＠ｙｙｙ．ｃｏｍ」の受信者は、「ｃｃｃ＠ｚｚｚ．ｏｒ．ｊｐ」に電子メールが配送されなかったことを検知することができない。つまり、「ｂｂｂ＠ｙｙｙ．ｃｏｍ」の受信者は、受信した電子メールのヘッダ上ではＣｃに「ｃｃｃ＠ｚｚｚ．ｏｒ．ｊｐ」が記載されているが、実際には「ｃｃｃ＠ｚｚｚ．ｏｒ．ｊｐ」に電子メールが配送されないことを検知できない。

このような状況を差出人に注意喚起するために、本実施形態では無効なドメインが存在した場合には、電子メールのスコアや、しきい値（自動配送しきい値、自動削除しきい値）に関わらず電子メールの配送を保留する。かかる場合には、保留されたことを差出元に通知し、どのエンベロープの宛先のドメインが無効であるかを、併せて通知する。

（２）会社名チェック、名前・敬称チェックの応用例
本実施形態の会社名チェックでは、電子メールのヘッダの宛先ではなく、エンベロープの宛先に対応する会社名（略称等）を、顧客ＤＢから取得し、取得した会社名が、電子メールのメッセージの本文の冒頭部分に含まれているか否かを判断してもよい。また、本実施形態の名前・敬称チェックでは、電子メールのヘッダの宛先ではなく、エンベロープの宛先に対応する名前（姓・名）を、顧客ＤＢから取得し、その名前が、電子メールのメッセージの本文の冒頭部分に含まれているか否かを判断してもよい。また、かかる場合において、エンベロープの宛先とヘッダのＢｃｃの宛先とが同一である場合には、当該宛先を、会社名チェック、名前・敬称チェックの判断対象外としてもよい。

（３）メール教育用サーバとして利用する例
本実施形態のサーバを、スコアリングによって電子メールの評価を行うことができる教育用のサーバとして利用してもよい。

例えば、サーバが受け付けた電子メールについて、ルールに基づいてスコアリングを行い、スコアを差出元に通知する処理を行う。例えば、図７は、差出元に評価結果を通知するメールの一例である。例えば、サーバは、評価した電子メールのスコア、スコアの内訳を含む通知メールを作成し、通知メールを送信元に通知する。なお、サーバは、受け付けた電子メールの本文に対して、ルールに該当する箇所を特定の色（例えば赤色）で示したＨＴＭＬ形式の通知メールを作成してもよい。差出人は、瞬時に間違いを判断することができるからである。なお、本実施形態のサーバは、受け付けた電子メールの本文に対して、ルールに該当する箇所を特定の色で示したデータを、特定のファイル形式（ＰＤＦ等）に変換してファイルを生成し、当該ファイルを通知メールに添付してもよい。

このようにすれば、電子メールのビジネスマナー等の教育を実践的にコストを抑えて行うことができる。

（４）ルール
本実施形態では、上述した複数のルールの他に、以下のルール（加点条件）を更に加えて、スコアリングを行ってもよい。

（Ａ）電子メールサイズチェック
本実施形態では、電子メールのサイズが予め設定された所定値（例えば、１メガバイト）より大きいというルールを追加してもよい。つまり、電子メールのサイズが、所定値より大きい場合には、電子メールサイズチェックのルールスコアを、電子メールのスコアに加点する処理を行う。なお、電子メールサイズチェックの所定値は、管理者用ＵＩにおいて、管理者からの入力に基づいて設定できるようにしてもよい。

（Ｂ）件名サイズチェック
本実施形態では、電子メールのヘッダの件名（Ｓｕｂｊｅｃｔ）が、予め設定された所定値（例えば、１２８バイト）より大きいというルールを追加してもよい。つまり、電子メールのヘッダの件名のサイズが、所定値より大きい場合には、件名サイズチェックのルールスコアを、電子メールのスコアに加点する処理を行う。なお、件名サイズチェックの所定値は、管理者用ＵＩにおいて、管理者からの入力に基づいて設定できるようにしてもよい。

（Ｃ）添付ファイルの添付し忘れチェック
本実施形態では、電子メールの本文に「添付」という文字列を含み、かつ、当該電子メールにファイルが添付されていない、というルールを追加してもよい。つまり、電子メールの本文に「添付」という文字列が検索され、かつ、当該電子メールにファイルが添付されていない場合には、添付ファイルの添付し忘れチェックのルールスコアを、電子メールのスコアに加点する処理を行う。

なお、本実施形態では、電子メールのボディがマルチパート形式であって、複数のパートのうち、パートヘッダに記載されているパートの属性（Ｃｏｎｔｅｎｔ−Ｔｙｐｅ）が、ｔｅｘｔメディアタイプ（ｔｅｘｔ／ｐｌａｉｎ、ｔｅｘｔ／ｈｔｍｌ等）以外のメディアタイプであるパートが存在する場合に、電子メールにファイルが添付されていると判断する。

例えば、パートの属性が、ｉｍａｇｅメディアタイプ、ａｕｄｉｏメディアタイプ、ｖｉｄｅｏメディアタイプ、ａｐｐｌｉｃａｔｉｏｎメディアタイプ（例えば、ａｐｐｌｉｃａｔｉｏｎ／ｏｃｔｅｔ−ｓｔｒｅａｍ）等である場合に、電子メールにファイルが添付されていると判断する。

なお、パートの属性が、ｔｅｘｔメディアタイプ以外のメディアタイプのパートのボディ部分のデータは、電子メールの添付ファイルのデータとなる。

また、本実施形態では、電子メールの本文において、引用符（例えば「＞」）から始まる行については、「添付」という文字列の検索対象から除外してもよい。つまり、電子メールの本文に含まれる、他のメール等を引用した引用文を、添付ファイルの添付し忘れチェックの対象外としてもよい。

（Ｄ）添付ファイルのサイズチェック
本実施形態では、電子メールの添付ファイルのサイズが所定値（例えば、１００キロバイト）以上である、というルールを追加してもよい。つまり、電子メールの添付ファイルのサイズが、所定値より大きい場合には、添付ファイルのサイズチェックのルールスコアを、電子メールのスコアに加点する処理を行う。なお、添付ファイルのサイズチェックの所定値は、管理者用ＵＩにおいて管理者からの入力に基づいて設定できるようにしてもよい。

（Ｅ）添付ファイルの圧縮チェック
本実施形態では、電子メールの添付ファイルが圧縮されていない、というルールを追加してもよい。つまり、電子メールにファイルが添付されていると判断され、その添付ファイルが圧縮されていないと判断される場合には、添付ファイルの圧縮チェックのルールスコアを、電子メールのスコアに加点する処理を行う。なお、本実施形態では、添付ファイルのパートの属性が圧縮処理用のメディアタイプである場合に、電子メールの添付ファイルが圧縮されていると判断する。圧縮処理用のメディアタイプとは、例えば、ａｐｐｌｉｃａｔｉｏｎ／ｚｉｐや、ａｐｐｌｉｃａｔｉｏｎ／ｘ−ｚｉｐ−ｃｏｍｐｒｅｓｓｅｄ等である。

また、本実施形態では、電子メールの添付ファイルが圧縮されていない場合であって、その添付ファイルの圧縮率が所定率（例えば、７０％）以上であることを、添付ファイルの圧縮チェックのルールとしてもよい。なお、圧縮率（％）は、下式（１）によって求めることができる。

圧縮率＝（１−（圧縮後のデータ量／圧縮前のデータ量））＊１００・・・（１）
また、電子メールの添付ファイルが圧縮されていない場合であって、圧縮前の添付ファイルのサイズと、圧縮後の添付ファイルのサイズとの差が所定値（例えば、１メガバイト）以上であることを、添付ファイルの圧縮チェックのルールとしてもよい。

つまり、電子メールの添付ファイルが圧縮されていない場合であって、その添付ファイルの圧縮率が所定率（例えば、７０％）以上である場合、圧縮前の添付ファイルのサイズと、圧縮後の添付ファイルのサイズとの差が所定値以上である場合の少なくとも一方に該当することを、添付ファイルの圧縮チェックのルールとしてもよい。

また、本実施形態では、所定率、添付ファイルの圧縮前後の差の値は、管理者用ＵＩにおいて管理者からの入力に基づいて設定できるようにしてもよい。

（Ｆ）書きかけ電子メールチェック
本実施形態では、文末定型句（「以上」、「よろしくお願い致します。」等）の文字列を予め登録し、電子メールの本文に、文末定型句が存在しない、というルールを追加してもよい。つまり、電子メールの本文に、文末定型句の文字列が検索されない場合には、書きかけであるとみなし、書きかけ電子メールチェックのルールスコアを、電子メールのスコアに加点する処理を行う。

（Ｇ）敬語チェック
本実施形態では、電子メールの本文に、予め設定された敬語を構成する文字列（「ご覧になる」、「なさる」等）が含まれない、というルールを追加してもよい。つまり、電子メールの本文に、敬語を構成する文字列が検索されない場合には、敬語チェックのルールスコアを、電子メールのスコアに加点する処理を行う。なお、敬語を構成する文字列は、管理者用ＵＩにおいて管理者からの入力に基づいて設定できるようにしてもよい。

（Ｈ）誤字脱字チェック
本実施形態では、電子メールの本文に、予め設定された誤字脱字の文字列が含む、というルールを追加してもよい。つまり、電子メールの本文に、誤字脱字の文字列が検索された場合には、誤字脱字チェックのルールスコアを、電子メールのスコアに加点する処理を行う。なお、誤字脱字の文字列は、管理者用ＵＩにおいて管理者からの入力に基づいて設定できるようにしてもよい。

（５）添付ファイルの自動圧縮処理
本実施形態では、添付ファイルが圧縮されていない場合には、自動的に添付ファイルを圧縮する処理を行う圧縮処理部を含んでもよい。そして、本実施形態では、圧縮処理部によって添付ファイルを圧縮した電子メールを配送する処理を行う。このようにすれば、電子メールのデータ量を抑えることができ、通信負荷を軽減することができる。また、差出人が、添付ファイルを圧縮する手間を省くことができる。

本実施形態では、添付ファイルの圧縮率が所定率（例えば、７０％）以上である場合に、添付ファイルを圧縮して配送するようにしてもよい。

また、圧縮前の添付ファイルのサイズと圧縮後の添付ファイルのサイズとの差が所定値（例えば、１メガバイト）以上である場合に、添付ファイルを圧縮して配送するようにしてもよい。このようにすれば、受信者側の解凍処理（展開処理）の煩雑さのデメリットと、データ量を削減することができるメリットとのバランスを考慮して、圧縮処理を行って配送するか否かの判断を、適切に行うことができる。

本実施形態では、圧縮率が所定率以上である場合、圧縮前後の差が所定値以上である場合の少なくとも一方に該当する場合に、添付ファイルを圧縮して配送するようにしてもよい。

なお、所定率、添付ファイルの圧縮前後の差の値は、管理者用ＵＩにおいて管理者からの入力に基づいて設定できるようにしてもよい。また、例えば、所定率、添付ファイルの圧縮前後の差の値を、上述した添付ファイルの圧縮チェックルールと同じ値に設定し、添付ファイルの圧縮チェックルールに該当する場合には、自動的に添付ファイルを圧縮して配送するようにしてもよい。

また、自動的に添付ファイルを圧縮した場合には、自動的に添付ファイルを圧縮したことを知らせる内容を含む通知メールを作成し、差出元に通知してもよい。なお、本実施形態において、圧縮対象の電子メールが保留された場合には、保留通知メールに、添付ファイルが圧縮されたこと知らせるメッセージを含ませるようにし、差出元に保留通知メールを通知してもよい。

（６）添付ファイルの自動暗号化処理
本実施形態では、所定の宛先について予め自動暗号化処理を行うように設定し、電子メールのエンベロープの宛先が、予め設定された所定の宛先である場合には、自動的に添付ファイルを暗号化する処理を行う暗号化処理部を含んでもよい。そして、本実施形態では、暗号化処理部によって、添付ファイルを暗号化した電子メールを配送する処理を行う。このようにすれば、差出人が添付ファイルを暗号化する手間を省くことができ、また、盗聴、改ざんのリスクを避けることができる。

なお、本実施形態では、件名や本文に「極秘」、「重要」、「秘」等の特定文字列（特定文字）が含まれる場合に、添付ファイルを自動的に暗号化するようにしてもよい。

また、自動的に添付ファイルを暗号化した場合には、自動的に添付ファイルを暗号化したことを知らせる通知メールを作成し、差出元に通知してもよい。なお、本実施形態において、暗号化対象の電子メールが保留された場合には、保留通知メールに、添付ファイルが暗号化されたこと知らせるメッセージを含ませるようにし、差出元に保留通知メールを通知してもよい。

（７）評価手法の応用例
本実施形態では、電子メールのスコアが、大きいスコアであるほど評価が悪いものとみなして保留処理を行っているが、電子メールのスコアが、低いスコアであるほど評価が悪いものとみなして保留処理を行うようにしてもよい。かかる場合には、各ルールのルールスコアを負の値に設定する。また、自動削除しきい値が自動配送しきい値よりも小さい値（自動削除しきい値＜自動配送しきい値）になるように設定し、電子メールのスコアが、自動配送しきい値以下である場合に、電子メールの配送を保留する。また、スコアが自動削除しきい値以下である場合には、自動削除保留期間経過後、自動的に削除する処理を行い、スコアが自動削除しきい値より大きい値で、自動配送しきい値以下である場合には、自動的に配送する処理を行う。

１０ サーバ、２０ 端末、
１００ 処理部、１１０ メールサーバ、１１２ 受け付け部、１１３ 解析部、
１１４ 評価部、１１４ａ ドメイン判断部、１１５ 保留判定部、１１６ 送信部、
１１６ａ 配送部、１１６ｂ 通知部、１１８ 保留部、１１９ 保留メール処理部、
１２０ Ｗｅｂサーバ、１２１ 管理者用ＵＩ部、１２２ ユーザ用ＵＩ部、
１３０ ルール設定部、１７０ 記憶部、１７１ 顧客ＤＢ、１７２ ユーザＤＢ、
１７３ 保留メール格納領域、１７４ アクション履歴ＤＢ、１７５ ルールＤＢ、
２１０ Ｗｅｂブラウザ、２１１ ＭＵＡ

Claims (3)

1. 宛先が指定された電子メールを配送するサーバのためのプログラムであって、
   差出元から送信され、複数の宛先が指定された電子メールを受け付ける受け付け部と、
   宛先毎に、宛先のドメインが有効か否かを判断するドメイン判断部と、
   無効なドメインであると判断された宛先が存在する場合には、前記複数の宛先の全てに対する前記電子メールの配送を保留する保留部として、コンピュータを機能させることを特徴とするプログラム。
2. 請求項１において、
   前記電子メールの配送が保留された場合には、保留されたことを通知する通知メールを前記電子メールの差出元に通知する通知部として、コンピュータを更に機能させることを特徴とするプログラム。
3. 請求項２において、
   前記通知部が、
   無効なドメインであると判断された宛先を前記差出元に通知することを特徴とするプログラム。

Images