JP3868258B2

JP3868258B2 - 電子メール配送サーバ

Info

Publication number: JP3868258B2
Application number: JP2001325886A
Authority: JP
Inventors: 雅人野中
Original assignee: Oki Electric Industry Co Ltd
Current assignee: Oki Electric Industry Co Ltd
Priority date: 2001-10-24
Filing date: 2001-10-24
Publication date: 2007-01-17
Anticipated expiration: 2021-10-24
Also published as: JP2003134167A

Description

【０００１】
【発明の属する技術分野】
本発明は電子メール配送サーバに関し、例えば、sendmail間で行われるＳＭＴＰに応じた手順にしたがってインターネット上で電子メールを配送する場合などに用いて好適なものである。
【０００２】
【従来の技術】
従来の電子メールに関する技術としては、次の文献１、文献２に記載されたものがある。
【０００３】
文献１：特開２００１-１７５５５２号公報
文献２：特開２００１-９４５８９号公報
電子メールを扱える携帯電話の普及やインターネット等のコンピュータネットワークの発展に伴い、情報伝達手段として電子メールを利用する機会が増えている。ビジネス分野においても電子メールの役割・流通量は年々大きくなっており、社外で電子メールをチェックするために、携帯電話機や自宅のＰＣ（パーソナルコンピュータ）に会社のメールアドレス宛の電子メールを転送する、といったことが行われるようになっている。
【０００４】
しかしながら、インターネット経由で電子メールを送受信する場合、内容を盗み読みされ秘密情報が漏洩する危険性がある。更に、配送先が携帯電話機等の携帯端末の場合、端末の処理能力が低い、データ通信速度が遅い、通信コストが高い、といった制約があった。このため、社外で手軽に電子メールをチェックしたいという要望と秘密情報の漏洩防止との両立が課題となっていた。
【０００５】
このような状況のもと、前記文献１では、電子メールの概要文と暗号文をセットにして送信するシステムを開示している。暗号化メールを利用する場合、暗号化及び復号の計算量が大きいという課題があるが、文献１では概要文をつけることで復号の必要な暗号化メール数の削減を実現している。具体的には、秘密情報を含む電子メールを送信する送信クライアントは、該電子メール全文を暗号化すると共に秘密情報が含まれないように配慮してメールの概要を示す概要文を生成し、平文の概要文に暗号文の全文を添付して送信する。
【０００６】
これを受け取った受信クライアントは、最初に概要文を読み、必要なメールだけ暗号を復号して全文を読むことができる。つまり、受信クライアントでは、重要度の低い電子メールは暗号文を復号しなくて済むようになる。このようにして、秘匿性を確保しつつ受信クライアントの処理削減を実現している。
【０００７】
また、前記文献２では、メールサーバにフィルタリング機能と仲介機能を持たせるシステムを開示している。電子メールが大量に配送されると受信クライアントの負荷が重くなるという問題があるが、文献２では重要度の低い電子メールをメールサーバで廃棄することで受信クライアントの負荷を低減している。
【０００８】
具体的には、メールサーバに電子メールの廃棄条件を設定しておき、これに当てはまる重要度の低い電子メールをメールサーバで廃棄すると共に廃棄した事を送信クライアントに伝える、廃棄条件に当てはまらない電子メールはこれを受信するかどうか受信クライアントに打診してか配送する、といった処理をしている。また、このシステムの有効な適用分野として移動電話機が挙げられている。
【０００９】
【発明が解決しようとする課題】
ところが文献１のように暗号化メールを利用する場合には暗号化及び復号のためにクライアント間でツールを揃える必要があり、鍵の管理のために認証局（ＣＡ）からＩＤを取得する必要があるなど手軽ではなかった。このため、セキュリティが確保されている社内ネットワーク下では秘密情報を含む電子メールであっても暗号化されていないケースが多く、会社のメールアドレス宛のメールを社外に転送することは、情報漏洩において非常に危険な状態にあった。
【００１０】
これには社外へ転送する際に電子メールを暗号化することによって対処することも考えられるが、電子メールの配送先が携帯電話機などである場合には問題である。携帯電話機に暗号化メールを配送しても、携帯電話機自体が処理負荷のために暗号化メールをサポートしておらず復号できないからである。
【００１１】
文献１に記載されている概要文と暗号文をセットにして配送するという方法は、復号しない可能性のある暗号文を予め配送してしまうため、通信時間や通信コストにおいても無駄があった。さらに、受信クライアントが暗号文と概要文からなるメールをスプールする必要があるため、通常に比べて大きな容量のメモリが必要という課題があった。
【００１２】
特に受信クライアントが携帯電話機の場合、暗号化メールが復号できないことに加え、概要文の分だけ文字数が増加するため電子メールの受信文字数制限によって正常な受信が行えなくなる可能性も少なくない。一例として、現在のところ我が国で最大の携帯電話ユーザを収容している携帯電話ネットワークの場合、受信文字数の上限は２５０文字である。
【００１３】
文献２に記載のシステムはダイレクトメール等の優先度の低い電子メールを配送しないようにすることが目的になっており、受信クライアントの負荷は軽減されるものの秘匿性については考慮されていなかった。このため、文献２のシステムで秘匿性を確保しようとすると、インターネットヘ電子メール配送されないようになってしまい、社外で電子メールをチェックしたいという要望に応えられるものではなかった。
【００１４】
以上のように、電子メールシステムにおいて、インターネット経由で手軽に電子メールを読みたいという要望の実現と、秘密情報を含む電子メールの配送による情報漏洩の対策との両立は、文献１,２の方法によっても実現されていなかった。
【００１５】
【課題を解決するための手段】
かかる課題を解決するために、本発明では、配送すべき電子メールを受け取り、所定の配送プロトコルにしたがって電子メールの配送を行う電子メール配送サーバにおいて、（１）前記電子メールのヘッダ部分または本文部分の内容に基づいて当該電子メールに求められる秘匿性の高低を判定すると共に、秘匿性が高い場合には、秘匿性の高さのレベルを判定する秘匿性判定手段と、（２）当該秘匿性判定手段が、秘匿性が高いと判定した電子メールに関し、秘匿性の高さのレベルが高いほど情報量が少ない概略文を生成する概略文生成手段と、（３）前記秘匿性判定手段が、秘匿性が低いと判定した電子メールはそのまま前記配送プロトコルにしたがって配送し、秘匿性が高いと判定した電子メールに関してはその配送を待機させた上で、当該電子メールを電子メール配送サーバが受け取っていることを電子メールの送信先に通知すると共に、前記概略文生成手段が生成した概略文を付加した通知用電子メールを前記配送プロトコルにしたがって配送する通知メール配送制御手段と、（４）配送を待機させた電子メールを、送信先からの指示に応じて実行される所定の配送待機メール処理手順にしたがって処理する配送待機メール処理手段とを備えたことを特徴とする。
【００１６】
【発明の実施の形態】
（Ａ）実施形態
以下、本発明にかかる電子メール配送サーバの実施形態について説明する。
【００１７】
メールサーバ（ＭＴＡ）は、電子メールの送信元および送信先のメーラ（ＭＵＡ）とともに電子メールシステムを構成する重要な要素である。メールサーバは機能上、メール配送サーバとメール受信サーバに分けることができる。
【００１８】
このうちメール配送サーバはＳＭＴＰなどのメール配送プロトコルにしたがって電子メールの配送を行うサーバであり、メール受信サーバは着信した電子メールを受信メールボックス内に保存し、ＰＯＰ３やＩＭＡＰ４などのメール取り出しプロトコルにしたがって当該電子メールの送信先のメーラからの指示に応じて受信メールボックス中の電子メールを処理するサーバである。
【００１９】
また、前記メーラは送信しようとする電子メールをメール配送サーバに送信したり、着信した電子メールをメール受信サーバ内の受信メールボックスから取り出したあと、開封して読んだりするためのソフトウエアであり、携帯電話機やパーソナルコンピュータなどのユーザ端末に搭載され得る。
【００２０】
電子メールの配送には様々な方法があるが、インターネット上で通常用いられるのは、送信先のドメインに配置されたＤＮＳサーバに問い合わせることで送信先のＩＰアドレスを取得して、送信元のドメインにあるメール配送サーバから直接的に、送信先のドメインにあるメール受信サーバに配送する方法である。ＳＭＴＰはＯＳＩ参照モデルのセッション層およびプレゼンテーション層に位置づけられるから、この配送に際しては、ＴＣＰ／ＩＰプロトコルなど、トランスポート層以下の各プロトコルが利用されるのは当然である。
【００２１】
この方法では、電子メールがメール受信サーバに受信され、該当する受信メールボックスに格納された時点で電子メールの配送が完了するが、送信先が携帯電話機等である場合には必ずしもそうではなく、送信先の携帯電話機がアベイラブルであることを確認するとメール受信サーバ主導で電子メールを送り付けることによって配送が完了することもある。
【００２２】
これは携帯電話ネットワーク上の電子メールシステムがインターネット上の一般的な電子メールシステムと必ずしも同じでないためである。携帯電話ネットワーク上にどのような電子メールシステムを構築するかは基本的に携帯電話ネットワークを管理、運営する携帯電話事業者の自由であると考えられるが、あまり特異な電子メールシステムを構築してしまうとインターネット上の電子メールシステムとの接続が正常に行えなくなる可能性が高まるため、携帯電話ネットワーク上であっても、基本的にはインターネット上と同じか、インターネット上と類似した電子メールシステムが構築される。
【００２３】
（Ａ−１）第１の実施形態の構成
本実施形態にかかる電子メールシステム１０の主要部の構成例を図１に示す。
【００２４】
図１において、当該電子メールシステム１０は、イントラネット１０１と、インターネット１０２とを備えており、イントラネット１０１上には本実施形態の特徴であるメールサーバ１０６が配置されている。また、イントラネット１０１にはクライアント端末１０３と１０４が接続され、インターネット１０２にはクライアント端末１０５と１２０が接続されている。
【００２５】
なお、インターネット１０２上などには、上述したＳＭＴＰに応じた電子メールの配送を支援するための多数の図示しないルータが配置されていることは当然である。
【００２６】
クライアント端末１０３〜１０５のうちイントラネット１０１内のクライアント端末１０３と１０４は、メーラを搭載したパーソナルコンピュータなどであってよい。また、インターネット１０２に接続されたクライアント端末１０５もパーソナルコンピュータなどであってもよいが、ここでは主として、メーラを搭載した携帯電話機を想定する。クライアント端末１０５が携帯電話機の場合、クライアント端末１０５とインターネット１０２のあいだには、点線で示した携帯電話ネットワークＰＮ１が介在することになる。
【００２７】
また、クライアント端末１０３を操作するユーザＵ１と、クライアント端末１０４を操作するユーザＵ２と、クライアント端末１０５を操作するユーザＵ３とは、例えば、同じ会社の社員であってよい。この場合、ユーザＵ１とＵ２の位置は社内にかぎられるが、ユーザＵ３の位置は社内でも社外でもかまわない。
【００２８】
メールサーバ１０６，クライアント端末１０３，１０４を含め、イントラネット１０１上に存在するすべての通信装置は、基本的に図示しないファイアウオールによって守られている。すなわち、インターネット１０２上の不特定の通信装置から不特定のプロトコルを用いてイントラネット１０１内の通信装置に直接アクセスすることはできないように、ファイアーウオールが設定されている。このため、例えば、クライアント端末１０３と１０４間で電子メールをやり取りする場合には、平文のままで電子メールを送受したとしてもインターネット１０２上の第３者に当該電子メールの内容を知られる可能性はない。
【００２９】
なお、セキュリティ性の向上のため、イントラネット１０１上に公開セグメント（非武装セグメント（ＤＭＺ））を設けて、イントラネット１０１を公開セグメントと非公開セグメントに分けることがある。
【００３０】
公開セグメントは、前記ファイアーウオールが提供するアクセス制御によってインターネット１０２上の不特定多数の通信装置から不特定のプロトコルによってアクセスされることがないという意味では完全に無防備ではないが、予めファイアーウオールに設定された限られたプロトコルによって限られた通信装置から（、または限られたプロトコルによって不特定多数の通信装置から）アクセスされるので、非公開セグメント内の通信装置に比べると、インターネット１０２上からの攻撃や盗聴に対して脆弱である。
【００３１】
本実施形態のメールサーバ１０６は後述するように、前記クライアント端末１０５からの返信メールＲＭ１を受け取る必要があるため、何らかの方法で、少なくともＳＭＴＰを用いたインターネット１０２上からのアクセスは可能としておく必要がある。
【００３２】
一例として、前記公開セグメント上に社外用のメールサーバを配置し、非公開セグメント上に社内用のメールサーバ（例えば、クライアント端末１０３と１０４の間のように、社内における電子メールのやり取りは、この社内用メールサーバが分担する）を配置する場合には、前記メールサーバ１０６を社外用のメールサーバとして、公開セグメント上に配置することで、前記返信メールＲＭ１の受け取りが可能となる。
【００３３】
なお、当該返信メールＲＭ１の配送にも上述したＤＮＳサーバにＩＰアドレスを問い合わせる方法を用いる場合には、当該公開セグメント上に社外用のＤＮＳサーバ（すなわち、社外から参照されてもかまわないドメインネームだけを登録してあるＤＮＳサーバ）も配置する必要がある。現在のところ、携帯電話機のメーラや電子メールシステムでReply-to機能に対応しているものはほとんど存在しないため通知メールＮＭ１のReply-toフィールドに送信元の電子メールアドレスＭＡ２（インターネット１０２上から前記非公開セグメント内の通信装置に送信される電子メールはすべて、いったんメールサーバ１０６に受信される）またはメールサーバ１０６の電子メールアドレスを書き込むことはできず、ユーザＵ３が返信メールＲＭ１を作成するときにも、電子メールシステムが返信メールＲＭ１をメールサーバ１０６へ配送するときにも、ユーザＵ３および電子メールシステムは、通常の新たな電子メールの作成および配送と同様な手順を実行する必要があるからである。
【００３４】
以下の説明では、クライアント端末１０４からクライアント端末１０５へ電子メールＥＭ１を送信する場合を想定する。また、クライアント端末１０４の電子メールアドレスはＭＡ２であり、クライアント端末１０５の電子メールアドレスはＭＡ３であるものとする。
【００３５】
図１のメールサーバ１０６は主として上述したメール配送サーバとして機能するもので、配送する元の電子メール（ここでは、ＥＭ１）の秘匿必要性を判断する機能を有し、秘匿すべきメールと判断された場合は、当該電子メールを配送する前に秘匿すべき電子メールの着信をクライアント端末（ここでは、１０５）に通知するものである。このような機能を実現するため、当該メールサーバ１０６は、メールサーバ部１０７と、通知メール生成部１０８と、秘匿必要性判断部１０９と、配送メール選択部１１０と、制御部１１１とを備えている。
【００３６】
このうちメールサーバ部１０７は基本的にＵＮＩＸ（登録商標）システムにおけるsendmail等のサーバアプリケーションプログラムで実現される部分である。メール転送エージェント（ＭＴＡ）であるsendmailとしては、ＵＮＩＸ（登録商標）系にかぎらず、すでに様々なプログラムが存在するが、その多くは、多様なコンピュータの間で電子メールをやり取りできるように、電子メールの配送に必要な最小限度の機能しか備えておらず、認証機能などは持たないのが普通である。
【００３７】
通常のメール配送サーバはこのメールサーバ部１０７に相当する機能だけを搭載しているので、本実施形態の特徴は、当該メールサーバ部１０７以外の構成要素１０８〜１１１にあるといえる。
【００３８】
ただし通常のsendmailは、ある電子メールを受け取ったら、上述したＤＮＳサーバにＩＰアドレスを問い合わせること等の手順を経て電子メールの配送を実行するだけであるが、本実施形態のメールサーバ部１０７は、受け取った電子メールを直ちに配送するのではなく、まず秘匿必要性判断部１０９、通知メール生成部１０８、および配送メール選択部１１０に供給し、配送メール選択部１１０が選択した電子メールをＳＭＴＰにしたがって次のメールサーバに配送する必要がある。
【００３９】
また、配送する電子メールが本来の電子メールＥＭ１ではなく通知メールＮＭ１である場合には、当該通知メールＮＭ１の配送後にも本来の電子メールＥＭ１はメールボックスＢＸ１などに保存しておく必要がある。
【００４０】
一例としては、メールサーバ１０６が電子メール（例えば、ＥＭ１）を受け取ったときには、その電子メールをメールサーバ部１０７内のsendmailに渡さず、秘匿必要性判断部１０９、通知メール生成部１０８、および配送メール選択部１１０に渡し、配送メール選択部１１０から出力される電子メール（ＥＭ１またはＮＭ１）をsendmailに渡す（この時点ではじめてsendmailが電子メールの受信を認識する）ように構成すれば、既存のsendmailの機能をほとんど改変することなくそのまま実装することができるから、簡便である。
【００４１】
メールサーバ部１０７に接続されている前記通知メール生成部１０８は、本来の電子メールＥＭ１の内容をもとに当該電子メールＥＭ１がメールサーバ１０６に着信したことを送信先ユーザＵ３に通知する通知メールＮＭ１を自動的に生成する部分で、生成した通知メールＮＭ１は配送メール選択部１１０に供給する。通知メールＮＭ１は、前記着信を通知する目的で使用される点で送信先のユーザＵ３にとっては特別な意味を持つが、電子メールシステムからみるとまったく通常の電子メールであり、電子メールＥＭ１などと同様、ＳＭＴＰにしたがって配送される。
【００４２】
通知メールＮＭ１が配送されるのは本来の電子メールＥＭ１の秘匿性が高いケースであるから通知メールＮＭ１自体がみだりに電子メールＥＭ１の内容を明かすものであってはならないが、その反面、通知メールＮＭ１は本来の電子メールＥＭ１が送信先ユーザＵ３にとって読む価値のあるものであるか否かの判断の基礎となる情報を提供する必要があるため、電子メールＥＭ１に関する必要最小限の情報を含んでいる必要がある。秘匿性を確保するためには通知メールＮＭ１が持つ情報の量は少なければ少ないほどよいが、価値判断の基礎を提供するためには情報量は多ければ多いほどよいから、通知メールＮＭ１の生成は、相互に矛盾することの多い要件を満足しなければならない困難で微妙な問題であるということができる。
【００４３】
一例としては、通知メールＮＭ１は、元の電子メールＥＭ１のヘッダ部から差出人（送信元）、作成時刻（送信時刻）等の情報を取り出して生成するようにしてもよい。例えば、「Ｕ２さんから○○時○○分に社外秘のメールが届いています。」といった内容になる。但し、通知メールＮＭ１の生成は特にこの方法に限定されるものではなく、メール本文の情報を用いても構わない。例えば、本文中から至急という言葉を検索し、「Ｕ２さんから○○時○○分に社外秘のメールが届いています。このメールは至急という言葉が含まれています。」といったものでも構わない。
【００４４】
ただし通知メール生成部１０８に、処理結果である通知メールＮＭ１の内容をユーザＵ２が予測することが難しい複雑な処理を行わせると、ユーザＵ２が秘匿したい肝心な情報を含んだ通知メールＮＭ１を生成してしまう可能性も高まるので、一般的には、通知メール生成部１０８が行う処理は、その結果をユーザＵ２が明確に予測することが可能な、できるだけ単純なものにしたほうがよいとも考えられる。
【００４５】
例えば、単に本来の電子メールＥＭ１の題名をそのまま通知メールＮＭ１の題名として本文に有効な内容を持たない通知メールＮＭ１を生成するようにしてもよい。
【００４６】
電子メールＥＭ１の題名は送信元のユーザＵ２が自身で作成するものであるから、上述した困難で微妙な問題を解決できる適切な題名を作成し、その題名をそのまま通知メール生成部１０８が通知メールの題名（必要ならば本文としてもよい）とするような処理を行うようにしておき、その旨を予めユーザＵ２に知らせておけば、生成される通知メールＮＭ１の内容が明確に予測できるから、ユーザＵ２の安心感も高まる。
【００４７】
また、電子メールＥＭ１の題名を通知メールＮＭ１の本文の内容とせずに題名とすることによって、クライアント端末１０５が通知メールＮＭ１を受信した際、開封しなくても価値判断ができるために簡便である。携帯電話ネットワークＰＮ１上の電子メールシステムによっては、開封不要な場合は電子メールＥＭ１自体のダウンロードも不要となる可能性も高く、携帯電話機の限られたメモリ容量を節約することも可能である。
【００４８】
なお、電子メール（ＥＭ１，ＮＭ１など）のヘッダ部内の各フィールドには通常、メッセージＩＤ（各電子メールを区別するためのユニークな番号。メールサーバ１０６によって自動的に付与される）、送信の日時、送信元（差出人）の情報（送信元の電子メールアドレス（ここでは、ＭＡ２）や氏名など）、送信先の情報（送信先の電子メールアドレス（ここではＭＡ３））、メールの題名、メール本文の種類（テキスト、画像、音声などの区別）などを示す各情報が収容されている。
【００４９】
配送メール選択部１１０は、本来の電子メールＥＭ１または通知メール生成部１０８が生成した通知メールＮＭ１のなかから、配送するものを選択する部分である。この選択は、秘匿必要性判断部１０９から制御入力端子に供給される選択制御信号ＳＣに応じて実行される。
【００５０】
通知メール生成部１０８と同様に、前記メールサーバ部１０７から電子メールＥＭ１を受け取る秘匿必要性判断部１０９は、メールサーバ１０６が配送すべき電子メール（ここでは、ＥＭ１）について秘匿必要性の高低を判断する部分であり、その判断結果に応じた前記選択制御信号ＳＣを前記配送メール選択部１１０の制御入力端子に供給する。
【００５１】
すなわち当該秘匿必要性判断部１０９は、秘匿必要性が高いと判断した場合には通知メールＮＭ１を選択させる選択制御信号ＳＣを出力し、秘匿必要性が低いと判断した場合には本来の電子メールＥＭ１を選択させる選択制御信号ＳＣを出力する。
【００５２】
このとき選択された電子メール（ＥＭ１またはＮＭ１）は平文のまま、送信先であるクライアント端末１０５へ配送される。
【００５３】
秘匿必要性判断部１０９では、受信した電子メールＥＭ１のヘッダ部に記述されている情報や、本文に記載されている内容から秘匿する必要性を判断することになるが、具体的な判断方法には様々なものが考えられる。
【００５４】
例えば、ヘッダ部の該当フィールドから読み出した前記送信元の情報や、メールの題名、更には拡張したフィールドの情報等を利用して判断するようにしてもよい。
【００５５】
このとき一例としては、特定の送信元からの電子メールは秘匿にする、題名に「社外秘」等の文字が含まれる場合は秘匿する、といった判断が考えられる。また、本文中から「限定情報」「社外秘」といった秘密を示すような記述、「価格」「２００億円」といった金額を示すような記述を検索して、秘匿必要性を判断することも可能である。
【００５６】
ただしここでも、前記通知メール生成部１０８と同様、秘匿必要性判断部１０９の判断結果がユーザＵ２に予測できるようにしたほうが安心感を与えることができる。これは、秘匿してくれることを期待して電子メールＥＭ１を送信したのに実際には秘匿してもらえず、平文のままの電子メールＥＭ１がインターネット１０２上を配送され盗聴されたということが起こらないようにするためである。その意味で、例えば、題名に「社外秘」等の文字を記述することによって、ユーザＵ２が明示的に、秘匿性が高いことを表示できるようにすることは望ましい。この場合、予め題名に「社外秘」等の文字を記述しておけば秘匿性が高いものとして処理することをユーザＵ２に知らせておくことが前提となることは当然である。
【００５７】
なお、電子メールＥＭ１の秘匿性が低いと秘匿必要性判断部１０９が判断する場合には通知メールＮＭ１は必要ないのであるから、秘匿必要性判断部１０９が秘匿性が高いと判断したときにはじめて、通知メール生成部１０８が通知メールＮＭ１を生成するように構成すると、効率的である。
【００５８】
最後に制御部１１１は、秘匿性が高いと判断された場合の電子メールＥＭ１につき、その処理を、通知メールＮＭ１を読んだ送信先のユーザＵ３からの指示に応じて決定し、決定に応じた処理を実行する部分である。
【００５９】
秘匿性が高いと判断された電子メール（例えば、ＥＭ１）に関する処理の内容の少なくとも一部は、予め送信先ユーザごとに登録しておいてもよいし、処理の内容のすべてを、送信先ユーザ（例えば、Ｕ３）からの返信メール（例えば、ＲＭ１）に応じて動的に決定するようにしてもよい。
【００６０】
クライアント端末１０５が携帯電話機である場合には、例えば、最も普及しているＳ／ＭＩＭＥや、よく知られたＰＥＭ、ＰＧＰなどの電子メールの暗号化方式で暗号化された電子メールＥＭ１を復号して読むことはできないため、ユーザＵ３の自宅などに設置したクライアント端末１２０宛に転送してもらい、自宅で読むようにしてもよい。当該クライアント端末１２０は、携帯電話機などではなく、Ｓ／ＭＩＭＥ、ＰＥＭ、ＰＧＰなどに対応した復号機能を持つメーラを搭載した通信装置で、例えば、パーソナルコンピュータなどであってよい。
【００６１】
この場合、自宅のクライアント端末１２０の電子メールアドレスＭＡＸ等は予めメールサーバ１０６内の制御部１１１などに登録しておいてもよく、動的に、返信メールＲＭ１で指示するようにしてもよい。予め登録してある場合には、返信メールＲＭ１では、転送の要否だけを指定すればよくなる。
【００６２】
電子メールＥＭ１を自宅のクライアント端末１２０に転送させる場合は、元の電子メールＥＭ１のヘッダ部に収容されてきた送信先の情報である電子メールアドレスＭＡ１を、自宅のクライアント端末１２０の電子メールアドレスＭＡＸに書き換える処理を、制御部１１１が実行し、前記暗号化を施した上で、ＳＭＴＰに応じた配送を行う必要がある。図１中のＥＮ（ＥＭ１）は、電子メールＥＭ１を暗号化した電子メールを示している。
【００６３】
なお、クライアント端末１０５がReply-to機能を持たない携帯電話機である場合などには、メールサーバ１０６がどのようにして、元の電子メールＥＭ１とその返信メールＲＭ１の対応関係を認識するかが問題となる。返信メールＲＭ１も前記通知メールＮＭ１と同様に、ユーザＵ３にとっては特別なメールであるが、外形的には通常の電子メールと変わらず、メールサーバ１０６が電子メールＥＭ１と同時に処理する可能性のあるその他の多数の電子メールと区別がつかないからである。
【００６４】
一例としては、返信メール（ＲＭ１）の題名に「返信」等と記載させることで返信メールであることを表示させ、同時に処理する可能性のある返信メール間の識別は、返信メールのヘッダ部に含まれる送信元および送信先の電子メールアドレス（ＭＡ３，ＭＡ２）と、元の電子メール（ＥＭ１）のヘッダ部に含まれる送信先および送信元の電子メールアドレス（ＭＡ２，ＭＡ３）の対応関係に基づいて実行するようにしてもよい。ただしこの場合、メールサーバ１０６は、同じ送信元（例えば、ＭＡ２）から同じ送信先（例えば、ＭＡ３）への電子メール（例えば、ＥＭ１など）は、同時には１通しか取り扱うことができない。
【００６５】
同じ送信元から同じ送信先への電子メール（例えば、ＥＭ１など）を、同時に複数取り扱うには、例えば、通知メール（ＮＭ１）のメッセージＩＤを含む返信メール（ＲＭ１）を送信させるようにすればよい。メッセージＩＤは各電子メールにユニークなものなので、通知メールの送信時にそのメッセージＩＤ（当該メッセージＩＤと元の電子メールＥＭ１との対応関係も記憶しておく）をメールサーバ１０６（制御部１１１）内に記憶しておけば、返信メールが届いたときに、その返信メールに対応する元の電子メールを一義的に識別することが可能である。
【００６６】
なお、送信先のユーザＵ３が暗号化した電子メールＥＭ１を取り寄せる方法としては、これら以外に、Ｗｅｂブラウザを利用してメールを閲覧する方法、元メールＥＭ１の送信者Ｕ２（あるいは、メールサーバ１０６）に対し受信クライアント端末（１０５または１２０）の暗号復号環境に合わせた暗号化メールを再送するように要求する方法、更には元メールの送信者Ｕ２に対し電話等の別の手段で問い合わせる方法等がある。
【００６７】
以下、上記のような構成を有する本実施形態の動作について説明する。本実施形態のメールサーバ１０６の動作を図２のフローチャートに示す。図２のフローチャートは、Ｓ２１〜Ｓ２６の各ステップによって構成されている。
【００６８】
（Ａ−２）第１の実施形態の動作
ここでは説明の簡単のために、イントラネット１０１内に前記社内用のメールサーバと社外用のメールサーバを別個に設置せず、社外および社内兼用のメールサーバを設置するものとし、前記メールサーバ１０６を、この兼用メールサーバとする。
【００６９】
また、同一内容の電子メールＥＭ１をクライアント端末１０４から、クライアント端末１０３および１０５に送信するものとする。このようなケースでは、通常、電子メールＥＭ１のヘッダ部のＣＣフィールドまたはＢＣＣフィールドに、送信先であるクライアント端末１０３の電子メールアドレスＭＡ１と、クライアント端末１０５の電子メールアドレスＭＡ３を記述しておく。
【００７０】
図２において、送信元のクライアント端末１０４から秘密情報を含んだ電子メールＥＭ１をメールサーバ１０６が受信すると、メールサーバ１０６は、当該電子メールＥＭ１のＣＣフィールドまたはＢＣＣフィールドの記述を参照して（Ｓ２１）、イントラネット１０１内のクライアント端末１０３に向けて配送する１つのジョブと、イントラネット１０１外のクライアント端末１０５に向けて配送するもう１つのジョブが存在することを認識する。
【００７１】
イントラネット１０１内のクライアント端末１０３に対する配送は、安全なイントラネット１０１内に閉じた経路で行われるため、ステップＳ２２はＮＯ側に分岐して、平文のままの電子メールＥＭ１をクライアント端末１０３へ配送することにより（Ｓ２６）、当該ジョブが終了する。
【００７２】
一方、イントラネット１０１外のクライアント端末１０５への配送は、盗み読みの恐れがある危険な経路（ここではインターネット１０２）を経由するためステップＳ２２がＹＥＳ側に分岐して、メールサーバ１０６内の秘匿必要性判断部１０９が、当該電子メールＥＭ１に秘密情報が含まれているか、すなわち秘匿性が高いか否かを判断する（Ｓ２３）。
【００７３】
前記秘匿必要性判断部１０９が当該電子メールＥＭ１の秘匿性が低いとの判断結果を出した場合には、ステップＳ２３がＮＯ側に分岐し、前記配送メール選択部１１０を介して平文のままの電子メールＥＭ１がインターネット１０２経由で配送されることにより（Ｓ２６）、すべてのジョブが終了する。
【００７４】
しかし秘匿性が高いとの判断結果を出した場合には、ステップＳ２３はＹＥＳ側に分岐して前記通知メール生成部１０８が生成した通知メールＮＭ１の配送が行われる（Ｓ２４，Ｓ２５）。
【００７５】
クライアント端末１０５が携帯電話機の場合、メール受信サーバへの電子メールの着信は、着信音やバイブレーションなどによって直ちに携帯電話ユーザＵ３に知らせるため、電子メールはほぼリアルタイムな通信手段として機能し得、通知メールＮＭ１の着信後ただちにユーザＵ３が当該通知メールＮＭ１を読む可能性は高い。
【００７６】
この通知メールＮＭ１の配送につづいて、前記返信メールＲＭ１の受信や、当該返信メールＲＭ１の内容に応じた暗号化電子メールＥＮ（ＥＭ１）の転送が行われ得る点はすでに述べた通りである。当該暗号化電子メールＥＮ（ＥＭ１）の転送によって、電子メールＥＭ１の受信により発生したメールサーバ１０６の全てのジョブが完了することになる。
【００７７】
なお、イントラネット１０１内に前記社内用のメールサーバと社外用のメールサーバを別個に設置した場合、社内用メールサーバは非公開セグメント内（例えばクライアント端末１０３）へ宛てた電子メールの配送は自身で実行し、インターネット１０２経由で行われる社外（例えば、クライアント端末１０５）へ宛てた電子メールの配送は自身では行わず、当該電子メールを社外用メールサーバであるメールサーバ１０６に転送した上で、配送を含むその後の処理をメールサーバ１０６に任せるようにするとよい。
【００７８】
これにより、インターネット１０２経由の返信メールＲＭ１などを、非公開セグメント内の社内用メールサーバが直接受信する必要がなくなって、セキュリティ性を高めることができる。
【００７９】
ところで、一般的なＳＭＴＰは上述したように認証機能を持たないため、送信元をいつわること等は比較的容易であり、平文でインターネット１０２上を配送される通知メールＮＭ１を第３者が盗聴した上で、当該第３者の通信装置に元の電子メールＥＭ１を暗号化したものを送信させることも行われる可能性があるが、この問題には、メールサーバ１０６が予め登録してある送信先に対してのみ電子メールＥＭ１の転送を行い、それ以外の送信先への転送は行わないようにすることで対応可能である。
【００８０】
また、現在のところほとんどの携帯電話機では電子メールに添付された添付ファイル（ワープロ文書ファイル、画像ファイルなど）を読むことができないが、本実施形態を用いれば、転送先のパーソナルコンピュータ（１２０）などで添付ファイルを読むことも可能である。
【００８１】
すなわち、クライアント端末１２０への転送を、電子メールＥＭ１の添付ファイルを読むための手段として活用することもできる。この場合、添付ファイルの有無などを通知メールＮＭ１で知らせるようにするとよい。
【００８２】
（Ａ−３）第１の実施形態の効果
本実施形態によれば、送信先のユーザが必要と認めた場合にだけ、暗号化された電子メールの配送を行うため、通信時間および通信コストを節約し、なおかつ、電子メールの秘匿性を維持しながら、インターネット経由で手軽に電子メールを読むことが可能である。
【００８３】
また、電子メールが配送される経路、電子メールの内容、および送信先ユーザの意思表示に応じて、必要な場合にだけ電子メールの暗号化を行うため、全体として、柔軟で効率的な電子メールシステムを提供することができる。
【００８４】
さらに、送信先ユーザに電子メール（ＥＭ１）の着信を知らせる通知メール（ＮＭ１）はサイズの小さな平文の電子メールであるため、携帯電話機などでも容易に読むことができ、その際に消費する記憶容量も節約できる。
【００８５】
（Ｂ）第２の実施形態
以下では、本実施形態が第１の実施形態と相違する点についてのみ説明する。
【００８６】
この相違点は、主として、前記通知メールに概略文を付加した点にかぎられる。
【００８７】
(Ｂ−１)第２の実施形態の構成および動作
本実施形態にかかる電子メールシステム１１の主要部の構成例を図３に示す。
【００８８】
図３において、図１と同一または対応する符号を付与した構成要素の機能は基本的に第１の実施形態と同じである。すなわち、イントラネット３０１は前記１０１と、インターネット３０２は前記１０２と同じであり、クライアント端末３０３は前記１０３と、クライアント端末３０４は前記１０４と、クライアント端末３０５は前記１０５と、クライアント端末３２０は前記１２０と同じである。
【００８９】
また、メールサーバ３０６の機能は基本的に前記メールサーバ１０６に対応し、その内部において、メールサーバ部３０７は前記１０７と、通知メール生成部３０８は前記１０８と、秘匿必要性判断部３０９は前記１０９と、配送メール選択部３１０は前記１１０と、制御部３１１は前記１１１とそれぞれ対応している。
【００９０】
さらに、図１と同じ符号を付与した各信号および情報、ならびにユーザ、すなわち、ＭＡ１〜ＭＡ３、ＭＡＸ、ＥＭ１，ＮＭ１，ＲＭ１，ＳＣ、ＥＮ（ＥＭ１）は、第１の実施形態と同じである。
【００９１】
本実施形態において新たに付加された構成要素であるメールサーバ３０６内の概略文生成部３１２は、電子メールＥＭ１をもとに、電子メールＥＭ１の内容に関する概略文ＡＢ１を自動的に生成する部分で、生成した概略文ＡＢ１は前記通知メール生成部３０８に出力する。
【００９２】
概略文ＡＢ１を受け取った通知メール生成部３０８では、自身の内部で生成した前記通知メールＮＭ１に当該概略文ＡＢ１を付加することによって、概略文付きの通知メールＮＭ１１を生成し、出力する部分である。ここで、出力された概略文付き通知メールＮＭ１１は、メールサーバ３０６の内部において、第１の実施形態の通知メールＮＭ１と同じ取り扱いを受ける。
【００９３】
付加の方法は、例えば、通知メールＮＭ１の本文部分（通知メールＮＭ１が本文部分に有効な内容を持たない場合を含む）に概略文ＡＢ１の内容の記述を追加する形であってよい。
【００９４】
概略文ＡＢ１は、電子メールＥＭ１の内容を第１の実施形態の通知メールＮＭ１よりは詳細に記述するものであるが、元の電子メールＥＭ１の内容のうち秘匿すべき部分を明かすものであってはならない（本文部分の文脈の要点自体が秘匿すべき事項である場合には、要点を明かしてはならない。したがってこの場合には、いわゆる「概要」を誰にでも分かる形で記述したものであってはならない）点は、当該通知メールＮＭ１と同じである。
【００９５】
また、概略文ＡＢ１は通知メールＮＭ１に付加するものであるから、通知メールＮＭ１の内容と同じであってはその意味を失う。
【００９６】
例えば、元のメールＥＭ１に含まれる差出人や作成時刻等の情報を利用して本文部分に、「Ｕ２さんから○○時○○分に社外秘のメールが届いています。」という文を含む通知メールＮＭ１を生成した場合ならば、「このメールの概略は次の通りです。〈概略文ＡＢ１の内容>」という文章を追加することによって概略文付き通知メールＮＭ１１を生成することができる。
【００９７】
概略文ＡＢ１の生成には、電子メールＥＭ１のなかに頻出する文字が含まれる文を抽出する統計的な方法や、質問・報告・依頼といったメールＥＭ１の主旨を判断し主旨に沿った文を抽出する方法など様々な方法を用いることも可能である。
【００９８】
本実施形態のメールサーバ３０６の動作はＳ４１〜Ｓ４６の各ステップから構成された図４のフローチャートに示す通りである。図４と第１の実施形態のフローチャートである図２とを対比すれば明らかなように、両者の相違点は、ステップＳ４４で行う概略文の生成処理の有無だけである。
【００９９】
当該概略文の生成処理は、前記概略文生成部３１２が実行する処理である。
【０１００】
なお、秘匿性判断部３０９が電子メールＥＭ１の秘匿性が低いと判断した場合には、通知メールＮＭ１自体が不要になるため、それに付加する概略文ＡＢ１の生成も不要となり、省略することが可能である。
【０１０１】
（Ｂ−２）第２の実施形態の効果
本実施形態によれば、第１の実施形態の効果と同等な効果を得ることが可能である。
【０１０２】
加えて、本実施形態では、通知メールに概略文を付加するため、価値判断の基礎となる情報をより多く提供することができ、送信先ユーザ（Ｕ３）にとって、利便性が高まる。
【０１０３】
（Ｃ）第３の実施形態
以下では、本実施形態が第１、第２の実施形態と相違する点についてのみ説明する。
【０１０４】
この相違点は、主として、秘匿必要性が高い場合に、その高さに応じたきめ細やかな処理を行う点にかぎられる。
【０１０５】
(Ｃ−１)第３の実施形態の構成および動作
本実施形態にかかる電子メールシステム１２の主要部の構成例を図５に示す。
【０１０６】
図５において、図１と同一または対応する符号を付与した構成要素の機能は基本的に第１の実施形態と同じである。すなわち、イントラネット５０１は前記１０１と、インターネット５０２は前記１０２と同じであり、クライアント端末５０３は前記１０３と、クライアント端末５０４は前記１０４と、クライアント端末５０５は前記１０５と、クライアント端末５２０は前記１２０と同じである。
【０１０７】
また、メールサーバ５０６の機能は基本的に前記メールサーバ１０６に対応し、その内部において、メールサーバ部５０７は前記１０７と、通知メール生成部５０８は前記１０８と、秘匿必要性判断部５０９は前記１０９と、配送メール選択部５１０は前記１１０と、制御部５１１は前記１１１とそれぞれ対応している。
【０１０８】
さらに、図１と同じ符号を付与した各信号および情報、ならびにユーザ、すなわち、ＭＡ１〜ＭＡ３、ＭＡＸ、ＥＭ１，ＮＭ１，ＲＭ１，ＳＣ、ＥＮ（ＥＭ１）は、第１の実施形態と同じである。
【０１０９】
また、図５と対応する符号を付与した概略文生成部５１２の機能は、第２の実施形態の概略文生成部３１２に対応するが、秘匿必要性判断部５０９から供給される信号ＬＢに応じて概略文の生成を行う機能を備えている。
【０１１０】
この秘匿必要性判断部５０９は、図５に示すように秘匿レベル判断部５１３を内蔵している。当該秘匿レベル判断部５１３は、元の電子メールＥＭ１の秘匿性が高いと判断された場合に動作する部分で、高いと判断された秘匿性に関し、さらに詳細に秘匿性の高さ（秘匿レベル）を判断する。
【０１１１】
秘匿レベルの判断の詳細さは、２段階以上であれば何段階であってもかまわないが、ここでは、一例として、高、中、低の３段階の判断を行うものとする。
【０１１２】
また、秘匿レベルの判定には、例えば、元の電子メールＥＭ１に記載された「最重要機密」、「重要機密」、「機密」等の文字から判定する方法や、差出人の役職から判定する方法等がある。
【０１１３】
当該秘匿レベル判断部５１３が秘匿レベルの判断を行うと、秘匿必要性判断部５０９から概略文生成部５０８に、当該判断結果に応じた秘匿レベル信号ＬＢが供給される。
【０１１４】
そして、当該秘匿レベル信号ＬＢを受け取った概略文生成部５０８は、秘匿レベル信号ＬＢの内容に応じて、異なる概略文ＡＢ１１を生成する。一般的には、秘匿レベル信号ＬＢが示す秘匿レベルが高いほど概略文の持つ情報の量を減らし、反対に秘匿レベルが低いほど概略文が持つ情報の量を増加する制御を行うことになる。この情報の量は、本来、送信先ユーザＵ３や盗聴しようとするインターネット５０２上の第３者にとっての有意義な情報の量（価値ある情報の量）であるべきと考えられるが、当該情報量として例えば、単純に文字数をもって情報の量とすれば、概略文生成部５１２の処理が容易になる。
【０１１５】
文字数を制御の基準とする場合、秘匿必要性が高いことは認められたものの、相対的に秘匿レベルの低い電子メールＥＭ１は概略文ＡＢ１１の文字数を多くし、相対的に秘匿レベルの高い電子メールＥＭ１については概略文ＡＢ１１の文字数を少なくすることになる。
【０１１６】
一例としては、秘匿レベルが高い(最重要機密の)場合は５０文字、中(重要機密)の場合は１００文字、低い(通常レベルの)場合は２００文字になるような概略文ＡＢ１１を出力するようにしてもよい。また、これらの文字数は、各秘匿レベルごとに固定してもよいが、元になる電子メールＥＭ１の本文の文字数などに応じて適応的に増減させることもできる。
【０１１７】
前記クライアント端末５０５が携帯電話機である場合でも、上述した受信文字数の上限の２５０文字は、我が国における主要な携帯電話事業者のなかで最低水準の文字数制限であり、他の携帯電話事業者は、２０００文字や３０００文字の電子メールの受信を認めているから、ここに列挙した秘匿レベルごとの文字数はどの携帯電話ネットワークに対しても適用可能な現実的な値である。
【０１１８】
本実施形態のメールサーバ５０６の動作を示すフローチャートは図６に示す通りである。図６のフローチャートは、Ｓ６１〜Ｓ６８の各ステップから構成されており、第１の実施形態のフローチャートである図２と対比すれば明らかなように、ステップＳ６４、Ｓ６５（Ｓ６５ａ〜Ｓ６５ｃ）以外の各ステップは第１の実施形態と同じである。
【０１１９】
受信した電子メールＥＭ１の秘匿必要性が高いと判断されてステップＳ６３がＹＥＳ側に分岐したあとで実行されるステップＳ６４では、前記秘匿レベル判断部５１３により、前記秘匿レベルの判断が行われる。
【０１２０】
そして判断された秘匿レベルが高い場合には、ステップＳ６５ａで、概略文生成部５１２により、ｎ文字以下の概略文ＡＢ１１が生成され、同様に、秘匿レベルが中の場合には、ステップＳ６５ｂで、ｍ文字以下の概略文ＡＢ１１が生成され、秘匿レベルが低い場合には、ステップＳ６５ｃで、ｌ文字以下の概略文ＡＢ１１が生成される。これらｎ、ｍ、ｌのあいだの大小関係は、ｎ＜ｍ＜ｌである。
【０１２１】
つづくステップＳ６６では、ここで生成した概略文ＡＢ１１を付加した前記概略文付き通知メールＮＭ１１が生成されることになる。
【０１２２】
（Ｃ−２）第３の実施形態の効果
本実施形態によれば、第２の実施形態の効果と同等な効果を得ることができる。
【０１２３】
加えて、本実施形態では、元の電子メール（ＥＭ１）の秘匿レベルに応じて、概略文の情報量をきめ細かく変更することができるため、柔軟性が高く、使い勝手がよい。
【０１２４】
（Ｄ）他の実施形態
上記第１〜第３の実施形態において、電子メールの読み書きをメーラではなくＷｅｂブラウザを用いて行うＷｅｂメールを用いれば、予め作成したフォームにしたがってメール本文の内容を記述させることができるため、例えば、送信元のユーザＵ２が電子メールＥＭ１のヘッダ部分や本文部分に関し、秘匿したい字句などを詳細に指定することも可能となる。これによれば、通知メール生成部１０８や概略文生成部５１２などに相当する機能ブロックでかなり複雑な処理を行っても、秘匿性を保つことが可能となり、送信元ユーザの安心感も高まる。
【０１２５】
また、上記第２および第３の実施形態では、通知メールに概略文を付加する構成を取ったが、概略文（ＡＢ１またはＡＢ１１）の送信先ユーザ（Ｕ３）ヘの配送は、通知メールとは別個に行うようにしてもよい。これは、第１の実施形態における元メール（ＥＭ１）の取り寄せと同じ方法を概略文に適用することを意味する。
【０１２６】
すなわち、第１の実施形態と同じく概略文の付加されていない通知メール（ＮＭ１）が最初に送信先ユーザ（Ｕ３）に配信され、送信先ユーザがメールサーバ（５０６に相当）に概略文メールの配送を指示する概略文要求メールを送ると、メールサーバが概略文のメールを配信することになる。
【０１２７】
ただし概略文はその生成過程で秘匿性に配慮されているため、元の電子メール（ＥＭ１）のように暗号化することなく配送可能である。したがって、概略文メールの配送先は携帯電話機などであってもよい。
【０１２８】
また、この方法における概略文メールの配送には、送信先ユーザ（Ｕ３）の意思が反映されるため、第２及び第３の実施形態の方法より柔軟性が高いといえる。
【０１２９】
以上の説明では主としてハードウエア的に本発明を実現したが、本発明はソフトウエア的に実現することも可能である。
【０１３０】
【発明の効果】
以上に説明したように、本発明によれば、配送すべき電子メールの秘匿性の高さ、及び送信先からの指示に応じて電子メール配送サーバにおける電子メールの処理を変更することができるため、通信時間および通信コストを節約し、なおかつ、盗聴の可能性のある危険な配送経路（例えばインターネットなど）を経由した場合でも、電子メールの秘匿性を維持することが可能になる。
【図面の簡単な説明】
【図１】第１の実施形態に係る電子メールシステムの主要部の構成例を示す概略図である。
【図２】第１の実施形態の動作を示すフローチャートである。
【図３】第２の実施形態に係る電子メールシステムの主要部の構成例を示す概略図である。
【図４】第２の実施形態の動作を示すフローチャートである。
【図５】第３の実施形態に係る電子メールシステムの主要部の構成例を示す概略図である。
【図６】第３の実施形態の動作を示すフローチャートである。
【符号の説明】
１０〜１２…電子メールシステム、１０１，３０１，５０１…イントラネット、１０２，３０２，５０２…インターネット、１０３〜１０５，１２０，３２０，５２０，３０３〜３０５，５０３〜５０５…クライアント端末、１０６、３０６，５０６…メールサーバ、１０８，３０８，５０８…通知メール生成部、１０９，３０９，５０９…秘匿必要性判断部、１１０，３１０，５１０…配送メール選択部、１１１，３１１，５１１…制御部、５１３…秘匿レベル判断部、ＥＭ１…元の電子メール、ＥＮ（ＥＭ１）…暗号化電子メール、ＮＭ１…通知メール、ＮＭ１１…概略文付き通知メール、ＡＢ１，ＡＢ１１…概略文。

