|
 |
ソフトウェア > Lotus > Lotus Developer Domain > 製品別技術情報 > Lotus Notes/Domino >
LDD Today
Notes/Domino SMTP を DMZ と共に使用する パート 2
|
|
|
by
David Bell, Senior IT Architect, IBM
Timothy Speed, Senior IT Architect, IBM
レベル：中級
原文の掲載：2004年11月15日
パート 2 では、DMZ 内に Domino Server を設置し、インバウンドとアウトバウンドの SMTP メール・トラフィックを制御するいくつかのシナリオを見ていきます。これによって、会社のリソース保護に役立つ DMZ のセットアップ方法を理解できます。
この連続記事のパート 1では、SMTP メールを DMZ 経由でルーティングするために、Lotus Notes/Domino をどのように設定するのかを説明しました。パート 2 ではこのテーマをさらに掘り下げ、インバウンド・トラフィック用の最初のリレー・ポイントおよびアウトバウンド・トラフィック用の最後のリレー・ポイントを提供するために、DMZ 内で Domino Server をどのように設定するのかを詳しく解説します。これに沿って、いくつかの構成例も紹介していきます。最初の記事と同様に、Lotus Notes/Domino のシステム管理者としての経験があると、この記事で扱う概念を理解しやすいでしょう。まだパート 1 を読んでいない場合は、パート 1からお読みになることをお勧めします。
|
|
こちらからは制御できない、他のシステムからのアクセスを受けるサービスを導入するときは、常にセキュリティを優先させます。DMZ での Domino Server のホスティングも例外ではありません。Domino Server を DMZ に導入するときは、次のガイドラインに従う必要があります。
- オペレーティング・システムをロックダウンし、すべての不要なサービスを無効にする。
外部からの Domino Server への接続は、SMTP メールのルーティングを行うポート 25 だけに制限します。内部ネットワークからは、サーバーを管理するために、システム管理者のアクセスを可能にする Notes NRPC トラフィックが必要です (ディレクトリ情報を複製する場合にも使用されます)。内部パススルーサーバーをプロキシーとして使用し、1 つの IP アドレスのみを用いてファイアウォール経由で DMZ にアクセスします。
- すべての不要なインターネット・プロトコル・ポートを無効にするデフォルトでは、Domino のサーバー文書でポート定義が有効になっています。SMTP ポート以外のすべてのポートを無効にする必要があります。
- 必要な Domino のサーバータスクのみ実行するDomino SMTP サーバーにはタスクのコアセットが必要ですが、それ以外のタスクは実行しないでください。
- サーバーの SMTP グリーティングを変更する使用しているメール・システムをハッカーに知られないようにします。SMTP ウェルカム・バナーを、Lotus Domino やそのバージョン情報を示さない一般的なグリーティングに設定します。これを行うには、Notes.ini 変数の SMTPGREETING を使用します。たとえば、「SMTPGREETING="ESMTP Service ready at %s"」と設定します。%s はシステム日時で置き換えられます。
- Domino Server の登録に内部の認証者を使用しないこれらのサーバー用に新規の認証階層を作成し、システム管理者および内部 Domino Server からのアクセスに対しては、これらのサーバーを相互認証します。内部の階層とは異なる、一般的な命名規則を使用してください。これは、外部に知らされる内部環境に関する情報を最小限にするためです。たとえば、サーバー名は SMTP01/SERVERS/SMTP のようにします。
- サーバーで管理するディレクトリ情報を最小限にする内部 Domino ディレクトリの完全なレプリカを DMZ に置くことは、良い方法ではありません。セキュリティが破られたときに、このレプリカはハッカーやスパマーに大切な情報を与えてしまいます。DMZ サーバーは、独自のドメインに配置してください。これによって、その Domino ディレクトリには、サーバー文書と設定に必要な最小限のグループしか含まれなくなります。認証階層と同様に、ドメイン名も一般的な名前 (たとえば、SMTP) を使用します。
- アドレスの検証が必要な場合は、拡張ディレクトリカタログを使用するDomino SMTP サーバーでインバウンド・メールのアドレスを検証するには、ディレクトリが必要です。この場合も、内部の Domino ディレクトリを公開せずに、ユーザー名とインターネットアドレス情報を持つ拡張ディレクトリカタログを内部のサーバーに作成します。そして、これを Domino SMTP サーバーに複製し、ディレクトリアシスタントを介して参照します。サーバーがタスクを実行するのに必要な最小限の情報だけを公開します。(このタイプの設定については、後で解説します。)
DMZ にサーバーを導入した後は、送信時と受信時の SMTP メール・ルーティングを可能にするために、サーバーを設定する必要があります。
アウトバウンドのルーティング
まず、アウトバウンドから見ていきましょう。内部 Domino Server は、SMTP ゲートウェイにメールを送信できなければなりません。これを行うには、NRPC 接続と SMTP 接続の 2 つの方法があります。NRPC は Domino Server がメール・ルーティングと複製を行うときの標準で、内部ファイアウォール経由の 1352 ポートでのアクセスが必要です。SMTP サーバーは内部サーバーと同じドメイン内に配置できないので、SMTP サーバーは Notes 名前付きネットワークを共有できません。このため、メール・ルーティングの接続文書が必要です。
より単純な方法は、1 つ以上の内部 Domino Server に対し、DMZ 内のこれらのサーバーへの SMTP のルーティングをポート 25 で許可することです。このとき、DMZ に送信する内部の各 Domino Server ごとに 1 つのリレーを指定しなければなりません。リレーホストの名前は内部の DNS で 1 つ以上の MX レコードとして解決されることが必要で、これによって予備のルーティングパスが得られます。
パート 1の記事では、DMZ のインターネットに面するサーバーと内部のトラステッド・ネットワークのサーバー間で、異なる SMTP TCP ポートを使用する例を示しました。会社でこの方法が必要な場合は、ポートリスト TCP 2222 を使用してください。この方法は、2 つのサーバー・グループ間に Notes NRPC を使用することによっても実現できます。インターネットに面するサーバーは TCP ポート 25 (標準どおり) で待ち受け、DMZ の内部を通過するトラフィックは TCP ポート 1352 を介してルーティングされます。
インバウンドのルーティング
インターネットから SMTP サーバーへのインバウンドのルーティングは、外部 DNS の MX レコードを使用して処理されます。この MX レコードによって、インバウンド・メールの送信先のサーバーが決められます。メッセージが DMZ 内の Domino SMTP サーバーに到達すると、インバウンドパスを続行するために、メッセージの次のホップを決める必要があります。この段階では、受信したすべてのインバウンド・メールを 1 つ以上の内部 Domino Server に送信するものとします。
これは、スマートホストが行う作業です。これはたいへん簡単な方法で、DMZ 内の Domino Server に対し、受信した内部 SMTP ドメイン宛のすべてのメールを特定のリレー・アドレスに渡すように指示します。予備のパスが利用できる場合は、ルーティングパスの優先順位を制御するために、このリレー・アドレスは DNS の 1 つ以上の MX レコードに対応している必要があります。
ルーティングのシナリオ
これらの概念を次のシナリオと図を用いて説明します。以下の図で、赤色のパスはプライマリ・ルートを示し、青色のパスはプライマリ・パスが使用できないときのバックアップ・ルートを示します。
シナリオ A: 単一の Point-of-Presence と複数の SMTP サーバー
このシナリオでは、SMTP1 がプライマリ・アウトバウンド・パスで、SMTP2 がプライマリ・インバウンド・パスとなります。サーバー障害のときは、それぞれがお互いのバックアップ・パスとして機能します。
図 1. 単一の Point-of-Presence と複数の SMTP サーバー
インバウンド・ルーティングのフローは次のとおりです。
- メール・サーバーは DNS で acme.com を検索し、利用可能な 2 つのホスト SMTP1 と SMTP2 を見つけます。
- SMTP2 は MX プリファレンスとして最小の値を持つので、インバウンド・メール・リレーとして優先されます。このため、メールは SMTP2 へルーティングされます (SMTP2 が利用可能な場合)。それ以外の場合は、メールは SMTP1 へルーティングされます。
- SMTP1 と SMTP2 は inbound.acme.com のスマートホスト・エントリを解決し、次のホップの候補として 2 つのホスト HUB1 と HUB2 を見つけます。
- HUB1 が利用できる場合は、SMTP サーバーは HUB1 にリレーし、HUB1 が利用できない場合は HUB2 にリレーします。
- メールが HUB1 または HUB2 に到達すると、通常の Notes メール・ルーティングが発生します
アウトバウンド・ルーティングの流れも同様で、次のようになります。
- HUB1 と HUB2 に、外部インターネット・アドレス宛のメールがあります。
- これらのハブはリレーホストのエントリ outbound.acme.com を解決し、利用可能な 2 つのホスト SMTP1 と SMTP2 を見つけます。
- 優先されるアウトバウンド・サーバー (SMTP1) は、MX プリファレンスとして低い値を持ちます。このため、メールはそのサーバーにルーティングされます (サーバーが利用できる場合)。このサーバーが利用できない場合は、HUB サーバーは SMTP2 にルーティングします。
- SMTP サーバーは DNS で受信者のドメイン (destination.com) を検索し、返された MX レコードに従ってホストに接続します。
サーバーごとに、MX レコードの優先度を変える必要はありません。インバウンドとアウトバウンドのメールをサーバー間で均等に振り分けたいときは、各サーバーのペアで MX レコードのプリファレンス値を等しくします。
インバウンドとアウトバウンドに異なるルートを用いるのは一般的な方法です。このようにすることで、通常の状況でのトラブルシューティングが容易になるからです。これらの各ポイントごとに 1 つのサーバーを設定する方法は、考えられる最も簡単な設定といえるでしょう。各ポイントに複数のサーバーを配置すると、サーバー障害に対する弾力性が高まります。
シナリオ B: 複数の Point-of-Presence と複数の SMTP サーバー
ISP ネットワーク接続や災害などの大きなサイト障害からシステムを保護するには、より複雑な枠組みが必要となります。このような状況では、複数の Point-of-Presence を使用するとたいへん効果的です。このシナリオでは、2 つの Point-of-Presence を用いるケースを説明しますが、必要であれば、カバーする範囲を広げるために、数を何倍にも増やすことができます。
メール・ドメインが単一のエントリで (例: acme.com)、「サブドメイン」の部分 (例: us.acme.com や eu.acme.com) を持たない場合は、メールはバックアップ・パスを持つメインの Point-of-Presence にルーティングされます。サブドメインを持つ場合は、各サブドメイン宛のメールが、適切なローカルの Point-of-Presence にルーティングされます。この Point-of-Presence がメインとなり、他の Point-of-Presence はバックアップ用です。
次の例では、ドメインは acme.com で、障害がない限り、すべてのメールは単一の Point-of-Presence に送信されます。
図 2. シナリオ B のインバウンド・ルーティング
インバウンド・ルーティングのフローは次のとおりです。
- メール・サーバーは DNS で acme.com を検索し、利用可能な 4 つのホスト SMTP1 ～ SMTP4 を見つけます。
- SMTP2 は MX プリファレンスとして最小の値を持つので、インバウンド・メール・リレーとして優先されます。このため、メールは SMTP2 へルーティングされます (SMTP2 が利用可能な場合)。
- SMTP2 が利用できない場合は、SMTP1 が次に優先されるインバウンド・リレーとなります。SMTP1 も利用できない場合は、SMTP4 が次に優先され、最後は SMTP3 になります。
- メールが SMTP1 または SMTP2 にリレーされると、inbounda.acme.com に対するスマートホストのエントリを解決し、次のホップとして利用可能な 4 つのホスト HUB1 ～ HUB4 を見つけます。最も優先されるのは HUB1 で、以下、HUB2、HUB3、HUB4 の順になります。
- メールが SMTP3 または SMTP4 にリレーされると、inboundb.acme.com に対するスマートホストのエントリを解決し、次のホップとして利用可能な 4 つのホスト HUB1 ～ HUB4 を見つけます。最も優先されるのは HUB3 で、以下、HUB4、HUB1、HUB2 の順になります。
- 優先される HUB サーバーが利用できる場合は、SMTP サーバーはその HUB サーバーにリレーします。それ以外の場合は、MX プリファレンスの順に従って、代わりの HUB サーバーを使用します。
- メールが内部の HUB レイヤーに到達すると、通常の Notes メール・ルーティングが発生します。
アウトバウンド・ルーティングも同様です。
図 3. シナリオ B のアウトバウンド・ルーティング
図 3 について説明します。
- HUB1 ～ HUB2 に、外部インターネット・アドレス宛のメールがあります。
- HUB1 または HUB2 がメールを受信すると、リレーホストのエントリ outbounda.acme.com を解決し、利用可能な 4 つのホスト SMTP1 ～ SMTP4 を見つけます。SMTP1 が最も優先されるメインのルートで、以下、SMTP2、SMTP3、SMTP4 の順となります。
- HUB3 または HUB4 がメールを受信すると、リレーホストのエントリ outboundb.acme.com を解決し、利用可能な 4 つのホスト SMTP1 ～ SMTP4 を見つけます。SMTP3 が最も優先されるメインのルートで、以下、SMTP4、SMTP1、SMTP2 の順となります。
- 優先される SMTP サーバーが利用できる場合は、HUB サーバーはその SMTP サーバーにリレーします。それ以外の場合は、MX プリファレンスの順に従って代わりの SMTP サーバーを使用します。
- SMTP サーバーは DNS で受信者のドメイン (destination.com) を検索し、返された MX レコードに従ってホストに接続します。
基本的な概念はシナリオ A と同様で、少し複雑になっているだけです。障害発生時には、すべてのサーバーが、acme.com 宛のメールの送信先として、より多くの選択肢を持ちます。これにより、個々のサーバーからサイト全体または Point-of-Presence に至るまで、幅広い障害に対処できる非常に弾力性の高いアーキテクチャーが得られます。
シナリオ A とシナリオ B のもう 1 つの大きな違いとして、SMTP リレーホストのエントリが各 Point-of-Presence ごとに異なる点が挙げられます。これにより、各 Point-of-Presence へのルーティングまたは各 Point-of-Presence からのルーティングを個別に制御できます。この場合も、MX プリファレンス値を変えて優先とバックアップを区別する代わりに、MX プリファレンスを等しい値に設定し、ルーティングのバランスを取ることも可能です。
スマートホストを使用する
スマートホストはインバウンド・メールのルーティング (ローカル・ドメインの受信者) を処理し、リレーホストはアウトバウンド・メールのルーティング (外部ドメインの受信者) を処理します。スマートホストのエントリは各サーバーに固有で、サーバー設定文書で設定されています。複数のサーバーがリレーの次のホップとしてまったく同じ選択肢を持つ場合は、複数のサーバー用に同じスマートホスト・エントリを使用することができます。
しかし、前にも説明したように、複数のホストでルーティングの優先順位 (またはコスト) を設定するときは、それぞれ個別の MX プリファレンスとして解決される複数のスマートホスト・エントリを使用する必要があります。スマートホスト・リレーのエントリは、サーバー設定文書の [ルーター/SMTP] - [基本] タブにあります。
図 4. [ルーター/SMTP] - [基本] タブ
![[ルーター/SMTP] - [基本] タブ](i/20041115_1_04.gif)
[ローカルインターネットドメインスマートホスト] を指定するだけでなく、サーバーがすべてのローカルメールをスマートホストにリレーすることを示すために、[すべてのローカルインターネットドメイン受信者用にスマートホストを使用] を有効にする必要があります。これを有効にしないと、Domino Server は利用可能なすべてのディレクトリで見つけられない受信者宛のメールだけをリレーします。拡張ディレクトリカタログ (後で説明します) を使用してアドレスの検証が行われる場合は、受け入れられたメッセージだけがディレクトリにエントリを持つ必要があります。この設定を有効にしないと、Domino はこれらのメッセージをスマートホストにリレーしません。
このセクションでは、DMZ を使用するときの Domino Server の設定例を 2 つ紹介します。1 つはユーザー情報を含むディレクトリを持たない Domino Server の例で、もう 1 つはユーザーディレクトリ情報を持つ Domino Server の例です。
ユーザーディレクトリ情報を持たない Domino Server
このケースでは、Domino Server はリレーとして機能するよう設定されます。Domino Server はユーザーディレクトリ情報にアクセスする権限を持たないので、メールアドレスの検証を行うことはできません。前述のとおり、内部の実動ドメインのディレクトリのレプリカを DMZ に置くことは好ましくありません。この設定を次の図に示します。
図 5. ユーザーディレクトリ情報を持たない Domino Server
Domino SMTP サーバー上の Domino ディレクトリには、システム管理者の認証に必要な情報以外のユーザー情報はまったく含まれていません。DMZ には、内部 Domino ディレクトリからの情報は公開されません。
ディレクトリ情報を持つ Domino Server
スパム・メールを最も早い段階でブロックするために、通常は、受信メールのアドレスを何らかの方法で検証することが推奨されます (スパムは、ランダムに作成されたメールアドレスに送信されることがよくあります)。目的は、正当な内部受信者宛のメールだけを通過させることです。これを行うには、Domino SMTP サーバーがディレクトリを持ち、これに対してアドレスを比較して検証し、正当な受信者かどうかを識別します。正当でないものは拒否します。
もう一度繰り返しますが、情報のセキュリティは最も優先しなければなりません。では、内部 Domino ディレクトリをこれらのサーバーに複製したくないとき、アドレスの検証にはどのディレクトリを使用すればよいのでしょうか。この場合、最も簡潔で効果的な解決方法は拡張ディレクトリカタログ (EDC) を使用することです。EDC を使用すると、次の利点が得られます。
- どの情報を内部ディレクトリから取り出し、EDC に集約するかを制御できます。
- ディレクトリの作成と管理を行う内部メカニズムがあります。これは、Directory Cataloger タスクと呼ばれます。
- 複製は堅牢かつ実装が容易な配布メカニズムです。
では、この方法は、ディレクトリ情報を持たない Domino Server を使用する方法とどこが異なるのでしょうか。図 6 にアーキテクチャーを示します。
図 6. ユーザーディレクトリ情報を持つ Domino Server
Directory Cataloger タスクは、内部ドメインにあるサーバー上の EDC を維持する役割を持ち、収集されるユーザー情報が含まれるソース・ディレクトリへのアクセス権を持ちます。しかし、すべての内部ディレクトリ情報が EDC に収集されるわけではありません。
EDC を作成するには、Domino ディレクトリの標準テンプレートに基づいて新規のデータベースを作成します (ここでは、例として smtpedc.nsf というデータベースにします)。これは、モバイルディレクトリカタログの作成とは異なります。モバイルディレクトリカタログは圧縮されていて、検索を行うには全文検索が必要です。EDC には、標準の Domino ディレクトリと対応するすべてのビューが含まれていて、これらのビューで検索を実行できます。
このデータベースを作成した後は、非常に厳しい ACL を設定します。必要な ACL エントリの例を下図に示します。
| ACL エントリの名前 |
アクセス権 |
追加する権限 |
| - Default - |
[なし] |
なし |
| Anonymous |
[なし] |
なし |
| AcmeAdministrators |
[管理者] |
[文書の削除] |
| */SERVERS/SMTP |
[管理者] |
[文書の削除] |
| HUB1/SERVERS/ACME |
[管理者] |
[システム管理サーバー] |
|
| メモ: | DMZ 内のサーバー間で EDC を相互に複製する場合は、*/SERVERS/SMTP が必要です。 |
|
最後に、EDC 設定文書を作成します。
図 7. EDC 設定文書の作成
[基本] タブの [追加で取り込むフィールド名] オプションで、[InternetAddress] を選択します (サーバーは、このフィールドを使用して受信メールの受信者名を比較します)。[集約を制限するサーバー] フィールドで、情報の集約と処理レポートの作成を行うサーバーを指定します。レポートは、システム管理者に送信され、問題が発生していないか監視されます。
図 8. 拡張ディレクトリカタログの [基本] タブ
![拡張ディレクトリカタログの [基本] タブ](i/20041115_1_08.gif)
[詳細] タブでは、ソースの内容をより詳細に制限するために、複製の選択式を入力できます。DMZ を使用する例では、有効なインターネットアドレスの値を含むユーザー、グループ、メール受信データベースの各エントリだけを集約します。これによって、インターネット・メールの受信者は、これらのエントリに該当する人だけに制限されます。
図 9. 拡張ディレクトリカタログの [詳細] タブ
![拡張ディレクトリカタログの [詳細] タブ](i/20041115_1_09.gif)
エントリを制御する別の方法として、ディレクトリの各エントリに表示される [他のディレクトリとの同期を許可] オプションを使用できます。このオプションを使用すると、選択式による制限に、さらに制限を追加できます。
指定した集約サーバーのサーバー文書で、作成した EDC が、集約スケジュールに従って処理されるカタログとして設定されている必要があります。これを行うには、[ディレクトリカタログファイル名] フィールドに EDC のファイル名を入力します。
図 10. ディレクトリカタログのファイル名
次に、スケジュールに従って EDC を DMZ に複製し、情報を最新の状態に保ちます。ディレクトリカタログの集約スケジュールと複製スケジュールによって、新規ユーザーが正規受信者として認識されるまでの時間が決められます。この点には注意が必要です。
さらに、Domino SMTP ゲートウェイに対し、この二次ディレクトリを参照するよう設定しなければなりません。この参照を有効にするには、ディレクトリアシスタントのセットアップが必要です。まず、DMZ 内のサーバーで [ディレクトリアシスタント] データベースを作成します。ここでは、例として dmzda.nsf というデータベースを作成します。このデータベースは、設定後、各 SMTP サーバーに複製してください。
[ディレクトリアシスタント] データベースで、EDC を示すエントリを作成します。[基本情報] タブで、ドメイン名を入力し、エントリが有効になっていることを確認します。
図 11. ディレクトリアシスタントの [基本] タブ
![ディレクトリアシスタントの [基本] タブ](i/20041115_1_11.gif)
サーバーが任意のレプリカを利用できるようにするために、[レプリカ] タブで、サーバー名のフィールドにアスタリスク (*) を入力します。次に、EDC データベース名を入力し、このタブでも有効になっていることを確認します。
図 12. ディレクトリアシスタントの [レプリカ] タブ
![ディレクトリアシスタントの [レプリカ] タブ](i/20041115_1_12.gif)
各 Domino SMTP サーバーのサーバー文書で、ディレクトリアシスタントのデータベース名を適切なフィールドに追加します。
サーバー文書を変更した後は、変更内容を有効にするために、サーバーを再起動します。サーバーの再起動後、ディレクトリが参照されていることを確認するために、サーバーコンソールで「SHOW XDIR」を入力します。次のような出力が表示されます。
図 13. SHOW XDIR の出力
EDC とディレクトリアシスタントを設定した後は、アドレスの検証を有効にできます。これを行うには、SMTP サーバーのサーバー設定文書で [ルーター/SMTP] - [基本] タブを表示し、アドレス参照を [フルネームのみ] に設定します。この設定により、サーバーは完全なインターネット・メールアドレスを検索で使用するようになります。つまり、ローカル・パートだけを分離してローカル・パートで名前を一致させることを防止できます。次に、[ルーター/SMTP] - [制限と制御] - [SMTP インバウンド制御] タブで、ローカルドメインでの受信者の確認を有効に設定します。
これで、Domino SMTP サーバーが、作成および設定した EDC に対してアドレスの検証を実行するようになりました。正しい受信者のアドレスと不正なアドレスを使用してメールを送信し、サーバーの動作をテストします。サーバーコンソールを見て、不正なメールがポリシー上の理由で拒否されることを確認してください。正しい宛先のメールは、インターネット・ドメインにルーティングされます。
この連続記事では、Domino ベースのセキュアな SMTP サービスを設定するいくつかのシナリオを見てきました。これまでに説明したように、多くの種類のコンポーネントをこの目的のために利用できます。
この記事で取り上げたものは次のとおりです。
- 社内の独立したトラステッド・ネットワーク
- トラステッド・ネットワークと信頼されていないインターネットを分離する DMZ
- Lotus Domino によるワールドクラスの SMTP サービス
- Domino SMTP の先進のセキュリティ機能 (リレーおよびスパムの防止、 DNS ブロックなど)
- さまざまな DMZ 設定
- MX レコードを介した DNS 設定
- Notes 名前付きネットワーク
- 障害復旧のための設定
これらの内容を選択して組み合わせることにより、ビジネスの目的に応じた SMTP アーキテクチャーを構築できます。
現在では、SMTP が電子メールのサービスとして選択されています。しかし、ほとんどのエンド・ユーザーは、この事実を知らないか、あるいは気にしていません。このため、セキュアで効率的なソリューションを構築することは、あなたの腕にかかっています。Lotus Domino には、これを行うためのツールと機能が用意されています。
筆者について(原文のまま)
David Bell is a Senior IT Architect with the IBM Software Group, specializing in services for the Lotus Software brand of products. In that capacity, he is responsible for anticipating and resolving technical issues that arise in the course of consulting engagements and for designing, building, and implementing messaging infrastructures that meet customer needs. He works with customers to facilitate the formulation and execution of information strategies that are innovative and well aligned with their business goals. David has been working with Lotus Notes and Domino since the 1990s, designing and implementing architectures for organizations of all sizes.
Timothy Speed is an infrastructure and security architect for IBM Software Services for Lotus (ISSL). Tim has been involved in Internet and messaging security since 1992. He also participated with the Domino infrastructure team at the Nagano Olympics and assisted with the Lotus Notes systems for the Sydney Olympics. His certifications include MCSE©, VCA (VeriSign Certified Administrator), Lotus Domino CLP Principal Administrator, and Lotus Domino CLP Principal Developer. Tim has also co-authored four books: The Internet Security Guidebook, ISBN: 0122374711, February, 2001; The Personal Internet Security Guidebook, ISBN: 0126565619, October, 2001; Enterprise Directory and Security Implementation Guide: Designing and Implementing Directories in Your Organization, ISBN:0121604527; and Internet Security: A Jumpstart for Systems Administrators and IT Managers, ISBN 1555582982.
|
|
|
|
|
