Zimbra Collaboration Administrator Guide

ユーザー認証管理を目的としてシステムに搭載した機能を下の表にまとめました。

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

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

Zimbra Collaboration サーバーが外部インターネットへの接続があり、かつ、Zimbraライセンスサーバーに繋がる場合、ライセンスは自動でアクティベーションされます。ライセンスが自動でアクティベーションされない場合は、 手動でのライセンスのアクティベーションについてを参照してください。

Zimbraライセンスサーバーへ外部接続ができないシステムの場合、 Zimbraのサポートポータルを利用すると、マニュアル操作でライセンスをアクティベーションすることができます。Zimbraのホームページ(www.zimbra.com)へアクセスし、Support をクリックすると、Zimbraのテクニカルサポートページが表示されます。Zimbra Collaboration Suport をクリックすると、サポートポータルページが表示されます。メールアドレスとパスワードを入力してログインします。

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

Zimbra Collaboration サーバーライセンスのインストールまたはアクティベーションに失敗した場合のZimbra Collaborationサーバーへの影響は次のとおりです。

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

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

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

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

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

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

ライセンス契約したユーザー数の上限に達した場合、アカウントの作成も削除もできなくなります。

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

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

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

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

デフォルトでは、メッセージストアはメールボックスサーバー内 /opt/zimbra/store 配下に格納されます。各メールボックスは、その内部メールボックスIDにちなんだ固有のディレクトリを持っています。メールボックスIDは、システム全体ではなく個々のサーバー内でのみ、一意です。

受信者が複数であるメッセージの場合、メッセージ保存領域に格納されるのは１件です。UNIXシステム内のユーザーごとの固有メールボックスディレクトリには、この実ファイルへのハードリンクが格納されます。

Zimbra Collaboration がインストールされると、各メールボックスサーバーにインデックスボリュームとメッセージボリュームが1つずつ設定されます。メールボックスはそれぞれ、現在のインデックスボリューム内のディレクトリに固定で割り当てられます。新たに配信あるいは作成されたメッセージは、現在のメッセージボリュームに保存されます。

メールストレージ管理として階層型ストレージ管理(HSM)ポリシーを実装することで、比較的古いメッセージのストレージボリュームを設定できます。詳細は 設定を管理するを参照してください。

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

各アカウント(メールボックス)は、1サーバーにしか入りません。そのサーバーに存在するメールボックスのデータを格納するデータストアがスタンドアロンの状態で存在します。

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

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

プロセスの説明

メールストアサービスにより、メールボックス/アカウントのデータへのバックエンドアクセスが可能です。 メールストアのウェブアプリケーションには以下が含まれます。

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

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

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

メール環境が、Zimbra以外のLDAPサーバーやMicrosoft Active Directoryを認証用に使用していて、Zimbra LDAPサーバーをZimbra Collaboration 関連のトランザクション用に使用している場合は、外部LDAPと外部Active Directoryの認証を利用することができます。ただし、OpenLDAPと外部LDAPサーバーの両方にユーザーが存在していなければなりません。

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

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

所有しているユーザーデータベースに外部認証を統合させるカスタム認証を実装できます。認証リクエストがくると、Zimbraはドメインに指定された認証メカニズムをチェックします。この認証メカニズムがカスタムに設定されている場合、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分ごとです。キャッシュする期間はローカル設定キーで設定します。

タイプに沿ったIDや名称を指定しない場合、キャッシュにある、そのタイプの全エントリがフラッシュされ、キャッシュは更新されます。

グローバル設定属性を変更した場合、変更を行ったサーバーには直ちに変更が反映されます。他のメールボックスサーバーの場合、キャッシュをフラッシュするかサーバーを再起動しなければ変更は反映されません。グローバル設定属性のLDAPエントリに有効期間はありません。

