Zimbra Collaboration Administrator Guide version 8.8.3

ユーザー認証向けにシステムに実装された主な機能は、次の表にまとめられています。

データ保全を目的としてシステムに搭載した機能を下の表にまとめました。

(SNMPトリガーで生成される) Zimbra Collaboration のシステムログは、データ保存に使用できます。このデータは例えばユーザーや管理者の行動やログインの失敗、クエリ遅延、メールボックスにおける行動、モバイルシンクアクティビティ、データに関するエラーです。お使いのシステムのセキュリティおよびコンプライアンス要件に従い、イベントやアラート、トラップなどをログ管理とイベント修正システムへと転送して、通知およびポリシーを一元化できます。

Zimbra Collaboration サーバーは外部のインターネットへ接続し、Zimbraのライセンスサーバーへ接続可能の場合、ライセンスのアクティベーションが自動的完了します。ただし、自動的にライセンスをアクティベーションできない場合、 手動でのライセンスのアクティベーションについてを参照してください。

使用しているシステムがZimbraライセンスサーバーへ正常に接続できない場合、 Zimbraのサポートポータルを使用し、手動でライセンスのアクティベーションを実行できます。Zimbraサポートポータルで手動のアクティベーションを実行する場合、Zimbraのホームページ(www.zimbra.com)へアクセスし、Support をクリックししてください。Zimbraのテクニカルサポートページが表示されます。Zimbra Collaboration Suport をクリックサポートポータルへアクセスするメールアドレスとパスワードを入力してログインします。サポートポータルにて、Manual Activationを実行してください。

サポートポータルにアクセスできない場合、sales@zimbra.com までZimbraの営業日にお問い合わせください。

Zimbra Collaboration のサーバーライセンスをインストールまたはアクティベートできていない場合、使用中のZimbra Collaborationサーバーに以下の影響がでます。

アカウントを作成するには、 Zimbra Collaboration のライセンスが必要です。なお、Zimbraライセンスを新たに購入、更新、または変更した場合、Zimbraサーバーにも最新のライセンス情報に更新する必要があります。管理コンソールにあるグローバル設定ページから ライセンスを更新ウィザード を使用することで、新しいライセンスのアップロードとインストールもできます。 ライセンスのアクティベーション を使用すると、インストールしているライセンスのアクティベーションが実行されます。

ホーム > 設定 > グローバル設定 > ライセンス にてアクセスした現在のライセンス情報ページに、ライセンスID、利用開始日、満了日、購入アカウント数、および使用可能アカウント数が表示されます。

使用中のアカウント数が購入アカウント数に達した場合は、アカウントの新規作成ができなくなります。なお、ライセンスに作成可能のアカウント数を追加で購入、または、既存の(使用していない)アカウントを削除することで、アカウントの新規作成が可能となります。ライセンスに作成可能のアカウント数を追加で購入する場合は、Zimbraの営業部までご連絡ください。

Zimbraのネットワーク版の機能を中断せずに継続使用する場合、ライセンスの満了日より30日間前に更新する必要があります。なお、ライセンスが満了されるまで30日間以内の場合、管理コンソールにリマインド用の通知メッセージが表示されます。

Zimbra Collaboration のネットワーク版のライセンスが満了した場合、管理コンソール、およびすべてのユーザーのウェブクライアントにて、ライセンスが満了された警告メッセージが表示されます。ライセンスの満了から30日間の猶予期間が発生します。猶予期間内では警告メッセージが表示されますが、すべての機能は継続して使用できます。

なお、猶予期間が終了しますと、サーバーがオープンソース版の機能へ自動的に切り替わります。ライセンス満了後、以下の重要な機能が使用できなくなります。

ライセンス契約した最大ユーザー数に達すると、ライセンスを満了した環境に新しいアカウントの作成ができなくなります。

なお、ライセンスを更新する予定はない場合、Zimbra Collaborationの無料オープンソース版(FOSS)へアップグレードすることで、新しいアカウントの作成と既存アカウントの削除が可能になります。その場合、Zimbra Collaborationのネットワーク版と同バージョンのFOSS版を選択してから、最新のFOSS版へ更新することをお勧めします。

使用中のアカウント数が購入アカウント数に達した場合は、アカウントの新規作成ができなくなります。なお、ライセンスに作成可能のアカウント数を追加で購入、または、既存の(使用していない)アカウントを削除することで、アカウントの新規作成が可能となります。ライセンスに作成可能なアカウント数を追加で購入する場合は、Zimbraの営業部までご連絡ください。

Zimbraのネットワーク版の機能を中断せずに継続で使用する場合、ライセンスの満了日より30日前に更新する必要があります。なお、ライセンスが満了されるまで30日以内の場合、管理コンソールにリマインド用の通知メッセージが表示されます。

メッセージの本文と添付ファイルを含め、メッセージの内容は全て、メッセージストア内にMIMEフォーマットにて保存されます。

メッセージのストアは各メールボックスサーバーの /opt/zimbra/store 配下にデフォルトで格納されます。各メールボックスには、各自の名部ZCSメールボックスIDにちなんだ名称のディレクトリがあります。メールボックスのIDは各サーバー内では一意ですが、システム全体としては一意ではありません。

