ようこそ、Notes/Domino ファン & ブロガーのみなさん !


【ご注意】 このブログはビジネスに活用いただくためのものですので、以下の点を守ってご利用願います。


1. 他社あるいは他人への誹謗中傷のコメントはご遠慮ください。

2. コメントはビジネスとして問題のない言葉、表現を使ってください。

3. Webで一般公開されていない、具体的な個人や法人を特定するコメントはご遠慮ください。

4. 個人情報の記載は行わないでください。


上記を守られないコメントは、こちらの判断で削除させていただきますのでご了承願います。


尚、このサイトの掲載内容は私自身の見解であり、IBMとは全く関係はありません。

また、IBMのビジネスに利害を及ぼすために記載している訳ではありません。


ここに記載されている内容は、私自身の経験からの記載であり、内容が正確でない場合もあることをご理解の上、ご利用願います。


ご利用に際しては、左側のフレームに記載しております【注】をご一読の上、利用条件を守ってご利用ください。

1 | 2 | 3 | 4 | 5 |最初 次ページ >>
May 21, 2016

管理者からの未既読判断は可能か? -7-

テーマ:Technique
<話題の履歴>

管理者からの未既読判断は可能か? -1-
管理者からの未既読判断は可能か? -2-
管理者からの未既読判断は可能か? -3-
管理者からの未既読判断は可能か? -4-
管理者からの未既読判断は可能か? -5-
管理者からの未既読判断は可能か? -6-


前回は、改めて開発すべきSpam/Virus 調査Toolの技術的課題の検討を行ってみました。

今回は、この機能要件に従い実装するための概要設計を行ってみます。

まず、調査しなければならないMail ServerはUserの環境にもよりますが複数存在します。
前々回に、Spam/Virus Mailの調査方法の検討を行いましたが、db.Searchで探すのが最も妥当なのではないかと思われます。
しかし、それ程Performanceが良いとは思われない訳で、数千人とか数万人の環境だと、1 Serverで処理したとしたら、膨大な時間が掛かることが予測されます。
となると、処理の分散化を当初から考えておく必要があると思います。

しかし、調査用のDBをMail Server単位に配置したのでは、全てのデータを集約して会社全体の状態を確認することが困難になります。
ここは、Notes/Dominoの特徴であるReplicaを活用して設計するのが得策と思われます。

後は、Replica配置したRemote Server上でのAgentの実行や実行後の収集Dataや実行Logの集約が出来、それがMail ServerではないDB Server上に登録された調査用のDBから集中管理が出来ることが重要です。

この制限条件に基づいて、設計してみます。

【環境】(DB配置)
 1) 集中コントロールするDB ServerにSpam/Virus調査DBを配置する
 2) Mail ServerにSpam/Virus調査DBのReplicaを配置する
 3) 分散配置されたReplicaでは操作は禁止する

【調査対象Mail Server定義】(環境設定Form/View)
 1) Cluster環境も考慮して調査対象Mail Server(Cluster Server)の定義
 2) 調査対象Serverに対して調査Program(Agent)を実行可能とする

【調査対象Spam/Virus Mailパターン定義】(調査パターン定義Form/View)
 1) Subjectの「始まる/終わる/含む」のパターンで定義を可能とする
 2) 追加オプションとして添付ファイル名(「始まる/終わる/含む」のパターン)の定義を可能とする
 3) 追加オプションとして送信者名(FromまたはSMTPOriginator)が詐称のパターンの定義を可能とする

【Spam/Virus Mail受信者情報収集定義】(収集情報Form/View)
 1) Notes基本名/別名
 2) Home Mail Server名/Mail DB File名
 3) Internet Address
 4) DJX組織情報

【Spam/Virus Mail収集情報定義】(収集情報Form/View)
 1) 送信者(From)
 2) 送信元(SMTPOriginator)
 3) 送信先(To/Cc/Bcc)
 4) 件名(Subject)
 5) 本文(Body)のText情報(フィッシングを考慮してLink先情報を変更できること)
 6) 添付ファイル名
 7) 文書UNID(削除対応用)
 8) SMTP配信経路情報(Received Field内容)
 9) 未既読情報
10) 発見場所情報(ごみ箱/ごみ箱以外)
11) Spam/Virus判断情報(削除対象/削除対象外)
12) 削除情報(管理者強制削除/User削除)