グローバル設定属性のなかには、サーバーが再起動したときにだけ読み込まれるものもあります。こうした属性への変更は、キャッシュをフラッシュしたとしてもサーバーが再起動されるまでは有効になりません。グローバル設定や、グローバル設定を継承したサーバー設定のなかにも、サーバー起動時のみに読み込まれるものがあります。例えば、ポートやプロセススレッド数です。こうした属性の変更により、サーバー再起動が必要となります。

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

ZimbraのPostfixファイル — main.cf と master.cf — はZCS で使用できるように修正してあります。

外部のSMTPクライアントが標準ではないアクションや許可されていない行動をした場合にPostfixがそのメッセージを受け付けないように設定することができます。制限を設けることで、迷惑メール送信者に対処します。デフォルトでは完全修飾ドメイン名で接続しないクライアントが制限されます。DNSベースの制限も可能です。

外部サーバー宛のメッセージを別のSMTPサーバーへ送信するようにPostfixを設定できます。通常、リレーやスマートホストなどと言われます。

よくあるリレーホストのユースケースは、全メールを特定のホストからリレーさせる必要のあるISPの場合や、フィルターリング用SMTPプロキシサーバーがある場合です。

リレーホストの設定を、ウェブメールのMTA設定と混合させないでください。リレーホストとは、Postfixが外部サーバー宛のメールをリレーするためのMTAです。ウェブメールのMTAは、作成したメッセージのためにZimbraサーバーが使用するものであり、 MTAパッケージのPostfixサーバー用ロケーションにあります。

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

Clam AntiVirusは、ZCSサーバーごとに使用可能なウイルス対策ソフトです。

このソフトは、ウイルスが含まれていると判別されたメッセージを検疫用メールボックスへ移動するように設定されています。デフォルトでは、Zimbra MTAはClamAVのウイルス対策の更新を2時間ごとにチェックします。

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

Zimbraは迷惑メールの判別に、Berkeley DBのデータベースまたはMariaDBのデータベースに保存している学習データを使ってSpamAssassinを利用します。更に、メールサーバーのオーバーロードを防止するPostscreen機能の利用も可能です。これらについては以下のトピックスに記載しています。

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

受信 メッセージキューには新たに受信したメッセージが入ります。メッセージごとの一意のファイル名で識別されます。アクティブメッセージキューに空き容量がある場合、メッセージはアクティブメッセージキューへ移動します。問題がない場合、メッセージはこの受信メッセージキューを即座に通過します。

アクティブ メッセージキューには送信待ちメッセージが入ります。アクティブキューに一度に入れられるメッセージ数はMTAに設定されています。このキューから別のキューへメッセージを移動する前に、ウイルス対策と迷惑メール対策のフィルターで処理します。

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

保持 メッセージキューには処理できなかったメッセージが入ります。管理者が移動させるまで、メッセージはこのキューに留まります。このキューにあるメッセージに対する定期送信は試行されません。

破損 キューには読み込み不可能な壊れたメッセージが入ります。

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

以下のポートはZimbraプロキシまたはZimbraメールボックス（プロキシが設定されていない場合）のいずれかで使用されています。これらのポートで起動中の他のサービスがある場合はそのサービスを停止します。

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

Zimbraのプロキシには、クライアントが渡す Host のヘッダーに入れられる値を厳しく制限できる機能があります。

この機能は、 新規インストール の場合には デフォルトで有効 ですが、これまでのバージョンからの アップグレード　の場合はインストール中に切り替えない限り　無効 です。

zimbraReverseProxyStrictServerNameEnabled の真偽値を設定してプロキシサーバーを再起動することでも、同機能を実現することができます。

サーバー名による制御機能が有効な場合、ドメインレベルで設定アイテム zimbraVirtualHostName と zimbraVirtualIPAddress を使用することで、許容されるサーバー名を追加で指定することができます。

IMAPプロキシはZimbra Collaborationでインストールされ、インストール中の設定メニューからセットアップされます。HTTPプロキシを設定するには、プロキシを指定したプロキシノードにインストールする必要があります。この他の設定は基本的に必要ありません。

HTTPプロキシのインストールが完了しており、メールボックスサーバーとプロキシノードをセットアップした後に、IMAP/POPプロキシをセットアップする必要がある場合。

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