複数受信者を持つメッセージは、メッセージ保存領域内に１件のみ保存されます。UNIXシステム上にある、ユーザーごとのメールボックスディレクトリには、実際のファイルへのハードリンクが入っています。

Zimbra Collaboration をインストールすると、各メールボックスサーバーにインデックスボリュームが1つ、メッセージボリュームが1つ構成されます。各メールボックスは、現インデックスボリューム上の固定のディレクトリに作成されます。新しいメッセージが配信または作成されると、そのメッセージは現メッセージボリュームに保存されます。

階層型ストレージ管理(HSM)は、メールのストレージリソースを管理できる機能です。HSMポリシーを設定することにより、古いメッセージのストレージボリュームを構成できます。詳細は 設定を管理するを参照してください。

データストアは、内部メールボックスIDがユーザーアカウントとリンクされているSQLデータベースです。会話、メッセージがどこに保存されているかを示すポインター、タグを含むメッセージのメタデータはすべてファイルシステムに格納されます。SQLデータベースファイルは /opt/zimbra/db にあります。

各アカウント(メールボックス)は、1サーバーにだけ入っています。メールボックスのデータが格納されているデータストアは、各サーバーにスタンドアロンで存在しています。

インデックスや検索の技術は、Apache Luceneを用いて提供しています。メッセージを受信した際に、メッセージ内容と添付ファイルは自動的にインデックスされます。インデックスファイルは各アカウントに紐づきます。インデックスファイルは /opt/zimbra/index 配下に保存されます。

なお、メッセージ内容のトークン化とインデックスのプロセスを管理者やユーザーが設定することはできません。

プロセスは以下のとおりです。

メールストアサービスでは、メールボックス/アカウントのデータへのバックエンドアクセスを提供します。 メールストアのウェブアップには以下を含みます。

ユーザーインターフェースサービスでは、メールボックスのアカウントデータと管理コンソールへのフロントエンドユーザーインターフェースのアクセスを提供します。以下を含みます。

ウェブアプリケーションサーバースプリットのインストールと設定方法に関しては Zimbra Collaboration Multi-Server Installation Guide を参照してください。

サーバー上で zimbra-imapd サービスが有効になっている場合、マルチバリュー属性 zimbraServiceEnabled に追加されます。

例えば、IMAPオンリーのサーバーの場合は以下のとおりです。

以下、zimbra-imapdのDEB/RPMにより、zimbra-imapd用にインストールされるファイルです。

上記に加え、 zimbra-core パッケージとして /opt/zimbra/lib/jars 内にすでにインストールされているそのほかのjarファイルもこのサービスで使用します。

次のSSL関連ファイルを作成するため、 zmsetup.pl から zmcertmgr が呼ばれます。

zimbra-imapd サービスは、 /opt/zimbra/conf/imapd.log4j.properties に格納されている設定によって、次のログファイル( /opt/zimbra/log 内)を作成します。

zmimapdctl スクリプトは以下のファイルをじかに作成します。

アクティビティの統計は /opt/zimbra/zmstat/imapd.csv に集められます。

設定を変更するにあたり、まず memcached にある既存の経路をどうするかを決める必要があります。経路は、デフォルトでは zimbraMemcachedClientExpirySeconds というLDAP属性にて指定されているとおり、1日分が memcached にキャッシュされます。変更しなければ、これがこのまま、経路がキャッシュされる期間として、そして、lookup extensionが新たにあてたIMAPDサーバーへIMAPトラフィックを送信する間隔として、採用されることになります。変更する場合は、以下の2点を実施します。

Zimbra Collaboration のプロキシは、設定されているIMAPロードバランスストラテジに基づき、IMAP(S)リクエストを送信するIMAPDサーバーを選択します。

今のところ、IMAPロードバランスストラテジとして以下があります。

クライアントからのIMAPリクエストはプロキシによって処理され、設定されているIMAPロードバランスストラテジに基づき、指定のIMAPDサーバーへ送られます。図では、リクエストに該当するIMAPDサーバーの選択に、 ClientIPHash が使われています。IMAPDサーバーの選択に用いるアルゴリズムは * *オプション を使って設定することができます。

セットアップ: user1 と user2 というユーザーたちにはそれぞれ Mailboxd #1 と Mailboxd #2 が用意されています。

処理は以下のとおり進みます。

内部認証方法はOpenLDAPディレクトリサーバー上で起動しているZimbraスキーマを使用します。OpenLDAPに格納されているアカウントには、userPassword の属性にユーザーのパスワードのsalted-SHA1 (SSHA)ダイジェストが保存されます。ログインする際に入力したパスワードをSSHAダイジェストで演算し、保存した値と比較します。

外部LDAPや外部Active Directoryを使用する場合、認証用の別のサーバーにLDAPのサーバーやMicrosoftのActive Directoryを使用すると、Zimbra Collaboration に関連している動作がZimbra-LDAPのサーバーで使用する必要があります。なお、認証用の外部LDAPサーバーとZimbraの動作用のOpenLDAPサーバーが別々のサーバーとなるため、ユーザーのアカウントをお互いのサーバーに共存する必要があります。