【設定情報配布】(ViewのButton)
 1) 「調査対象Mail Server定義」、「調査対象Spam/Virus Mailパターン定義」のMail Serverへの即時配布を可能とする
 2) 配布完了のチェックを実施する

【Spam/Virus Mail情報収集】(ViewのButton/Agent)
 1) 「調査対象Mail Server定義」に定義された全てのMail Serverで並行でSpam/Virus Mail情報収集実行可能とする
 2) 「調査対象Spam/Virus Mailパターン定義」に一致するMail調査結果を文書として保存する
 3) 収集したSpam/Virus Mail情報を集中コントロールするDB Serverに配置したDBに集約する
 4) 情報収集Logを集中コントロールするDB Serverに配置したDBに集約する

【Spam/Virus Mailの調査】(ViewのButton/Agent)
 1) 個別(User名指定)/対象User List(Textファイルで指定)/全Userでの調査を可能とする
 2) 複数あるMail Serverでの同時並行実行を可能とする
 3) 調査Logを保存する
 4) 取集されたSpam/Virus Mailの分類(Spam/Virus及び対象外の判断)を可能とする

【Spam/Virus Mailの駆除】(ViewのButton/Agent)
 1) Spam/Virus Mailと判断されたMailの一括削除(ごみ箱を含む)を可能とする
 2) 削除状態を調査した収集情報に反映する
 3) 削除Logを保存する
 4) Spam/Virus Mailと判断されたMailの検体保存(調査用)を可能とする

【情報収集Log情報】(収集Log Form/View)
 1) Agent開始時間
 2) Agent実行Server名
 3) 調査したUserのNotes基本名/別名
 4) 調査したUserのHome Mail Server名/Mail DB File名
 5) 調査状況
  5-1) 調査したSpam/Virus名
  5-2) 発見情報(ごみ箱以外での発見数/ごみ箱での発見数)
 6) Agent終了時間及びError情報

【削除Log情報】(削除Log Form/View)
 1) Agent開始時間
 2) Agent実行Server名
 3) 削除したUserのNotes基本名/別名
 4) 削除したUserのHome Mail Server名/Mail DB File名
 5) 削除状況
  5-1) 削除したSpam/Virus名
  5-2) 削除情報(ごみ箱以外での削除数/ごみ箱での削除数)
 6) Agent終了時間及びError情報


これで実際の詳細設計/開発が行えるのではないかと思います。

実は、この仕組みは概要設計も詳細設計もすることなく、頭の中だけで設計し既に開発がほぼ終わっています。
全UserのSpam/Virus Mail CheckはPerformanceの観点で考慮点がありますので、Test的に100 User程度に制限して実行しましたが、ごみ箱を探さない場合で、1-2GB程度のMail DB容量の100 Userで8-10分程度という状態でした。
1 Serverあたり1000 Userとか2000 Userを登録されている会社が多いと思いますので、へたをすると200分程度の実行時間が必要ではないかと見積もっています。
特にごみ箱に多くの文書がある場合は、更に時間が掛かると思われます。
Agentとしてはかなり時間が掛かりますので、発見後夜に実行するとかの考慮が必要でしょうし、Agentの最大実行時間を拡張することも必要です。

逆に、SMTP Logなどから、Spam/Virus Mailが侵入したUserが特定可能な場合は、1 Userあたり1分以下で情報収集が可能です(正確な時間は測定していませんが、Agent Logの開始時間と終了時間で判断できます)。
先にSMTP LogからSpam/Virus Mailの侵入先を特定できるのであれば、侵入先のみ調査するのが得策と言えます。

削除も、集中管理Serverから、10文書程度の削除を行っても、直ぐに終わることが確認できています。

実際のCodeを紹介することは行いませんが、これまでの記事から、皆さんなら直ぐに開発できるのではないかと思います。

最近では、Spam/Virus Mailが日々発生し、企業としては悩まされる毎日だと思いますが、この情報が参考になれば幸いです。

<終わり>
 
いいね!(16)  |  コメント(0)  |  リブログ(0)
最近の画像つき記事
 もっと見る >>
May 20, 2016

Webから隠しCheckbox Fieldを保存した際にTextになる障害 (続)

テーマ:Trouble Info
以前紹介したこの障害ですが、簡単に再現テストができます。

要するに、複数値を持つCategories Fieldがあり、Webから非表示状態で保存されれば良いのです。

最近のDiscussion TemplateはxPagesで出来ているので面倒なので、文書ライブラリTemplateを使うと簡単に再現できます。