プロキシがZCSで設定されている場合、各プロキシサーバーのIPアドレスをLDAP属性 zimbraMailTrustedIP 属性内に設定することでそれらプロキシのIPアドレスを信頼できるものとし、ユーザーがプロキシ経由でログインできるようにしておかなければなりません。 プロキシIPアドレスはメッセージヘッダー情報 X-Forwarded-For に記載されます。 X-Forwarded-For ヘッダーは、自動でLocalconfigヘッダー属性 zimbra_http_originating_ip_header に追加されます。ユーザーログイン時、このIPアドレスとユーザーのアドレスは、Zimbraのメールボックスログに記録されます。

この属性内に各々のプロキシIPアドレスを記載してください。例：プロキシサーバーが2つの場合

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

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

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

ログインとログアウトという異なる２つのページをグローバルレベルまたはドメインレベルで設定できます。

ログインが認証されないときや期限切れ認証のときに、管理者をリダイレクトさせるURLを指定

グローバル設定:

ドメイン設定:

ログアウトするときに管理者をリダイレクトさせるURLを指定

グローバル設定:

ドメイン設定:

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

画面右側のイラストは、ナビゲーションペインにある現在サポート中のオプションの拡張ビューです。

階層内の現在位置は、その時に表示されているページ上部のバーに必ず表示されるため、現在の表示画面から遷移する方法は、下記のとおり複数あります。

ナビゲーションペインのオプションは下記トピックで説明されています。

ホーム 画面がデフォルトのログイン時の表示です。ホーム ナビゲーションペインと ホーム ページがあります。このページには、システムステータスのスナップショットが表示され、不可欠なタスクにクイックアクセスできるリンクもあります。

監視 画面には 監視 ナビゲーションペインと 監視 ページがあります。ページには、Collaboratorが監視したサーバーに関する様々な情報が一覧表示されます。

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

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

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

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

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

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

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

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

各エントリに関する追加情報や各エントリに設定を行なうためのアクセスが必要であれば、対象行でアクションを実行することができます。

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

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

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

複数のメッセージを表示

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

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

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

管理コンソール UIの概要は下記イラストになります。

ナビゲーションペインの項目を選択し処理を実行するには、ギアアイコンを利用する方法と、項目のポップアップメニューを利用する方法があります。

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

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

この画面に関する詳細は 拡張子から添付ファイルをブロックする を参照してください。

添付ファイルに特定の拡張子を伴うメッセージを拒否することもできます。 一般的な拡張子 から承認しない拡張子を選択します。リストにない拡張子を追加することも可能です。こうした拡張子が添付ファイルに含まれているメッセージはすべて拒否されます。デフォルトでは、差出人と宛先にメッセージがブロックされた旨が通知されます。

メッセージがブロックされた際の通知を宛先に送信したくない場合、このオプションを無効にします。

グローバルアクセスの有効化は、IMAPページとPOPページから行ないます。

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

POP3のおかげで、ユーザーはZimbraサーバーに保存されているメッセージの検索と、新着メッセージのローカルコンピュータへのダウンロードができます。プリファレンス > メール ページにあるユーザーのPOP設定により、メッセージのダウンロード方法と保存方法が決まります。

本項で説明するオプションの設定は、新しいドメイン ウィザードから行ないます。

グローバルアドレス帳(GAL)は企業全体のユーザーリストのことで、メールシステムにいる全てのユーザーが、GALを参照できます。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同期アカウントは管理コンソールから作成します。CLIでのこの機能は zmgsautil になります。

認証とは、ディレクトリサーバーへアクセスするユーザーやサーバーを識別し、ユーザーログイン時に入力されたユーザー名とパスワード情報に基づき正当なユーザーにはアクセスを認めるプロセスのことです。

認証方法はドメイン単位で設定します。

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

仮想ホストを作成すると、それがユーザーログイン時のデフォルトドメイン名に使用されます。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、プロキシなどの様々なZimbraサービスが表示されます。

