JP2018196058A - クラウドサーバーシステム、その制御方法およびそのプログラム - Google Patents

Abstract

【課題】 ユーザーが利用する機能に応じて送信先メールアドレスの有効性を提示する仕組みを導入し、送信先メールアドレスを必要とする場合のみユーザーは送信先メールアドレスの有効性を確認できるようにすることを目的とする。【解決手段】 機能の実行時にメール送信が必須か任意であるかを判定し、メール送信が必須な場合は送信先宛先のメールアドレスが有効かを確認する。【選択図】 図４

Description

本発明は、メール送信機能を備えたクラウドサーバーシステム、その制御方法およびそのプログラムに関する。

近年、クラウドサービスと呼ばれるインターネットまたはイントラネットを介してソフトウェアの機能を提供するシステムが広まっている。クラウドサービスが提供する機能の中にはユーザーに処理結果を通知する機能があり、その通知方法として電子メールを利用する方法が知られている。送信元であるクラウドサービスがメール送信を行う際には、ＲＦＣ５３２１で定義されているＳＭＴＰプロトコルを利用し、外部のメールサーバーに対してメール送信要求を行う。

ＳＭＴＰプロトコルには送信先メールアドレスが原因でメールが送信先へ不達となった場合にメール送信元へ不達を示すバウンスメールを送信するという仕様がある。メールサーバーはスパム業者などの不正な送信者からの大量メール送信を防ぐために、バウンスメールが多い送信元を含む送信元ドメインからのメール送信を禁止するものが存在している。

これを回避するため、バウンスメールの発生を確認した送信元はバウンスメールに記載の送信先アドレスを管理し、ユーザーのメール送信時にメールアドレスが管理されているメールアドレスと同一である場合はメール送信を送信しない方法が考えられている。これにより、バウンスが発生したメールアドレスにメールが送信されなくなるため、外部のメールサーバーによるメール送信の禁止を未然に防ぐことが可能になる。特許文献１では、送信元のサーバーで無効なメールアドレスを管理し、ユーザーが端末を介してメールアドレスの有効性をサーバーに問い合わせる事で、対象のメールアドレスが無効か否かを確認しメール送信する方法が示されている。

特開２００４−１５１７５１

ユーザーが利用するクラウドサービスの機能には、メール送信が必要な機能と不要な機能とが混在していることが考えられる。ユーザーの利用する機能がメール送信不要な機能であった場合はメール送信が不要なので送信先メールアドレスの有効性を確認する必要はなく、ユーザーは送信先メールアドレスの有効性を確認する手間を省ける。しかし、この手間を省くためにユーザーは各機能に対するメール送信の必要性を認識していなければならず、クラウドシステム利用の利便性の低下を招く。

そこで本願発明は、ユーザーが利用する機能に応じて送信先メールアドレスの有効性を提示する仕組みを導入し、送信先メールアドレスを必要とする場合のみユーザーは送信先メールアドレスの有効性を確認できるようにすることを目的とする。

本発明に係るサーバーシステムは、複数の機能を備えたクラウドサービスをクライアントに提供するクラウドサーバーシステムであって、前記クラウドサーバーシステムから送信されてきたメールを送信先メールアドレスに送信するメールサーバーが前記メールをバウンスメールとして通知してきたことに応じて、前記送信先メールアドレスをバウンスリストにて管理する管理手段と、前記クライアントから受信した実行要求が指定する機能に対して割り当てられたメール送信レベルを確認する第１の確認手段と、取得した送信先メールアドレスが前記バウンスリストに含まれるため無効であるか否かを確認する第２の確認手段と、前記第１の確認手段によりメール送信レベルがメール送信を必要とするレベルであると確認されかつ前記第２の確認手段により無効であると確認された場合はエラー処理を実行し、前記第１の確認手段によりメール送信レベルがメール送信は任意であるとするレベルであると確認されかつ前記第２の確認手段により無効であると確認された場合はメール送信を除く方法で前記実行要求の処理結果を伝えるサービス手段と、を含むクラウドサーバーシステムであることを特徴とする。

ユーザーが利用する機能に応じて送信先メールアドレスの有効性を提示する仕組みを導入したことで、送信先メールアドレスを必要とする場合のみユーザーは送信先メールアドレスの有効性を確認できるようになり、クラウドシステム利用の利便性低下の虞を回避できる。

実施例１におけるシステム全体図 実施例１におけるハードウェア構成図 実施例１におけるソフトウェア構成図 実施例１における機能実行フロー図 実施例２におけるメールアドレス有効判定フロー図 実施例３におけるアカウントのメールアドレス必須確認フロー図