外部認証方法では、入力されたユーザー名とパスワードをの特定のLDAP認証サーバーへ送信し、バインドを試します。バインドが成功した場合、認証サーバーへの接続が切断し、パスワードが認証されたことになります。

外部認証には zimbraAuthLdapURL 属性と zimbraAuthLdapBindDn 属性が必要です。

カスタム認証にて、所有のユーザーデータベースでの外部認証を使用することも可能です。認証のリクエストを受けた場合、Zimbraがドメインへ設定している認証のメカニズムを確認します。カスタムに設定している場合、ユーザーの認証には登録しているカスタムの認証ハンドラを使用します。

カスタム認証を設定するには、ドメインがカスタム認証を使用するように準備し、カスタム認証のハンドラを登録します。

Kerberos5 の認証メカニズムでは、ユーザーを外部のKerberosサーバーへ認証します。

Kerberos5を個人のアカウントと指定するにはアカウントの zimbraForeignPrincipal を kerberos5:{kerberos5-principal} として設定します。
例: kerberos5:user1@MYREALM.COM.

以下の ZCSの連絡先属性へマップされたLDAP属性 の表は、GALの検索属性とZimbra Collaborationの連絡先情報をマッピングしています。

LDAP属性はGAL属性フィールドにマッピングしています。例えば、LDAP属性 displayName と cn は、GALのエントリ項目 fullName へマップできます。マッピングは zimbraGaILdapAttrMap 属性に設定されています。

GALは各ドメイン単位で設定します。属性を設定する場合、管理コンソールのGAL設定ウィザードを使用できます。

GAL属性への追加、変更、および削除はZimbraの管理コンソール、または zmprov のコマンドラインにて実施します。

ユーザーがZimbraのウェブクライアントのオプションやプリフレンスを変更すると、アカウント関連属性も変更されます。

ZCS のテーマ(スキン)のプロパティファイル、および地域のリソースファイルを追加、または変更する場合、新しい内容を反映するためにキャッシュをフラッシュする必要があります。

アカウント、COS、グループ、ドメイン、およびサーバーの属性を変更した場合、変更を行ったサーバーでは変更が直ちに反映されます。ただし、他のサーバーでは属性がキャッシュされている場合、LDAPの情報は定期的に更新されます。

ZCS でのデフォルト設定ではサーバーの定期アップデートは15分ごとです。キャッシュの期間はローカル設定キーにて設定します。

なお、[account|cos|domain|group|server]のタイプと共に[name|id]を指定しない場合、キャッシュにあるタイプの記載はすべてフラッシュされ、キャッシュが更新されます。

グローバル設定属性を変更した場合、変更したサーバー上ではただちにその変更は反映されます。他のメールボックスサーバーでは、キャッシュをフラッシュするか、サーバーを再起動しなければ変更は反映されません。LDAPに記載しているグローバル設定属性の有効期間はありません。

特定なグローバル設定は各サーバー内へサーバーの再起動時のみに読み込めます。サーバー動作の効率化により、キャッシュをフラッシュしても、その特定な設定はサーバーの再起動後のみに有効されます。また、ポートやプロセス可能のスレッド数のようなグローバル設定やサーバー設定はサーバーの起動時のみに読み込む場合があります。そのような属性を変更するとサーバーの再起動が必要となります。

全てのサーバーにおいて、グローバル設定の変更をフラッシュする場合

ZCS で使用するため、Zimbra はPostfixファイル — main.cf と master.cf — のデフォルト設定を編集しました。

外部のSMTPクライアントが非標準的な行動やその他許されない行動を起こした際、メッセージを拒否するように制限を設定できます。このような制限を設定すると迷惑メールを削減できる効果があります。デフォルトとして、完全修飾ドメイン名で接続しないクライアントは制限されます。DNSベースの制限も設定できます。

Postfixに外部サーバー宛のメッセージを別のSMTPサーバーへ送信することを設定できます。例えばリレーやスマートホストなど。

リレーホストの代理使用として、ISPの条件にすべてのメールを特定のホストへリレーする必要があります。そうでないと、メッセージがSMTPのプロキシサーバーでフィルターされることになります。

リレーホストの設定とウェブメールのMTA設定とを混乱しないようにしてください。Postfixは外部サーバー宛のメールをリレーホストへ送信します。ウェブメールのMTAはZimbraサーバーで使用されます。そしてZimbra MTAパッケージでインストールしたPostfixサーバーの場所に設定する必要があります。

なお、管理コンソールにて、外部配信のためのリレーMTAを設定できます。

各ZCSサーバーにClam AntiVirus のウイルス対策ソフトウェアを使用しています。

ウイルス対策の設定では、ウイルスが含まれているメッセージを検疫用のメールボックスへ移動します。デフォルトの設定では、Zimbra MTAは2時間ずつにウイルス対策の更新をClamAVへ確認します。

管理コンソールからウイルス対策設定を変更できます。

