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


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


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

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

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

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


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


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

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


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


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

1 | 2 | 3 | 4 | 5 |最初 次ページ >>
August 14, 2016

不正なMIME FormatのMailを解釈する問題

テーマ:Trouble Info
最近、Spam/Virus Mailなど、非常に多くなっています。

その対応の為にSMTP Server上で、添付ファイルの検査や、送信元の検査を行い、社内への侵入を防ぐ措置を取られている会社も多いと思います。

ところが、最近、意図的なのかそうでないのか分かりませんが、MIMEのMulti-PartのFormatを無視したMailが届くことがあります。

Multi-PartのMIMEはBoundaryという境目を定義して、その中に本文や添付ファイルを納めていますが、Boundaryが宣言されて終了するまでがMulti-PartのMIME Messeageと解釈するのが一般的です。

ところが、最近のSpam/Virusで、このBoundaryを複数定義するMIMEがあることが分かっています。
意図的なのか、そうでないのかは不明ですが、このFormatで来ると、一般的なAnti-Spamが出来ると言っているSMTP Mail Serverをすり抜けてしまうのです。

一般的なAnti-Spamを提供するServiceでは、RFCで定義されたMIMEの範囲を検査しますが、上記のような不正なBoundary定義があると、最初のBoundaryでMailの内容は終わりであると判断してそれ以上の解析は行いません。

しかし、SMTPでの検査ですから、不正なMIMEで検査が不十分であったとしても、原本のまま皆さんの会社に届いてしまうわけです。
SMTP Serverは元のMessageを改ざんしたりはしませんので、当たり前の動きと言えるかも知れません。

こういうMailが届いた場合、後はクライアント側での処理に依存することになるのです。

私が知っている限り、Thunderbirdでは、このMailの後半のBoundaryが表示されることはありません。

ところが何故か、Notes/DominoではNotes/iNotes Client共に表示されるのです。

つまり、2番目のRFC的には不正なBoundaryに添付ファイルなどがあっても表示されてしまうのです。
これは致命的と言わざるを得ない状態です。

内容がかなりセンシティブなため、公開を控えていましたが、IBMさんの対応が不明なため、敢えて公開させて頂きます。

いつもIBMさん(特にUS開発部門)からは、Notes/DominoはRFCに厳格だと言われてきた記憶があるので、今回の件は徹底的に追及したいと思います。
いいね!した人  |  コメント(0)  |  リブログ(0)
最近の画像つき記事
 もっと見る >>
July 21, 2016

iNotesのArchive Policyの仕組みを解明したい! -7-

テーマ:Test Lab.
<話題の履歴>

iNotesのArchive Policyの仕組みを解明したい! -1-
iNotesのArchive Policyの仕組みを解明したい! -2-
iNotesのArchive Policyの仕組みを解明したい! -3-
iNotesのArchive Policyの仕組みを解明したい! -4-
iNotesのArchive Policyの仕組みを解明したい! -5-
iNotesのArchive Policyの仕組みを解明したい! -6-


前回は、既存のUserを含め、Archiveを有効/無効にするには何がKeyになっているかを確認し、運用Planを考えてみました。

今回は、Archiveを有効/無効にするために、どのProfile文書を更新するのが良いのかを考えていきます。


今回は、まず、新規にUserを作成して、Compact -Aを実行した後のArchive Profileの内容を確認してみます。

以前紹介したToolではNotes Clientから確認することになり、Archive Profileの更新が行われてしまいますので、今回は昔からあるNotesPeekで確認しながら進めてみたいと思います。
また、あのToolを使うと、意味不明なProfile文書が出来ていましたので、信用しないことにします。
もし、NotesPeekでもダメなら、LotusScriptでProfile DocumentのCollectionを収集して処理するしかないです。

さて、新規Userを作成します。
新規Userには、Organizational Policyが適用された状態で作成されます。
つまり、Archiveは全面禁止という状態です。

iNotes_Archive_35

これで、NotesPeekからProfile Documentの状態を確認します。

iNotes_Archive_36

CalendarProfileとiNotesProfileだけ作成された状態になっていることが確認できます。

ではここで、Archive Policyを適用して、Compact -AでArchiveを実施してみます。