以下、本発明を実施するための最良の形態について図面を用いて説明する。

［実施例１］
インターネット上で様々なサービス提供者が様々なクラウドサービスを提供している。ここで、複数のサービス提供者が運営している複数のクラウドサービスを組み合わせ、１つのソリューションを実現するという手法が存在する。この手法はマッシュアップと呼ばれ、表向きはあたかも１つのＷｅｂサイトあるいはＷｅｂサービスとして見える。しかしながら、マッシュアップしているサービスは実際にはバックエンドで複数のクラウドサービスと連携し、必要な機能を組み合わせてソリューションを実現する。なお、ここで言うクラウドサービスとは、Ｗｅｂサイト、Ｗｅｂアプリケーション、Ｗｅｂサービスなどが提供する機能群のことである。Ｗｅｂサイト、Ｗｅｂアプリケーション、Ｗｅｂサービスなどは、サーバーコンピューターで実行されるソフトウェアである。以降、ネットワーク上で機能を提供しているクラウドサービスを本実施例ではリソースサービスと呼び、リソースサービスを構成しているサーバーをリソースサーバーと呼ぶ。

図１は、本実施の形態に係るネットワークシステムのネットワーク構成を示している。インターネット１００は、インターネットなどの外部から接続可能なパブリックなネットワークである。イントラネット１０１は、ＬＡＮなどの外部から接続不可能なプライベートなネットワークである。

リソースサーバー１０２は、リソースサービスを提供しているオンラインサービスシステムである。リソースサーバー１０２は、インターネット１００を介した端末１１０あるいは不図示の外部サービスシステムからのリクエストに応じて、リソースサービスを提供する。なおリソースサーバーに設置されるリソースサービスは１つでも複数でもよいが、本実施例では１つのリソースサービスには複数の機能が搭載されていることを想定している。アクセス管理サーバー１０３は、リソースサービスを利用するユーザーのアカウント情報と、認証情報および認可情報を管理するサービスシステムである。メール送信サーバー１０４は、不図示の外部メールサーバーに対してＳＭＴＰプロトコル等を用いてメールの送受信を行うサービスシステムである。この外部メールサーバーはバウンスメールが多い送信元ドメインからのメール送信を禁止するメールサーバーを想定している。

なお、リソースサーバー１０２、アクセス管理サーバー１０３、メール送信サーバー１０４は同一サーバー上に構成されても良いし、それぞれ個別のＬＡＮ上に構成されても良い。実施例１において各サーバーは１台ずつ設置されているが、複数台で構成されたシステムであってもよい。本発明でサーバーシステムと称した場合、各サーバーの台数が１台および複数台のどちらの形態も含んでいることを意図している。なお、サーバーシステムが提供する各サービスはユーザーからは見えないクラウドサービスであるので、クラウドサーバーシステムと称する場合もある。

端末１１０は、ＰＣ、スマートフォン、タブレットと呼ばれる携帯端末の他、画像形成装置といったデバイスであり、Ｗｅｂブラウザーがインストールされているクライアントである。クライアントである端末１１０上のＷｅｂブラウザーは、リソースサーバー１０２が公開するＷｅｂサイトにアクセスし、リソースサーバー１０２が提供する機能を利用出来る。

図２は、図１に示した各種リソースサービスが配置されているサーバーのハードウェア構成である。ユーザーインターフェース２０１は、ディスプレイ、キーボード、マウスなどによる情報の入出力を行うハードウェアである。これらのハードウェアを備えないコンピューターは、リモートデスクトップなどにより他のコンピューターから接続・操作することも可能である。

ネットワークインターフェース２０２は、ＬＡＮなどのネットワークに接続して、他のコンピューターやネットワーク機器との通信を行うハードウェアである。ＣＰＵ２０３は、ＲＯＭ２０４、ＲＡＭ２０５、二次記憶装置２０６などから読み込んだプログラムを実行し、各種サービスを実現する。ＲＯＭ２０４は、組込済みプログラムおよびデータが記録されている記憶装置である。ＲＡＭ２０５は、一時メモリ領域である。二次記憶装置２０６は、ＨＤＤに代表されるような外部記憶装置である。各部は入出力インターフェース２０７を介して接続されている。

図３は本発明に係る、リソースサーバー１０２、アクセス管理サーバー１０３、メール送信サーバー１０４のモジュール構成を示した図である。これらのモジュールは二次記憶装置２０６からＲＡＭ２０５にロードされ、ＣＰＵ２０３により実行されることで夫々の機能を実現する。