Zimbra はSpamAssassinを使用して、メッセージをBerkeley DBのデータベース、またはMariaDBのデータベースに格納されている学習データを経由させて迷惑メールであるかどうかを検査します。更に、メールサーバーのオーバーロードを防止するPostscreen機能の利用も可能です。両方の対策は、以下のトピックで説明されています。

Zimbra のMTAにメールが受信した際、配信を管理するために複数のキューへルートします：受信 (incoming)、 アクティブ(active)、遅延 (deferred)、 保持(hold)、そして破損(corrupt)。

受信 のメッセージキューは新規着信したメッセージを一時的に保持します。各メッセージは一意のファイル名で識別されます。アクティブキューに空がある場合、移動します。問題がなければ、受信キューのメッセージは先へと進みます。

アクティブ のメッセージキューは送信待ちのメッセージを保護します。MTAはアクティブキューに同時に並ぶことのできるメッセージ数を制限します。メッセージをアクティブキューから別のキューへ移動する前に、ウイルス対策と迷惑メール対策のフィルターで処理します。

配信できないメッセージが 遅延 キューへ移動されます。配信できない理由は遅延キューのファイルに記載します。このキューは定期的にスキャンされ、メッセージの再配信をします。指定した再配信数を超えると、メッセージ送信は失敗し、送信元へバウンスされます。送信元にメッセージの配信ができなかった旨の通知を送信することができます。

保持 のメッセージキューに処理できなかったメッセージを保持します。このキューにあるメッセージは管理者のみ移動できます。保持キューに移動したメッセージは定期的な送信試行はしません。

破損 のキューには、読み込めない、壊れているメッセージを保護します。

メールキューの配信関連の問題を管理コンソールにて監視できます。詳細については ZCSサーバーの監視 をご参照ください。

以下のポートはZimbraプロキシ、またはZimbraメールボックスで使用しています。他のサービスがこれらのポートを使用している場合、そのサービスを無効化してください。

エンドクライアントはZimbraプロキシのポートを使用し、直接にZimbraプロキシへ接続します。ZimbraプロキシはZimbraメールボックスのポートを使用し、ルート検索ハンドラ、またはZimbraメールボックスへ接続します。

IMAPプロキシをZimbra Collaborationと共にインストールし、Zimbra Collaborationの設定メニューで初期設定をします。HTTPプロキシを設定するには、プロキシは指定したプロキシノードでインストールする必要があります。それ以上の設定は基本的に必要ありません。

HTTPプロキシをインストール後にIMAP/POPプロキシを設定する場合、メールボックスサーバーとプロキシノードを設定します。

HTTPプロキシを設定する場合、Zimbraプロキシは指定したノードにインストールする必要があります。

ユーザーが正常に ZCSのプロキシ経由でログインするため、プロキシのIPアドレスをシステムに信頼する必要があります。LDAPの zimbraMailTrustedIP 属性にて、プロキシのIPアドレスをシステム上に信頼できます。 なお、プロキシのIPアドレスがメッセージヘッダー情報の X-Forwarded-For 値に表示します。 Localconfigの zimbra_http_originating_ip_header 属性値が X-Forwarded-For の値です。ユーザーがログインした際、このIPアドレスとユーザーが使用するIPアドレスがZimbraのメールボックスログに記録されます。

各プロキシIPアドレスを追加する必要があります。例えば、nginx-1とnginx-2の2つプロキシサーバーの場合

管理コンソールあるいはCLIからいつでもパスワードを変更できます。

管理コンソールから、 パスワード変更 画面を利用して、新規パスワードの文字列を設定し、そのユーザーパスワード修正のポリシーを定義します。

ユーザーアカウント をダブルクリック　または 画面右上の　ギア　アイコンから、ポップアップメニューで　パスワードを変更 を選択します。

別のログインとログアウトページはグローバル設定かドメイン設定で設定できます。

ログインが認証されないか、認証が期限切れの管理者をリダイレクトさせる特定のURLを設定する場合

グローバル設定:

ドメイン設定:

管理者がログアウトするときに特定のURLへとリダイレクトする場合

グローバル設定:

ドメイン設定:

ホーム にあるナビゲーションペイン内のオプションは、ホーム ディレクトリ配下にカテゴリー別に定義されています。 設定ページへの導線となるオプションもあれば、レポートを含むページへ遷移するオプションもあります。選択されたオプションに従って表示されます。

右側のイラストレーションは、ナビゲーションペイン内で現在サポートされているオプションの拡張ビューです。

現在されているページの上部バーには、階層内の現在位置が必ず表示されます。現在の表示から離れるための選択肢は下記の通り複数あります。

ナビゲーションペインのオプションは次のトピックに記載してあります。

ホーム 画面はデフォルトのログイン表示です。ここに ホーム のナビゲーションペインとホームのページがあります。このページに、システムステータスのスナップショット表示と主要タスクへのクイックアクセスリンクがあります。

監視 画面には監視のナビゲーションペインと監視のページがあります。これらページにはCollaboratorが監視したサーバーについての多様な情報がリストとして表示されます。

管理 画面には 管理 ナビゲーションペインと 管理 のページがあります。これらページにはCollaboratorが現在管理しているアカウント、エイリアス、配布リスト、リソースというカテゴリー別の表が表示されます。