Claims

配送すべき電子メールを受け取り、所定の配送プロトコルにしたがって電子メールの配送を行う電子メール配送サーバにおいて、
前記電子メールのヘッダ部分または本文部分の内容に基づいて当該電子メールに求められる秘匿性の高低を判定すると共に、秘匿性が高い場合には、秘匿性の高さのレベルを判定する秘匿性判定手段と、
当該秘匿性判定手段が、秘匿性が高いと判定した電子メールに関し、秘匿性の高さのレベルが高いほど文字数が少ない概略文を生成する概略文生成手段と、
前記秘匿性判定手段が、秘匿性が低いと判定した電子メールはそのまま前記配送プロトコルにしたがって配送し、秘匿性が高いと判定した電子メールに関してはその配送を待機させた上で、当該電子メールを電子メール配送サーバが受け取っていることを電子メールの送信先に通知すると共に、前記概略文生成手段が生成した概略文を付加した通知用電子メールを前記配送プロトコルにしたがって配送する通知メール配送制御手段と、
配送を待機させた電子メールを、送信先からの指示に応じて実行される所定の配送待機メール処理手順にしたがって処理する配送待機メール処理手段と
を備えたことを特徴とする電子メール配送サーバ。
請求項１の電子メール配送サーバにおいて、
前記秘匿性判定手段は、
前記電子メールの本文部分に含まれる字句の内容に応じて当該電子メールに求められる秘匿性の高さを判定する本文内容判定部を備えたことを特徴とする電子メール配送サーバ。
請求項１の電子メール配送サーバにおいて、
前記秘匿性判定手段は、
前記電子メールのヘッダ部分に含まれる該当フィールドの記述内容に応じて当該電子メールに求められる秘匿性の高さを判定するヘッダ内容判定部を備えたことを特徴とする電子メール配送サーバ。
請求項１の電子メール配送サーバにおいて、
前記配送待機メール処理手段は、前記配送待機メール処理手順の一部として、前記電子メールの送信先から指示された送信先へ、当該電子メールを暗号化した上で配送する手順を含むことを特徴とする電子メール配送サーバ。
請求項１の電子メール配送サーバにおいて、
前記通知メール配送制御手段は、通知用電子メールを秘匿性が高いと判定されてから作成することを特徴とする電子メール配送サーバ。