リソースサーバー１０２は、アプリケーションモジュール３００を持つ。アプリケーションモジュール３００は、リソースサーバー１０２で動作するアプリケーションプログラムであり、リソースサービスの機能を実現する。また、アプリケーションモジュール３００は必要に応じて、メール送信サーバー１０４に対してメール送信要求を行う。その際にアプリケーションモジュール３００は、アクセス管理サーバー１０３に対してユーザー情報取得要求を行い、メールアドレスなどのメール送信用情報を取得する。

アクセス管理サーバー１０３は、アクセス管理モジュール３１０と、アカウント管理モジュール３１１を持つ。アクセス管理モジュール３１０は、ユーザーやサービスの認証処理や認可処理を行い、リソースサーバー１０２が提供する機能の利用に制限を設ける。アカウント管理モジュール３１１は、リソースサーバー１０２を利用するユーザーおよびサービスのアカウント情報とテナント情報を管理する。テナント情報とはユーザーが所属するテナントの識別情報を指し、ここでいうテナントとは企業や顧客と言ったグループ単位のことを指す。

メール送信サーバー１０４は、メール送信モジュール３２０と、メール受信モジュール３２１、バウンスリスト管理モジュール３２２を持つ。メール送信モジュール３２０は、メール送信要求を受け付けると、不図示の外部メールサーバーに対してＳＭＴＰを用いてメール送信を行う。メール送信要求には送信先メールアドレス、送信元メールアドレス、本文が少なくとも含まれる。その際、メール送信モジュール３２０は、バウンスリスト管理モジュール３２２に問い合わせを行い、送信先のメールアドレスがバウンスリストに登録されていないことを確認する。もし送信先のメールアドレスがバウンスリストに含まれていた場合、メール送信モジュール３２０はメール送信を行わない。

メール受信モジュール３２１は、メール送信モジュール３２０によって送信されたメールがバウンスした際に、外部メールサーバーから送信されるバウンスメールを受信する。バウンスメールには、送信先メールアドレス、送信元メールアドレス、バウンス理由が含まれている。メール受信モジュール３２１はバウンスメールを受信すると、バウンスリスト管理モジュール３２２に対し、バウンスメールに含まれている送信先メールアドレスをバウンスリストに登録するように要求する。メール送信サーバー１０４はバウンスリストに基づきメール送信を制御することで、不達となるメールが送信される虞が低下する。

バウンスリスト管理モジュール３２２は、バウンスが発生した送信先メールアドレスをバウンスリストとして管理する。なおバウンスリスト管理モジュール３２２は、バウンスリストにメールアドレスを追加した日時をバウンス発生日時として管理し、バウンス発生から一定期間経過したらバウンスリストからそのメールアドレスを削除するなどの制御を行ってもよい。表１にメール送信サーバー１０４のバウンスリスト管理モジュール３２２で管理している、バウンスリストの例を示す。

次に、ユーザーがメール送信必須な機能であるユーザー作成機能を実行したものと仮定する。アプリケーションモジュール３００は、ユーザー作成機能の実行要求を受け付けると、不図示のユーザー作成画面を用いてユーザーＩＤ、メールアドレスなどの入力を求める。アプリケーションモジュール３００は、全ての項目が入力され、ユーザー作成実行要求を受け付けると、バウンスリスト管理モジュール３２２からバウンスリストを取得し、送信先メールアドレスがバウンスリストに含まれているか否かを確認する。送信先メールアドレスがバウンスリストに含まれていた場合、メールアドレス無効と判断してメール送信を行わない。例えば、ユーザーＩＤ「ユーザー１」、メールアドレス「ａａａ＠ｔｅｓｔ．ｃｏｍ」がユーザー作成画面で入力された場合、表３に示したバウンスリストに「ａａａ＠ｔｅｓｔ．ｃｏｍ」が含まれているため、メールアドレス無効と判断する。その他の例として、ログインしたユーザーのユーザーＩＤに予め関連付けられたメールアドレスを取得し、端末１１０から実行要求を受け付けたタイミングで表２に示したバウンスリストにメールアドレスが含まれるか否かを確認する方法がある。つまり、送信先メールアドレスの取得方法に限定はなく、いずれの場合であっても送信先メールアドレスがバウンスリストに含まれていないかが確認される。