設定 画面には 設定 のナビゲーションペインと 設定 のページがあります。個々やグローバルコンポーネントの設定が可能です。

グローバル設定により、サーバー、アカウント、COS、ドメインのデフォルトのグローバル値を定義します。値やパラメーターが別の設定で明確に定義されていない場合は、ここでのデフォルト値およびパラメーターが適用されます。

グローバル設定のデフォルトは、インストール中に設定されます。管理コンソールからいつでもこの設定を変更することができます。

ツールおよび移行 画面には ツールおよび移行 のナビゲーションペインがあり、システムのソフトウェアの管理機能やシステムバックアップ/リストア機能へアクセスできます。管理者はこのページから特定のウィザードにアクセスしたりツールをダウンロードすることが可能です。

検索 画面には、管理コンソールのヘッダーにある検索項目で実施されたクエリの 検索 結果を表示します。

ヘルプセンター は、オンラインヘルプとドキュメントの参照用です。ヘルプセンター 画面にはアクセス可能なリンクがいくつもあります。コミュニティフォーラムへアクセスしたり、移行に関するよくある質問への回答を閲覧したりすることもできます。

ナビゲーションペインからカテゴリーを選択すると通常は、選択したカテゴリーに対して管理している全オブジェクトが表形式で表示されることになります。表には項目名付きのカラムが表示されており、その中にあるメールアドレス、表示名、ステータス、最終ログイン、説明 (設定されている場合) などの情報を閲覧することができます。

表内のエントリーに対する情報の追加や設定へのアクセスが必要な場合は、該当行をそれぞれ選択し、アクションを実行することができます。

メッセージの表示を閉じるにはメッセージ内にある 閉じる ボタンをクリックします。

表示したい通知メッセージを1件もしくは複数件作成するには、この項のガイドラインに沿って、 zimbraAdminConsoleLoginMessage 属性を使用してしてください。

グローバル、または特定のドメインへの通知メッセージを作成:

複数のメッセージを表示:

通知メッセージを1件もしくは複数件削除するには、この項のガイドラインに沿って、zimbraAdminConsoleLoginMessage 属性を使用してしてください。

特定の通知メッセージを削除:

すべての通知メッセージを削除:

管理コンソール UIの概要図は次のイラストで示すとおりです。

ナビゲーションペインで選んだエンティティに対する処理を行なうには、ギアアイコンを使うという選択肢と、項目のポップアップメニューを使うという選択肢があります。

管理コンソールでは、広範囲にわたる設定のオプション内容をコンテナに入れて論理的にグループ化しています。こうしたコンテナ内にある設定オプションは、 管理コンソール UIの概要図 にて一覧にしています。
デフォルトでは、ページ内の全てのコンテナが開いています (広がっています) 。各コンテナの左上にある開閉ボタンをクリックしてコンテナを閉じる (見えなくする) ことで、ビューページ内スペースを確保することも可能です。

グローバル設定の「添付ファイル」設定ページにて、メッセージの添付ファイルに関するグローバルのルールを指定できます。なお、提供サービス、および各アカウントにてルールを設定することも可能です。グローバル設定に添付ファイルのルールを設定すると、グローバル設定は優先に適用されます。

画面のセクションに関する詳細は 特定のファイル拡張子の添付ファイルをブロックする を参照してください。

添付ファイルに特定のファイル拡張子が含まれている場合、メッセージの受信を拒否することができます。拒否するファイル拡張子を 一般的な拡張子 のリストより選択できます。また、リストに他の拡張子を追加することもできます。ブロックされている拡張子が添付ファイルに含まれているメッセージはすべてMTA側で受信拒否されます。基準設定では、差出人と宛先に対し、メッセージがブロックされたという通知メッセージが送信されます。

メッセージがブロックした際に通知メッセージを送信したくない場合、無効にできます。

グローバルアクセスを有効にするには、IMAPページとPOPページを使用してください。

IMAP/POP3のポーリング間隔は提供サービスの詳細設定から指定できます。デフォルトではポーリング間隔は設定されていません。

POP3では、Zimbraのサーバーに保存しているメッセージ、および新着のメッセージをローカルのコンピュータへダウンロードできます。なお、POPでメッセージのダウンロードと保存する設定はユーザーの プリファレンス > メール ページで設定できます。

本項で説明されているオプションを設定するには、新しいドメイン ウィザードを使用してください。

グローバルアドレス帳(GAL)はメールシステムのユーザー全員が参照可能な、企業全体のユーザーのリストです。GALは通常、完全なメールアドレスが分からなくても、姓または名から他のユーザーを検索できるようなメールシステムにするために使われています。

GALはドメイン単位で構成されます。また、各ドメインのGALモード設定によって、GALの検索先を指定します。

グローバルアドレス帳(GAL)を定義するには、ドメイン設定で GALモード設定 ツールを使用してください。

ドメインに内部、または外部のGALを作成した際、そのドメイン用のGAL同期アカウントも自動的に作成されます。複数のメールボックスサーバーを使用している場合、各メールボックスサーバーにGAL同期アカウントを作成することができます。GAL同期アカウントを使用することで、GAL名称のオートコンプリートへのアクセス速度が向上します。

