(57)【特許請求の範囲】
【請求項１】
複数のユーザにＷｅｂメールサービスを提供するためのＷｅｂメールサーバにおいて、
各ユーザ宛の電子メールを記憶しておくためのメール記憶手段と、
１つ以上のメールアドレスのそれぞれについて、そのメールアドレスを送信元アドレスとした電子メールがなりすましメールではないことをメール受信者に知らせるための画像情報として用意されている認証済情報のＵＲＬを記憶したＵＲＬ記憶手段と、
各ユーザ宛の電子メールがなりすましメールであるか否かを判定する判定手段と、
前記メール記憶手段に記憶されている情報と前記判定手段による判定結果とに基づき、各ユーザに、そのユーザ宛に届いている各電子メールの差出人名が表示される受信メール一覧Ｗｅｂページであって、前記判定手段によりなりすましメールではないと判定された各電子メールについては、その電子メールの送信元メールアドレスに対応づけられて前記ＵＲＬ記憶手段に記憶されているＵＲＬを埋め込んだ受信メール一覧Ｗｅｂページを提供する受信メール一覧Ｗｅｂページ提供手段と
を備えることを特徴とするＷｅｂメールサーバ。
【請求項２】
複数のメールアドレスのそれぞれについて、そのメールアドレスを送信元アドレスとした電子メールがなりすましメールであるか否かの判定条件を複数種類の送信ドメイン認証処理の処理結果の組み合わせにて規定する判定条件情報を記憶した判定条件情報記憶手段を、さらに備え、
前記判定手段は、
前記メール記憶手段に記憶すべき電子メールが受信される度に、受信された電子メールに対して前記複数種類の送信ドメイン認証処理を行い、
前記受信メール一覧Ｗｅｂページ提供手段により或るユーザに受信メール一覧Ｗｅｂページが提供されるときに、当該ユーザ宛に届いている各電子メールがなりすましメールであるか否かを、各電子メールの送信元メールアドレスに対応づけられて前記判定条件情報記憶手段に記憶されている前記判定条件情報に従って、各電子メールについての前記認証処理手段による前記複数種類の送信ドメイン認証処理の処理結果に基づき、判定する
ことを特徴とする請求項１に記載のＷｅｂメールサーバ。
【請求項３】
前記受信メール一覧Ｗｅｂページ提供手段は、
前記判定手段によりなりすましメールであると判定された各電子メールについては、な
りすましメールであることを示す警告情報が表示される受信メール一覧Ｗｅｂページを提供する
ことを特徴とする請求項１又は２に記載のＷｅｂメールサーバ。
【請求項４】
前記ＵＲＬ記憶手段は、
１つ以上のメールアドレスのそれぞれについて、そのメールアドレスを送信元アドレスとした電子メールがなりすましメールであることをメール受信者に知らせるための画像情報として用意されている警告情報のＵＲＬである警告情報ＵＲＬも記憶し、
前記受信メール一覧Ｗｅｂページ提供手段は、
前記判定手段によりなりすましメールであると判定された各電子メールについては、各電子メールの送信元メールアドレスに対応づけられて前記ＵＲＬ記憶手段に記憶されているいる警告情報ＵＲＬを埋め込んだ受信メール一覧Ｗｅｂページを提供する
ことを特徴とする請求項１乃至請求項３のいずれか一項に記載のＷｅｂメールサーバ。
【請求項５】
各ユーザに、各ユーザが各ユーザ宛の電子メールの中から選択した電子メールの内容が示されるメール内容Ｗｅｂページであって、前記判定手段によりなりすましメールであると判定された電子メールについては、なりすましメールであることを示す情報が示されるメール内容Ｗｅｂページを提供するメール内容Ｗｅｂページ提供手段を、
さらに備える
ことを特徴とする請求項１乃至請求項４のいずれか一項に記載のＷｅｂメールサーバ。
【請求項６】
前記メール記憶手段は、
前記判定手段による判定結果を示す情報がメールヘッダに含まれる電子メールを記憶する
ことを特徴とする請求項１乃至請求項５のいずれか一項に記載のＷｅｂメールサーバ。
【請求項７】
前記判定手段が、
各ユーザ宛の電子メールがなりすましメールであるか否か送信ドメイン認証技術によりを判定する
ことを特徴とする請求項１に記載のＷｅｂメールサーバ。
【発明の詳細な説明】
【技術分野】
【０００１】
本発明は、Ｗｅｂメールサービスを提供するためのＷｅｂメールサーバに、関する。
【背景技術】
【０００２】
周知のように、電子メール（以下、単にメールと表記する）の利用者（以下、メールユーザと表記する）宛に、送信を依頼していない広告メールや個人情報の搾取を目的としたメール（以下、迷惑メールと表記する）が送信されてくる場合がある。そのため、一般的なメールユーザは、図１０に示したようなメール一覧画面をディスプレイ上に表示させ、各メールの“差出人”によって実際に閲覧するメール（及び、閲覧せずに破棄するメール）を決定している。
【０００３】
ただし、迷惑メールの中には、差出人を詐称したもの（以下、なりすましメールと表記する）が存在している。従って、メール一覧画面上に表示される差出人のみに基づき、各メールを閲覧するか破棄するかを決定した場合、メールユーザが、なりすましメールを閲覧してしまい、その結果として、個人情報の搾取被害等にあってしまう危険性がある。また、自身の差出人名（メールアドレス）が、なりすましメールに悪用されてしまった企業／個人の信用が失墜してしまうことにもなる。
【０００４】
そのため、なりすましメールであるか否かを判定するための様々な技術（例えば、    特許文献１参照。）が提案されているが、各メールユーザが、自身宛の各メールがなりすましメールであるか否かを簡単に見分けることが出来る技術は未だ開発されていないのが現状である。
【先行技術文献】
【特許文献】
【０００５】
【特許文献１】特表２００９−５１８７５１号公報
【発明の概要】
【発明が解決しようとする課題】
【０００６】
そこで、本発明の課題は、メールユーザが、自身宛の各メールが、なりすましメールである可能性があるものであるか否かを簡単に見分けることが可能なメール環境を実現できるＷｅｂメールサーバを提供することにある。
【課題を解決するための手段】
【０００７】
上記課題を解決するために、本発明の、複数のユーザにＷｅｂメールサービスを提供するためのＷｅｂメールサーバは、各ユーザ宛の電子メールを記憶しておくためのメール記憶手段と、１つ以上のメールアドレスのそれぞれについて、そのメールアドレスを送信元アドレスとした電子メールがなりすましメールではないことをメール受信者に知らせるための画像情報として用意されている認証済情報のＵＲＬを記憶したＵＲＬ記憶手段と、各ユーザ宛の電子メールがなりすましメールであるか否かを判定する判定手段と、メール記憶手段に記憶されている情報と判定手段による判定結果とに基づき、各ユーザに、そのユーザ宛に届いている各電子メールの差出人名が表示される受信メール一覧Ｗｅｂページであって、判定手段によりなりすましメールではないと判定された各電子メールについては、その電子メールの送信元メールアドレスに対応づけられて前記ＵＲＬ記憶手段に記憶されているＵＲＬを埋め込んだ受信メール一覧Ｗｅｂページを提供する受信メール一覧Ｗｅｂページ提供手段とを備える。
【０００８】
すなわち、本発明のＷｅｂメールサーバは、各ユーザに、自身宛のメール中、なりすま
しメールでないことが確実なメールについては“認証済情報”が示される受信メール一覧Ｗｅｂページを提供できるものとなっている。従って、このＷｅｂメールサーバを用いておけば、各ユーザ（メールユーザ）が、自身宛の各メールがなりすましメールである可能性があるものであるか否かを簡単に見分けることが可能なメール環境を実現できることになる。
【００１０】
また、本発明のＷｅｂメールサーバを実現するに際しては、ＵＲＬ記憶手段として、１つ以上のメールアドレスのそれぞれについて、そのメールアドレスを送信元アドレスとした電子メールがなりすましメールであることをメール受信者に知らせるための画像情報として用意されている警告情報のＵＲＬである警告情報ＵＲＬも記憶する手段を採用しておくと共に、受信メール一覧Ｗｅｂページ提供手段として、判定手段によりなりすましメールではないと判定された各電子メールについては、その電子メールの送信元メールアドレスに対応づけられて前記ＵＲＬ記憶手段に記憶されているＵＲＬを埋め込んだＵＲＬを埋め込んだ受信メール一覧Ｗｅｂページを提供する手段を採用しておくことが出来る。
【００１１】
また、本発明のＷｅｂメールサーバを実現するに際しては、自身宛の各メールが、なりすましメールであるか否かを簡単に見分けることができるようにするために、受信メール一覧Ｗｅｂページ提供手段として、判定手段によりなりすましメールであると判定された各電子メールについては、なりすましメールであることを示す警告情報が表示される受信メール一覧Ｗｅｂページを提供する手段を採用しておくことが望ましい。
【００１３】
また、本発明のＷｅｂメールサーバを実現するに際して、各ユーザに、各ユーザが各ユーザ宛の電子メールの中から選択した電子メールの内容が示されるメール内容Ｗｅｂページであって、判定手段によりなりすましメールであると判定された電子メールについては、なりすましメールであることを示す情報が示されるメール内容Ｗｅｂページを提供するメール内容Ｗｅｂページ提供手段を付加しておくことも出来る。さらに、メール記憶手段として、判定手段による判定結果を示す情報がメールヘッダに含まれる電子メールを記憶する手段を採用しておくことも、判定手段として、各ユーザ宛の電子メールがなりすましメールであるか否か送信ドメイン認証技術によりを判定する手段を採用しておくことも出来る。
【発明の効果】
【００１６】
本発明のＷｅｂメールサーバを用いれば、各メールユーザが、自身宛の各メールが、なりすましメールである可能性があるものであるか否かを簡単に見分けることが可能なメール環境を実現することが出来る。
【図面の簡単な説明】
【００１７】
【図１】本発明の第１実施形態に係るＷｅｂメールサーバの概略構成及び使用形態の説明図である。
【図２】第１実施形態に係るＷｅｂメールサーバが備える契約情報データベースの説明図である。
【図３】第１実施形態に係るＷｅｂメールサーバが備える画像指定情報データベースの説明図である。
【図４】第１実施形態に係るＷｅｂメールサーバが各ユーザに提供する受信メール一覧Ｗｅｂページの説明図である。
【図５】第１実施形態に係るＷｅｂメールサーバが各ユーザに提供するメール内容Ｗｅｂページの説明図である。
【図６】第１実施形態に係るＷｅｂメールサーバ内のＷｅｂサーバ部が実行する受信メール一覧Ｗｅｂページ提供処理の流れ図である。
【図７】第１実施形態に係るＷｅｂメールサーバ内のメール管理部が実行するヘッダ情報提供処理の流れ図である。
【図８】第１実施形態に係るＷｅｂメールサーバ内のメール管理部が実行するメール提供処理の流れ図である。
【図９】本発明の第２実施形態に係るメールサーバの概略構成及び使用形態の説明図である。
【図１０】受信メール一覧画面の説明図である。
【発明を実施するための形態】
【００１８】
以下、本発明の実施の形態について、図面を参照して詳細に説明する。
【００１９】
《第１実施形態》
まず、図１乃至図３を用いて、本発明の第１実施形態に係るＷｅｂメールサーバ１０の概要を説明する。なお、以下の説明では、Ｗｅｂメールサーバ１０（図１）の運用者のことを、サーバ運用者と表記する。また、サーバ運用者からメールアカウントを得ている者のことを、ユーザと表記する。
【００２０】
図１に模式的に示してあるように、Ｗｅｂメールサーバ１０は、インターネットＮに接続されて使用されるサーバ（１台或いは複数台のコンピュータからなる装置／システム）であり、メール受信部１１、メール管理部１２、Ｗｅｂサーバ部１４及びＤＢ記憶部１５を備えている。
【００２１】
ＤＢ記憶部１５は、契約情報データベース２４及び画像指定情報データベース２５を記憶した不揮発性記憶装置である。
【００２２】
ＤＢ記憶部１５内の契約情報データベース２４は、図２に模式的に示してあるように、“Ｆｒｏｍメールアドレス”、“運用開始日”、“なりすまし判定論理式”、“判定条件成立時動作”及び“判定条件不成立時動作”からなる契約情報を複数個記憶可能なデータベースである。画像指定情報データベース２５は、図３に模式的に示してあるように、“ＦＬＡＧ”と“アイコンＵＲＬ”からなる画像指定情報を複数個記憶可能なデータベースである。
【００２３】
メール受信部１１（図１）は、複数（図では１つ）のメール配信システム３０から送信されてくる各ユーザ宛のメールを受信してメール管理部１２内のメール記憶部１３に記憶するユニット（１種のコンピュータ）である。なお、メール配信システム３０とは、いわゆるメールサーバのことであり、メール記憶部１３とは、いわゆるメールボックスとして機能する不揮発性記憶装置のことである。
【００２４】
このメール受信部１１（内のＣＰＵ）は、或るユーザ宛のメールを受信した場合、なりすまし判定プログラム２１に従って、当該メールに対してなりすまし判定処理を実行するものとなっている。
【００２５】
メール受信部１１が実行するなりすまし判定処理は、受信したメールがなりすましメール（差出人を詐称したメール）であるか否かを判定し、判定結果を示す情報（以下、判定結果情報と表記する）を、受信したメール（メール記憶部１３にその後保存されるメール）のメールヘッダに追加する処理である。
【００２６】
このなりすまし判定処理は、受信したメールについて、ＳＰＦ（Sender Policy Framework）認証及びＳｅｎｄｅｒＩＤ認証を行う処理となっている。さらに、なりすまし判定
処理は、メールヘッダに電子署名（DKIM-signature）ヘッダが含まれるメール〔配信（送信）メールのメールヘッダに電子署名を付加する電子署名付与プログラム３１が実行されるメール配信システム３０からのメール〕については、ＤＫＩＭ（DomainKeys Identified Mail）認証も行う処理となっている。なお、ＳＰＦ認証、ＤＫＩＭ認証とは、メールヘッダ内の情報（差出人アドレス中のドメイン名、電子署名ヘッダのｄタグ値）に応じたＤＮＳサーバ４０から照合用の情報（公開鍵等）を取得することにより、電子メールの認証（差出人が詐称されているか否かの判定）を行う技術のことである。
【００２７】
メール管理部１２は、Ｗｅｂサーバ部１４から要求されたデータを、メール記憶部１３及び契約情報データベース２４内の各種情報に基づき用意し、用意したデータをＷｅｂサーバ部１４に返送する処理を、メール情報提供プログラム２２に従って実行するユニットである。
【００２８】
Ｗｅｂサーバ部１４は、各ユーザのＰＣ５０（Ｗｅｂブラウザ）から要求されたＨＴＭＬデータやイメージデータを各ユーザのＰＣ５０に返送することにより、各ユーザのＰＣ５０に受信メール一覧Ｗｅｂページやメール内容Ｗｅｂページ（詳細は後述）を表示させるユニットである。このＷｅｂサーバ部１４は、各Ｗｅｂページ用のＨＴＭＬデータの作成に必要なデータを、メール管理部１２及び画像指定情報データベース２５から取得するユニットとなっている。
【００２９】
以上のことを前提に、以下、本実施形態に係るＷｅｂメールサーバ１０の構成、動作をさらに具体的に説明する。
【００３０】
まず、契約情報データベース２４、画像指定情報データベース２５への契約情報、画像指定情報の設定タイミング、契約情報、画像指定情報の各要素情報の意味等を説明する。
【００３１】
本実施形態に係るＷｅｂメールサーバ１０は、図４に模式的に示したような受信メール一覧Ｗｅｂページ、すなわち、なりすましメールでないことを示す認証済アイコン又はなりすましメールであることを示す警告アイコンが差出人欄に示される受信メール一覧Ｗｅｂページを、各ユーザに提供できるものである。また、Ｗｅｂメールサーバ１０は、図５に模式的に示したようなメール内容Ｗｅｂページ、すなわち、閲覧中のメールがなりすましメールであるか否かについてのメッセージ（図では、閲覧中のメールがなりすましメールである旨のメッセージ）が示されるメール内容Ｗｅｂページを、各ユーザに提供できるものともなっている。
【００３２】
契約情報データベース２４及び画像指定情報データベース２５は、『メール送信者に固有なアイコンを認証済アイコン／警告アイコンとして表示できるようにすること』や、『認証済アイコン等の表示サービスをサーバ運用者と所定の契約を行った者（以下、契約メール送信者と表記する）からのメールのみに対して行えるようにすること』等を目的として設けられているデータベースである。
【００３３】
具体的には、或る契約メール送信者との間の上記契約時には、認証済アイコン／警告アイコンの表示対象とするメールアドレス、認証済アイコン等の表示開始日、なりすましメールであるか否かを判定するために実際に行う処理の内容が定められる。そして、定められたメールアドレス、定められた表示開始日、定められた処理内容を表す情報（論理式）が、それぞれ、Ｆｒｏｍメールアドレス、運用開始日、なりすまし判定論理式として設定された契約情報が契約情報データベース２４に追加される。
【００３４】
また、契約メール送信者との間の契約時には、認証済アイコン、警告アイコンの双方の表示を行うか、いずれか一方のみの表示を行うか、各アイコンとしてユニークなものを使用するか共用認証済アイコン／共用警告アイコンを使用するか等も定められる。ここで、共用認証済アイコン／共用警告アイコンとは、それについての画像指定情報が画像指定情報データベース２５に始めから（契約情報データベース２４に最初の契約情報が追加される前から）設定されているアイコンのことである。以下、共用認証済アイコンについての画像指定情報中のＦＬＡＧ（共用認証済アイコンに対応づけられているＦＬＡＧ）のことを、共用認証済アイコン用ＦＬＡＧと表記し、共用警告アイコンについての画像指定情報中のＦＬＡＧのことを、共用認証済アイコン用ＦＬＡＧと表記する。
【００３５】
契約メール送信者が認証済アイコンとしてユニークなアイコンを表示することを希望した場合には、当該アイコン用のユニークなＦＬＡＧ（既存の各ＦＬＡＧと異なるＦＬＡＧ）が定められる。そして、当該ＦＬＡＧと、契約メール送信者が指定したアイコンが存在する場所を示すＵＲＬ（"http://"を含まないもの）とからなる画像指定情報が、画像指
定情報データベース２５（図３）に追加される。また、契約メール送信者に関する契約情報（図２）に、“判定条件成立時動作”として、当該ＦＬＡＧをメールヘッダ内に追加することを示す情報（“ＦＬＡＧ「￥１０００」を付与”等）が設定される。
【００３６】
契約メール送信者が認証済アイコンとして共用認証済アイコンを表示することを希望した場合には、画像指定情報データベース２５に画像指定情報が追加されることなく、契約情報に、“判定条件成立時動作”として、共用認証済アイコン用ＦＬＡＧをメールヘッダ内に追加することを示す情報が設定される。また、契約メール送信者が認証済アイコンの表示を行わないことを希望した場合（警告済アイコンの表示のみを行うことを希望した場合）には、契約情報の“判定条件成立時動作”は、ＮＵＬＬとされる。
【００３７】
警告済アイコンの表示を行う場合には、通常、契約情報に、“判定条件不成立時動作”として、共用警告アイコン用ＦＬＡＧをメールヘッダ内に追加することを示す情報が設定される。ただし、契約メール送信者が警告アイコンとして特定のアイコンの表示を希望した場合には、当該特定のアイコンにユニークなＦＬＡＧを割り当てる作業、画像指定情報データベース２５に当該特定のアイコンに関する画像指定情報を追加する作業、及び、“判定条件不成立時動作”として、当該特定のアイコンに割り当てたＦＬＡＧをメールヘッダ内に追加することを示す情報を設定する作業が行われる。
【００３８】
次に、受信メール一覧Ｗｅｂページ提供時のＷｅｂメールサーバ１０の動作を説明する。
【００３９】
或るユーザ（以下、処理対象ユーザと表記する）が、自身（或いは他人）のＰＣ５０のＷｅｂブラウザを起動してＷｅｂメールサーバ１０（Ｗｅｂサーバ部１４）にログインしてきた場合、Ｗｅｂサーバ部１４は、図６に示した手順の受信メール一覧Ｗｅｂページ提供処理を開始する。
【００４０】
そして、受信メール一覧Ｗｅｂページ提供処理を開始したＷｅｂサーバ部１４、まず、ヘッダ情報取得処理（ステップＳ１０１）を行う。
【００４１】
このヘッダ情報取得処理は、処理対象ユーザ宛に届いている各メールのヘッダ情報をメール管理部１２から取得する処理である。なお、この処理は、『処理対象ユーザ宛に届いている１つの（最初／次の）メールのヘッダ情報の提供を要求するヘッダ情報要求コマンド』をメール管理部１２に対して発行する処理を繰り返し、ヘッダ情報要求コマンドに対する応答として、“ヘッダ情報を未提供のメールが無くなった旨の情報”が返送されきたときに終了する処理となっている。
【００４２】
受信メール一覧Ｗｅｂページ提供処理の残りの各ステップの内容を説明する前に、ここで、ヘッダ情報要求コマンドに対するメール管理部１２の動作を説明しておくことにする。
【００４３】
メール管理部１２は、Ｗｅｂサーバ部１４からヘッダ情報要求コマンドを受け取った場合、図７に示した手順のヘッダ情報提供処理を実行するように構成されている。
【００４４】
すなわち、ヘッダ情報要求コマンドを受け取ったメール管理部１２は、まず、メール記憶部１３から、処理対象ユーザ宛の最初／次のメールのヘッダ情報を読み出す処理（ステップＳ２０１）を行う。なお、流れ図（図７）への表記は省略してあるが、メール管理部１２は、このステップＳ２０１の処理に失敗した場合（処理対象ユーザ宛の全メールのヘッダ情報の処理完了後にヘッダ情報要求コマンドを受け取った場合）、“ヘッダ情報を未提供のメールが無くなった旨の情報”をＷｅｂサーバ部１４に返送してヘッダ情報提供処理を終了する。
【００４５】
或るメールのヘッダ情報を取得したメール管理部１２は、当該ヘッダ情報中のＦｒｏｍメールアドレスと同じＦｒｏｍメールアドレスを含む契約情報（以下、対応契約情報と表記する）が契約情報データベース２４内に存在しているか否かを判断する（ステップＳ２０２）。
【００４６】
対応契約情報が契約情報データベース２４内に存在していなかった場合（ステップＳ２０２；ＮＯ）、メール管理部１２は、メール記憶部１３から読み出したヘッダ情報をそのままＷｅｂサーバ部１４に返送（ステップＳ２０７）してから、ヘッダ情報提供処理を終了する。
【００４７】
また、メール管理部１２は、対応契約情報が存在していた場合（ステップＳ２０２；ＹＥＳ）には、処理対象となっているヘッダ情報中のメール送信日が、対応契約情報中の運用開始日以降であるか否かを判断する（ステップＳ２０３）。そして、メール管理部１２は、メール送信日が運用開始日以降でなかった場合（ステップＳ２０３；ＮＯ）には、ヘッダ情報をそのままＷｅｂメール部に返送（ステップＳ２０７）してから、ヘッダ情報提供処理を終了する。
【００４８】
一方、メール送信日が運用開始日以降であった場合（ステップＳ２０３；ＮＯ）、メール管理部１２は、ヘッダ情報中の判定結果情報（ＳＰＦ認証結果、ＳｅｎｄｅｒＩＤ認証結果、ＤＫＩＭ認証結果）に基づき、対応契約情報中のなりすまし判定論理式が成立する（TRUEである）か否かを判断する（ステップＳ２０４）。そして、メール管理部１２は、なりすまし判定論理式が成立していた場合（ステップＳ２０４；ＹＥＳ）には、処理中のヘッダ情報に対して対応契約情報中の判定条件成立時動作が指定する内容の動作を行う（ステップＳ２０５）。すなわち、対応契約情報中の判定条件成立時動作がＮＵＬＬでなかった場合、メール管理部１２は、このステップＳ２０５において、処理中のヘッダ情報にＦＬＡＧ値（「￥１０００」等）を追加する処理を行う。また、対応契約情報中の判定条件成立時動作がＮＵＬＬであった場合、メール管理部１２は、ヘッダ情報に何ら情報を追加することなく、ステップＳ２０５の処理を終了する。
【００４９】
メール管理部１２は、なりすまし判定論理式が成立していなかった場合（ステップＳ２０４；ＮＯ）には、処理中のヘッダ情報に対して対応契約情報中の判定条件不成立時動作が指定する動作を行う（ステップＳ２０６）。
【００５０】
そして、ステップＳ２０５又はＳ２０６の処理を終えたメール管理部１２は、ＦＬＡＧを追加した（又はＦＬＡＧを追加しなかった）ヘッダ情報をＷｅｂメール部１４に返送（ステップＳ２０７）してから、ヘッダ情報提供処理を終了する。
【００５１】
図６に戻って、受信メール一覧Ｗｅｂページ提供処理の内容説明を続ける。
【００５２】
ヘッダ情報取得処理（ステップＳ１０１）を行うことにより処理対象ユーザ宛の全メールのヘッダ情報を取得したＷｅｂメール部１２は、取得したヘッダ情報群と画像指定情報データベース２５内の情報とに基づき、図４に示したような受信メール一覧ＷｅｂページをＷｅｂブラウザに表示させることが出来る受信メール一覧Ｗｅｂページデータ（ＨＴＭＬデータ）を作成する処理（ステップＳ１０２）を行う。より具体的には、Ｗｅｂメール部１２は、各ヘッダ情報（ＦＬＡＧを含むもの）内のＦＬＡＧに対応付けられているアイコンＵＲＬを画像指定情報データベース２５（図４参照）から読み出し、読み出した各アイコンＵＲＬを対応するメールの差出人情報部分に埋め込んだ受信メール一覧Ｗｅｂページデータを作成する処理を行う。
【００５３】
そして、Ｗｅｂメール部１２は、作成した受信メール一覧Ｗｅｂページデータを処理対象ユーザが操作しているＰＣ５０に返送して（ステップＳ１０３）から、受信メール一覧Ｗｅｂページ提供処理を終了する。
【００５４】
次に、メール内容Ｗｅｂページ提供時のＷｅｂメールサーバ１０の動作を説明する。
【００５５】
図５から明らかなように、メール内容Ｗｅｂページは、処理対象ユーザが受信メール一覧Ｗｅｂページから閲覧するメールを選択したときに表示されるＷｅｂページである。このメール内容Ｗｅｂページを要求するＨＴＴＰリクエストを受信した場合、Ｗｅｂサーバ部１４は、所定形式のメール要求コマンドを発行することにより、処理対象ユーザが閲覧
を要求しているメール（受信したメールの全データ）の出力（自ユニットへの提供）をメール管理部１２に要求する。
【００５６】
上記メール要求コマンドを受け取ったメール管理部１２は、図８に示した手順のメール提供処理を開始し、まず、当該コマンドで要求されているメールをメール記憶部１３から読み出す（ステップＳ３０１）。その後、メール管理部１２は、読み出したメールのヘッダ情報に対して、上記したヘッダ情報提供処理と本質的には同内容／同手順の処理（ステップＳ３０２〜Ｓ３０６）を実行する。
【００５７】
ただし、なりすまし判定論理式が成立していた場合（ステップＳ３０４；ＹＥＳ）、メール管理部１２は、“判定条件成立時動作”を行うのではなく、メール記憶部１３から読み出したメールのヘッダ情報に、所定の認証済メッセージ提示要フラグを追加する処理（ステップＳ３０５）を行う。また、メール管理部１２は、なりすまし判定論理式が成立していなかった場合（ステップＳ３０４；ＮＯ）には、“判定条件不成立時動作”を行うのではなく、メール記憶部１３から読み出したメールのヘッダ情報に、所定の警告メッセージ提示要フラグを追加する処理（ステップＳ３０６）を行う。
【００５８】
そして、ステップＳ３０５，Ｓ３０６の処理を終えたメール管理部１２は、そのヘッダ情報に認証済／警告メッセージ提示要フラグに追加したメールをＷｅｂサーバ部１４に返送して、このメール提供処理を終了する。
【００５９】
このような手順でメール管理部１２が返送してくるメールを受け取ったＷｅｂサーバ部１４は、当該メールのヘッダ情報中に、警告メッセージ提示要フラグが設定されているか、警告メッセージ提示要フラグが設定されているか、いずれのメッセージ提示要フラグも設定されていないかを判別する。
【００６０】
そして、Ｗｅｂサーバ部１４は、メール管理部１２からのメールのヘッダ情報中に警告メッセージ提示要フラグが設定されていた場合には、当該メールに基づき、閲覧中のメールがなりすましメールである旨のメッセージが示されるメール内容Ｗｅｂページ（図５）をＷｅｂブラウザに表示させるためのＨＴＭＬデータを用意して、処理対象ユーザが使用しているＰＣ５０に返送する。
【００６１】
また、Ｗｅｂサーバ部１４は、メール管理部１２からのメールのヘッダ情報中に認証済メッセージ提示要フラグが設定されていた場合には、当該メールに基づき、閲覧中のメールがなりすましメールではない旨のメッセージが示されるメール内容ＷｅｂページをＷｅｂブラウザに表示させるためのＨＴＭＬデータを用意して、処理対象ユーザが使用しているＰＣ５０に返送する。
【００６２】
また、Ｗｅｂサーバ部１４は、メール管理部１２からのメールデータのヘッダ情報中にいずれのメッセージ提示要フラグも設定されていなかった場合には、当該メールデータに基づき、通常のメール内容ＷｅｂページをＷｅｂブラウザに表示させるためのＨＴＭＬデータを用意して、処理対象ユーザが使用しているＰＣ５０に返送する。
【００６３】
以上、説明したように、本実施形態に係るＷｅｂメールサーバ１０は、各ユーザに、自身宛の各メール（いずれかの契約メール送信者の“Ｆｒｏｍメールアドレス”が差出人アドレスとして使用されているもの）がなりすましメールであるか否かを簡単に見分けることが可能な受信メール一覧Ｗｅｂページ及びメール内容Ｗｅｂページを提供する機能を有している。従って、このＷｅｂメールサーバ１０を用いておけば、各メールユーザが、自身宛の各メールがなりすましメールであるか否かを簡単に見分けることが可能なメール環境を実現できることになる。
【００６４】
《第２実施形態》
図１０に、本発明の第２実施形態に係るメールサーバ２０の構成及び使用形態を示す。
【００６５】
図示してあるように、メールサーバ２０は、メール受信部１１、メール管理部１２、ＤＢ記憶部１５及びメールサーバ部１６を備えたサーバである。なお、このメールサーバ２０は、上記したＷｅｂメールサーバ１０を、一種のＩＭＡＰ対応メールサーバに変形したものである。また、メールサーバ２０は、メールクライアントプログラム１８（詳細は後述）をインストールしたＰＣ５０から利用すべきものとして開発したサーバとなっている。
【００６６】
本実施形態に係るメールサーバ２０が備えるメール受信部１１、メール管理部１２、ＤＢ記憶部１５は、それぞれ、Ｗｅｂメールサーバ１０が同名の構成要素と同じユニットである。
【００６７】
メールサーバ部１６は、メールプログラム２８に従って、上記したＷｅｂメール部１４と同様の動作を行うユニットである。具体的には、メールサーバ部１６は、メールクライアントプログラム１８からの各種要求に対して以下のように応答するユニットとなっている。
【００６８】
メールサーバ部１６は、メールクライアントプログラム１８から受信メール一覧画面の表示に必要な情報が要求された場合には、Ｗｅｂサーバ部１４が行うものと同じヘッダ情報取得処理を行うことにより処理対象ユーザ宛の全メールのヘッダ情報を取得する。次いで、メールサーバ部１６は、画像指定情報データベース２５を参照することにより、取得したＦＬＡＧを含む各ヘッダ情報中のＦＬＡＧをアイコンＵＲＬに置き換える処理を行う。そして、ＦＬＡＧをアイコンＵＲＬに置き換えた各ヘッダ情報及びＦＬＡＧを含んでいなかった各ヘッダ情報をメールクライアントプログラム１８に返送する。
【００６９】
メールサーバ部１６は、メールクライアントプログラム１８からメール内容画面の表示に必要な情報が要求された場合には、Ｗｅｂサーバ部１４が発行するものと同じメール要求コマンドをメール管理部１２に対して発行する。そして、メールサーバ部１６は、当該コマンドに対する応答として返送されてくるメール（ヘッダ情報に認証済／警告提示要メッセージが含まれていることがあるもの）を、そのまま、メールクライアントプログラム１８に返送する。
【００７０】
メールサーバ２０を利用する各ＰＣ５０にインストールされるメールクライアントプログラム１８は、上記のような情報に基づき、受信メール一覧Ｗｅｂページ（図４参照）と同様の構成を有する受信メール一覧画面や、メール内容Ｗｅｂページ（図５参照）と同様の構成を有するメール内容画面を表示するプログラムである。
【００７１】
すなわち、メールクライアントプログラム１８は、受信メール一覧画面の表示指示操作がなされた場合には、所定形式の要求をメールサーバ２０（メールサーバ部１６）に対して送信することにより、アイコンＵＲＬを含む幾つかのヘッダ情報とアイコンＵＲＬを含まない幾つかのヘッダ情報とを取得する。そして、取得したヘッダ情報中のアイコンＵＲＬに基づき、認証済／警告アイコンを取得した上で、受信メール一覧Ｗｅｂページと同様の構成を有する受信メール一覧画面をディスプレイ上に表示する。
【００７２】
また、メールクライアントプログラム１８は、メール内容画面の表示指示操作がなされた場合には、所定形式の要求をメールサーバ２０（メールサーバ部１６）に対して送信することにより、ヘッダ情報に認証済／警告提示要メッセージが含まれているメール又は通
常のメールを取得する。そして、メールクライアントプログラム１８は、取得したメールのヘッダ情報中にメッセージ提示要フラグが含まれていた場合には、閲覧中のメールがなりすましメールではない旨又は閲覧中のメールがなりすましメールである旨のメッセージが本文の先頭部分に示されるメール内容画面をディスプレイ上に表示する。また、メールクライアントプログラム１８は、取得したメールのヘッダ情報中にメッセージ提示要フラグが含まれていなかった場合には、そのようなメッセージが示されない通常のメール内容画面をディスプレイ上に表示する。
【００７３】
本実施形態に係るメールサーバ２０、メールクライアントプログラム１８は、上記機能を有するものとなっている。従って、メールサーバ２０をメールクライアントプログラム１８と共に用いておけば、各ユーザに、自身宛の各メール（いずれかの契約メール送信者の“Ｆｒｏｍメールアドレス”が差出人アドレスとして使用されているもの）がなりすましメールであるか否かを簡単に見分けることが可能なネットワークシステムを構築できることになる。
【００７４】
《変形形態》
上記した各実施形態に係る技術は、各種の変形が行えるものである。例えば、Ｗｅｂメールサーバ１０を、契約メール送信者からのメールについてのみ、なりすまし判定処理を行うものに変形することが出来る。また、Ｗｅｂメールサーバ１０を、メール記憶部１３内に、判定結果情報ではなく、ＦＬＡＧ又はアイコンＵＲＬがメールヘッダ内に設定されたメールが記憶されるものに変形することも出来る。さらに、
【００７５】
また、メールサーバ２０を、判定結果情報を含むヘッダ情報をメールクライアントプログラム１８に返送するものに変形しておくとと共に、メールクライアントプログラム１８を、ヘッダ情報中の判定結果情報に基づきメールサーバ２０に問い合わせを行うことにより、差出人欄に表示するアイコンを得るプログラムに変形しておくことも出来る。
【００７６】
さらに、認証済アイコン／警告アイコン（つまり画像情報）の代わりに特定の文字列が表示されるようにしておくことも出来る。また、Ｗｅｂメールサーバ１０、メールサーバ２０の具体的な構成、契約情報データベース２４、画像指定情報データベース２５の具体的な構成を上記したものとは異なるものとしても良いことは、当然のことである。
【符号の説明】
【００７７】
１０  Ｗｅｂメールサーバ
１１  メール受信部
１２  メール管理部
１３  メール記憶部
１４  Ｗｅｂサーバ部
１５  ＤＢ記憶部
１６  メールサーバ部
１８  メールクライアントプログラム
２０  メールサーバ
２１  なりすまし判定プログラム
２２  メール情報提供プログラム
２３  Ｗｅｂメールプログラム
２４  契約情報データベース
２５  画像指定情報データベース
２８  メールプログラム
５０  ＰＣ
【図１】
0005486452.tif 000002
【図２】
0005486452.tif 000003
【図３】
0005486452.tif 000004
【図４】
0005486452.tif 000005
【図５】
0005486452.tif 000006
【図６】
0005486452.tif 000007
【図７】
0005486452.tif 000008
【図８】
0005486452.tif 000009
【図９】
0005486452.tif 000010
【図１０】
0005486452.tif 000011