図４を用いて、リソースサーバー１０２のアプリケーションモジュール３００が機能実行要求を受け付け、処理を行うフローを説明する。ステップＳ４０１において、リソースサーバー１０２上のアプリケーションモジュール３００は、端末１１０から送信された機能の実行要求を受信する。アプリケーションモジュール３００は、リソースサービスが提供する機能単位でメール送信が必要か否かをメール送信レベルで管理している。表２にアプリケーションモジュール３００が管理している機能毎のメール送信レベルの例を示す。

ステップＳ４０２において、アプリケーションモジュール３００は、実行要求で指定された対象の機能がメール送信不要か否かを表２のメール送信レベルに基づいて確認する。アプリケーションモジュール３００は、メール送信が不要の場合、ステップＳ４０３で機能を実行し、不要ではない場合、ステップＳ４０４を行う。メール送信は、ユーザーが選択した機能を実行することでその機能の実行結果をメールでユーザーに通達する必要がある場合に行われることを想定している。

例えば、権限の強いアカウントの作成時にセキュリティを担保するために、有効期限付きのワンタイムＵＲＬを作成して本人にアクセスさせるという機能は、メール送信が必須である。一方で、現在の利用状況等の集計を行う機能では、実行したアカウントにメール送信できる場合は集計結果をメールで送り、メール送信できない場合は画面から集計結果を取得できるようにすればよいため、メール送信は任意と言える。クラウドサービスの提供者は、用意した機能毎にメール送信レベルを設定することになる。

ステップＳ４０３において、アプリケーションモジュール３００は、メール送信が不要な機能を実行する。ステップＳ４０３が実行される場合、すなわち実行要求で指定された機能のメール送信レベルがメール送信を必要としないレベルだった場合、バウンスリストに送信先メールアドレスが含まれるか否かの確認が行われない。なぜなら、メール送信が不要であるため送信先メールアドレスがバウンスリストに含まれていようがいまいがメール送信をしないと割り切ることで、外部メール送信サーバーによってメール送信禁止処理が実行されるリスクを避けるためである。

本実施例では、表２に示した機能の内、メール送信が不要な機能であるユーザー情報変更機能を実行することを想定している。アプリケーションモジュール３００は、ユーザーの変更後のアカウント情報を受け付け、アクセス管理サーバー１０３に対してアカウント情報更新を実行する。

ステップＳ４０４において、アプリケーションモジュール３００は、対象の機能のメール送信レベルを確認する。メール送信が必須の場合、ステップＳ４０５を実行し、メール送信が任意の場合はステップＳ４１０を実行する。ステップＳ４０５において、アプリケーションモジュール３００は、送信対象のメールアドレスが有効か否かの確認を行う。アプリケーションモジュール３００は、メール送信サーバー１０４からバウンスリストを取得し、対象のメールアドレスがバウンスリストに含まれているか否かを確認する。なおメールアドレス有効チェック方法はこの方法に限らない。例えばアプリケーションモジュール３００がメール送信サーバー１０４にメールアドレスが有効であるか否かを問い合わせ、メール送信サーバー１０４が対象のメールアドレスがバウンスリストに登録されているか否かを確認し応答する形式でも良い。また、アプリケーションモジュール３００がバウンスリストを管理し、対象のメールアドレスが自身のバウンスリストに登録されているかを確認しても良い。本ステップにおける送信先メールアドレスの有効性の確認とは、送信先メールアドレスがバウンスリストに含まれているか否かによる有効性の確認である。

その後、アプリケーションモジュール３００は、ステップＳ４０６において、メールアドレスが有効だった場合はステップＳ４０７を実行し、メールアドレスが無効だった場合はステップＳ４０８を実行する。本実施例における表２に示した機能の内、メール送信が必須な機能であるユーザー作成機能を実行したものとする。アプリケーションモジュール３００は、ステップＳ４０５で作成するアカウント情報を受け付け、そのアカウント情報に含まれるメールアドレスが有効かの確認を行う。

ステップＳ４０７において、アプリケーションモジュール３００は、メール送信に必要な情報の取得を行った上で、メール送信が必須な機能を実行する。なおメール送信に必要な情報には、送信先メールアドレス、送信元メールアドレス、処理実行結果を含む本文などがある。アプリケーションモジュール３００は、送信先メールアドレスとしてステップＳ４０５で有効性を確認した送信先メールアドレスを設定し、送信元メールアドレスとしてアプリケーションモジュール３００が管理するシステムのメールアドレスを設定する。なお、送信元メールアドレスはアプリケーションモジュール３００が提供する機能単位で異なる。例えば操作を実行しているユーザーのメールアドレスや、リソースサーバーが管理しているメールアドレスなどでも良い。ユーザー作成機能を実行した場合では、アプリケーションモジュール３００は、ユーザーアカウントを作成し、メール送信に必要な情報を元にメールを送信する。その後、ステップＳ４０８において、アプリケーションモジュール３００は、ステップＳ４０７で取得したメール送信に必要な情報を利用し、メール送信を実行する。