サーバー用のGAL同期アカウントが作成されると、GALのリクエストはドメイン用のGAL同期アカウントではなくサーバー用のGAL同期アカウントを使用するようになります。GalSyncResponseにはGAL同期アカウントIDと現在の変更番号が暗号化されたトークンが含まれています。クライアントはその情報を保存し、次回のGalSyncRequestにて使用します。なお、ユーザーは最初に同期したGAL同期アカウントを使用して、GAL同期を実行します。何らかの理由でGAL同期アカウントを使用できない場合、従来のLDAPベースの検索が実行されます。

GAL同期アカウントを設定する場合、GALデータベースを確定してから、連絡先データをデータソースからGAL同期アカウントのアドレス帳へ同期させます。なお、両方 のGALモードを使用している場合、各LDAPのデータソースへアドレス帳が作成されます。

GAL同期のGALポーリング間隔は、GAL同期アカウントがLDAPサーバーへ同期する頻度を指定します。同期の間隔は日数、時間、分数、秒数のいずれかです。ポーリング間隔はデータソースごとに設定します。

GAL同期アカウントがLDAPのディレクトリーと同期する際、LDAPにあるすべてのGAL連絡先がGAL同期アカウントのアドレス帳に追加されます。同期中にアドレス帳へ新規作成した連絡先、既存の連絡先の編集、および削除の情報が更新されます。なお、LDAPとGAL同期アカウントが同期しますと、GAL同期アカウントのアドレス帳がLDAPで保存している情報に上書きされますので、GAL同期アカウントのアドレス帳を直接に編集しても編集した内容が消えます。

管理コンソール、またはコマンドラインの zmgsautil にて、新規のGAL 同期アカウントを作成することができます。

ユーザーがログインする際に、ユーザー名とパスワードが有効であることを確認するプロセスが「認証」です。認証のプロセスではユーザー、またはサーバーをディレクトリーサーバーの情報と確認し、提供した情報が正常である場合はサーバーへのアクセスを許可します。ドメイン単位をベースとして認証モードを設定します。

仮想ホストではサーバーに複数のドメイン名をホストすることができます。基本的なドメイン設定は変わりません。

追加した仮想ホスト名はユーザーがログインする際のデフォルトドメイン名として使用します。Zimbraのウェブクライアントを仮想ホストでアクセスすると、ユーザー名に仮想ホストのドメイン名を含めずにログオンすることが可能となります。

Zimbraのウェブクライアントのログインページを開くには、仮想ホスト名をURLとして入力します。例: https://mail.company.com.

Zimbraのログイン画面が表示されたら、ユーザーはユーザー名とパスワードのみを入力します。認証リクエストは該当する仮想ホスト名をもつドメインを検索します。仮想ホストが見つかると、そのドメインに対する認証は完了です。

各ドメインで作成可能なアカウント数を制限することができます。ドメイン作成時に作成可能な最大アカウント数を設定できます。また、ドメインの設定にて最大のアカウント数を自由に変更できます。

管理コンソールにて、 設定 > ドメイン > アカウント制限 のページで設定できます。なお、このページを設定しない場合、ドメインへのアカウント作成の制限はありません。

リソース、スパム、およびハムのアカウントはこの制限に数えません。

ドメインに複数の提供サービス(COS)を使用している場合、どの提供サービスが設定可能かを選択できます。また、提供サービスを使用中のドメインに最大アカウント数も指定できます。これはドメインのアカウント制限ページで設定します。使用中の提供サービスアカウントタイプの数はトラッキングされます。なお、提供サービスの制限はドメインの最大アカウント数を超えることができません。

アカウントに使用されている提供サービスの数はトラッキングされます。アカウントの全般情報ページにて、割り当てた数および残数が確認できます。

ドメイン名の変更する際、実際に新しいドメインを作成し、すべてのアカウントを新しいドメインへ移動してから元のドメインを削除することになります。すべてのアカウント、エイリアス、配布リスト、およびリソースのアドレスは新しいドメイン名へ変更されます。LDAPの更新にて、変更が反映されます。

ドメイン名を変更する前に:

ドメイン名が変更された後:

ドメインのエイリアスにて、複数のドメイン名を1つのドメイン名へ転送します。例えば、使用中のドメイン名はdomain.comでも、ユーザーに@example.comのアドレスを持たせたい場合、domain.comのエイリアスドメインとしてexample.comを作成することができます。user@example.com へメール送信することは、user@domain.com にメール送信することと同じです。

警告は各ドメインに設定します。アップグレードする場合、過去の運用を継続に提供するため、既存のグローバル警告は各ドメインへドメインの警告へ自動的に変換されます。

各ドメインの警告サポートは以下の手順で有効化できます。

ドメインの内部ユーザー間で送受信するメールに警告を追加しないように設定できます。

attachedzimbraAmavisOutboundDisclaimersOnly を TRUE にします。

上位互換性を保つため、この属性のデフォルトは FALSE です。

関連した属性を FALSE に設定することで、警告のサポートを完全に無効化できます。

