JP4857246B2 - Approval device, approval method, and program - Google Patents
Approval device, approval method, and programDownload PDFInfo
- Publication number
- JP4857246B2 JP4857246B2JP2007288881AJP2007288881AJP4857246B2JP 4857246 B2JP4857246 B2JP 4857246B2JP 2007288881 AJP2007288881 AJP 2007288881AJP 2007288881 AJP2007288881 AJP 2007288881AJP 4857246 B2JP4857246 B2JP 4857246B2
- Authority
- JP
- Japan
- Prior art keywords
- approval
- address
- reply
- approver
- Prior art date
- Legal status (The legal status is an assumption and is not a legal conclusion. Google has not performed a legal analysis and makes no representation as to the accuracy of the status listed.)
- Expired - Fee Related
Links
Images
Landscapes
- Information Transfer Between Computers (AREA)
- Data Exchanges In Wide-Area Networks (AREA)
Description
Translated fromJapanese本発明は、承認装置、承認方法、及びプログラムに関する。The present invention relates to anapproval apparatus, an approval method, and a program .
情報伝達の手段として電子メールが普及している。電子メールにどのような内容を記載するかは送信者の責任であり、送信者の勘違いや操作ミスによって、例えば社外秘情報などの情報が受信者に送信されると情報漏洩につながる。そこで、電子メールの送信前に承認者による承認が行われている（特許文献１および２参照）。
しかしながら、特許文献１に開示される技術では、承認者に承認を行うように電子メールが送信されるが、承認者は、その電子メールに記載されたＵＲＬにＷｅｂブラウザを操作してアクセスし、Ｗｅｂブラウザを操作して承認を行う必要があるので手間がかかる。また、特許文献２に開示される技術では、承認者は、承認要請メールデータを受信し、それを所定の承認用または否認用のメールアドレスに転送することによって承認を行うことができるが、転送先として所定の承認用または否認用のメールアドレスを選択する手間がかかる。 However, in the technology disclosed in
本発明は、このような背景を鑑みてなされたものであり、承認者が容易に電子メールの承認を行うことができる承認装置、承認方法、及びプログラムを提供することを目的とする。The present invention has been made in view of such a background, and an object thereof is to provide anapproval device, an approval method, and a program that allow an approver to easily approve an electronic mail.
上記課題を解決するための本発明の主たる発明は、電子メールを受信する電子メール受信部を有する承認装置であり、受信した前記電子メールに基づき、第１のメールアドレスを送信元とし、第２のメールアドレス及び承認者のメールアドレスを宛先として設定した電子メールである承認依頼メールを作成して送信する承認依頼メール送信部と、前記承認依頼メールについて前記承認者から返信された電子メールである返信メールを取得する返信メール取得部と、前記記憶した返信メールの宛先に前記第１のメールアドレスおよび前記第２のメールアドレスの両方が含まれている場合に承認と判定し、前記返信メールの宛先に前記第１のメールアドレスのみが含まれている場合に非承認と判定する承認判定部とを備えることとする。A main invention of the present invention for solving the above-mentioned problem isan approval devicehaving an e-mail receiving unit that receives an e-mail , and based on thereceived e-mail, the first e-mail address is a sender, An approval request mail sending unit thatcreates and sends an approval request mail, which is an e-mail with the e-mail addressand approver's e-mail address set as destinations, and an e-mail returned from the approver for the approval request mail It determines the reply mail acquisition unit thatTokusu preparative reply mail, the authorization when both the first mail address and the second mail address is included in said memorized the reply mail address, the reply An approval determination unit that determines non-approval when only the first mail address is included in the mail destination is provided.
その他本願が開示する課題やその解決方法については、発明の実施形態の欄及び図面により明らかにされる。 Other problems and solutions to be disclosed by the present application will be made clear by the embodiments of the invention and the drawings.
本発明によれば、承認者が容易に電子メールの承認を行うことができる。 According to the present invention, an approver can easily approve an electronic mail.
＝＝システム構成＝＝
以下、本発明の一実施形態に係る電子メールを送信するメールシステムについて説明する。本実施形態のメールシステムでは、電子メールの送信時に、電子メールの送信者とは異なる承認者からの承認を受けることを想定している。== System configuration ==
Hereinafter, a mail system for transmitting an electronic mail according to an embodiment of the present invention will be described. In the mail system of the present embodiment, it is assumed that when an e-mail is transmitted, an approval from an approver different from the sender of the e-mail is received.
図１は、本実施形態の係るメールシステムの全体構成を示す図である。同図に示すように、本実施形態のメールシステムは、メールサーバ１０、ユーザ端末２０、および承認者端末３０を含んで構成されている。ユーザ端末２０、承認者端末３０、およびメールサーバ１０はそれぞれ通信ネットワーク１４０に接続されており、通信ネットワーク１４０を介して互いに通信が可能である。通信ネットワーク１４０は、例えば、インターネットやＬＡＮ（Local Area Network）などであり、イーサネット（登録商標）や公衆電話回線網、無線通信網などにより構築される。本実施形態では、通信ネットワーク１４０上では、ＴＣＰ／ＩＰによる通信が行われるものとする。 FIG. 1 is a diagram showing an overall configuration of a mail system according to the present embodiment. As shown in the figure, the mail system of this embodiment includes a
ユーザ端末２０は、電子メールの送受信を行うユーザ（電子メールの送信者または受信者である。以下、ユーザ端末２０を操作するユーザをドメインユーザという。）が操作する、例えばパーソナルコンピュータやワークステーション、ＰＤＡ（Personal Digital Assistance）、携帯電話端末などのコンピュータである。ユーザ端末２０では、電子メールの送受信を行うアプリケーションソフト動作しており、いわゆるＭＵＡ（Mail User Agent）として機能している。ドメインユーザはＭＵＡを操作して電子メールの作成や送受信を行う。 The
承認者端末３０は、ユーザ端末２０から送信された電子メール（以下、配送メールという。）の配送を承認するユーザ（以下、承認者という。）が操作する、例えば、パーソナルコンピュータやワークステーション、ＰＤＡ、携帯電話端末などのコンピュータである。承認者端末３０もＭＵＡの機能を提供している。後述するように、承認者はＭＵＡを操作して電子メールを送信することにより承認処理を行う。本実施形態では、承認者のメールアドレス（以下、承認者アドレスという。）を送信元として、一般的な電子メールの送信は行われないものとし、承認者から送信される電子メールは、承認処理のためにのみ用いられるものとする。なお、承認者による電子メール送信の承認処理の詳細については後述する。 The
メールサーバ１０は、ユーザ端末２０や承認者端末３０から送信される電子メールの配送を行う、いわゆるＭＴＡ（Mail Transfer Agent）の機能を提供する、例えばパーソナルコンピュータやワークステーションなどのコンピュータである。メールサーバ１０は、ＳＭＴＰ（Simple Mail Transfer Protocol）に規定されたデータとして、ユーザ端末２０や承認者端末３０から電子メールを受け付け、受け付けた電子メールの宛先がドメインユーザのメールアドレス（以下、ドメインユーザアドレスという。）または承認者アドレスであれば、電子メールを所定の記憶領域（以下、メールボックスという。）に記憶し、それ以外であれば、電子メールを他のコンピュータに転送することにより電子メールの配送を行う。なお、メールアドレスが、ドメインユーザアドレスまたは承認者アドレスであるかどうかは、例えば、所定のドメインに所属しているか否かにより判定することができる。本実施形態では、「domain1」または「domain2」がドメインとして設定されているメールアドレスは、ドメインユーザアドレスまたは承認者アドレスであるものとする。 The
また、メールサーバ１０は、ユーザ端末２０や承認者端末３０からＰＯＰ（Post Office Protocol）に規定されたメール取得要求などのコマンドを受け付けて、メール取得要求に応じて、メールボックスに記憶されている電子メールの読み書きを行う。 Further, the
なお、本実施形態では、メールサーバ１０が全てのユーザおよび承認者からの電子メールの配送を行う。ユーザ端末２０および承認者端末３０が電子メールの送信を行う場合には、電子メールをメールサーバ１０に送信し、電子メールの受信を行う場合には、電子メールを取得するコマンド（以下、メール取得要求という。）をメールサーバ１０に送信するものとする。 In the present embodiment, the
本実施形態では、メールサーバ１０は、配送すべき電子メール（以下、配送メールという。）の配送時に承認者による承認を受けることを想定している。
メールサーバ１０は、配送メールを配送してもよいかどうかを問い合わせる電子メール（以下、承認依頼メールという。）を承認者宛てに作成してメールボックスに格納する。承認依頼メールのヘッダには、承認者アドレスが宛先（Ｔｏ）フィールドに設定され、所定のメールアドレスである第１の管理者アドレス（admin01@domain1）が送信元（Ｆｒｏｍ）のフィールドに設定され、さらに、所定のメールアドレスである第２の管理者アドレス（admin02@domain1）が宛先（ＴｏまたはＣｃ）として設定される。In the present embodiment, it is assumed that the
The
これに対する承認者からの返信の電子メールには、宛先として承認依頼メールの送信元である第１の管理者アドレスが設定される。ここで、宛先に第２の管理者アドレスも加えられている場合、メールサーバ１０は、配送メールの配送が承認されたと判断する。逆に第１の管理者アドレスのみが宛先となっている場合には、メールサーバ１０は、配送メールの配送が承認されなかったと判断する。 In response to this, an e-mail returned from the approver is set with a first administrator address as a destination of the approval request mail. Here, when the second administrator address is also added to the destination, the
一般的なＭＵＡは、受信した電子メールの送信元（ＦｒｏｍフィールドまたはＲｅｐｌｙ−Ｔｏフィールドに設定されている返信先）に対して返信する電子メール（以下、返信メールという。）を送信する「返信」機能と、送信元、宛先およびカーボンコピーの全てに対して応答メールを送信する「全員に返信」機能とを備えている。 A general MUA transmits a reply e-mail (hereinafter referred to as a reply mail) to the sender of the received e-mail (a reply destination set in the From field or Reply-To field). And a “reply to all” function that sends a response mail to all of the source, destination, and carbon copy.
したがって、承認者は、承認依頼メールに対して、ＭＵＡの「全員に返信」機能により返信した場合には、配送メールの配送を承認したことになり、ＭＵＡの「返信」機能により返信した場合には、配送メールの配送を承認しなかったことになる。このように、本実施形態のメールシステムでは、一般的なＭＵＡの機能を利用して、承認者が容易に承認処理を行うことができるようにしている。 Therefore, when the approver responds to the approval request mail by the “reply to all” function of the MUA, the approver approves the delivery of the delivery mail, and when the reply is replied by the “reply” function of the MUA. Did not approve delivery of the delivery mail. As described above, in the mail system according to the present embodiment, an approver can easily perform an approval process by using a general MUA function.
以下、詳細について説明する。 Details will be described below.
＝＝ハードウェア＝＝
図２は、本実施形態のメールシステムのハードウェア構成を示す図である。
同図に示すように、メールサーバ１０は、ＣＰＵ１０８、主記憶装置１０１、通信インタフェース１０９、ディスクインタフェース１１０、およびディスクインタフェース１１０に接続されたハードディスク装置１１４を備えている。== Hardware ==
FIG. 2 is a diagram illustrating a hardware configuration of the mail system according to the present embodiment.
As shown in the figure, the
ハードディスク装置１１４は、各種のプログラムやデータを記憶する記憶装置である。ハードディスク装置１１４に代えて、フラッシュメモリやＣＤ−ＲＯＭドライブなどの記憶装置を採用するようにしてもよい。主記憶装置１０１には、サーバプログラム１０２が記憶されている。サーバプログラム１０２は、ハードディスク装置１１４から主記憶装置１０１に読み出すようにしてもよいし、通信ネットワーク１４０を介して他のコンピュータから受信するようにしてもよい。ＣＰＵ１０８は、主記憶装置１０１に記憶されているサーバプログラム１０２などのプログラムを実行することにより各種の機能を実現する。 The
通信インタフェース１０９は、通信ネットワーク１４０に接続するためのインタフェースであり、例えば、イーサネット（登録商標）に接続するためのアダプタや、公衆電話回線網に接続するためのモデム、無線通信網に接続するための無線通信装置などである。 The
ディスクインタフェース１１０は、ハードディスク装置１１４と接続するためのインタフェースであり、例えば、ＳＣＳＩ（Small Computer System Interface）やＩＤＥ（Integrated Drive Electronics）、ＳＡＮ（Storage Area Network）などのプロトコルに従ってハードディスク装置１１４にアクセスする。ＣＰＵ１０８は、ディスクインタフェース１１０を介してハードディスク装置１１４に対するデータの入出力を行う。 The
なお、ハードディスク装置１１４は、メールサーバに内蔵する形態としてもよいし、メールサーバ１０とは別体の独立した記憶装置としてもよい。また、ＮＡＳ（Network Attached Storage）のように、他のコンピュータが管理する記憶装置にアクセスするようにしてもよい。 The
ユーザ端末２０および承認者端末３０は、同じハードウェア構成である。図２に示すように、ユーザ端末２０および承認者端末３０はそれぞれ、ＣＰＵ１２７、主記憶装置１２１、通信インタフェース１２８、ディスクインタフェース１２９、入出力インタフェース１３０、ディスクインタフェース１２９に接続されたハードディスク装置１３３および入出力インタフェース１３０に接続された入出力装置１３２を備えている。 The
入出力装置１３２は、データの入出力を行う、例えば、キーボードやマウス、タッチパネル、ディスプレイ、プリンタなどである。ユーザ端末２０および承認者端末３０は、通常キーボード、マウスおよびディスプレイなどの複数の入出力装置１３２を備える。 The input /
＝＝ソフトウェア＝＝
図３は、本実施形態のメールシステムの機能構成を示す図である。
ユーザ端末２０および承認者端末３０は同じ機能を有し、それぞれ制御部１２３、メール表示部１２４、メール受信部１２５、メール送信部１２６、およびメールデータ記憶部１３１を備えている。
メール表示部１２４、メール受信部１２５およびメール送信部１２６は、ユーザ端末２０および承認者端末３０が備えるＣＰＵ１２７が主記憶装置１２１に記憶されているクライアントプログラム１２２を実行することにより実現される。また、メールデータ記憶部１３１は、ユーザ端末２０および承認者端末３０が備える主記憶装置１２１やハードディスク装置１３３が提供する記憶領域として実現される。なお、制御部１２３、メール表示部１２４、メール受信部１２５、メール送信部１２６、およびメールデータ記憶部１３１は、一般的なＭＵＡの機能である。== Software ==
FIG. 3 is a diagram showing a functional configuration of the mail system according to the present embodiment.
The
The
制御部１２３は、メール表示部１２４、メール受信部１２５、メール送信部１２６の制御を行う。 The
ユーザが入出力装置１３２において電子メールの送信を指示するコマンドを入力した場合、制御部１２３は、ユーザが入出力装置１３２において入力した電子メールの内容（以下、メールデータという。）を、入出力インタフェース１３０を介して受け付ける。制御部１２３は、受け付けたメールデータをメール送信部１２６に渡す。メール送信部１２６は制御部１２３から受け取ったメールデータを記述した電子メールを作成し、作成した電子メールを、通信インタフェース１２８を介してメールサーバ１０に送信する。なお、メール送信部１２６は、ＳＭＴＰに規定される電子メールの送信要求として電子メールを送信する。 When the user inputs a command for instructing transmission of an e-mail in the input /
ユーザが入出力装置１３２において電子メールの受信を指示するコマンドを入力した場合、制御部１２３は、ユーザが入出力装置１３２において入力した、ユーザを特定するユーザＩＤやパスワードを、入出力インタフェース１３０を介して受け付ける。なお、ユーザＩＤやパスワードは、主記憶装置１２１やハードディスク装置１３３などに予め記憶しておくようにしてもよい。制御部１２３は、ユーザＩＤおよびパスワードをメール受信部１２５に渡す。メール受信部１２５は、ユーザＩＤおよびパスワードを設定したメール取得要求をメールサーバ１０に送信し、メールサーバ１０がメール取得要求に応じて送信する電子メールを受信して、受信した電子メールをメールデータとして、ディスクインタフェース１２９を介してメールデータ記憶部１３１に記憶する。 When the user inputs a command for instructing the reception of the e-mail at the input /
ユーザが入出力装置１３２において電子メールの表示を指示するコマンド（以下、メール表示要求という。）を入力した場合、制御部１２３は、メール表示要求をメール表示部１２４に通知する。メール表示部１２４は、メールデータ記憶部１３１からメールデータを読み出し、読み出したメールデータを、入出力インタフェース１３０を介して入出力装置１３２に渡して、入出力装置１３２が受け取ったメールデータを出力する。これにより、ユーザは電子メールの内容を閲覧することができる。なお、電子メールの受信を指示するコマンドを受け付けた場合に、電子メールの受信と表示との両方の処理を行ってもよい。 When the user inputs a command (hereinafter referred to as a mail display request) for instructing to display an e-mail in the input /
メールサーバ１０は、制御部１０３、メール受付部１０４、メール送信部１０５、承認処理部１０６、監視処理部１０７、メールボックス１１１、承認者テーブル１１２、承認待ちテーブル１１３、および送信待ちキュー１１４を備えている。 The
制御部１０３、メール受付部１０４、メール送信部１０５、承認処理部１０６、および監視処理部１０７（本発明のタイムアウト監視部に該当する。）は、メールサーバ１０が備えるＣＰＵ１０８が、主記憶装置１０１に記憶されるサーバプログラム１０２を実行することにより実現される。メールボックス１１１、承認者テーブル１１２、承認待ちテーブル１１３、および送信待ちキュー１１４は、メールサーバ１０が備える主記憶装置１０１やハードディスク装置１１４が提供する記憶領域として実現される。 The
メール送信部１０５（本発明の電子メール送信部に該当する。）は、電子メールの配送を行う。メール送信部１０５は、電子メールの宛先がドメインユーザアドレスまたは承認者アドレスである場合には、宛先のメールアドレスに対応付けてメールボックス１１１に電子メールを格納し、宛先がそれ以外のアドレスである場合には、他のＭＴＡや中継サーバなどに電子メールを転送することにより、電子メールの配送を行う。 The mail transmission unit 105 (corresponding to the electronic mail transmission unit of the present invention) delivers electronic mail. When the destination of the email is a domain user address or an approver address, the
メール受付部１０４（本発明の電子メール受信部に該当する。）は、通信ネットワーク１４０を介して、ユーザ端末２０や承認者端末３０、他のＭＴＡ、中継サーバなどから送信される電子メールを受信する。メール受付部１０４は電子メールを受信すると、電子メールを受け付けた旨を制御部１０３に通知する。 The mail reception unit 104 (corresponding to the electronic mail reception unit of the present invention) receives an electronic mail transmitted from the
制御部１０３は、メールを受け付けた旨の通知（受付通知）を検知し、承認処理部１０６に、メール受付部１０４が受信した電子メールを渡す。 The
承認処理部１０６は、制御部１０３から受け取った電子メール（以下、受信メールという。）を解析し、この受信メールの配送に承認が必要であるかどうかを判定する。承認が必要であるか否かは、受信メールの送信先に設定されているメールアドレスが、ドメインユーザアドレスであるか否か、および、受信メールの送信者に対応する承認者が登録されているか否かに応じて判断される。 The
送信者に対応する承認者は承認者テーブル１１２に登録される。図４は、承認者テーブル１１２の構成例を示す図である。同図に示すように、承認者テーブル１１２は、送信者のメールアドレス８１１に対応付けて、承認者アドレス８１２を記憶している。 The approver corresponding to the sender is registered in the approver table 112. FIG. 4 is a diagram illustrating a configuration example of the approver table 112. As shown in the figure, the approver table 112 stores an
本実施形態では、承認処理部１０６は、電子メールの送信先がドメインユーザである場合か、送信者に対応する承認者が承認者テーブル１１２に登録されていない場合に、受信メールの承認は不要と判定する。 In this embodiment, the
承認処理部１０６が受信メールについて承認不要と判断した場合、メール送信部１０５は、受信メールの配送を行う。 When the
承認処理部１０６は、承認が必要であると判断した受信メール（以下、配送メールという。）を送信待ちキュー１１４に格納する。 The
図５は、受信メール９００の構成例を説明する図である。配送メール９００は、エンベロープ情報９０１、ヘッダ部９０２およびボディ部９０３により構成されている。図４の例では、配送メール９００のボディ部９０３には、本文９０４が含まれている。 FIG. 5 is a diagram for explaining a configuration example of the received
エンベロープ情報９０１は、ＳＭＴＰでやりとりされる際に電子メールに付帯される情報であり、電子メールの送信元（エンベロープＦｒｏｍ）と送信先（エンベロープＴｏ）とが記述される。
ヘッダ部９０２およびボディ部９０３は、メールサーバ１０においてメールボックス１１１に記憶される情報であり、ユーザ端末２０および承認者端末３０においてメールデータ記憶部１３１に登録され、メール表示部１２４により出力される情報である。ヘッダ部９０２にも、送信元（Ｆｒｏｍ）と送信先（Ｔｏ）とが設定されるが、ＭＴＡにおいて送信元とエンベロープＴｏとが異なり、あるいは送信先とエンベロープＴｏとが異なるように書き換わることもある。ヘッダ部９０２には、題名（Ｓｕｂｊｅｃｔ）など各種のフィールドが含まれる。ボディ部９０３には、本文９０４や添付ファイルなど、電子メールの内容となる各種の情報が記述される。 The
図６は、送信待ちキュー１１４（本発明の電子メール記憶部に該当する。）の構成例を示す図である。送信待ちキュー１１４に格納される配送メールには識別情報（以下、キューＩＤという。）が割り当てられる。本実施形態では、送信待ちキュー１１４は、ファイルシステムにおけるディレクトリとして実現され、送信待ちキュー１１４には、配送メールがキューＩＤをファイル名としたファイルとして格納されるものとする。 FIG. 6 is a diagram showing a configuration example of the transmission waiting queue 114 (corresponding to the electronic mail storage unit of the present invention). Identification information (hereinafter referred to as queue ID) is assigned to the delivery mail stored in the
承認処理部１０６は、送信待ちキュー１１４に格納した配送メールについて、承認者に承認依頼メールを送信し、承認待ちの状態になった配送メールに関する情報（以下、承認待ち情報という。）を承認待ちテーブル１１３に登録する。 The
図７は、承認待ちテーブル１１３に登録される承認待ち情報の構成例を示す図である。同図に示すように、承認待ち情報は、承認依頼メールの識別情報（メッセージＩＤ；Message-ID）８０１に対応付けて、配送メールのキューＩＤ８０２、配送メールの送信者８０３、承認者アドレス８０４、および、承認待ち情報を登録した日時（受付日時）８０５を含んでいる。承認待ちテーブル１１３に登録されているキューＩＤが示す配送メールは、承認者による承認を待っている状態であることを示す。 FIG. 7 is a diagram illustrating a configuration example of approval waiting information registered in the approval waiting table 113. As shown in the figure, approval waiting information is associated with identification information (message ID; Message-ID) 801 of an approval request mail, a delivery
承認処理部１０６は、承認者からの返信メールに応じて、承認されたか否かを判定する。なお、承認処理部１０６による配送メールの承認処理の詳細については後述する。 The
承認処理部１０６が配送メールについて配送が承認されたと判定した場合には、メール送信部１０５は、配送メールを配送する。 When the
承認待ちテーブル１１３に登録された承認待ち情報は、登録されてから所定時間経過後に監視処理部１０７により削除される。図８は、監視処理部１０７による承認待ち情報の監視処理の流れを示す図である。 The approval waiting information registered in the approval waiting table 113 is deleted by the
監視処理部１０７は、登録から所定時間（例えば、３時間や６時間、２４時間など、任意に設定できるものとする。）経過した承認待ち情報、すなわち、受付日時から所定時間後の日時よりも現在日時が後になるものを、承認待ちテーブル１１３から取得し（ステップ７００）、取得した承認待ち情報のそれぞれについて以下の処理を行う（ステップ７０１）。 The
監視処理部１０７は、承認待ち情報の送信者８０３を宛先として、所定時間内に承認がなかった旨のメッセージを本文として設定した電子メールを作成し、メール送信部１０５が、この電子メールを配送する（ステップ７０２）。 The
また、監視処理部１０７は、承認待ち情報の承認者８０４を宛先として、承認依頼メールへの回答がなかった旨のメッセージを本文として設定した電子メールを作成し、メール送信部１０５が、この電子メールを配送する（ステップ７０３）。 In addition, the
監視処理部１０７は、承認待ち情報のキューＩＤ８０２が示すファイルを送信待ちキュー１１４から削除し（ステップ７０４）、承認待ち情報を承認待ちテーブル１１３から削除する（ステップ７０５）。 The
監視処理部１０７が以上の処理を繰り返して、登録から所定時間を経過した承認待ち情報を削除する。 The
＝＝承認処理＝＝
図９は、承認処理部１０６の詳細構成を示す図である。承認処理部１０６は、承認結果判定処理部２００、承認判定処理部２０１、承認依頼メール作成処理部２０２、および通知メール作成処理部２０３を備えている。== Approval processing ==
FIG. 9 is a diagram illustrating a detailed configuration of the
承認結果判定処理部２００（本発明の返信メール取得部および承認判定部に該当する。）は、受信メールと承認待ちテーブル１１３の承認待ち情報とを比較して、受信メールが返信メールであるか否かを判定し、受信メールが返信メールであると判断した場合は、承認の結果を通知メール作成処理部２０３に渡す。通知メール作成処理部２０３（本発明の第１および第２のエラー通知部に該当する。）は、承認の結果を通知する電子メールを作成し、メール送信部１０５がその電子メールを配送する。 The approval result determination processing unit 200 (corresponding to the reply mail acquisition unit and the approval determination unit of the present invention) compares the received mail with the approval waiting information in the approval waiting table 113, and determines whether the received mail is a reply mail. If it is determined that the received mail is a reply mail, the approval result is passed to the notification mail
承認結果判定処理部２００が、受信メールが承認者からの返信メールではないと判断した場合には、承認依頼判定処理部２０１が、受信メールについて承認が必要であるか否かを判断する。承認依頼判定処理部２０１は、承認必要と判断した場合、受信メールを配送メールとして送信待ちキュー１１４に格納するとともに、承認待ちテーブル１１３へ承認待ち情報を登録する。 If the approval result
さらに承認依頼判定処理部２０１は、配送メールの送信者に対応する承認者アドレスを承認者テーブル１１２から取得し、取得した承認者アドレスを承認依頼メール作成処理部２０２に渡す。Further, the approval request
承認依頼メール作成部２０２（本発明の承認依頼メール送信部に該当する。）は、受け取った承認者アドレスを宛先とした承認依頼メールを作成し、メール送信部１０５は、承認依頼メールを配送する。 The approval request mail creation unit 202 (corresponding to the approval request mail transmission unit of the present invention) creates an approval request mail with the received approver address as a destination, and the
承認依頼判定処理部２０１は、受信メールが承認不要と判断した場合には、受信メールをメール送信部１０５に渡し、メール送信部１０５が受信メールを配送する。 If the approval request
以下、承認処理部１０６による承認処理について詳述する。
図１０は、承認結果判定処理部２００が、受信メールの宛先に応じて、受信メールが承認者からの返信メールであるか否かを判定する処理の流れを示す図である。Hereinafter, the approval processing by the
FIG. 10 is a diagram showing a flow of processing in which the approval result
承認結果判定処理部２００は、受信メールのエンベロープ情報に含まれている宛先（エンベロープＴｏ）がなくなるまでステップ３０２の処理を繰り返す（ステップ３００）。 The approval result
承認結果判定処理部２００は、エンベロープＴｏに設定されている宛先のメールアドレス（以下、受信者アドレスという。）を取得し（ステップ３０１）、取得した受信者アドレスが第１の管理者アドレス（admin01@domain1）であるか否かを判定する（ステップ３０２；承認回答判定部）。 The approval result
受信者アドレスが第１の管理者アドレスであれば（ステップ３０２：ＹＥＳ）、受信メールは承認者からの返信メールと判定され、承認結果判定処理部２００は後述の図１９のステップ３２０に進み、承認者による承認結果に応じた処理を行う。 If the receiver address is the first administrator address (step 302: YES), the received mail is determined as a reply mail from the approver, and the approval result
一方、すべての受信者アドレスが第１の管理者アドレスでなければ（ステップ３０２：ＮＯ）、図１１のステップ３１０に進む。
図１１は、承認結果判定処理部２００が受信メールの解析を行い、受信メールがどのような電子メールであるのかを判定する処理の流れを示す図である。
承認結果判定処理部２００は、受信メールに含まれるReferencesヘッダからMessage-IDを取得する（ステップ３１０；返信先取得部）。承認結果判定処理部２００は、ReferenceヘッダからMessage-IDを取得できた場合（ステップ３１１：ＹＥＳ）、取得したMessage-IDが承認待ちテーブル１１３に登録されているか否かを判定し（ステップ３１２）、登録されていれば（ステップ３１２：ＹＥＳ）、後述のステップ３１７に進み、登録されていなければ（ステップ３１２：ＮＯ）、ステップ３１３に進む。On the other hand, if all the recipient addresses are not the first administrator address (step 302: NO), the process proceeds to step 310 in FIG.
FIG. 11 is a diagram illustrating a flow of processing in which the approval result
The approval result
承認結果判定処理部２００は、ReferencesヘッダからMessage-IDを取得できなかった場合（ステップ３１１：ＮＯ）または、取得したMessage-IDが承認待ちテーブル１１３に登録されていなかった場合（ステップ３１２：ＮＯ）には、受信メールのヘッダ情報に含まれるIn-Reply-ToヘッダからMessage-IDを取得する。 The approval result
承認結果判定処理部２００は、In-Reply-ToヘッダからMessage-IDを取得できた場合（ステップ３１４：ＹＥＳ）、取得したMessage-IDが承認待ちテーブル１１３に登録されているか否かを判定する（ステップ３１５）。 The approval result
承認結果判定処理部２００は、In-Reply-Toヘッダにも、承認依頼メールのMessage-IDが設定されていない場合（ステップ３１５：ＮＯ）、には、図１２に示す承認依頼判定処理部２０１による処理が行われる（ステップ３１６）。 If the Message-ID of the approval request mail is not set in the In-Reply-To header (step 315: NO), the approval result
図１２は、承認依頼判定処理部２０１が受信メールの解析を行い、受信メールに承認が必要か否かの判定を行う処理の流れを示す図である。
承認依頼判定処理部２０１は、受信メールのエンベロープ情報に含まれるエンベロープＴｏがなくなるまで以下の処理を繰り返す（ステップ４００）。
承認依頼判定処理部２０１は、受信メールのエンベロープ情報に含まれるエンベロープＴｏに設定されている受信者アドレスを取得し（ステップ４０１）、取得した受信者アドレスが所属するドメインが、「domain1」および「domain2」のいずれでもないか否かにより、承認が必要か否かを判定する（ステップ４０２；承認要否決定部）。なお、受信者アドレスに応じて承認が必要か否かを判断することに限らず、本文や添付ファイルの内容などに応じて承認が必要か否かを判断するようにしてもよい。FIG. 12 is a diagram illustrating a flow of processing in which the approval request
The approval request
The approval request
承認依頼判定処理部２０１は、すべての受信者アドレスについて承認が不要と判断した場合には（ステップ４０２：ＹＥＳ）、受信メールをメール送信部１０５に渡し、メール送信部１０５が受信メールを配送する（ステップ４０３）。 If the approval request
一方、承認依頼判定処理部２０１は、受信者アドレスのいずれかについて承認が必要と判断した場合には（ステップ４０２：ＮＯ）、エンベロープ情報から送信元（エンベロープＦｒｏｍ）のメールアドレス（以下、送信者アドレスとう。）を取得し（ステップ４０４）、送信者アドレスに対応する承認者アドレスを承認者テーブル１１２から検索する。 On the other hand, if the approval request
承認依頼判定処理部２０１は、送信者アドレスに対応する承認者アドレスが見つからなかった場合には（ステップ４０５：ＮＯ）、受信メールの承認は不要として、受信メールをメール送信部１０５に渡し、メール送信部１０５が受信メールを配送する（ステップ４０６）。なお、ステップ４０２において承認が必要と判定された場合には、ステップ４０５における判定処理を行わずに、ステップ４０７に進むようにしてもよいし、受信メールの送信者やメールシステムの管理者宛てに、承認者テーブル１１２に承認者が設定されていない旨を示す電子メールを送信するようにしてもよい。 If the approver address corresponding to the sender address is not found (step 405: NO), the approval request
一方、送信者アドレスに対応する承認者アドレスが見つかった場合には（ステップ４０５：ＹＥＳ）、承認が必要と判断され、図１３に示す承認依頼メール作成処理部の処理が行われる。 On the other hand, if an approver address corresponding to the sender address is found (step 405: YES), it is determined that approval is required, and the processing of the approval request mail creation processing unit shown in FIG. 13 is performed.
図１３は、承認依頼メール作成処理部２０２による承認依頼メールの作成処理の流れを説明する図である。
承認依頼メール作成処理部２０２は、受信メールにユニークなキューＩＤを割り当て、割り当てたキューＩＤをファイル名にして受信メールを配送メールとして送信待ちキュー１１４に格納する（ステップ５００）。FIG. 13 is a diagram for explaining the flow of an approval request mail creation process by the approval request mail
The approval request mail
承認依頼メール作成処理部２０２は、承認依頼判定処理部２０１がステップ４０５で取得した承認者アドレスをヘッダのＴｏフィールドに設定し、第１の管理アドレス（admin01@domain1）をヘッダのＦｒｏｍフィールドに設定し、第２の管理アドレス（admin02@domain1）をヘッダのＣｃフィールドに設定し、ユニークなMessage-IDを生成してヘッダに設定した承認依頼メールを新規に作成する（ステップ５０１）。 The approval request mail
図１４は、承認依頼メール作成処理部２０２が作成する承認依頼メール９１０の構成例を示す図である。承認依頼メール９１０も、通常の電子メールと同じくエンベロープ情報９１１、ヘッダ部９１２、およびボディ部９１３から構成される。 FIG. 14 is a diagram illustrating a configuration example of an
エンベロープ情報９１１に含まれるエンベロープＦｒｏｍには、第１の管理者アドレス（admin01@domain1）が設定される。承認依頼メール９１０の配送時にエラーが発生した場合には、第１の管理者アドレス宛に承認依頼メール９１０が転送される。エンベロープ情報９１１に含まれるエンベロープＴｏには、承認依頼判定処理部２０１がステップ４０５で取得した、送信者アドレス（aaa@domain1）に対応する承認者アドレス（zzz@domain1）が設定される。 A first administrator address (admin01 @ domain1) is set in the envelope From included in the
ヘッダ部９１２には、承認依頼メール９１０の識別情報であるMessage-IDや、送信元（Ｆｒｏｍ）フィールド、宛先（Ｔｏ）フィールド、カーボンコピー（Ｃｃ）フィールドなどが含まれる。Message-IDは、一般ユーザに容易に推測されないように、例えば、乱数などを用いて作成する。 The
Ｆｒｏｍフィールドには、上記エンベロープＦｒｏｍと同様に、第１の管理者アドレス（admin01@domain1）が設定される。したがって、承認者がこの承認依頼メール９１０に対して返信をした場合には、宛先に第１の管理者アドレスが含まれることになり、上述したように、図１０の処理において、Ｆｒｏｍフィールドに第１の管理者アドレスが設定されているか否かにより、メールサーバ１０が受信した電子メールが承認者からの返信メールであるか否かが判定される。 In the From field, a first administrator address (admin01 @ domain1) is set as in the envelope From. Therefore, when the approver replies to this
Ｔｏフィールドには、エンベロープＴｏと同じく、承認者アドレス（zzz@domain1）が設定される。 As in the envelope To, the approver address (zzz @ domain1) is set in the To field.
Ｃｃフィールドには、第２の管理者アドレス（admin02@domain1）が設定される。承認者がＭＵＡの「全員に返信」機能を用いて承認依頼メールに対して返信を行った場合には、Ｃｃフィールドに設定されていた第２の管理者アドレスも、返信メールのＴｏフィールドあるいはＣｃフィールドに設定される。後述するように、本実施形態のメールサーバ１０は、承認者からの返信メールの宛先（ＴｏフィールドおよびＣｃフィールド）に第１の管理者アドレスのみが設定されている場合には「非承認」、宛先に第１および第２の管理者アドレスの両方が設定されている場合には「承認」と判定する。 A second administrator address (admin02 @ domain1) is set in the Cc field. When the approver sends a reply to the approval request mail using the “reply to all” function of the MUA, the second administrator address set in the Cc field is also the To field or Cc of the reply mail. Set to the field. As will be described later, the
なお、第２の管理者アドレスは、「admin02@domain1」に限らず、例えば、承認者が「承認」の返信を行うことが容易に確認できるような名称、例えば「SYOUNIN.OK@domain」のようにしてもよい。これにより、承認者は、「承認」とする結果を返信しようとしていることをＭＵＡにおいて容易に確認することができるので、承認者の作業ミスを減らすことができる。
件名（Subject）フィールドには、承認者に対して承認依頼要求が来ていることがわかるような文字列を設定することが望ましい。The second administrator address is not limited to “admin02 @ domain1”. For example, a name that can be easily confirmed by the approver to reply “approval”, for example, “SYOUNIN.OK@domain”. You may do it. Thereby, since the approver can easily confirm in the MUA that the result of “approval” is to be returned, the work mistake of the approver can be reduced.
In the subject field, it is desirable to set a character string so that an approval request request is received from the approver.
ボディ部９１３には、本文９１４および添付ファイル９１５が含まれる。
本文９１４には、承認者に承認依頼が来ていることを示すメッセージと、承認の対象となる配送メールのエンベロープ情報とが記載される。また、本文９１４には、配送を承認する場合は「全員へ返信」により返信を行い、非承認とする場合は「返信」により返信を行うように指示するインストラクションを記述する。これにより承認者の作業ミスを減らすことができる。The
The
添付ファイル９１５は、承認の対象となる配送メールである。このように承認が必要となった配送メール自体を添付することで、承認者がその電子メールの本文の内容や添付ファイル、宛先のメールアドレスなどを確認することができる。 The attached
図１１に戻り、Referencesヘッダに含まれるMessage-IDが承認待ちテーブル１１３に登録されている場合（ステップ３１２：ＹＥＳ）またはIn-Reply-Toに含まれるMessage-IDが承認待ちテーブル１１３に登録されている場合（ステップ３１５：ＹＥＳ）には、第１の管理者アドレスが設定されていないにも関わらず、承認依頼メールへの返信として送信された電子メールが受信されたことになる。例えば、承認者がＭＵＡにおいて返信の操作をした際に、第１の管理者アドレスを宛先から除外してしまったような場合に、このような電子メールが受信されることになる。承認結果判定処理部２００は、不正な電子メールを受信したと判定し（ステップ３１７）、図１５に示す、通知メール作成処理部２０３によるエラー処理が行われる（ステップ３１８）。 Returning to FIG. 11, when the Message-ID included in the References header is registered in the approval waiting table 113 (step 312: YES), or the Message-ID included in In-Reply-To is registered in the approval waiting table 113. If yes (step 315: YES), the electronic mail transmitted as a reply to the approval request mail is received even though the first administrator address is not set. For example, when the approver performs a reply operation in the MUA, such e-mail is received when the first administrator address is excluded from the destination. The approval result
図１５は、通知メール作成処理部２０３によるエラー処理の流れを示す図である。
通知メール作成処理部２０３は、承認待ちテーブル１１３から、承認結果判定処理部２００が上記図１１のステップ３１０またはステップ３１３で取得したMessage-IDに対応する承認待ち情報を取得する（ステップ６００）。通知メール作成処理部２０３は、承認待ち情報の送信者８０３を宛先として、エラーが発生した旨を示すメッセージを含む電子メール（以下、エラーメールという。）を送信する（ステップ６０１）。FIG. 15 is a diagram showing a flow of error processing by the notification mail
The notification mail
図１６は、通知メール作成処理部２０３が作成するエラーメール９４０の構成例を示す図である。エラーメール９４０には、エンベロープ情報９４１、ヘッダ部９４２、ボディ部９４３が含まれる。エンベロープ情報９４１に含まれるエンベロープＦｒｏｍには、第１の管理者アドレス（admin01@domain1）が設定される。エンベロープＴｏには、承認待ち情報のキューＩＤ８０２が示すファイルに格納されている配送メールの送信者（承認待ち情報の送信者８０３）が設定される。ヘッダ部９４２に含まれる件名（Ｓｕｂｊｅｃｔ）フィールドには、エラーが発生した旨の示す文字列が記載される。ボディ部９４３にふくまれる本文９４４には、どのようなメールアドレスを宛先とした配送メールに対しての承認が失敗したかを示すメッセージや、配送メールの件名、送信日時などを記載する。添付ファイル９４５は、配送メールである。これにより、配送メールの送信者は、エラーが発生した電子メールを容易に確認することができる。FIG. 16 is a diagram illustrating a configuration example of the
次に通知メール作成処理部２０３は、承認待ち情報のキューＩＤ８０２が示すファイルを送信待ちキュー１１４から削除し（ステップ６０２）、承認待ち情報を承認待ちテーブル１１３から削除する（ステップ６０３）。すなわち、承認待ち状態であった配送メールが破棄されたことになる。 Next, the notification mail
以上のようにして、承認依頼メール９１０が承認者に配送されると、承認者は配送メールの配送の承認、非承認を判断する。 As described above, when the
承認者は、配送を非承認とする場合には、ＭＵＡの「返信」機能を用いて、承認依頼メール９１０のＦｒｏｍフィールドに設定されていた第１の管理者アドレス（admin01@domain1）のみを宛先とした返信メールをメールサーバ１０に送信する。非承認を表す返信メール９２０の構成例を図１７に示す。非承認の返信メール９２０には、エンベロープ情報９２１、ヘッダ部９２２、およびボディ部９２３が含まれ、エンベロープ情報９２１に含まれるエンベロープＦｒｏｍには承認者アドレスが設定され、エンベロープＴｏには、第１の管理者アドレス（admin01@domain1）のみ設定される。また、ヘッダ部９３１に含まれるReferencesヘッダ（またはIn-Reply-Toヘッダ）には承認依頼メール９１０のMessage-IDが設定される。これによりメールサーバ１０は、返信メール９２０が承認依頼メール９１０に対する返信と判断することができる。なお、承認者は、非承認とする理由を入力し、入力した理由をボディ部９２３に含まれる本文９２４として設定するようにしてもよい。この場合、送信者が非承認の理由を知ることができる。なお、ここで承認者は、送信者を宛先やカーボンコピーに追加するようにしてもよい。これにより、非承認の理由を直接送信者に送信することができる。 When the approver disapproves the delivery, only the first administrator address (admin01 @ domain1) set in the From field of the
一方、承認者が配送を承認する場合には、ＭＵＡの「全員に返信」機能を用いて、承認依頼メール９１０のＦｒｏｍフィールドおよびＣｃフィールドに設定されていた第１および第２の管理者アドレス（admin01@domain1およびadmin02@domain1）を宛先として設定した返信メールを返信する。承認を表す返信メール９３０の構成例を図１８に示す。返信メール９３０には、エンベロープ情報９３１、ヘッダ部９３２、およびボディ部９３３が含まれる。エンベロープ情報９３１に含まれるエンベロープＦｒｏｍには承認者アドレスが設定され、エンベロープＴｏには第１の管理者アドレス（admin01@domain1）および第２の管理者アドレス（admin02@domain1）の両方が設定される。ヘッダ部９３２に含まれるReferencesヘッダ（またはIn-Reply-Toヘッダ）には、承認依頼メール９１０のMessage-IDが設定される。これによりメールサーバ１０は、返信メール９３０が承認依頼メール９１０に対する返信であることを判断することができる。 On the other hand, when the approver approves the delivery, the first and second administrator addresses (set in the From field and Cc field of the
ここで図１０に戻り、受信メールの受信者アドレスに第１の管理者アドレスが含まれていた場合には（ステップ３０２：ＹＥＳ）、受信メールは承認者からの返信メールとして、図１９のステップ３２０に進む。
図１９は、承認結果判定処理部２００が返信メールの解析を行い、返信メールがどのようなメールであるのかを判定する処理の流れを示す図である。
承認結果判定処理部２００は、返信メールに含まれるReferencesヘッダからMessage-IDを取得する（ステップ３２０）。承認結果判定処理部２００は、ReferenceヘッダからMessage-IDを取得できた場合（ステップ３２１：ＹＥＳ）、取得したMessage-IDが承認待ちテーブル１１３に登録されているか否かを判定する（ステップ３２２）。Returning to FIG. 10, when the first administrator address is included in the recipient address of the received mail (step 302: YES), the received mail is used as a reply mail from the approver, and the step of FIG. Proceed to 320.
FIG. 19 is a diagram illustrating a flow of processing in which the approval result
The approval result
承認結果判定処理部２００は、ReferencesヘッダからMessage-IDを取得できなかった場合（ステップ３２１：ＮＯ）または、取得したMessage-IDが承認待ちテーブル１１３に登録されていなかった場合（ステップ３２２：ＮＯ）には、返信メールに含まれるIn-Reply-ToヘッダからMessage-IDを取得する（ステップ３２３）。 The approval result
承認結果判定処理部２００は、In-Reply-ToヘッダからMessage-IDを取得できた場合（ステップ３２４：ＹＥＳ）、取得したMessage-IDが承認待ちテーブル１１３に登録されているか否かを判定する（ステップ３２５）。 The approval result
承認結果判定処理部２００は、In-Reply-ToヘッダからもMessage-IDを取得できなかった場合（ステップ３２４：ＮＯ）、すなわち、返信メールの宛先に第１の管理者アドレスが設定されていたにも関わらず、返信メールの返信先を取得できなかった場合、または、In-Reply-Toヘッダから取得したMessage-IDが承認待ちテーブル１１３に登録されていない場合（ステップ３２５：ＮＯ）、すなわち、返信先の承認依頼メールに対応する配送メールが存在しない場合には、不正な返信メールを取得したと判定して、当該返信メールを破棄して処理を終了する（ステップ３２６）。なお、返信先の承認依頼メールに対応する配送メールが存在しない場合とは、例えば、監視処理部１０７により、所定時間内に承認、非承認の判定がなされなかった配送メールおよび対応する承認待ち情報が削除された場合である。If the approval result
承認結果判定処理部２００は、ReferencesヘッダまたはIn-Reply-Toヘッダから取得したMessage-IDが承認待ちテーブル１１３に登録されている場合（ステップ３２２：ＹＥＳまたはステップ３２５：ＹＥＳ）、取得したMessage-IDに対応する承認者８０４を承認待ちテーブル１１３から取得し（ステップ３２７）、図２０のステップ３３０に進む。 If the Message-ID acquired from the References header or the In-Reply-To header is registered in the approval waiting table 113 (step 322: YES or step 325: YES), the approval result
図２０は、承認結果判定処理部２００が返信メールの解析を行い、承認または非承認の判定を行う処理の流れを示す図である。
承認結果判定処理部２００は、返信メールのエンベロープ情報から送信元（エンベロープＦｒｏｍ）の送信者アドレスを取得する（ステップ３３０）。承認結果判定処理部２００は、取得した送信者アドレスと、図１９のステップ３２７で取得した承認者アドレスとを比較する（ステップ３３１）。これらが一致しなければ（ステップ３３１：ＮＯ）、上述した図１５の通知メール作成処理部２０３によるエラー処理が行われる（ステップ３３２）。FIG. 20 is a diagram illustrating a flow of processing in which the approval result
The approval result
承認結果判定処理部２００は、返信メールのエンベロープ情報に含まれているエンベロープＴｏがなくなるまで、ステップ３３４およびステップ３３５の処理を繰り返す（ステップ３３３）。 The approval result
承認結果判定処理部２００は、返信メールのエンベロープ情報に含まれるエンベロープＴｏから受信者アドレスを取得し（ステップ３３４）、取得した受信者アドレスが第２の管理者アドレス（admin02@domain1）と一致するか否かを判定する（ステップ３３５）。 The approval result
エンベロープＴｏに第２の管理者アドレスが含まれていない場合には（ステップ３３５：ＮＯ）、図２１に示す通知メール作成処理部２０３による非承認処理が行われる（ステップ３３６）。 When the second administrator address is not included in the envelope To (step 335: NO), non-approval processing by the notification mail
図２１は、通知メール作成処理部２０３による非承認処理の流れを示す図である。
通知メール作成処理部２０３は、上記図１９の処理において承認結果判定処理部２００が取得したMessage-IDに対応する承認待ち情報を、承認待ちテーブル１１３から取得する（ステップ６１０）。通知メール作成処理部２０３は、承認待ち情報の送信者８０３を宛先として、配送メールが非承認であった旨を示すメッセージを含む電子メール（以下、非承認メールという。）を送信し（ステップ６１１）、承認待ち情報を承認待ちテーブル１１３から削除する（ステップ６１２、６１３）。FIG. 21 is a diagram showing the flow of non-approval processing by the notification mail
The notification mail
上記非承認処理により作成される非承認メール９５０の構成例を図２２に示す。
非承認メール９５０は、エンベロープ情報９５１、ヘッダ部９５２およびボディ部９５３を含んでいる。エンベロープ情報９５１に含まれるエンベロープＦｒｏｍには、第１の管理者アドレス（admin01@domain1）が設定される。エンベロープＴｏには、承認待ち情報のキューＩＤ８０２が示すファイル名に格納されている配送メールの送信元（Ｆｒｏｍフィールドに設定されているメールアドレス）を設定する。
ヘッダ部９５２に含まれる件名フィールドには、送信者が承認結果をすぐに認識できるように「非承認」である旨を記載する。
ボディ部９５３に含まれる本文９２４には、配送メールの宛先や、件名、送信日時など、送信者が配送メールを特定しやすい情報を記述する。また、承認者からの返信メールの本文に非承認とした理由が含まれている場合には、その理由を本文９２４にも記載するようにする。また、返信メールを添付ファイルとしてボディ部９５３に含めるようにしてもよい。さらに、配送メールを添付ファイルとしてボディ部９５３に含めるようにしてもよい。これによりどのような内容の配送メールが非承認とされたのかを送信者が容易に把握することができる。A configuration example of the
The
The subject field included in the
In the
一方、図２０の処理において、返信メールのエンベロープＴｏに第２の管理者アドレスが含まれていた場合には（ステップ３３５：ＹＥＳ）、図２３に示す、通知メール作成処理部２０３による承認処理が行われる（ステップ３３７）。 On the other hand, in the process of FIG. 20, when the second administrator address is included in the envelope To of the reply mail (step 335: YES), the approval
図２３は、通知メール作成処理部２０３による承認処理の流れを示す図である。
通知メール作成処理部２０３は、上記図１９の処理において承認結果判定処理部２００が取得したMessage-IDに対応する承認待ち情報を、承認待ちテーブル１１３から取得する（ステップ６２０）。通知メール作成処理部２０３は、承認待ち情報の送信者８０３を宛先として、配送メールが承認された旨を示すメッセージを含む電子メール（以下、承認メールという。）を送信し（ステップ６２１）、承認待ち情報のキューＩＤ８０２をメール送信部１０５に通知して、メール送信部１０５は、キューＩＤが示すファイルに格納されている配送メールを配送する（ステップ６２２）。通知メール作成処理部２０３は、承認待ち情報を承認待ちテーブル１１３から削除する（ステップ６２３）。
図２３の承認処理において作成される承認メール９６０の構成例を図２４に示す。FIG. 23 is a diagram showing the flow of approval processing by the notification mail
The notification mail
A configuration example of the
承認メール９６０は、エンベロープ情報９６１、ヘッダ部９６２およびボディ部９６３を含んでいる。エンベロープ情報９６１に含まれるエンベロープＦｒｏｍには、第１の管理者アドレス（admin01@domain1）が設定される。エンベロープＴｏには、承認待ち情報のキューＩＤ８０２が示すファイル名に格納されている配送メールの送信元（Ｆｒｏｍフィールドに設定されているメールアドレス）を設定する。
ヘッダ部９６２に含まれる件名フィールドには、送信者が承認結果をすぐに認識できるように「承認」の旨を記載する。
ボディ部９６３に含まれる本文９６４には、配送メールの宛先や、件名、送信日時など、送信者が配送メールを特定しやすい情報を記述する。また、返信メールを添付ファイルとしてボディ部９６３に含めるようにしてもよい。The
The subject field included in the
The
以上説明したように、本実施形態のメールシステムによれば、承認者からの返信メールの宛先に、第１および第２の管理アドレスが含まれている場合には承認と判定し、返信メールの宛先に第１の管理アドレスのみが含まれている場合には非承認と判定することができる。一般的なＭＵＡでは、送信者（Reply-Toヘッダがある場合はそのメールアドレス、ない場合はFromヘッダのメールアドレス）にのみ返信する「返信」機能と、送信者と同報者（ToヘッダやCcヘッダのメールアドレス）のすべてに返信する「全員に返信」機能とが提供されているので、承認者は、一般的なＭＵＡを用いて、承認する場合には、承認依頼メールに対して「全員に返信」機能を用いて返信し、非承認とする場合には、承認依頼メールに対して「返信」機能を用いて返信すればよい。したがって、一般的なＭＵＡが備える「全員に返信」および「返信」の機能を利用して、承認者が承認および非承認の指定を容易に行うことができる。 As described above, according to the mail system of this embodiment, when the first and second management addresses are included in the reply mail address from the approver, it is determined as approval, and the reply mail When only the first management address is included in the destination, it can be determined as non-approved. In a general MUA, a “reply” function that sends a reply only to the sender (if there is a Reply-To header, its email address, if not, the email address in the From header), and the sender and the broadcaster (To header or “Reply to all” function is provided for replying to all of the email addresses in the Cc header). When an approver approves using a general MUA, When replying using the “Reply All” function and disapproving it, it is sufficient to reply to the approval request mail using the “Reply” function. Therefore, the approver can easily specify approval and non-approval by using the “reply to all” and “reply” functions of a general MUA.
なお、本実施形態では、返信メールに第１および第２の管理者アドレスの両方が含まれていた場合に承認と判定し、第１の管理者アドレスのみが含まれていた場合に非承認と判定するものとしたが、逆に、第１および第２の管理者アドレスの両方が含まれている場合に非承認と判定し、第１の管理者アドレスのみが含まれている場合に承認と判定するようにしてもよい。 In this embodiment, it is determined to be approved when both the first and second administrator addresses are included in the reply mail, and when the first administrator address is only included, the approval is determined to be unapproved. On the contrary, when both the first and second administrator addresses are included, it is determined as non-approved, and when only the first administrator address is included, approval is determined. You may make it determine.
また、本実施形態では、受信メールの配送に承認が必要であるか否かは、送信先がドメインユーザアドレスであるか否か、および、送信者に対応する承認者が登録されているか否かにより決定されるものとしたが、これに限らず、送信先のユーザごとに、承認が必要であるか否かを管理するテーブルを用意し、そのテーブルを参照して承認の要否を判定するようにしてもよいし、電子メールの内容に所定のキーワードが含まれているか否かにより判定するようにしてもよい。また、電子メールに添付ファイルが含まれているか否かなどにより判定するようにしてもよい。 In this embodiment, whether or not approval is required for delivery of the received mail depends on whether or not the transmission destination is a domain user address and whether or not an approver corresponding to the sender is registered. However, the present invention is not limited to this, and a table for managing whether or not approval is required is prepared for each user of the transmission destination, and whether or not approval is required is determined with reference to the table. The determination may be made based on whether or not a predetermined keyword is included in the content of the e-mail. Further, the determination may be made based on whether or not the attached file is included in the e-mail.
また、本実施形態では、受信メールの配送に承認が必要であるか否かは、受信メールごとに判定するものとしたが、受信メールの宛先が複数ある場合には、受信者アドレスごとに承認が必要か否かを判定するようにしてもよい。この場合、受信者アドレスごとに、承認依頼メールが承認者に送信される。 In this embodiment, whether or not approval is required for delivery of received mail is determined for each received mail. However, if there are multiple destinations for received mail, approval is performed for each recipient address. It may be determined whether or not is necessary. In this case, an approval request mail is transmitted to the approver for each recipient address.
また、本実施形態では、承認者テーブル１１２には送信者ごとに承認者が登録されるものとしたが、宛先になるメールアドレスに対する条件と、承認者アドレスとを対応付けて記憶しておき、受信メールの宛先にマッチする条件に対応する承認者に対して、承認依頼メールを送信するようにしてもよい。また、全ての受信メールについての承認依頼メールを所定の承認者に送信するようにしてもよい。 In this embodiment, an approver is registered for each sender in the approver table 112. However, a condition for an email address that is a destination and an approver address are stored in association with each other. An approval request mail may be transmitted to an approver corresponding to a condition that matches the destination of the received mail. Moreover, you may make it transmit the approval request mail about all the received mails to a predetermined approver.
また、本実施形態では、配送メールはユーザ端末２０から送信されることを前提としたが、他のＭＴＡから受信し、他のドメイン宛に電子メールを転送する場合の電子メールの承認を行うようにしてもよい。 In this embodiment, it is assumed that the delivery mail is transmitted from the
また、本実施形態のメールシステムでは、ＭＴＡの機能を提供するメールサーバ１０が受信メールの承認、非承認を判定するものとしたが、複数のＭＴＡの間で電子メールの中継を行う中継サーバが行うようにしてもよい。この場合のメールシステムの全体構成を図２５に示す。 In the mail system according to the present embodiment, the
図２５に示すように、中継サーバにおいて承認を行うメールシステムは、メールサーバ１６０と、複数の中継サーバ１５０および１７０とを含んで構成されている。
中継サーバ１５０および１７０はそれぞれ、上述したメールサーバ１０が備えていた、承認処理部１０６、監視処理部１０７、承認者テーブル１１２、承認待ちテーブル１１３、送信待ちキュー１１４を備えており、制御部１０３、メール受付部１０４、およびメール送信部１０５に代えて、制御部１５１、メール受付部１５２、およびメール送信部１５３を備えている。As shown in FIG. 25, the mail system that performs approval in the relay server includes a
Each of the
中継サーバ１５０および１７０のハードウェア構成は、図２に示すメールサーバ１０の構成と同じであり、承認処理部１０６、監視処理部１０７、承認者テーブル１１２、承認待ちテーブル１１３および送信待ちキュー１１４も上述のメールサーバ１０と同じ機能を提供する。 The hardware configuration of the
中継サーバ１５０のメール受付部１５２は、メールサーバ１６０および中継サーバ１７０から電子メールを受信する。中継サーバ１５０のメール送信部１５３は、メールサーバ１６０から受信した電子メールは中継サーバ１７０に送信し、中継サーバ１７０から受信した電子メールはメールサーバ１６０に送信し、中継サーバ１５０が生成した電子メールはメールサーバ１６０に送信する。 The
また、中継サーバ１７０は、他の中継サーバまたはメールサーバ（不図示）とも接続されているものとし、中継サーバ１７０のメール受付部１５２は、他の中継サーバまたはメールサーバと中継サーバ１５０との両方から電子メールを受信する。中継サーバ１７０のメール送信部１５３は、中継サーバ１５０から受信した電子メールは他の中継サーバまたはメールサーバに送信し、他の中継サーバまたはメールサーバから受信した電子メールは中継サーバ１５０に送信する。 The
以下、中継サーバ１５０が備える制御部１５１、メール受付部１５２およびメール送信部１５３の動作を説明する。なお、中継サーバ１７０についても、電子メールの送信元や送信先が異なるものの動作は同じである。 Hereinafter, operations of the
メール受付部１５２は、メールサーバ１６０または中継サーバ１７０から送信される電子メールを受け付ける。メール受付部１５２は、電子メールを受け付けたことを制御部１５１に通知する。 The
制御部１５１は、メール受付部１５２からの通知が届くと、承認処理部１０６に取得した電子メールを渡し、承認処理部１０６が電子メールの承認、非承認を判定する。 When the notification from the
メール送信部１５３は、承認処理部１０６により承認された配送メールを、配送メールの受信元に応じて、通信ネットワーク１４０を介して、中継サーバ１７０またはメールサーバ１６０に送信する。また、メール送信部１５３は、承認処理部１０６により生成された承認メールや非承認メール、エラーメールなどの電子メールを、通信ネットワーク１４０を介して、メールサーバ１６０に送信する。 The
このように、メールサーバ１０の機能を中継サーバが備えるようにすることもできる。これにより、数多くの電子メールを配送するメールサーバにおいて承認に係る処理負荷を上げることなく、電子メールの承認を行うことができる。 Thus, the relay server can be provided with the function of the
以上、本実施形態について説明したが、上記実施形態は本発明の理解を容易にするためのものであり、本発明を限定して解釈するためのものではない。本発明は、その趣旨を逸脱することなく、変更、改良され得ると共に、本発明にはその等価物も含まれる。 Although the present embodiment has been described above, the above embodiment is intended to facilitate understanding of the present invention and is not intended to limit the present invention. The present invention can be changed and improved without departing from the gist thereof, and the present invention includes equivalents thereof.
１０ メールサーバ ２０ ユーザ端末
３０ 承認者端末 １０１ 主記憶装置
１０２ サーバプログラム １０３ 制御部
１０４ メール受付部 １０５ メール送信部
１０６ 承認処理部 １０７ 監視処理部
１０８ ＣＰＵ １０９ 通信インタフェース
１１０ ディスクインタフェース １１１ メールボックス
１１２ 承認者テーブル １１３ 承認待ちテーブル
１２１ 主記憶装置 １２２ クライアントプログラム
１２３ 制御部 １２４ メール表示部
１２５ メール受信部 １２６ メール送信部
１２７ ＣＰＵ １２８ 通信インタフェース
１２９ ディスクインタフェース １３０ 入出力インタフェース
１３１ メールデータ記憶部 １３２ 入出力装置
１４０ 通信ネットワーク １５０ 中継サーバ
１５１ 制御部 １５２ メール受付部
１５３ メール送信部 １６０ メールサーバ
１７０ 中継サーバDESCRIPTION OF
Claims (6)
Translated fromJapanese受信した前記電子メールに基づき、第１のメールアドレスを送信元とし、第２のメールアドレス及び承認者のメールアドレスを宛先として設定した電子メールである承認依頼メールを作成して送信する承認依頼メール送信部と、
前記承認依頼メールについて前記承認者から返信された電子メールである返信メールを取得する返信メール取得部と、
前記記憶した返信メールの宛先に前記第１のメールアドレスおよび前記第２のメールアドレスの両方が含まれている場合に承認と判定し、前記返信メールの宛先に前記第１のメールアドレスのみが含まれている場合に非承認と判定する承認判定部と、
を備えることを特徴とする承認装置。An approval devicehaving an email receiver for receiving emails ;
Based on the received e-mail, an approval request e-mail thatcreates and sends an approval request e-mail that is an e-mail set with the first e-mail address as the sender and the second e-mail addressand the e-mail addressof the approver as the destination A transmission unit;
And reply mail acquisition unit thatTokusu retrieve the reply e-mail is an e-mail that has been returned from the approver for the approval request e-mail,
When both the first mail address and the second mail address are included in the stored reply mail address, it is determined as approval, and only the first mail address is included in the reply mail address. An approval determination unit that determines non-approval when
An approval apparatus comprising:
前記返信メール取得部は、前記電子メール受信部が受信した前記電子メールの宛先が前記第１のメールアドレスと一致した場合に、当該電子メールを前記返信メールとして取得すること、
を特徴とする請求項１に記載の承認装置。Comprisingapprovers storageunit that storesthe mail address of the approver,
The reply mail acquisition unit, when said emaildestination e-mail receiving unit receives matches thefirst email address,obtaining the electronic mailby said reply mail,
The approval apparatus according to claim 1.
前記返信メールに対応する前記承認依頼メールの前記電子メールＩＤを取得する返信先取得部と、
前記承認判定部が承認と判定した場合にのみ、取得した前記電子メールＩＤに対応する前記電子メールを前記電子メール記憶部から読み出して送信する電子メール送信部と、
を備えることを特徴とする請求項１に記載の承認装置。An email storage unit that stores the email to be approved in association with an email ID that identifies the approval request email;
And the reply-acquisition unit for acquiring the e-mail IDof the approval request e-mailcorresponding to the reply mail,
An e-mail transmission unit that reads and transmits the e-mail corresponding to the acquired e-mail ID from the e-mail storage unit only when the approval determination unit determines approval.
The approval apparatus according to claim 1, further comprising:
を特徴とする請求項３に記載の承認装置。The e-mail transmission unit deletes the e-mail corresponding to the acquired e-mail ID from the e-mail storage unit when the approval determination unit determines non-approval;
The approval apparatus according to claim 3.
受信した前記電子メールに基づき、第１のメールアドレスを送信元とし、第２のメールアドレス及び承認者のメールアドレスを宛先として設定した電子メールである承認依頼メールを作成して送信するステップ、
前記承認依頼メールについて前記承認者から返信された電子メールである返信メールを取得するステップ、及び
前記記憶した返信メールの宛先に前記第１のメールアドレスおよび前記第２のメールアドレスの両方が含まれている場合に承認と判定し、前記返信メールの宛先に前記第１のメールアドレスのみが含まれている場合に非承認と判定するステップ
を実行させることを特徴とする承認方法。To the approval devicethat receives the email ,
Based on the received e-mail, the first e-mail address and the transmission source, a second e-mail addressand sendingto create the set approval request mail is an e-mailapprover email address as a destination,
The approval request mail for steps thatTokusu preparative reply mail is a reply e-mail from the approver, and both of the first mail address and the second mail address in the storage the reply mail address An approval method, comprising: determining that the message is approved if it is included, and determining non-approval if only the first mail address is included in the destination of the reply mail.
受信した前記電子メールに基づき、第１のメールアドレスを送信元とし、第２のメールアドレス及び承認者のメールアドレスを宛先として設定した電子メールである承認依頼メールを作成して送信する機能、
前記承認依頼メールについて前記承認者から返信された電子メールである返信メールを取得する機能、及び
前記記憶した返信メールの宛先に前記第１のメールアドレスおよび前記第２のメールアドレスの両方が含まれている場合に承認と判定し、前記返信メールの宛先に前記第１のメールアドレスのみが含まれている場合に非承認と判定する機能
を実現させるためのプログラム。To the approval devicethat receives the email ,
Based on the received e-mail, the first e-mail address and the transmission source, the ability tosend the second mail addressand approver email addressto create an authorization request mail is an e-mail that has been set as the destination,
The approval request mail for the approver function thatTokusu preparative reply mail is a reply e-mail from, and both of the first mail address and the second mail address in the storage the reply mail address A program for realizing a function of determining approval if included, and determining non-approval when only the first mail address is included in the reply mail destination.
Priority Applications (1)
| Application Number | Priority Date | Filing Date | Title |
|---|---|---|---|
| JP2007288881AJP4857246B2 (en) | 2007-11-06 | 2007-11-06 | Approval device, approval method, and program |
Applications Claiming Priority (1)
| Application Number | Priority Date | Filing Date | Title |
|---|---|---|---|
| JP2007288881AJP4857246B2 (en) | 2007-11-06 | 2007-11-06 | Approval device, approval method, and program |
Publications (3)
| Publication Number | Publication Date |
|---|---|
| JP2009118174A JP2009118174A (en) | 2009-05-28 |
| JP2009118174A5 JP2009118174A5 (en) | 2010-02-25 |
| JP4857246B2true JP4857246B2 (en) | 2012-01-18 |
Family
ID=40784806
Family Applications (1)
| Application Number | Title | Priority Date | Filing Date |
|---|---|---|---|
| JP2007288881AExpired - Fee RelatedJP4857246B2 (en) | 2007-11-06 | 2007-11-06 | Approval device, approval method, and program |
Country Status (1)
| Country | Link |
|---|---|
| JP (1) | JP4857246B2 (en) |
Families Citing this family (6)
| Publication number | Priority date | Publication date | Assignee | Title |
|---|---|---|---|---|
| JP5088351B2 (en)* | 2009-08-05 | 2012-12-05 | コニカミノルタビジネステクノロジーズ株式会社 | E-mail transmission device and program |
| JP5246814B2 (en)* | 2011-02-10 | 2013-07-24 | Ｎｅｃシステムテクノロジー株式会社 | Mail misdelivery prevention device, mail misdelivery prevention method, and mail misdelivery prevention program |
| JP5477919B2 (en)* | 2012-03-02 | 2014-04-23 | Ｎｅｃシステムテクノロジー株式会社 | Attached file relay device, attached file relay method, and program |
| JP6024450B2 (en)* | 2012-12-27 | 2016-11-16 | 富士通株式会社 | Mail processing program, mail processing apparatus and mail processing method |
| JP6840962B2 (en)* | 2016-09-08 | 2021-03-10 | 日本電気株式会社 | Mail device, its information processing method, program, and mail system |
| US11748499B2 (en)* | 2020-09-23 | 2023-09-05 | Microsoft Technology Licensing, Llc | Asynchronous authorization of application access to resources |
Family Cites Families (4)
| Publication number | Priority date | Publication date | Assignee | Title |
|---|---|---|---|---|
| JP2003168063A (en)* | 2001-11-30 | 2003-06-13 | Hitachi Ltd | Payment approval method and system in card payment method |
| JP2004032605A (en)* | 2002-06-28 | 2004-01-29 | Systemport Inc | Electronic mail answering system and computer program for the same |
| JP2005346643A (en)* | 2004-06-07 | 2005-12-15 | Jfe Systems Inc | Transmission mail processing method and apparatus |
| JP2006270415A (en)* | 2005-03-23 | 2006-10-05 | Kyocera Mita Corp | Image processing apparatus |
- 2007
- 2007-11-06JPJP2007288881Apatent/JP4857246B2/ennot_activeExpired - Fee Related
Also Published As
| Publication number | Publication date |
|---|---|
| JP2009118174A (en) | 2009-05-28 |
Similar Documents
| Publication | Publication Date | Title |
|---|---|---|
| US6993561B2 (en) | Method and apparatus for maintaining a unified view of multiple mailboxes | |
| US7836132B2 (en) | Delivery confirmation for e-mail | |
| CN100463397C (en) | A file transfer method and system | |
| JP5129567B2 (en) | Messaging protocol for processing messages with attachments | |
| US6769067B1 (en) | Method and system for network communication control and security | |
| Hansen et al. | Message Disposition Notification | |
| JP4857246B2 (en) | Approval device, approval method, and program | |
| US20090049134A1 (en) | Method for delaying delivery of e-mail content | |
| JP4521480B1 (en) | Method, system, and computer program for correcting an email message with unsent recipients | |
| TWI262682B (en) | Message gateway and method and system for message dispatching based on group communication | |
| JP3281294B2 (en) | Automatic cleaning device for e-mail address list | |
| US20090282248A1 (en) | Method and system for securing electronic mail | |
| JP2009169866A (en) | E-mail client, control method therefor, and computer program | |
| JP2006331003A (en) | Information processing apparatus and e-mail control method | |
| US8615554B1 (en) | Electronic mail delivery physical delivery backup | |
| US7882182B2 (en) | Correcting information in a received electronic mail | |
| JP2006135662A (en) | File transfer relay method and file transfer relay system | |
| KR20030055817A (en) | Mail control method of receiving and deleting mails selectively using mail header information and mail client terminal | |
| KR20080018393A (en) | Real-time integrated messaging system providing instant messaging service and mail service and service method thereof | |
| JP2010186230A (en) | E-mail relay system and e-mail relay method | |
| JP4640620B2 (en) | E-mail management system, mail server, e-mail management method, and program | |
| JP4477396B2 (en) | E-mail transmission / reception system | |
| KR100614866B1 (en) | System and method for determining the reception possible state before sending mail | |
| KR20010081731A (en) | Apparatus for and method of reading e-mail from web-based e-mail service server using e-mail program | |
| KR20040015784A (en) | File Transfer System with Instant Messenger including file transfer function, and File Tranfer Method by the system |
Legal Events
| Date | Code | Title | Description |
|---|---|---|---|
| A521 | Written amendment | Free format text:JAPANESE INTERMEDIATE CODE: A523 Effective date:20100113 | |
| A621 | Written request for application examination | Free format text:JAPANESE INTERMEDIATE CODE: A621 Effective date:20100113 | |
| A977 | Report on retrieval | Free format text:JAPANESE INTERMEDIATE CODE: A971007 Effective date:20110525 | |
| A131 | Notification of reasons for refusal | Free format text:JAPANESE INTERMEDIATE CODE: A131 Effective date:20110607 | |
| A521 | Written amendment | Free format text:JAPANESE INTERMEDIATE CODE: A523 Effective date:20110801 | |
| TRDD | Decision of grant or rejection written | ||
| A01 | Written decision to grant a patent or to grant a registration (utility model) | Free format text:JAPANESE INTERMEDIATE CODE: A01 Effective date:20111004 | |
| A01 | Written decision to grant a patent or to grant a registration (utility model) | Free format text:JAPANESE INTERMEDIATE CODE: A01 | |
| A61 | First payment of annual fees (during grant procedure) | Free format text:JAPANESE INTERMEDIATE CODE: A61 Effective date:20111031 | |
| FPAY | Renewal fee payment (event date is renewal date of database) | Free format text:PAYMENT UNTIL: 20141104 Year of fee payment:3 | |
| R150 | Certificate of patent or registration of utility model | Free format text:JAPANESE INTERMEDIATE CODE: R150 | |
| LAPS | Cancellation because of no payment of annual fees |