ステップＳ４０９において、アプリケーションモジュール３００は、メール送信が必須な機能は実行不可能と判断し、エラー処理を行う。具体的なエラー処理としては機能の実行が不可能なことを通知するためのエラー応答が考えらえる。すなわち、ユーザーは結果的には選択した機能を利用することはできないことになる。たとえば、ユーザー作成機能の場合、もしメールアドレスが無効な状態でユーザーを作成してしまうと、初期パスワードが通知できず、またメールを利用したパスワードリセットも行えない。そのためアプリケーションモジュール３００は不図示のエラー画面を表示し、入力されたメールアドレスが無効であることを示した上で、アカウント作成は実行しない。

ステップＳ４１０において、アプリケーションモジュール３００は、ステップＳ４０５と同じようにメールアドレスが有効かの確認を行う。表２に示した機能の内、メール送信が任意な機能である使用状況集計機能を実行したものとする。アプリケーションモジュール３００は、使用状況集計機能の実行要求を受け付けると、実行要求を行ったアカウントに登録されているメールアドレスをアクセス管理サーバー１０３から取得する。表３にアクセス管理サーバー１０３が管理しているアカウントの例を示す。例えば、使用状況集計機能を実行したユーザーが「Ａｄｍｉｎｉｓｔｒａｔｏｒ＠１０１ＡＡ」だった場合、アクセス管理サーバーに登録されているメールアドレスは「ａｄｍｉｎ＠ｔｅｓｔ．ｃｏｍ」となる。このメールアドレスはバウンスリストに含まれていないため、メールアドレス有効と判断される。ステップＳ４１１において、メールアドレスが有効だった場合はステップＳ４１２を実行し、メールアドレスが無効だった場合はステップＳ４１４を実行する。

ステップＳ４１２において、アプリケーションモジュール３００はメール送信が任意な機能についてメール送信ありのパターンで処理を実行し、ステップＳ４１３において処理結果をメール送信する。メール送信ありのパターンでは、アプリケーションモジュール３００はメール送信に必要な情報を取得した上で、処理結果をメール本文に追加したり、メールに添付する結果ファイルとして作成したりする。たとえば、アプリケーションモジュール３００は使用状況の集計を実行し、集計結果をまとめて圧縮ファイル化する。作成した集計結果ファイルを添付したメールを実行ユーザーのメールアドレスに対して送信する。

ステップＳ４１４において、アプリケーションモジュール３００はメール送信が任意な機能についてメール送信なしのパターンで処理を実行し、その処理結果をメール送信以外の別の方法でユーザーに提供する。メール送信なしのパターンでは、アプリケーションモジュール３００は処理結果をユーザーが操作する端末の画面上に表示させる他、ダウンロードできるファイルとして生成しダウンロードさせる。表２に示した機能の内、メール送信が任意な機能である使用状況集計機能を実行したものとする。アプリケーションモジュール３００は、使用状況の集計を実行し、集計結果を表示させるためのＨＴＭＬを作成しユーザーが操作する端末に送信し、端末のＷｅｂブラウザーに表示させる。

実施例１の方法により、メール送信が必須の機能と任意の機能については、機能実行前に送信先メールアドレスが有効か否かが確認され、その結果によって適切な処理フローが決定される。また、メール送信が不要な機能については送信先メールアドレスの有効性に依らず処理が実行される。この方法により、信先メールアドレスを必要とする場合のみユーザーは送信先メールアドレスの有効性を確認できるようになり、クラウドシステム利用の利便性低下の虞を回避できる。

［実施例２］
次に図５を用いて、送信先メールアドレスがバウンスリストに登録されていないが無効なメールアドレスであった場合でも、その送信先メールアドレスに対するメール送信を防ぐ第２の形態について説明する。実施例１では、外部のメールサーバーで発生するバウンスの数を減らすために、一度バウンスしたメールアドレスにはメール送信しないという対応を取った。しかしこの方法では、初めて送信する送信先メールアドレスに対しては、送信を試みないとバウンスメールが通知されるか分からない。本実施例では、初めて送信する送信先メールアドレスであっても、明らかに無効なメールアドレスについてはメール送信を行わない方法について説明する。実施例２にて説明しなかった部分は実施例１と同様となる。