ドメインの Zimlet ページにて、サーバーに配備しているZimletをすべて表示します。ドメインのユーザーに全てのZimletを利用させたいわけではない場合、そのドメインで使用できるZimletをリストから選択してください。なお、このドメインのZimletページで設定した値は、提供サービスおよびアカウントに設定した値をオーバーライドします。

全般情報ページは以下の設定情報が含まれています。

逆引きプロキシをインストールした場合、プロキシサーバーとメールボックスサーバーの通信はすべてプレインテキストで行う必要があります。逆引きプロキシの参照ターゲットサーバ を有効にすると、以下パラメーターの値が自動的に設定されます。

なお、「備考」のテキストボックスでは、設定のメモなどを自由に追加し、保存できます。

MTA ページでは以下の設定を表示します:

サーバーに複数のIPアドレスを使用している場合、IPアドレスのバインドで特定のサーバーをバインド(使用)するIPアドレスを指定できます。

証明書は異なるホスト同士やクライアントとサーバー同士でセキュア通信に使用されるデジタル証明です。証明書はサイトの所有者を証明するために使います。

2種類の証明書を使用できます：自己署名証明書と商業用の証明書。

Zimbra Collaborationをインストールした際、テストのため、自己署名証明書を自動的にインストールします。そのため、Zimbra Collaborationのサーバーを本番環境で使用する際は、商業用の証明書をインストールする必要があります。

証明書署名リクエスト(CSR)を発行するには、専用のフォームにドメイン、会社、国についての詳細を入力し、RSAの秘密キーでCSRを発行します。発行したファイルをコンピュータへ保存し、ご利用の認証局へ送信します。

商業署名入りの証明書を入手するには、管理コンソールにあるZimbraの証明書ウィザードを使用して、RSAの秘密キー、および証明書署名リクエスト(CSR)を発行します。

証明書のパラメーター設定には下表のガイドラインをご利用ください。

Zimbraサーバーで発行したCSRをローカルのコンピュータへダウンロードし、VeriSignやGoDaddyのような認証局へ提出します。認証局よりデジタル署名の証明書が発行されます。

認証局より証明書を受信後、Zimbra Collaborationへのインストールが必要です。インストールするためには、証明書インストールウィザードを再度使用します。なお、証明書を有効にするため、インストール後、サーバーを再起動する必要があります。

現在配備されている証明書の詳細を閲覧することが可能です。詳細には証明書の件名、発行者、有効日数、サブジェクト代替名を含みます。

証明書はZimbra のLDAP、MTA、およびプロキシなど別のサービスを表示します。

証明書が失効した場合、ZCSシステムが正常に動作できなくなる可能性があります。ご利用のクライアントと環境を継続的に使用するため、ZCSにインストールしているSSL証明書を有効な状態に維持することが重要です。発行されているSSL証明書の失効日などを含めた情報はZCS管理コンソールから確認できます。意図せず失効してしまわないように、証明書は定期的に失効日を確認することを推奨します。

Zimbra Collaborationサーバー上の各ドメインへSSL証明書をインストールできます。複数のドメインをサポートするためにはZimbraプロキシがZimbra Collaborationにインストールされ、正常に設定されている必要があります。ドメインごとの仮想ホスト名と仮想IPアドレスは仮想ドメイン名とIPアドレスで構成されます。

ドメインごとに商業署名入りの証明書を発行する必要があります。証明書に含まれる公開鍵はそのドメインに属することを証明します。

Zimbraプロキシ仮想ホスト名とIPアドレスを以下で設定します。

ドメインの証明書の編集方法:

ドメイン用に発行された署名入りの商業用の証明書と秘密キーのファイルを、選択したドメインの ドメインの証明書 セクションへコピーします。

外部送信メールのDKIM署名はドメインレベルで行われます。

DKIM 署名を設定するには、コマンドラインでzmdkimkeyutilを実行し、DKIMキーとSelector(公開鍵)を生成します。発行したSelectorをDNSサーバーへ追加します。

DKIMキーが更新されると、DNSサーバーも新しいTXTレコードでリロードする必要があります。

以前のキーで署名されたメールを継続して検証できるように以前のテキストレコードをDNS内に一定期間残しておくことを推奨します。

ZCS サーバーにログインし、zimbra ユーザーとして以下のコマンドを実行します。

任意： コマンドラインに -b を使用すると、発行する公開キーに使用するビット数を指定できます。 例: -b <####> また、-b を追加しない場合は、公開キーの基準ビット数は2048ビットです。

DKIM署名をZCSから削除すると、DKIMのデータがLDAPから削除されます。新規作成したメッセージにはドメイン署名が追加されなくなります。以前のキーで署名されたメールを継続して検証できるように以前のテキストレコードをDNS内に一定期間残しておくことを推奨します。

削除するには以下のコマンドを実行します。

ドメイン、Selector、秘密キー、公開署名およびアイデンティティに関して保存されているDKIM情報を確認するには、以下のコマンドを実行します。

迷惑メールの自動学習フィルターは基準設定で有効にしています。以下２つのフィードバック用メールボックスが自動的に作成され、学習フィルターで使用されます。