【再現手順】

1) 文書ライブラリTempalateからServerにDBを作成
2) Designerで開いて、Categories FieldをWeb Browserから非表示に設定
3) Notes Clientから新規文書を作成して複数Categoryを付与
4) Web Browserから文書を開いて編集後に保存

Notes Clientから文書のPropertyを確認すると、Categories Fieldが単数の値になっていることが確認できます。

その後、前回紹介した、

DominoSingleValueListField=0

を設定して、Server Restartして同様の手順を踏むと、問題は発生しなくなります。

Notes.iniパラメーターが有効に機能していることの確認に使えますので、活用ください。

 
いいね!(0)  |  コメント(0)  |  リブログ(0)
May 13, 2016

管理者からの未既読判断は可能か? -6-

テーマ:Technique
<話題の履歴>

管理者からの未既読判断は可能か? -1-
管理者からの未既読判断は可能か? -2-
管理者からの未既読判断は可能か? -3-
管理者からの未既読判断は可能か? -4-
管理者からの未既読判断は可能か? -5-


前回は、技術的な実現可能性の検証の前に、考慮すべき技術課題を検討しました。

今回は、この課題の検証をしてみたいと思います。

前回列挙した技術的課題を順番に考えてみましょう。

前回列挙した技術的課題は、以下です。

1) 一時的削除(Soft Deletion)された場合の文書の検索は出来るか?
2) 一時的削除(Soft Deletion)された場合の文書の削除は出来るか?
3) db.SearchでCollectionを集める場合と、AllDocuments Viewを全て舐めて判断する場合のPerformanceの違いはどうか?
4) 発信元Hostを調査できるか?

先ずは、

1) 一時的削除(Soft Deletion)された場合の文書の検索は出来るか?

ですが、これは単純にdb.Searchを使ったLotusScriptのProgramを書くと直ぐに分かります。

検証方法としては、

1. 特定のSubjectのMailを検証するUserに送付する
2. LotusScriptでMailのSubjectでdb.Searchで検索するProgramを作成する
3. 作成したProgramでMailが検索できることを確認する
4. 検索に成功したMailを削除して、ごみ箱に入れる(一時的削除状態にする)
5. 再度作成したProgramでMailを検索する

というStepになりますが、結論から言うと、残念ながら「ごみ箱」($SoftDeletions) Viewに入れられた文書はdb.Searchでは探すことが出来ないのです。
DBの文書としては削除されてしまった文書と判断されます。

では、この「ごみ箱」($SoftDeletions) Viewに入っている文書を検索する場合はどうすれば良いのでしょうか?

賢明な皆さまなら直ぐに分かると思いますが、「ごみ箱」($SoftDeletions) Viewを舐めて順番に文書を得ていくことです。
つまり、「ごみ箱」($SoftDeletions) Viewを含めてSpam/Virus Mailを検索したい場合は、通常のdb.Searchで探しても文書が見つからない場合は「ごみ箱」($SoftDeletions) Viewを舐めて探さなければならないと言うことです。
これにより、条件に一致する文書を探し出すことは可能です。

次に2点目の

2) 一時的削除(Soft Deletion)された場合の文書の削除は出来るか?

を見てみます。

これも、既に検索して取得したDocument UNIDを使ってdb.GetDocumentByUNIDで探すのが一般的だと思いますが、「ごみ箱」($SoftDeletions) Viewに入ってしまっている文書はDB上は削除済と判断されて探すことが出来ないのです。
LotusScriptのMethodだと、db.GetDocumentByUNIDなのですが、この中に「ごみ箱」($SoftDeletions) Viewに入っている文書は含まれていません。
詰まり、db.GetDocumentByUNIDで探すと、IsERR_NOTES_BAD_UNIDが返ってきてしまいます。

通常のLotusScriptのProgramingの場合、set doc = でNotesDocumentを探してから、If Not(doc Is Nothing)といった処理でError Handlingを行いますが、db.GetDocumentByUNIDの場合は、Setした段階でErrorになりますので、Designer Helpに書かれているように、On Error IsERR_NOTES_BAD_UNID Goto [Label]で処理するしかありません。