例えば表３で示したユーザー「Ａｄｍｉｎｉｓｔｒａｔｏｒ＠１０２ＡＡ」のメールアドレスは「ａｄｍｉｎｉｓｔｒａｔｏｒ＠ｔｅｓｔ２．ｃｏｍ」となっており、表２で示したバウンスリストには登録されていない。ただしバウンスリストはバウンス通知されたメールアドレスのみを管理しているため、一度もメールが送られていないメールアドレスについては有効なメールアドレスなのかを確認できない。そのため、「ａｄｍｉｎｉｓｔｒａｔｏｒ＠ｔｅｓｔ２．ｃｏｍ」というメールアドレスは、メールが届く正常なメールアドレスなのか、一度も送信されていないメールアドレスなのか判断がつかない。

以下は、アプリケーションモジュール３００がステップＳ４０５およびステップＳ４１０で実行した、実施例２におけるメールアドレスが有効か否かの確認フローである。ステップＳ５００において、アプリケーションモジュール３００は、不図示のＤＮＳサーバーに対して送信先メールアドレスのドメインの問い合わせを行う。ＤＮＳサーバーとは、ネットワーク上のドメイン名とＩＰアドレスとの変換を行うサーバーである。ＤＮＳサーバーはメールアドレスのドメイン名について、送信するサーバーをＭＸレコードとして管理している。メール送信サーバー１０４がメール送信を行う際には、不図示のＤＮＳサーバーに対して送信先のメールアドレスのドメインの問い合わせを行い、送信先の不図示の外部メールサーバーのアドレスを取得する。その上でメール送信サーバー１０４は取得したメールアドレスに対して送信先メールアドレスでのメール送信を要求する。

ステップＳ５００では、メール送信を実行する前にＤＮＳサーバーに対してメールアドレスのドメインの問い合わせをしている。もしメールアドレスのドメインが有効な場合、ＤＮＳサーバーからＭＸレコードが応答される。一方で無効なドメインの場合、ＤＮＳサーバーでドメインが見つからず、ＭＸレコードは応答されない。これにより、対象のメールアドレスを管理する外部メールサーバーのドメインがＤＮＳに登録されているか否かが確認できる。

例えば、「ａｄｍｉｎｉｓｔｒａｔｏｒ＠ｔｅｓｔ２．ｃｏｍ」に対して送信先メールアドレスの有効性確認を行ったものとする。アプリケーションモジュール３００がＤＮＳサーバーに対しドメイン「ｔｅｓｔ２．ｃｏｍ」の問い合わせを行う。アプリケーションモジュール３００は、ＤＮＳサーバーから応答されたＭＸレコードにドメイン「ｔｅｓｔ２．ｃｏｍ」が含まれていた場合、ドメイン「ｔｅｓｔ２．ｃｏｍ」は有効なドメインと判断する。一方でＭＸレコードが空だった場合、ドメイン「ｔｅｓｔ２．ｃｏｍ」は存在しないドメインと判断する。その後、ステップＳ５０１において、メールアドレスが有効だった場合はステップＳ５０２を実行し、メールアドレスが無効だった場合はステップＳ５０５を実行する。

ステップＳ５０２において、アプリケーションモジュール３００はステップＳ４０５と同様にバウンスリストを取得し、対象の送信先メールアドレスがバウンスリストに登録されているか否かを確認する。ステップＳ５０３において、送信先メールアドレスがバウンスリストに登録されていなかった場合はステップＳ５０４を、バウンスリストに登録されていた場合はステップＳ５０５を実行する。ステップＳ５０４において、アプリケーションモジュール３００は、送信先メールアドレスが有効であると判断する。ステップＳ５０５において、アプリケーションモジュール３００は、送信先メールアドレスが無効であると判断する。バウンスリストに基づく送信先メールアドレスの有効性の判定は実施例１と同様である。

実施例２の方法により、バウンスリストに登録されていなくても無効なドメインの送信先メールアドレスに対してメール送信されることを防ぐ事ができる。なお、実施例２ではステップＳ５００でドメインの確認を行ってからステップＳ５０２でバウンスリストに登録されているか確認したが、確認する順番は逆でも構わない。