> load updall names.nsf -t "($ServerAccess)"
[1078:0002-0118] 2016/06/15 20:43:09 Index update process started: names.nsf -t ($ServerAccess)
[1078:0002-0118] 2016/06/15 20:43:09 Updating C:\IBM\Domino\data\names.nsf view '($ServerAccess)'
[1078:0002-0118] 2016/06/15 20:43:09 Index update process shutdown
> load compact -A mail\
[0E80:0004-050C] 2016/06/15 20:43:18 Archiving documents from mail\administ.nsf (Administrator)
[0E80:0004-050C] 2016/06/15 20:43:18 Archiving documents from mail\hiwama.nsf(Hanako Iwama)
[0E80:0004-050C] 2016/06/15 20:43:18 Archiving documents from mail\iiwama.nsf(Ichiro Iwama)
[0E80:0004-050C] 2016/06/15 20:43:19 Pushing mail\iiwama.nsf to archive\a_iiwama.nsf
[0E80:0004-050C] 2016/06/15 20:43:19 Pushing mail\iiwama.nsf to archive\a_iiwama.nsf
[0E80:0004-050C] 2016/06/15 20:43:19 アーカイブ: データベース mail\iiwama.nsf
のアーカイブプロフィール文書に問題があるので、削除する必要があります。
[0E80:0004-050C] 2016/06/15 20:43:19 Archived mail\iiwama.nsf, 0 documents were archived and 0 were deleted
[0E80:0004-050C] 2016/06/15 20:43:19 Archiving documents from mail\siwama.nsf(Shinya Iwama)
[0E80:0004-050C] 2016/06/15 20:43:19 Archiving documents from mail\tiwama.nsf(Taro Iwama)
[0E80:0002-0DF0] 2016/06/15 20:43:20 Database compactor process shutdown

Archiveは正常に実行されたようなので、NotesPeekで再度確認します。

ここで、Archive ProfileとColorProfileが作成されたことが分かります。

iNotes_Archive_37

では、Archive Profileの内容を見てみます。
Archive Profileは作成されましたが、Archive Plicyで配布したArchive条件の文書をどこで指しているのかはわかりません。

iNotes_Archive_38

ColorProfileやiNotesProfileの内容を確認してみてもこれといった情報は見つからないのです。

iNotes_Archive_39

では、ここで、BrowserからiNotesでAccessしてみることにします。
iNotesでは既に、Archiveが有効な状態になっていることが確認できます。

iNotes_Archive_40

この時点で、再度NotesPeekから、Profile Documentの内容を確認します。
これまで無かったProfile文書が追加されたことが分かります。

iNotes_Archive_41

iNotesViewProfileとDolsOfflineConfigration、Archive Database Profileには大した情報は入っていません。
ただ、Archive Database Profileに値が入ったことで、Archive条件文書が参照可能になったのではないかと考えられます。

iNotes_Archive_42

iNotesViewProfileが新しく出来ているのも、Archive対象としてViewを指定しているからだと思われます。

こうして考えていくと、Archive Profile、iNotesViewProfile、Archive Database ProfileがArchive PolicyからiNotesでのArchive MenuをControlする要素になっているのではないかと考えられる訳です。

では、意地悪してこれらのProfile Documentを消してみたらどうなるのか?というのは、読者の皆さんも思われるのではないでしょうか?
私も、同じで、iNotes Accessから出来てしまったProfileというのは、iNotesでの用途に使われていることは明らかなので、順番に消してみたいという衝動に駆られます。

今回実行するには、記事が長くなってしまいますので、削除の試験は次回に持ち越したいと思います。


今回は、NotesPeekを使って、Profile Documentの内容を把握しながら、どのようなProfile Documentに変化があるのかを見てみました。

次回は、iNotesでAccessして追加されたProfile Documentを削除することでどのような変化があるのかを見てみたいと思います。

<続く>
いいね!した人  |  コメント(0)  |  リブログ(0)
July 18, 2016

iNotesのArchive Policyの仕組みを解明したい! -6-

テーマ:Test Lab.
<話題の履歴>