証明書が失効するとZCSシステムが正常に動作しなくなる恐れがあるため、クライアントや環境の継続利用に向けて、ZCSにインストールされているSSL証明書の有効状態を保つことが重要です。配備したSSL証明書の有効日数などの情報はZCS管理コンソールから確認できます。証明書を定期的に確認して、失効日を把握し、有効状態を保つことを推奨します。

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

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

Zimbraプロキシ仮想ホスト名とIPアドレスの設定

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

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

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

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

DKIMキーの更新時、新しいTXTレコードを使用してDNSサーバーをリロードする必要があります。

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

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

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

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

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

迷惑メールの自動学習フィルターはデフォルトで有効にしています。次の２つのフィードバック用メールボックスが学習フィルター用に自動作成されます。

こうした学習アカウントに対して、メールボックス容量制限と添付ファイルのインデックスは無効にされています。無効にすることで、メールボックスの容量がいっぱいになってメッセージがバウンスされることを防ぎます。

何を迷惑メールと捕らえるかによって、迷惑フィルターの良好さは変わります。ユーザーがメッセージを迷惑メールのフォルダへ移動したり、迷惑メールのフォルダから別のフォルダへメッセージを移動することは、メッセージを迷惑メールとして新たにタグ付けすることになり、それがSpamAssassinフィルターの学習になります。こうしてタグ付けされたメッセージは、適切な迷惑メール学習メールボックスへと送信されます。

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

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

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

上記の属性が空欄時、迷惑メールあるいは迷惑メールではないとしてタグ付けしたメッセージは、迷惑メールの学習用メールボックスにコピーされません。

迷惑と非迷惑のトークン、キーワード、文字、短い文字列を迷惑メールのフィルターにあらかじめ学習させたい場合、メッセージをマニュアル操作でmessage/rfc822の添付ファイルとして迷惑メールと非迷惑メールの学習メールボックスに転送します。

zmtrainsa の実行時、こうしたメッセージが迷惑メールのフィルター学習に使用されます。精度の高いスコアを達成するために、サンプルメッセージが充分であることを確認してください。メッセージを迷惑メールとしてタグ付けするための判断には、迷惑メールと非迷惑メッセージがそれぞれ最低でも200通必要です。

バックスキャッタの迷惑メッセージを減らす目的で、エイリアスドメイン宛の RCPT To: の内容を検証するZimbra アクセスポリシーデーモンを実行するサービスを実行することができます。

postfix_policy_time_limit キーを設定している理由は、デフォルトでは、Postfix spawn(8)デーモンはPostfixの子プロセスを開始の1000秒後に自動でKILLするためです。これは、SMTPクライアントがSMTPプロセスと接続している限り実行し続け得るポリシーデーモンにとっては短い時間です。

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

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

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

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

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

MTA設定にあるDNSツールを使用して、制限リストを定義します。

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

ZCSでメッセージを受け取る前段階でサードパーティ製アプリケーションの迷惑フィルターを使用している場合、サードパーティの仕様で迷惑メッセージとしてタグ付けされたメッセージは全て迷惑メールのフォルダへ送信されるというのが、ZCSのグローバルルールです。メッセージの宛先がホワイトリストに登録されていても、迷惑メッセージとしてタグ付けされた場合は迷惑メールのフォルダへ移動されます。

ホワイトリストとして識別したメッセージを迷惑メールのフォルダへ送信したくない場合、 ユーザーのメールボックスに送信するために、 zimbraSpamWhitelistHeader と zimbraSpamWhitelistHeaderValue を設定する必要があります。このグローバルルールは、ZCSのMTA迷惑メールフィルタールールとは無関係です。メッセージは依然としてユーザーのフィルタールールを通過します。

ホワイトリストのヘッダーを検索

値を設定

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

Free/Busyのインターオペラビリティを管理コンソールで設定するには、グローバル設定、ドメイン、提供サービス、アカウントの設定を以下のように設定する必要があります。

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