個人的には、こういう場合もNothingを返してくれたらProgramが楽だと思うのですが、残念ながらそうではないのです。
On Error Gotoは私としては予期しないErrorが起こった場合の最終手段として書くことが多いので、これを定常的に利用しないといけないのは違和感があります。
色々な会社が開発されたApplication Codeを見ていると、On Error Gotoで済まされている場合は非常に品質の悪いCodeになっていることが分かっています。
そういうCodeを書かれている開発会社は、正常な処理が行われた場合以外は全部Errorとして扱っていて、Error Handlingを放棄しているCodeだと思われてなりません。

話が少しそれましたが、「ごみ箱」($SoftDeletions) Viewに入っている文書を探すのも面倒だということです。

Mail TempalteをCustomizeすることが許されるのであれば」($SoftDeletionsByUNID) というような、Document UNIDでSortしたViewを用意しておけば、Set view = db.GetView("($SoftDeletionsByUNID)")でViewをSetしてから、view.GetDocumentByKeyを使って取得することも考えられますが、Mail TemplateのCustomizeが許されない環境の場合は、、「ごみ箱」($SoftDeletions) Viewに収められている文書を順番に判断して、削除対象の文書IDと同じ文書IDの文書を探してから削除するという処理が必要になります。

これはかなり負荷の高い処理になる感じですが、通常のNotes/DominoのMail DBの場合は、Soft Deletionで残される期間は48時間であり、一般のUserが2日間に削除するMailの量はそれほどではなく、耐えられる気もします。

実際に、大量の文書を削除して試してみたことがありますが、1000文書程度削除して実行するとかなりPerformanceが悪化しました。

これに関連して、Performanceという観点では、

3) db.SearchでCollectionを集める場合と、AllDocuments Viewを全て舐めて判断する場合のPerformanceの違いはどうか?

というのがありますが、「ごみ箱」($SoftDeletions) Viewを舐めて処理するProgramを書いた経験上からすると、数GBに膨れ上がった数万文書のDBのMailをAllDocuments Viewで舐めて処理するのは得策ではないというのが私の判断です。

最後に残った、

4) 発信元Hostを調査できるか?

ですが、これは前回も書いたと思いますが、Spam/Virus Mailの場合、踏み台を使って送信している場合が多くあまりあてになる情報ではありません。
ただ、Spam/Virus Mail調査と言うことを考えると、参考情報として活用出来るかもしれません。
これは、NotesのFieldで言うと、Received Fieldに格納されている情報です。
このFieldもそうなのですが、e-MailからMIMEとして受け取ったMailの場合、RFCのMIME Native e-Mail Fieldとして定義されているFieldがNotesには幾つか存在します。

皆さんも、Mail DBのViewでこういうFieldを表示して、Mailの解析をしたいと思われたことがあるかと思いますが、ViewでField選択して表示しても表示されない経験があるのではないでしょうか?

RFCのMIME Native e-Mail Fieldとして定義されているFieldは単純Viewに表示したりすることは出来ないのです。
ただ、このReceived Fieldに関しては、LotusScriptの以下のMethodが用意されていて、Textとして取り込むことが可能になっています。

GetReceivedItemText (NotesDocument)

これで取得すれば、Domino ServerにMailが到着するまでのSMTP Serverの受信記録が参照できます。


これで、要件定義で出てきた技術的課題がある程度解決できるメドが立ったと言えます。

ただ、Performanceという観点から考えると未知の部分が多く、まだ評価を行わなければいけないと思われます。

世の中のPerformanceの悪いProgramというのは、結局、開発環境で開発/テストを行い、本番を想定したテストが十分でないと言う場合が殆どですので、本番に適用するまでにはPerformance Testの項目も評価項目として文書化して残しておくべきだと思われます。

今回は、要件定義から懸念される技術的課題の検討を行ってみました。

次回は、具体的な設計を考えてみます。

<続く>
 
いいね!(7)  |  コメント(0)  |  リブログ(0)
1 | 2 | 3 | 4 | 5 |最初 次ページ >>

AD

Amebaおすすめキーワード

Ameba人気のブログ

Amebaトピックス

ランキング

  • 総合
  • 新登場
  • 急上昇
  • トレンド

ブログをはじめる

たくさんの芸能人・有名人が
書いているAmebaブログを
無料で簡単にはじめることができます。

公式トップブロガーへ応募

多くの方にご紹介したいブログを
執筆する方を「公式トップブロガー」
として認定しております。

芸能人・有名人ブログを開設

Amebaブログでは、芸能人・有名人ブログを
ご希望される著名人の方/事務所様を
随時募集しております。