iNotesのArchive Policyの仕組みを解明したい! -1-
iNotesのArchive Policyの仕組みを解明したい! -2-
iNotesのArchive Policyの仕組みを解明したい! -3-
iNotesのArchive Policyの仕組みを解明したい! -4-
iNotesのArchive Policyの仕組みを解明したい! -5-


前回は、新規Userを作成してiNotesだけで運用した場合の動作の検証を行いました。

今回は、既存iNotes UserのArchive Profileを再有効化した場合を検証します。


まずは、前回新規に作成したUserを再度Archive Policyを適用します。
PolicyがAssignされたことを確認後、BrowserでF5で更新して状態を確認すると、Archive Menuが復活することが分かります。

iNotes_Archive_34

どうやら、Preferenceの保存をすることなく、設定が反映します。
以前試験した際は、Preferenceを保存しなければ反映しなかったのですが、新規に作成したUserの場合は最初にPreferenceを保存するだけでArchiveが有効になり、その後はPreferenceの保存は必要ないようです。
ところが、このUserから再度Archive Policyを除外して見ると、Archive Menuは残ったままです。
この場合、Preferenceを保存することで、Archive Menuが消えました。
再度有効にした際も、Preferenceを保存することでArchive Menuが現れます。
同様に、Preference保存ではなく、HTTPをRestartすることでも、Archive Menuの状態が変化することが分かりました。
ということは、iNotes Preferenceの保存が重要なのではなく、HTTPのCacheがResetされることが重要なのではないかと思われます。
iNotes Preferenceの保存は、HTTP CacheをRefreshするための方法でしかないのでは
ないでしょうか?

他の既存User(新規Userとは異なり、最初はLocal Archiveが許可されていたUser)でも試してみると、同様にHTTP RestartでMenuの状態が変化することが分かりました。
しかし、運用を考えると、HTTP Restartを行うわけにはいきませんので、ProgramからPreferenceを更新することを考えた方が良いでしょう。

ただ、ProgramからPreferenceを再保存するにしても、複数Serverで運用されている環境では、Groupの更新はSystem Administration Serverで行われ、各ServerにReplicaが回ってから更新する必要があります。
そういう意味からは、Mail TemplateにAgentを仕込んで、毎晩実行される定期Agentとして運用するのが良いのかも知れません。

今回の一連の実験から分かったことは、

1) 新規Userの場合は、Compact -AでArchiveを実行することで"Archive Profile"にArchive条件が書き込まれ、Archiveが有効になる。

2) Archive Policyを即時に反映させたい場合は、Updall names.nsf -t "($ServerAccess)"を発行し、Serverの隠しViewを更新してGroup Cacheを最新の状態にする必要がある。

3) Archiveの有効/無効化を行った後、Archive Menuの表示を適切にするには、iNotes Preferenceを保存するか、HTTPをRestartして、HTTPのCacheを最新の状態に更新する必要がある。

ということだと思います。

これが分かれば、どういう運用をすれば良いかが見えてきます。

つまり、

1) System Administration ServerでArchiveを有効にするUserを含んだGroupのMemberの変更処理を夜間のAgentで実行する。

2) 同時に、GroupのMemberの増減をCheckして、削除されたMemberのArchive Viewへの振り分けAgentを無効にし、追加されたMemberのArchive Viewへの振り分けAgentを有効にする。

3) Replication Scheduleを考慮し、System Administration Serverからの
names.nsfのReplicationが終わった後に、各Mail ServerのProgram文書でCompact -Aを実行する。

4) UserのMail DBに定期実行Agentを仕込み、出社前とかにProfile Documentを更新する。

これで、ほぼ目的は達成できるのではないかと思われます。

最後のProfile Documentの更新ですが、これまでの実験結果から、Archive Profileが更新されればArchive Menuの表示が変わると思われますが、この点はもう少し検証してみたいと思います。

今回は、既存のUserを含め、Archiveを有効/無効にするには何がKeyになっているかを確認し、運用Planを考えてみました。

次回は、Archiveを有効/無効にするために、どのProfile文書を更新するのが良いのかを考えていきます。

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

AD

Ameba人気のブログ

Amebaトピックス

      ランキング

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

      ブログをはじめる

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

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

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

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

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