［実施例３］
次に、図６を用いてアカウントのメールアドレスが無効だった場合のリソースサーバーの対応について説明する。実施例１で説明したように、送信先メールアドレスが無効なユーザーはメール送信が必須な機能は使えなくなる。そのため、全サービスを問題なく使うためには有効なメールアドレスに設定しなおす必要がある。しかしながら、有効なメールアドレスを準備するには手間がかかる。特に企業内の管理部門がメールアドレスを管理している場合、必要な手続きを踏んで申請などを行う必要がある。実施例３にて説明しなかった部分は実施例１または２と同様となる。

一方で、メールアドレスが無効だとシステム運用に弊害が発生するアカウントが存在している。例えばユーザーがパスワードを忘れてしまった場合の対応として、管理者によるパスワードリセットか、メール通知によるパスワードリセットという２つの方法が考えられる。もしテナント内の一般ユーザーがパスワードを忘れてしまい、かつメールアドレスが無効だった場合には管理者にリセットを依頼すればよい。しかし、管理者がパスワードを忘れてしまいメールアドレスも無効となってしまうと、パスワードリセットする方法がなく、管理者が不在となってしまう。なお、本対応はユーザーがログインした際、または機能を利用しようとした際に実行される。

ステップＳ６００において、アプリケーションモジュール３００はアクセス管理サーバー１０３からログインし操作を行っているユーザーのアカウントに登録されているメールアドレスを取得する。たとえば、「Ｃｕｓｔｏｍｅｒ＠１０１ＡＡ」がログインしたものとする。アプリケーションモジュール３００はアクセス管理サーバー１０３から、メールアドレス「ａａａ＠ｔｅｓｔ．ｃｏｍ」を取得する。

ステップＳ６０１において、アプリケーションモジュール３００は、対象のアカウントにメールアドレスが設定されているかを確認する。設定されていた場合はステップＳ６０２を、設定されていなかった場合はステップＳ６０４を実行する。ステップＳ６０２において、アプリケーションモジュール３００は、前述のステップＳ４０５のように、対象のメールアドレスが有効かのチェックを行う。メールアドレスが有効だった場合は問題なしとして処理を終了し、無効だった場合はステップＳ６０４を実行する。「ａａａ＠ｔｅｓｔ．ｃｏｍ」の場合はバウンスリストに登録されているため、メールアドレス無効と判断される。

ステップＳ６０４において、アプリケーションモジュール３００は、対象のアカウントの権限に従い、メールアドレス必須レベルを取得する。表４にアプリケーションモジュール３００が管理しているメールアドレス必須レベルの例を示す。たとえば、アプリケーションモジュール３００は、アクセス管理サーバー１０３から権限「一般者」を取得し、表４からメールアドレス必須レベル「任意」を取得する。その後、ステップＳ６０５において、メールアドレスが必須だった場合はステップＳ６０６を実行し、任意だった場合はステップＳ６０７を実行する。

ステップＳ６０６において、アプリケーションモジュール３００は、操作を行っているユーザーに対してメールアドレス登録要求を行う。以降、登録が行われるまでいずれの機能も実行できないようにしても良い。ステップＳ６０７において、アプリケーションモジュール３００は、操作を行っているユーザーに対してメールアドレス無効を通知する。

本実施例の機能によりメールアドレスが無効であると確認され、その後有効なメールアドレスが登録されなかった場合、実施例１または実施例２に記載の制御により、ユーザーはメール送信を必須とする機能を利用できないことになる。実施例３の方法により、ユーザーが機能を利用する前に無効なメールアドレスを更新する機会を設けることが可能になる。

［その他の実施例］
本発明は、以下の処理を実行することによっても実現される。即ち、上述した実施例の機能を実現するソフトウェア（プログラム）を、ネットワーク又は各種記憶媒体を介してシステム或いは装置に供給し、そのシステム或いは装置のコンピュータ（またはＣＰＵやＭＰＵ等）がプログラムを読み出して実行する処理である。

１０２ リソースサーバー
１０３ アクセス管理サーバー
１０４ メール送信サーバー
３００ アプリケーションモジュール
３１１ アカウント管理モジュール
３２０ メール送信モジュール
３２２ バウンスリスト管理モジュール

Claims (10)