なお、クォータを無効にすることで、容量が残っていないメールボックスよりバウンスのメッセージが発生しないため、上記の学習用アカウントにメールボックスのクォータ、および添付ファイルのインデックスは無効にしています。

迷惑内容をどの程度で判定できるかは、直接、迷惑フィルターの効率に影響します。基本的に、ユーザーがメッセージを迷惑メールのフォルダーへ移動する、または迷惑メールのフォルダーから別のフォルダーへメッセージを移動する場合、SpamAssassinのフィルターが学習されます。ユーザーが迷惑メールのフォルダーへ移動、または迷惑メールのフォルダーからの移動する場合、適切の迷惑メール学習メールボックスへメッセージのコピーが自動的に配信されます。

ZCSがインストールされたとき、最初のMTAにのみ迷惑メールのスパム/ハムをクリーンアップするフィルターが構成されます。 ZCS迷惑メールの学習ツール(zmtrainsa)は、自動的にスパムとハムのメッセージを収集し、迷惑メールフィルターを学習します。なお、zmtrainsa のスクリプトはcrontabのジョブとして設定し、メッセージをSpamAssassinへ配信し、迷惑メッセージの内容、および迷惑メッセージではない内容からキーワードなどを収集し、迷惑フィルターを学習させます。zmtrainsaのスクリプト は毎日に実行し、学習が終了するとスパムとハムのメールボックスを空にします。

ZCS の既定設定では、全てのユーザーでメッセージを迷惑メールフォルダーに移動することによって迷惑メールのフィルター学習に利用されます。

ユーザーから迷惑メールのフィルターを学習させたくない場合、学習する機能を無効化できます。

上記の属性を空欄にすると迷惑メール、および迷惑メールではないとしてフラグしたメッセージは迷惑メールの学習用メールボックスへコピーされません。

迷惑と非迷惑のトークン、キーワード、文字、および短い文字列を迷惑メールのフィルターへ手動に学習する場合があります。その場合、迷惑メールと非迷惑メールの学習メールボックスへメッセージをmessage/rfc822の添付ファイルとして転送します。

zmtrainsa が起動すると、迷惑メールと非迷惑メールのメールボックスに配信しているメッセージが迷惑メールのフィルターを学習します。配信するメッセージへ正常な迷惑メールスコアを得るため、学習するメッセージが十分であることを確認してください。基準として、迷惑メールを適切に判断するため、最低に200通の迷惑メッセージと200通の非迷惑メッセージが必要と考えられます。

なお、バックスキャッタの迷惑メッセージを減らすため、Milter サーバーを動作することが可能です。MilterサーバーではPostfixのSMTPアクセスポリシーのダイモンを使用し、エイリアスのドメイン宛の RCPT To: 内容を制限できます。

Postfix spawn(8)デーモンの基準設定では、Postfixの子プロセスが開始してから1000秒後で自動的にKILLします。なお、SMTPクライアントがSMTPプロセスに接続している期間は1000秒を超える可能性があります。長時間でポリシーデーモンを正常に使用するため、 postfix_policy_time_limit キーを設定しています。

SMTPDポリシーを無効にします。

ポリシーの制約を定義します。メール受信者のRBLリストとRHSBLのリストのオン・オフをこのMTAページで切り替えることができます。

基準のプロトコルチェックでは、以下3つのRBLを有効にできます。

グリーディングでのホスト名がRFCに反する- - reject_invalid_host

以下のRBLの設定も可能です。

受信者制限の一環として、 reject_rbl_client <rbl hostname> オプションも使用可能です。

MTA設定にあるDNSツールを使用して、制限リストを定義してください。

最新のRBLリストについては Comparison of DNS blacklists(DNSブラックリストの比較) の記事を参照してください。

ZCSに基準設定では迷惑メールとしてタグ付けされたメッセージはすべて迷惑フォルダーへ配信されます。また、ZCSへメッセージが受信する前に、サードパーティ製のアプリケーションで迷惑フィルターを使用した場合、サードパーティの仕様で迷惑メッセージとしてタグ付けされたメッセージも自動的に迷惑メールのフォルダーへ配信されます。なお、メッセージの宛先がホワイトリストに登録されていても、迷惑メッセージとしてタグ付けされた場合は迷惑メールのフォルダーへ移動されます。

ホワイトリストした宛先のメッセージを迷惑メールのフォルダーへ配信しないように設定する場合、 zimbraSpamWhitelistHeader と zimbraSpamWhitelistHeaderValue を設定する必要があります。なお、設定してもZimbraのMTA迷惑メールフィルター、およびユーザーのフィルターのルールが適用されます。

メッセージにホワイトリストのヘッダーを検索する場合：

値を設定する場合：

Free/Busy機能のセットアップには、以下が必要です。

Free/Busyの相互運用を管理コンソールで設定するには、グローバル設定、ドメイン、提供サービス、およびアカウントの設定を以下のように設定する必要があります。

ZCS のサーバー間でFree/Busyのインターオペラビリティを設定できます。Free/Busyのインターオペラビリティは各サーバーに設定します。