1. 複数の機能を備えたクラウドサービスをクライアントに提供するクラウドサーバーシステムであって、
   前記クラウドサーバーシステムから送信されてきたメールを送信先メールアドレスに送信するメールサーバーが前記メールをバウンスメールとして通知してきたことに応じて、前記送信先メールアドレスをバウンスリストにて管理する管理手段と、
   前記クライアントから受信した実行要求が指定する機能に対して割り当てられたメール送信レベルを確認する第１の確認手段と、
   取得した送信先メールアドレスが前記バウンスリストに含まれるため無効であるか否かを確認する第２の確認手段と、
   前記第１の確認手段によりメール送信レベルがメール送信を必要とするレベルであると確認されかつ前記第２の確認手段により無効であると確認された場合はエラー処理を実行し、前記第１の確認手段によりメール送信レベルがメール送信は任意であるとするレベルであると確認されかつ前記第２の確認手段により無効であると確認された場合はメール送信を除く方法で前記実行要求の処理結果を伝えるサービス手段と、を含むクラウドサーバーシステム。
2. 前記サービス手段は、前記第１の確認手段によりメール送信レベルがメール送信を必要としないレベルであると確認された場合は、前記実行要求の処理を実行した後に前記実行要求の処理結果を伝えないことを特徴とする請求項１に記載のクラウドサーバーシステム。
3. 前記第１の確認手段によりメール送信レベルがメール送信を必要としないレベルであると確認された場合は、前記第２の確認手段による前記送信先メールアドレスが無効であるか否かの確認が行われないことを特徴とする請求項１または２に記載のクラウドサーバーシステム。
4. 前記第１の確認手段によりメール送信レベルがメール送信は任意であるとするレベルであると確認されかつ前記第２の確認手段により前記送信先メールアドレスが有効であると確認された場合は、前記実行要求の処理結果を前記送信先メールアドレスに対しメール送信して伝えることを特徴とする請求項１乃至３の何れか１項に記載のクラウドサーバーシステム。
5. 前記第２の確認手段は、前記送信先メールアドレスのドメインをＤＮＳサーバーへ問い合わせ、その問い合わせ結果に基づき前記送信先メールアドレスのドメインが有効であるか否かを確認し、ドメインが無効であると確認されたことに応じて前記送信先メールアドレスは無効であることを確認することを特徴とする請求項１乃至４の何れか１項に記載のクラウドサーバーシステム。
6. 前記第２の確認手段は、前記送信先メールアドレスのドメインをＤＮＳサーバーへ問い合わせ、その問い合わせ結果に基づき前記送信先メールアドレスのドメインが有効であるか否かを確認し、ドメインが有効であると確認されたことに応じて前記送信先メールアドレスが前記バウンスリストに含まれるため無効であるか否かを確認することを特徴とする請求項１乃至５の何れか１項に記載のクラウドサーバーシステム。
7. 前記クラウドサーバーシステムにログインしたユーザーのアカウントに関連づくメールアドレスを取得し、取得したメールアドレスが前記バウンスリストに含まれるため無効であると確認された場合に、前記アカウントに関連づく権限を基に前記アカウントが送信先メールアドレスを必須とするアカウントであるか否かを確認する第３の確認手段と、
   前記第３の確認手段により前記アカウントが送信先メールアドレスを必須とするアカウントであると確認された場合、送信先メールアドレスの登録を要求する通知手段と、を有する請求項１乃至６の何れか１項に記載のクラウドサーバーシステム。
8. 前記通知手段は、前記第３の確認手段により前記アカウントが送信先メールアドレスを必須としないアカウントであると確認された場合、送信先メールアドレスが無効であることを通知することを特徴とする請求項７に記載のクラウドサーバーシステム。
9. 複数の機能を備えたクラウドサービスをクライアントに提供するクラウドサーバーシステムを制御する方法であって、
   管理手段は、前記クラウドサーバーシステムから送信されてきたメールを送信先メールアドレスに送信するメールサーバーが前記メールをバウンスメールとして通知してきたことに応じて、前記送信先メールアドレスをバウンスリストにて管理し、
   第１の確認手段は、前記クライアントから受信した実行要求が指定する機能に対して割り当てられたメール送信レベルを確認し、
   第２の確認手段は、取得した送信先メールアドレスが前記バウンスリストに含まれるため無効であるか否かを確認し、
   サービス手段は、前記第１の確認手段によりメール送信レベルがメール送信を必要とするレベルであると確認されかつ前記第２の確認手段により無効であると確認された場合はエラー処理を実行し、前記第１の確認手段によりメール送信レベルがメール送信は任意であるとするレベルであると確認されかつ前記第２の確認手段により無効であると確認された場合はメール送信を除く方法で前記実行要求の処理結果を伝えることを特徴とする方法。
10. 請求項９に記載の方法をコンピューターに実行させるためのプログラム。

Images