これまでのバージョンからのアップグレード/移行で、Zimbraの新規機能であるモバイル同期モジュールの有効化を予定している場合は、重要な情報である "Things to Know Before Upgrading"インストールガイド を必ず一読するようにしてください。

License

CC BY-SA Synacor, Inc., 2019

© 2019 by Synacor, Inc. Zimbra Collaboration Administrator Guide

本書はクリエイティブ・コモンズの表示+継承4.0国際ライセンスの適用対象です(Synacor社との間に別途ライセンス合意がある場合を除く)。次のサイトからこのライセンスを閲覧できます。 https://creativecommons.org/licenses/by-sa/4.0

あるいは、Creative Commons, PO Box 1866, Mountain View, CA 94042, USA.宛てに連絡してください。

Synacor, Inc., 2016
40 La Riviere Drive, Suite 300
Buffalo, New York 14202

はじめに

Zimbra Collaboration は電子メール、アドレス帳、カレンダー、タスクおよびウェブドキュメント編集の機能をすべて兼ね備えた、メッセージングとコラボレーションのソリューションです。

対象読者

本ガイドは、Zimbra Collaborationのサーバー環境のインストール、保守、サポートを担当するシステム管理者向けに作成しています。

本ガイドの適切な利用には、次の知識やスキルが必要です。

  • Linuxオペレーティングシテム関連の技術、オープンソースのコンセプトに関する知識

  • メールシステム管理に関する運用知識

サードパーティ製のコンポーネントについて

バックアップ管理、ユーザー認証、オペレーティングシステムおよびデータベース管理に関し、Zimbra Collaborationは標準規格やオープンソースの推進を可能な範囲において遵守します。ただし、「製品の概略」章で紹介している、正規のテストで証明された使用方法に限り、サポートします。本ガイドに参考程度に記載している箇所はありますが、Zimbra Collaborationでは、他のサードパーティ製のツールのサポートや認証はいたしません。

サポートと連絡情報

www.zimbra.com から、オープンソースメッセージングのベストソリューションのコミュニティーに参加できます。皆様からのフィードバックや製品への要望をお待ちしております。

  • Zimbra Collaboration の購入に関しては、sales@zimbra.comまでご連絡ください。

  • ネットワーク版をご利用のお客様に対するサポートに関しては、support@zimbra.comまでご連絡ください。

  • Zimbra のフォーラム から、インストールや設定についての問題解決に関する情報を確認できます。

  • Zimbra のフォーラムに参加すると、 Zimbra Collaboration に関する情報を他のユーザーと共有できます。

製品関連の詳細については、以下からご覧ください。

製品に対する疑問やご希望される機能追加については、Zimbraのフォーラムに投稿し、お知らせください。

製品のライフサイクル

以下に Zimbra コンポーネントの製品ライフサイクルについて詳細を案内します。

コンポーネントのサポート終了について

コンポーネント サポート終了の詳細

IMAPD

IMAPD は Zimbra 8.8.5 にベータ版の機能として提供しましたが、安定した状態として提供しておりません。本機能の提供を終了いたしました。

Exchange用のZCS移行ウイザード

このツールはPSTファイルのインポートでのみサポートしており、テクニカルガイダンスとして2010年12月31日までサポートします。 なお、すべてのアカウント移行の代替案として、https://zimbra.audriga.com/[audriga社の移行ソリューション] の利用を推奨しております。

Domino用のZCS移行ウイザード

サポート終了

ZCSのアカウント移行

Zimbra管理コンソールのGUIでのZCSアカウント移行のサポートが終了しており、テクニカルガイダンスが2019年1月17日までとなっております。

エンタプライズのモジュール

Zimbraのクラシック HSM, クラシック Backup, およびクラシック Mobile のサポートが終了しており、次回の Zimbra 8.8 のリリースから削除する予定です。 ネットワーク版のNGモジュール、またはZSPへ移行していない場合、お早めに移行いただくことを推奨しております。

Zimbra デスクトップ

デスクトップクライアントのサポートが終了しており、テクニカルガイダンスが2019年10月1日までとなっております。

Zimbra タッチクライアント

サポート終了

Zimbra モバイルクライアント

サポート終了

HTML クライアント

サポート終了しており、テクニカルガイダンスが2022年7月1日までとなっております。

製品の概略

本章ではZimbraコンポーネントのシステム概要を説明します。

インフラの概要

Zimbra Collaboration のアーキテクチャは既知のオープンソース技術と業界標準に基づいたプロトコルから構成されています。そして、単体あるいは複数サーバーで構成された環境で稼動可能なクライアントインターフェースやサーバーコンポーネントによって、高い利便性と拡張性を実現しています。

Architectural Overview

Zimbra Collaboration のアーキテクチャの主な特性

主な特性 コンポーネンツ/説明

オープンソース技術

Linux®, Jetty, Postfix, MariaDB, OpenLDAP®

業界基準のオープンプロトコル

SMTP, LMTP, SOAP, XML, IMAP, POP

現代の技術をいかした設計

HTML5, Javascript, XML, Java

スケーラビリティ

Zimbraの各メールボックスサーバーには、メールボックスアカウントと紐づくメッセージおよびインデックスが格納されます。Zimbraのプラットフォームは、縦横無尽に拡張することができます (システムリソース追加、サーバー追加)。

ブラウザでのクライアント画面

一般的なウェブプラットフォームから、簡単かつ直感的にZimbra Collaboration機能を利用することができます。

ブラウザでの管理コンソール

メール、カレンダー、共有機能

Zimbra Collaboration は革新的なメッセージングとコラボレーションのアプリケーションであり、ブラウザベースのウェブクライアントからアクセス可能な最先端のソリューションを提供しています。

  • 直観的なメッセージ管理、検索機能、タグ機能、共有機能

  • 公開、非公開あるいは共有可能なカレンダー

  • 非公開あるいは共有可能なアドレス帳や配信リスト

  • 非公開あるいは共有可能なタスクリスト

Zimbra のコンポーネント

Zimbraのアーキテクチャは、業界標準のプロトコルを利用したオープンソース技術で構成されています。サードパーティー製のソフトウェア一覧にあるサードパーティー製のソフトウェアはZimbraのソフトウェアにバンドルされているので、Zimbraのインストール処理時に自動インストールされます。これらのコンポーネントはZimbraで使用できるように検証・設定されています。

Table 1. サードパーティー製のソフトウェア一覧
サードパーティーコンポーネント 説明

Jetty

Zimbraソフトウェアが起動するウェブアプリケーションサーバー

Postfix

適したZimbraサーバーへメールメッセージを転送するオープンソースのメール転送エージェント (MTA)

Open LDAP ソフトウェア

Zimbra のシステム設定とZimbraのグローバルアドレス帳を格納し、ユーザー認証を行う、Lightweight Directory Access Protocol (LDAP) のオープンソース実装。ZimbraはActive Directoryなどの外部LDAPディレクトリより提供しているGALやユーザー認証サービスでも利用できます。

MariaDB

データベースソフトウェア

Lucene

オープンソースのテクストと検索エンジン

特定の添付ファイルの種類をHTMLへ変換するサードパーティソース

アンチウイルスとアンチスパム

オープンソース部分では以下が含まれています。

  • ClamAV: アンチウイルスのスキャナー

  • SpamAssassin: 迷惑メールを判断するメールフィルター

  • Amavisd-new : MTAと複数のコンテンツフィルターのインターフェース

Apache JSieve

メール用フィルターを管理

LibreOffice

ハイファイなドキュメントプレビュー

Zimbra のアプリケーションパッケージ

Zimbra Collaboration には、アプリケーションパッケージ一覧にあるアプリケーションパッケージが含まれています。

Table 2. アプリケーションパッケージ一覧
パッケージ 説明

Zimbra Core

ライブラリ、ユーティリティ、監視ツール、基準の設定ファイル。 Zimbra-core内にある zmconfigd は自動的に有効にされ、全てのシステムで起動します。

Zimbra Store

(Jettyを含む) メールボックスサーバー用コンポーネント。Zimbraメールボックスサーバーには以下のコンポーネントが含まれます。

  • データストア — MariaDBのデータベース。

  • メッセージストア — メールメッセージおよび添付ファイルすべての保存先。

  • インデックスストア — インデックスと検索技術はLuceneで提供しています。インデックスファイルは各メールボックスに保持されます。

  • ウェブアプリケーションサービス — Jettyウェブアプリケーションサーバーがいずれかのストアサーバー上でウェブアプリケーションを実行します。1つ以上のウェブアプリケーションサービスを提供します。

Zimbra LDAP

Zimbra Collaboration はオープンソースのLDAPディレクトリサーバーである、 OpenLDAP® のソフトウェアを使用しています。ユーザー認証やZimbraのグローバルアドレス帳、そして設定の属性は、OpenLDAPより提供されるサービスです。なお、ZimbraのGALやユーザー認証は、Active Directoryなどの外部LDAPディレクトリでも運用できます。

Zimbra MTA

Postfixはオープンソースのメール通信エージェント (MTA) です。PostfixではSMTPよりメールを受信し、ローカルメール通信プロトコル (LMTP) を利用してメッセージを適したZimbraメールボックスサーバーへとルートします。 また、ZimbraのMTAにはアンチウイルスとアンチスパムのコンポーネントも含まれています。

Zimbra Proxy

Zimbra プロキシはIMAP[S]/POP[S]/HTTP[S]のクライアントリクエストを内部 ZCS サービスへ配信する高パフォーマンスなプロキシサービスです。このパッケージは通常、MTAサーバーまたは独自サーバーにインストールされます。Zimbra-proxyパッケージがインストールされるとプロキシ機能がデフォルトで有効化されます。Zimbraプロキシをインストールすることを強く推奨しますし、分散されたウェブアプリケーションサーバーを使用する場合は必要です。

Zimbra Memcached

ZimbraプロキシをインストールするとMemcachedが自動的に選択されます。プロキシを使用する場合は最低1つのサーバーでzimbramemcachedを実行する必要があります。1つ以上のZimbraプロキシを備えた単一のMemcachedサーバーを使用することもできます。分散されたウェブアプリケーションサーバーを使用する場合、zimbra-memcachedが必要です。

Zimbra SNMP (任意)

サーバー監視のためZimbra SNMPをインストールする場合、このパッケージを各Zimbraサーバーにインストールする必要があります。

Zimbra Logger (任意)

使用する場合は、1つのメールボックスサーバーにのみインストールし、同時にメールボックスサーバーとしてインストールしなければなりません。このZimbraロガーにより、syslogの記録・取得用ツールがインストールされます。ロガーをインストールしないと、管理コンソールに サーバー統計 は表示されません。

Zimbra Spell (任意)

AspellのオープンソーススペルチェックをZimbraウェブクライアントに使用しています。Zimbra-Spellをインストールする場合、Zimbra-Apacheパッケージもインストールされます。

Zimbra Apache

このZimbra Apacheパッケージは、Zimbra Spell、またはZimbra Convertdのインストール中にインストールされます。

Zimbra Convertd

このパッケージはZimbraストアサーバーにインストールします。Zimbra CollaborationのシステムにはZimbra-Convertdパッケージは1つのみ必要です。デフォルトでは1つのZimbra-Convertdが各Zimbraストアサーバーにインストールされます。Zimbra- Convertdをインストールすると、Zimbra-Apacheのパッケージもインストールされます。

Zimbra Archiving (任意)

アーカイブとディスカバリー機能によりZimbra Collaborationが送受信したメッセージをすべて格納・検索することができます。このパッケージはメールボックスのクロス検索機能を含んでおり、使用中のメールボックスおよびアーカイブされたメールボックスの両方に対してメッセージ検索が可能です。 備考:アーカイブとディスカバリー機能を使用するとメールボックス利用ライセンスの追加につながる恐れがあります。Zimbra アーカイブとディスカバリー機能に関する詳細はZimbraの営業部までご連絡ください。

メールの流れ — マルチサーバー設定

各環境の設定内容は、変数の数値によって変わ変化します。例えば、メールボックス数、メールボックス容量、パフォーマンス要件、既存のネットワークインフラ、ITポリシー、セキュリティ方針、スパムフィルターリング要件などです。一般的にどの環境でも、発生するトラフィックやユーザー接続は下図に示すとおり、共通しています。ネットワーク内で数値の部分を設定するという方法でも可能です。

Mail Flow - Multi-Server Configuration

図の順番の説明をします。

  1. インターネットメールを受信したら、迷惑メールのフィルターリングのため、ファイアウォールとロードバランサーを通してからEdge MTAへ送ります。

  2. フィルターされたメールが2番目のロードバランサーへ届きます。

  3. 外部ユーザーがメッセージングサーバーへ接続した場合も、ファイアウォールと2つのロードバランサーを通ります。

  4. 受信されたインターネットメールは、いずれかのZimbra Collaboration のMTAサーバーへと向かい、迷惑メールとウイルスのフィルターリングを通過します。

  5. 対象のZimbra Collaboration MTAサーバーは宛先のディレクトリ情報をZimbra CollaborationのLDAPレプリカのサーバーに検索しにいきます。

  6. Zimbra Collaboration のLDAPサーバーからユーザー情報を取得後、MTAサーバーは適したZimbra Collaboration メールボックスサーバーへメールを通信します。

  7. 内部のエンドユーザーから接続される場合は、Zimbra Collaboration サーバーのいずれかに直接接続し、Zimbra Collaboration LDAPからユーザー情報を取得します。必要に応じてリダイレクトされます。

  8. マウントしたディスクに対してZimbra Collaborationサーバーのバックアップをとることも可能です。

Zimbra システムディレクトリのツリー

以下の表はZimbraのインストールパッケージで作成されるメインディレクトリの一覧です。(親である) /opt/zimbra 配下にインストールする場合、Zimbra CollaborationではどのZimbra Collaborationサーバーでもディレクトリ構成は同じになります。

この表にないディレクトリは、Zimbraのコアとなるソフトウェアや、その他サードパーティ製のツールに必要とされるライブラリです。
Table 3. /opt/zimbra 配下のシステムディレクトリツリー
ファイル 説明

backup/

完全バックアップと増分バックアップのデータを保存

bin/

コマンドラインのユーティリティにて記載されているユーティリティを含むZimbra Collaboration のアプリケーションファイル

cdpolicyd

ポリシーのファンクション、スロットル機能

clamav/

ウイルスや迷惑メールを制御するClam AVのアプリケーションファイル

conf/

設定の情報

contrib/

通信に使用するサードパーティ製のスクリプト

convertd/

変換のサービス

cyrus-sasl/

SASL AUTH のdaemon (デーモン)

data/

LDAP、mailboxd、postfix、amavisd、clamavなどのデータディレクトリを含みます。

db/

データストア

docs/

SOAPやその他の技術に関するtxtファイル

extensions-extra/

様々な認証方法に関するサーバーの拡張

extensions-network-extra/

様々なネットワーク認証方法に関するサーバーの拡張

httpd/

Apacheのウェブサーバーを含みます。Aspellとconvertdを別々のプロセスとして使用します。

index/

インデックスのストア

java/

Javaのアプリケーションファイル

jetty/

mailboxdアプリケーションサーバーインスタンス。このディレクトリの webapps/Zimbra/skins 配下にZimbra UIのテーマファイルが入っています。

lib/

ライブラリ

libexec/

内部で使用する実行ファイル

log/

Zimbra Collaboration サーバープリケーションのローカルログ

logger/

ログサービスが使用するRRDとSQLite のデータファイル

mariadb/

MariaDB のデータベースファイル

net-snmp/

統計収集に使用

openldap/

OpenLDAPのサーバーインストール。ZCSが使用できるようにあらかじめ設定されています。

postfix/

Postfixのサーバーインストール。Zimbra Collaborationが使用できるようにあらかじめ設定されています。

redolog/

Zimbra Collaboration サーバーでの最新の実行ログ

snmp/

SNMPのモニターファイル

ssl/

証明書

store/

メッセージストア

zimbramon/

コントロールのスクリプトやPerlモジュール

zimlets/

Zimbraと一緒にインストールするZimletのZipファイル

zimlets-deployed/

Zimbraのウェブクライアントで使用可能なZimlet

zimlets-network/

ネットワーク版のZimbraと一緒にインストールするZimletのZipファイル

zmstat/

mailboxd の統計。csvファイルとして保存されます。

Zimbraウェブクライアント

ユーザーはZimbra機能を使用する際に、様々なウェブクライアントからログインすることができます。ウェブクライアントではメール、カレンダー、アドレス帳、タスク等の機能を利用できます。

Table 4. Zimbraウェブクライアント
クライアントのタイプ 説明

アドバンス ウェブクライアント

Ajaxが動作可能で、ウェブコラボレーションの全機能を利用できます。高速なネットワーク回線および比較的新しいブラウザで快適に動作します。

標準 ウェブクライアント

低速インターネット回線やメールボックスをHTMLベースで使用したいユーザーに向いています。

モバイル HTML クライアント

標準 ウェブクライアント使用中にZimbraへのモバイルアクセスを行います。

Zimbraへのログイン時、ログイン画面で標準ウェブクライアントへ変更するメニューを使用しない限り、アドバンス ウェブクライアントが表示されます。ZWCは画面解像度が800x600であることを検知すると、自動で標準ウェブクライアントにリダイレクトします。ユーザーはこの場合もアドバンス ウェブクライアントを選択できますが、見やすい画面表示のための、標準ウェブクライアントを推奨するメッセージが表示されます。

ウェブサービスとデスクトップクライアント

Zimbra Collaborationへの接続は、ウェブブラウザやモバイルデバイスの他に、Exchangeウェブサービス (EWS) などのウェブサービスや、MAPIを使ったMicrosoft Outlook Zimbraコネクタのようなデスクトップクライアントからも可能です。以下をサポートします。

  • Exchange ウェブサービス (EWS) Mac端末でMicrosoft Outlookを利用する際の Zimbra Collaboration とExchangeサーバーとのクライアント通信を可能にします。EWSのクライアント通信を有効化する方法は、提供サービスの章を参照してください。EWSはライセンス対象のアドオン機能です。

  • Messaging Application Programming Interface (MAPI) Microsoft Outlook 2013/2010/2007/2003との同期が可能です。全てを委譲でき、オフラインアクセスも可能で、S/MIMEもサポートしています。Windows端末でMicrosoft Outlookを利用する際は、Zimbra Collaborationへの接続にOutlook用のZimbraコネクタを使用してください。MAPI (Microsoft Outlook)コネクタを有効化する方法は、提供サービスの章を参照してください。

  • サポート対象:全てのPOP3、IMAP4、CalDAVクライアント、CardDAVクライアント

オフラインモード

Zimbraのオフラインモードではネットワーク接続がない場合にも Zimbraウェブクライアント(ZWC)を使用してデータにアクセスすることができます。

例えば、サーバー接続がない場合やサーバー接続が切断された場合は、ZWCが自動的に“オフラインモード”へ切り替えます。サーバー接続が復元されると、自動で“オンラインモード”に切り替えます。

オフラインモードでは、通常のブラウザキャッシングを考慮したキャッシュ機能のあるHTML5を使用します。

セキュリティ対策

情報インフラを守るための最善策のひとつは、セキュリティ対策を複数組み合わせて使用し、システム全体のセキュリティを向上させることです。以下に記載したこうした対策は、防御用のメカニズムとしてZimbra Collaboration のプラットフォームに実装されています。

セキュリティ関連のニュースや注意など、最新の情報や詳細は、 Zimbra WikiSecurity Center からご覧ください。

認証とアクセス管理

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

Table 5. 認証とアクセス管理機能
機能 説明

ライフサイクル管理

Zimbra Collaborationのユーザー管理関連の登録・読込・更新・削除の全機能にLDAPディレクトリを使用します。 LDAP利用は任意ですが、Zimbra Collaboration専用の属性はすべて、従来のLDAPディレクトリにて格納・管理されます。

1要素認証

システムへのアクセスに必要とされる、ユーザーの登録済みユーザー名とパスワードのペアです。 この認証情報はソルト付ハッシュにてユーザー用ストアに登録されています。入力されたパスワードと比較して、承認 (一致) か不承認 (不一致) かを判断します。外部ディレクトリ (LDAPまたはActive Directory) を使用したい場合は、その外部LDAPディレクトリにログイン情報を格納することもできます。詳しくはZimbra LDAP サービスをご覧ください。

2要素認証

2層のセキュリティ認証です。管理コンソールから、ZCSと連携しているモバイル端末にパスコード生成を行う (Enabled) か行わないか (Disabled) を設定します。ユーザーまたはCOSアカウントに対して生成を行うを設定した場合は、クライアントサービスへの接続に、生成されたパスコードの使用が必要となります。詳しくは2要素認証について2要素認証をご覧ください。

アクセス権認証

ユーザーカウントは、様々な属性や権限レベル、ルールによって、実行可能な機能や閲覧可能なデータについて定義されています。管理コンソールの管理者は、各業務をサポートする目的でグループの作成や、アクセス権限の割り当てができます。

情報セキュリティとプライバシー

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

Table 6. 情報セキュリティとプライバシー機能
主旨 説明

セキュリティ・統一性・プライバシーの管理

Zimbra Collaboration は (公的信用のある認証局 (CA) から与えられた) S/MIME 認証の使用ならびに、内部PKI (公開鍵基盤) 、ドメインキー認証メール (DKIM) 、DMARC (Domain-based Message Authentication) 、Amavisd-new (受信、送信用DMARCポリシーを管理するためにMTAで稼働している) の利用をサポートしています。

暗号化メソッド

In-transit

後述のプロトコルに加え、TLSを利用して、サービスとエンドポイントを安全につなぎます: SMTP, LMTP+STARTTLS, HTTPS, IMAPS/IMAP+STARTTLS, POP3S/POP3+STARTTLS

At-rest

エンドtoエンドの暗号であるS/MIMEを使用して、秘密鍵による復号が行われるまで、Zimbra Collaboration メッセージストアにあるデータは暗号化されています。

Anti-virus とAnti-spam

従来のZimbra Collaboration 機能とサードパーティ製プラグイン (Amavisd-new, ClamAV, Spam Assassin) にて、マルウェアとスパムの対策を行っています。

システムログ

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

Table 7. セキュリティデータ
機能 説明

インシデント対応

管理者は、悪意のあるアクションや不慮の行動に対し、リモートでのデバイズワイピングやアカウント凍結を行うことができます。

アーカイブとディスカバリ

この任意の機能により、管理者は、アーカイブメールボックスと現行メールボックスのアーカイブや保存ポリシーの適用対象とする特定のユーザーのメールメッセージを選択できます。

ライセンス

アカウントの作成にはZimbraライセンスが必要です。Zimbraのライセンスの購入、更新、変更時は、その最新のライセンス情報にてZimbraサーバーを更新します。

ライセンスの種類

Zimbra Collaboration のライセンス機能により管理者は、配備予定のライセンスを見た目に分かりやすく制御できます。なお、以下のライセンスされた機能の監視や管理は可能となっています。

ライセンス上限 以下の上限を設定

アカウント上限

作成可能アカウント数と作成済みアカウント数が表示されます。

MAPIアカウント上限

Microsoft Outlook(ZCO)用Zimbraコネクタを使用できるアカウント数。

Exchange ウェブサービス(EWS) のアカウント上限

Exchangeサーバーへの接続にEWSを使用できるアカウント数。EWSはライセンス対象のアドオン機能です。

ハイファイなドキュメントプレビュー

ハイファイなドキュメントプレビューを使用できるアカウント数。LibreOfficeをインストールする必要があります。

アーカイブ用アカウント上限

作成可能アーカイブ用アカウント数。アーカイブ機能をインストールする必要があります。

提供しているライセンスの種類

Zimbra Collaborationの試用版を無料で入手できます。本番環境にインストール後は、サブスクリプションまたはパーペチャルの購入が必要なります。

ライセンスの種類 目的

試用版

無料。Zimbraのウェブサイト(https://www.zimbra.com) から入手できる試用版。最大50ユーザーの作成が可能。最大60日間有効。

試用延長版

無料。最大50ユーザーの作成が可能。期間延長可。Zimbra営業部より入手できます。sales@zimbra.com または1-972-407-0688までご連絡ください。

サブスクリプション

有料。特定のZimbra Collaboration システムに適用可。購入したZimbraアカウント数、使用開始日および有効期限がライセンスファイル内に暗号化されています。

パーペチャル

有料。サブスクリプションと同様、特定のZCSシステムシステムに適用可。購入したZimbraアカウント数、使用開始日および有効期限2099年12月31日がライセンスファイル内に暗号化されています。サポート契約を更新する場合、新しいパーペチャルライセンスは発行されませんが、システムにあるお客様のアカウントレコードはサポート終了日にて新たに更新されます。

アカウント種類でのライセンス影響

以下にZimbra Collaboration のアカウント種類とライセンスへの影響を説明します。

ライセンスのアカウント種類 目的

システムアカウント

システムアカウントはZimbra Collaborationで使用する特別なアカウントです。迷惑メール(スパムとハム)フィルターリング用アカウント、ウイルス付きメール隔離用アカウント、ドメインにGALを設定するGALsync用アカウントなどがあります。削除しないようにご注意ください!システムアカウントはライセンスのアカウント数には含まれません。

管理者アカウント

管理者アカウントと管理権限委譲アカウント。ライセンスのアカウントとしてカウントされます。

ユーザーアカウント

ユーザーアカウントはライセンスのアカウント上限数にカウントされます。アカウントを削除すると、この変更がライセンスのアカウント上限数に反映されます。

エイリアスアカウント

非該当

配布リスト

リソースアカウント

ライセンスのアクティベーション

ネットワーク版の環境はすべて、ライセンスをアクティベーションする必要があります。新しい環境の場合はライセンス発行日から10日間のアクティベーション猶予期間があります。管理コンソールから実施可能です。

管理コンソール:

ホーム > 設定 > グローバル設定 > ライセンス にアクセスし、画面の右上 ギア アイコンの ライセンスのアクティベーション を選択します。

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 はシングルユーザーモードに切り替わり、全機能が1ユーザーの利用に制限されます。

無効

Zimbra Collaboration はシングルユーザーモードへと切り替わります。

アクティベートしていない

ライセンスのアクティベーション猶予期間は10日間です。何かしらの理由によりライセンスがアクティベーションされない場合、 猶予期間後、Zimbra Collaboration はシングルユーザーモードへと切り替わります。

開始が未来日

Zimbra Collaboration はシングルユーザーモードです。

猶予期間中

ライセンス満了日が過ぎ、30日の更新猶予期間中です。ライセンス契約していた機能はまだすべて有効ですが、ライセンスの更新警告メッセージを管理者が確認する可能性があります。

満了

ライセンス満了日が過ぎ、30日の更新猶予期間も経過しています。 Zimbra Collaboration サーバーはオープンソース版の機能へと切り替わります。

ライセンスを入手する

ZimbraのホームページにあるDownloadsから無料の試用版ライセンスを入手できます。試用延長版ライセンスやサブスクリプション、パーペチャルの入手については、Zimbraの営業部 sales@zimbra.com までお問い合わせください。

購入したZimbra Collaboration システムにのみサブスクリプションやパーペチャルのインストールが可能です。お客様のZimbra Collaboration 環境にに必要なZimbraライセンスは1つです。このライセンスには作成可能なアカウント数の上限を設定します。

購入したアカウント数、使用中アカウント数、満了日などの現ライセンス情報は ホーム > 設定 > グローバル設定 > ライセンス から確認できます。

ライセンスを管理する

管理コンソールの グローバル設定 ページにある ライセンスを更新 ウィザードを使用して、新しいライセンスのアップロードとインストールができます。ライセンスのアクティベーション を使用すると、インストールされているライセンスがアクティベーションされます。

ホーム > 設定 > グローバル設定 > ライセンス から、現ライセンス情報を確認できます。ライセンスID、利用開始日、満了日、購入アカウント数および使用可能アカウント数が表示されます。

ライセンス情報

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

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

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

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

ライセンスの満期

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

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

  • バックアップと復元

  • Exchangeウェブサービス(EWS) — EWSは別売りのライセンス機能です

  • ハイファイなドキュメントプレビュー

  • Outlook用のZimbraコネクタ

  • S/MIME

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

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

更新

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

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

ライセンスを更新する

Zimbraのライセンスの更新、変更時は、その最新のライセンス情報にて Zimbra Collaboration メールボックスサーバーを更新してください。管理コンソールから、あるいはコマンドラインでzmlicenseコマンドを使用することで、ライセンスの更新が可能です。

zmlicense
管理コンソール:

ホーム > 設定 > グローバル設定 > ライセンス

ライセンスの更新

  1. 管理コンソールへ接続するパソコンにZimbraのライセンスを保存します。

  2. 管理コンソールにログイン後、 ホーム > 設定 > グローバル設定 > ライセンス に遷移し、画面の右上 ギア アイコンにある ライセンスを更新 をクリックします。 ライセンス インストール ウィザードが開きます。

  3. 保存したライセンスファイルをブラウザで選択し、次へ をクリックすると、ライセンスファイルがサーバーへアップロードされます。

  4. インストール をクリックします。アップロードしたライセンスがサーバーにインストールされます。

  5. ギア アイコンにある ライセンスのアクティベーション をクリックします。Zimbra Collaborationのアップグレード時は、ネットワーク版の機能を継続するためにただちにアクティベーションする必要があります。

ライセンスの情報が自動で更新されます。キャッシュされたアカウントライセンスの数は各メールボックスサーバーにて自動リフレッシュされます。

Zimbraのメールボックスサーバー

Zimbraのメールボックスサーバーは、メッセージ、連絡先、カレンダー、添付ファイルなど、メールボックスのすべてのコンテンツを管理するサーバーです。

Zimbraのメールボックスサーバーではバックアップとログファイルを専用のボリュームに保持します。各サーバーがアクセスできるのは、自身のサーバー内にあるストレージボリュームのみです。他のサーバーへの読み込み、書き込み、閲覧はできません。

メールボックスのサーバーについて

アカウントは1メールボックスサーバー内に設定され、各アカウントに紐づくメールボックスには、メッセージ、添付ファイル、カレンダー、連絡先、そのアカウントのコラボレーションファイルが入っています。

各Zimbraメールボックスサーバーには、そのサーバーに存在するメールボックス用に、メッセージストア、データストア、インデックスストアがスタンドアロンの状態で存在します。ここからは、各ストアとディレクトリの場所についての概要を説明します。

メッセージストア

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

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

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

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

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

データストア

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

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

  • データストアは、メールボックスIDとユーザーのLDAPアカウントをマッピングします。Zimbra Collaboration データベース内の第一識別子はZCSメールボックスIDであり、ユーザー名やアカウント名ではありません。メールボックスIDはシングルメールボックスサーバー内では一意です。

  • ユーザーのタグ定義、フォルダ、連絡先、カレンダーの予定、タスク、ブリーフケースのフォルダ、フィルターのルールなどのメタデータは、データストアデータベースに格納されています。

  • メッセージの閲覧状況、関連タグなどのメッセージ関連情報は、データストアデータベースに格納されています。

インデックスストア

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

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

Index Store

プロセスの説明

  1. Zimbra のMTAは、受信したメッセージをそのアカウントのメールボックスが存在しているメールボックスサーバーにルートします。

  2. そのメールボックスサーバーは、メッセージのヘッダーや本文、添付ファイル(PDFファイルやMicrosoft Wordドキュメントなど)を解析し、単語をトークン化します。

  3. インデックスファイル作成のため、メールボックスサーバーは、トークン化した情報をLuceneへ渡します。

トークン化とは単語単位でのインデックスです。電話番号、メールアドレス、ドメイン名などの代表的なパターンは、上の図のようにトークン化されます。

ウェブアプリケーションサーバー

Jettyウェブアプリケーションサーバーはどのストアサーバー上でもウェブアプリケーション(webapps)を実行し、単体または複数のウェブアプリケーションサービスを利用できるようにします。

メールストアサービス

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

  • メールストア(メールサーバー) = /opt/zimbra/jetty/webapps/service

  • Zimlets = /opt/zimbra/jetty/webapps/zimlet

ユーザーインターフェースサービス

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

  • Zimbraウェブクライアント = /opt/zimbra/jetty/webapps/zimbra

  • Zimbra管理コンソール = /opt/zimbra/jetty/webapps/zimbraAdmin

  • Zimlet = /opt/zimbra/jetty/webapps/zimlet

ウェブアプリケーションサーバースプリット

ウェブアプリケーションサーバースプリット機能により、メールストアのサービス(メールサーバー)とユーザーインターフェースのサービス(ウェブクライアントサーバー)を分けることも可能です。

例えば、html/cssページなどの固定UIコンテンツを提供する「zimbra, zimbraAdmin」というウェブアプリケーションをウェブクライアントサーバーで実行し、すべてのSOAPリクエストを処理する「service」というウェブアプリケーションをメールサーバーで実行します。この2つのサーバーはスプリットモードで動いています。

ウェブアプリケーションサーバースプリット機能には以下のメリットがあります。

  • ウェブクライアントとメールサーバーを分割することでカスタマイズのプロセスが簡単になり、メールサーバーを再起動せずに新しくカスタマイズしたUIや更新したUIを提供できるようになります。つまり、ダウンタイムが発生しません。

  • ZimbraウェブクライアントやZimbra管理コンソールをカスタマイズする場合、メールサーバーを停止させずに、ウェブクライアントサーバーをオフラインにしてカスタマイズやメンテナンスを行なうことができます。

  • ウェブクライアントは、メールボックスのアカウントとは全く関係がありません。つまり、どのウェブクライアントサーバーでも、アカウントのリクエストを処理できます。

ウェブアプリケーションサーバースプリットのインストールと設定方法

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

メールボックスのサーバーをバックアップする

Zimbra Collaborationには、Zimbra Collaborationサーバーごとに設定可能なバックアップマネージャーがあり、バックアップと復元の両機能を実施できます。バックアッププロセスの実行のためにZimbra Collaborationサーバーを停止する必要はありません。バックアップマネージャーを使用してシングルユーザーのメールボックスを復元できます。1ユーザーのメールボックスが破損した時に、システム全体を復元する必要はありません。完全バックアップと増分バックアップは /opt/zimbra/backup に保存されます。詳細は バックアップと復元を参照してください。

Zimbraの各メールバックスサーバーは、最後の増分バックアップ以降にメッセージストアサーバーで処理された、現在のトランザクションとアーカイブのトランザクションの入ったRedoログを生成します。サーバー復元時、バックアップファイルを完全に復元し終わったら、アーカイブのRedoログと使用中の現在のRedoログに保存されているRedoログをすべてリプレイし、システムが落ちた地点まで戻します。

メールボックスのサーバーログ

Zimbra Collaboration のシステム環境は、1つまたは複数のメールボックスサーバーとサードパーティ製のコンポーネントで構成されています。いずれのコンポーネントからもログデータが出力される可能性はあります。ローカルのログは /opt/zimbra/log に保存されます。

Zimbra Collaborationログメッセージを選択すると、SNMPトラップが生成されます。SNMP監視ソフトウェアを用いれば、これをキャプチャできます。詳細については ZCS サーバーの監視を参照してください。

システムログ、Redoログ、バックアップしたセッションを別々のディスクに保存することにより、ディスク破損時における復旧不可能なデータロスのリスクを最小限に留めるようにしてください。

IMAP

Zimbra Collaboration はデフォルトでインストールされる内部の IMAP サーバが含まれており、zimbra-mailboxd のプロセスの一部となっております。(Zimbra Mailbox Server)

一般的な IMAP 設定オプション

以下のグローバルとサーバ側の設定では IMAP サービスの管理やチューニングが可能となっております。

  • zimbraImapServerEnabled. TRUE に設定した場合、内部の IMAP サーバが有効化されます。FALSE に設定した場合、内部の IMAP サーバが無効化されます。デフォルトの設定は TRUE です。

  • zimbraImapSSLServerEnabled. TRUE に設定した場合、内部の IMAP SSL サーバが有効化されます。FALSE に設定した場合、内部の IMAP SSL サーバが無効化されます。デフォルトの設定は TRUE です。

  • zimbraImapBindAddress (サーバ側での設定のみ). 内部の IMAP サーバプロセスがリッスンするインターフェースのアドレスを指定します。値が空の場合、すべてのインターフェースへバインドします。

  • zimbraImapBindPort. 内部の IMAP サーバプロセスがリッスンするポート番号を指定します。デフォルトの値は 7143 です。

  • zimbraImapSSLBindAddress (サーバ側での設定のみ). 内部の IMAP SSL サーバプロセスがリッスンするインターフェースのアドレスを指定します。値が空の場合、すべてのインターフェースへバインドします。

  • zimbraImapSSLBindPort. 内部の IMAP SSL サーバプロセスがリッスンするポート番号を指定します。デフォルトの値は 7993 です。

  • zimbraImapNumThreads. IMAP ハンドラのスレッドプールに使用可能なスレッド数を指定します。デフォルトでは Zimbra Collaboration が IMAP NIO を使用しておりますので、各 IMAP ハンドラスレッドが複数のコネクションを処理できます。デフォルト値の 200 では最大 10,000 アクティブ IMAP クライアントを同時に処理できます。

  • zimbraImapCleartextLoginEnabled. 非 SSL/TLS コネクションで cleartext のログインを許可するかどうかを指定します。デフォルトの設定は FALSE です。

  • zimbraImapProxyBindPort. IMAP プロキシサーバがリッスンするポート番号を指定します。デフォルト設定は 143 です。詳細については Zimbra Proxy Components をご参照ください。

  • zimbraImapSSLProxyBindPort. IMAP SSL プロキシサーバがリッスンするポート番号を指定します。デフォルト設定は 993 です。詳細については Zimbra Proxy Components をご参照ください。

  • zimbraImapMaxRequestSize. 実際のデータを除いた IMAP リクエストの最大サイズをバイト数で指定します。注意: この設定は IMAP LOGIN リクエストには適用されません。IMAP LOGIN のリクエストは IMAP プロキシ (Zimbra Proxy Components) で処理しており、最大 256 文字に制限しております。

  • zimbraImapInactiveSessionCacheMaxDiskSize. 削除する非アクティブの IMAP キャッシュの最大ディスクサイズをバイト数で指定します。デフォルトの設定は 10GB です。Ehcache の内部仕様により、実際に使用するディスクサイズが上限を大きく超えてしまいますので、この上限は完全な上限ではありません。

  • zimbraImapInactiveSessionEhcacheSize. 削除する非アクティブの IMAP キャッシュの最大ヒープサイズをバイト数で指定します。デフォルトの設定は 1MB です。Ehcache の内部仕様により、実際に使用するディスクサイズが上限を大きく超えてしまいますので、この上限は完全な上限ではありません。

  • zimbraImapActiveSessionEhcacheMaxDiskSize. アクティブな IMAP キャッシュに使用できる最大ディスクサイズをバイト数で指定します。デフォルトの設定は 100GB です。Ehcache の内部仕様により、実際に使用するディスクサイズが上限を大きく超えてしまいますので、この上限は完全な上限ではありません。

Zimbra LDAP サービス

LDAPディレクトリサービスは、Zimbraサービスの利用が許されているユーザー情報およびデバイスが集積したレポジトリを提供します。Zimbra LDAPデータに使用される集積レポジトリには、OpenLDAPのディレクトリサーバーを使用しています。

Zimbra Collaboration はMicrosoft Active Directoryサーバーとの統合もサポートしています。特殊なディレクトリを実装する場合の詳細は、サポートまで連絡してください。

LDAPサーバーは、ZCS のインストール時にインストールされます。個々のサーバーが、処理パラメーターを特定する属性の入ったLDAPエントリを保持しています。また、各属性が特定されていないサーバーには、グローバル設定オブジェクトによりデフォルトが設定されます。

LDAP属性のサブセットはZimbraの管理コンソールやzmprovのコマンドラインで設定可能です。

LDAPのトラフィックの流れ

LDAPディレクトリのトラフィック図は、Zimbra LDAPのディレクトリサーバーと他のZimbra Collaborationサーバー間のネットワークトラフィックを示しています。 ZimbraのMTAとZimbra Collaborationのメールボックスサーバーは、ディレクトリサーバーにあるLDAPデータベースに対して読み込みと書き込みを行います。

Zimbraのクライアントは、LDAPへ接続するZimbraサーバー経由で接続します。

LDAP Traffic Flow

LDAP のディレクトリ階層

LDAPのディレクトリ階層はツリー状で、メールブランチと設定ブランチの2種類に分かれています。メールブランチはドメインで構成されています。ドメインに属するエントリ、例えばアカウント、グループ、エイリアスなどは、ディレクトリ内ではドメインDN配下に登録されます。設定ブランチにはドメインの一部ではない管理システムエントリが含まれています。設定ブランチのエントリには、システム管理のアカウント、グローバル設定、グローバル権限、COS、サーバー、MIMEタイプ、Zimletなどがあります。

Zimbra LDAP階層図です。各エントリ(オブジェクト)タイプには特定の関連オブジェクトクラスがあります。

LDAP Directory Hierarchy

LDAPディレクトリのエントリは、属性の集合でできており、グローバルで一意の名前(dn)を持っています。エントリに使用する属性は、そのエントリに関わるオブジェクトクラスによって決まります。オブジェクトクラス属性の値によって、そのエントリが従うべきスキーマルールが決まります。

エントリの種類を決めるオブジェクトクラスを構造のオブジェクトクラスと言い、変更ができません。それ以外のオブジェクトクラスを予備のオブジェクトクラスと言い、エントリの追加や削除が可能です。

LDAPで使用する予備のオブジェクトクラスは、既存のオブジェクトクラスを組み合わせることができます。例えば、 構造のオブジェクトクラス inetOrgPerson と予備のオブジェクトクラス zimbraAccount を持つエントリは、アカウントになります。 構造のオブジェクトクラス zimbraServer を持つエントリは、Zimbraシステム内の1つまたは複数のZimbraパッケージがインストールされているサーバーになります。

Zimbra Collaboration LDAPのスキーマ

各LDAP実装の中心には、スキーマを使用して構成したデータベースがあります。

ZimbraのLDAPスキーマは、OpenLDAPソフトウェアに含まれている一般的なスキーマを継承しています。既存のディレクトリ環境と共存するように設計されています。

Zimbra Collaboration 専用に作成した属性とオブジェクトクラスはすべて “zimbra”で始まります。例えばオブジェクトクラス zimbraAccount や 属性 zimbraAttachmentsBlocked などです。
OpenLDAP実装には、以下のスキーマファイルが含まれています。

  • core.schema

  • cosine.schema

  • inetorgperson.schema

  • zimbra.schema

  • amavisd.schema

  • dyngroup.schema

  • nis.schema

Zimbraのスキーマを変更することはできません。

Zimbra Collaboration のオブジェクト

オブジェクト 詳細 オブジェクトのクラス

アカウント

Zimbraのメールボックスサーバーにある、ログイン可能なアカウントのことです。アカウントエントリはユーザーアカウントもしくは管理者アカウントです。オブジェクトクラス名は zimbraAccount です。このオブジェクトクラスは zimbraMailRecipient のオブジェクトクラスを継承します。 全てのアカウントには次のプロパティがあります。
 - user@example.domain形式の名前
 - 変更されず、再利用されない一意のID
 - 属性
属性にはユーザーが(プリファレンスから)変更できるものと管理者のみ変更できるものがあります。 すべてのユーザーアカウントはドメインに紐づくため、アカウントの作成以前にドメインを作成する必要があります。

zimbraAccount

提供サービス (COS)

アカウントが持つデフォルト属性。使用できる機能、使用できない機能が定義されています。COSにより、機能やデフォルトのプリファレンス設定、メールボックス割り当て容量、メッセージの保持期限、パスワード制限、添付ファイルブロック設定、新規アカウントの作成用のサーバープールを制御します。

zimbraCOS

ドメイン

example.comexample.org のような、電子メールを使用可能にさせるドメインのことです。ドメインに属するユーザーへメッセージが配信されるよりも前に、ドメインが存在している必要があります。

zimbraDomain

配布リスト

メーリングリストとも言います。リストのアドレスへ1通、メールを送信すると、リストのメンバー全員へメッセージが届きます。

zimbraDistributionList

ダイナミックグループ

配布リストと類似しています。差異は、ダイナミックグループのメンバーはLDAP検索によって動的に計算されるという点です。LDAP検索フィルターはダイナミックグループエントリの属性内に定義されています。

配布リストもダイナミックグループもどちらも、委任された管理者のフレームワーク内で、被譲与者またはターゲットとして使用することができます。

zimbraGroup

サーバー

Zimbraシステム内の1つまたは複数のZimbraパッケージがインストールされているサーバーのことです。属性は、サーバーの設定情報で、サーバーで実行中のサービスを示したりします。

zimbraServer

グローバル設定

サーバーやドメインというオブジェクト用のデフォルト値を指定します。他のオブジェクト用の属性が設定されていない場合、その属性の値はグローバル設定から継承されます。グローバル設定値は必要なものなので、Zimbraコアパッケージの一環として、インストール中に設定されます。これがシステムのデフォルト設定の値になります。

zimbraGlobalConfig

エイリアス

アカウント、配布リスト、またはダイナミックグループのエイリアスのことです。 zimbraAliasTarget 属性はこのエイリアスエントリのターゲットエントリを指します。

zimbraAlias

Zimlet

Zimbra内にインストール・設定されているZimletを定義します。

zimbraZimletEntry

カレンダーのリソース

会議で指定することのできる機器や会議室のようなカレンダーリソースを定義します。カレンダーリソースとは、 zimbraCalendarResource オブジェクトクラスにさらに追加の属性を持つアカウントです。

zimbraCalendarResource

Identity

ユーザーのペルソナのことです。ペルソナには、ユーザーの識別情報、例えば、表示名、送信メールに使用する署名エントリのリンクが入っています。ユーザーは複数のペルソナを作成できます。IdentityエントリはDITにあるユーザーのLDAPエントリの直下に作成されます。

zimbraIdentity

データソース

ユーザーの外部メールソースを指します。データソースの例としては、POP3やIMAPがあります。データソースにはPOP3/IMAPのサーバー名、ポート、ユーザーの外部メールアカウントのパスワードが保存してあります。データソースには、表示名や外部アカウントの代わりに送信されるアウトバウンドメールに使用する署名へのリンクなどを含むペルソナ情報も格納されます。データソースのエントリはDIT内のユーザーのLDAPエントリの下に作成されます。

zimbraDataSource

署名

ユーザーの署名を指します。ユーザーは複数の署名を作成することができます。署名のエントリはDIT内のユーザーのLDAPエントリの下に作成されます。

zimbraSignature

アカウントの認証について

内外のLDAPおよび外部Active Directoryが、サポート対象の認証のメカニズムです。認証方式はドメインごとに設定します。 zimbraAuthMech 属性が設定されていない場合、デフォルトでは内部認証を使用します。

内部認証方式はOpenLDAPサーバーで動いているZimbraスキーマを使用します。

zimbraAuthFallbackToLocal 属性を有効にしていると、外部認証が失敗した場合にローカル認証へフォールバックできます。デフォルトはFALSEです。

内部認証のメカニズム

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

外部LDAPと外部Active Directoryの認証メカニズム

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

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

属性 zimbraAuthLdapURLzimbraAuthLdapBindDn が外部認証には必要です。

  • zimbraAuthLdapURL 属性の ldap://ldapserver:port/ は、外部ディレクトリサーバのIPアドレスまたはホスト名と、portでポート番号を表します。ポート番号の代わりに正式なホスト名を使用することもできます。

    ldap://server1:3268
    ldap://exch1.acme.com

    SSL接続の場合、 ldap: の代わりに ldaps: を使用します。サーバーが使用するSSL証明書は信頼済みの証明書として設定する必要があります。

  • 属性 zimbraAuthLdapBindDn には外部ディレクトリサーバーへバインドする際に使用するDNを指定します。

    認証のプロセスの始まりでは、ユーザー名は user@example.com の形式です。

    外部ディレクトリ内では、ユーザー名を有効なLDAPバインド DN (Distinguished Name:識別名)へ変換する必要がある場合があります。Active Directoryの場合、バインドの DN は別のドメインの可能性もあります。

カスタム認証

所有しているユーザーデータベースに外部認証を統合させるカスタム認証を実装できます。認証リクエストがくると、Zimbraはドメインに指定された認証メカニズムをチェックします。この認証メカニズムがカスタムに設定されている場合、Zimbraは登録されているカスタム認証ハンドラを実行して、そのユーザーを認証します。

カスタム認証のセットアップには、ドメインをカスタム認証に設定し、カスタム認証ハンドラを登録してください。

ドメインをカスタム認証に設定

ドメインをカスタム認証にするには、ドメインの属性 zimbraAuthMech に custom:{登録したカスタム認証ハンドラ名} を設定します。

下の例では、sampleの名の下に、カスタム認証が登録されています。

Example 1. ドメインをカスタム認証に設定する
zmprov modifydomain {domain|id} zimbraAuthMech custom:sample
カスタム認証ハンドラを登録する

カスタム認証ハンドラを登録するには下記を実行し、

ZimbraCustomAuth.register( handlerName, handler )

拡張のinitメソッドに追加します。

  • クラス: com.zimbra.cs.account.ldap.ZimbraCustomAuth

  • メソッド: public synchronized static void register (String handlerName, ZimbraCustomAuth handler)

    属性の説明:

    • handlerName の名の下に、このカスタム認証ハンドラがZimbraの認証インフラへ登録されます。この名前はドメインのzimbraAuthMech属性にも設定します。

    • handler というオブジェクト上で、認証方法は、このカスタム認証ハンドラの場合に実行されます。オブジェクトは ZimbraCustomAuth (またはサブクラス)のインスタンスである必要があります。

Example 2. カスタム認証ハンドラを登録する
public class SampleExtensionCustomAuth implements ZimbraExtension {

  public void init() throws ServiceException {
  /*
   * Zimbra の認証インフラへ登録。
   * custom:sample はドメインの属性zimbraAuthMech に設定してください。
   *    */
   ZimbraCustomAuth.register("sample", new SampleCustomAuth());
  }
...
}
カスタムの認証方法について

認証リクエストがくると、指定されたドメインがカスタム認証に設定されている場合、認証用フレームワークは ZimbraCustomAuth.register() のhandlerパラメーターとして渡されたインスタンス ZimbraCustomAuth 上で認証方法を実行します。

認証すべき最初のもの(プリンシパル)用のアカウントオブジェクトとユーザーが入力したクリアテキストのパスワードは ZimbraCustomAuth.authenticate() へ渡されます。

アカウントのオブジェクトからすべてのアカウント属性を取得できます。

Kerberos5 の認証方法

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

  1. kerberos5 を、このドメインの属性 zimbraAuthMech として設定します。

  2. Kerberosデータベース内でこのドメインのユーザーが作成されている Kerberos5 Realm を、このドメインの属性 zimbraAuthKerberos5Realm として設定します。 ユーザーがパスワードを使用してログインしたときに、そのドメインの属性 zimbraAuthMechkerberos5 に設定されていたら、サーバーは {メールアドレスのローカル部分}@{zimbraAuthKerberos5Realmの値} でKerberos5プリンシパルを構成させたものをkerberos5サーバーへの認証に使います。

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

グローバルアドレスリスト(GAL)について

グローバルアドレスリスト(GAL)はユーザーの社内ディレクトリで、通常、組織内で有効で、メールシステム内の全ユーザーが利用することができます。Zimbra Collaborationでは社内のユーザーアドレスを検索する際に、この社内ディレクトリを使用します。

Zimbra Collaborationのドメインごとに、GALを下記の利用に設定できます。

  • 外部のLDAPサーバー

  • Zimbra Collaborationの内部LDAPサーバー

  • GAL検索の外部LDAPサーバーおよびZimbra Collaboration LDAP

Zimbra CollaborationのウェブクライアントはGALを検索できます。ユーザーが名前を検索すると、名前がLDAPの検索フィルターへと変換されます。下記例の %s はユーザーが検索中の名前です。

Example 3. GALを検索する
(|(cn = %s*)(sn=%s*)(gn=%s*)(mail=%s*))
  (zimbraMailDeliveryAddress = %s*)
  (zimbraMailAlias=%s*)
  (zimbraMailAddress = %s*)

Zimbra Collaboration上でのGAL 属性

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

LDAP属性はGALエントリ項目にマッピングされます。例えば、LDAP属性 displayNamecn は、GALのエントリ項目 fullName へマップできます。このマッピングは zimbraGaILdapAttrMap 属性に設定されています。

Table 8. ZCSの連絡先属性へマップされた属性
デフォルトのLDAP属性 Zimbra Collaboration の連絡先属性 説明

co

workCountry

会社の国

company

Company

会社名

givenName/gn

firstName

sn

lastName

cn

fullName

フルネーム

initials

initials

名前のイニシャル

l

workCity

会社の市

street, streetaddress

workStreet

会社の住所

postalCode

workPostalCode

会社の郵便番号

telephoneNumber

workPhone

会社の電話番号

mobile

mobile

携帯番号

pager

pager

ポケベルの番号

facisimileTelephoneNumber

faxNumber

ファックスの番号

st

workState

会社の州

title

jobTitle

職種

mail

email

メールアドレス

thumbnailPhoto

サムネイルの画像

objectClass

Zimbra Collaboration GAL の検索条件

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

属性を変更する方法

GAL属性への追加、変更、削除はZimbraの管理コンソールから、または zmprov コマンドで実施します。

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

LDAPのキャッシュをフラッシュする

ZimbraLDAPサーバーで以下のタイプのエンティティを変更した場合、変更の反映にLDAPキャッシュのフラッシュが必要となる場合があります。

  • テーマ

  • 地域

  • アカウント

  • グループ

  • COS

  • ドメイン

  • グローバル設定

  • サーバー

  • Zimletの設定

テーマや地域のキャッシュをフラッシュする

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

スキンをフラッシュ
zmprov flushCache skin
地域をフラッシュ
zmprov flushCache locale

アカウント、グループ、COS、ドメインおよびサーバーをフラッシュする

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

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

アップデート時間の設定変更
zmlocalconfig ldap_cache_<object>_maxage
即座に変更を反映
zmprov flushCache {account|cos|domain|group|server|...} [name|id]...

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

サーバー属性によっては、キャッシュをフラッシュしたあとでも、再起動が必要なものもあります。例えば、バインドポートやプロセススレッド数などです。

グローバル設定をフラッシュする

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

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

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

  1. ローカルサーバーの設定を変更します。

    zmprov mcf zimbraImapClearTextLoginEnabled TRUE

    ローカル設定キーである zimbra_zmprov_default_soap_serverzimbra_admin_service_port により判別されるサーバー経由でこの変更を実行します。

  2. その他全サーバーのグローバル設定のキャッシュをフラッシュするには、各サーバーで zmprov flushCache を実行する必要があります(または zmprov flushCache -a を使用します)。

    例:

    zmprov -s server2 flushCache config
    zmprov -s server3 flushCache config
  3. サーバー再起動が必要かどうかを確認します。

    zmprov desc -a <attributename>

    再起動が必要な場合、requiresRestart が返されます。

Zimbraのメール送信エージェント

ZimbraのMTA (Mail Transfer Agent: メール送信エージェント) は、SMTP経由でメールを受信し、ローカルメールの配信プロトコル (LMTP) を利用して、各メッセージを適当なZimbraメールボックスにルートします。

MTAパラメーターの設定は、管理コンソールとCLIの両方で実施可能ですが、CLIのほうが確実な結果を得られます。

Zimbra MTAサーバーには、以下のプログラムが備わっています。

MTA サーバプログラム 目的/説明

Postfix MTA

メールのルートとリレー、添付ファイルのブロック。

Clam Anti-Virus

メールのメッセージ本文や添付ファイルのウイルススキャン。

Spam Assassin

迷惑メール (スパム) メッセージを判別。

Amavisd-New

PostfixとClamAV/SpamAssassin間のインターフェース。

Zimbra Milter Server

配布リストへ送信可能なアドレスを制限、配布リストからの送信メッセージに Reply-toX-Zimbra-DL のヘッダーを追加。

Zimbra policy server

バックスキャター迷惑メールからのエイリアスドメインの保護を支援。

Cluebringer

レート制限のようなアクションの強制実行に使用するポリシーdaemon/cbpolicyd。詳細は次を参照してください。 https://wiki.zimbra.com/wiki/Postfix_Policyd

Opendkim

送信メールへ署名するように設定されている場合に署名。詳細は次を参照してください。 https://wiki.zimbra.com/wiki/Configuring_for_DKIM_Signing

Zimbra Collaborationの設定では、メールの転送と配信は別物です。PostfixはMTA (転送の役割) として、Zimbraのメールサーバーはメール配信エージェント (MDA:配信の役割) として機能します。

MTAの設定はLDAPに格納されます。zmconfigd処理がLDAPのディレクトリを2分ごとにポーリングし、変更点をPostfixの設定ファイルに反映します。

メール受信のルートの概要

Zimbraメールボックスサーバーは、Zimbra MTAサーバーからメッセージを受け取り、事前に作成されている全フィルターに、そのメッセージを通します。

MTAサーバーはSMTPからメールを受け取ると、LMTPを使用して各メッセージを適当なメールボックスサーバーにルートします。メッセージが届くと、全ての要素を検索できるように、その内容をインデックスします。

Zimbra のMTA 配置

メールのルートやリレー、添付ファイルの管理のため、ZCSにはプリコンパイルしたPostfixが備わっています。PostfixはSMTP経由でインバウンドのメッセージを受け取ると、ウイルス対策と迷惑メール対策のフィルターリングを行い、LMTP経由でメッセージをZCSサーバーに渡します。

Postfixには、アウトバウンドメッセージを転送する役割もあります。Zimbraは、Zimbraウェブクライアントで作成したメッセージをPostfix経由で送信します。同一サーバーにいる他のユーザーへ送信するメッセージも同様です。

Zimbra MTA Deployment
Edge MTAは、メールのあらゆるEdgeセキュリティソリューションになり得ます。既に、 機能ソリューション、例えばフィルターリングなどは、配置済みかもしれません。フィルターリングの中にはEdge MTAとZimbra MTA間で重複するものもあります。

Postfix の設定ファイル

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

  • main.cf — LDAPテーブルを追加しています。Zimbra MTAの zmconfigd がZimbra LDAPからデータを取得し、Postfixの設定ファイルを変更します。

  • master.cf — Amavisd-Newを使えるように変更しています。

Postfix設定ファイルを編集してもアップグレード時に自動で上書きされてしまうため、正確に文書化しておく必要があります。可能であれば、Zimbraの定義済みパラメーターを使用して、必要となる設定内容の変更を実装してみてください。

SMTP 認証について

SMTP認証では、許可されたメール送信元だけが外部ネットワークからZimbra MTAへメッセージ送信することができます。SMTPクライアントのメッセージ送信時はユーザーIDとパスワードがMTAへ送信されます。

MTAは、そのLDAPアカウントに関する認証情報をチェックして、そのユーザーがメール配信を許可されているかどうかを確認できます。

ユーザー認証はZimbra LDAPのディレクトリサーバーから、あるいは実装されている場合はMicrosoft Active Directoryのサーバーから、実行されます。

SMTPの制限

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

制限の影響を理解してから設定するようにしてください。精度なメールシステムを使用していない人からのメッセージを受け入れるために、チェック機能を妥協しなければならない状況もあります。

外部サーバー宛のメッセージを別サーバーへ送信する

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

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

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

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

管理コンソール:

ホーム > 設定 > グローバル設定 > MTA → ネットワーク

リレーホストを設定する際、メールの送信ループが発生しないように注意してください。
MTA Settings

ウイルス対策と迷惑メール対策の保護

Amavisd-Newのユーティリティは、Zimbra MTA とClam Anti-Virus (ClamAV)やSpamAssassinスキャナー間のインタフェースです。

ウイルス対策の保護

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

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

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

管理コンソール:

Home > 設定 > グローバル設定 > AS/AV → ウィルス対策設定

Anti-Virus Protection
ClamAVのウェブサイトからHTTP経由で更新を取得します。
送信するメールの添付ファイルをスキャンする

Zimbraウェブクライアントを使用して送信されるメッセージの添付ファイルに対し、リアルタイムスキャンを実施できます。スキャンが有効な場合、ファイルがメールに添付されると、メッセージの送信前にClamAVによってスキャンされます。ClamAVがウイルスを検出すると、メッセージへのファイル添付がブロックされます。デフォルトでは、シングルノード環境の場合にスキャンが有効化されています。

シングルノード環境でスキャンを有効化するには、以下を実行します。

zmprov mcf zimbraAttachmentsScanURL clam://localhost:3310/
zmprov mcf zimbraAttachmentsScanEnabled TRUE

マルチノード環境でスキャンを有効化する場合

  1. ClamAVスキャンを処理するMTAノードを指定してください。

  2. 以下を実行し、有効化してください。

    zmprov ms <mta_server> zimbraClamAVBindAddress <mta_server>
    zmprov mcf zimbraAttachmentsScanURL clam://<mta_server>:3310/
    zmprov mcf zimbraAttachmentsScanEnabled TRUE

迷惑メール対策の保護

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

SpamAssassinを利用した迷惑メール対策

以下のトピックスにガイドラインが記載されています。

SpamAssassinのカスタマイズ方法についての詳細は https://wiki.zimbra.com/wiki/Anti-spam_strategies を参照してください。

SpamAssassinのスコアを管理する: SpamAssassinは、事前定義されているルールとBayesのデータベースを使用して、メッセージを数字でスコア付けします。Zimbraは、20を100%としたSpamAssassinのスコアをベースとしてメッセージの 迷惑度 をパーセント値で決定します。33%-75%のメッセージは迷惑メールと判断してユーザーの迷惑メールフォルダへ配信します。75%以上のメッセージは深刻な迷惑メールと判断して自動削除します。

管理コンソールから迷惑メールのしきい値と件名のプレフィックスを変更できます。

管理コンソール:

Home > 設定 > グローバル設定 > AS/AV → 迷惑メールチェック設定

Spam Assassin Settings

デフォルトでは、迷惑メールの学習にBerkeley DBのデータベースを使用しています。MariaDBのデータベースも使用可能です。

MTAサーバーにMariaDBのメソッドを使用する場合

zmlocalconfig -e antispam_mariadb_enabled=TRUE

これが有効なとき、Berkeley DBのデータベースは使用できません。

スパムフィルターに学習させる: ユーザーがインプットするスパム(迷惑)あるいはハム(迷惑ではない)の判別内容によって、迷惑メール対策フィルターの効果に違いがでます。ユーザーが迷惑メールのフォルダへメッセージを移動したり、迷惑メールのフォルダから通常のフォルダへメッセージを移動することにより、SpamAssassinフィルターは学習します。ユーザーが移動したメッセージのコピーは適宜、スパム学習用メールボックスに自動送信されます。

インストール時、スパム/ハムのクリーンアップフィルターは最初のMTAのみに設定されます。ZCSのスパム学習ツール(zmtrainsa)は自動的にメッセージを収集し、スパムフィルターに学習させます。 zmtrainsa スクリプトは、スパム学習用メールボックスを毎日空にします。

新しいZCS環境では、スパム/ハムの学習を当初インストールされているMTAに制限しています。このMTAをアンインストールまたは移動した場合、別のMTAに対してスパム/ハム学習を有効化する必要があります。この設定を行なわない場合、新しいMTAで zmtrainsa --cleanup を正常に実行することはできません。

新しいMTAサーバーにて以下のコマンドを実行し、設定します。

zmlocalconfig -e zmtrainsa_cleanup_host=TRUE

迷惑メールや迷惑ではないメールによく含まれる文字や単語、トークンを最初に迷惑メールフィルターに学習させて迅速にデータベースを構築したい場合、メッセージをmessage/rfc822添付としてマニュアル操作で迷惑メールボックスや非迷惑メールボックスに転送します。 zmtrainsa の実行で、転送されたメッセージを利用して、迷惑メールフィルターに学習させます。スコアの精度を上げるには、サンプルメッセージをたくさん登録するようにしてください。迷惑メールの判断には、最低約200通の迷惑メッセージと200通の非迷惑メッセージが必要とされています。

SpamAssassinのsa-updateツールはSpamAssassinの一部です。このツールでSA organizationのSpamAssassinルールを更新します。このツールは /opt/zimbra/common/bin にインストールされます。

迷惑メールの最終処理を設定する: 次の属性を利用しAmavisを設定することで、迷惑メールの最終処理を管理できます。

zimbraAmavisFinalSpamDestiny

この属性のデフォルトは D_DISCARD です (宛先へ配信せずに削除する処理です) 。

以下のコマンドで設定します。

zmprov mcf "zimbraAmavisFinalSpamDestiny" D_PASS
zmprov ms serverhostname.com D_PASS
Table 9. 設定可能な属性値
説明

D_PASS

宛先へ配信されます。受信者の迷惑メールフォルダに格納されることになります (ただし、迷惑メールフォルダを使用不可にしているサイトもあります) 。

D_BOUNCE

送信者へ送り返されます。この設定の場合backscatterを作成できるため("送信者" が実際にメールを送信した人物でない)、推奨しません。

D_REJECT

メールを拒否します。この設定はbackscatterの機会が縮小します。

  • 有効な送信者の場合、MTAは送信者にメール拒否について知らせます。

  • 無効な送信者の場合、関連MTAがメールを削除します (つまり、なりすましメール)。

D_DISCARD

メールは何ごともなく削除されます(配信されません)。

信頼できるネットワークを設定する: ZCSの設定では、ローカルネットワークのリレーのみ許可します。ただし、リレーメールを許された信頼できるネットワークを設定することが可能です。信頼できるMTAネットワークはグローバル設定として設定しますが、サーバー設定でも設定できます。サーバー設定はグローバル設定をオーバーライドします。

管理コンソールから信頼できるMTAネットワークをグローバル設定として設定する方法

管理コンソール:

ホーム > 設定 > グローバル設定 > MTA → ネットワーク

MTA Trusted Networks

サーバーベースで信頼できるMTAネットワークを設定する場合は、まず、グローバル設定として信頼できるMTAネットワークが設定済みであることを確認します。

管理コンソール:

ホーム > 設定 > サーバー → サーバー名 → MTA → ネットワーク

MTA Trusted Networks

複数のネットワークを記載する場合、カンマ空白 で区切ります。長い行が続く場合、下記例のように次の行を空白で開始します。

127.0.0.0/8, 168.100.189.0/24
127.0.0.0/8 168.100.189.0/24 10.0.0.0/8 [::1]/128 [fe80::%eth0]/64

Milter サーバーを有効にする: Milterサーバーを有効にして、配布リストに送信できるアドレスを制限することができます。また、Reply-ToX-Zimbra-DL を配布リストから送信するメッセージヘッダーに追加することができます。管理コンソールからグローバルまたは特定のサーバーに対して、設定することが可能です。

MTAが起動しているサーバーにのみMilterサーバーを有効化してください。

グローバルにMilterサーバーを有効にする場合、管理コンソールからMilterサーバーを有効にします。

管理コンソール:

Home > 設定 > グローバル設定 > MTA → Milter サーバー

MTA Milter Server

特定のMilterサーバーを有効にし、個々のサーバーにMilterのバインドアドレスを設定するには、管理コンソールを使用します。

管理コンソール:

Home > 設定 > サーバー → サーバー名 → MTA → Milter サーバー

MTA Milter Server
PostScreenを利用した迷惑メール対策

ZimbraのPostscreenは、サーバーのオーバーロードを防ぐためにZimbra Collaborationの迷惑メール対策の一環としてバージョン8.7より追加されています。意図的に、PostscreenをSMTPプロキシとはしていません。Postscreenの目的は、Postfix SMTPサーバー処理からスパムボットを遠ざけながら、正当なトラフィックのためにオーバーヘッドを最小化することです。シングルPostscreen処理では、複数のインバウンドSMTP接続を処理し、どのクライアントをPost-fix SMTPサーバー処理へ繋ぐかを決定します。スパムボットを追いやることで、Postscreenは正当な送信元のためにSMTPサーバー処理を開放でき、また、サーバーのオーバーロード状態が始まる兆候を遅らせることができます。

通常の配備では、PostscreenがTCPポート25でMXサービスを実施し、MUAクライアントがクライアント認証の必要なTCPポート587のサブミッションサービスからメールを送ります。他の方法として、Postscreenではない専用の “port 25” サーバーをセットアップすることも可能です。MXサービスを使わずにこの専用サーバーで送信サービスとクライアント認証を行ないます。

Postscreenは、エンドユーザークライアント(電子メールクライアント)のメールを受け取るSMTPポートで使用するべきではありません。

Zimbra Collaboration Postscreen は数々のテストを通った実績を持つ送信元暫定ホワイトリストを保有しています。送信元IPアドレスがホワイトリストに存在する場合、Postscreenは即座にその接続をPostfix SMTPサーバー処理へ渡します。こうすることで、正当なメールの場合のオーバーヘッドを最小化します。

Postscreenサービスを利用する通常のシナリオでは、ロード中のメールに、正当と思われるメールと潜在的に悪意のあるメールエンティティ(ボットやゾンビなど)が混在していることを想定するのが妥当です。この概念を次の図で表します。 望まないエンティティは赤色で、正当と思われるメールは緑色で示しています。

Postscreen

Postscreenは基本チェックを行い、明らかにボットやゾンビと分かる接続を拒否します。暫定ホワイトリストに掲載されていない接続の場合はそのメールをローカルの迷惑メール対策ソフトとウィルス対策ソフトに回して、受け入れるか拒否するかを決めさせます。悪意のない接続の場合はPostscreenセキュリティで受け入れた後にSMTPデーモンと直接会話させて、迷惑メール対策・ウィルス対策チェックによるメールスキャンを(通常どおり)行います。デフォルトでは、ボットもゾンビも全て拒否されます。

Postscreen処理のパラメーター設定にはZimbra CLI属性を使用します。ignore、enforce、dropを含む Postscreen属性 については次のガイドラインを利用してください。

  • ignore — この結果を無視します。他のテストを完了させることができます。このテストは後続のクライアント接続で繰り返されます。メールをブロックせずにテストし、統計を収集するのに有効なため、これがデフォルト設定です。

  • enforce — 他のテストを完了します。550 SMTPを返してメール配信を拒否し、hello/sender/recipient情報のログをとります。このテストは後続のクライアント接続で繰り返されます。

  • drop — 521 SMTPを返し、即座に接続が落とされます。このテストは後続のクライアント接続で繰り返されます。

Postscreen属性:

Postscreenのコマンドを使用するには zmprov mcf プロンプトへ遷移します(バージョン8.7以降)。 Postscreenの有効化 ではこうした属性の使用例を確認できます。

  • zimbraMtaPostscreenAccessList — デフォルト = permit_mynetworks

    Postconfのpostscreen_access_listというリモートSMTPクライアントIPアドレス分の恒久ホワイト/ブラックリストを設定します。リモートSMTPクライアントが接続するとすぐにPostscreen(8)はこのリストを検索します。カンマ(もしくは空白)で区切られたコマンドリスト(上位または下位のケース)またはルックアップテーブル(配列)を指定してください。この検索はコマンドが該当の送信元IPアドレスを見つけた時点で終了します。

  • zimbraMtaPostscreenBareNewlineAction — デフォルト = ignore

    リモートSMTPクライアントが “生の改行コード” 、つまり、前にCRをつけずにLFのみを送信した場合にPostscreen(8)がとるアクション。ignore、enforce、dropのいずれかになります。

  • zimbraMtaPostscreenBareNewlineEnable — デフォルト = no

    postscreen(8)サーバーでの “生の改行コード” のSMTPプロトコルテストを有効または無効にします。このテストは代償が大きいです。リモートSMTPクライアントはこのテストを通過した後、実際のPostfix SMTPサーバーと会話できるようになる前に接続を閉じる必要があるためです。

  • zimbraMtaPostscreenBareNewlineTTL — デフォルト = 30d

    “生の改行コード” のSMTPプロトコルテストの成功結果をpostscreen(8)が利用できる期間。この間、その送信元IPアドレスはこのテストの対象外となります。デフォルト設定は長くしてあります。リモートクライアントはこのテストを通過した後、実際のPostfix SMTPサーバーと会話できるようになる前に接続を閉じる必要があるためです。 0以外の時間を指定してください(整数の値+時間単位を特定する1文字)。
    時間単位:s(秒)、m(分)、h(時)、d(日)、w(週)。

  • zimbraMtaPostscreenBlacklistAction — デフォルト = ignore

    postscreen_access_list パラメーターを使用し、そのリモートSMTPが恒久ブラックリストに掲載されていると分かったときにPostscreen(8)がとるアクション。ignore、enforce、dropのいずれかになります。

  • zimbraMtaPostscreenCacheCleanupInterval — デフォルト = 12h

    postscreen(8)に許されているキャッシュクリーンアップ処理実行間隔。キャッシュクリーンアップはキャッシュデータベースに対するロードが増加するため、頻繁に実行するべきではありません。この機能を使用するには、キャッシュデータベースが delete(削除) and sequence(継続) 操作をサポートしている必要があります。キャッシュクリーンアップを無効にするには0時間を指定します。

    各キャシュクリーンアップの実行後、postscreen(8) デーモンは、保持・ドロップされたエントリ数をログに出力します。 postfixのリロード 後、あるいは postfixの停止 後、もしくは $max_idle 時間(アイドルタイム制限)内にリクエストがなかった場合に、デーモンは停止し、クリーンアップの実行は partial としてログに記録されます。
    時間単位:s(秒)、m(分)、h(時)、d(日)、w(週)。

  • zimbraMtaPostscreenCacheRetentionTime — デフォルト = 7d

    期限切れのエントリが暫定ホワイトリストから削除される前にpostscreen(8)がキャッシュできる期間。これにより、1時間前にキャッシュエントリから消えた送信元をその理由だけで NEW と記録することを防ぐことができます。また、かつて厳しいプロトコルテストを通過しながらも再訪していない送信元の情報でキャッシュがいっぱいになることを防げます。
    時間単位:s(秒)、m(分)、h(時)、d(日)、w(週)。

  • zimbraMtaPostscreenCommandCountLimit — デフォルト = 20

    postscreen(8)に搭載されているSMTPプロトコルエンジンに対し、SMTPセッションごとのコマンド総数上限を設定します。このSMTPエンジンはメール配信しようとする試みを全て一気に延期あるいは拒否するため、ジャンクコマンドとエラーコマンドに対する制限を他に設ける必要はありません。

  • zimbraMtaPostscreenDnsblAction — デフォルト = ignore

    リモートSMTPクライアントのcombined DNSBLスコアがしきい値以上の場合にPostscreen(8)がとるアクション(このスコアはパラメーター postscreen_dnsbl_sitespostscreen_dnsbl_threshold で定義されています)。ignore、enforce、dropのいずれかになります。

  • zimbraMtaPostscreenDnsblSites

    DNSのホワイト・ブラックリストのオプションリストで、要素にはドメイン、フィルター、重さがあります。リストが空でないときdnsblog(8)デーモンはリモートSMTPクライアントのIPアドレスを使用してこれらのドメインを問い合わせます。そして、postscreen(8)は各送信元のDNSBLスコアをエラー以外の応答で更新します。

    メールを拒否する場合、PostscreenはDNSBL domainnameを返します。DNSBLのドメインネームにある “パスワード” 情報を隠すには、 postscreen_dnsbl_reply_map 機能を使用してください。

    送信元のスコアが postscreen_dnsbl_threshold で特定されたしきい値以上の場合、postscreen(8)はそのリモートSMTPクライアントとの接続を切ることができます。

    カンマまたは空白で区切られた、 domain=filter*重さ のリストを指定してください。

    • =filter が指定されていない場合、postscreen(8)はエラーでないDNSBL応答を使用することになります。それ以外の場合、フィルターと一致するDNSBL応答のみ使用します。このフィルターは d.d.d.d 形式で、各dは数字もしくは [] で囲まれたパターンです。[] には “;” で仕切られた数値や、数値..数値の範囲が入っています。

    • 重さ が指定されていない場合、postscreen(8)はリモートSMTPクライアントのDNSBLスコアに1を加算します。それ以外の場合、重さは整数である必要があり、また、postscreen(8)はそのリモートSMTPクライアントのDNSBLスコアに指定された重さを加算します。ホワイトリストにしたい場合、マイナスの数値を指定してください

    • postscreen_dnsbl_sites エントリ1件についてDNSBL応答が複数あるとき、postscreen(8)が重さを適用するのは1度だけです。

    例:

    example.comを信頼度の高いブロックリストとして使用し、また、example.net とexample.orgの両方が合致する場合のみブロックする

    postscreen_dnsbl_threshold = 2
    postscreen_dnsbl_sites = example.com*2, example.net, example.org

    127.0.0.4を含むDNSBL応答だけをフィルターする

    postscreen_dnsbl_sites = example.com=127.0.0.4
  • zimbraMtaPostscreenDnsblThreshold — デフォルト = 1

    postscreen_dnsbl_sitesパラメーターで定義されたcombined DNSBLスコアに基づき、リモートSMTPクライアントのブロック下限値を全体に定義する値。

  • zimbraMtaPostscreenDnsblTTL — デフォルト = 1h

    DNSベースの評価テストを通過したことのある送信元IPアドレスの再テストが必要となるまでに、かつての成功結果をpostscreen(8)が利用できる期間。

    0以外の時間を指定してください(整数の値+時間単位を特定する1文字)。 

    時間単位:s(秒)、m(分)、h(時)、d(日)、w(週)。

  • zimbraMtaPostscreenDnsblWhitelistThreshold — デフォルト = 0

    リモートSMTPクライア ントが postscreen_dnsbl_sites パラメーターで定義されているcombined DNSBLスコアに基づいて "220 greeting" プロトコルテスト の "前後" のテストをスキップできるようにします。

    この機能を有効にするにはマイナス値を指定します。送信元が他のテストに失敗せずにpostscreen_dnsbl_whitelist_thresholdを通過すると、保留中あるいは無効のテスト全てに完了済みフラグがつけられ、postscreen_dnsbl_ttl と等しいTTLが設定されます。テストがすでに完了していて、そのTTLが postscreen_dnsbl_ttl より短ければ、その値でTTL が更新されます。

  • zimbraMtaPostscreenGreetAction — デフォルト = ignore

    postscreen_greet_wait パラメーターで指定された期間中、応答を待たずにリモートSMTPクライアントが会話を始めた場合にPostscreen(8)がとるアクション。ignore、enforce、dropのいずれかになります。

  • zimbraMtaPostscreenGreetTTL — デフォルト = 1d

    PREGREETテストの成功結果をpostscreen(8)が利用できる期間。この間、この送信元IPアドレスはテスト対象外となります。デフォルト設定は比較的短くしてあります。正当な送信元が実際のPostfix SMTPサーバーと即座に会話できるようにするためです。

    0以外の時間を指定してください(整数の値+時間単位を特定する1文字)。
    時間単位:s(秒)、m(分)、h(時)、d(日)、w(週)。

  • zimbraMtaPostscreenNonSmtpCommandAction — デフォルト = drop

    postscreen_forbidden_ commandsパラメーターで指定された期間中にリモートSMTPクライアントがSMTP以外のコマンドを送信した場合にPostscreen(8)がとるアクション。ignore、enforce、dropのいずれかになります。

  • zimbraMtaPostscreenNonSmtpCommandEnable — デフォルト = no

    postscreen(8)サーバーでの“non_smtp_command”のテストを有効または無効にします。クライアントはこのテストを通過した後、実際のPostfix SMTPサーバーと会話できるようになる前に接続を閉じる必要があるため、代償の大きいテストです。

  • zimbraMtaPostscreenNonSmtpCommandTTL — デフォルト = 30d

    “non_smtp_command” SMTPプロトコルテストの成功結果をpostscreen(8)が利用できる期間。この間、その送信元IPアドレスはこのテストの対象外となります。実際のPostfix SMTPサーバーと会話できるようになる前に接続を閉じる必要があるためデフォルト設定は長くしてあります

    0以外の時間を指定してください(整数の値+時間単位を特定する1文字)。
    時間単位:s(秒)、m(分)、h(時)、d(日)、w(週)。

  • zimbraMtaPostscreenPipeliningAction — デフォルト = enforce

    リモートSMTPクライアントがコマンドを1件送信しサーバー応答を待つ代わりに、複数のコマンドを送信してきた場合にpostscreen(8)がとるアクション。ignore、enforce、dropのいずれかになります。

  • zimbraMtaPostscreenPipeliningEnable — デフォルト = no

    postscreen(8)サーバーでの “pipelining” SMTPプロトコルテストを有効または無効にします。送信元はこのテストを通過した後、実際のPostfix SMTPサーバーと会話できるようになる前に接続を閉じる必要があるため、代償の大きいテストです。

  • zimbraMtaPostscreenPipeliningTTL — デフォルト = 30d

    “pipelining” SMTPプロトコルテストの成功結果をpostscreen(8)が利用できる期間。この間、その送信元IPアドレスはこのテストの対象外となります。送信元はこのテストを通過した後、実際のPostfix SMTPサーバーと会話できるようになる前に接続を閉じる必要があるため、デフォルト設定は長めにしてあります。

    0以外の時間を指定してください(整数の値+時間単位を特定する1文字)。
    時間単位:s(秒)、m(分)、h(時)、d(日)、w(週)。

  • zimbraMtaPostscreenWatchdogTimeout — デフォルト = 10s

    内蔵されているウォッチドッグタイマーによる停止前に、postscreen(8)処理がリモートSMTPクライアントのコマンドへの応答、あるいはキャッシュ処理の実行に許されている期間。安全のためのこのメカニズムを使用することで、Postfix内のバグあるいはシステムソフトによってpostscreen(8)が無反応となることを防止します。失敗の警告や不必要なキャッシュ破壊を避けるため、この制限時間を10秒以下に設定しないようにしてください。

    0以外の時間を指定してください(整数の値+時間単位を特定する1文字)。
    時間単位:s(秒)、m(分)、h(時)、d(日)、w(週)。

  • zimbraMtaPostscreenWhitelistInterfaces

    ローカルpostscreen(8)サーバーIPアドレスリスト。ホワイトリストに掲載されていないリモートSMTPクライアントは、ここからpostscreen(8)の暫定ホワイトリストステータスを取得できます。クライアントがPostfix SMTPサーバー処理に伝達できるようになるにはこのステータスが必要です。デフォルトでは、送信元はどのローカルpostscreen(8)サーバーIPアドレス上のpostscreen(8)ホワイトリストステータスでも取得することができます。

    postscreen(8)がプライマリMXアドレスとバックアップMXアドレスの両方に応答するような場合、クライアントがプライマリMXアドレスに接続した場合にのみ暫定ホワイトリストステータスを渡すように postscreen_whitelist_interfaces パラメーターを設定することも可能です。 クライアントがホワイトリストに掲載されると、そのクライアントはどのアドレスのPostfix STMPサーバーにも話しかけることができるようになります。このため、バックアップMXアドレスにしか接続しないクライアントが、ホワイトリストに載ることはありませんし、Postfix SMTPサーバー処理と会話できることもありません。

    ネットワークアドレスリストやネットワーク/ネットマスクパターンリストをカンマ区切りや空白区切りで指定します。ネットマスクは、ホストアドレスのネットワークパート部のビット番号を特定します。次行を空白から開始することで、長い行を継続することができます。

    /file/name あるいは type:table のパターンの特定も可能です。 /file/name というパターンを内容に替えます。 type:table のルックアップ(配列)テーブルはテーブルエントリがルックアップ文字列に一致する場合に、一致します(ルックアップ結果は無視されします)。

    このリストでは左から右にマッチング検索を行い、最初に一致したところで検索が停止します。 !のパターン を指定して、アドレスやネットワークブロックをそのリストから除外します。

    IPv6 アドレスの情報を postscreen_whitelist_interfaces 値の [] 内および /file/name にて特定したファイル内に指定する必要があります。IP version 6 アドレスには、文字 “:” が含まれているため、こうしない限り type:table のパターンと混在します。

    例:

    /etc/postfix/main.cf:
    
    # バックアップIPアドレスへホワイトリスト接続をしないでください。
    postscreen_whitelist_interfaces = !168.100.189.8, static:all
  • zimbraMtaPostscreenDnsblMinTTL — デフォルト = 60s

    DNSベースの評価テストを通過したことのある送信元IPアドレスの再テストが必要となるまでに、かつての成功結果をpostscreen(8)が利用できる期間の下限。DNSの応答が更に大きいTTL値を特定していて、その値がpostscreen_dnsbl_max_ttlの値よりも大きくない限り、使用されることになります。

    0以外の時間を指定してください(整数の値+時間単位を特定する1文字)。
    時間単位:s(秒)、m(分)、h(時)、d(日)、w(週)。

  • zimbraMtaPostscreenDnsblMaxTTL — デフォルト = postscreen dnsbl ttl

    DNSベースの評価テストを通過したことのある送信元IPアドレスの再テストが必要となるまでに、かつての成功結果をpostscreen(8)が利用できる期間の上限。DNSの応答が更に短いTTL値を特定していて、その値がpostscreen_dnsbl_min_ttlの値よりも小さくない限り、使用されることになります。

    0以外の時間を指定してください(整数の値+時間単位を特定する1文字)。
    時間単位:s(秒)、m(分)、h(時)、d(日)、w(週)。

    注意点として、このデフォルト設定は、3.1よりも前のPostscreenバージョンにも適用されます。

Postscreenの有効化:

このセクションでは、中から上レベルでPostscreen保護を行なう場合に当てはまるグローバル設定の例を記載します。

Example 4. Postscreenのグローバル設定
zmprov mcf zimbraMtaPostscreenAccessList permit_mynetworks
zmprov mcf zimbraMtaPostscreenBareNewlineAction ignore
zmprov mcf zimbraMtaPostscreenBareNewlineEnable no
zmprov mcf zimbraMtaPostscreenBareNewlineTTL 30d
zmprov mcf zimbraMtaPostscreenBlacklistAction ignore
zmprov mcf zimbraMtaPostscreenCacheCleanupInterval 12h
zmprov mcf zimbraMtaPostscreenCacheRetentionTime 7d
zmprov mcf zimbraMtaPostscreenCommandCountLimit 20
zmprov mcf zimbraMtaPostscreenDnsblAction enforce
zmprov mcf \
  zimbraMtaPostscreenDnsblSites 'b.barracudacentral.org=127.0.0.2_7' \
  zimbraMtaPostscreenDnsblSites 'dnsbl.inps.de=127.0.0.2*7' \
  zimbraMtaPostscreenDnsblSites 'zen.spamhaus.org=127.0.0.[10;11]*8' \
  zimbraMtaPostscreenDnsblSites 'zen.spamhaus.org=127.0.0.[4..7]*6' \
  zimbraMtaPostscreenDnsblSites 'zen.spamhaus.org=127.0.0.3*4' \
  zimbraMtaPostscreenDnsblSites 'zen.spamhaus.org=127.0.0.2*3' \
  zimbraMtaPostscreenDnsblSites 'list.dnswl.org=127.0.[0..255].0*-2' \
  zimbraMtaPostscreenDnsblSites 'list.dnswl.org=127.0.[0..255].1*-3' \
  zimbraMtaPostscreenDnsblSites 'list.dnswl.org=127.0.[0..255].2*-4' \
  zimbraMtaPostscreenDnsblSites 'list.dnswl.org=127.0.[0..255].3*-5' \
  zimbraMtaPostscreenDnsblSites 'bl.mailspike.net=127.0.0.2*5' \
  zimbraMtaPostscreenDnsblSites 'bl.mailspike.net=127.0.0.[10;11;12]*4' \
  zimbraMtaPostscreenDnsblSites 'wl.mailspike.net=127.0.0.[18;19;20]*-2' \
  zimbraMtaPostscreenDnsblSites 'dnsbl.sorbs.net=127.0.0.10*8' \
  zimbraMtaPostscreenDnsblSites 'dnsbl.sorbs.net=127.0.0.5*6' \
  zimbraMtaPostscreenDnsblSites 'dnsbl.sorbs.net=127.0.0.7*3' \
  zimbraMtaPostscreenDnsblSites 'dnsbl.sorbs.net=127.0.0.8*2' \
  zimbraMtaPostscreenDnsblSites 'dnsbl.sorbs.net=127.0.0.6*2' \
  zimbraMtaPostscreenDnsblSites 'dnsbl.sorbs.net=127.0.0.9*2'
zmprov mcf zimbraMtaPostscreenDnsblTTL 5m
zmprov mcf zimbraMtaPostscreenDnsblThreshold 8
zmprov mcf zimbraMtaPostscreenDnsblTimeout 10s
zmprov mcf zimbraMtaPostscreenDnsblWhitelistThreshold 0
zmprov mcf zimbraMtaPostscreenGreetAction enforce
zmprov mcf zimbraMtaPostscreenGreetTTL 1d
zmprov mcf zimbraMtaPostscreenNonSmtpCommandAction drop
zmprov mcf zimbraMtaPostscreenNonSmtpCommandEnable no
zmprov mcf zimbraMtaPostscreenNonSmtpCommandTTL 30d
zmprov mcf zimbraMtaPostscreenPipeliningAction enforce
zmprov mcf zimbraMtaPostscreenPipeliningEnable no
zmprov mcf zimbraMtaPostscreenPipeliningTTL 30d
zmprov mcf zimbraMtaPostscreenWatchdogTimeout 10s
zmprov mcf zimbraMtaPostscreenWhitelistInterfaces static:all

Postscreenのテスト:

テストでは、何のアクションもとらずに結果を表示するPostscreenを使用します。テストシナリオでは、何のアクションもとらずメール接続のログをとるようにPostscreenに指示します。結果が問題なければ、必要に応じてメールを実行またはドロップを行なうための値をPostscreenに設定します。

  1. DNSベースのブラックホールリスト(DNSBL)を設定します。

  2. PostscreenをIgnore(無視)に設定します。

テストセッション中にPostscreenから550エラーの結果が返ってきた場合の実例

Mar 1 02:03:26 edge01 postfix/postscreen[23154]: DNSBL rank 28 for [112.90.37.251]:20438

Mar 1 02:03:26 edge01 postfix/postscreen[23154]: CONNECT from [10.210.0.161]:58010 to [10.210.0.174]:25

Mar 1 02:03:26 edge01 postfix/postscreen[23154]: WHITELISTED [10.210.0.161]:58010

Mar 1 02:03:27 edge01 postfix/postscreen[23154]: NOQUEUE: reject: RCPT from [112.90.37.251]:20438: 550 5.7.1 Service unavailable; client [112.90.37.251] blocked using zen.spamhaus.org; from=<hfxdgdsggfvfg@gmail.com>, to=<support@zimbra.com>, proto=ESMTP, helo=<gmail.com>

Mar 1 02:03:27 edge01 postfix/postscreen[23154]: DISCONNECT [112.90.37.251]:20438

メールの送受信について

Zimbra MTAは受信メッセージと送信メッセージを配信します。送信メッセージの場合、Zimbra MTAが受信者のあて先を決定します。あて先がローカルサーバーの場合、Zimbraサーバーへメッセージを配信します。あて先サーバーがリモートメールサーバーの場合、Zimbra MTAは伝達方式を確立し、リモートホストへメッセージを転送します。受信するメッセージの場合、MTAはリモートのメールサーバーから接続のリクエストを許可してローカルユーザー宛てのメッセージを受け取る必要があります。

MTAのメール送受信には、AレコードとMXレコードをDNS内に設定する必要があります。メール送信するにはMTAはDNSを利用して、ホスト名やメールのルート情報を解読します。メール受信するには、メッセージを正常にメールサーバーへ転送するためにMXレコードを正しく設定しておく必要があります。

DNSを有効にしない場合は、リレーホストを設定する必要があります。

メッセージのキュー

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

Message Queues

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

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

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

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

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

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

Zimbra プロキシサーバー

Zimbraプロキシは、IMAP/POP3やHTTP クライアントリクエストのバックエンドサーバーへのリバースプロキシに使用されるPOP3/IMAP/HTTP プロキシとして設定することのできる、高性能なプロキシサーバーです。

Zimbra Collaborationのインストール中にZimbraのプロキシパッケージのインストール・設定をします。このパッケージはメールボックスサーバー、MTAサーバー、または独立したサーバーにインストールできます。Zimbraプロキシのパッケージがインストールされると、プロキシ機能が有効になります。通常、特に編集は必要ありません。

Zimbraプロキシを使用する利点

以下の項目はZimbraプロキシを使用するメリットです。

  • Zimbraプロキシによるメールボックスサーバーへのアクセスの中央化

  • ロードバランス

  • セキュリティ

  • 認証

  • SSLの停止化

  • キャッシュ

  • ロギングと監視の中央化

  • URLの再発行

  • サーバー名による制御の徹底 (任意)

詳細について、Wikiページ Zimbra_Proxy_Guide を参照してください。

プロキシのコンポーネント

Zimbraプロキシの仕組みで素早く安定したスケーラブルなHTTP/POP/IMAPプロキシを提供します。Zimbraプロキシのコンポーネントは以下となります。

コンポーネント 説明

Nginx

すべてのHTTP/POP/IMAPリクエストを処理する、高パフォーマンスのHTTP/IMAP/POP3プロキシサーバーです。

Memcached

配布されるメモリオブジェクトを高パフォーマンスでキャッシュするシステムです。パフォーマンスを向上させるため、この中にルート情報をキャッシュします。

Zimbra Proxyルート検索ハンドラ

ZCS メールボックスサーバーにあるサーブレットです。ユーザーアカウントのルート情報のクエリを処理します。ルート情報には、ユーザーアカウントが入っているサーバーとポート番号があります。

プロキシ構成と運用の流れ

ここでは、Zimbraプロキシの構成とフローを説明します。

  1. エンドクライアントがHTTP/HTTPS/POP/IMAPのポートを使用してZimbraプロキシへ接続します。

  2. Zimbra Collaboration プロキシが外からの接続を受信すると、Nginxコンポーネントがルート検索ハンドラコンポーネントへHTTPリクエストを送信します。

    Proxy Architecture

  3. Zimbra Collaboration プロキシのルート検索ハンドラがアクセスされているアカウントのルート情報を確認し、Nginxへ返します。

  4. Memcachedコンポーネントは、設定された期間内にこのルート情報を保存します (デフォルトは1時間) 。Nginxは、このデフォルトの保存期間中はルート検索ハンドラへ問い合わせせずに、このルート情報を利用します。

  5. Nginxはルート情報を使用して、Zimbra Collaborationのメールボックスに接続します。

  6. Zimbra CollaborationプロキシはZimbra Collaborationメールボックスに接続してウェブ/メールのプロキシセッションを開始します。エンドクライアントはZimbra Collaborationメールボックスへ直接接続しているかのように動作します。

Zimbraプロキシ設定の変更

Zimbraプロキシが設定されていると、Zimbraプロキシの設定は必要に応じてZimbra CollaborationのLDAP設定やLocalconfigから代理のキーワードを使用します。

Zimbraプロキシの設定完了後に変更が必要となった場合、ZimbraのLDAP属性やLocalconfig属性を編集します。その後、変更を反映したZimbraのプロキシ設定を生成するためにzmconfigdを実行します。Zimbraプロキシの設定ファイルは /opt/zimbra/conf/nginx.conf にあります。このNginx.confファイルには基本設定ファイル、memcache設定ファイル、メール設定ファイル、ウェブ設定ファイルが含まれています。

Zimbraプロキシに対するよくある変更は、IMAP/POP設定の当初デフォルト設定からの変更です。

  • 当初デフォルト設定からのHTTP リバースプロキシ設定変更。

  • KerberosのGSSAPI認証。この場合、Zimbraプロキシのパスワードを含む、KerberosのKeytabファイルのありかをマニュアル操作で指定します。

Zimbra プロキシ

Zimbraのプロキシにより、エンドユーザーはMicrosoft Outlook、Mozilla Thunderbirdなどのクライアントや他のPOP/IMAPエンドクライアント製品を使用して、Zimbra Collaborationアカウントにアクセスすることができます。エンドユーザーはPOP3、IMAP、POP3S (セキュアPOP3) 、IMAPS (セキュアIMAP) を使用して接続します。

プロキシによって例えば、ユーザーはimap.example.comをユーザーのIMAPサーバーとして入力できます。imap.example.comで起動するこのプロキシがユーザーのIMAPトラフィックを分析し、ユーザーのメールボックスのあるバックエンドのメールボックスサーバーを探し当ててユーザーのIMAPクライアントからの接続を正しいメールボックスサーバーへと導きます。

POPとIMAPのZimbra プロキシポート

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

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

Table 10. プロキシポート
Zimbraプロキシポート (ZCS外部) ポート

HTTP

80

HTTPS

443

POP3

110

POP3S (セキュアPOP3)

995

IMAP

143

IMAPS (セキュアIMAP)

993

Zimbraメールボックスポート( ZCS内部)

ポート

ルート検索ハンドラ

7072

HTTP バックエンド (プロキシが設定されている場合)

8080

HTTPSバックエンド (プロキシが設定されている場合)

8443

POP3バックエンド (プロキシが設定されている場合)

7110

POP3Sバックエンド (プロキシが設定されている場合)

7995

IMAPバックエンド (プロキシが設定されている場合)

7143

IMAPSバックエンド (プロキシが設定されている場合)

7993

サーバー名による制御の徹底

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

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

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

  • TRUE - サーバー名による制御は有効

  • FALSE - サーバー名による制御は無効

zmprov mcf zimbraReverseProxyStrictServerNameEnabled TRUE

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

zmprov md example.com zimbraVirtualHostName mail.example.com zimbraVirtualIPAddress 1.2.3.4
ドメインごとに必要なバーチャルIPアドレスは1つだけですが1つ以上でも問題ありません。

HTTPプロキシのインストール後にIMAPとPOPプロキシを設定する方法

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

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

リモートホストに対し実行するには、zmproxyconfig -r コマンドを実行します。 これにはそのサーバーがLDAPマスター内で適切に設定されている必要があります。
独立プロキシノードのIMAP/POPプロキシを設定する

独立したプロキシサーバーを使用している環境の場合、本項の記述を参照してください。

  1. プロキシを使用する各ZimbraメールボックスサーバーでIMAP/POPプロキシを有効化します。

    /opt/zimbra/libexec/zmproxyconfig -e -m -H mailbox.node.service.hostname

    これにより以下が設定されます。

    ポート属性 設定

    zimbraImapBindPort

    7143

    zimbraImapProxyBindPort

    143

    zimbraImapSSLBindPort

    7993

    zimbraImapSSLProxyBindPort

    993

    zimbraPop3BindPort

    7110

    zimbraPop3ProxyBindPort

    110

    zimbraPop3SSLBindPort

    7995

    zimbraPop3SSLProxyBindPort

    995

    zimbralmapCleartextLoginEnabled

    TRUE

    zimbraReverseProxyLookupTarget

    TRUE

    zimbraPop3CleartextLoginEnabled

    TRUE

  2. プロキシとメールボックスのサーバーでサービスを再起動します。

    zmcontrol restart

プロキシノードを設定する

プロキシサービスがインストールされている各プロキシノードで、ウェブ用にプロキシを有効化します。

/opt/zimbra/libexec/zmproxyconfig -e -m -H proxy.node.service.hostname

これにより以下が設定されます。

ポート属性 設定

zimbraImapBindPort

7143

zimbraImapProxyBindPort

143

zimbraImapSSLBindPort

7993

zimbraImapSSLProxyBindPort

993

zimbraPop3BindPort

7110

zimbraPop3ProxyBindPort

110

zimbraPop3SSLBindPort

7995

zimbraPop3SSLProxyBindPort

995

zimbraReverseProxyMailEnabled

TRUE

シングルノードを設定する

ZimbraプロキシがZimbra Collaborationと同一サーバーにインストールされている環境の場合、本項の記述を参照してください。

  1. ウェブ用にプロキシを有効化します。

    /opt/zimbra/libexec/zmproxyconfig -e -m -H mailbox.node.service.hostname

    これにより以下が設定されます。

    ポート属性 設定

    zimbraImapBindPort

    7143

    zimbraImapProxyBindPort

    143

    zimbraImapSSLBindPort

    7993

    zimbraImapSSLProxyBindPort

    993

    zimbraPop3BindPort

    7110

    zimbraPop3ProxyBindPort

    110

    zimbraPop3SSLBindPort

    7995

    zimbraPop3SSLProxyBindPort

    995

    zimbraImapCleartextLoginEnabled

    TRUE

    zimbraReverseProxyLookupTarget

    TRUE

    zimbraPop3CleartextLoginEnabled

    TRUE

    zimbraReverseProxyMailEnabled

    TRUE

  2. プロキシとメールボックスのサーバーでサービスを再起動します。

    zmcontrol restart

Zimbra HTTPプロキシを設定する

Zimbraプロキシは、HTTPリクエストのバックエンドサーバーへのリバースプロキシを行なうことが可能です。

例えば、ユーザーはウェブブラウザから https://mail.example.com のプロキシサーバーへ接続します。mbs1.example.comにメールボックスがあるユーザーからの接続は、mail.example.com上で起動しているプロキシによってmbs1.example.comに渡されます。プロキシはRESTやCalDAVのクライアント、OutlookのZimbraコネクター、およびZimbraの NG モバイル同期のデバイスをサポートしています。

HTTPリバースプロキシは下記のとおり、リクエストをルートします。

  • リクエスト中のURLからユーザー名を判別できる場合、そのリクエストは、URLから判明したユーザーのバックエンドメールボックスサーバーへルートされます。このメカニズムにより、REST、CalDAV、Zimbraモバイルシンクがサポートされています。

  • リクエストに認証トークンのCookie(ZM_AUTH_TOKEN)が含まれている場合、そのリクエストは、認証されたユーザーのバックエンドメールボックスサーバーへルートされます。

  • 上記の方法が失敗した場合、IPハッシュの方法が使用されます。これにより、リクエストを処理、あるいは必要な内部のプロキシにてリクエストを処理できるため、バックエンドメールボックスサーバー中でそのリクエストはロードバランスされます。

HTTPプロキシを設定する方法

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

リモートホストに対し実行するには、/opt/zimbra/libexec/zmproxyconfig -r コマンドを実行します。 ただし、これにはそのサーバーがLDAPマスター内で適切に設定されている必要があります。
HTTPプロキシを独立したプロキシノードとして設定する

独立したプロキシサーバーを使用している環境の場合、本項の記述を参照してください。

  1. プロキシを使用する各ZimbraメールボックスサーバーでIMAP/POPプロキシを有効化します。

    /opt/zimbra/libexec/zmproxyconfig -e -w -H mailbox.node.service.hostname

    これにより以下が設定されます。

    属性 設定

    zimbraMailReferMode

    reverse-proxied

    zimbraMailPort

    8080 (ポートの衝突回避のため)

    zimbraMailSSLPort

    8443 (ポートの衝突回避のため)

    zimbraReverseProxyLookupTarget

    TRUE

    zimbraMailMode

    HTTP

  2. プロキシとメールボックスのサーバーでサービスを再起動します。

    zmcontrol restart
  3. 各ドメインについて、REST URL、メール、ブリーフケースのフォルダに使用する公開サービスホスト名を設定します。

    zmprov modifyDomain <domain.com> zimbraPublicServiceHostname <hostname.domain.com>

プロキシノードを設定する

プロキシサービスがインストールされている各プロキシノードで、ウェブ用にプロキシを有効化します。

/opt/zimbra/libexec/zmproxyconfig -e -w -H proxy.node.service.hostname

これにより以下が設定されます。

属性 設定

zimbraMailReferMode

reverse-proxied プロキシサーバーのメールモードを設定する場合、コマンドに-xのオプションを追加し、次の中から希望のモードを指定します: http, https, both, redirect, mixed

zimbraMailProxyPort

80 (ポートの衝突回避のため)

zimbraMailSSLProxyPort

443 (ポートの衝突回避のため)

zimbraReverseProxyHttpEnabled

TRUE (ウェブプロキシが有効であることを示す)

zimbraReverseProxyMailMode

HTTP (デフォルト)

プロキシサーバーのメールモードを設定する場合、コマンドに -x のオプションを追加し、次の中から希望のモードを指定します: http, https, both, redirect, mixed

HTTPプロキシのシングルノードを設定する

ZimbraプロキシがZCS と同一サーバーにインストールされている環境の場合、本項の記述を参照してください。

  1. プロキシする各Zimbraメールボックスサーバーにウェブのプロキシを有効化します。

    /opt/zimbra/libexec/zmproxyconfig -e -w -H mailbox.node.service.hostname

    これにより以下が設定されます。

    属性 設定

    zimbraMailReferMode

    reverse-proxied

    zimbraMailPort

    8080 (ポートの衝突回避のため)

    zimbraMailSSLPort

    8443 (ポートの衝突回避のため)

    zimbraReverseProxyLookupTarget

    TRUE

    zimbraMailMode

    HTTP (唯一サポートされているモード)

    zimbraMailProxyPort

    80 (ポートの衝突回避のため)

    zimbraMailSSLProxyPort

    443 (ポートの衝突回避のため)

    zimbraReverseProxyHttpEnabled

    TRUE (ウェブプロキシが有効であることを示す)

    zimbraReverseProxyMailMode

    HTTP (default)

    プロキシサーバーのメールモードを設定する場合、コマンドに -x のオプションを追加し、次の中から希望のモードを指定します: http, https, both, redirect, mixed

  2. プロキシとメールボックスのサーバーでサービスを再起動します。

    zmcontrol restart

    各ドメインについて、REST URL、メール、ブリーフケースのフォルダに使用する公開サービスホスト名を設定します。

    zmprov modifyDomain <domain.com> zimbraPublicServiceHostname <hostname.domain.com>

プロキシがアップストリーム接続にクリアテキストを使用する設定

プロキシがアップストリーム接続にクリアテキストを使用するように設定する場合、 zimbraReverseProxySSLToUpstreamEnabled にFALSEを設定します。

この属性のデフォルトはTRUEです。初期インストールの状態、アップストリームのコミュニケーションはSSL配信がデフォルトです。

REST URL の生成

REST URL用に以下の属性のホスト名、サービスプロトコル、サービスポートをグローバルレベルあるいはドメインレベルで設定します。

  • zimbraPublicServiceHostname

  • zimbraPublicServiceProtocol

  • zimbraPublicServicePort

REST URLを生成する場合

  • domain.zimbraPublicServiceHostname が設定されている場合、 zimbraPublicServiceProtocol + zimbraPublicServiceHostname + zimbraPublicServicePort を使用します。

  • 上記以外の場合はサーバー (アカウントのホームサーバー) の属性にフォールバックします。

    • プロトコルは server.zimbraMailMode より計算されます。

    • ホスト名は server.zimbraServiceHostname です。

  • ポートはプロトコルより計算されます。

zimbraMailReferMode について - 以前のバージョンでは、ユーザーがログインしたサーバー上にユーザーのメールボックスが存在していなかった場合、 zimbra_auth_always_send_refer というlocalconfig変数がバックエンドサーバーのアクションを指定しました。ユーザーが間違ったバックエンドホストへログインしている場合はデフォルト値であるFALSEでによりユーザーをリダイレクトしました。

マルチサーバーの ZCS環境で、分かりやすいランディングページの作成のためにロードバランスされた名称が必要だったときは、ユーザーを常にリダイレクトする必要があったはずです。この場合は、 zimbra_auth_always_send_refer をTRUEに設定していました。

現在は、完全なリバースプロキシを使用しているため、ユーザーをリダイレクトする必要がありません。Nginxのリバースプロキシにて、localconfig変数 zimbraMailReferMode を使用しています。

プロキシの信頼済みIPアドレスを設定する

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

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

zmprov mcf +zimbraMailTrustedIP {nginx-1のIP } +zimbraMailTrustedIP {nginx-2のIP }

localconfigにX-Forwarded-Forが正しく追加されたことを確認するには、以下のコマンドを実行します。

zmlocalconfig | grep -i http

正常に追加されている場合、次のように表示されます。

zimbra_http originating_ip_header = X-Forwarded-For

Kerberos認証用にZimbraプロキシを設定する

Kerberos5認証機能を利用中の環境で、IMAPとPOPプロキシ向けに設定したい場合、本項の記述を参照してください。

Kerberos5認証機能が正しく設定されていることを確認してください。詳細はZimbra LDAP サービスを参照してください。
  1. 各プロキシノードで、サーバー属性zimbraReverseProxyDefaultRealにその該当プロキシサーバーのrealm名を設定します。例:

    zmprov ms [DNS name.isp.net] zimbraReverseProxyDefaultRealm [ISP.NET]
  2. メールクライアントが接続するプロキシIPアドレスごとに、メールサーバーのGSSAPI認証用設定が必要です。各プロキシIPアドレスの各プロキシノードで以下を実行します。

    zmprov mcf +zimbraReverseProxyAdminIPAddress [IP address]
  3. 各プロキシサーバーで以下を実行します。

    zmprov ms [proxyexample.net] zimbraReverseProxyImapSaslGssapiEnabled TRUE
    
    zmprov ms proxyl.isp.net zimbraReverseProxyPop3SaslGssapiEnabled TRUE
  4. プロキシサーバーを再起動します。

    zmproxyctl restart

Zimbra管理コンソール

Zimbraの管理コンソールは、Zimbraサーバーとユーザーアカウントの一括管理を可能とするブラウザベースのユーザーインターフェースです。

管理者のアカウントについて

管理コンソールにログインすると、許可されているタスクがナビゲーションペインに一覧表示されます。許可されているタスクは、管理担当者の権限に基づいています。

Zimbra Collaborationを管理する管理者アカウントは2種類あります。

  • システム管理者(グローバル管理者) サーバー、グローバル設定、ドメイン、アカウントの管理に必要な全ての権限を有し、他の管理者のアカウントを作成することもできます。Zimbraインストール時、自動でシステム管理者アカウントが1つ作成されます。追加でシステム管理者アカウントを作成することも可能です。管理者のタスクは、管理コンソールまたはコマンドラインから実行できます。

  • 委任された管理者 管理コンソールから行なう様々な管理タスクの実施に必要な権限を、システム管理者からカスタマイズで付与される管理担当者です。詳細は 管理権限の委任を参照してください。

管理コンソールへログインする

  1. 通常の環境で管理コンソールを起動するには、下記のURLパターンを利用します。

    パラメーター 説明

    server.domain.com

    Zimbraサーバー名 または IPアドレス

    7071

    デフォルトHTTPリッスンポート

  2. ログイン画面にて、admin@domain.com 形式での完全な管理者アドレスと Zimbra Collaborationのサーバーインストール中に設定したパスワードを入力します。

    管理コンソール

管理者のパスワードを変更する

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

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

管理コンソール:

ホーム > 管理 > アカウント

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

Change Password
zmprov sp adminname@domain.com password

ログインページとログアウトページをカスタマイズする

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

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

グローバル設定:

zmprov mcf zimbraAdminConsoleLoginURL <https://example.com>

ドメイン設定:

zmprov md <domain> zimbraAdminConsoleLoginURL <https://example.com>

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

グローバル設定:

zmprov mcf zimbraAdminConsoleLogoutURL <https://example.com>

ドメイン設定:

zmprov md <domain> zimbraAdminConsoleLogoutURL <https://example.com>

タスクを管理する

ZCSタスクのほとんど、例えばアカウント作成、提供サービス作成、サーバーステータス監視、ドメイン管理、バックアップスケジューリング、セッション管理などは、管理コンソールから管理できます。

その他の設定や保守タスク、例えば、サービスの開始や停止、ローカルサーバー設定の管理などの場合、管理コンソールからは実施できないため、コマンドラインを利用する必要があります。

管理コンソールから、特定の機能に紐づく属性を表示する必要がある場合、現在表示されている設定ページのテキストラベルをクリックして、ポップアップにその情報を表示させることができます。こうしたポップアップには、下記の様にガイドテキストも表示されます。

管理コンソールでの属性表示

属性ポップアップの表示のため、項目のラベルをクリック

Viewing Attributes

表示中の属性ポップアップにて項目についてのガイドを表示するため、More をクリック

Viewing Attributes

UIの案内

Zimbra Collaboration の管理コンソールは、設定や監視ツール、ログイン権限に基づいた表示が素早く案内できるように構成されています。また、様々な ヘルプ やオンスクリーンガイドに簡単にアクセスすることも可能です。

管理コンソールにログインすると表示される ホーム にはステータス情報と本書で説明したオプションが表示されます。オプションを選択して、その設定に遷移することも可能です。

管理コンソール
  1. 前のページあるいは次のページへ遷移

  2. 現在の位置/パス

  3. 検索

  4. 検索のリフレッシュ

  5. 現在のユーザーとログアウトオプション

  6. ヘルプ

  7. ギアアイコン

  8. ステータスペイン

  9. 表示ペイン

  10. ナビゲーションペイン

ナビゲーションペイン内と表示ペイン内の表示およびオプションは、選択された内容に沿って更新されます。他のUI部分?? 矢印ボタン、検索項目、画面リフレッシュ、現在の位置/パス、現在のログイン、ヘルプ?? は、常に表示されています。

ギアアイコン ギアアイコン を特定の画面に表示させて、画面上の機能に紐づいている機能に即座にアクセスできるようにしています。ギアアイコンについての詳細はギアアイコンを使うを参照してください。

ホームナビゲーションペイン

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

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

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

  • 前ページあるいは次ページへの遷移には、右矢印または左矢印をクリック。

  • 特定のUIへの遷移には、ホームのドロップダウンからオプションを1つ選択。

  • 特定のオプションへの直接遷移には、ナビゲーションペインにある階層をクリック。

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

ホームのUI

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

Home UI
  1. 前ページまたは次ページへ遷移

  2. 検索

  3. 検索のリフレッシュ

  4. 現在のユーザーとログアウトオプション

  5. ヘルプ

  6. システムステータス

  7. ステータスペイン

  8. クイックスタート

  9. ナビゲーションペイン

Table 11. ホームのUI
項目 説明

要約

現在実行中かつ表示中の Zimbra Collaboration のバージョンと、このセッションに紐付き、検出されているサーバー数、アカウント、ドメイン、提供サービス(COS)を表示。

メンテナンス

直近のソフトウェアバックアップを表示。

ランタイム

サービス、アクティブなセッション、キュー長を表示。

1 開始

 {product-name}
処理の起動に欠かせないステップを表示。このUIの機能へのクイックリンクもあります。
  1. ライセンスのインストール

  2. バックアップの設定

  3. 証明書をインストール

  4. デフォルトの提供サービスを設定

2 ドメインを設定

Collaboratorの管理対象のドメインを確立するために必要なステップを表示。各ステップに対象UI機能へのクイックリンクがあります。

  1. ドメインを作成

  2. GALを設定

  3. 認証を設定

3 アカウントの追加

Collaboratorでの管理用アカウントを作成するステップを表示。各ステップに対象UI機能へのクイックリンクがあります。

  1. アカウントを追加

  2. アカウントを管理

  3. 移行と共存

監視のUI

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

監視のUI
  1. 前ページまたは次ページへ遷移

  2. 検索

  3. 検索のリフレッシュ

  4. 現在のユーザーとログアウトオプション

  5. ヘルプ

  6. ステータスペイン

  7. ナビゲーションペイン

監視ナビゲーションペインと監視ページ

監視 のページにあるオプションを使用して、様々な方法 ― ダイナミックチャートや表 ― で、個々あるいはシステム全体で見たサーバーやサービスを表示します。

ダイナミックチャートの表示には、Adobe Flash Playerがアクティブである必要があります。
Table 12. 監視のUI
オプション 説明

サーバーステータス

サーバーステータス Collaboratorが監視した、サーバーごとのサービスと時間

高度な統計

高度な統計向けのシステム全体の情報ページ。ページにある次の選択項目のパラメーターを使用すると、新しいチャートをセットアップできます: サーバー、グループ、開始、終了、カウンタ

高度な統計のページには、下記のオプションもあります。

  • グラフ設定を非表示

  • グラフを更新

  • グラフを削除

メッセージ数

メッセージ数向けのシステム全体の情報ページ。 過去48時間、30日、60日、365日の件数を図に表します。この情報は、SMTPまたはLMTPを使用した、メッセージ受信者数に基づいています。各図の下に件数ごとの時間間隔が提示されます。

メッセージボリューム

メッセージボリューム向けのシステム全体の情報ページ。SMTPまたはLMTPを使用した、メッセージ受信者数およびそれに紐づくメッセージボリュームを表す図が表示されます。過去48時間、30日、60日、365日の件数です。各図の下に件数ごとの時間間隔が提示されます。

迷惑メール対策/ウィルス対策

迷惑メール対策/ウィルス対策向けのシステム全体の情報ページ。

アクティビティ

過去48時間、30日、60日、365日に渡り、AS/ACシステムによって処理された固有メッセージの数を示します。各図の下に件数ごとの時間間隔が提示されます。

サーバー統計

選択したサービスホストの統計にアクセスします。ホストの情報は下記のとおり閲覧できます。

  • サービスホスト名の上にカーソルをあてて停止すると、ライセンス情報のポップアップが表示されます。

    License

  • サービスホスト名を右クリックしてポップアップにある 表示 ボタンを選択すると、統計ページに遷移します。サービスホスト名のダブルクリックでも統計ページにアクセスできます。

    View

サーバー統計ナビゲーションペインには、選択したサーバーの下記情報を表示させるオプションもあります。: ディスク、セッション、メールボックスの割り当て容量、メッセージ数、メッセージボリューム、迷惑メール対策/ウィルス対策アクティビティ

メールキュー

各ページタブから検知されたメールキューの遅延、受信、アクティブ、保持、破損に関する統計件数が表示されます。各タブページには要約フィルター情報とメッセージの詳細情報があります。

管理のUI

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

管理のUI
  1. 前ページまたは次ページへ遷移

  2. 設定

  3. 検索のリフレッシュ

  4. 現在のユーザーとログアウトオプション

  5. ヘルプ

  6. ギアアイコン

  7. ステータスペイン

  8. ナビゲーションペイン

Table 13. 管理のUI
オプション 説明

アカウント (数)

Collaboratorが管理しているアカウントの表。下記の操作が可能です。

  • ポップアップ表示からID情報を表示: アカウントの行にカーソルをあてて停止します。

  • 表の行を右クリックするかギアアイコンを使用して、次の機能にアクセスします: 削除, 編集, パスワードを変更, 新しい管理者, メールを表示, 新規, セッションを無効にする, 権限を表示, 許可を設定, メールボックスを移動, メールを検索

エイリアス (数)

Collaboratorが管理しているエイリアスの表。各エイリアスは、全てのメールを特定のアカウントへ転送するメールアドレスです。

下記の操作が可能です。

  • ポップアップ表示からID情報を表示: エイリアスの行にカーソルをあてて停止します。

  • 表の行を右クリックするかギアアイコンを使用して、次の機能にアクセスします: 削除, 編集, 新しい管理者, メールを表示, エイリアスの 移動, 新規, セッションを無効にする, 権限を表示, 許可を設定, メールボックスを移動, メールを検索

配布リスト (数)

Collaboratorが管理している配布リストの表。配布リストとは、ある共通メールアドレス1つを使用した、メールアドレスのグループリストです。配布リストへの送信は、そのリストに含まれる全員のアドレスへの送信です。 To: の宛て先の行には、この配布リストのアドレスが表示されます。

下記の操作が可能です。

  • ポップアップ表示からID情報を表示: 配布リストの行にカーソルをあてて停止します。

  • 表の行を右クリックするかギアアイコンを使用して、次の機能にアクセスします: 削除, 編集, 新しい管理者, メールを表示, 新規, 権限を表示, 許可を設定, メールを検索

リソース (数)

Collaboratorが管理しているリソースの表。リソースとは、ミーティングで予定される可能性のある場所または機器のことです。

下記の操作が可能です。

  • ポップアップ表示からID情報を表示: リソースの行にカーソルをあてて停止します。

  • 表の行を右クリックするかギアアイコンを使用して、次の機能にアクセスします: 削除, 編集, 新しい管理者, メールを表示, 新規, 権限を表示, 許可を設定, メールを検索

設定のUI

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

Configure UI
  1. 前ページまたは次ページへ遷移

  2. 検索

  3. 検索のリフレッシュ

  4. ヘルプ

  5. ギアアイコン

  6. ステータスペイン

  7. ナビゲーションペイン

Table 14. 設定のUI
オプション 説明

提供サービス

管理コンソールから管理する提供サービス(COS)を表示します。

  • 表内の行をダブルクリックし、選択したCOSの設定画面へアクセスします。

    あるいは

  • 表内の行を右クリック、またはギアアイコンを使用して、次の機能へアクセスします: 新規, 削除, 編集, 複製

ドメイン

管理コンソールから管理するドメインを表示します。

  • 表内の行をダブルクリックし、選択したドメインの設定画面へアクセスします。

    あるいは

  • 表内の行を右クリック、またはギアアイコンを使用して、次の機能へアクセスします: 新規, 削除, 編集, GALを設定, 認証を設定, アカウントを表示, ドメインエイリアスを追加, 許可を設定

サーバー

管理コンソールから管理するサーバーを表示します。

  • 表内の行をダブルクリックし、選択したサーバーの設定画面へアクセスします。

    あるいは

  • 表内の行を右クリック、またはギアアイコンを使用して、次の機能へアクセスします: 編集, キャッシュをフラッシュ, プロキシを有効にする, プロキシを無効にする

グローバル設定

Zimbra Collaborationのグローバルパラメーターの設定に使用するツールへアクセスできます。

ギアアイコン: 保存, ダウンロード, ライセンスを更新, ライセンスのアクティベーション, 手動によるライセンスのアクティベーション

Zimlet

管理コンソールから管理するZimletを表示します。

  • 表内の行をダブルクリックし、選択したZimletの設定画面へアクセスします。

    あるいは

  • 表内の行を右クリック、またはギアアイコンを使用して、次の機能へアクセスします: 配備, 配備解除, ステータスの切り替え

管理拡張機能

管理コンソールから管理する管理拡張機能を表示します。

  • 表内の行をダブルクリックし、選択した管理拡張機能の設定画面へアクセスします。

    あるいは

  • 表内の行を右クリック、またはギアアイコンを使用して、次の機能へアクセスします: 配備, 配備解除

証明書

管理コンソールから管理する証明書を表示します。

  • 表内の行をダブルクリックし、選択した証明書についての全般情報画面へアクセスします。

    あるいは

  • 表内の行を右クリック、またはギアアイコンを使用して、次の機能へアクセスします: 証明書をインストール, 証明書を表示

権限

管理コンソールから管理する様々な権限を表示します。

  • 表内の行をダブルクリックし、選択した権限についての全般情報画面へアクセスします。

    あるいは

  • 表内の行を右クリック、またはギアアイコンを使用して、次の機能へアクセスします: 表示

グローバルACL

管理コンソールから管理するグローバルアクセスコントロールリストを表示します。

  • 表内の行をダブルクリックし、選択したグローバルACLの編集画面へアクセスします。

    あるいは

  • 表内の行を右クリック、またはギアアイコンを使用して、次の機能へアクセスします: 追加, 削除, 編集

グローバル設定のUI

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

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

Table 15. グローバル設定のUI
オプション 説明

全般情報

  • 取得できるGAL検索結果の最大件数を設定します。

  • デフォルトドメインを定義します。

  • リモートデータソースのコンテンツを一度に実行できるスレッド数を設定します。

詳細は 全般情報の設定を参照してください。

添付ファイル

  • 特定の拡張子を持つファイルが添付されたメールを拒否するルールを有効にします。

  • 添付ファイルを読み込まないようにします。

  • 閲覧用に添付をHTML形式に変換します。

詳細は 添付の設定を参照してください。

MTA

  • 認証を有効にします。

  • メッセージの最大サイズを設定します。

  • プロトコルチェックとDNSチェックを有効または無効にします。

  • X-Originating-IPをメッセージのヘッダーに追加します。

詳細は MTA設定を参照してください。

IMAP

IMAPサービスを有効にします。この設定変更は、サーバーを再起動するまで反映されません。

POP

POPS3 サービスを有効にします。この設定変更は、サーバーを再起動するまで反映されません。

AS/AV

迷惑メールチェックとウィルス対策のルールを設定します。迷惑メールチェックの設定は、サーバーを再起動するまで反映されません。

テーマ

  • 既存テーマのカラースキームをカスタマイズします。

  • テーマにロゴを追加します。

テーマ設定を変更するには、サーバー設定のツールバーにある“キャッシュをフラッシュ”ボタンを使用して、サーバーテーマのキャッシュをフラッシュする必要があります。

詳細は テーマ色やロゴ管理を参照してください。

詳細設定

  • 外部のゲストとの共有ブリーフケースフォルダにログイン時、認証要求ダイアログに社名として最初に表示する表示名を設定します。

  • アカウントメール検証の正規表現ルールを追加します。

保持ポリシー

ユーザーのフォルダにあるアイテムの保持と廃棄の時間軸でのしきい値を設定します。保持ポリシーと廃棄ポリシーはグローバル設定として設定することもできます。グローバル設定から継承する代わりにCOSレベルのポリシーを設定することもできます。

Proxy

Webプロキシとメールプロキシのパラメーターを設定します。詳細プロキシパラメーター用のツールもあります。

S/MIME

(Secure Multipurpose Internet Mail Extensions): S/MIMEタブでLDAPの設定を行ないます (S/MIME機能が有効にされている場合)。ユーザーはプライベートキーの取得にLDAPサーバーを使用します。

ACL

(Access Control List): ACE(Access Control Entry)設定画面に遷移して、委任された管理者の管理権限を選択したターゲットに追加、編集、削除します。

Backup/Restore

基準のバックアップやオートグループ化のバックアップのバックアップパラメーターを設定します。 詳細はバックアップと復元をご覧ください。

HSM

(hierarchical storage management): メッセージをセカンダリボリュームに移動させる前の経過期間を設定します。

ライセンス

  • Zimbraライセンスを更新・インストールします。

  • 現在のライセンス情報を表示します。

ツールおよび移行のUI

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

Tools and Migration UI
  1. 前ページまたは次ページへ遷移

  2. 検索

  3. 検索のリフレッシュ

  4. 現在のユーザーとログアウトオプション

  5. ヘルプ

  6. ステータスペイン

  7. ナビゲーションペイン

Table 16. ツールおよび移行
オプション 説明

ダウンロード

ダウンロード可能なzipパッケージのあるZimbraユーティリティへアクセスします。多様なプラットホームに向けた移行ウィザードやOutlookコネクタが含まれており、一般的な管理用途や個々のエンドユーザーとの同期に使えます。詳細は ダウンロード可能なウィザードとコネクタ に記載しています。

ソフトウェア更新

お使いのシステムにZimbraサーバー更新が必要かどうかをチェックします。また、ポーリングやソフトウェア更新に必要な連絡先メール情報を表示します。

詳細は Zimbra Collaboration のソフトウェア更新を確認する を参照してください。

アカウント移行

システムで検知されたアカウント移行の詳細を表示します。インポートの合計数と各ステータスが一覧で表示されます。一覧にあるアカウント移行の各オーナー名も表示されます。 Zimbraサーバーからアカウントを移行する を参照してください。

クライアントのアップロード

システムにアップロードする対象ソフトウェアの最新版を閲覧するページです。画像を選択後、アップロード ボタンを使用して、ソフトウェアアップロードを処理します。

Backups

直近のシステムバックアップに基づく現在の空き容量と総容量 (MB) の概要ビューにアクセスします。このナビゲーションペインで管理者を特定し、その管理者に関連したバックアップ履歴を閲覧することもできます。この履歴には、ラベルと開始時間、終了時間が表示されます。また、各バックアップ結果やバックアップ対象のディレクトリパスが表示されます。詳細は、バックアップと復元 を参照してください。

ダウンロード可能なウィザードとコネクタ

ツールおよび移行 画面の ダウンロード オプションを利用して本項記載のツールを取得します。

Table 17. ツールおよび移行

Exchange/PST用の ZCS 移行ウィザード (32 ビット)
Exchange/PST用のZCS 移行ウィザード (64 ビット)

Microsoft ExchangeもしくはPSTファイルからZimbra Collaboration サーバーへ、メールカレンダーと連絡先をサーバー TO サーバーで移行するzipファイルを取得します。

このパッケージはPSTファイルのインポートのみサポートしており、テクニカルガイダンスのサポートのみが2020年12月31日まで提供しています。 なお、すべてのアカウント移行の代替案として、https://zimbra.audriga.com/[audriga社の移行ソリューション] の利用を推奨しております。

Domino用ZCS 移行ウィザード

このパッケージのサポートが終了しております。 なお、すべてのアカウント移行の代替案として、https://zimbra.audriga.com/[audriga社の移行ソリューション] の利用を推奨しております。

レガシーExchange用 ZCS 移行ウィザード

このパッケージのサポートが終了しております。 なお、すべてのアカウント移行の代替案として、https://zimbra.audriga.com/[audriga社の移行ソリューション] の利用を推奨しております。

Outlook MSI Customizer 用Zimbraコネクタ

標準のZCO MSIをカスタマイズに使用する機能の備わったテキストファイルです。サーバー名、ポート、組織専用の変数をカスタマイズできます。

Outlook Branding MSI用Zimbraコネクタ

標準のZCO MSIをカスタマイズするにはWindowsのVisual Basic Script Edition (VBScriptのスクリプトファイル)を取得します。カスタマイズにより、Zimbra製品の全インスタンスの名称およびロゴが入れ替わります。

Table 18. エンドユーザーツールおよび移行

Outlook用Zimbra コネクタ (32 ビット)
Outlook用Zimbra コネクタ (64 ビット) (ユーザー案内)

ユーザーのWindows システムにインストールするWindows Installer Package zipファイルを取得します。このアプリで、ユーザーのOutlookが ZCS サーバーのカレンダー、連絡先、メールと同期できます。

(レガシー)Microsoft Outlook PSTインポートツール

このパッケージのサポートが終了しております。 PST インポートする場合、一般的な移行ウイザードを使用してください。

(レガシー)Microsoft Exchange の移行ウイザード

このパッケージのサポートが終了しております。 なお、すべてのアカウント移行の代替案として、https://zimbra.audriga.com/[audriga社の移行ソリューション] の利用を推奨しております。

一般的な移行ウイザード

このツールでMicrosoft ExchangeサーバとOutlook PSTファイルにあるデータをZimbraサーバへインポートします。

このパッケージはPSTファイルのインポートのみサポートしております。 なお、すべてのアカウント移行の代替案として、https://zimbra.audriga.com/[audriga社の移行ソリューション] の利用を推奨しております。

検索のUI

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

  • 検索のクエリを入力せずにこのページを開くと、デフォルトで全検索が行なわれ、コンテンツペインにアカウント、ドメイン、配布リストが表示されます。

  • オートコンプリーション機能によって、名前の一部を入力後表示される 一致した文字列一覧から、検索可能な名称を選択することができます。

  • ZimbraのメールボックスIDの数値を使用して、アカウント検索することもできます。ただし、メールボックスIDによる検索の場合、検索時にIDの全文字列を入力する必要があります。

Search UI
  1. 前ページまたは次ページへ遷移

  2. 検索オプション

  3. 検索

  4. 検索のリフレッシュ

  5. 現在のユーザーとログアウトオプション

  6. ヘルプ

  7. ギアアイコン

  8. ステータスペイン

  9. 検索ナビゲーションペイン

Table 19. 検索のUI
オプション 説明

すべての結果

全検索結果の件数および表を表示します。

アカウント

アカウントに対するクエリ結果の件数および表を表示します。

ドメイン

ドメインに対するクエリ結果の件数および表を表示します。

配布リスト

配布リストに対するクエリ結果の件数および表を表示します。

基本属性

姓、名、表示名、あるいはアカウントのID番号によってユーザーを検索します。管理者や委任された管理者のみの検索も可能です。

ステータス

次のステータスによってアカウントを検索します: アクティブ、閉鎖、ロック、ロックアウト、保留、メンテナンス

最終ログイン時刻

最終ログイン時刻によってアカウントを検索します。検索対象とするデータの範囲を指定できます。

外部メールアドレス

外部メールアドレスによってアカウントを検索します。

提供サービス

提供サービスによってオブジェクトを検索したり、提供サービスのないオブジェクトを検索します。

サーバー

選択したサーバーのアカウントを検索します。

ドメイン

選択したドメインのアカウントを検索します。

保存済み検索

このセクションにはデフォルトで、事前に定義された共通検索クエリがあります。オリジナルのクエリを作成して保存することも可能です。クエリ文を入力後、検索を保存 ボタンをクリックして名付けた検索は、保存済み検索セクションに追加されます。

簡単な検索のセットアップ

  1. 検索タイプを決定するため、検索 項目にあるドロップダウンリスト内の次の選択肢から1つを選びます: アカウント, 配布リスト, エイリアス, リソース, ドメイン, 提供サービス, 全ての種類のオブジェクト

    アカウントの場合は、表示名、姓、名、メールアドレスの始まりの部分、エイリアス、配布先アドレス、メールボックスIDから検索することができます。

  2. 検索 項目に検索用文字列を入力します。

    部分検索も可能ですが、メールボックスIDでの検索の場合はIDの全文字列を入力する必要があります。

  3. 検索 をクリックします。

    入力条件に基づいた検索結果が検索ページに表示されます。

  4. 検索 > すべての結果 のナビゲーションペインに検索結果の合計数が表示されます。

ヘルプセンターのUI

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

Help Center UI
  1. 前ページまたは次ページへ遷移

  2. 検索

  3. 検索のリフレッシュ

  4. 現在のユーザーとログアウトオプション

  5. ヘルプ

  6. ステータスペイン

  7. ナビゲーションペイン

Collaboratorの表ツール

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

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

行でのアクション 結果

カーソルをあてる

(アカウントの行から取得した)右の例のように、選択したIDの詳細を表示します。

Tools

右クリック

選択行のポップアップメニューにアクセスします。右の例のとおり、共通の表からでも行によってポップアップメニューが異なる場合があります。

アカウントとエイリアス (左) : 配布リストとリソース (右) :

Tools

通知メッセージボックス

グローバル管理者は、管理コンソールに表示する通知メッセージ (MOTD: Message of the Day) を作成することができます。

管理者が管理コンソールへログインする度に、設定しておいた通知メッセージが画面左上に下記例のように表示されます。

Message of the Day

通知メッセージを閉じたり、置き換えたり、削除したりすることができます。

通知メッセージを閉じる

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

通知メッセージを作成する

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

コマンド入力を使用してメッセージを作成する場合は、表示したいメッセージをダブルクォーテーションマークで括ってください。

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

zmprov md <domain> zimbraAdminConsoleLoginMessage "message to display"

複数のメッセージを表示

zmprov md <domain> +zimbraAdminConsoleLoginMessage "second message to display"

通知メッセージを削除する

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

コマンド入力を使用してメッセージを削除する場合は、個別または複数の削除についての下記ガイドを参照してください。
  • 属性の前にマイナス(-)を付け、削除したい通知メッセージごとにダブルクォーテーションマークで括ってください。

  • すべての通知メッセージを削除する場合、シングルクォーテーションマークを記載してください。

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

zmprov md <domain> -zimbraAdminConsoleLoginMessage "message to display"

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

zmprov md <domain> zimbraAdminConsoleLoginMessage ''

参考:機能について

管理コンソールから使用できる下記トピックの機能概要を説明します。

GUIのロードマップ

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

管理コンソール UIの概要図
High-level View of Administration Console UI

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

ギアアイコンを利用する

表示されている選択可能なアイテムに ギア アイコンが使用できる場合、ページ右上にこのアイコンが配置されます。

The Gear Icon

実行できるオプションを確認するには、ナビゲーションペインやビューページにある項目を1つ選択し、ハイライトさせます。ハイライトされている項目に対し実行できないオプションは、ギアアイコンメニューで強調表示されません。つまり強調表示されたオプションは実行できます。下図は、全く同じ画面でナビゲーションペインの項目をハイライトさせたときと、ビューページの行エントリをハイライトさせたときの、ギアアイコンのオプション例です。

The Gear Icon

次の表は、ギアアイコンから開始できる機能と、それにより内容が変化するギアアイコンメニューの概要です。

Table 20. ギアアイコン 操作
ナビゲーションペインの項目 選択肢 オプション Gear Icon

ホーム モニター

サーバー統計

表示

メールキュー

フラッシュ

管理

アカウント

新規, 新しい管理者, 編集, 削除, パスワードを変更, セッションを無効にする, メールを表示, メールボックスを移動, 権限を表示, 許可を設定

エイリアス

新規, 新しい管理者, 編集, 削除, エイリアスを移動, セッションを無効にする, メールを表示, メールボックスを移動, 権限を表示, 許可を設定

配布リスト

新規, 新しい管理者, 編集, 削除, メールを表示, 権限を表示, 許可を設定

リソース

新規, 新しい管理者, 編集, 削除, メールを表示, 権限を表示, 許可を設定

設定

提供サービス

新規, 削除, 編集, 複製

ドメイン

新規, 削除, 編集, GALを設定, 認証を設定, アカウントを表示, ドメインエイリアスを追加, 許可を設定

サーバー

編集, キャッシュをフラッシュ, プロキシを有効にする, プロキシを無効にする

グローバル設定

保存, ダウンロード, ライセンスを更新, ライセンスのアクティベーション, 手動によるライセンスのアクティベーション

Zimlet

配備, 配備解除, ステータスの切り替え

管理拡張機能

配備, 配備解除

証明書

証明書をインストール, 証明書を表示

ボイス/チャットサービス

新規, 削除, 編集, セッションIDの生成

権限

表示

グローバル ACL

追加, 削除, 編集

ツールおよび移行

ソフトウェア更新

保存, 今すぐチェック

アカウント移行

タスクの削除, 最新の情報に更新, 移行ウィザード

バックアップ

表示, バックアップ, 復元, 設定, リフレッシュ

検索

すべての結果

削除, 編集, パスワードを変更, メールを表示, エイリアスを移動, セッションを無効にする, メールボックスを移動, ダウンロード

アカウント

ドメイン

配布リスト

項目のポップアップメニューを利用する

項目のポップアップメニューを利用して、その項目の処理を実行する方法もあります。

ナビゲーションペインにポップアップメニューはありません。

下記の例は、ビューページで特定したエントリから表示されるポップアップ内容を表します。

Example 5. ポップアップのオプション内容
Popup options

コンテナ

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

Containers

設定を管理する

ZCS コンポーネントは、ソフトウェアの初回インストール時に設定されます。インストール後は本章で説明するように管理コンソールやCLIから、コンポーネントを管理することができます。

管理コンソールの使用方法等に関する ヘルプ は、管理コンソール内で提供しています。CLIからしか実行できないタスクは、Zimbra CLI コマンド でコマンドラインのユティリティの使用方法についての説明を参照してください。

グローバル設定

グローバル設定はZimbraサーバー内の全てのアカウントに適用されます。グローバル設定はインストール中にあらかじめ設定されます。管理コンソールから設定を変更することもできます。

グローバル設定での設定内容は、デフォルト値としてサーバー、アカウント、提供サービス、ドメインのレベルに継承されます。こうしたレベルで属性が設定された場合、その設定はグローバル設定にオーバーライドします。

管理コンソール:

グローバル設定を設定するには次のように遷移します。
ホーム > 設定 > グローバル設定

設定済みのグローバル設定

  • デフォルトドメイン

  • GAL検索結果の最大件数。デフォルト値は100。

  • 添付ファイルのユーザーへの表示方法と添付ファイルの拡張子制限。

  • 認証プロセスの設定、外部配信用リレーMTA、DNS検索、プロトコルチェック。

  • 迷惑メールチェックの制御と受信メッセージをチェックするための迷惑メール対策のオプション。

  • Zimbra Collaborationサーバーとサードパーティ製のサーバーに渡る、Free/Busyのスケジューリング。

  • テーマのカスタマイズ: 配色の修正とロゴの追加。

  • 外部ゲストによる共有ブリーフケースへのアクセス時、表示される会社名の設定。

  • バックアップのデフォルトディレクトリとバックアップの通知情報。

  • セカンダリストレージ領域へのメール移動のためのグローバルHSMスケジュール。

  • 現在のZimbra ライセンス情報の表示、ライセンスの更新、作成済みアカウント数の表示。

全般情報の設定

管理コンソール:

ホーム > 設定 > グローバル設定

インストール・有効化されているサーバーのグローバルパラメーターの閲覧と設定は、 全般情報 ページから行ないます。

サーバーで定義した設定は、この全般情報ページで設定した内容をオーバーライドします。

General Information

  1. 要件に合うようにパラメーターを修正します。

  2. ギア アイコンから 保存 を選択します。

Table 21. 全般情報のパラメーター
オプション 詳細

GAL検索で取得できる結果の最大件数

ユーザー検索で返されるGAL検索結果の最大件数。ドメインでも設定できる値です。ドメインでの設定は、グローバル設定にオーバーライドします。
デフォルト値は100。

デフォルトドメイン

ユーザーがログインした際、アカウント認証で対象となるドメイン。

同時に実行できる予定済みタスクの最大数

外部データソースから取得するデータのスレッド数。

  • この値を低く設定しすぎると、充分な頻度での外部ソースからのメール受信ができなくなります。

  • この値を高く設定しすぎると、メールのダウンロードにサーバー負荷がかかり、主要である内部リクエストを正常に処理できなくなる恐れがあります。
    デフォルト値は20。

メールボックス削除のスリープ時間間隔

メールボックス削除のたびに"停止"するべき時間間隔です。メッセージ削除スケジュールを0に設定すると、メッセージは削除されません。そのため、メール、ゴミ箱、迷惑メールの保持期間を指定していたとしても、メッセージは削除されません。
デフォルトでは、1分毎のメッセージ削除がスケジュールされています。

デスクトップからアップロードされるファイルの最大サイズ (KB)

ブリーフケースにアップロードできる最大のファイルサイズです。

送信できる1件あたりのメッセージと添付ファイルの最大サイズは、 ホーム > 設定 > グローバル設定 > MTA ページの メッセージ セクションで設定します。

管理者ヘルプURL
委任された管理者のヘルプURL

Zimbra Collaboration のヘルプを使用するには、管理コンソールのヘルプにあるリンクのURLを使用します。

添付の設定

添付ファイルの処理ルールを設定する

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

管理コンソール:

ホーム > 設定 > グローバル設定 > 添付ファイル

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

Table 22. グローバル設定詳細
オプション 詳細

提供サービスの設定にかかわらず、添付ファイルを表示しない

ユーザーは添付ファイルをいっさい閲覧できません。添付ファイルからのウイルス発生防止用にこのグローバル設定を利用することも可能です。いっさいの添付ファイルが開けないからです。

提供サービスの設定にかかわらず、添付ファイルをHTML形式で表示

添付ファイルの閲覧はHTMLでのみ可能です。 提供サービスに他の設定をした場合も、このグローバル設定が提供サービス設定にオーバーライドします。

提供サービスの設定に従って表示

添付ファイルの表示方法は、提供サービスで設定したルールに従います。

ブロックされている拡張子の通知を受信者に送信

拡張子から添付ファイルをブロックする

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

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

管理コンソール:

ホーム > 設定 > グローバル設定 > 添付ファイル

MTA設定

MTAページのオプションを使用して、認証の有効/無効、リレーホスト名、メッセージの最大サイズ、DNS検索の有効化、プロトコルチェック、DNSチェックを設定します。

管理コンソール:

ホーム > 設定 > グローバル設定 > MTA

MTA Configuration

Table 23. MTAページのオプション
オプション 詳細

認証

  • 認証 を有効にする:有効にしておく必要があります。モバイルSMTP認証ユーザーをサポートして、そのユーザーたちのメールクライアントがZimbra のMTAと会話できるようにします。

  • TLS認証のみ :すべてのSMTP認証にTransaction Level Security(処理レベルのセキュリティ)の使用を強制します。パスワードがそのままで通信されることを回避するためです。

ネットワーク

  • ウェブメールMTAホスト名とウェブメールMTAポート : メール送信用にウェブサーバーが接続するMTA。デフォルトポート番号は25です。

  • 外部配信用のリレーMTA : リレーホスト名。これは、Postfixが外部メールをリレーするZimbraのMTAです。

  • 受信SMTPホスト名: MXレコードが、スパムリレーや外部のZimbra以外のサーバーを指している場合、そのサーバー名を入力します。このチェックは、ドメインのMX設定を属性zimbraInboundSmtpHostnameと比較します。この属性が設定されていない場合、ドメインのMXをzimbraSmtpHostnameと比較チェックします。

  • 信頼できるMTAネットワーク : メールをリレーしてよい信頼できるネットワークを設定します。複数のネットワークアドレスはカンマや空白で区切ります。

  • DNS が有効な場合、Zimbra のMTAは、あて先ドメインのMXレコード検索用の明示的なDNSクエリーを実行します。このオプションを使用しない場合、外部配信用のリレーMTA項目に、リレーホストを入力してください。

  • ドメイン管理者が管理コンソールからMXレコードを確認できるようにする : 有効な場合、ドメイン管理者はドメインのMXレコードをチェックできます。

Milter サーバー

  • Milterサーバーを有効にする : 有効な場合、配布リストへメール送信可能なユーザーに対するルールをMilterが強制できます。

アーカイブ機能の設定

  • アーカイブ機能をインストールした場合、ここで設定を有効化できます。

メッセージ

  • メッセージの最大サイズ(KB) : 送信できる1件あたりのメッセージと添付ファイルの最大サイズを設定できます。

    ブリーフケースにアップロードできるファイルの最大サイズの設定を設定するには、全般情報ページに遷移します。
  • メッセージにX-Originating-IPを追加X-Originating-IP ヘッダー情報で、サーバー転送されているメールメッセージの最初の送信元IPが特定できます。

ポリシーサービスの確認

  • zimbraMtaRestriction (疑わしいSMTPクライアントを拒否するためのチェック条件)をカスタマイズします。

プロトコルチェック

  • 迷惑メール対策のため、迷惑メール(UCE)を拒否します。

DNSチェック

  • 不明なクライアントIPアドレスや、不明な応答ホスト名、不明な送信者ドメインの場合にメッセージを拒否します。

  • RBLリスト : メール宛先のその他の制限を入力します。

RBL (リアルタイムブラックホールリスト) は、Zimbraのコマンドラインから有効/無効にできます。

グローバルのIMAPとPOP設定

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

管理コンソール:

ホーム > 設定 > グローバル設定 > IMAP
ホーム > 設定 > グローバル設定 > POP

IMAPやPOPの設定を変更した場合、その反映にZimbra Collaborationを再起動する必要があります。

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

IMAP/POPのプロキシがセットアップされていたら、そのポート番号が正しく設定されていることを確認してください。

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

ドメインの設定を管理する

ドメインはインストール中に1つ作成されます。インストール完了後にドメイン追加ができます。管理コンソールから以下のドメイン管理機能を使用できます。

  • グローバルのアドレス帳(GAL)

  • 認証

  • ユーザーログイン時のデフォルトドメインを確立するための、そのドメイン用の仮想ホスト

  • 共有等で使用される、REST URL用のパブリックサービスホスト名

  • そのドメイン内で作成可能な最大アカウント数

  • Microsoft Exchangeで利用するFree/Busyのインターオペラビリティ設定

  • ドメインのSSL証明書

ドメインは名称変更できるので、この場合、アカウント、配布リスト、エイリアス、リソースのアドレスの全てが新しいドメイン名に切り替わります。CLIユーティリティを使用してドメイン名称を変更します。詳細は ドメイン名を変更するを参照してください。

ドメイン設定はグローバル設定をオーバーライドします。

ドメインの全般情報を設定する

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

管理コンソール:

ホーム > 2 ドメインを設定 > 1 ドメインを作成…​

Create Domain

Table 24. 新しいドメイン — 全般情報
オプション 詳細

ドメイン名 *
パブリックサーバーホスト名

REST URLのホスト名を入力します。この値はよくファイル共有で使用されます。詳細は以下の 公開サービスのホスト名を設定するを参照してください。

パブリックサービスのポート

ドロップダウンから、HTTP、HTTPSのいずれかを選択します。

パブリックサービスのポート

受信SMTPホスト名

ドメインのMXレコードが、スパムリレーや外部のZimbra以外のサーバーを指している場合、そのサーバー名を入力します。

説明

デフォルトの提供サービス

ドメインに作成されたアカウントに他の提供サービスが設定されていなければ、(そのドメインの)デフォルトの提供サービスが自動で適用されます。

ステータス

ドメインスのテータスは、通常の状態だとアクティブです。ユーザーはログインでき、メールは配信されます。このステータスを変更すると、そのドメインのアカウントのステータスにも影響が及ぶ可能性があります。ドメインのステータスは、 ドメイン > 全般情報 ページに表示されます。ドメインのステータス値は以下のとおりです。

  • アクティブ : 通常、ドメインのステータスは「アクティブ」です。アカウントを作成でき、メールは配信されます。

    アカウントのステータス設定がドメインのステータス設定と異なる場合、アカウントのステータスがドメインのステータスをオーバーライドします。
  • 閉鎖 : ドメインのステータスが「閉鎖」のとき、ドメインのアカウントはログインできず、メッセージは送信元へバウンスされます。閉鎖ステータスは個々のアカウントのステータス設定をオーバーライドします。

  • ロック :ドメインのステータスが「ロック」のとき、ドメインのアカウントはログインできませんが、メール配信はまだ続きます。アカウントのステータスが「メンテナンス」または「閉鎖」の場合、アカウントのステータスがドメインのステータスをオーバーライドします。

  • メンテナンス : ドメインのステータスが「メンテナンス」のとき、ドメインのアカウントはログインできず、メールはMTAのキューに留まります。アカウントのステータスが「閉鎖」の場合、アカウントのステータスはドメインのステータスをオーバーライドします。

  • 保留 : ドメインのステータスが「保留」のとき、ドメインのアカウントはログインできず、メールはMTAのキューに留まり、アカウントも配布リストも作成、削除、変更できません。アカウントのステータスが「閉鎖」の場合、アカウントのステータスがドメインステータスの設定をオーバーライドします。

公開サービスのホスト名を設定する

REST URL用のパブリックサービスホスト名をドメインごとに設定できます。REST URLは、メールフォルダ、ブリーフケースフォルダ、タスクリスト、アドレス帳、カレンダーの共有時に使用されます。

ユーザーがZimbra Collaboration フォルダを共有したとき、デフォルトでは次のように、Zimbraサーバーホスト名とZimbraサービスホスト名からURLが作成されます。 https://server.domain.com/service/home/username/sharedfolder

作成される属性

  • ホスト名:server.zimbraServiceHostname。

  • プロトコル:server.zimbraMailMode から決定されます。

  • ポート番号:プロトコルから算出されます。

パブリックサービスホスト名を設定すると、その名称が次のようにサーバー名とサービス名の代わりに使用されます。 https://publicservicename.domain.com/home/username/sharedfolder

使用される属性

  • zimbraPublicServiceHostname

  • zimbraPublicServiceProtocol

  • zimbraPublicServicePort

他のFQDNのDNS情報にて、Zimbraサーバーへ内部と外部で転送するように設定すると、パブリックサービスホストとして使用することができます。

グローバルアドレス帳(GAL)モードの設定

グローバルアドレス帳(GAL)は企業全体のユーザーリストのことで、メールシステムにいる全てのユーザーが、GALを参照できます。GALはメールシステムでよく使われる機能であり、ユーザーが正確なメールアドレスを覚えていなくても姓や名から他のユーザーを検索できるようにします。

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

グローバルアドレス帳(GAL)の定義は、ドメイン設定で GALモード設定 ツールから行ないます。

管理コンソール:

ホーム > 2 ドメインを設定 > 1 ドメインを作成…​ → GALモード設定

GAL Mode Settings

Table 25. 新しいドメイン — GALモード設定
オプション 説明

GALモード

  • 内部 : ZimbraのLDAPサーバーがディレクトリ検索に使用されます。

  • 外部 : 外部のディレクトリサーバーがGAL検索に使用されます。GAL用に外部LDAPホストを複数、設定できます。(設定、メール配信など)他のディレクトリサービスはZimbraのLDAPを使用します。外部GALモードを設定する場合、別の検索設定と同期設定を設定することができます。別の検索設定を利用する場合とは例えば、LDAPの検索を最適化するためにLDAPキャッシュサーバーをセットアップしている環境であるものの、ユーザーがGALに同期できるようにしたい場合などです。

  • 両方 : 内部と外部のディレクトリサーバーを両方がGAL検索に使用されます。

GAL検索で取得できる結果の最大件数

ユーザー検索で返されるGAL検索結果の最大件数。この値が定義されていない場合、グローバル設定で定義された値が使用されます。 デフォルト値は100。

GAL同期アカウント名*

読み取り専用。GAL同期名と紐づくドメインが表示されます。

内部GALのデータソース名

読み取り専用。内部GAL名が表示されます。

内部GALのポーリング間隔

GAL同期アカウントがLDAPサーバーと同期する頻度を日数、時間、分、秒数のいずれかで定義します。LDAPサーバーとの最初の同期時、LDAPにある全てのGAL内容がGAL同期アカウントのアドレス帳に登録されます。その後の同期は、新規作成、修正、あるいは削除された連絡先情報が更新されます。

GAL同期アカウントで、GALのアクセス速度を向上させる

GAL同期アカウントは、内部GALや外部GALの作成時、そのドメインに作成されます。複数のメールボックスサーバーを使用している環境では、メールボックスサーバーごとにGAL同期アカウントを作成することができます。GAL同期アカウントの利用により、GAL内の名称へのオートコンプリート機能が速くなります。

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

GAL同期アカウントはシステムアカウントのため、Zimbraライセンスを利用しません。

GAL同期アカウントの設定時にGALデータソースを定義します。データソースの連絡先情報がGAL同期アカウントのアドレス帳に同期されます。GALモードが*両方* の場合はアカウント内にLDAPのデータソース分、アドレス帳が作成されます。

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

GAL同期アカウントがLDAPのディレクトリと同期すると、LDAPにある全てのGAL連絡先情報がそのGAL同期アカウントのアドレス帳に追加されます。同期中、アドレス帳は、新規作成、修正、あるいは削除された連絡先情報で更新されます。アドレス帳を直接修正しないでください。LDAPとGALのそのアドレス帳との同期で、直接アドレス帳に修正していた内容は削除されます。

GAL同期アカウントは管理コンソールから作成します。CLIでのこの機能は zmgsautil になります。

GAL同期アカウントを追加作成する

ZCSが複数のメールサーバーで構成されている場合、各メールサーバーにGAL同期アカウントをもう一つ追加することができます。

管理コンソール:

ホーム > 設定 > ドメイン

  1. もう一つGAL同期アカウントを追加したいドメインをダブルクリックします。

  2. 画面の右上にある ギア アイコンをクリックし、GALを設定 をクリックします。

  3. GALアカウントを追加 をクリックします。

  4. GAL同期アカウント名項目に、このアカウントの名称を入力します。デフォルト名は利用しないでください。

  5. このアカウントを適用するメールボックスサーバーを選択します。

  6. GALデータソース名 を入力します。GALモード が 「両方」の場合、内部GALと外部GALのデータソース名を両方入力します。

  7. GAL同期アカウント更新のため、LDAPサーバーと同期すべき頻度を GALのポーリング間隔 に設定します。

  8. 完了 をクリックします。

GAL同期アカウント名を変更する

GAL同期アカウントのデフォルトアカウント名は galsync です。GALモードの設定時に別の名称を指定できます。GAL同期アカウント作成が完了した後のアカウント変更はデータ同期が失敗する要因となるため実施できません。

アカウント名を変更するには、既存のGAL同期アカウントを削除し、そのドメインの新しいGALを作成します。

管理コンソール:

ホーム > 設定 > ドメイン

  1. GAL同期アカウント名を変更したいドメインをダブルクリックします。

  2. 画面の右上にある ギア アイコンの GALを設定 をクリックしてウィザードを開いたら、GALモードを「内部」に変更します。他の項目は変更しないでください。完了 をクリックします。

  3. 管理コンソールの 管理 > アカウントに遷移してドメインのアカウントペインを開き、ドメインのGAL同期アカウントを削除します。

  4. 設定 > ドメイン に再度遷移して 「GALを設定」 をクリックします。GAL同期アカウント名項目にお好みの名称を入力します。他のGAL設定項目の入力が終わったら、 完了 をクリックします。ドメインのアカウントペインに新しいGAL同期アカウントが表示されます。

認証モード

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

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

管理コンソール:

ホーム > 2 ドメインを設定 > 1 ドメインを作成…​ → 認証モード

Table 26. 新しいドメイン — 認証モード
オプション 説明

認証メカニズム

  • 内部 : 内部の認証方法は、そのドメインの認証にZimbraディレクトリサーバーを使用します。内部を選択したらそれで設定完了です。

  • 外部LDAP : ディレクトリサーバーへのバインド操作で渡されるユーザー名とパスワードが認証情報です。外部サーバーへバインドするには、LDAP URLとLDAPフィルターの指定とDNパスワードの設定が必要です。

  • 外部Active Directory : Active Directory サーバーへ渡されるユーザー名とパスワードが認証情報です。Active Directory のドメイン名とURLを指定する必要があります。

仮想ホストの使用

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

仮想ホストを作成すると、それがユーザーログイン時のデフォルトドメイン名に使用されます。Zimbraウェブクライアントユーザーは、ユーザー名に含まれるドメイン名を入力せずにログインできるようになります。

管理コンソール:

ホーム > 2 ドメインを設定 > 1 ドメインを作成…​ → 仮想ホスト

Table 27. 新しいドメイン — 仮想ホスト
オプション 説明

仮想ホストを追加

ドメインの仮想ホストを識別するための英数字。仮想ホストにはAレコードを使用した有効なDNS設定が必要です。ドメインから仮想ホストを削除するには、ウィザード画面のホスト名の横にある 削除 ボタンをクリックします。

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

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

アカウント制限の設定

各ドメイン内で作成可能な最大アカウント数を制限することができます。作成可能な最大アカウント数はドメイン作成時に設定できます。ドメイン設定を編集して、この数を設定したり修正したりできます。

管理コンソールの 設定 > ドメイン > アカウント制限 ページから、この設定が可能です。このページを設定しない場合、ドメイン内アカウント数に上限はありません。

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

Zimbra Collaboration のライセンスによって定められている最大アカウント数を超えることはできません。

ドメインに複数の提供サービス(COS)がある場合、設定可能な提供サービスを選択すること、そしてその提供サービスに紐付けられるドメインアカウント数を設定することが可能です。これは、ドメインのアカウント制限ページで設定します。使用中の提供サービスアカウントタイプ数はトラッキングされます。全ての提供サービスのアカウント上限が、そのドメインの最大アカウント数を上回るようにはできません。

提供サービスに紐付けられるドメインアカウント数はトラッキングされます。アカウントの全般情報ページにて、紐付けた数とその残数が確認できます。

ドメイン名を変更する

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

ドメイン名変更前の作業

  • 新しいドメイン名向けにDNSにMXレコードが作成されていることを確認します。

  • 完全に機能する、そのドメインのバックアップがあることを確認します。

ドメイン名変更後の作業

  • 旧ドメイン名が設定されている外部リファレンスを新しいドメイン名に更新します。これにはバックアップ完了通知など管理者のメールボックスへ送信された自動生成メールが含まれることもあります。直ちに新ドメイン名のフルバックアップを実行します。

zmprov -l rd [旧ドメイン名] [新しいドメイン名]
ドメイン名の変更プロセス

zmprov コマンドの実行により、ドメイン名変更プロセスが以下の流れで進みます。

  1. 旧ドメイン名のステータスは内部ステータス「シャットダウン」に変わり、ドメインのメールステータスは「保留」に変わります。ユーザーはログインできず、メールはMTAのキューに留まり、アカウントもカレンダーのリソースも配布リストも作成、削除、変更できません。

  2. 新しいドメインは、内部ステータス「シャットダウン」で、メールステータスは「保留」で作成されます。

  3. アカウント、カレンダーのリソース、配布リスト、エイリアス、リソースはすべて新しいドメインにコピーされます。

  4. LDAPを更新して、新しいドメインアドレスを反映します。

  5. 旧ドメインが削除されます。

  6. 新しいドメインのステータスを「アクティブ」に変更します。新しいドメインでのメッセージの受信が可能となります。

ドメインのエイリアスを追加する

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

ドメインエイリアスはプライマリドメイン名と同じ、ドメイン名です。エイリアスを追加する前に、ドメインを所有し、かつ、その所有権を立証する必要があります。
管理コンソール:

ホーム > 設定 > ドメイン をアクセスし、右上の ギア アイコンより ドメインエイリアスを追加 をクリックします。

ドメインの警告サポートの有効化

警告はドメイン単位で設定します。アップグレード時はそれまでの運用を継続できるように、グローバル警告が各ドメインにあるドメイン専用の警告に自動変換されます。

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

  1. 新しいドメイン(例:example.com)とアカウント(例:user2@example.com )を作成します。

    $ zmprov cd example.com cb9a4846-6df1-4c18-8044-4c1d4c21ccc5
    $ zmprov ca user2@example.com test123 95d4caf4-c474-4397-83da-aa21de792b6a
    $ zmprov -l gaa user1@example.com user2@example.com
  2. 警告の使用を有効化します。

    $ zmprov mcf zimbraDomainMandatoryMailSignatureEnabled TRUE
    $ zmprov gcf zimbraDomainMandatoryMailSignatureEnabled
    zimbraDomainMandatoryMailSignatureEnabled: TRUE
  3. 新しいドメインに警告を追加します。

    $ zmprov md example.com
    zimbraAmavisDomainDisclaimerText "text disclamer"
    zimbraAmavisDomainDisclaimerHTML "HTML disclaimer"
    
    $ zmprov gd example.com zimbraAmavisDomainDisclaimerText zimbraAmavisDomainDisclaimerHTML
    # name example.com
    zimbraAmavisDomainDisclaimerHTML: HTML disclaimer
    zimbraAmavisDomainDisclaimerText: text disclamer
    
    $ zmprov gd eng.example.com
    # name eng.example.com
    zimbraAmavisDomainDisclaimerText
    zimbraAmavisDomainDisclaimerHTML
    1. 最初のMTAにて以下を実行します。

      /opt/zimbra/libexec/zmaltermimeconfig -e example.com
      
      Enabled disclaimers for domain: example.comm
      Generating disclaimers for domain example.com.
    2. 残り全ての追加MTAにて以下を実行します。

      /opt/zimbra/libexec/zmaltermimeconfig
      • テストとして、アカウント(例:user2@example.com)から、HTML形式とテキスト形式でメール送信します。

      • 検証として、HTMLの警告メールとテキストの警告メールが正しく受信されていることを確認します。

      • ドメインexample.comを無効化する場合

        1. Zimbraユーザーで最初のMTAにて以下を実行します。

          /opt/zimbra/libexec/zmaltermimeconfig -d example.com
        2. 残りの全MTAにて以下を実行します。

          /opt/zimbra/libexec/zmaltermimeconfig

内部ドメインメールの警告を無効化する

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

attachedzimbraAmavisOutboundDisclaimersOnlyTRUE にします。

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

警告の機能を無効化する

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

zmprov mcf zimbraDomainMandatoryMailSignatureEnabled FALSE

ドメインにあるZimlet

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

サーバーの設定を管理する

ZimbraのサーバーはZimbraのサービスパッケージが最低1つインストールされているマシンです。インストールする際、Zimbraのサーバーは自動的にLDAPサーバーへ登録されます。

管理コンソールから、Zimbraソフトを設定している全サーバーのステータスを閲覧することも既存のサーバーレコードの編集や削除することも可能です。サーバーをLDAPに直接追加することはできません。インストール時に新しいホストを登録するように設計されているZimbra Collaboration インストール用プログラムを使用して新規サーバーを追加する必要があります。

管理コンソールから、特定のサーバーに遷移したサーバー設定画面で閲覧できる情報。

  • 全般情報: サービスのホスト名、LMTP表示名、バインドアドレス、同時に実行できる予定済みタスクの最大スレッド数。

  • サービス:有効なサービスのリスト。 リスト内のサービスを有効/無効に設定できます。

  • MTA:サーバーの認証方法の有効/無効、グローバル設定と異なるウェブ メールのMTAホスト名、外部配信用のリレーMTAホスト名の指定、サーバーに対するMilterサーバーの有効/無効、Milterのバインドアドレスの指定。 必要に応じて、DNS参照の有効/無効も設定できます。

  • IMAP/POP: サーバーにPOPやIMAPの有効/無効、使用するポート番号の指定。IMAP/POPのプロキシを使用している場合、ポート番号が正常であることも確認できます。

  • ボリューム:インデックスとメッセージストアのボリューム設定およびHSMポリシーの管理。

  • IPアドレスのバインド:サーバーが複数のIPアドレスを使用している場合、IPアドレスのバインドにより、バインド先のインターフェースを指定できます。

  • プロキシ:プロキシを設定している場合、サーバーでの設定。

  • バックアップ/復元:サーバーのバックアップと復元設定。 サーバーのバックアップと復元を設定すると、グローバル設定のバックアップと復元の設定をオーバーライドします。

サーバーは、こうした値がサーバー設定で設定されていない場合、グローバル設定の値を継承します。グローバル設定から継承できる設定には、MTA、SMTP、IMAP、POP、ウィルス対策、迷惑メール対策の設定があります。

サーバーの全般情報

全般情報ページには以下の設定情報があります。

  • サーバー表示名と説明

  • サービスホスト名

  • LMTP表示名、バインドアドレス、同時に実行できる予定済みタスクの最大スレッド数。デフォルトは20スレッドです。

  • メールボックス削除間のスリープ時間:サーバーはメッセージの削除期間をスケジュール管理しています。メールボックスからメッセージの削除のスリープ期間は、グローバル設定、またはサーバー設定の全般情報で設定します。デフォルトでは、メールボックス削除を1分ごとに実行します。

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

zimbraImapCleartextLoginEnabled TRUE
zimbraReverseProxyLookupTarget TRUE
zimbraPop3CleartextLoginEnabled TRUE

「備考」項目に、設定のメモなどを自由に追加・保存することができます。

サーバーのMTA設定

管理コンソール:

ホーム > 設定 > サーバー → サーバー名 → MTA

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

  • 認証:

    ユーザーが認証できるように、SMTPのクライアント認証を有効にします。認証されたユーザーまたは信頼済みのネットワークのみ、メールのリレーが許可されます。TLS認証が有効な場合、パスワードがそのまま渡されないように、すべてのSMTP認証でTransport Layer Security (SSLの後継)が強制されます。

  • ネットワーク: ウェブメールMTAホスト名、ウェブメールMTAタイムアウト、外部配信用のリレーMTA、信頼できるMTAネットワークID、サーバーのDNS参照を有効にする機能があります。

  • Milter サーバー

    Milterサーバーを有効にする にチェックが入っている場合、Milterサーバーは配布リストへ送信できる差出人を制限します。

IPアドレスのバインドを設定する

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

管理コンソール:

ホーム > 設定 > サーバー → サーバー → IPアドレスのバインド

Table 28. IPアドレスのバインド
オプション 詳細

ウェブクライアントサーバーのIPアドレス

HTTPサーバーが待機するインターフェースアドレス

ウェブクライアントサーバーのSSL IPアドレス

HTTPSサーバーが待機するインターフェースアドレス

ウェブクライアントサーバーのSSL Client Cert認証 IPアドレス

クライアント証明書を受け入れるHTTPSサーバーが待機するインターフェースアドレス

管理コンソールサーバーのIPアドレス

HTTPSサーバーが待機する管理コンソールインターフェースアドレス

ZCSでSSLの証明書を管理する

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

使用可能な証明書は自己署名証明書と商業用の証明書の2種類です。

  • 自己署名証明書 :自己署名証明書は、発行した作成者自身が署名する認証用証明書。

    証明書のインストールウィザードを使用すると、自己署名の証明書を発行できます。自己署名の証明書を使用して有効期限を変更したい場合に役に立ちます。通常、自己署名証明書はテストに使用します。
    デフォルトは1825日間(5年間)です。

  • 商業用の証明書 認証局(CA)が発行する証明書で、証明書に含まれている公開鍵は企業(サーバー)の所有者であることを証明します。

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

自己証明の環境にあるZCOユーザーの場合、クライアントのWindows証明書ストアへルートCAの証明書を追加しなければ警告メッセージが表示されます。 Zimbra WikiZCO Connection Security を参照ください。

証明書をインストールする

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

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

管理コンソール:

ホーム > 1 開始 > 3. 証明書をインストール

証明書に設定するパラメーターは、下記のガイドを参照してください。

Table 29. 証明書のインストール
オプション 詳細

共通名 (CN)

ウェブサイトへのセキュアなアクセスに使用されるドメイン正式名です。 任意の共通名を使用する予定はありますか? サーバーにある単一ドメインに複数のサブドメインを一つの証明書で管理したい場合、このチェックボックスをオンにします。アスタリスク (*) が共通名フィールドに追加されます。

国名 (C)

証明書に会社の所在地として表示したい国名。

都道府県/州 (ST)

証明書に会社の所在地として表示したい都道府県/州名。

市区町村 (L)

証明書に会社の所在地として表示したい市区町村名。

組織名 (O)

社名

組織のユニット (OU)

ユニット名(あてはまる場合)

サブジェクト代替名 (SAN)

SAN(サブジェクト代替名)を使用するなら有効なドメイン名の入力が必要です。SANを使用中、ドメイン名はまず共通名と比較され、その後SANに対してマッチング検索されます。複数のSANを作ることもできます。代替名がこの項目に入力されていると、クライアントは共通名を飛ばしてサーバー名がSANのいずれかとマッチするべく検索します。

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

認証局より証明書を受信後したら証明書インストールウィザードを再度使用し、Zimbra Collaborationへインストールします。インストール後、サーバーを再起動して証明書を有効にします。

インストール済みの証明書を確認する

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

管理コンソール:

ホーム > 設定 > 証明書 → zmhostname

証明書には、Zimbra のLDAP、MTA、プロキシなどの様々なZimbraサービスが表示されます。

有効の証明書を維持する

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

ドメインにSSLの証明書をインストールする

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

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

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

zmprov md <domain> +zimbraVirtualHostName {domain.example.com} +zimbraVirtualIPAddress {1.2.3.4}
仮想ドメイン名は、Aレコードを使用した有効なDNS構成が必要です。

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

管理コンソール:

ホーム > 1 開始 > 3. 証明書をインストール

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

Certificate Domain Load

  1. 最初はドメインの証明書から、次にルート証明書と中間証明書を降順でコピーします。これにより、証明書のチェーン全体を認証させることができます。

  2. 証明書を保存する前に、秘密キーのパスワードを全て削除します。

    パスワードの削除方法は、商用の証明書の提供元に確認してください。

  3. アップロード をクリックします。

    ドメイン証明書は以下に配備されます。 /opt/zimbra/conf/domaincerts

メッセージをDKIMで認証する

Domain Keys Identified Mail (DKIM) はメール受信者が検証できる方法でメッセージ配信することの責任を、配信する会社に持たせる、ドメインレベルでの認証メカニズムです。DKIMを配置している会社は、送信元サイトもしくは中間サイトです。メッセージ配信が信頼できるかものかどうかは、送信元の会社の評価がベースとなって判断されます。

外部へ送信するメッセージに DKIM電子署名を追加することで、そのメッセージを自組織のドメイン名と関連づけることができます。DKIM署名 は ZCSでホストされているドメインであれば、いくつでも有効にできます。この機能の利用のために全ドメインを DKIM署名を有効化する必要はありません。

以下を使用してDKIM のメールの認証メカニズムを定義します。

  • ドメイン名の識別子

  • 公開鍵の暗号化

  • DNSベースの公開鍵の配信サービス

DKIM 署名はメッセージのヘッダー項目に追加されます。以下はヘッダー情報の一例です。

DKIM-Signature a=rsa-sha1; q=dns;
     d=example.com;
     i=user@eng.example.com;
     s=jun2005.eng; c=relaxed/simple;
     t=1117574938; x=1118006938;
     h=from:to:subject:date;
     b=dzdVyOfAKCdLXdJOc9G2q8LoXSlEniSbav+yuU4zGeeruD00lszZVoG4ZHRNiYzR

迷惑メール、スプーフィング、フィッシングなどの詐欺行為を制限するプログラムの一環として、DKIM署名を検証できる受信者が署名者に関する情報を利用することができます。

Zimbra CollaborationにDKIM署名を設定する

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

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

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

    /opt/zimbra/libexec/zmdkimkeyutil -a -d <example.com>

    DNSサーバーへの追加が必要な、そのドメインの公開DNSレコード情報が表示されます。公開鍵のDNSレコードは、DNSサーバーへ追加する必要のある、そのドメインのDNS TXTレコードとして表示されます。

    任意: コマンドラインに -b <####> のように -b を加えると、発行する公開キーのビット数を指定できます。 -b を付けない場合、デフォルト設定は2048ビットです。

    DKIM Data added to LDAP for domain example.com with selector B534F5FC-EAF5-11E1-A25D-54A9B1B23156
    
    Public signature to enter into DNS:
    B534F5FC-EAF5-11E1-A25D-54A9B1B23156._domainkey IN TXT
    "v=DKIM1; k=rsa; p=MIGfMA0GCSqGSIb3DQEBAQUAA4GNADCBiQKBgQC+ycHjGL/mJXEVlRZnxZL/VqaN/Jk9VllvIOTkKgwLSFtVsKC69kVaUDDjb3zkpJ6qpswjjOCO+0eGJZFA4aB4BQjFBHbl97vgNnpJq1sV3QzRfHrN8X/gdhvfKSIwSDFFl3DHewKDWNcCzBkNf5wHt5ujeavz2XogL8HfeL0bTwIDAQA B" ; ----- DKIM B534F5FC-EAF5-11E1-A25D-54A9B1B23156 for example.com

    発行されたDKIMデータは、LDAPサーバーにドメインのLDAPとして保存されます。

  2. ドメインのプロバイダーにて、ドメインのDNSのDKIMのTXTレコードを更新します。

  3. DNSサーバーを再起動し、DNSレコードがサーバーから正常に返答していることを確認します。

  4. 公開鍵が秘密鍵と一致するかどうかを確認するには、 -d, -s, -x についての 識別子 テーブルの説明を参照してください。

    /opt/zimbra/common/sbin/opendkim-testkey -d <example.com> -s <0E9F184A-9577-11E1-AD0E-2A2FBBAC6BCB> -x /opt/zimbra/conf/opendkim.conf
    Table 30. 識別子
    パラメーター 説明

    -d

    ドメイン名

    -s

    Selector

    -x

    設定ファイル名

ドメインのDKIMデータを更新する

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

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

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

/opt/zimbra/libexec/zmdkimkeyutil -u -d <example.com>

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

  1. ドメインのプロバイダーにて、ドメインのDNSのDKIMのTXTレコードを更新します。

  2. DNSサーバーをリロードし、サーバーがDNSレコードを返していることを確認します。

  3. 公開鍵が秘密鍵と一致することを検証します。識別子テーブルの説明を参照してください。

    /opt/zimbra/common/sbin/opendkim-testkey -d <example.com> -s <0E9F184A-9577-11E1-AD0E-2A2FBBAC6BCB> -x /opt/zimbra/conf/opendkim.conf

ZCSからDKIM署名を削除する

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

/opt/zimbra/libexec/zmdkimkeyutil -r -d example.com

ドメインのDKIMデータを取得する

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

/opt/zimbra/libexec/zmdkimkeyutil -q -d example.com

迷惑メール対策の設定を管理する

ZCS ではSpamAssassinを使用して迷惑メールを処理しています。SpamAssassinは事前に定義されたルールとBayesのデータベースを使用して、メッセージを評価します。メッセージが迷惑メールかどうかはメッセージ評価のパーセントから判断します。33%~75%でタグ付けされたメッセージは迷惑メールと判断され、ユーザーの迷惑メールのフォルダへ配信されます。75%以上でタグ付けされたメッセージはユーザーへ配信せず、削除されます。

迷惑メール対策の設定は変更できます。

管理コンソール:

ホーム > 設定 > グローバル設定 > AS/AV

Anti-Spam Settings

  1. 迷惑メール対策の項目に要件に合うパラメーターを入力します。

  2. ギア アイコンから 保存 を選択し、設定した内容を適用します。

    Table 31. 迷惑メール対策
    オプション 説明

    削除しきい値

    迷惑メールと判断され、配信されない値。
    デフォルト値は75%

    タグ付けしきい値

    迷惑メールと判断され、迷惑メールフォルダに配信される値。
    デフォルト値は33%

    件名のプレフィックス

    スパムとしてタグ付けされたメッセージの件名に追加する文字列。

メッセージが迷惑メールとしてタグ付けされた場合、そのメッセージは受信者の迷惑メールフォルダへ配信されます。迷惑メールフォルダに格納された未読メッセージ数の確認や、迷惑メールフォルダを開いて迷惑メールとしてタグ付けされたメッセージをレビューすることができます。迷惑メールの学習フィルターを有効にしている場合、メッセージを迷惑メールのフォルダに追加または削除すると、この操作が迷惑メールのフィルターを学習させることになります。

また、SpamAssassinにおけるRBL (Real time black-hole lists) をZimbra のコマンドラインから有効または無効にすることができます。

迷惑メール対策の学習フィルター

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

  • 迷惑メール(スパム)を学習ユーザー: 迷惑メールとしてタグ付けされなかったが、迷惑メールとすべきメッセージを学習する。

  • 迷惑メールではない(ハム)を学習するユーザー: 迷惑メールとしてタグ付けされたものの、そうすべきでなかったメッセージを学習する。

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

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

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

新たにインストールした ZCSでは、 最初にインストールされたMTAへのスパム/ハム学習に制限されます。このMTAをアンインストール、あるいは移動した場合、別のMTAでスパム/ハム学習を有効にする必要がでてきます。 `zmtrainsa --cleanup`を実行するために、ホストでこれを有効化しているはずだからです。

新しいMTAサーバー上で設定するには以下のコマンドを実行します。

zmlocalconfig -e zmtrainsa_cleanup_host=TRUE

スパムの学習メールボックスを無効にする

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

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

  1. グローバル設定の ZimbraSpamIsSpamAccountZimbraSpamIsNotSpamAccount を編集します。

  2. 指定した属性からメールアドレスを空欄(削除)に設定します。

    zmprov mcf ZimbraSpamIsSpamAccount ''
    zmprov mcf ZimbraSpamIsNotSpamAccount ''

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

スパムフィルターを手動で学習する

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

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

エイリアスのドメインへのバックスキャッタスパムメッセージ受信を防ぐ

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

ドメインエイリアスの作成の詳細は、 Zimbra wikiManaging Domainsの記事を参照してください。
  1. Postfixのローカル設定キーを指定します。

    zmlocalconfig -e postfix_enable_smtpd_policyd=yes
  2. MTAの制約を定義します。

    zmprov mcf +zimbraMtaRestriction "check_policy_service unix:private/policy"

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

Postfixのポリシーデーモンを無効にする

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

zmlocalconfig -e postfix_enable_smtpd_policyd=no
管理コンソール:

ホーム > 設定 > グローバル設定 > MTA

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

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

  • tname

  • クライアントは、完全修飾ドメイン形式 (FQDN) のホスト名で接続グリーティングしなければならない - reject_non_fqdn_hostname

  • 差出人のアドレスは、完全修飾ドメイン形式(FQDN)を使用しなければならない - reject_non_fqdn_sender

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

zmprov mcf -zimbraMtaRestriction "check_policy_service unix:private/policy"

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

  • reject_rbl_client cbl.abuseat.org

  • reject_rbl_client bl.spamcop.net

  • reject_rbl_client dnsbl.sorbs.net

  • reject_rbl_client sbl.spamhaus.org

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

管理コンソール:

ホーム > 設定 > グローバル設定 > MTA → DNS チェック

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

DNS Checks

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

コマンドラインでRBLを追加する

  1. 現在設定されているRBLを確認します。

    zmprov gacf zimbraMtaRestriction
  2. 新しいRBLタイプを追加します:1つのコマンドに、既存のRBLと新しいRBLを入力します。単語が分かれるRBL名は、入力時にクォーテションで括ってください。

    zmprov mcf zimbraMtaRestriction [RBL type]
Example 6. 例:全ての制限を追加する場合:
zmprov mcf \
 zimbraMtaRestriction reject_invalid_hostname \
 zimbraMtaRestriction reject_non-fqdn_hostname \
 zimbraMtaRestriction reject_non_fqdn_sender \
 zimbraMtaRestriction "reject_rbl_client cbl.abuseat.org" \
 zimbraMtaRestriction "reject_rbl_client bl.spamcop.net" \
 zimbraMtaRestriction "reject_rbl_client dnsbl.sorbs.net" \
 zimbraMtaRestriction "reject_rbl_client sbl.spamhaus.org"

ホワイトリストと迷惑メールとしてタグ付けされたメッセージに関するグローバルルール

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

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

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

zmprov mcf zimbraSpamWhitelistHeader <X-Whitelist-Flag>

値を設定

zmprov mcf zimbraSpamWhitelistHeaderValue <value_of_third-party_white-lists_messages>

ウイルス対策の設定

Zimbraがインストールされている各サーバーで、ウイルス対策機能は有効です。ウイルス対策機能は、ウィルスがあると判別されたメッセージを隔離用メールボックスに送信するように設定されています。受信者にはメール通知にて、ウイルスによりメッセージが隔離されたことが知らせます。隔離されたメッセージの保持期間は7日間です。

管理コンソールから、システム内でフィルタリング対象としたい迷惑メールを指定することができます。

管理コンソール:

ホーム > 設定 > グローバル設定 > AS/AV

AS/AV

  1. ウイルス対策の項目に、要件に合うパラメーターを入力します。

  2. ギア アイコンから 保存 を選択します。

Table 32. ウイルス対策
オプション 説明

定義更新頻度

Zimbra MTAはデフォルトで、ClamAVのウィルス対策の更新を2時間おきにチェックします。この頻度は1時間から24時間の間で設定可能です。

暗号化されたアーカイブをブロック

パスワードで保護されたzipファイルなど、暗号化されたアーカイブはブロックされます。

受信者に通知を送信

ウイルス隔離のため、メッセージ配信が中止されたことをメールで警告します。

Zimbra Collaboration インストール中に、警告の通知先となる管理者メールアドレスを設定します。デフォルトは、管理者アカウントがウイルス対策の警告メッセージを受け取るように設定されています。ウイルスが発見されると、このメールアドレスへ自動的に通知されます。

更新はHTTP通信経由でClamAVのウェブサイトから取得します。

ZimbraのFree/Busyカレンダー予約機能

Free/Busy機能では、効率的な会議のスケジューリングのために、ユーザーが互いのカレンダーを確認できます。ZCSとMicrosoft ExchangeのサーバーをまたいでFree/Busy機能のセットアップができます。

ZCSがMicrosoft Exchange 2003、2007、2010版のサーバーへユーザーのFree/Busyスケジュールを問い合わせることができ、さらに、ZCSユーザーのFree/BusyスケジュールをExchangeサーバーに展開することも可能です。

Free/Busyのインターオペラビリティを確立するには、Exchangeのシステムを以下のExchangeセットアップ条件に記載されているとおりに設定し、そして、Zimbra Collaborationのグローバル設定、ドメイン設定、提供サービス設定、アカウント設定を設定する必要があります。Zimbra Collaborationの設定は管理コンソールから行なうのが最も簡単です。

Exchange 2003/2007/2010でのセットアップ条件

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

  • システムに一つのActive Directory (AD)が存在する、またはグローバルカタログが使用可能であること。

  • Zimbra Collaborationサーバーが最低1つのExchangeサーバーのIIS用HTTP(S)ポートに接続可能であること。

  • Exchange公開フォルダへのウェブUIがIISで取得可能であること。(http://server/public/)

  • Zimbra Collaboration のユーザーが、Active Directory内で、メールドメインごとに同一の管理グループを使用して、連絡先として登録されること。これは、ExchangeへのFree/Busyレプリカ運用を行なうZCS の場合にのみ必要です。

  • Zimbra Collaboration からExchangeへのFree/Busyレプリカ運用を行なう場合、すべてのZimbra Collaboration ユーザーのアカウント属性の zimbraForeignPrincipal にExchangeユーザーのメールアドレスがプロビジョンされること。

Zimbra CollaborationにFree/Busyを設定する

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

  • グローバルまたはドメイン単位でExchangeサーバーの設定を設定します。

    • Microsoft Exchange サーバーURL:Exchange へのウェブ UI

    • Microsoft Exchange 認証スキーマ: ベーシック または フォーム

      • ベーシックは、HTTPベーシック認証を経由したExchangeへの認証です。

      • フォームは、HTMLフォームに基づく認証としたExchangeへの認証です。

    • Microsoft Exchange サーバータイプ: WebDav または ews

      • Exchange 2003や2007にFree/Busyを使用する場合、WebDAVを選択します。

      • Exchange 2010、SP1にFree/Busyを使用する場合、ews (Exchange Web Service) を選択します。

  • Microsoft Exchangeユーザー名とパスワードを入れます。Microsoft公開フォルダにアクセスできる、Active Directory内のアカウント名とパスワードです。RESTやWebDAVインタフェースで、Exchangeサーバーを認証するのに使用します。

  • グローバル設定のFree/Busyイントラページ、ドメインのFree/Busyイントラページ、あるいは提供サービス(COS)の詳細設定ページから、Exchange用に legacyExchangeDN 属性で使用される oou 値を追加します。グローバル設定から追加すると、Exchangeに接続するアカウントすべてに適用されます。

  • アカウントのFree/Busyインターオプページから、アカウントの外部プリンシパルメールアドレスを設定します。これにより、Zimbra CollaborationアカウントとAD内の該当オブジェクトとのマッピングがセットアップされます。

これらの設定をExchangeサーバーで確認するには、Exchange のADSI Editツールを使用し、 o= , ou= , cn= 設定の legacyExchangeDN 属性を検索します。

Zimbra Collaboration と Zimbra Collaboration 間のFree/Busyインターオペラビリティ

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

各サーバーは ZCS 8.0.x 以降を使用している必要があります。
  1. サーバーのホスト名とポートを入力します。

    zmprov mcf zimbraFreebusyExternalZimbraURL http[s]://[user:pass@]host:port

    user:pass を指定しない場合、サーバーは名無しでfree/busyを検索します。

  2. サーバーを再起動します。

    zmcontrol restart
  3. 全てのサーバーに上記の手順1と2を実行します。

S/MIMEを設定する

S/MIMEはセキュアなメールメッセージを送信するためのスタンダードの1つです。S/MIMEのメッセージは、認証とメッセージの暗号化にデジタル署名を使用します。

現在S/MIME機能は、2種類の方法で実現可能です。

  1. クライアントマシンにJava 1.6 SEがデプロイされている必要のある、古いクライアントベースのソリューション。

  2. クライアントマシンにJavaの必要のない、新しいサーバーベースのソリューション。サーバーは全ての暗号化処理を行ないます(推奨)。

クライアントベースのソリューションを使用して、S/MIME機能が利用できるようにセットアップする

前提条件
  • ユーザーがS/MIMEを利用するには、PKI証明書と秘密キーがなければなりません。利用しているWindowsやApple Mac端末内の証明書ストアへ秘密キーをインストールする必要があります。Firefoxブラウザを使用する場合はブラウザの証明書ストアへインストールします。証明書のインストール方法は、コンピュータやブラウザの該当資料を参照してください。

  • S/MIMEが利用できるブラウザ

    • Mozilla Firefox 4 以降

    • Internet Explorer 8, 9

    • Chrome 12 以降

  • S/MIMEを利用するには、端末にJava 1.6 SEがデプロイされていなければなりません。されてない場合、催促のエラーが表示されます。

S/MIME のライセンス

S/MIMEの機能を有効にする ZCS ライセンスが必要です。

S/MIMEの機能を有効にする
管理コンソール:

ホーム > 設定 > 提供サービス → COS名 → 機能
ホーム > 管理 > アカウント → アカウント名 → 機能

S/MIME機能は、提供サービス(COS)、または各アカウントの機能ページにて有効にすることが出来ます。

  1. 編集したい 提供サービスまたはアカウントを選択します。

  2. 「機能」タブにある S/MIMEを有効にする にチェックを入れます。

  3. 画面の右上の 保存 をクリックします。

S/MIMEの証明書をインポートする

ユーザーが宛先の公開鍵証明書を次の場所に保存している場合、そのユーザーは暗号化したメッセージをその宛先に送信できます。

  • ユーザーのアドレス帳にある宛先の連絡先情報

  • 使用しているOSやブラウザのキーストア

  • 外部LDAPのディレクトリ

証明書をLDAPディレクトリに公開して、GALから証明書が検索・取得できるようにします。S/MIMEの証明書のフォーマットは、X.509 Base64エンコードDERを使用します。

証明書を検索できるように外部LDAPを設定する

証明書を保管するために外部LDAPを利用する場合、クライアントではなく外部LDAPに対して証明書の検索・取得をするように、Zimbra サーバーを設定することができます。

管理コンソール:

ホーム > 設定 > グローバル設定 > S/MIME
ホーム > 設定 > ドメイン → ドメイン名 → S/MIME

外部LDAPのサーバー設定は、 設定→グローバル設定→S/MIME設定→ドメイン→S/MIME の遷移先で、設定できます。

グローバル設定は、ドメイン設定にオーバーライドします。
  1. 「設定→グローバル設定」ページを編集、または「設定→ドメイン」で編集したいドメインを選択します。 S/MIME タブを開きます。

  2. 設定名 に、外部LDAPサーバーを識別するための名称を入力します。 例) companyLDAP_1

  3. LDAP URL に、LDAPサーバーのURLを入力します。 例) ldap://host.domain:3268

  4. DNを使って外部サーバーへバインドする場合、 S/MIME LDAPバインドDN にバインドDNを入力します。 例) administrator@domain

    匿名バインドを使用する場合、バインドDN項目とバインドパスワード項目を空白のままにします。

  5. S/MIME LDAP検索ベース 項目に、証明書を探すために検索される、LDAPサーバーの特定のブランチを入力します。

    例) ou=Common Users, DC=host, DC=domain

    あるいは、検索ベースのDNが自動で見つかるように、 検索ベースを自動的に検索 にチェックを入れます。これには、S/MIME LDAP検索ベース項目を空にしておく必要があります。

  6. S/MIME LDAPフィルター 項目に、検索用フィルターテンプレートを入力します。このフィルターテンプレートには、次の変換用変数を入れることができます。

    • %n - @ を含む検索キー(または、@を何も指定しなかったら@を含まない検索キー。)

    • %u - @を取り除いた検索キー(例えば、mail=%n)

  7. S/MIME LDAP属性 項目に、ユーザーのS/MIME証明書を入れる外部LDAPサーバー内の属性を入力します。属性が複数の場合はカンマで区切ります。

    例) "userSMIMECertificate, UserCertificate"

  8. 画面右上の 保存 をクリックします。

他の外部LDAPサーバーを追加する場合、 設定を追加 をクリックします。

サーバーベースのソリューションを使用して、S/MIME機能の利用をセットアップする

前提条件

クライアントベースのS/MIMEソリューションと同様。ただし、クライアントマシンにJavaは必要ありません。秘密キーをクライアントマシンのローカル/ブラウザの証明書ストアに格納する必要もありません。

S/MIMEのライセンス

クライアントベースのS/MIMEソリューションと同様。

S/MIMEの機能を有効にする

クライアントベースのS/MIMEソリューションと同様。

S/MIMEの証明書をインポートする

クライアントベースのS/MIMEソリューションと同様。ただし、宛先の公開鍵証明書をローカルOSやブラウザのキーストアに保存する必要はありません。この証明書は、前回のS/MIMEバージョンで明記されている、他の場所全てに公開することができます。

サーバーベースのS/MIMEソリューションのサポートのために入力されるLDAP属性の一覧
  1. zimbraSmimeOCSPEnabled

    • ユーザーと公開証明書の検証時、サーバーが使用します。

    • TRUEの場合、証明書の検証中に失効チェックが行なわれます。

    • FALSEの場合、証明書の検証中に失効チェックは行なわれません。

  2. zimbraSmimePublicCertificateExtensions

    • サポートされている、公開証明書ファイルの拡張子。カンマ区切り。

    • サポートされている、userCertificate LDAP 属性の形式一覧が入ります。

    • デフォルト値: cer,crt,der,spc,p7b,p7r,sst,sto,pem

    • Zimbraウェブクライアントは、サーバーからアップロードされた公開証明書について、このサポートされた形式/拡張子を検索します。

  3. zimbraSmimeUserCertificateExtensions

    • サポートされている、公開証明書ファイルの拡張子。カンマ区切り。

    • サポートされている、userSmimeCertificate LDAP 属性の形式一覧が入ります。

    • デフォルト値: p12,pfx

    • Zimbraウェブクライアントは、サーバーからアップロードされたユーザー証明書について、このサポートされた形式/拡張子を検索します。

S/MIMEのメールボックス トラストストアにCA証明書を追加する処理

S/MIMEは、localconfig.xml内で定義されているメールボックス トラストストアパスとパスワードを使用します。

キー名称は次のとおりです。

  • mailboxd_truststore

  • mailboxd_truststore_password

mailboxd_truststoreキーがlocalconfig.xml内に定義されていない場合、デフォルトで、mailboxd_truststoreの値は以下になります。

  • <zimbra_java_home>/jre/lib/security/cacerts

メールボックス トラストストアにCA証明書は、下記コマンドを実行してインポートできます。

keytool -import -alias -keystore <mailboxd_truststore path> -trustcacerts -file <CA_Cert>

容量管理

保存容量ボリュームの管理

ボリュームページから、Zimbraのメールボックスサーバー内のストレージボリュームを管理できます。 Zimbra Collaboration インストール時、各メールボックスサーバーにインデックスボリュームとメッセージボリュームが1つずつ設定されます。 新規ボリュームの追加、ボリューム種類の設定、圧縮のしきい値の設定が可能です。

「Blobを圧縮」が有効の場合、使用中ディスク容量は減りますが、サーバーのメモリー需要は増加します。
インデックスボリューム

Zimbraの各メールボックスサーバーに「現在のインデックスボリューム」が設定されています。各メールボックスは「現在のインデックスボリューム」にある恒久ディレクトリに割り当てられます。アカウントの割り当て先ボリュームの変更はできません。

ボリューム容量がいっぱいになったら、新しい「現在のインデックスボリューム」を作成して、新規のアカウントに備えることができます。新規ボリュームの追加、ボリューム種類の設定、圧縮のしきい値の設定が可能です。

「現在の」インデックスボリュームとしてタグ付けされていないボリュームも、割り当てされたアカウントについて継続使用されています。メールボックスからインデックスボリュームとして参照されるボリュームを削除することはできません。

メッセージボリューム

新規メッセージの作成時や配信時に、メッセージは現在のメッセージボリュームに保存されます。メッセージボリュームは複数作成できますが、新規メッセージが格納される「現在のボリューム」は1つしか設定できません。ボリューム容量がいっぱいになったら、新しい「現在の」メッセージボリュームを設定できます。「現在の」メッセージボリュームはすべての新規メッセージを受け取ります。新規メッセージが以前のボリュームに保存されることはありません。

「現在の」ボリュームを削除することはできませんし、メッセージが参照しているボリュームを削除することもできません。

階層型ストレージ管理を設置する (*)

*Zimbra 8.8 より、本機能は2つの異なるバージョンを提供しています。Zimbra 8.8 はスタンダード版と新世代(NG)版を提供しています。Zimbra 8.7 またはそれ以前のバージョンは、スタンダード版のみを提供しています。以下にスタンダード版の詳細を記載しています。Zimbra 8.8 で本機能の NG版を利用する方法につきましては、本ガイドの NG版専用チャプターをご参照ください。

階層型ストレージ管理(HSM:Hierarchical Storage Management) では、古いメッセージ用のストレージボリュームを設定できます。HSMとは、データの経過年数に基づいて、プライマリボリュームから現在のセカンダリボリュームに古いデータを移動させる処理です。

ディスク利用を管理するために、グローバルなHSMポリシーやメールボックスサーバーごとのHSMポリシーを設定します。個々のサーバーに設定されたポリシーはグローバルポリシーとして設定されたポリシーにオーバーライドします。

メールのメッセージやその他のアカウント内アイテムは、HSMポリシーに基づいて、プライマリボリュームからセカンダリボリュームに移されます。ユーザーが移動されたメッセージやアイテムを開くとき、何ら変わりはないため、移動に気づくことはありません。

デフォルトのグローバルHSMポリシーでは30日以上経過したメッセージとドキュメントファイルをセカンダリボリュームへ移します。タスク、予定、連絡先も移動する選択をすることもできます。日数、月数、週数、時間、分で指定した経過期間を過ぎたアイテムを移動するスケジュールも設定できます。

移動するアイテムを選択できる上、検索クエリー言語を使用したHSMポリシーの追加も可能です。

例えば、迷惑メールとしてタグ付けされたメッセージすべてを現在のセカンダリボリュームへ移動する場合、message:in:junk before:-[x] days をポリシーに追加します。

検索文字列をデフォルトのポリシーに追加することも、新しいポリシーを作成することもできます。
HSMのセッションをスケジューリングする

セカンダリボリュームにメッセージを移動するセッションは、サーバーOSのcronテーブルにスケジューリングされています。管理コンソールからサーバーを選択後、ボリュームページにて、新しいHSMセッションをマニュアル操作で開始したり、HSMセッションを監視したり、実行中のHSMセッションを強制終了したりできます。

サーバーの ギア アイコンメニューからHSMセッションをマニュアル操作で開始することができます。

マニュアルでセッションを強制終了し、処理を再起動すると、HSMセッションがHSMの経過ポリシー条件に一致するエントリをプライマリストアから検索します。前回実行時に移動されたエントリはすでにプライマリストアに存在していないため、対象外になります。

HSMジョブを特定のバッチサイズになるように設定することができます。 zimbraHsmBatchSize の属性は、HSMのシングルオペレーションで移動できる最大アイテム件数をグローバルに、あるいはサーバーごとに設定できます。 デフォルトのバッチサイズは10,000です。上限を超える場合、すべての対象アイテムが移動されるまで、HSM処理が繰り返されます。

グローバルなバッチサイズの変更

zmprov mcf zimbraHsmBatchSize <num>

サーバーに対するバッチサイズの修正

zmprov ms `zmhostname` zimbraHsmBatchSize <num>

メール保持ポリシーの管理

ユーザーアカウントのメールメッセージ、ゴミ箱、迷惑メールフォルダに対する保持ポリシーを設定できます。基本となるメール保持ポリシーは、提供サービスや個々のアカウントの設定で、メールメッセージ、ゴミ箱、迷惑メールの保持期間を設定することです。

ユーザーがアカウントにある受信トレイやその他のメールフォルダに保持ポリシーを利用することも可能です。ユーザーも独自の保持ポリシーを作成できます。

Zimbra では、ゴミ箱から削除されたメッセージを保存しておくゴミ箱フォルダ機能を有効にできます。有効なとき、メールの保持期間ルールや廃棄ポリシーに基づく保持期間を過ぎたメッセージが、サーバー内のゴミ箱フォルダへ移されます。ユーザーは 完全に削除されるまでにゴミ箱内に保持される有効期間 で設定されたしきい値までであれば、ゴミ箱フォルダから削除したメッセージを復元できます。

ゴミ箱フォルダ機能が無効な場合は、メールの保持期間が過ぎるとメッセージはサーバーから完全に削除されます。

メッセージの削除を禁止するための訴訟ホールド(Legal Hold)をアカウントに設定することも可能です。

メッセージの有効期間

提供サービスや個々のアカウントの設定で、アカウントのフォルダ、ゴミ箱、迷惑メールフォルダからメールメッセージを自動削除する時期を設定できます。

Table 33. メール有効期間オプション
機能 詳細

メールメッセージの有効期間

RSSフォルダのデータも含め、フォルダ内のメッセージが自動的に消去されるまでの日数。
デフォルトは 0。
最低日数は30日です。

ゴミ箱のメッセージの有効期間

ゴミ箱へ移動したメッセージが完全に削除されるまでの日数。
デフォルトは30日です。

迷惑メールメッセージの有効期間

迷惑メールフォルダへ移動したメッセージが完全に削除されるまでの日数。
デフォルトは30日です。

メールメッセージの完全削除

基準の設定では、サーバーが1分ごとに有効期限を切れたメッセージを自動的に削除します。メールボックス削除のスリープ時間間隔を変更することができます。

メールボックス削除のスリープ時間間隔を分単位でグローバルに定義することが可能です。

管理コンソール:

ホーム > 設定 > グローバル設定 > 全般情報

Purge Interval

例えば、メールボックス削除のスリープ時間間隔を1分に設定している場合、サーバーはMailbox1から期限切れのメッセージを削除後、Mailbox2の期限切れのメッセージを削除するまでに1分間待機します。

メールボックス削除のスリープ時間間隔を「0」に設定していると、メール、ゴミ箱、迷惑メールのメッセージ有効期限が設定されていても、メッセージは自動削除されません。

ユーザーはメッセージ保持設定を閲覧できないため、メッセージの自動削除ポリシーを設定したら、ユーザーにお知らせください。

メッセージの保持ポリシーと廃棄ポリシーを設定する

保持ポリシーや廃棄ポリシーは、グローバル設定あるいは提供サービスの設定として設定することができます。ユーザーはこうしたポリシーを自分のアカウント内のフォルダに自由に選択・適用できます。 ユーザー独自の保持ポリシーや削除ポリシーを作成することも可能です。ユーザーはフォルダのプロパティの編集ダイアログから、管理者がセットアップしたポリシーの有効化や独自のポリシーの作成を行なうことができます。

グローバルな保持ポリシー

システムワイドな保持ポリシーや廃棄ポリシーを管理コンソールから管理できます。

保持ポリシーページを使用して、グローバルな保持ポリシーや廃棄ポリシーを管理します。

管理コンソール:

ホーム > 設定 > グローバル設定 > 保持ポリシー

Global Retention Policy

提供サービス用の保持ポリシー

選択した提供サービスの保持ポリシーページを使用して、その提供サービスの保持ポリシーや廃棄ポリシーを管理します。

管理コンソール:

ホーム > 設定 > 提供サービス → 提供サービス名 → 保持ポリシー

COS Retention Policy

提供サービス用の保持や廃棄ポリシーを使用する場合、 グローバル設定で定義されたポリシーを引き継がずにCOSレベルのポリシーを有効化します。 のチェックボックスがオンである必要があります。

保持ポリシーは、フォルダへ強制的に自動適用されません。フォルダの保持ポリシーの期限を超えていないアイテムをマニュアル操作で削除する場合、以下の警告メッセージが表示されます。
フォルダの保持期間内にあるメッセージを削除しています。 メッセージを削除しますか?

廃棄ポリシーのメッセージ有効期限が切れると、アイテムはアカウントから削除されます。このとき、ユーザーのゴミ箱フォルダには移されません。ゴミ箱フォルダ機能が有効であれば、サーバー内のゴミ箱フォルダへ移されます。そうでなければ、メッセージはサーバーから完全に削除されます。

メッセージの有効期間が保持/廃棄ポリシーと共に機能する方法

メッセージの有効期限がゼロ(0)以外の値であれば、フォルダに適用している保持ポリシーや廃棄ポリシーに加え、以下の設定が適用されます。

メッセージ有効期間が120日に設定されているとき

  • フォルダAに360日間のカスタム廃棄ポリシーがあるとき、120日間後にフォルダAのメッセージが削除されます。

  • フォルダBに90日間のカスタム廃棄ポリシーがあるとき、90日間後にフォルダBのメッセージが削除されます。

  • フォルダCに150日間のカスタム保持ポリシーがあるとき、120日間後にフォルダCのメッセージが削除されます。

ゴミ箱フォルダを管理する

ゴミ箱フォルダ機能が有効であれば、メッセージ、ゴミ箱、または迷惑メールの有効期間が切れると、メッセージはサーバー内のゴミ箱フォルダに移されます。ユーザーはZCS上のゴミ箱を右クリックし、 削除された項目を復元 を選択することで、X日の間に削除したメッセージを復元することができます。このしきい値は エンドユーザーがゴミ箱の内容を表示できる有効期間 の設定に基づいています。

完全に削除されるまでにゴミ箱内に保持される有効期間 で、ゴミ箱フォルダのメッセージ保持期間を設定します。保持期間より古いゴミ箱フォルダ内のアイテムは、完全に削除され、復元できません。

管理者は、ゴミ箱フォルダの中身(迷惑メールを含む)にアクセスでき、メッセージの保持期間が切れる前に強制削除することもできます。

ゴミ箱フォルダにあるアイテムを検索する
zmmailbox -z -m <user@example.com> search --dumpster -l <#> --types <message,contact,document> <search-field>

「Search-field」は、期間 'before:mm/dd/yyyy and after:mm/dd/yyyy' でも、特定の人物へのメール 'to: Joe' または特定の人物から 'from: Joe' のメールでも可能です。

ゴミ箱フォルダからアイテムを削除する

ゴミ箱フォルダにあるアイテムは、CLIや管理コンソールから削除できます。

zmmailbox -z -m <user@example.com> -A dumpsterDeleteItem <item-ids>
管理コンソール:

ホーム > 設定 > 提供サービス → 提供サービス名 → 機能 → 全般的な機能

  1. ゴミ箱フォルダ にチェックを入れて、有効にします。

  2. エンドユーザーがゴミ箱の内容を表示できる有効期間 を設定するには、提供サービス名の 詳細設定タイムアウトポリシーセクション に遷移します。

  3. 完全に削除されるまでにゴミ箱内に保持される有効期間 を設定するには、提供サービス名の 詳細設定メール保持ポリシー セクションに遷移します。

アカウントに訴訟ホールドを設定する

ゴミ箱フォルダ機能が有効であれば、ユーザーアカウント内のアイテムをすべて保管する訴訟ホールド(Legal Hold)の設定が可能です。

ゴミ箱フォルダ機能を有効にしたとき、 ゴミ箱フォルダの完全な削除が可能 となる機能も自動で有効化されます。 無効にすることで、ユーザーのゴミ箱フォルダのアイテムを削除する機能が停止します。提供サービスや個々のアカウントの設定で、この値を設定できます。 ゴミ箱フォルダの完全な削除が可能 が有効なとき、アカウント内のフォルダに設定した全ての削除ポリシーが無視されます。

訴訟ホールドの設定

管理コンソール:

ホーム > 設定 > 提供サービス → 提供サービス名 → 機能
ホーム > 管理 > アカウント → アカウント名 → 機能

機能 ページにある ゴミ箱フォルダの完全な削除が可能 のチェックをはずします。

管理拡張機能のカスタムモジュール

開発者は、Zimbraの管理コンソールのUIにカスタムモジュールを追加作成することができます。新規ビューの作成や、新しいデータオブジェクト管理の追加、あるいは既存のアイテムを新しいプロパティで拡張したり、既存ビューをカスタマイズすることも可能です。

管理コンソールUIのカスタムモジュール作成方法についての全般情報や最新情報は、Zimbra Wiki Extending_Admin_UIを参照してください。

管理コンソールUIに現在取り込まれているZimbra拡張機能は全て、閲覧のみ可として、コンテンツペインに一覧表示されています。

モジュールを作成した本人だけが削除することができます(「管理拡張機能のモジュールを削除する」を参照してください)。

新しい管理コンソールUIモジュールを配備する

管理コンソール:

ホーム > 設定 > 管理拡張機能

管理コンソールのアクセスに使用する端末に、モジュールのZipファイルを保存します。

  1. ギア アイコンから 配備 を選択して、Zimletまたは拡張機能をアップロードおよび配備 ダイアログを表示します。

  2. アップロードするカスタムモジュールのZipファイルを選択します。

  3. 配備 ボタンをクリックします。

    ファイルがアップロードされると即座に拡張機能がサーバーに配備されます。

管理拡張機能のモジュールを削除する

管理拡張機能を削除することで、選択したモジュールとその関連ファイルが全て削除されます。元のZipファイルは削除されません。

管理コンソール:

ホーム > 設定 > 管理拡張機能

下記手順で、管理拡張機能のカスタムモジュールを削除します。

  1. 削除したいモジュールを選択し、ギア アイコンから 配備解除 を選びます。確認用のメッセージダイアログが表示されます。

  2. はい をクリックすると、処理が実行されます。

Ephemeral Data(エフェメラルデータ)

Zimbra Collaborationの通常オペレーションにてLDAPに格納されるエフェメラルデータには主に3つあります。

  • 最終ログインタイムスタンプ (zimbraLastLogonTimestamp)

  • 認証トークン (zimbraAuthTokens)

  • CSRFトークン (zimbraCsrfTokenData)

ユーザー数が少ないメールシステムでは、このようなエフェメラルデータのストレージをLDAPサーバで行えることが可能です。 ただし、大量のアクティブユーザー様のメールシステムでは、短時間に残るデータストレージがLDAPをオーバーロードしてしまう可能性があります。 そのため、このようなエフェメラルデータを外部のサーバへ保管することを推奨しております。

注意:外部ストレージサーバーのインストールおよび管理方法は本書では言及しません。

エフェメラルデータのストレージ場所の設定は次のLDAP属性で行います。

属性

フォーマット

説明

zimbraEphemeralBackendURL

[backend name]:[params]

エフェメラルデータバックエンドURL設定

現在サポートされているエフェメラルデータの2つのバックエンド

バックエンド

フォーマット

説明

LDAP

ldap://default

デフォルト設定

SSDB

ssdb:127.0.0.1:8888

SSDBサーバーとポート

高頻度の認証リクエストは、エフェメラルデータのストレージバックエンドに高負荷を発生させます。以下の Zimbra Wiki ページにて、認証リクエストの負荷テストの結果をご参照ください。

運用中の Zimbra Collaboration に SSDB の利用へ変更する方法

すでに稼働中の Zimbra Collaboration 環境にて、 エフェメラルデータのストレージ用に LDAP ではなく SSDB を利用するには、次のように設定します。

  1. SSDB をインストールし、それに設定されているIPアドレスとポート番号をメモします。このデータを次の手順で使用する必要があるためです。詳細は、 SSDB インストールと設定 を参照してください。

  2. コマンド /opt/zimbra/bin/zmmigrateattrs を使って、既存のエフェメラルデータを SSDB へ移行します。

  3. Zimbra Collaboration が SSDB を使用するように設定します。

移行手順

  1. 環境にあるマシンのいずれかからコマンドプロンプトを立ち上げます。

  1. zmmigrateattrs ユーティリティを使用して、既存のエフェメラルデータを SSDB バックエンドに移行します。

sudo su - zimbra
/opt/zimbra/bin/zmmigrateattrs ssdb:<ip address|hostname>:port #該当サーバーの値に変更してください。

IPアドレスもしくはホスト名を移行先URLのホスト部分として使用する場合があるかもしれません。いずれにせよ、そこからクラスタ内のすべてのマシンの適切なIPアドレスが導かれる必要があります。入力されたSSDBアドレスから、稼働しているバックエンドが導けない場合、移行処理は終了します。

  1. SSDB を使用するように Zimbra Collaboration を設定します。

sudo su - zimbra
zmprov mcf zimbraEphemeralBackendURL ssdb:<ip address|hostname>:port #該当サーバーの値に変更してください。

2.と同様、ホストとポートから、稼働しているSSDBバックエンドが導かれる必要があります。導けない場合、zimbraEphemeralBackendURL の値は変更されません。

移行の詳細

移行情報

コマンド zmmigrateattrs --status を実行すると、最新の移行処理についての情報が表示されます。移行が現在進行中の場合、このコマンドを別のターミナルウィンドウから実行する必要があるかもしれません。これにより、下記の3種類の情報が出力されます。

  1. 移行のステータス: IN_PROGRESS(進行中)、COMPLETED(完了)、FAILED(失敗)のいずれか。

  2. 移行先として機能するSSDBバックエンドのURL。

  3. 移行処理が開始された時点のタイムスタンプ。

移行情報はコマンド zmmigrateattrs --clear によりリセット可能です。リセットは、このステータスがシステムの真の状態を反映していない場合にのみ実行するようにしてください。

一時的なバックエンドのURLを変更する

zimbraEphemeralBackendURL の値が修正されると、 Zimbra Collaboration は把握できる最後の移行のステータスをチェックします。その後のシナリオは下記のとおりいくつかに分かれます。

  1. 移行が完了しており、URLが新しく入力された値と一致する場合、 zimbraEphemeralBackendURL はこの新しい値に変更されて、移行情報はリセットされます。これが想定するユースケースです。

  2. 移行が現在進行中の場合、zimbraEphemeralBackendURL は更新されません。

  3. 移行情報がない、移行が失敗している、新しいURLが移行のURLと不一致、のいずれかにあたる場合、zimbraEphemeralBackendURL は更新されますが、データが移行された保証はないことを伝える警告がログに記録されます。

エフェメラルデータを転送する

移行処理中と、バックエンドURLが変更されるまでの間は、LDAPと SSDB の両方に新しいエフェメラルデータを格納します。これにより、この2つのバックエンドを同期させないようにしています。移行先URLと一致するように zimbraEphemeralBackendURL の新しい値が更新されると、移行情報はリセットされ、転送のメカニズムは停止します。この値が不一致の場合、移行情報はリセットされず、転送は続きます。留意すべきこととして、最初の移行からURL変更までに開きがある場合でも、移行の実行は一回のみ必要です。対象のバックエンドはオフラインになるまで最新状態を維持します。しかし、移行終了からバックエンドURL変更までの間に SSDB がオフラインになった場合、移行を再実行する必要があります。

こうしたシナリオは下図にて表すことができます。

(左図:移行中と移行後)
(中央:バックエンドポイントを移行のURLに変更後)
(右図:バックエンドポイントを異なるURLに変更後) ephemeral data migration

高度な移行のオプション

zmmigrateattrs ツールに、移行に関するオプションをいくつか加えることができますが、充分に注意してお使いください。

  • -r または --dry-run オプションにて、実際の移行を行わなくてもアカウントごとの変更内容がコンソールに出力されます。

  • -n または --num-threads オプションにて、移行に使用されるスレッド数を指定します。このオプションを使わない場合は、同期(逐次)移行となります。

  • -a または --account オプションにて、カンマ区切りで指定したアカウント一覧を移行することができます。このオプションはテストまたはデバック時にのみ使用するようにしてください。

  • -d または --debug オプションにて、ログのデバッグが可能となります。

パラメーターに属性名をきちんと明示して渡さない限りは、前述の例のとおり、エフェメラルデータのすべての属性に対して移行が行われることになります。

移行に関する制約

エフェメラルデータの移行は一方通行のプロセスです。 zmmigrateattrs スクリプトでは、データを SSDB からLDAPに戻すことはできませんし、異なる SSDB インスタンス間でデータ移行することもできません。すなわち、移行後に zimbraEphemeralBackendURL の値がLDAPに戻されたとしても、以前の認証データは接続不可になり、ユーザーセッションもすべて無効になります。新規 SSDB バックエンドへの移行が必要な場合は、事前にデータを新しいロケーションに複製してから、 zimbraEphemeralBackendURL の値を変更する必要があります。

これには1つ例外があります。 SSDB へ切り替えた直後は最小のデータ損失でバックエンドをLDAPへ安全に戻すことが可能です。この理由は、移行中は元の値がLDAPに保持されるためです。バックエンドを SSDB に切り替えると、切り替え時点のエフェメラルデータのスナップショットがLDAP内に残ります。移行のユーティリティは今のところ、領域を空けるためにこのデータを削除するという方法を採っていません。このため、バックエンドを戻すことは可能です。最初に変更してから戻すまでの時間が長くなるほど、LDAPのスナップショットはエフェメラルデータの真の状態から遠ざかることになります。

zmprovへの変更

マルチバリューのエフェメラルデータの格納方法の変更に伴い、属性 zimbraAuthTokenszimbraCsrfTokenDatazmprov ga <account> の一環として返されることはなくなります。 zimbraLastLogonTimestamp の値は従来どおり返ってきますが、 -l フラグが使われない場合だけです。 -l フラグを付加した場合、サーバーにアクセスを制限するのはLDAP内の属性のみだからです。こうした属性を zmprov ma <account> を使って修正することはエフェメラルデータのバックエンドに関係なく、引き続き可能です。修正を実施するには、次のように、与えられた属性値がそのLDAPフォーマットと一致していなければなりません。
認証トークンの場合 tokenId|expiration|serverVersion
CSRFトークンの場合 data:crumb:expiration

移行のCSV出力

zmmigrateattrs を実行するたびに、ディレクトリ /opt/zimbra/data/tmp/ 内にCSVファイルが作成されます。このファイルには移行されたアカウントごとの移行情報が含まれます。 例えば移行された属性の数などです。この数はゼロになることもあります。あるアカウントの全てのエフェメラルデータがすでに移行先ストアに存在するなどの場合です。

移行が失敗した場合、同一ディレクトリ内にエラーの詳細のみをレポートする切り出しCSVファイルが作成されます。ファイル名称は実行終了時で記録されます。

アカウント削除の実施

エフェメラルデータ削除の動きはSSDBバックエンドとLDAPバックエンドの場合で少々異なります。SSDBがバックエンドの場合、アカウント削除によって、最終ログインタイムスタンプ zimbraLastLogonTimestamp 属性はSSDBから消されることになります。しかし、認証トークン zimbraAuthTokens とCSRFトークン zimbraCsrfTokenData はそのトークンのライフタイムが経過するまでSSDB内に残ります(デフォルトでは2日間)。これに対して、LDAPのエフェメラルデータの場合は、アカウント削除処理の一部として、即座に一掃されます。

SSDB インストールと設定

インストール方法について

Zimbra Collaboration のパッケージには SSDB サーバーが含まれておらず、Zimbra Collaboration のインストールおよび構成ツールでは SSDB の設定を変更できません。最新版の SSDB をインストールする場合、SSDB の開発コミュニティに公開されている手順をご参照ください: SSDB Installation Documentation 現時点では、Zimbra Collaboration は SSDB 1.9.5 でのみ運用確認を行っております。 なお、SSDB 1.9.5 をインストールする際にhttp://ssdb.io/docs/install.html[SSDB installation instructions] のインストール手順を参照する場合、 master.zip ではなく、 stable-1.9.5.zip をダウンロードします。

設定オプションの概要

本章では、SSDB で使用可能なオプションについて次の観点から説明します。

  • マスター・スレーブ間レプリカ (複製) による高い可用性

  • マスター・マスター間レプリカ (複製) による高い可用性

  • マスターサーバーの複数利用 (マルチマスター) による高い可用性をもつ拡張機能

本書は、本件に関する精緻な説明するものではありません。また、本書の記載時点では、zimbraEphemeralBackendURL および移行用属性を変更を行なう前に、システム管理者による SSDB および関連パッケージのインストール・設定が完了していなければなりません。

SSDBRedis クライアントとの互換性があり、また現在、Zimbra Collaboration は Reis 互換クライアントを SSDB との通信に利用しています。このため、ここに記載するコンセプトの多くは、Reis バックエンドで適用できます。

マスター・スレーブ間レプリカによる高い可用性

通常処理

本書で説明するマスター・スレーブ間レプリカの実装方法では、 Keepalived を使って、設定済みバーチャルIPアドレスを保持します。このバーチャルIPアドレスは、通常状況下であれば、マスターである SSDB インスタンスにバインドされています。

ssdb master slave normal

フェールオーバー

Keepalived がマスターのインスタンスでの障害を検知すると、バーチャルIPアドレスはバックアップする側へとバインドされなおされます。これにより、バックアップ側インスタンスはマスターに昇格します。

ssdb master slave failover

マスター・マスター間レプリカによる高い可用性

マスター・スレーブ間レプリカと違う点は、両 SSDB インスタンスともにオンラインであり、かつ、アクセス可能であることです。片方の変更内容を、もう片方のインスタンスがレプリケーション (複製) します。後述するセットアップ例では、フロントエンドに HAProxy を使用します。商用の場合、プロキシサービス自体の可用性が高いものを使用する必要があることをご留意ください。

ssdb master master

マルチサーバー設定による拡張機能

通常、SSDBRedis も、単一インスタンス内にキー・スペース全体が入っています。しかし、 twemproxy サービスなどを利用して、複数のインスタンスをフロンドエンド化することも可能です。これは、ハッシュ化のモードを多数サポートしているため、特定のキーに紐づくデータがいつも同じサーバーに格納されるように実現できます。これにより、非常に大きな環境で拡張させることができます。

個々の SSDB インスタンスをマスター・スレーブペアに設定することで、高い可用性と拡張機能の双方を実現できます。

ssdb multi master

マスター・スレーブ間レプリカ

SSDB の可用性を高くする方法の1つは、マスター・スレーブ間レプリカにセットアップして、マスターのインスタンスが停止した場合にバックアップ側の SSDB インスタンスが自動で引き継ぐシステムを設定することです。本書では、この目的を遂行するための一技術を記載します。

概要

SSDB を2つのサーバーにインストールします。1つはマスターに指定、もう1つはスレーブつまりバックアップに指定したものとして設定します。そして定期的に後者がマスターサーバーでの変更内容をレプリケーションするように設定します。

Keepalived も両サーバーにインストールしてください。各 Keepalived インスタンスが互いを監視するようになります。マスターサーバーが停止した場合、 Keepalived がその障害を検知し、スレーブつまりバックアップサーバーをマスターサーバーへと昇格させます。 Keepalived は、現マスターサーバーがどちらであろうとその現マスターサーバーにバインドされている バーチャルIPアドレス を保持しています。

Keepalived で保持されているバーチャルIPアドレスが zimbraEphemeralBackendURL にバインドされるように、Zimbra Collaborationを設定します。

Zimbra Collaboration と SSDB マスター・スレーブ設定 両方 のインストールおよび設定が完了したら、 Ephemeral Data章にある手順に従い、zimbraEphemeralBackendURL を更新してください。

以下に記した例は、 Ubuntu 16.04 が稼動しているサーバー上にて実施されました。

必要パッケージ

前提条件

ご利用中のLinuxディストリビューションに適用できる手順に従い、 SSDBKeepalived を2つのサーバーにインストールするようにしてください。

設定

次の設定手順は、 SSDB/var/lib/ssdb にインストールされていること、そして、同一ディレクトリ内にすべての SSDB 設定ファイルがあることを前提にしています。また、内部のホストアドレスが 192.168.56/24 のネットワーク上にあるものとして記載します。

  • 192.168.56.111 - 当初、マスターである SSDB サーバーのIPアドレス

  • 192.168.56.112 - 当初、スレーブである SSDB サーバーのIPアドレス

  • 192.168.56.120 - Keepalived が保持することになるバーチャルIPアドレス

指定 (当初) マスターのSSDB設定

このマシンのIPアドレスは 192.168.56.111 です。

/var/lib/ssdb/ssdb_master.conf

後述の枠内に記載されている、キーとなる設定項目は次のとおりです。

  • server/ip - 有効なIPアドレスすべてをバインド

  • server/port - 標準の SSDB ポートをバインド

  • server/deny, server/allow - localhost および内部 (ホスト) アドレスに対する SSDB アクセスを制限

マスター・スレーブ間レプリカに関する設定項目のみ以下、記載します。

# ssdb-server config
# インデントはタブで!

# このファイルへのパス、ディレクトリが存在すること。
work_dir = ./var
pidfile = ./var/ssdb.pid

server:
        ip: 0.0.0.0
        port: 8888
        deny: all
        allow: 127.0.0.1
        allow: 192.168.56

replication:
        binlog: yes
        #  sync (同期) のスピード。*MB/sまで。 -1:無制限
        sync_speed: -1
        slaveof:
                # sync|mirror, デフォルトはsyncです
                #type: sync

/var/lib/ssdb/ssdb_slave.conf

後述の枠内に記載されている、キーとなる設定項目は次のとおりです。

  • server/ip - localhost をバインド

  • server/port - standard SSDB ポートをバインド

  • slaveof/type - sync

  • slaveof/host - 192.168.56.112 はもう片方の SSDB サーバー

  • slaveof/port - 8888 - 標準の SSDB ポート

繰り返しますが、マスター・スレーブ間レプリカに関する設定項目のみ以下、記載します。

# ssdb-server config

# このファイルへのパス、ディレクトリが存在すること。
work_dir = ./var_slave
pidfile = ./var_slave/ssdb.pid

server:
        ip: 127.0.0.1
        port: 8888

replication:
        binlog: yes
        #  sync (同期) のスピード。*MB/sまで。 -1:無制限
        sync_speed: -1
        slaveof:
                # sync|mirror, デフォルトはsyncです
                type: sync
                # host: <hostname>  SSDB 1.9.2 以上で利用可能。
                ip: 192.168.56.112
                port: 8888
指定 (当初) スレーブのSSDB設定

このマシンのIPアドレスは 192.168.56.112 です。

ssdb_master.conf ファイルは、対応する指定マスターサーバーと同じです。

ssdb_slave.conf ファイルは、対応する指定マスターサーバーとほぼ同じです。次のアイテムのみ異なります。

  • slaveof/ip (または host) - 192.168.56.111 はもう片方の SSDB サーバーです。

指定 (当初) マスターのKeepalived設定

/etc/keepalived/keepalived.conf

特記すべき、キーとなる設定項目は次になります。

  • state - 指定 (当初) マスターサーバーでもバックアップサーバーでも、Stateには BACKUP を設定。この場合、どちらのサーバーが当初 MASTER 状態かを決めるのに priority を使用します。

  • nopreempt - マスターサーバーが停止してバックアップサーバーがマスターサーバーへと昇格した場合、自動でオンラインに立ち上がるはずの元のマスターを、この設定ファイルの命令により、その役目を復活させないようにします。元のマスターはすでに最新の内容ではないからです。この場合、立ち上がった後は、バックアップモードで保たれることとなり、新たにマスターとなったサーバーから情報をレプリケーションするようになります。 注意: 停止したマスタを立ち上げるのにマニュアル操作が必要となる場合もあります。

  • interface - この例では enp0s8 がインターフェース識別子で、このために virtual_ipaddress が定義されることとなります。 環境に適した値を選別してください。

  • priority - 当初の指定マスターサーバーのpriorityの値は、当初の指定バックアップサーバーのpriorityの値よりも高くなければなりません。

  • advert_int - 本書の例としてはデフォルト値1秒を設定しました。 Keepalived 1.2.21 以上をご利用になる場合は、小数点以下を指定することができます。例 0.1 (秒)。これを使って Keepalived がマスターサーバーの停止を更に迅速に検知できるようにします。

  • notify - state 変更時に呼ばれるスクリプトのパスです。このスクリプトの全容は後述します。

  • virtual_ipaddress - Keepalived が保持するバーチャルIPアドレスです。

vrrp_instance VRRP1 {
        state BACKUP
        nopreempt
        interface enp0s8
        virtual_router_id 41
        priority 200
		advert_int 1
        notify /var/lib/ssdb/notify.sh

        authentication {
                auth_type PASS
                auth_pass 1234
        }
        virtual_ipaddress {
                192.168.56.120 dev enp0s8 label enp0s8:vip
        }
}

/var/lib/ssdb/notify.sh

以下はStateが変更されているときに Keepalived が呼ぶスクリプトです。ただし、USER に指定する値は、SSDB 処理のオーナーであるユーザー名にしてください。

#!/bin/bash
# rootで実行すること。

ENDSTATE=$3
NAME=$2
TYPE=$1

LOG=/var/log/keepalived-state-transition.log
LOG_ERROR=0
LOG_WARNING=1
LOG_INFO=2
LOG_DEBUG=3
LOG_LEVEL=$LOG_INFO

KPCFG=/etc/keepalived/keepalived.conf
USER=<SSDB-user-name>
PREFIX=/var/lib/ssdb


function log {
    lvl=$1
    msg="$2"
    if [ $lvl -le $LOG_LEVEL ]
    then
        now=$(date)
        echo "$now [$lvl] $msg" >> $LOG
    fi
}

function log_error {
    log $LOG_ERROR "$1"
}
function log_warning {
    log $LOG_WARNING "$1"
}
function log_info {
    log $LOG_INFO "$1"
}
function log_debug {
    log $LOG_DEBUG "$1"
}

function backup {
    log_info "Transitioning to BACKUP state"
    runuser -l $USER -c "${PREFIX}/ssdb-server ${PREFIX}/ssdb.conf -s stop"
    runuser -l $USER -c "cp ${PREFIX}/ssdb_slave.conf ${PREFIX}/ssdb.conf"
    runuser -l $USER -c "${PREFIX}/ssdb-server -d ${PREFIX}/ssdb.conf"

}

function fault {
    log_error "keepalived is in FAULT state"
}

function master {
    log_info "Transitioning to MASTER state"
    runuser -l $USER -c "${PREFIX}/ssdb-server ${PREFIX}/ssdb.conf -s stop"
    runuser -l $USER -c "cp ${PREFIX}/ssdb_master.conf ${PREFIX}/ssdb.conf"
    runuser -l $USER -c "${PREFIX}/ssdb-server -d ${PREFIX}/ssdb.conf"
}


case $ENDSTATE in
    "BACKUP") # Perform action for transition to BACKUP state
        backup
        exit 0
        ;;
    "FAULT")  # Perform action for transition to FAULT state
        fault
        exit 0
        ;;
    "MASTER") # Perform action for transition to MASTER state
        master
        exit 0
        ;;
    *)    echo "Unknown state ${ENDSTATE} for VRRP ${TYPE} ${NAME}"
        exit 1
        ;;
esac
指定 (当初) バックアップのKeepalived設定

/etc/keepalived/keepalived.conf

このファイルはマスターノードにあるファイルとほとんど同じですが、以下が異なります。

  • priority - 当初プライオリティはマスターノードより低くします。

  • nopreempt オプションはありません。一度、元のマスターサーバーの停止によりバックアップサーバーがマスターサーバーとなった場合は、元のサーバーがMASTERステータスに戻る前に、システムに対して人的介入ができるようにしておく必要があるためです。

vrrp_instance VRRP1 {
        state BACKUP
        interface enp0s8
        virtual_router_id 41
        priority 100
        advert_int 1
        notify /var/lib/ssdb/notify.sh

        authentication {
                auth_type PASS
                auth_pass 1234
        }
        virtual_ipaddress {
                192.168.56.120 dev enp0s8 label enp0s8:vip
        }
}

バックアップサーバーの /var/lib/ssdb/notify.sh はマスターと同じです。

マスター・マスター間レプリカ

概要

SSDB の可用性を高くするもう1つの方法は、マスター・マスター間レプリカにセットアップして、2つの SSDB サーバーの前段に、Redis プロトコルを読み解くプロキシを設定することです。このプロキシは、両サーバーの状態を監視して、停止したサーバーをその稼動状態からはずす役目があります 。

2つの SSDB サーバーの前段に単一の HAProxy インスタンスを使った簡単な例を以下説明します。

必要パッケージ

  • SSDB 1.9.2 以上のバージョンを想定した例を以下に示します。

  • HAProxy

前提条件

ご利用中のLinuxディストリビューションに適用できる手順に従い、 SSDB を2つのサーバーにインストールしてください。HAProxy を更に別のサーバーにインストールしてください。 KeepalivedHAProxy サーバープールの可用性を高くするのに役立ちます。

設定

プライマリマスターサーバーのSSDB設定

注意:

  • マスター・マスター間レプリカに関する設定項目のみ以下、記載します。

# ssdb-server config
## ssdb-server config インデントはタブで!

# このファイルへのパス、ディレクトリが存在すること。
work_dir = ./var
pidfile = ./var/ssdb.pid

server:
        ip: 0.0.0.0
        port: 8888
        deny: all
        allow: 127.0.0.1
        # e.g., 192.168.56
        allow: <ip-address-prefix>


replication:
        binlog: yes
        #  sync (同期) のスピード。*MB/sまで。 -1:無制限
        sync_speed: -1
        slaveof:
                id: svc_2
                type: mirror
                host: <hostname-of-other-master>
                port: 8888
セカンダリマスターサーバーのSSDB設定

注意:

  • マスター・マスター間レプリカに関する設定項目のみ以下、記載します。

# ssdb-server config
# インデントはタブで!

# このファイルへのパス、ディレクトリが存在すること。
work_dir = ./var
pidfile = ./var/ssdb.pid

server:
        ip: 0.0.0.0
        port: 8888
        deny: all
        allow: 127.0.0.1
        # e.g., 192.168.56
        allow: <ip-address-prefix>


replication:
        binlog: yes
        #  sync (同期) のスピード。*MB/sまで。 -1:無制限
        sync_speed: -1
        slaveof:
                id: svc_1
                type: mirror
                host: <hostname-of-other-master>
                port: 8888
HAProxy 設定

注意:

  • SSDB に関する設定のみ以下、記載します。

  • SSDBRedis というネットワークプロトコルをサポートしています。 Redis クライアントを使用して、SSDB サーバーに接続し、そこで操作することができます。これがZimbra Collaboration が行っていることです。

defaults REDIS
        mode tcp
        timeout connect  4s
        timeout server  30s
        timeout client  30s

frontend ft_redis
        bind <published-ip-address>:8888 name redis
        default_backend bk_redis

backend bk_redis
        option tcp-check
        server R1 <first-master-ip-address>:8888 check inter 1s
        server R2 <second-master-ip-address>:8888 check inter 1s

マルチサーバーでの拡張機能・レプリケーション

概要

本書では、マスターサーバー複数設定の詳細説明はいたしません。要するに、前述の手順どおり、個別 SSDB マスター・スレーブペアを複数、インストール・設定することになります。各ペアは、サブセットとしてのキー・スペース全体を持つ役割があります。

マスター・マスター間設定のように、 SSDB サーバープールの全ペアの前段に、Redis プロトコルを読み解くプロキシサーバーが存在します。また、特定のキーに関連する全てのリクエストが、必ず同じマスター・スレーブペアにルーティングされるために存在しているそのデータキーを、終始ハッシュ可能にしていなくてはなりません。

こうした製品の1つに Twitter から出ている twemproxy があります。

LDAP 属性

SSDB バックエンドは、SSDB サーバーに対するアクセス管理にリソースプールを利用します。つまり、エフェメラルデータ操作を行うスレッドは、まず、このプールでリソースを獲得します。このため、そのプールの設定管理用LDAP属性を以下2つ紹介します。

zimbraSSDBResourcePoolSize は、プールのサイズを制御します。これにより、エフェメラルAPI操作を同時に行なうことのできるクライアントスレッド数を決定します。デフォルトでは0が設定されており、この場合、プールサイズに上限はありません。

zimbraSSDBResourcePoolTimeout は、スレッドが例外をスローする前にリソースを待機する時間を制御します。デフォルトは0であり、この場合、時間切れはありません。プールサイズが0の場合、この属性による影響はありません。なぜなら、エフェメラルデータの操作を行なうのにスレッドがリソースの開放を待つ必要がないからです。

プールサイズが有限な場合、タイムアウトの値をゼロ以外にすることを推奨します。そうでないと、一度 SSDB 接続が切れたときに再度確立したあとも永久にmailboxdスレッドがブロックされ続ける原因となるからです。一般的に、リソースプールはメールボックスがリソースに困らないようなサイズにしておくべきです。

Zimbra Collaboration の運用負荷と合わせるように SSDB をチューニングする

SSDB サーバへ直接に影響する Zimbra Collaboration の運用負荷は認証リクエストの頻度と Zimbra Collaboration ウェブクライアントと第三者 SOAP クライアントで送信される SOAP リクエストの頻度となります。各認証リクエストは SSDB に 2つか3つの書き込み作業を発生させます。書き込み作業では、zimbraLastLogonTimestamp, zimbraAuthTokens, および zimbraCsrfTokenData の値を更新します。なお、zimbraCsrfTokenData は Zimbra Collaboration ウェブクライアント、などで CSRF を有効化している SOAP クライアントを利用する場合のみで更新されます。各認証された SOAP リクエストは SSDB に2つの読み込み作業を発生させます。

最小推奨の SSDB システム条件

最小のシステム条件として、SSDB サーバに 2GB RAM と 1つの CPU を推奨しております。SSDB サーバに監視と設定の管理ツール、などの追加ツールを実行する予定がある場合、メモリとCPUコアの増加をご検討ください。詳細につきましては、 Zimbra and SSDB Authentication Load Tests をご参照ください。

おわりに

エフェメラルデータのストレージ要件が単一インスタンス内で収まるような環境の場合は、シンプルなマスター・スレーブ間レプリケーションがいちばん簡単に実装できますし、リソースも最小限で済みます。マスター・マスター間レプリカの場合は、両マスターサーバー間でリクエストのロードバランスをとることができますが、双方が定期的にもう片方をレプリケーションしなければなりません。このため、整合性を保つという追加タスクが SSDB に課されます。

アカウントの提供サービスについて

アカウントに指定される提供サービス(COS)によって、ユーザーアカウントのデフォルト設定や各機能が使用可か不可かが決まります。各アカウントは、提供サービスが1つ指定されます。提供サービスにより、メールボックスの割り当て容量、メッセージの有効期限、パスワード制限、添付ファイルのブロック、サーバープールの使用量を制御します。

提供サービスはグローバルオブジェクトであるため、特定のドメインやドメインのセットに限定されることはありません。

管理コンソールから、提供サービスを作成、編集できます。

管理コンソール:

ホーム > 設定 > 提供サービス → 提供サービス名

提供サービスでアカウントの利用方法を管理する

Zimbra Collaboration のインストール時、デフォルト提供サービスが自動作成されます。管理者は、デフォルト提供サービスの修正や提供サービスの新規作成を実施できます。

提供サービスの画面から管理できる機能

  • アクセス可能な機能やプリファレンス

  • 使用可能なテーマやZimlet

  • 添付ファイル制限、割り当て容量、パスワードのログインポリシーなどの詳細設定

  • ウェブクライアントのバージョン(アドバンスドとスタンダードのクライアント)

  • ウェブサービスとデスクトップクライアント(EWS、MAPIなど)

  • オフラインモード

  • 保持ポリシー

例えば、メールボックスの割り当て容量無制限、メッセージ自動削除なし、全機能が有効の、提供サービスを経営者用に作成することができます。もう1つ、従業員用に提供サービスを作成し、そのメールボックスの割り当て容量を設定、60日以降の古いメッセージを自動削除を設定、メール以外の機能を無効にすることができます。特定の提供サービスでアカウントをグルーピングすることによって、アカウントの機能をいっぺんに更新・変更できます。このように、提供サービスの変更時、その提供サービスを指定されているアカウント全てが変更されます。

新規アカウント作成時に提供サービスを指定しないときや、ユーザーに指定していた提供サービスがなくなったとき、デフォルト提供サービスが自動で指定されます。

提供サービスを1つ作成し、それをあるドメインに作られた全アカウントのデフォルト提供サービスとして設定することができます。複数の提供サービスを作成し、そのうちどれをドメインが使用できるかを限定することも可能です。アカウントの作成時、そのドメインに決まった提供サービスがなく、管理者が提供サービスを指定しないとき、デフォルト 提供サービスが自動で指定されます。

提供サービスの設定は、グローバル設定やユーザー設定にオーバーライドされる場合があります。以下はその例です。

  • 送信済み フォルダに保存される送信メッセージを、別のフォルダに保存されるように、ユーザーのプリファレンスで変更できるかどうか。

  • グローバル設定として設定した添付ファイル制限は、提供サービスの設定にオーバーライドできます。

アカウントに指定した提供サービスのなかには、IMAPクライアントに適用されないものもあります。

機能やプリファレンスを選択する

提供サービスで使用できる機能はすべて、 機能 ページに表示されます。このページから、提供サービスに含めたい機能を選択したり、選択から外したりできます。

アカウントレベルでの設定変更は、そのアカウントの提供サービスでのルールをオーバーライドします。

プリファレンス ページで、メッセージの保存や閲覧の初期プリファレンスを設定できます。また、ZWCの表示に特定のロケールを選択することも可能です。ロケールを指定していない場合、ブラウザのロケールがデフォルトです。

機能やプリファレンスの詳細は、アカウントのカスタマイズ を参照してください。

プリファレンスを無効にする

デフォルトでは、プリファレンスは有効で、ユーザーはアカウントに設定されているデフォルト プリファレンスを変更できます。

管理者はプリファレンスを無効にすることができます。この場合、ユーザーのメールボックスのプリファレンスが非表示になるため、ユーザーはアカウントにセットアップされた機能のデフォルト設定を変更することができません。

デフォルトのタイムゾーンを設定する

アカウントのプリファレンスに表示されるデフォルトタイムゾーンは、標準版のウェブクライアントで受信するメッセージとカレンダー予定の、日付・時間のローカライズに使われます。

標準版のウェブクライアントを使用する場合、コンピュータのタイムゾーンはメッセージ受信日時やカレンダーの予定日時に使用されません。 プリファレンス > カレンダーオプション でのタイムゾーン設定が使用されます。

アドバンスド版のウェブクライアントの使用中は、コンピュータのタイムゾーンで受信メッセージやカレンダー予定のタイムスタンプが決まります。プリファレンスの 全般 にあるタイムゾーン設定は使われません。

アドバンスドと標準版のウェブクライアントは、メッセージの時間表示に同じタイムゾーンソースを使用していないため、複数のクライアントに表示されるメッセージのタイムスタンプが異なっていると気づく場合があります。この現象を回避するには、ウェブクライアントのタイムゾーンとコンピュータのタイムゾーンを一致させるます。

サーバープールを使用する

複数のメールボックスサーバーで構成している環境の場合、新規アカウントのメールボックスサーバーへの割り当てに、提供サービスが使われます。提供サービスの設定時、サーバープールへ追加すべきサーバーを選択します。各サーバープール内で、ランダムなアルゴリズムにより、新規メールボックスが有効サーバーに割り当てられます。

新規アカウントウィザードからの新規アカウント作成時、特定のメールボックスサーバーにアカウントを設定できます。 自動 からチェックを外し、サーバー項目にメールサーバーを入力します。

アカウントの割り当て容量を設定する

アカウントの割り当て容量とは、アカウントに許されているストレージサイズの上限です。メッセージ、アドレス帳、カレンダー、タスク、ブリーフケースのファイルが割り当て容量にカウントされます。アカウントの割り当て容量は、管理コンソールから提供サービスや個々のアカウントの設定で、設定できます。

割り当て容量の制限を「0」に設定した場合、アカウントに容量の制限はありません。

アカウントの割り当て容量の使用状況を確認する

ドメインの全アカウントの割り当て容量を確認します。

管理コンソール:

ホーム > 設定 > ドメイン → ドメイン名 → メールボックスの割り当て容量

割り当て容量の制限が近いことをユーザーに通知する

メールボックスの割り当て容量の制限に近づいている旨をユーザーは受け取ることができます。容量のパーセントと警告文は修正可能です。その提供サービスの 割り当て容量 コンテナへ遷移します。

管理コンソール:

ホーム > 設定 > 提供サービス → 提供サービス名 → 詳細設定 → 割り当て容量

表示/設定されたしきい値に達すると、割り当て容量を警告する通知がユーザーに送信されます。

ドメインの割り当て容量を設定する

ドメインのメールボックスの割り当て容量の上限を設定できます。ドメインのメールボックス割り当て容量のデフォルトは無制限です。ドメインの割り当て容量とは、ドメイン内の全メールボックスで使用できる最大ストレージ容量です。

総割り当て容量も設定可能です。ドメイン内全てのアカウント割り当て容量の合計が総容量を超えても構いません。

総割り当て容量に達したときに送受信するメッセージを管理する、総割り当て容量ポリシーを設定できます。このポリシーには下記のオプションがあります。

  • 送受信の許可(通常どおりメッセージの送受信を継続許可する)

  • 送信のブロック(メッセージの送信を許可しない)

  • 送受信のブロック(メッセージの送受信を許可しない)

設定された総割り当て容量の警告パーセントに達すると、警告メールが自動送信されます。日次で実行されるCron tabのジョブによりドメイン総割り当て容量パーセントがチェックされ、パーセントを超える場合は割り当て容量警告メールが送信されます。

ドメイン割り当て容量の設定時、アカウントの有効割り当て容量は、ドメイン設定またはアカウントの設定の下限値です。

ドメイン割り当て容量を設定するには、そのドメインの ドメイン割り当て容量設定 コンテナに遷移します。

管理コンソール:

ホーム > 設定 > ドメイン → ドメイン名 → 詳細設定 → ドメイン割り当て容量設定

容量超過時の管理

管理者は、メールボックス制限容量超過時におけるメッセージ配信管理を設定できます。デフォルトでは、MTAが一時的に据え置き用のキューにメッセージを送信します。メールボックスに充分な容量が戻ると、メッセージが配信されます。このときの動作を、メッセージを据え置き用のキューへ送信せずに送信者へ送り返すという方法と、超過した場合もメッセージをメールボックスへ送信するという方法に変更することができます。

メッセージを据え置き用のキューへ送信せずに、送信者へ送り返します。

zmprov mcf zimbraLmtpPermanentFailureWhenOverQuota TRUE

超過した場合もメッセージをメールボックスへ送信します。

zmprov mc {cos-name} zimbraMailAllowReceiveButNotSendWhenOverQuota TRUE

この属性がTRUEのとき、容量制限を超過したメールボックスでも、新規メールとカレンダー招待を受けとることができます。この迂回策はメッセージにのみ対応しています。その他のメールアイテムは依然として容量制限に左右されます。

パスワードを管理する

内部認証を使用しているとき、アカウントのツールバーから簡単にパスワード変更ができます。新規パスワードをユーザーに伝える必要があります。

Microsoft Active Directory (AD)をユーザー認証に使用時、提供サービスの「パスワードを変更」オプションを無効にする必要があります。ZimbraはADパスワードポリシーを管理しません。

管理者が作成したパスワードをユーザーに変更させたいなら、アカウントの 初回ログイン時にパスワードを変更させる オプションを有効にします。ユーザーの次回ログイン時、パスワード変更が必須となります。

パスワードの制約は提供サービスレベルまたはアカウントレベルで設定できます。強力なパスワードの作成やパスワードの定期的な変更をユーザーに要求したり、不正パスワードの入力時にアカウントをロックアウトするパラメーターを設定したりできます。

特定のパスワード変更ページを使用する

Zimbra Collaborationの認証が外部認証として設定されているなら、ユーザーのパスワード変更時、パスワード変更 ページへ転送するように設定できます。このURLはグローバル設定またはドメイン単位で設定できます。

パスワード変更ページのURLを zimbraChangePasswordURL 属性に設定します。

ZWCの プリファレンス > 全般 にある パスワードを変更 ボタンがこのURLへリンクします。また、パスワードが期限切れの時、このページに遷移されます。

ドメインのパスワードを修正します。

zmprov md example.com zimbraChangePasswordURL https://auth.example.com

パスワードのポリシーを設定する

ドメインの内部認証を設定しているなら、強力なパスワード作成をユーザーに要求してシンプルなパスワードによるディレクトリハーベスティング攻撃 (DHA) を防ぐことができます。設定されているログイン失敗回数の上限に達したら、アカウントからユーザーをロックアウトさせられます。

提供サービスの パスワード コンテナからパスワードポリシーを設定します。

管理コンソール:

ホーム > 設定 > 提供サービス → 提供サービス名 → 詳細設定 → パスワード

使用できるパスワード設定の一覧です。

Table 34. パスワードオプション
パスワードオプション 説明

パスワードの最小長/最大長

パスワードの最小と最大の長さを指定します。 デフォルトの設定では最小が6と最大が64文字です。

パスワードの最短/最長有効期間 (日)

パスワードの有効期限を設定します。最短から最長の間であれば、ユーザーはいつでもパスワードを変更できます。最長の有効期間を超えるとパスワードの変更が必要になります。

以下の設定で、強力なパスワードの作成をユーザーに要求できます。

大文字の最小数

A-Z の大文字

小文字の最小数

a-zの小文字

句読記号の最小数

アルファベットや数字以外の記号、例えば !, $, #, &, %

数字の最小数

10進数の数字 0 - 9

数字または句読点の最小値

英数値以外と数値との組み合わせ

固有パスワード履歴の最小数

一度使用したパスワードが再度使用可能となるまでの一意の新規パスワード数

パスワードの最短有効期間 (日)

パスワード変更までの最短日数

パスワードの最長有効期間 (日)

パスワード変更までの最長日数

ユーザーがパスワードを変更しないようにする

ユーザーはパスワードを変更できません。認証が外部なら、このオプションを有効にする必要があります。

初回ログイン時にパスワードを変更させる

ユーザーの初回サインイン時、パスワード変更が要求されます。

パスワードを変更

有効にした場合、パスワードの有効期限以内であればいつでもユーザーはアカウントのプレファレンスタブからパスワード変更ができます。

ログインポリシーを管理する

アカウントが一定期間ロックアウトされるまでのログイン失敗許容回数の上限を設定できます。こうしたポリシーの利用により、パスワード攻撃を防ぐことができます。

ユーザーログインポリシーを設定するには、その提供サービスの ログイン失敗ポリシー コンテナを使用します。

管理コンソール:

ホーム > 設定 > 提供サービス → 提供サービス名 → 詳細設定 → ログインポリシーのオプション

Table 35. ログインポリシーのオプション
ログインポリシーのオプション 説明

ログイン失敗のロックアウトを有効にする

「ログイン失敗時のロックアウト」機能を有効します。これ以降の設定が可能になります。

許可される連続ログイン失敗の回数

アカウントがロックアウトされるまでのログイン失敗許容回数。デフォルトは10。0のとき、アカウントはロックアウトされません。

アカウントをロックアウトする時間

アカウントがロックアウトされる期間。0のとき、正しいパスワードが入力されるまでロックアウトは解除されません。あるいは管理者がアカウントのステータスを変更し、新規パスワードを作成すると解除されます。デフォルトは1時間。

アカウントをロックするためにログインの失敗が発生しなければならない時間枠

ログイン失敗連続回数がログから消されるまでの期間。0のとき、ログイン失敗連続回数に関係なくユーザーは認証を試し続けることができます。デフォルトは1時間。

2要素認証について

2要素認証 (FA) 機能 (バージョン8.7で搭載) により、システムへアクセスされる際の認証レイヤーが増えるため、提供サービスやユーザーアカウントに適用するセキュリティポリシーを更に追加することができます。管理コンソールから、ユーザーのメールボックスに対する2FA機能の適用有無を管理します。

2 Factor Authentication

詳細は、 2要素認証 を参照してください。

セッションがタイムアウトするポリシーを設定する

管理者は複数の条件を用いてユーザーセッションの許容時間を設定できます。

セッションのタイムアウトポリシーを設定するには、特定の提供サービスの タイムアウトポリシー コンテナを使用します。

管理コンソール:

ホーム > Configure> 提供サービス → 提供サービス名 → 詳細設定 → タイムアウトポリシー

Table 36. セッションタイムアウトポリシーオプション
セッションタイムアウトポリシーオプション 説明

管理コンソール認証トークンの有効期間

管理者の認証トークンをブラウザのCookieに保存します。認証トークンの期限が切れるまで、管理者はログイン入力せずに管理コンソールを開くことができます。デフォルトは12時間。

認証トークンの有効期間

ZWC認証トークンをブラウザのCookieに保存します。認証トークンの期限が切れるまで、管理者はログイン入力せずにZWCを開くことができます。デフォルトは2日間。期限が過ぎるとログイン画面が表示され、処理の継続にログインが必要となります。

セッションのアイドルタイムアウト

アクティビティがなくてもユーザーセッションがアクティブでありつづける期間。アクティビティには、クリック可能なマウス操作、フォルダ内閲覧、ボタンクリックなどがあります。デフォルトは無制限。

管理コンソールのセッションを無効にするリンクから、ユーザーのウェブクライアントセッションを期限切れにすることができます。これにより、即座に現行セッションが無効になります。

defaultExternal提供サービスを管理する

defaultExternal提供サービスは、ZCS 登録ユーザーからのカレンダー共有やブリーフケースアイテム共有の招待を外部ユーザーが承諾したときに作成される外部仮想アカウントに指定されます。

仮想アカウントはサーバーに登録されないものの、外部ユーザーはZWCにログインでき、共有アイテムを閲覧するための表示名やパスワードを設定できます。閲覧できるのは、アクセスが許可されているフォルダのみです。

defaultExternalの提供サービスには、次の一般機能が設定されています。 パスワードを変更、UIテーマを変更、HTML作成、エクスポート、検索。主な機能は一切設定されていません。

アカウントのカスタマイズ

本章では、提供サービスや個々のアカウントの設定で、アカウントに対して設定できる機能とユーザープリファレンスについて説明します。

メールボックス機能はZimbraのウェブクライアントユーザーであれば有効です。IMAPやPOPクライアトの利用時、こうした機能が使用できない可能性があります。

メッセージングと情報共有のアプリ

提供サービスの設定やアカウントへの提供サービス設定により、アカウント機能のデフォルト設定と、アカウントグループに適用される制約が決まります。個々のアカウントに別の設定ができ、変更した設定はすべて、提供サービスの設定にオーバーライドします。提供サービスの更新時、提供サービスにオーバーライドする設定のあるアカウントには、その更新は反映されません。

メールのメッセージング機能

使用できるメールメッセージ機能はシステム管理者によって設定・管理されます。ユーザーはその使用できる機能のほとんどについて、プリファレンスから管理することができます。

デフォルトでは、ユーザー自身がプリファレンスを管理できますが、ユーザー側でアカウントのプリファレンスを修正できないように制御することもできます。現在サポートされているZWCのメールメッセージ機能を、 メール機能の表にまとめて記載します。

Table 37. メール機能
メールメッセージ機能 説明

メール

メールのアプリを有効にする。デフォルトで有効です。

管理コンソールの参照先: 提供サービス名 > 機能 → 主な機能 コンテナ

スレッド

メッセージを共通のスレッドとしてグループ化することができます。デフォルトではReferencesヘッダー項目によりメッセージをスレッド化します。Referencesヘッダーが存在しない場合、件名を使用します。

デフォルトを変更するには、提供サービスまたは個々のアカウントの zimbraMailThreadingAlgorithm を編集します。 詳細は スレッドのデフォルト値を変更する を参照してください。

この機能が有効なとき、スレッド表示はデフォルトのビューです。提供サービスのプレファレンスでデフォルトビューを変更できます。ユーザーからもデフォルト変更が可能です。

管理コンソールの参照先: 提供サービス名 > 機能 → メールの機能 コンテナ

HTML 作成

メッセージを作成する際に、HTMLの編集機能を利用できます。また、デフォルトのフォント設定をプリファレンスとして指定できます。

管理コンソールの参照先: 提供サービス名 > プリファレンス → メールを作成 コンテナ

下書きとして自動保存する間隔

下書きを自動保存する頻度。デフォルトでは30秒ごとに自動保存されます。ユーザーはこの頻度を変更できませんが、下書き自動保存機能を無効化することはできます。

管理コンソールの参照先: 提供サービス名 > プリファレンス → メールを作成 コンテナ

後でメールを送信

有効なとき、ユーザーは後からメッセージ送信する 後で送信 オプションを選択できます。ユーザーは送信する日時を設定できます。メッセージは下書きフォルダに保存されます。

管理コンソールの参照先: 提供サービス名 > 機能 → メールの機能 コンテナ

メッセージの優先度

有効なとき、ユーザーはメッセージの優先度を設定できます。受信者は、メッセージの優先度を表す高低フラグをZWCから確認できます。

管理コンソールの参照先: 提供サービス名 > 機能 → メールの機能 コンテナ

添付ファイルのインデックス作成を有効にする

添付ファイルがインデックスされます。インデックスされた添付ファイルは検索対象にできます。

管理コンソールの参照先: 提供サービス名 > 詳細設定 → 添付ファイル設定 コンテナ

任意のアドレスへのメール転送を許可

システム管理者は、ユーザーの利用できるデフォルトでの転送先アドレスを指定できます。ユーザーは、アカウントのプリファレンスタブから、この転送先アドレスを変更できます。

ユーザーに表示されない転送先アドレスも指定することができます。アカウントに送信されるメッセージのコピーは、指定された転送先アドレスに即座に転送されます。

管理コンソールの参照先: 提供サービス名 > 機能 → メールの機能 コンテナ

不在メッセージ

ユーザーは、受け取ったメッセージに対して自動返信するメッセージを作成できます。送信者が送信したメッセージの数にかかわらず、デフォルトでは7日間に1度だけ各送信者に自動返信を行います。この設定は、提供サービスのプリファレンスページにある 社内不在時のキャッシュ有効期間 から変更できます。

管理コンソールの参照先: 提供サービス名 > 機能 → メールの機能 コンテナ

新着メール通知用のアドレスを有効にする

ユーザーは、新着メッセージを知らせるアドレスを指定することができます。ユーザーはアカウントのプリファレンスからこの機能を有効・無効にしたり、アドレスを指定したりできます。

通知メッセージのテンプレート例の変更は 通知メールのテンプレートを カスタマイズ を参照してください。

管理コンソールの参照先: 提供サービス名 > 機能 → メールの機能 コンテナ

ペルソナ

有効なとき、別のルールを管理するアカウント名を追加作成できます。そのペルソナアカウントから送信するメッセージの差出人名にアカウントのエイリアスを選択したり、そのペルソナアカウント用の署名を設定したりできます。要件に応じて、作成できるペルソナ数を設定できます。最小値は0で、デフォルトは20です(zimbraIdentityMaxNumEntries)。

管理コンソールの参照先: 提供サービス名 > 機能 → メールの機能 コンテナ

メール署名の最大長

1つの署名内に使用できる最大文字数です。デフォルトは2014文字です。

ユーザーが作成できる署名の数は zimbraSignatureMaxNumEntries 内に設定されています。

管理コンソールの参照先: 提供サービス名 > プリファレンス → メールを作成 コンテナ

高度な検索

ユーザーは、日時、ドメイン、ステータス、タグ、サイズ、添付ファイル、Zimlet、フォルダによる、複雑な検索条件を作成することができます。

管理コンソールの参照先: 提供サービス名 > 機能 → 検索の機能 コンテナ

保存済み検索

ユーザーは、作成または実行していた検索条件を保存できます。

管理コンソールの参照先: 提供サービス名 > 機能 → 検索の機能 コンテナ

初回メール検索

有効なとき、デフォルトの検索メールボックスを変更できます。

管理コンソールの参照先: 提供サービス名 > 機能 → 全般的な機能 コンテナ

外部POPアクセス

有効なとき、ユーザーは、ZWCアカウントから直接、自身のPOPアカウントのメールメッセージを取得できます。ユーザーは、アカウント設定に、外部アカウントアドレスを追加します。

管理コンソールの参照先: 提供サービス名 > 機能 → メールの機能 コンテナ

外部IMAPアクセス

有効なとき、ユーザーは、ZWCアカウントから直接、自身のIMAPアカウントのメールメッセージを取得できます。ユーザーは、アカウント設定に、外部アカウントアドレスを追加します。

管理コンソールの参照先: 提供サービス名 > 機能 → メールの機能 コンテナ

アカウントのエイリアス

システム管理者は、アカウントのエイリアスを作成できます。ユーザーはこの変更ができません。

メールフィルター

ユーザーは、送受信メッセージとカレンダー予約に適用するルールや該当のアクションを定義できます。受信メールメッセージがフィルタールールの条件に合う場合、そのルールに紐づく該当のアクションが行なわれます。

受信メッセージへの迷惑メールチェックが実行完了した後に、ユーザーのメールフィルターが実行されます。 迷惑メールとして判断されたメッセージは迷惑メールフォルダに移されます。迷惑メールチェック中に誤って迷惑メールとして判断されないように、ユーザーは、プリファレンスメールフォルダから迷惑メールホワイトリストを作成して、これを防ぐことができます。 管理コンソールの参照先: 提供サービス名 > 機能 → メールの機能 コンテナ

フラグ付け

ユーザーは、フラグを作成して、メッセージや連絡先、ブリーフケースフォルダ内のファイルにそれを指定することができます。

管理コンソールの参照先: 提供サービス名 > 機能 → メールの機能 コンテナ

キーボードショートカットを有効にする

メールボックス内でキーボードのショートカットを利用できます。 プリファレンスのショートカットフォルダから、使用できるショートカット一覧を確認できます。

管理コンソールの参照先: 提供サービス名 > プリファレンス → 全般オプション コンテナ

グローバルアドレスリストアクセス

ユーザーはメールメッセージに使う名称を検索するために会社のディレクトリにアクセスできます。

管理コンソールの参照先: 提供サービス名 > 機能 → 全般的な機能 コンテナ

GALのオートコンプリート

有効なとき、ユーザーがメール作成時にヘッダー何文字か入力すると、GALに存在する名称が利用ランクに応じて表示されます。詳細は オートコンプリートで表示する名前のランク を参照してください。

管理コンソールの参照先: 提供サービス名 > 機能 → 全般的な機能 コンテナ

アドバンスド(AJAX)クライアントによるオフラインのサポート

有効なとき、Zimbraウェブクライアントを使用中のユーザーは、ネットワークに接続せずに、オフラインモードを利用したデータアクセスが可能です。詳細は「製品の概略」章のオフラインモードを参照してください。

管理コンソールの参照先: 提供サービス名 > 機能 → 全般的な機能 コンテナ

IMAP アクセス

IMAPプロトコルを使用中のユーザーは、サードパーティのアプリケーションを利用してメールボックスにアクセスできます。

提供サービスや各アカウントの 詳細設定 ページにある データソース > IMAP のポーリング間隔セクションからポーリング間隔を設定できます。デフォルトでは、ポーリング間隔は設定されていません。

管理コンソールの参照先: 提供サービス名 > 機能 → メールの機能 コンテナ

POP3 アクセス

POPプロトコルを使用中のユーザーは、サードパーティのアプリケーションを利用してメールボックスにアクセスできます。POPメールメッセージを取得するとき、メッセージと添付ファイルはZimbraサーバーに保存されます。
ユーザーの プリファレンス > メール にて、

  • メッセージダウンロード方法

  • ごみメールを含めるか否か。ごみメッセージは、受信箱にダウンロードされます。

  • POPアカウントメッセージの削除方法

提供サービスや各アカウントの 詳細設定 ページにある データソース > POP3 のポーリング間隔セクションからポーリング間隔を設定できます。デフォルトでは、ポーリング間隔は設定されていません。

管理コンソールの参照先: 提供サービス名 > 機能 → メールの機能 コンテナ

オートコンプリートで表示する名前のランク

オートコンプリートの機能は、呼ばれた頻度の最も高い名称を上から順にリストアップします。ユーザーは、上位にリストアップ表示させたくない連絡先については 無視 をクリックすることで、連絡先名称をランク付けし直すことができます。

ユーザーが管理するメールプリファレンス

本項で説明するほとんどのプリファレンスのデフォルト動作は、管理コンソールの提供サービスまたは各アカウントのプリファレンスから設定できます。ユーザーは、アカウントのプリファレンスメールページから、下記のメールプリファレンスを修正すること ができます。

  • ウェブクライアントが新着メッセージをチェックする分単位の頻度。

  • メールメッセージの警告通知を設定・変更します。警告方法として、音を鳴らす、メール新着にタブをハイライトさせる、ブラウザをフラッシュする、からセットアップできます。

  • Zimbra Collaborationの使用言語を設定します。ZCSに複数のロケールがインストールされている場合、ブラウザの言語とは異なるロケールを選択することができます。

  • 送信メッセージのコピーを送信済みフォルダに保存するか否か。

  • 転送メッセージのコピーを保存するかメールボックスから削除するか。

  • メッセージの新規作成を別ウィンドウで行なうか否か。

  • HTMLを含むメッセージをHTMLで表示するかプレインテキストで表示するか。

  • 必要時に閲覧済み確認を送信するか否か。

  • 出力されるメッセージのフォントサイズを変更します。デフォルトは12ptです。

  • ユーザーは、プリファレンスメールフォルダから、受信メッセージのフィルタリングに使用するホワイトリストとブラックリストの独自の迷惑メールオプションをセットアップできます。各リストのデフォルトの最大アドレス数はそれぞれ100です。この値は、提供サービスや各アカウントごとに、コマンドラインの zmprov を使用して変更可能です。 属性は、zimbraMailWhitelistMaxNumEntrieszimbraMailBlacklistMaxNumEntries です。

  • ユーザーは、 プリファレンス署名 ページから、次のメールプリファレンスを修正できます。

    • 送信メッセージに自動署名を付けるか否か。

    • 返信するメッセージや転送するメッセージの作成方法のプリファレンス。

インポートやエクスポートを使用したユーザーデータの保存

ユーザーは、プリファレンスインポート/エクスポート ページから、メールメッセージ、連絡先、カレンダー、タスクを含むすべてのアカウントデータをエクスポートできます。アカウント内の特定のアイテムをエクスポートして、パソコン内や他の場所にそのデータを保存することができます。

アカウントデータは、アカウントの復元のためにインポート可能なtar-gzip (tgz)のアーカイブファイルとして保存されます。連絡先は .csvファイルとして保存され、カレンダーの予定は .icsファイルとして保存されます。コピーされたデータでもアカウントからは削除されません。

エクスポートしたアカウントデータファイルは、WinRARなどのアーカイブ処理ソフトを使用して、閲覧できます。同ページからすべてのファイルがアカウントにインポートできます。

インポート/エクスポートの機能を 提供サービス や各 アカウント機能 ページから、無効にすることができます。

RSSのポーリング間隔の設定

ユーザーは、RSSの提供とフィードの公開をしているウェブサイトを定期的に読み込んだり、その更新情報を直接メールボックスに受信したりできます。フィードは最大50個返されます。なお、RSSフィードで受信したデータ量は、ユーザーのアカウント容量にカウントされます。

デフォルトは、RSSデータの12時間毎の更新です。ユーザーは、RSSフィードフォルダを右クリックして、新しいフィードをマニュアル操作で更新できます。

RSSのポーリング間隔は、管理コンソールの提供サービスまたは各アカウントの 詳細設定 ページにある データソース > RSSのポーリング間隔 から変更できます。

連絡先リスト機能

Zimbraの連絡先リストでユーザーは、連絡先リストを複数作成したり、メール送受信時、自動で連絡先の名称を追加することができます。連絡先を連絡先リストにインポートすることができます。

ユーザーがメールフォルダ、連絡先リスト、カレンダー予定を共有するには、全般的な機能設定コンテナにある 共有 を有効にする必要があります。

ホーム > 設定 > 提供サービス → 提供サービス名 → 機能 → 全般的な機能設定

Table 38. 連絡先リストの機能
機能名 説明 提供サービス/アカウントタブ

連絡先

ユーザーはパーソナルな連絡先リストが作成できます。デフォルトで、連絡先リストとメッセージ送信済み連絡先リストが作成されます。

機能

フォルダの最大許容連絡先数

全連絡先リストに入れられる連絡先の最大数です、0は無制限を表します。

詳細設定

ユーザーは自身のアカウントの プリファレンス連絡先ページ から連絡先リストのプリファレンスを修正できます。

デフォルト動作の設定

管理コンソール:

ホーム > 設定 > 提供サービス → 提供サービス名 → プリファレンス
ホーム > 管理 > アカウント → アカウント名 → プリファレンス

  • 連絡先の自動追加を有効にする: 新たなアドレスへのメッセージ送信時、送信済みリストにその連絡先が自動追加されます。

  • 連絡先を選択する場合、グローバルアクセスリストを使用する。

  • アドレスをオートコンプリートするときにGALを使用: 宛先などの入力時、GALのアドレスや名前もオートコンプリート対象として検索します。

カレンダー機能

Zimbraカレンダーでユーザーは、予定や会議のスケジューリング、繰り返しイベントの登録、複数カレンダーの作成、他ユーザーとのカレンダー共有、委任された管理者による自身のカレンダーへのアクセスを行なうことができます。外部カレンダーの定期的な読み込みとZimbraウェブクライアントからのカレンダー情報の閲覧ができます。カレンダーにある予定を検索することもできます。

ユーザーがカレンダー、連絡先リスト、ブリーフケースのファイルを共有するには、全般的な機能設定コンテナにある 共有 を有効にする必要があります。

管理コンソール:

ホーム > 設定 > 提供サービス → 提供サービス名 → 機能 → 全般的な機能

Table 39. カレンダー機能
カレンダー機能 説明 提供サービス/アカウントタブ

カレンダー

ユーザーは、カレンダーの維持、会議のスケジューリング、自身のカレンダーへのアクセスの委任、複数のパーソナルカレンダーの作成、などが可能です。

機能

グループカレンダー

グループカレンダーが無効の場合、個人的な予定の作成と会議への参加承諾だけが可能です。参加者、スケジュール、リソース検索タブは表示されません。

機能

ネストされたカレンダー

メール、連絡先、カレンダーフォルダと同様、カレンダーをZCSのフォルダ内にネストすることができます。管理者はCLIを利用してネストされたカレンダーリストを作成できます。移行時、ネストされたカレンダーグルーピングをインポートすることができます。 下記例を参照してください。

タイムゾーン

カレンダーのスケジューリングに使用するタイムゾーンを設定します。ドメイン管理者は、管理コンソールのアカウントにある全般情報ページでこの設定をします。

プリファレンス

以下のアドレスにカレンダー招待を転送

ユーザーのカレンダー招待の転送先アドレスを指定できます。ユーザーも、プリファレンスカレンダーフォルダーから、転送先アドレスを指定することができます。
招待が転送されるアカウントからその招待に返信するには、共有カレンダーに対する管理権限が必要です。

各アカウントの転送設定

<カレンダー名>フォルダ配下に、新たなカレンダーを作成します。

zmmailbox -z -m user1 cf -V appointment "/カレンダー名/サブカレンダー名"

カレンダーの予定に関する問題のトラブルシューティング

zmcalchk コマンドを使用して、同じ会議について、複数ユーザーのカレンダー同士をチェックし、矛盾があればメッセージを通知します。

予定が一致していないときにもこのコマンドを使用して、予定の所有者や全参加者に通知することができます。

リモートカレンダーの更新間隔の変更

リモートカレンダーはデフォルトで12時間ごとに更新されます。この頻度は管理コンソールから修正できます。

管理コンソールからカレンダーの更新間隔を修正するには、提供サービスや各アカウントの 詳細設定 ページから、データソース > カレンダーのポーリング間隔 項目に遷移します。

参加者による予定編集の無効化

参加者が自身のカレンダー予定に対して行なった変更は、他のユーザーには共有されません。予定の所有者が変更した場合、その変更によって、編集後の参加者の予定が上書きされます。システム管理者は、提供サービスの属性 zimbraPrefCalendarApptAllowAtendeeEdit を変更して、参加者が本人のカレンダー予定を編集できないようにできます。

zmprov mc <cosname> zimbraPrefCalendarApptAllowAtendeeEdit FALSE

その他のカレンダーのプリファレンスを設定

ユーザーはカレンダープリファレンス表のカレンダープリファレンスを修正できます。デフォルト動作は提供サービスやアカウントのプリファレンスページで設定可能です。

カレンダープリファレンス 説明

タイムゾーン

ユーザーのプリファレンスに表示されるタイムゾーン。詳細は デフォルトのタイムゾーンを設定するを参照してください。提供サービスでタイムゾーンを設定した場合、ドメインに設定したタイムゾーンは無視されます。

予定のリマインダーを表示する時間(分)

会議前にリマインダーを通知を送信する時間を分単位で設定します。

最初のカレンダービュー

デフォルトのビューを設定します。日、週、週平日、月、予定、リストで設定可能です。

週の最初の曜日

仕事を開始する曜日を設定します。

デフォルトの予定表示

パブリックかプライベートかの設定ができます。新規予定ページでのデフォルト表示オプションです。

デフォルト設定はパブリック、予定の詳細は他のユーザーから閲覧可能です。

デフォルトがプライベートのとき、全ての受信カレンダー招待がプライベートとしてユーザーのカレンダーにマークされ、詳細は非表示とされます。

CalDAVインターフェイス用に共有カレンダーのiCal委任モデルを使用

CalDAVのプロトコルを使用して、Apple iCalをユーザーのカレンダーにアクセスするように設定できます。有効なとき、共有カレンダーがユーザーのiCalアカウントの委任タブに表示されるため、ユーザーはカレンダーへのアクセスを委任することができます。

自動ポーリングについては、提供サービスまたは各アカウントの 詳細設定 ページ内の データソース > CalDAVのポーリング間隔 項目からポーリング間隔を設定できます。

期限切れリマインダーを有効にする

ユーザーがZWCへログインすると、過去2週間分の削除されていないリマインダーがポップアップで表示されます。無効のとき、Zimbra Collaborationは古いリマインダーを自動削除します。

新着カレンダーイベントのためのToaster通知を有効にする

新しいカレンダーイベントの受信時、ZWCにポップアップを表示します。

キャンセルメールを作成者に送信することを許可

ユーザーが予定日時に参加できない予定に招待された時、 新しい時間を提案 のボタンをクリックし、別の日時を選択・提案できます。予定の所有者は、その提案日時をメールで受け取ります。

PUBLISHメソッドを使って招待を自動追加

カレンダー招待メールは、そのカレンダーオブジェクト内に method=REQUEST を含んでいなければなりませんが、なかには誤って method=PUBLISH を使用しているサードパーティ製メールクライアントもあります。 こうしたメールはデフォルトでは処理されません。このオプションを有効にし、ルールを緩めることができます。

転送された招待をカレンダーに自動追加

ユーザーに転送された招待が、転送受信者のカレンダーに自動追加されます。

予定のリマインダー時にブラウザのタイトルを点滅

予定のリマインダーがポップアップすると、ユーザーがそのポップアップを閉じるまでブラウザが点滅します。

可聴予定通知を有効にする

予定のリマインダーがポップアップすると、ユーザーはコンピュータが鳴らす音で気づかされます。ユーザーは、QuickTimeまたはWindows Mediaをインストールしている必要があります。

招待を拒否されたユーザーからの招待を自動拒否

ユーザーは、カレンダーの招待を送ってくる相手を設定することができます。有効なとき、ユーザーを招待する権限のない者に対しては、それを知らせる自動返信メッセージが送られます。

招待時に予定を自動追加

有効なとき、ユーザーのデフォルトカレンダーに予定が自動追加され、拒否した予定はZWCのカレンダーにグレーアウトされて表示されます。

モバイルデバイスから予定を閲覧した場合、拒否した予定がグレーアウトで表示されないため、その招待が削除されたことが分からない可能性ががあります。

委任アクセスを通じて行われた変更を通知

カレンダーへのアクセスを委任しているユーザーには、予定が委任アクセス権限で変更されたことが通知されます。

常にミニカレンダーを表示

カレンダーのビューにミニカレンダーが自動表示されます。

新しい予定を作成するときに簡易追加ダイアログを使用

有効なとき、カレンダー上でのダブルクリックまたはドラッグ時、簡易追加ダイアログが表示されます。

予定ビューにタイムゾーンリストを表示

有効なとき、タイムゾーンのリストが予定ダイアログに表示されるため、使用するタイムゾーンを予定作成中に変更することができます。

Zimbraのタスクのセットアップ

Zimbraのタスクでユーザーは、タスクのToDoリストを作成して、完了までの管理ができます。

ユーザーによるタスクリストの共有には、機能ページで 共有 を有効にする必要があります。タスクリストの共有は、個人、グループ、パブリックに対して実施可能です。

タスクの機能の有効化/無効化

 管理コンソール:

ホーム > 設定 > 提供サービス → 提供サービス名 → 機能
ホーム > 管理 > アカウント → アカウント名 → 機能

ZimbraのウェブクライアントのUIテーマ

ZimbraウェブクライアントのUIの見え方を変更できます。ZCSにはZimbraテーマが多数備わっており、また、他にもユーザーがテーマを作成できます。システム管理者は、デフォルトとするテーマの設定や、ユーザーが使い勝手を良くするためのカスタマイズで選択できるテーマの指定ができます。テーマ開発の詳細は、 テーマ色やロゴ管理 を参照してください。

次のテーマを使用する際のオプションは、提供サービスまたは各アカウントから設定できます。

  • ユーザーを特定のテーマに限定する

    機能のページで UIテーマを変更 のチェックを外します。ZWCのテーマは、テーマページの 現在のUIテーマ にリストアップされているテーマのみです。

  • ユーザーはZimbraにインストールしたテーマを自由に設定する

    UIテーマを変更 が有効なとき、ユーザーは、使用できるテーマのリストのどのテーマへもアクセスできます。

2要素認証

2要素認証(2FA)機能によって、システム内の特定のユーザー、全ユーザー、特定のメールボックス、あるいは全ての重要なメールボックスに適用しうる、セキュリティの二次要件を設定することができます。2FAは、ユーザーアカウントや提供サービスに設定できます。

新しいユーザーアカウントの2FA

新しいアカウントのセットアップ画面には、他の 詳細設定 に並んで2FAの設定があります。

管理コンソール:

ホーム → 3 アカウントの追加 → 1. アカウントの追加
 — 次へ詳細設定 まで進み、2要素認証 までスクロールダウンします。

New Account Two Factor Authentication

パラメーターに関する説明は、 2要素認証パラメーター を参照してください。

既存のユーザーアカウントの2FA

既存アカウントの場合、詳細設定 オプションから2FAを適用できます。

管理コンソール:

ホーム > 管理 > アカウント

次の手順で、アカウントの設定にある 2要素認証 コンテナに編集モードで遷移します。

  1. アカウント一覧から アカウント名 を選択します。

  2. 画面右上 ギア アイコンから 編集 を選択します。

     —  このアカウントの 全般情報 が表示されている状態になります。

  3. 画面の左パネルから 詳細設定 を選択します。

  4. 画面中央にある 2要素認証 コンテナまでスクロールダウンします。

Edit Account Two Factor Authentication

パラメーターに関する説明は、 2要素認証パラメーター を参照してください。

提供サービスの2FA

提供サービスの2FA設定に使用できるパラメーターは、他の詳細設定機能と同じところにあります。

提供サービスに2FAを適用するには、パラメーターを設定する 2要素認証 コンテナを使用します。

管理コンソール:

ホーム > 設定 > 提供サービス → 提供サービス名 → 詳細設定 → 2要素認証

Class of Service Two Factor Authentication

パラメーターに関する説明は、 2要素認証パラメーター を参照してください。

Table 40. 2要素認証パラメーター
パラメーター 説明

2要素認証を有効にする

選択したCOSアカウントに対する本機能の有効(チェック有り)または無効(チェック外し)を設定します。

2段階認証が必要

選択したCOSアカウントに対して、本機能の利用を必須とするなら有効(チェック入り)に、それ以外は無効(チェックなし)にします。

生成するワンタイムコードの数

アカウントがシステムへのアクセスを試行する時に表示/入力されうる、最大6桁まで指定されるパスコードの値。初回ログイン認証が通ったアカウントには、パスコードが存在します。

各パスコードの寿命は15秒です。

アプリケーションパスコードを有効にする

2要素認証をサポートしていない古いアプリケーションには、例外的なコードを生成できます。

その他のアカウント設定

共有を有効にする

共有機能が有効なとき、ユーザーは、メールメッセージ、カレンダー、連絡先リスト、タスクリスト、ブリーフケースを含む、すべてのフォルダを共有できます。

ユーザーは、与えるアクセスの権限をタイプで指定します。ユーザーは、完全な管理者アクセスのある内部ユーザーや、フォルダ内容の閲覧にパスワードを要する外部ユーザーとの共有が、フォルダ内容が閲覧できるURLがあれば誰でもアクセスできる公開アクセスと同様に、実施できます。

内部ユーザーがメールフォルダを共有したとき、共有フォルダのコピーが共有相手の概要ペインにあるフォルダリストに追加されます。ユーザーは、ZWCのプリファレンス共有ページから、自身の共有フォルダを管理できます。

SMSでの通知設定

ZWCの プリファレンス→通知 ページでユーザーは、タスクやカレンダーにある予定のリマインダーをモバイルデバイスで受け取るように、メールアドレスやSMSへの通知を設定することができます。SMSでの通知は、デフォルトでは無効です。

SMSでの通知は、ドメイン、提供サービス、各アカウントごとに設定できます。提供サービスで設定したSMS通知は、ドメインでの設定にオーバーライドします。管理コンソールでは、ドメイン、提供サービス、各アカウントにある機能ページで設定します。

SMS通知のセットアップ時、ユーザーは、地域とキャリアを選択します。SMS/メールのゲートウェイのリストは ZmSMS.properties に入っています。このリストをカスタマイズして、リストにないSMS/メールのゲートウェイを追加できます。

添付ファイルの閲覧設定

添付ファイルの閲覧ルールは、グローバル設定、提供サービスの設定、特定のアカウントの設定として、設定できます。グローバル設定は、提供サービスやアカウントの設定にオーバーライドします。以下の4つのオプションが使用できます。

Table 41. 添付ファイルの閲覧機能
機能名 説明 提供サービス/アカウントタブ

ウェブメールで添付ファイルを表示させない

添付ファイルを閲覧できません。これはグローバル設定でも適用可能です。

詳細設定

HTML形式でのみ表示可能

受信した添付ファイルの形式を問わず、HTML形式として開きます。

詳細設定

元の形式でのみ表示可能

コンピュータに登録されていない専用のアプリケーションを必要とする添付ファイルの場合、開けないことがあります。

詳細設定

HTML形式あるいは元の形式で表示可能

ユーザーは、添付ファイルを元の形式で開くか、HTML形式で開くかを選択できます。

詳細設定

ユーザーが外部サイトへ移るときに警告メッセージを表示する

ユーザーは、アカウントからログアウトする前に、ブラウザにある戻る矢印や進む矢印、ブラウザを閉じる、をクリックすることができます。

  • このプリファレンスが有効な場合、ユーザーがアカウントから外部へ移るときに確認プロンプトが表示されます。

  • このプリファレンスが無効な場合、確認プロンプトは表示されません。

ウェブクライアントのチェックボックスを有効にする

バッチ操作用のリストビューにメール、連絡先、ボイスメールの項目を選択するためのチェックボックス表示 が有効な場合、ユーザーがコンテンツペインにあるメッセージ、連絡先、タスクリストを閲覧するときに、各アイテムにチェックボックスが追加されます。ユーザーは、アイテムを選択したのち、選択したその全アイテムに一括でアクションを実行することができます。アクションとは例えば、既読/未読、特定のフォルダへの移動、フォルダへのドラッグ&ドロップ、削除、タグを付ける、などです。

プリファレンスのインポート/エクスポート

ユーザーはプリファレンスの「インポート/エクスポート」ページから、メールメッセージ、連絡先、カレンダー、タスク、ブリーフケースフォルダを含むすべてのアカウントデータをエクスポートできます。アカウント内の特定のアイテムをエクスポートして、パソコン内や他の場所にそのデータを保存できます。アカウントデータは、アカウントの復元のためにインポート可能なtar-gzip (tgz)のアーカイブファイルとして保存されます。連絡先は .csvファイルとして保存され、カレンダーの予定は .icsファイルとして保存されます。コピーされたデータでもアカウントからは削除されません。エクスポートしたアカウントデータファイルは、WinRARなどのアーカイブ処理ソフトを使用して、閲覧できます。同ページからすべてのファイルがアカウントにインポートできます。

ユーザーに「インポート/エクスポート」の機能を使用させたくない場合、提供サービスや各アカウントの機能ページから、無効にすることができます。

スペルチェック辞書への単語登録

ZWCユーザーが、ZWCのスペルチェック中にスペルエラーとしてマークされる単語や略語を頻繁に使用している場合、システム管理者は、提供サービスやドメインの属性 zimbraPrefSpellIgnoreWord に、スペルチェック時に対象外とする単語を追加更新できます。

ドメインに対象外とする単語を設定

zmprov md example.com +zimbraPrefSpellIgnoreWord <word> +zimbraPrefSpellIgnoreWord <word2>

Zimbra の階層制度アドレス帳 (Hierarchical Address Book、HAB)

HAB について

階層制度のアドレス帳 (HAB) ではユーザー様がアドレス帳に部署の単位で宛先を検索することが可能となります。ほとんどの場合、ユーザー様はデフォルトのグローバルアドレス帳(GAL)のデフォルト単位のみをアクセスできますので、部署の詳細、同じ名前の人の区別、などを簡単に特定できない状況です。HABを実際のビジネス単位へカスタマイズすることで、ユーザー様に内部の宛先をより効率的に検索することが可能となります。

階層制度アドレス帳の運用について

階層制度アドレス帳 (HAB) では、ルート会社(例えば Zimbra)がトップレベルとなります。そのトップレベルの下に複数の子レベルを追加し、異なる部署や課、などを自由に指定することができます。以下の図では、以下の仕様の Zimbra 用の HAB の事例を紹介しています。

  • トップレベルはルート会社を示している、つまり Zimbra です。

  • 子レベルに Zimbra の異なるビジネス課を示している、つまり管理課, エンジニア課, カスタマーサポート課, および営業部です。

  • さらなる子レベルに各管理課, エンジニア課, カスタマーサポート課, および営業部に別れている部署やチームを示しています。

HABHierarchy
Figure 1. 階層制度の事例

年功序列

年功序列 は階層制度にさらなるカスタマイズできるレベルとなります。HABを作成する際、このパラメータで特定のユーザーや部署を各レベル内で年功序列のランクを与えることが可能です。このランクでは、HABが表示する宛先の人物やグループの順番を指定されます。年功序列が高いほど、リストの順番が他のユーザーやグループの先に表示されます。例えば:

  • 副社長を 100

  • 本部のオペレーションマネジャーを 50

  • ビジネスの管理者を 25

年功序列 のパラメータが設定していない、またはほかのユーザーアカウントと一致している場合、HABの基準順番はアルファベット順となります。

階層制度アドレス帳の設定方法について

organizational unit (OU) を作成する

操作コマンド
zmprov createHABOrgUnit <OUのドメイン名> <OU名>
実例
zmprov createHABOrgUnit example.com ZimbraOU
詳細

ZimbraOU as an organizational unit created.

この OU にグループを作成する

各部署にグループを作成し、メールアドレスを関連させる必要があります。

操作コマンド
zmprov createHABGroup <グループ名> <OU名> <グループのメールアドレス>
実例

以下のコマンドでは、階層制度の事例 を参考し、8 の HAB グループを作成します。

zmprov createHABGroup Zimbra ZimbraOU zimbra@example.com
zmprov createHABGroup CorporateOffice ZimbraOU CorpOffice@example.com
zmprov createHABGroup Engineering ZimbraOU eng@example.com
zmprov createHABGroup ProdSupport ZimbraOU prodsupport@example.com
zmprov createHABGroup SalesAndMarketing ZimbraOU sales-mark@example.com
zmprov createHABGroup HumanResources ZimbraOU hr@example.com
zmprov createHABGroup Accounts ZimbraOU accounts@example.com
zmprov createHABGroup Administration ZimbraOU administration@example.com

階層制度を作成する

階層制度を作成するため、(Zimbra のグループ以外に)各グループ親のグループを関連する必要があります。

操作コマンド
zmprov addHABGroupMember ParentGroupEmailAddress ChildGroupEmailAddress
実例

以下のコマンドでは、階層制度の事例 の階層制度を参考し、Zimbra のグループがルートのグループであるため、7 の HAB グループに親グループを指定します。

以下では、Human Resources, Accounts, および Administration の親グループを Corporate Office に指定し、Corporate Office, Engineering, Product Support, および Sales & Marketing の親グループを Zimbra に指定します。

zmprov addHABGroupMember CorpOffice@example.com hr@example.com
zmprov addHABGroupMember CorpOffice@example.com accounts@example.com
zmprov addHABGroupMember CorpOffice@example.com administration@example.com
zmprov addHABGroupMember zimbra@example.com CorpOffice@example.com
zmprov addHABGroupMember zimbra@example.com eng@example.com
zmprov addHABGroupMember zimbra@example.com prodsupport@example.com
zmprov addHABGroupMember zimbra@example.com sales-mark@example.com

Zimbra ID を取得する

zimbraId は各メールアドレスに関連している一意的に指定されている認識IDです。このパラメータでは ユーザーをグループに閲覧すること および グループがルートとして指定する ことができます。

要注意:以下の事例、および他の事例にも、zimbraId を代表するために仮の値 (xxxxxxxx-xxxx-xxxx-xxxx-xxxxxxxxxxxx) を使用しています。

操作コマンド
zmprov gdl <グループのメールアドレス> zimbraId
実例
zmprov gdl zimbra@example.com zimbraId
実例の出力
# distributionList zimbra@example.com memberCount=4
zimbraId: xxxxxxxx-xxxx-xxxx-xxxx-xxxxxxxxxxxx
詳細

ルートのグループとして指定するグループのメールアドレスは_zimbra@example.com_ です。

グループへユーザーを追加する

以下の事例では、他のユーザーへ影響を与えずに CorporateOffice のグループへ Jane DoeJohn Smith のユーザーを追加します。

操作コマンド
zmprov addHABGroupMember <グループのメールアドレス> <ユーザーのメールアドレス>
実例
zmprov addHABGroupMember hr@example.com jane.doe@example.com
zmprov addHABGroupMember accounts@example.com john.smith@example.com

年功序列を設定する

HAB でグループが表示する順番を指定します。年功序列が高いグループが他のグループより先表示されます。

操作コマンド
zmprov modifyHABGroupSeniority <zimbra ID> <年功序列>
実例

グループ名とアルファベット順を問わず、Engineering のグループを CorporateOffice の上に表示させるため、 Zimbra ID を取得し、SeniorityIndexNumber に指定する年功序列の重要性を特定し、以下のコマンドを実行します。

CorporateOffice に年功序列を 90 に指定する

zmprov modifyHABGroupSeniority xxxxxxxx-xxxx-xxxx-xxxx-xxxxxxxxxxxx 90

Engineering に年功序列を 100 に指定する

zmprov modifyHABGroupSeniority xxxxxxxx-xxxx-xxxx-xxxx-xxxxxxxxxxxx 100

要注意:グループに年功序列を指定しますと、そのグループにあるユーザーにも 年功序列 が設定されます。

HAB のルート会社を指定する

階層制度を作成するために1つのグループをルートのグループとして指定し、他のグループがそのグループの子グループとして指定する必要があります。なお、以下のコマンドでは、 zimbra@example.com をルートとして指定します。

操作コマンド
zmprov md <ドメイン名> zimbraHierarchicalAddressBookRoot <ルートとして指定するグループの ZimbraID>
実例
zmprov md 'example.com' zimbraHierarchicalAddressBookRoot xxxxxxxx-xxxx-xxxx-xxxx-xxxxxxxxxxxx
実例の出力
# distributionList zimbra@example.com memberCount=4
zimbraId: xxxxxxxx-xxxx-xxxx-xxxx-xxxxxxxxxxxx

正常に設定されたことを確認する方法

  1. Zimbra のウェブクライアントへログインします。

  2. 新しいメッセージ をクリックします。

  3. メールの 作成 ウィンドウにて、宛先 のボタンをクリックします。

  4. アドレスを選択 のウインドウにて、右上から 名前の表示元 ドロップダウンメニューをクリックします。

  5. 階層制度アドレス帳 を選択します。

  6. 左側のリストに階層制度アドレス帳が表示されます。

    HABStructure zimbra
  7. グループをクリックしますと、そのグループにあるユーザーを閲覧し、メールの宛先として選択することが可能です。

ユーザーアカウントのプロビジョニング

アカウントがプロビジョニングされると、システム管理者はメールボックスを作成し、当初のメールアドレスを設定し、Zimbra Collaborationのアプリケーションおよび機能を使用するために提供サービスを適用します。

アカウントを1つずつ設定することも、別サーバーから複数の既存アカウントを移行することもできます。

ユーザーアカウントを作成する

ユーザーアカウントを追加する前に、使用する機能やアクセス権限を決める必要があります。対象の機能を持つ提供サービスをアカウント作成時に設定することも可能ですし、機能をアカウントに個別設定することも可能です。詳細は アカウントの提供サービスについて を参照してください。

アカウントへ設定した提供サービスに適切な機能が備わっている場合、アカウントに個別設定を追加で行なう必要はありません。 アカウントを作成するとZimbraのLDAPサーバーに適切な情報が設定されます。ユーザーが最初にログインしたとき、あるいはユーザーアカウント宛にメッセージが配信されたとき、メールボックスサーバー上にそのメールボックスが作成されます。

標準のアカウントを作成します。

管理コンソール:

ホーム → 3 アカウントの追加 → 1. アカウントを追加

  1. アカウント名 セクションにて、必要最低限の情報であるアカウント名と姓を入力します。

    デフォルト提供サービスが自動適用されます。

  2. 完了 をクリックし、アカウントを作成します。

続けて、個々のアカウントの特性や機能を設定することができます。アカウントに対する変更内容は提供サービスにオーバーライドします。

既存のアカウントの移行およびアカウントメールのインポート

Zimbra 管理コンソールのUI上での ZCS アカウント移行がサポート終了しており、2019年12月17日までテクニカルガイダンス期間となります。 なお、すべてのアカウント移行の代替案として、https://zimbra.audriga.com/[audriga社の移行ソリューション] の利用を推奨しております。

管理コンソールからアカウント移行用ウィザードを使用して、一度に複数のアカウントをプロビジョニングすることができます。一般IMAPサーバーや別のZCS サーバーからアカウントをインポートできます。

7.2以降のZCSに存在するアカウントのみZCS 8へ移行できます。

また、カスタム作成したXMLファイルからプロビジョニング対象のアカウント名をインポートすることも可能です。

移行用ウィザードで、アカウントのプロビジョニングとデータのインポートを一度に実行できます。または、1回目のウィザードでアカウントのプロビジョニング、2回目でそのアカウントにデータをインポートできます。

既存のLDAPディレクトリやXMLファイルからアカウントレコードを取得する場合、新たに作成するアカウント用パスワードの要件を設定しておく必要があります。選択肢には、アカウントごとにランダムなパスワードを自動生成する方法と全アカウントに同一パスワードを設定する方法があります。また、初回ログイン時にユーザーにパスワードを変更させることもできます。

プロビジョニングが完了すると、このウィザードが新規アカウント一覧の.csvファイルを作成します。このファイルに生成されたパスワードも含まれています。今後の参照用にダウンロードしておくことを推奨します。ただし、ファイルは安全な場所に格納してください。プロビジョニングしたアカウントのパスワード情報が含まれているからです。

スプリットされたドメイン環境を使用している場合、ウィザードにSMTPのホストとポートを設定できます。スプリットされたドメイン環境に関する詳細は以下のWiki記事を参照ください。 https://wiki.zimbra.com/wiki/Split_Domain

Zimbraサーバーからアカウントを移行する

ZCS 7.2.0以降に依存しているアカウントをZCS 8へ移行できます。

管理コンソール:

ホーム → 3 アカウントの追加 → 3. 移行と共存

  1. メールサーバーの種類 にて、 Zimbra Collaboration を選択します。

  2. アカウントをプロビジョニングしている場合、アカウントレコードをインポートしますかはい を選択します。メールのデータを今回インポートしない場合、メールをインポートしますかいいえ を選択します。

  3. 次へ をクリックします。

  4. 概要のページに 別のZimbra LDAPディレクトリからインポート が選択されていることを確認します。 次へ をクリックします。

  5. 一括提供オプション のページでパスワードをランダムに設定するか、固定のパスワードを設定するかを選択します。

    Table 42. 一括提供の機能
    一括提供の機能 説明

    各アカウントにランダムパスワードを生成

    ランダムパスワードの生成を選択した場合、パスワードの長さを設定する必要があります。パスワードは6から64文字まで設定可能です。

    デフォルトは8文字です。

    ランダムパスワードの生成を使用する場合、ユーザーへパスワードを伝えるためにアカウントとパスワードが発行される*.csvファイルをダウンロードする必要があります。

    すべての新規アカウントに同じパスワードを使用

    すべての新規アカウントに同様のパスワードを使用するを選択した場合、使用するパスワードを入力します。

    初回ログイン後にパスワードの変更をユーザーに要求

    ユーザーの初回ログイン時にパスワード変更を強制するようになるため、このオプションの使用を推奨します。

    SMTPホスト / SMTPポート

    スプリットのドメイン環境の場合、SMTPのホスト名とポートを指定します。

  6. 次へ をクリックします。

  7. ディレクトリ接続 のページでサーバーへ接続する情報を入力します。

    Table 43. ディレクトリ接続のオプション
    ないドメインを自動的に作成 詳細

    ないドメインを自動的に作成

    このオプションを有効にすると、アカウントのインポート時、アカウントのドメインが存在しない場合にドメインを作成します。

    このオプションを有効にしない場合、サーバーに存在しないドメインのアカウントは作成されません。無効にすると、事前に作成した特定のドメインのアカウントのみを簡単にインポートできます。

    取得する最大レコード数

    一度にインポートできる最大のアカウント数を指定します。基準は無制限 (0) となっています。

    サーバー名、LDAP URL、ポートおよびSSLを使用

    • LDAP URLは ldap://<ldapdirectory.example.com> の形で入力します。

    • デフォルトのポートは389ですが、変更できます。

    • SSLを使用している場合、チェックします。

    バインドDN

    Zimbraの設定はデフォルトで以下となります。 uid=zimbra,cn=admins,cn=zimbra

    バインドパスワード

    サーバーのパスワードを入力します。

    LDAPフィルター

    LDAP検索フィルターを指定します。インポートしたいアカウント情報の種類の検索条件を定義できます。デフォルトのフィルター (objectclass=zimbraAccount) では、メールアドレス、アカウントIDおよびアカウントの属性が含まれています。

    LDAP検索ベース

    LDAP全体に検索するサブセクションを指定します。

  8. 次へ をクリックします。

    アカウント移行のウィザード は指定したディレクトリサーバーへ接続し、確認したドメイン数、アカウント数、そしてZCS上で既に存在しているアカウント数を取得し、レポートとして表示します。また、指定したパスワードのオプションも表示します。

  9. 発行したレポートの確認後、次へ をクリックします。 アカウントは Zimbra Collaboration のサーバーにプロビジョニングされます。

  10. プロビジョニングされたアカウントとパスワードが記載されている.csvファイルをダウンロードします。なお、ウィザードを終了すると、発行した.csvファイルが自動的に削除されるため、再ダウンロードおよび再発行することができません。ご注意ください。

一般IMAPサーバーからアカウントを移行する

以下の手順にて、IMAPよりZimbraサーバーへアカウントをプロビジョニングできます。

管理コンソール:

ホーム → 3 アカウントの追加 → 3. 移行と共存

  1. メールサーバーの種類 にて、一般IMAPサーバー を選択します。

  2. アカウントをプロビジョニングしている場合、「アカウントレコードをインポートしますか」に はい を選択します。メールのデータを今回インポートしない場合、「メールをインポートしますか」に いいえ を選択します。

  3. 次へ をクリックします。

  4. 概要 のページで「別のZimbra LDAPディレクトリからインポート」が選択されていることを確認します。 次へ をクリックします。

  5. 一括提供オプション のページでパスワードをランダムに設定するか、固定のパスワードを設定するかを選択します。

    Table 44. 一括提供の機能
    一括提供の機能 説明

    各アカウントにランダムパスワードを生成

    ランダムパスワードの生成を選択した場合、パスワードの長さを設定する必要があります。パスワードは6から64文字まで設定可能です。

    デフォルトは8文字です。

    ランダムパスワードの生成を使用するを選択した場合、ユーザーへパスワードを伝えるためにアカウントとパスワードが発行される*.csvファイルをダウンロードする必要があります。

    すべての新規アカウントに同じパスワードを使用

    すべての新規アカウントに同様のパスワードを使用する場合、使用するパスワードを入力します。

    初回ログイン後にパスワードの変更をユーザーに要求

    ユーザーの初回ログイン時にパスワード変更を強制するようになるため、このオプションの使用を推奨します。

    SMTPホスト / SMTPポート

    スプリットされたドメイン環境の場合、SMTPのホスト名とポートを指定します。

  6. 次へ をクリックします。

  7. ディレクトリ接続 のページにサーバーへ接続する情報を入力します。

    Table 45. ディレクトリ接続のオプション
    ディレクトリ接続のオプション 説明

    ないドメインを自動的に作成

    このオプションを有効にすると、アカウントのインポート時、アカウントのドメインが存在しない場合にドメインを作成します。

    このオプションを有効にしない場合、サーバーに存在していないドメインのアカウントは作成されません。無効にすると、事前に作成した特定のドメインのアカウントのみを簡単にインポートできます。

    取得する最大レコード数

    一度にインポートできる最大のアカウント数を指定します。デフォルトは無制限 (0) となっています。

    サーバー名, LDAP URL, ポート, およびSSLを使用

    • LDAP URL は ldap://<ldapdirectory.example.com> The

    • デフォルトのポートは389ですが、変更できます。

    • SSLを使用している場合、チェックします。

    バインドDN

    サーバーのバインドDNを指定します。 uid=zimbra,cn=admins,cn=zimbra

    バインドパスワード

    サーバーのパスワードを入力します。

    LDAP フィルター

    LDAP検索フィルターを指定します。インポートしたいアカウントの情報の種類の検索条件を定義できます。デフォルトのフィルター (objectclass=zimbraAccount) では、メールアドレス、アカウントID、アカウント属性が含まれています。 フィルターを自由に変更できます。

    LDAP 検索ベース

    LDAP全体に検索するサブセクションを指定します。

  8. 次へ をクリックします。

    移行のウィザードは指定したディレクトリサーバーへ接続し、確認したドメイン数、アカウント数、そして ZCS上で既に存在しているアカウント数を取得し、レポートとして表示します。また、指定したパスワードのオプションも表示します。

  9. 発行したレポートの確認後、 次へ をクリックします。 アカウントはZimbra Collaborationのサーバーにプロビジョニングされます。

  10. プロビジョニングされたアカウントとパスワードが記載されている.csvファイルをダウンロードします。なお、ウィザードを終了すると、発行した.csvファイルが自動的に削除されますので、再ダウンロードおよび再発行することができません。ご注意ください。

XMLファイルからアカウントを移行する

インポートするアカウントの情報をXMLファイルに保存し、XMLファイルをZimbraへアップロードすることで、アカウントをプロビジョニングできます。

管理コンソール:

ホーム → 3 アカウントの追加 → 3. 移行と共存

  1. メールサーバーの種類 にて、元のサーバーの種類を選択します。

  2. アカウントをプロビジョニングしている場合、「アカウントレコードをインポートしますか」に はい を選択します。メールのデータを今回インポートしない場合、「メールをインポートしますか」に いいえ を選択します。

  3. 次へ をクリックします。

  4. 概要 のページに XMLファイルからインポート を選択し 次へ をクリックします。

  5. XMLファイルの横にある 参照 ボタンをクリックし、XMLファイルを選択します。次へ をクリックするとアップロードします。

  6. オプションを確認のページにて、XMLファイルに確認したドメイン数、アカウント数、そしてZCS上で既に依存しているアカウント数をレポートとして表示します。また、指定したパスワードのオプションも表示します。

  7. 内容に問題がない場合、次へ をクリックします。内容が正常ではない場合、XMLファイルを修正してから進みます。

    次へ をクリックした場合、XMLファイルに確認したアカウントはZimbra Collaborationサーバーへプロビジョニングされます。

  8. プロビジョニングされたアカウントとパスワードが記載している.csvファイルをダウンロードします。なお、ウィザードを終了すると、発行した.csvファイルが自動的に削除されますので、再ダウンロードおよび再発行することができません。ご注意ください。

特定のアカウントへメールをインポートする

メールのインポートをしたいアカウントリストを指定する場合、アカウントを選択するか、XMLファイルでアカウントを選択することで、指定できます。

この手順の作業を行なう前に、アカウントはZCS サーバー上にプロビジョニングされていなければなりません。
管理コンソール:

ホーム → 3 アカウントの追加 → 3. 移行と共存

  1. メールサーバーの種類 にて、元のサーバーの種類を選択します。

  2. アカウントレコードをインポートしますかいいえ を選択します。

  3. メールをインポートしますかはい を選択します。

  4. 次へ をクリックします。

  5. インポートのオプション のページで、メールをインポートするアカウントを指定する方法を選択します。

  6. 次へ をクリックします。

    インポートするアカウントを選択する場合、手順7へ進みます。 XMLファイルでアカウントを指定する場合、手順9へ進みます。

  7. インポートするアカウントを選択する場合、検索ボックスで追加するアカウントを検索します。ドメイン、またはユーザー名で検索できます。検索するテキストを入力せずに「検索」をクリックすると、すべてのアカウントが結果に表示されます。

    メールデータをインポートするアカウントを左から選択し、「追加」のボタンをクリックし、右の データインポートのためのアカウント リストへ移動します。

  8. 次へ をクリックします。

  9. XMLファイルでアカウントを指定する場合、「参照」より使用するXMLファイルを選択します。

  10. 次へ をクリックします。

  11. IMAP接続の詳細ページにて、エクスポートするサーバーのIMAPへ接続するための情報を記載します。IMAPのホスト名、ポートおよび管理者のログイン情報が必要となります。IMAPサーバーの情報入力を完了します。

  12. 次へ をクリックします。

  13. オプションの確認ページにて、データのインポート詳細を確認します。問題がない場合、次へ をクリックし、データのインポートを開始します。

XMLファイルの例

アカウントのプロビジョニングやデータのインポートで使用するXMLファイルの例を以下に紹介しています。XMLファイルを作成する際にご参照ください。

Example 7. アカウントのプロビジョニングにXMLファイルを使用する

メールデータをインポートせずに、複数のアカウントをプロビジョニングする場合、以下のようなXMLファイルを使用します。

<?xml version="1.0" encoding="UTF-8"?>
<ZCSImport>
<ImportUsers>
<User>
<sn>Sample</sn>
<givenName>Sam</givenName>
<displayName>Sam Sample</displayName>
<RemoteEmailAddress>ssample@example.com</RemoteEmailAddress>
<password>test123</password>
<zimbraPasswordMustChange>TRUE</zimbraPasswordMustChange>
</User>
<User>
<sn>Zackry</sn>
<givenName>Zak</givenName>
<displayName>Zak Zackry</displayName>
<RemoteEmailAddress>zzackry@example.com</RemoteEmailAddress>
<password>test123</password>
<zimbraPasswordMustChange>TRUE</zimbraPasswordMustChange>
</User>
</ImportUsers>
</ZCSImport>
Example 8. 外部にホストしているドメインからアカウントのプロビジョニングにXMLファイルを使用する

以下の例では、メールデータをインポートせずに、外部にホストしているドメインのアカウントを複数、プロビジョニングします。

下記例の場合、新しく作成したアカウントの zimbraMailTransport の属性に ZCSサーバーの替わりに、指定している外部のSMTPサーバーが設定されます。

<?xml version="1.0" encoding="UTF-8"?>
<ZCSImport>
<SMTPHost>smtp.example.com</SMTPHost>
<SMTPPort>25</SMTPPort>
<ImportUsers>
<User>
<sn>Sample</sn>
<givenName>Sam</givenName>
<displayName>Sam Sample</displayName>
<RemoteEmailAddress>sam@example.com</RemoteEmailAddress>
</User>
<User>
<sn>Zackry</sn>
<givenName>Zak</givenName>
<displayName>Zak Zackry</displayName>
<RemoteEmailAddress>zzackry@example.com</RemoteEmailAddress>
</User>
</ImportUsers>
</ZCSImport>
Example 9. メールのインポートにXMLファイルを使用する

以下の例では、ZCSでアカウントをプロビジョニングせずに、IMAP通信でGmailのアカウントからメールデータをインポートします。メールデータをインポートする前に、アカウントがZCSにプロビジョニングされている必要があります。

<?xml version="1.0" encoding="UTF-8"?>
<ZCSImport>
<IMAPHost>imap.gmail.com</IMAPHost>
<IMAPPort>993</IMAPPort>
<ConnectionType>ssl</ConnectionType>
<UseAdminLogin>0</UseAdminLogin>
<ImportUsers>
<User>
<sn>Sample</sn>
<givenName>Sam</givenName>
<displayName>Sam Sample</displayName>
<RemoteEmailAddress>sam@example.com</RemoteEmailAddress>
<RemoteIMAPLogin>sam@example.com</RemoteIMAPLogin>
<remoteIMAPPassword>test123</remoteIMAPPassword>
</User>
</ImportUsers>
</ZCSImport>

外部LDAPから新しいアカウントを自動的にプロビジョニングする

外部LDAPからの新しいアカウントの自動プロビジョニングは、CLIで対応します。本項で、サポートしているCLI属性と自動プロビジョニング方法について説明します。

概要

ZCSのドメインに、外部LDAP認証、preauth、SPNEGOのような外部LDAPの認証方法を設定している場合、ZCSにユーザーアカウントを自動作成できます。プライマリのメールアドレスやデフォルトのアカウント属性は外部のディレクトリよりマッピングされます。外部ディレクトリのデータからのアカウントの新規作成方法や作成タイミングを設定できます。

下記3つのモードが自動プロビジョニング設定でサポートされています。

モード 説明

Eagerモード

ZCS は外部のディレクトリを定期的に確認し、新規アカウントを自動作成します。新規ユーザーの確認のために外部ディレクトリをポーリングする頻度、各回における処理可能な最大ユーザー数、特定のサーバーでアカウントの自動プロビジョニング対象としてスケジューリングするドメインを管理できます。

概要: Eagerモードの自動プロビジョニングを設定する

Lazyモード

ユーザーの初回ログイン時、自動プロビジョニングをサポートしている認証方法の1つでZWCにログインしたときにそのユーザーがZCSディレクトリに存在しなければ、そのユーザーのためにZCS内に新規アカウントが自動作成されます。

概要: Lazyモードの自動プロビジョニングを設定する

Manualモード

自動プロビジョニングは実行されません。代わりに、管理者がマニュアル操作で、設定されている外部自動プロビジョニングLDAPソースを検索し、その検索結果から1つエントリを選択し、その外部エントリのために該当のZimbraアカウントを作成します。

Guidelines are provided in Manuralモードの自動プロビジョニングを設定する

自動でアカウント作成する際、アカウント名 (@の左にある部分) は外部ディレクトリに存在するユーザー属性よりマッピング (取得) されます。これは zimbraAutoProvAccountNameMap 内に定義します。また、姓、名、電話番号、住所、など、他のアカウント情報は zimbraAutoProvAttrMap に指定された属性にて、外部ディレクトリからマッピング (取得) されます。Zimbraの属性へマッピングすべき属性を決めるため、外部ディレクトリの属性をレビューすることができます。

自動作成したアカウントへの提供サービスの設定はマニュアル操作で作成したアカウントと同じように決定します。

  • ドメインに特定の提供サービスを設定している場合、新規作成したアカウントにはその提供サービスが設定されます。

  • ドメインに特定の提供サービスを設定していない場合、 ZCS のデフォルト提供サービスが設定されます。

アカウントが自動作成された場合、サーバーから ようこそ のメッセージが自動で受信されるように設定できます。ドメイン AutoProvNotification 属性にてメッセージの件名や本文を管理します。

自動プロビジョニングの属性

本項では、外部LDAPディレクトリから新規アカウントの自動プロビジョニングを設定するときに使用できる zmprov コマンドを紹介します。

zimbraAutoProvMode

EAGER、LAZY、MANUALから自動プロビジョニングで使用するモードを設定します。1つのドメインでモードを複数、有効化できます。

zimbraAutoProvAuthMech

LDAP, PREAUTH, KRB5, SPNEGOのいずれかから認証方法を設定します。LAZYモードの場合に有効です。 ユーザーが指定した外部認証方法で認証された後、ユーザーのアカウントがZimbraのディレクトリに存在していない場合、アカウントがZimbraのディレクトリに自動作成されます。

zimbraAutoProvLdapURL

自動プロビジョニングで使用する外部LDAPソースのLDAP URLを設定します。

zimbraAutoProvLdapStartTlsEnabled

自動プロビジョニングで外部LDAPサーバーにアクセスする際、StartTLSのプロトコルを使用するか否かです。デフォルトの設定はFALSEです。

zimbraAutoProvLdapAdminBindDn

自動プロビジョニングで使用するLDAP検索のバインドDNを設定します。

zimbraAutoProvLdapAdminBindPassword

自動プロビジョニングで使用するLDAP検索の管理バインドパスワードを設定します。

zimbraAutoProvLdapSearchBase

自動プロビジョニングで zimbraAutoProvLdapSearchFilter と共に使用するLDAP検索ベースを設定します。
設定されていないとき、LDAPのルートDSEが使用されます。

zimbraAutoProvLdapSearchFilter

自動プロビジョニングで使用するLDAP検索フィルターのテンプレートを定義します。LAZYモードの場合、 zimbraAutoProvLdapSearchFilter または zimbraAutoProvLdapBindDn を設定する必要があります。

2つとも設定されている場合、 zimbraAutoProvLdapSearchFilter が優先されます。詳細は プレースホルダー を参照してください。

zimbraAutoProvLdapBindDn

自動プロビジョニングで使用するLDAP外部フィルターのテンプレートを指定します。LAZYモードの場合、 zimbraAutoProvLdapSearchFilter または zimbraAutoProvLdapBindDn を設定する必要があります。

2つとも設定している場合、 zimbraAutoProvLdapSearchFilter が優先して適用されます。詳細は プレースホルダー を参照してください。

zimbraAutoProvAccountNameMap

アカウント名のローカル部分を含む外部ディレクトリ内の属性名を定義します。この名前は、Zimbraアカウントの作成に使用されます。指定されていないとき、アカウント名のローカル部分は、Zimbraへの認証に使用された最初のユーザー名になります。

zimbraAutoProvAttrMap

外部エントリの属性値から ZCS のアカウント属性へマッピングするための属性を定義します。値は {外部属性}={zimbra属性} 形式にします。設定されていないとき、外部ディレクトリの属性は ZCS アカウントへ取り込まれません。

誤ったマッピング設定は、アカウント作成が失敗する原因となります。下記は不正なマッピング条件の例です。

  • 無効な外部ソース属性名

  • 無効なzimbra属性名

  • 外部ソース属性には複数の値があるが、Zimbra属性の値は1つのみ

  • 構文の違反 (例えば、外部ソース属性のStringだが、Zimbra属性がInteger型など)

zimbraAutoProvNotificationFromAddress

新規アカウントが受信する「ようこそ」メッセージの 差出人 を定義します。設定されていないとき、メール通知は新規作成されたアカウントに送信されません。

zimbraAutoProvNotificationSubject

ユーザーの自動プロビジョニング時にユーザーに送信される通知メッセージの件名の作成に使われるテンプレート。

使用可能な変数: ${ACCOUNT_ADDRESS}, ${ACCOUNT_DISPLAY_NAME}

zimbraAutoProvNotificationBody

ユーザーの自動プロビジョニング時にユーザーに送信される通知メッセージの本文の作成に使われるテンプレート。

使用可能な変数: ${ACCOUNT_ADDRESS}, ${ACCOUNT_DISPLAY_NAME}

zimbraAutoProvListenerClass

自動プロビジョニングのリスナーのクラス名を定義するドメイン設定。使用するクラスは com.zimbra.cs.account.Account.AutoProvisionListener のインターフェースを実装している必要があります。各アカウントがZimbraに自動作成された後、独立したリスナーが呼ばれます。サーバーの拡張としてリスナーをプラグインすると、外部LDAPディレクトリでアカウントの自動プロビジョニング状況を更新するなどのタスク管理が可能になります。

EAGERプロビジョニングの各インターバルで、ZCS は zimbraAutoProvLdapSearchFilter の値に基づきLDAP検索を実行します。検索結果のエントリはこのバッチでの自動プロビジョニング候補です。 zimbraAutoProvLdapSearchFilter には、ZCSの既存アカウントがヒットしない条件を設定しておく必要があります。設定されていないとき、同じアカウントが何度も作成されます。 ZCSでアカウントの自動プロビジョニングが完了すると、 com.zimbra.cs.account.Account.AutoProvisionListener.postCreate (Domain domain, Account acct, String external DN) が自動プロビジョニングのフレームワークから呼ばれます。顧客は、AutoProvisionListenerのインターフェースをZCSのサーバー拡張に実装して、 AutoProvisionListener.postCreate() を呼ばせるようにします。このpostCreateを実装すると、例えば、ZCSにプロビジョニングされたばかりのアカウントに、外部ディレクトリ属性を設定できます。この属性は、 zimbraAutoProvLdapSearchFilter に条件として設定できるため、このエントリは次のインターバルのLDAP検索結果に返ってこなくなります。

zimbraAutoProvBatchSize

EAGER自動プロビジョニングの各インターバルで処理される最大アカウント数を定義するドメイン設定 | グローバル設定。

zimbraAutoProvScheduledDomains

サーバーでのEAGER自動プロビジョニングが予定されているドメインをリストアップするサーバー属性。予定のドメインの zimbraAutoProvMode は EAGERモードが有効である必要があります。EAGER自動プロビジョニングについて、1つのサーバー上でドメインを複数、スケジュールできます。また、EAGER自動プロビジョニングについて、複数のサーバー上で1つのドメインをスケジュールできます。

zimbraAutoProvPollingInterval

EAGERモード中の、アカウントのポーリングとプロビジョニングのインターバルを定義するドメイン設定|グローバル設定。 zimbraAutoProvBatchSizezimbraAutoProvScheduledDomains に設定されたドメイン数にも影響されるため、実際のインターバルはこの定義より長くなる可能性があります。

各インターバル中、自動プロビジョニングのスレッドは zimbraAutoProvScheduledDomains 内のドメインをすべて確認し、 domain.zimbraAutoProvBatchSize の値になるまで新規アカウントを自動作成します。この処理時間が zimbraAutoProvPollingInterval よりも長くなると、zimbraAutoProvPollingInterval になる前に、次のインターバルがすぐに起動されます。

  • サーバーが起動した時点でこの値が「0」の場合、自動プロビジョニングのスレッドは開始しません。

  • サーバーが実行中にこの値を「0」に変更した場合、自動プロビジョニングのスレッドが終了します。

  • サーバーが実行中にこの値を「0」から他の値に変更すると、自動プロビジョニングのスレッドが開始します。

プレースホルダー

Table 46. 自動プロビジョニング属性で利用するプレースホルダー
タグ 説明 結果

%/n

ユーザー名と@ 記号

user1@example.com を返します。

%u

@記号なしのユーザー名

user1 を返します。

%d

ドメイン

example.com を返します。

%D

DCとしてのドメイン

example,dc=com を返します。

Eagerモードの自動プロビジョニングを設定する

Eagerモードの場合、ZCS は自動プロビジョニングのため外部のディレクトリのアカウントを定期的に確認します。外部ディレクトリを確認するインターバル、各インターバルで処理可能な最大ユーザー数、自動プロビジョニング対象のサーバーやドメインを管理できます。

  1. ZCS のサーバーへログインし、Zimbraユーザーに切り替えます。

    zmprov
  2. EAGERモードを有効化します。

    md <example.com> zimbraAutoProvMode EAGER
  3. 各インターバルで処理可能な最大アカウント数を設定します。

    md <example.com> zimbraAutoProvBatchSize <#>
  4. アカウントのポーリングとプロビジョニングのインターバルを設定します。自動プロビジョニングのスレッドを起動するため、この値は「0」以外の値に設定する必要があります。デフォルトは15分です。

    ms <server.com> zimbraAutoProvPollingInterval <x minutes>
  5. 自動プロビジョニング対象のドメインを設定します。サーバーに複数のドメインを設定できます。

    また、対象ドメインは複数サーバーに設定できます。

    ms <server.com> +zimbraAutoProvScheduledDomains <domain1.com> \
      +zimbraAutoProvScheduledDomains <domain2.com>
  6. 外部LDAPの詳細を設定します。

    1. LDAP URLを設定します。

      md <example.com> zimbraAutoProvLdapURL "ldap://xxx.xxx.xxx.xxx:<port>"

      一般的にLDAPはポート389を使用します。

    2. (任意) StartTLSを有効化します。

      md <example.com> zimbraAutoProvLdapStartTlsEnabled TRUE
    3. 自動プロビジョニング用のLDAP管理者バインドDNを設定します。

      md <example.com> zimbraAutoProvLdapAdminBindDn "cn=admin, dc=autoprov, dc=company, dc=com"
    4. 自動プロビジョニング用のLDAP管理者の検索バインドパスワードを設定します。

      md <example.com> zimbraAutoProvLdapAdminBindPassword <password>
    5. 自動プロビジョニング対象のユーザーを検索する際のテンプレートを設定します。

      検索フィルター使用例

      md <example.com> zimbraAutoProvLdapSearchFilter "(uid=<%placeholder>)"

      サポート対象のプレースホルダーについては プレースホルダー を参照してください。

    6. 自動プロビジョニングのLDAP検索ベースを設定します。

      これは、ディレクトリ内のLDAP検索の開始地点です。zimbraAutoProvLdapSearchFilter で、と共に使用されます。設定されていないとき、LDAPディレクトリのルートである rootDSE が開始地点です。

      md <example.com> zimbraAutoProvLdapSearchBase "dc=autoprov,dc=company,dc=com"
      md <example.com> zimbraAutoProvLdapBindDn <"placeholder1">

      サポート対象のプレースホルダーについてはプレースホルダー を参照してください。

  7. (任意) 外部ディレクトリにて、アカウント名のローカル部分が依存する属性を指定します。新規アカウントを作成する際に、アカウント名のローカル部分が ZCS アカウント名として使用されます。なお、アカウント名のローカル部分を指定していない場合、 ZCSへ認証したユーザー名をローカル名として使用します。

    md <example.com> zimbraAutoProvAccountNameMap <value>
  8. (任意) 外部エントリの属性値から ZCS のアカウント属性へマッピングします。セットアップされていないとき、外部ディレクトリの属性は ZCS アカウントへ取り込まれません。値は {外部属性}={zimbra属性} 形式にします。

    誤ったマッピング設定は、アカウント作成が失敗する原因となります。

    外部エントリの値「sn」をZimbraアカウントの「displayName」にマッピングし、外部エントリの「description」の値を ZCS アカウントの「description」にマッピングします。

    md <example.com> +zimbraAutoProvAttrMap sn=displayName +zimbraAutoProvAttrMap description=description
  9. (任意) 新規作成アカウントに「ようこそ」のメッセージを送信したいとき、メッセージの 差出人 を設定します。

    md <example.com> zimbraAutoProvNotificationFromAddress <name@example.com>
  10. zmprovを抜けます。

    exit

Lazyモードの自動プロビジョニングを設定する

LDAP、preauth、Kerberos 5およびSpnegoの外部認証にユーザーが認証した場合、Lazy モードの自動プロビジョニングが新規アカウントを作成します。

  1. ZCSのサーバーへログインし、Zimbraユーザーに切り替え、コマンドプロンプトでzmprovを入力します。

  2. LAZYモードを有効化します。

    md <example.com> zimbraAutoProvMode LAZY
  3. LAZYモードが使用する外部認証方法LDAP, PREAUTH, KRB5, SPNEGOを指定します。複数の認証方法を指定できます。

    md <example.com> zimbraAutoProvAuthMech <type> +zimbraAutoProvAuthMech <type2>
  4. 外部LDAPの詳細を設定します。

    1. LDAP URLを設定します。

      md <example.com> zimbraAutoProvLdapURL "ldap://xxx.xxx.xxx.xxx:<port>"

      一般的にLDAPはポート389を使用します。

    2. (任意) StartTLSを有効化します。

      md <example.com> zimbraAutoProvLdapStartTlsEnabled TRUE
    3. 自動プロビジョニング用のLDAP管理者バインドDNを設定します。なお、 cn=<LDAPadmin_name>, dc=autoprov, dc=<company_name>, dc=<com> のフォーマットを使用する必要があります。

      md <example.com> zimbraAutoProvLdapAdminBindDn <"bindDN">

      例: "cn=admin, dc=autoprov, dc=company, dc=com"

    4. 自動プロビジョニング用のLDAP管理者の検索バインドパスワードを設定します。

      md <example.com> zimbraAutoProvLdapAdminBindPassword <password>
    5. (任意) 自動プロビジョニング対象のユーザーを検索する際のテンプレートを設定します。

      検索フィルター使用例

      md <example.com> zimbraAutoProvLdapSearchFilter <"placeholder">

      サポート対象のプレースホルダーについては プレースホルダー を参照してください。

      LAZYモードにzimbraAutoProvLdapSearchFilter、またはzimbraAutoProvLdapBindDnを設定する必要があります。
    6. 自動プロビジョニングのLDAP検索ベースを設定します。zimbraAutoProvLdapSearchFilter と共に、LDAPの検索を開始する場所を指定します。なお、この値を設定しない場合、LDAPディレクトリのルートである rootDSE が自動的に使用します。

      md <example.com> zimbraAutoProvLdapSearchBase <"location">

      <”location”>の例: "dc=autoprov,dc=company,dc-com"

    7. (任意) アカウントのプロビジョニングで使用するLDAP外部DNテンプレートを設定します。

      md <example.com> zimbraAutoProvLdapBindDn "uid=%<placeholder1>, %<placeholder2>"

      サポート対象のプレースホルダーについてはプレースホルダー を参照してください。

  5. (任意) 外部エントリのアカウント名のローカル部分が依存する属性を指定します。新規アカウントを作成する際に、アカウント名のローカル部分がZCSアカウント名として使用されます。なお、アカウント名のローカル部分が指定されていない場合、ZCSへ認証したユーザー名をローカル名として使用します。

    md <example.com> zimbraAutoProvAccountNameMap <value>
  6. (任意) 外部エントリの属性値から ZCS のアカウント属性へマッピングします。セットアップされていないとき、外部ディレクトリの属性は ZCS アカウントへ取り込まれません。値は {外部属性}={zimbra属性} 形式にします。

    外部エントリの値 sn をZimbraアカウントの displayName にマッピングし、外部エントリの「description」の値を ZCS アカウントの「description」にマッピングします。

    md <example.com> +zimbraAutoProvAttrMap sn=displayName +zimbraAutoProvAttrMap description=description
  7. (任意) 新規に作成したアカウントへ ようこそ のメッセージを送信希望の場合、メッセージの 差出人 を設定します。

    md <example.com> zimbraAutoProvNotificationFromAddress <name@example.com>
  8. zmprovを抜けます。
    exit

Manuralモードの自動プロビジョニングを設定する

外部LDAPサーバーとの自動プロビジョニングを無効にするには、Manualモード設定を使用します。

  1. ZCSサーバーへログインし、Zimbraユーザーに切り替え、コマンドプロンプトでzmprovを入力します。

  2. Manualモードを有効化します。

    md <example.com> zimbraAutoProvMode MANUAL

リソースを管理する

「リソース」とは、会議などに予約できる場所や機器のことです。 各会議室や、場所を固定しない機器 (視聴覚の機器、など) は、リソースアカウントとしてセットアップします。管理コンソールの 管理 > リソース にて、 Zimbra Collaborationに設定しているリソースアカウントを管理できます。

ユーザーアカウントのカレンダー機能で、リソースをカレンダーに予約できます。リソースアカウントは、利用可・不可に基づき、予約依頼を自動で許可・拒否します。

管理者はリソースのメールボックスを定期的に監視する必要はありません。リソースのメールボックス内容は、メールの削除ポリシーにより、自動削除されます。

リソースウィザードを使用して、リソース設定を行ないます。以下のリソース詳細をアカウントに設定できます。

  • リソースの種類:場所または機器

  • 予定のポリシー

  • カレンダー招待のコピーを転送するメールアドレス

  • リソースの説明

  • 問題が発生した際に対応可能の連絡先情報

  • 場所の情報:ビル名、住所、部屋名、収容人数など

  • リソースの自動返信メッセージや署名のカスタマイズ

リソースアカウントを作成するとLDAPサーバーにディレクトリのアカウントが作成されます。

リソースを予約するには、リソース機器や場所を会議に招待します。リソースの選択時、リソースの説明、連絡先、空き状況を閲覧できます。

会議の招待が送信されると、リソースアカウントにメールが送信されます。予定ポリシーに従い、リソースが空いていれば、リソースのカレンダーに会議が自動追加されてそのリソースは予約済みに表示されます。

リソースの予定ポリシーを設定する

リソースの予定ポリシーでは、リソースカレンダーの維持方法を設定できます。以下の予定ポリシーを使用できます。

  • 繰り返し予約を自動拒否 — リソースが1度に1つの会議にしかスケジューリングできないとき、この値は有効です。このリソースに繰り返し予約を入れることはできません。

  • 使用可能な場合には自動的に受け入れ、競合する場合には自動的に拒否する — このオプションが選択されているとき、リソースが予約済みでない限り、自動で依頼が許可されます。リソースの空き時間が閲覧可能です。自動拒否のルールを編集して、競合する予約を許可できます。

  • 手動で受け入れ、競合する場合には自動的に拒否する — このオプションが選択されているとき、競合する予約は全て、リソースアカウントに自動で拒否されます。競合していない予約依頼は、リソースカレンダーに仮予約としてマークされるため、マニュアル操作での許可が必要となります。これをセットアップするなら、招待をマニュアル操作で許可できるアカウントに招待のコピーが転送されるように設定する必要あります。自動拒否のルールを編集して、競合する予約を許可できます。

  • 常に自動的に受け入れる — リソースアカウントは予約された予定を自動的に許可します。この場合、リソースの空き状況は反映されないため、複数の会議が同じ時間帯にそのリソースを予約する可能性があります。リソースは常に招待を受け入れるため、社外でよく会議に使う場所を参加者への招待に含めたい場合に使用することを推奨します。

  • 自動的に受け入れない、自動的に拒否しない — リソースアカウントはマニュアル操作で管理されます。委任されたユーザーがリソースアカウントにログインし、すべての依頼をマニュアル操作で許可・拒否する必要があります。

競合のルール — 管理者は、競合する場合には自動的に拒否するように設定されているアカウントに、しきい値をセットアップできます。部分的に許される繰り返し予定の全体に対するパーセンテージや、競合数として、設定します。

競合の最大許容数競合の最大許容パーセント は、依頼された繰り返し予定日全て、使用できない場合も繰り返し予定がスケジューリングできるように設定されます。

競合があったとしても、競合の最大許容数または競合の最大許容パーセントのいずれかに達するまで、リソースは予約を許可します。部分予約が機能できるように、両項目に0以外の値を設定しておく必要があります。

リソースアカウントを管理する

リソースアカウントとしてログインすると、リソースのプリファレンスを設定できます。 リソースアカウントのプリファレンス > カレンダー から、ユーザーによるリソースカレンダー管理を設定できます。リソース管理には、次のオプションがあります。

  • 招待の転送先。アカウントのプロビジョニング時に転送先アドレスがセットアップされていた場合、管理者はそのアドレスを変更できます。

  • リソースを使用できるユーザー。アクセス許可セクションの招待のところから、 内部ユーザーのみが自分を予定の招待できるようにする を選択し、適切なユーザーメールアドレスをこのリストに追加してください。

リソースカレンダーを特定のユーザーに共有して管理者権限を付与することができます。管理者として委任されたユーザーは、そのカレンダーに対する全ての管理者権限を持つことになります。招待について、閲覧、編集、追加、削除、許可、拒否ができます。

ユーザーアカウントの管理

ユーザーアカウントのステータス

管理コンソール:

ホーム > 管理 > アカウント

アカウントのステータスにより、ユーザーのログインとメール受信の可否が決まります。このステータスは、管理コンソールの 管理 ペインに表示されます。

Table 47. ステータス - ユーザーアカウント
ステータス 説明

アクティブ

メールボックスアカウントの通常の状態です。メールは配信され、ユーザーはクライアントインタフェースにログインできます。

メンテナンス

ログイン不可で、このアカウント宛のメールは全てMTAのキューに並びます。

バックアップ中やアカウントのインポート/エクスポート/復元時、このステータスがアカウントに自動設定されることをご注意ください。

保留

新規作成されたアカウントで、まだアクティブになる準備が終わっていないとき。保留中、ログイン不可で、メールはバウンスされます。

ロック

ログイン不可で、メールはこのアカウントに継続配信されます。メールアカウントが危険にさらされている(未認証エンティティが使用)と思わしき場合、管理者はこのロックステータスを設定できます。

閉鎖

ログイン不可で、メールはバウンスされます。サーバーから削除せずに、削除済みアカウントとする場合にこのステータスが使用されます。閉鎖によるアカウントライセンスへの影響はありません。

ロックアウト

不正なパスワードでのログイン試行時、自動でセットされるステータスです。ロックアウトは、マニュアルでは管理者でも設定できません。設定で許容されているログイン試行回数を超えた場合にセットされます。ロックアウトの期間も設定可能です。

管理者はロックアウトのステータスをいつでも解除できます。

アカウントを削除する

管理コンソール:

ホーム > 管理 > アカウント

管理コンソールからアカウントを削除できます。これにより、アカウントはサーバーから消去され、メッセージストアにあるメッセージが削除され、ライセンスの使用中アカウント数が変更されます。

アカウント削除前に、アカウントの完全バックアップを実行してアカウント情報を保存してください。バックアップの詳細は バックアップと復元 の章を参照してください。

アカウントのメールボックスを閲覧する

すべてのフォルダ、カレンダー予定およびタグを含めて、特定のアカウントのメールボックス内容をすべて管理コンソールから閲覧できます。

管理コンソール:

ホーム > 管理 > アカウント → アカウント名

アカウント名 を選択後、ギア アイコンから メールを表示 を選択します。対象ユーザーのZWCアカウントが別ウィンドウで開かれます。

この機能では、管理者とユーザーは同一アカウントに同時にログインできるため、困っているユーザーのアカウントに直接アクセスし、サポートすることができます。

アカウントにアクセスするメールを表示アクションは全て audit.log に記録されます。

電子メールのエイリアスを使用する

メールのエイリアスは、特定のメールアカウントに全メールをリダイレクトするメールアドレスです。エイリアスはメールアカウントではありません。各アカウントにいくつでもエイリアスを設定できます。

管理→エイリアスペインからエイリアスを選択時、設定されているエイリアスが全て内容ペインに表示されます。エイリアスの作成、特定のエイリアスのアカウント情報の閲覧、エイリアスの対象アカウントの変更、エイリアスの削除ができます。

配布リストを管理する

配布リストとは、メールアドレスの集合が共通メールアドレス内にリストアップされたものです。配布リストへの送信時、そのリスト内の全員にメッセージを送信していることになります。あて先項目には配布リストのメールアドレスが表示されます。個々の受信者のアドレスが閲覧されることはありません。

メンバーリストを管理する管理者が必要な配布リストの作成や、リストのメンバーを自動で追加・削除するダイナミック配布リストの作成ができます。ダイナミック配布リストの詳細は、 ダイナミック配布リストを使用する を参照してください。

ユーザーがメンバーになっている配布リストは、管理→アカウント→メンバーページから確認できます。Zimbraユーザーのメールアドレスが配布リストに追加されると、その配布リスト名がユーザーこのアカウントのメンバーページに反映されます。配布リストの削除時、このアカウントのメンバーページからその配布リスト名が消去されます。

配布リストの購読ポリシーを管理する

配布リストのメンバー管理のための購読ポリシーをセットアップできます。リストのオーナーは配布リストのプロパティページから、購読ポリシーを管理できます。

オプション 詳細

新しい購読の要求

  • 自動的に受け入れる — 誰でも購読メンバーになれます。

  • リストのオーナーの承認が必要 —  ユーザーが購読するためには、配布リストのオーナーにメッセージを送信し、オーナーはそのメールの依頼に答えます。

  • 自動的に拒否する — 誰も配布リストに追加できません。

購読解除の要求

  • 自動的に受け入れる —  誰でもリストから除名できます。

  • リストのオーナーの承認が必要 — ユーザーが配布リストからリストから除名されるには、配布リストのオーナーにメッセージを送信します。オーナーは除名のメール依頼を承認する必要があります。

  • 自動的に拒否する — ユーザーはリストから除名できません。

配布リストのオーナーが使用できる管理オプション

配布リストにオーナーを登録すると、オーバーはZWCの自身のアカウントのアドレス帳、配布リストフォルダから管理することができます。リストのオーナーは、リストの編集のために、配布リストを右クリックして グループを編集 を選択できます。

メンバーの追加・削除のほか、オーナーが設定できる配布リストのプロパティに次のようなものがあります。

  • グローバルアドレスリストに表示されないように、配布リストをプライベートとしてマーク

  • リストへメッセージ送信できるユーザーを管理

  • メンバーの購読ポリシーの設定

  • 他のオーナーの追加

配布リストを作成する

配布リストの作成は、本項の手順を参考にしてください。

管理コンソール:

ホーム > 管理 > 配布リスト

  1. 画面の右上にある ギア アイコンから 新規 をクリックします。

  2. メンバー ページで、配布リストの名前を入力します。スペースは使用できません。他の項目は任意です。

  3. 右側の「このリストにメンバーを追加」から、配布リストに追加するメンバーを検索します。追加するメンバーを選択して、 選択項目を追加 をクリックします。ページに表示されたアドレス全てを追加したいなら、 このページを追加 をクリックします。会社のリストに存在しないメンバーを追加したいなら、 または下にアドレスを入力 項目にメールアドレスを正確に入力します。

  4. 次へ をクリックし、配布リストの プロパティ ページに進みます。

    Table 48. 配布リストプロパティオプション
    配布リストプロパティオプション 詳細

    メール受信可

    デフォルトで有効です。配布リストがメッセージを受信すべきでないなら、このオプションを無効にします。

    GALに表示しない

    このオプションを有効にすると配布リストがグローバルアドレスリスト(GAL)に表示されません。このオプションを利用して、配布リストのメールアドレスの存在を知るユーザーを制限できます。

    メールサーバー

    デフォルトで「自動」が設定されます。特定のメールサーバーを指定する場合、「自動」を無効にし、一覧からサーバーを特定します。

    ダイナミックグループ

    このチェックボックスを有効にすると メンバーURL 項目が表示されます。ダイナミック配布リストを作成します。詳細は以下の ダイナミック配布リストを使用する を参照してください。

    新しい購読の要求

    以下のいずれかを選択します。

    • 自動的に受け入れる

    • リストのオーナーの承認が必要

    • 自動的に拒否する

    購読解除の要求

    以下のいずれかを選択します。

    • 自動的に受け入れる

    • リストのオーナーの承認が必要

    • 自動的に拒否する

  5. メンバー ページで、配布リストを直接メンバーとするか間接メンバーとするかを選択します。

  6. 配布リストにエイリアスを追加すべきなら、作成します。

  7. 配布リストを他のユーザーにも管理させるなら、オーナー ページから、対象者のメールアドレスを入力します。

  8. 配布リストが受信するメッセージの返信方法を設定します。

  9. 完了 をクリックします。配布リストが有効になり、URLが作成されます。

配布リストへのアクセスを管理する

配布リストの作成後は、配布リストのメンバーを閲覧できるユーザーや配布リストへメッセージ送信できるユーザーを管理できます。デフォルトでは、全ユーザーに全配布リストへのアクセス権があります。本章では、CLIから行なう配布リストへのアクセス管理について説明します。

配布リストにアクセスできるユーザーを制限するには、ドメインの個々のユーザーにアクセス権を与えます。あるいは、ドメインのユーザーにだけ配布リストへのアクセスを許可したいなら、ドメインに対するアクセス権を与えることができます。ドメインにアクセス権を与えると、ドメインにある全配布リストがその権限を継承します。

個々の配布リストに対する権限を付与すると、配布リストへのアクセスが認められる特定のユーザーを設定することができます。

配布リストへのアクセス制限はコマンドラインの zmprov grantRight (grr) コマンドで実行可能です。

権限付与についての詳細は、 管理権限の委任を参照してください。
配布リストのメンバーを閲覧できるユーザー

デフォルトでは、全ユーザーが配布リストのメンバーのメールアドレスを閲覧できます。配布リストのメールアドレスに、「+」が吹き出し表示されます。クリックして、配布リストを展開することができます。配布リスト内のメールアドレスが一覧表示されます。ユーザーは、この展開されたリストから、個々のアドレスを選択できます。

個別のユーザーやドメインに、配布リスト内のメールアドレス閲覧を制限します。

  • 個別のユーザー

    zmprov grr domain <ドメイン名> usr <アドレス@ドメイン> viewDistList
  • ドメイン内全ユーザー

    zmprov grr domain <ドメイン名> dom <example.com> viewDistList
  • 配布リストに権限を付与し、特定のユーザーにリストを閲覧させる

    zmprov grr dl <dll_name@example.com> usr <アドレス@ドメイン>
配布リストへメッセージ送信できるユーザー

デフォルトでは、すべてのユーザーがすべての配布リストにメッセージ送信できます。誰が配布リストにメッセージを送れるかを定義するために、ドメインや配布リストに権限を付与できます。使用する権限のない配布リストにメッセージを送信しようとすると、あて先の配布リストへメッセージを送信する権限がない旨を伝えるメッセージが送信されます。

ホーム > 設定 > グローバル設定 > MTA にある Milterサーバー は有効でなければなりません。

個別のユーザーやドメインに、配布リストへのメッセージ送信を制限します。

  • ドメイン内のあるユーザーのみにすべての配布リストへのメッセージ送信を許可。

    zmprov grr domain <ドメイン名> usr <アドレス@ドメイン> sendToDistList
  • ドメイン内の全ユーザーにすべての配布リストへのメッセージ送信を許可。

    zmprov grr domain <ドメイン名> dom <example.com> sendToDistList

ユーザータイプによる、個々の配布リストへのアクセス許可とその解除の方法です。

  • 特定の内部ユーザーにアクセスを許可。

    zmprov grr dl <dlname@example.com> usr <username@example.com> sendToDistList

    アクセス許可を解除。

    zmprov rvr dl <dlname@example.com> usr <username@example.com> sendToDistList
  • 配布リストのメンバーのみにアクセスを許可。

    zmprov grr dl <dlname@example.com> grp <dlname2@example.com> sendToDistList

    アクセス許可を解除。

    zmprov rvr dl <dlname@example.com> grp <dlname2@example.com> sendToDistList
  • ドメイン内の全ユーザーのみにアクセスを許可。

    zmprov grr dl <dlname@example.com> dom <example.com> sendToDistList

    アクセス許可を解除。

    zmprov rvr dl <dlname@example.com> dom <example.com> sendToDistList
  • 外部ドメイン内の全ユーザーのみにアクセスを許可。

    zmprov grr dl <dlname@example.com> edom <example.com> sendToDistList

    アクセス許可を解除。

    zmprov rvr dl <dlname@example.com> edom <example.com> sendToDistList
  • すべての内部ユーザーのみにアクセスを許可。

    zmprov grr dl <dlname@example.com> all sendToDistList

    アクセス許可を解除。

    zmprov rvr dl <dlname@example.com> all sendToDistList
  • すべてのパブリック電子メールアドレスにアクセスを許可。

    zmprov grr dl <dlname@example.com> pub sendToDistList

    アクセス許可を解除。

    zmprov rvr dl <dlname@example.com> pub sendToDistList
  • 特定の外部メールアドレスにアクセスを許可。

    zmprov grr dl <dlname@example.com> gst <someone@foo.com> "" sendToDistList

    アクセス許可を解除。

    zmprov rvr dl <dlname@example.com> gst <someone@foo.com> "" sendToDistList
Active Directoryのアカウントによる配布リストのメンバーの閲覧を有効にする

Active Directory配布リストのメンバーをメッセージやアドレス帳から確認には、Active DirectoryのGALグループハンドラを、Active Directoryごとに、ZCSのGalSyncアカウント内に設定する必要があります。

本項の手順で、Active DirectoryごとのGalSyncアカウントを更新します。この設定を行なうには、GalSyncアカウント名とそのGALSyncアカウント内の全データソースを認識している必要があります。

  1. GalSyncアカウントのZimbraIDを表示します。

    zmprov gd {ドメイン名} zimbraGalAccountId

    アカウント名の検索

    zmprov ga {GAL同期アカウントのzimbraId} name
  2. GalSyncアカウントのデータソースを表示します。

    zmprov gds {ドメインのGAL同期アカウント名}
  3. Active Directoryのグループハンドラを有効にします。

    zmprov mds {ドメインのGalSyncアカウント名} {ADのデータソース名} \
     zimbraGalLdapGroupHandlerClass com.zimbra.cs.gal.ADGalGroupHandler

ダイナミック配布リストを使用する

ダイナミック配布リストは、メンバーを自動的に管理します。ユーザーは、リストに自動で追加・削除されます。ダイナミック配布リスト作成時、メンバーURLが指定されます。このメンバーURLは、含まれているはずのメンバーの識別に使用されます。このメンバーURLは、管理コンソールの配布リストのプロパティページで閲覧できます。

ダイナミック配布リストは、管理コンソールまたはコマンドラインから作成できます。URL内には、ダイナミック配布リストに追加されるユーザータイプの判別用に、特有のオブジェクトクラスを指定します。例えば、ダイナミック配布リストを、オブジェクトクラス = zimbraAccountで設定したとします。すると、新規アカウントの作成やアカウントの削除時、このダイナミック配布リストは更新されます。

すべてのモバイル、POP/IMAPのユーザーにダイナミック配布リストを作成できます。

配布リストのフィルタールールも変更することができます。配布リストを編集すると、新しいルールに従って、参加するメンバーが更新されます。

ダイナミック配布リストを使用する

ダイナミック配布リストは前述のとおり、管理コンソールまたはCLIから作成できます。

管理コンソール:

ホーム > 管理 > 配布リスト

  1. 右上の ギア アイコンより、 新規 をクリックします。

  2. メンバー ページから、ダイナミック配布リストの名前を入力します。スペースは使用できません。リストにメンバーを追加しないでください。

  3. 次へ をクリックし、プロパティ ページで設定します。

    Table 49. ダイナミック配布リストのオプション
    オプション 説明

    メール受信可

    デフォルトで有効です。配布リストがメッセージを受信すべきでないなら、このオプションを無効にします。

    GALに表示しない

    このオプションを有効にすると配布リストがグローバルアドレスリスト(GAL)に表示されません。このオプションを利用して、配布リストのメールアドレスの存在を知るユーザーを制限できます。

    メールサーバー

    デフォルトで 自動 が設定されます。特定のメールサーバーを指定する場合、 自動 を無効にし、一覧からサーバーを特定します。

    ダイナミックグループ

    このチェックボックスを有効にします。

    権限管理で使用可能

    このチェックボックスを無効にします。

    メンバーURL

    メンバーURLはLDAP URLのフィルターの一種で、リストに追加・削除するユーザータイプを決めます。

    このリストのURLを入力します。コマンドでは ldap://??sub? がURLです。 様々なダイナミック配布リストの作成のため、フィルターの組み合わせを自由にメンバーURLに追加します。

    Example 10. すべてのユーザー、GALアカウント、スパム/ハムのリスト
    ldap:///??sub?(objectClass=zimbraAccount)
    Example 11. 委任された管理者のリスト
    ldap:///??sub?(&(objectClass=zimbraAccount)(zimbraIsDelegatedAdminAccount=TRUE))
    Example 12. アクティブなアカウントすべて
    ldap:///??sub?(&(objectClass=zimbraAccount)(ZimbraAccountStatus=active))
    Example 13. 役職が「Manager」のユーザーすべて

    役職はアカウントの 連絡先情報の役職 から取得します。 この例ではこの項目にManagerが設定されています。

    ldap:///??sub?(&(objectClass=zimbraAccount)(title=Manager))

    新しい購読の要求

    自動的に拒否する を選択します。

    購読解除の要求

    自動的に拒否する を選択します。

  4. ダイナミック配布リストにエイリアスを追加すべきなら、作成します。

  5. ダイナミック配布リストを他のユーザーにも管理させるなら、オーナー ページから、対象者のメールアドレスを入力します。

  6. 返信先メールアドレスをセットアップしたいなら、ここに入力します。配布リストへの返信は全て、このメールアドレスに送信されます。

  7. 完了 をクリックします。ダイナミック配布リストが作成されます。

指定したフィルターに基づき、リストにユーザーが自動追加されます。管理者がユーザーを追加・削除するとリストは更新されます。

元は管理コンソールで作成されたダイナミック配布リストをCLIを使用して編集するには、そのダイナミック配布リストの zimbraIsACLGroup を必ず FALSE にする必要があります。

CLIの zmprov コマンドでダイナミック配布リストを管理できます。コマンドでは ldap:///??sub? がURLです。様々なダイナミック配布リストの作成のため、フィルターの組み合わせを自由にメンバーURLに追加します。

  1. すべての新規・既存アカウントのダイナミック配布リストを作成します。

    すべてのユーザー、GALアカウント名、スパム/ハムのアカウント名が含まれます。ユーザーアカウントの削除時、自動的にリストから削除されます。

    zmprov cddl <all@domain.com> zimbraIsACLGroup FALSE \
      memberURL 'ldap:///??sub?(objectClass=zimbraAccount)'
  2. 提供サービスを作成し、ユーザーに指定します。

    提供サービスを作成します。特定の条件、例えば「全マネージャー」など、に基づき、作成した提供サービスをユーザーに指定すると、その提供サービス用のダイナミック配布リストを簡単に修正することができます。

    Example 14. 特定の提供サービスにアクティブアカウントがあるユーザーが全員入っているダイナミック配布リスト
    zmprov cddl <allusers@domain.com>  zimbraIsACLGroup FALSE \
      memberURL 'ldap:///??sub?(&(objectClass-zimbraAccount) (zimbraCOSId=513e02e-9abc-4acf-863a-6dccf38252e3) (zimbraAccountStatus=active))'
    Example 15. 役職に基づいてユーザーが全員入っているダイナミック配布リスト

    この実行には、アカウントの連絡先情報に 役職 が設定されていなければなりません。この例は役職に「Manager」が設定されています。

    zmprov cddl <allmanagers@domain.com> zimbraIsACLGroup FALSE' \
      memberURL ldap:///??sub?(&(objectClass-zimbraAccount) (zimbraCOSId=513e02e-9abc-4acf-863a-6dccf38252e3) (title=Manager))'
    Example 16. 委任された管理者全員のダイナミック配布リスト
    zmprov cddl <alldelegatedadmins@domain.com> zimbraIsACLGroup FALSE \
      memberURL 'ldap:///??sub?(&(objectClass-zimbraAccount) (zimbraCOSId=513e02e-9abc-4acf-863a-6dccf38252e3) (zimbraIsDelegatedADminAccount=TRUE))'

メールボックスを移動する

メールボックスは、同じLDAPサーバーを共有するZimbraサーバー間で移動できます。

メールボックスの移動は管理コンソールやCLIコマンドから実行できます。 zmmboxmove を使用すれば、サーバーを停止せずに、サーバー間のメールボックス移動ができます。

移動先のサーバーが、メールボックス移動プロセスを管理します。移動はバックグランドで動作するため、アカウントは、ほぼ全てのデータが移動し終わるまで、アクティブモードのままです。アカウントは、最終データ移動のわずかな間、ロックされますが、すぐにアクティブモードに戻ります。

メールボックス移動プロセスは以下の手順で実行されます。

  • メールボックスブロブが移動先のサーバーに移されます。

  • 内容がほぼ移されると、アカウントはメンテナンスモードに切り替わります。

  • データベーステーブル、インデックスディレクトリ、変更されたブロブ全てが移されます。

  • アカウントはアクティブモードに戻されます。

メールボックスが移動先サーバーに移動後、元サーバーにまだコピーがありますが、ステータスは閉鎖です。ユーザーはログイン不可、メールは配信されません。旧メールボックスの削除前に、データが完全に新メールボックスへ移されていることを確認してください。

  • メールボックスを新サーバーに移動。

    zmmboxmove -a <アドレス@ドメイン> --from <旧サーバー> --to <新サーバー>
  • 旧サーバーからメールボックスを削除。

    zmpurgeoldmbox -a <アドレス@ドメイン> -s <旧サーバー>

メールボックスを移動するグローバル設定のオプション

メールボックス移動に関するグローバル設定のオプションとして、メールボックス移動時、検索インデックス、ブロブ、HSMブロブを除外するように設定できます。以下の設定オプションを、移動元サーバーあるいは移動先サーバーで設定できます。

  • zimbraMailboxMoveSkipSearchIndex — 検索インデックスデータを含めない場合、移動後にメールボックスを再インデックスしないといけません。

  • zimbraMailboxMoveSkipBlobs — メールボックスに紐づくブロブは、プライマリとセカンダリボリューム(HSM)込みで、除外されます。

  • zimbraMailboxMoveSkipHsmBlobs — 移動中のメールボックスのためのHSMブロブが既に存在するとき、有用です。 zimbraMailboxMoveSkipBlobs が設定されていないものHSMボリュームにあるブロブをスキップしたい場合にこのオプションを設定してください。

管理権限の委任 (*)

*Zimbra 8.8 より、本機能は2つの異なるバージョンを提供しています。Zimbra 8.8 ではスタンダード版と新世代(NG)版を提供しています。Zimbra 8.7 またはそれ以前のバージョンでは、スタンダード版のみを提供しています。以下にスタンダード版の詳細を記載しています。Zimbra 8.8 で本機能の NG版を利用する方法につきましては、本ガイドの NG版専用チャプターをご参照ください。

グローバル管理者(システム管理者)は、様々な「委任された管理者」の役割を作成できます。

「委任された管理者」の役割には、配布リストの管理や、ユーザーが忘れたパスワードのリセットのように単純なものから、ドメインに対するドメイン管理者まで、様々な権限があります。

よく使用される2つの管理の役割である、ドメイン管理者と配布リスト管理者は既に定義されています。これら既存の役割の場合、管理者を追加するために必要な設定は他にありません。

管理者権限を付与するターゲット種類

管理権限の委任には、ターゲット上でのアクセス制御を制限するための定義を行なうことと、管理者がターゲットでタスクを実行するための権限を付与することがあります。

「ターゲット」とは、権限付与の対象とされる Zimbra Collaboration のオブジェクトです。各ターゲットは「ターゲット種類」に紐づきます。「ターゲット種類」は、ターゲット上でのアクセス制御エントリのタイプを識別します。

ターゲットに「ターゲット種類」を選択するときは、以下を参考にしてください。

  • ターゲットについて。どの特定のターゲットに権限を付与しますか? 例えば、ターゲット種類に「ドメイン」を選択した場合、どのドメインを指していますか?特定のドメイン名を指定してください(ターゲット名=example.com)。そのターゲットにアクセス制御エントリ(ACE)が付与されます。ACEは、そのターゲットエントリのLDAPデータに保存されます。

  • 付与したい権限は、選択したターゲット種類に適していますか?権限は、関連するターゲット種類にしか適用できません。例えば、アカウント作成は、ターゲット種類「ドメイン」にしか適用できませんし、パスワード設定は、ターゲット種類「アカウント」「カレンダーリソース」にしか適用できません。ターゲットに適用できない権限がターゲット上に付与されると、その権限は無視されます。

  • 権限を定義するときは、付与される権限が機能するターゲットスコープを考慮する必要があります。例えば、パスワード設定は、ターゲット種類「アカウント」「カレンダーリソース」にしか適用できませんが、この権限がターゲット種類「ドメイン」の権限リストに含まれると、ドメイン内のすべてのアカウントとカレンダーリソースで機能することになります。

Table 50. 権限のターゲット
ターゲット種類 ターゲットスコープの説明

アカウント

アカウントエントリ(特定のユーザー)

カレンダーリソース

カレンダーリソースエントリ

COS

提供サービスエントリ

配布リスト

配布リストとその配布リスト配下の全配布リスト。

アカウントとカレンダーリソースに適用できる権限の場合は、この配布リストの直接のメンバーまたは間接のメンバーである、すべてのアカウントとカレンダーリソースもスコープ内。

ドメイン

特定のドメインが該当します。サブドメインは対象外。

サブドメインの場合、ターゲットとして明確にタグ付けされている必要があります。

ドメインがターゲットのとき、権限は、ドメイン内のすべてのアカウント、カレンダーリソース、配布リストについて付与されます。

設定

グローバル設定専用の権限

グローバルACL

ターゲット種類内の全エントリについての管理者権限。例えば、ドメインでのアカウント作成権限であるグローバルACLに、ACEを追加できます。

この権限が付与されている「委任された管理者」のアカウントは、システム内の全ドメインでアカウント作成ができます。

サーバー

サーバーエントリ

Zimlet

Zimletエントリ

権限

権限とは、「委任された管理者」が、名づけられているターゲット上で実施可能・不可能な機能のことです。権限には、システム定義権限と属性権限があります。

システム定義権限

システム定義権限の種類

  • Presetの権限 (初期設定の権限)。例えば、 createAccount はアカウントの作成で、 renameDomain はドメインのリネームです。

    Presetの権限は固定のターゲット種類に紐づきます。例えば、createAccount はドメイン上のみの権限、renameAccount はアカウント上での権限、getServer はサーバー上での権限です。

    管理者がターゲット上でアクションを実行するのに必要な設定は他にありません。

    Presetの権限には、複数ターゲットへのアクセスを伴うものもあります。被譲与者は、関連する全てのターゲット上で、適当な権限が必要です。例えば、アカウントのエイリアス作成には、アカウントにエイリアスを追加する権限と、ドメインにエイリアスを作成する権限がなければなりません。

属性権限

属性権限の付与により、「委任された管理者」/管理グループは、ターゲット上での特定の属性を編集・閲覧が可能(または不可能)になります。

属性権限の種類

  • Attribute (setAttrs) の権限で、ドメイン管理者は、属性値の閲覧・編集ができます。例えば、 modifyAccount の権限で、ドメイン管理者はそのアカウントのすべての属性を編集できます。

  • Get attribute rights (getAttrs) の権限で、ドメイン管理者は属性値の閲覧ができます。例えば、getAccount の権限は、ユーザーアカウントのすべての属性値を表示します。

権限が付与されている属性の場合、ターゲット上に設定されています。また、読み込み(get)や書き込み(set)という権限の種類も特定されています。

属性権限は、権限の許可と拒否が設定されている、複数の属性の組み合わせで付与されている場合があります。これにより、許可の属性を拒否にすることができます。

Comboの権限

どんなターゲット種類でもComboの権限に指定でき、presetの権限と属性権限の両方をComboの権限に入れることができます。Comboの権限を利用して、即座に複数の属性をターゲット上で付与できます。

拒否の権限

権限には、許可と拒否があります。拒否の権限とは、被譲与者への付与が否定されている権限です。

  • 管理グループに拒否の権限が設定されると、そのグループ内のすべての管理者は、その権限が設定されているターゲットとサブターゲット上でのその権限が否定されます。

  • ある管理者が管理グループに属していてもいなくても、その管理者に拒否の権限が設定されると、その管理者は、その権限が設定されているターゲットとサブターゲット上でのその権限が否定されます。

ある管理グループに、Domain1上でのアカウント作成権限も含む、ドメイン管理者権限が付与されています。この管理グループに属するAdminAに、アカウント作成権限を除いたドメイン管理者の全権限を持たせたいとします。その場合、ターゲットDomain1上での 拒否の createAccount 権限をAdminAに付与します。

同じレベルでの付与では、拒否の権限が常に優先されます。例えば、あるドメイン上でのアカウント閲覧権限が許可されているAdminGroup1。対して、同じドメイン上でのアカウント閲覧権限が拒否されているAdminGroup2。AdminAは両方のグループのメンバーです。このとき、AdminAはこのドメイン内のどのアカウントも閲覧できません。拒否の権限が優先されるからです。

異なるレベルでの付与では、最も細かい権限が優先されます。例えば、User1もメンバーであるGroupDistributionList1内のアカウント閲覧の拒否の権限が、AdminAに付与されています。また、直接User1のアカウント上で、アカウント閲覧の許可の権限が、AdminAに付与されています。このとき、AdminAはUser1のアカウントを閲覧できます。「ターゲット」アカウント上での付与は、配布リスト上での付与に比べて細かいからです。

権限リストの使用

システム権限とその説明は、管理コンソールの権限フォルダの概要ペインにリストアップされています。この権限フォルダを利用すれば、どのシステム定義権限を「委任された管理者」に付与するかを定義できます。このフォルダには、権限名、紐づくターゲット種類、権限の種類、簡易説明が表示されます。

ページ上の権限を選択・クリックすると、別ページに詳細が表示されます。

  • Comboの権限では、Comboの権限に紐づく権限がリストアップされます。

  • 他の種類の権限では、権限に紐づく属性がリストアップされます。

zmprov のコマンドを使用してcomboの権限を確認できます。

  • Comboの権限の直接のサブ権限を確認します。

    zmprov gr adminConsoleDLRights
  • Comboの第2レベルのサブ権限を確認します。

    zmprov gr adminConsoleDLRights -e

システム定義権限のリストを閲覧する

zmprov コマンドを使用して特定のトピック用のシステム定義権限を確認できます:

Table 51. zmprovを使用してコンボの権限を表示
表示対象 使用する zmprov コマンド

アカウント

zmprov gar -t account

カレンダーリソース

zmprov gar -t calresource

提供サービス(COS)

zmprov gar -t cos

配布リスト [1]


1. アカウントやカレンダーリソース向けの権限はすべて、「ターゲット」配布リスト上でも付与できます。配布リスト上でこうした権限が付与されると、そのACEは、その配布リストの直接のメンバーまたは間接のメンバーである、全アカウントと全カレンダーリソースに、その権限を適用します。

zmprov gar -t dl

ドメイン

zmprov gar -t domain

グローバル設定 [2]


2. アカウントやカレンダーリソース、そして配布リスト向けの権限はすべて、「ターゲット」ドメイン上でも付与できます。ドメイン上で権限が付与されると、そのACEは、そのドメイン内の直接のメンバーまたは間接のメンバーである、全アカウントと全カレンダーリソース、全配布リストに、その権限を適用します。

zmprov gar -t config

グローバル付与 [3]


3. グローバルを除く全ターゲット向けの全権限を「ターゲット」グローバルで付与できます。グローバル付与エントリ上で権限が付与されると、そのACEはシステム上の全エントリにその権限を適用します。例えば(ドメイン向けの権限である)createAccountをグローバル付与エントリ上でAdminAに付与すると、AdminAはそのシステム上の全ドメインでアカウント作成ができます。

zmprov gar -t global

サーバー

zmprov gar -t server

Zimlet

zmprov gar -t zimlet

管理権限の委任を実行する

「委任された管理者」アカウントの作成と権限の付与は、その管理者の役割と、その管理者が管理することになるターゲットに指定する権限を定義してから実施します。

「委任された管理者」を更に効果的に管理するには、管理グループを作成して、そのグループに個々の管理者アカウントを追加します。管理グループにより、アクセス制御を役割ベースで作成できます。同じまたはほぼ同じ役割のある管理者たちを1つの管理グループにまとめられます。

管理権限は、下記のいずれの方法からでも委任できます。

  • 管理ウィザードを使用して、管理者または管理グループを作成し、そのアカウントに権限を付与します。

  • 既存の管理者アカウントに権限を付与します。既存の「委任された管理者」アカウントまたは管理グループのアカウントに、新規・既存の権限を追加・修正します。

  • ターゲットのACLページから直接、権限を追加・編集・削除します。

管理者と管理グループ

管理者と管理グループのアカウントは管理コンソールで作成します。

管理ウィザードの使用目的

  1. 管理グループあるいは管理者アカウントを作成します。

    1. 管理グループ は、管理グループを有効化した配布リスト(DL)です。この有効化が「委任された管理者」のDLであるというフラグです。管理グループの管理者を作成して、権限と管理ビューを設定した後に、その管理者のユーザーアカウントを管理グループに追加します。

    2. 管理者アカウント は、アカウント上の管理者を有効化したユーザーアカウントです。

  2. アカウントの管理ビューを設定します。ビューは「直接割り当てられた管理ビュー」一覧から選択します。管理ビューとは、「委任された管理者」の管理コンソールへのログイン時に表示される項目のことです。

    「直接割り当てられた管理ビュー」とは、管理者アカウント上に設定されているビューです。「継承した管理ビュー」とは、アカウントが所属する管理グループ上に設定されているビューです。

  3. 許可を設定します。 「デフォルトの許可を設定」画面の権限一覧は、「直接割り当てられた管理ビュー」カラムで選択した項目の表示に必要です。これら権限を承認して新しい権限を追加するなら「次へ」、権限を設定したくないならページを「スキップ」、権限を承認してウィザードを閉じるなら 完了 を選びます。

管理者アカウントや管理グループへ権限を付与する

システム管理者は、管理者や管理グループに付与されている権限を、アカウントのツールバーにある「許可を設定」のリンクから管理できます。管理にあるアカウントのアドレスのツールバーで 許可を設定 をクリックすると、直接許可のリストと継承許可のリストが内容ペインに表示されます。既存の管理者アカウント上で、権限の追加・編集・削除ができます。

ターゲットにACLを付与する

特定の被譲与者や特定の権限をターゲット上で追加したいとき、直接、ターゲットを編集できます。ターゲットごとにACLページという、許可されたACL一覧のページがあります。ターゲットの権限の追加・編集・削除ができます。管理者アカウント(被譲与者)は、この変更の反映のため、更新されます。

権限の取り消し

グローバル管理者(システム管理者)は、管理者に付与された権限を取り消せます。

管理コンソール:

ホーム > 管理 > アカウント

対象としたい管理者のアカウント開き、ギアアイコンの 許可を設定 をクリックします。

  1. 取消対象の 権限 をクリックし、削除 をクリックします。

  2. 確認画面で はい をクリックします。

「委任された管理者」が権限を取り消しできるのは、その権限がオプション 他の管理者に権限を与えることが可能 を有効にして作成された場合です。

付与された管理権限を一時的に取り消す

「委任された管理者」アカウントの権限を一時的に取り消す場合、対象の管理者のアカウントで、全般情報にある「管理者」のチェックを外す編集をします。ACLはアカウントから削除されません。

管理者へ付与された権限を閲覧する

管理者アカウントや管理グループのアカウントからギアアイコンの「権限を表示」を選択すると、付与されている権限、特定のターゲットに紐づく読み込み可の属性とその書き込み可の属性が表示されます。様々なターゲット向けの権限を確認するには、各タブをクリックします。

定義済みの委任管理の役割

以下の定義済み「委任された管理グループ」は自動で作成されます。これらグループに管理者アカウントを割り当てることができます。

ドメインの管理グループ

zimbradomainadmins という「委任された管理」グループは、アカウント、エイリアス、配布リスト、リソースについて、Zimbra Collaboration のドメインの管理のサポートに必要な全ての権限を付与します。

「委任された管理グループ」zimbradomainadmins に入っている管理者は、アカウントの作成と、アカウント容量・エイリアス・配布リスト・リソースアカウントの設定を含めたアカウント管理ができます。

ドメイン管理者が管理コンソールにログインすると、彼らによる管理が認められている機能しかナビゲーションペインに表示されません。

Zimbraウェブクライアントから管理コンソールへのリンクを作成する

ドメイン管理者の場合、すべてのタスクは管理コンソール上で行われます。ログインを容易にするため、「委任された管理者」アカウントの作成時に、彼らのZWCアカウントに管理コンソールへのリンクを設置できます。

管理コンソールへのリンクは zmprov のコマンドで作成します。

zmprov md {server.example.com} zimbraWebClientAdminReference {https://server.example.com:7071/}

配布リストの管理グループ

zimbradladmin という「委任された管理グループ」は、管理コンソールへのログインと配布リストの管理に必要となる全ての権限を 付与します。

この管理グループに入っている管理者が実施できること

  • アカウントリストの閲覧

  • 配布リストの新規作成、配布リストの削除

  • 配布リスト内メンバーの追加・編集・削除

「委任された管理者」の役割を作成する

複数ドメインの管理

一人のドメイン管理者に複数のドメインを管理させるには、個々のドメインを管理する権限を管理者アカウントあるいは管理グループに付与します。

例えば、 ドメイン domainexample1.com と ドメイン domainexample2.com を domanadministrator1@example.com に管理させるには、管理されるドメインの1つに新たな管理者アカウントを作成します。

  1. 管理するドメインの1つに(domainexample1.com)管理者アカウントを作成します。

  2. ドメイン管理者がドメインの管理に必要となるビューを選択します。ビューが選択されているとき、こうしたビューに紐づく権限が自動的に「デフォルトの許可を設定」画面に表示されます。

  3. 選択したビューに紐づく許可とは違う許可が必要であれば、このドメインの「追加の許可を設定」します。

  4. 管理されるもう一つのドメイン(domainexample2.com)に以下を追加します。

    • 「追加の許可を設定」画面にて、 追加 をクリックします。

    • ターゲット種類に、 domain を選択します。

    • ターゲット名に、対象ドメイン名(domainexample2.com)を入力します。

    • 権限の種類に、システム定義権限を選択します。

    • 権限名に、adminConsoleAccountRightsを入力します。 肯定的権限ですか(許可) のオプションが選択していることを確認します。

    • 追加/その他 をクリックします。

    • 権限名が空白の ACEを追加 画面が再表示されます。adminConsoleDLRights を入力し、 追加/その他 をクリックします。

    • 上記の手順を次の権限名について繰り返します。

      • adminConsoleAliasRights

      • adminConsoleResourceRights

      • adminConsoleSavedSearchRights

      • adminConsoleDomainRights

    • 上記の権限をすべて追加したら、 追加/完了 をクリックします。 追加の許可を設定 画面に、「ターゲット」ドメインに紐づくこれらの権限が表示されます。管理されるドメインを他にも追加するなら、 追加/その他 をクリックし、手順4から繰り返します。それ以外の場合、 完了 をクリックします。

配布リストの管理

配布リストを管理するユーザーを割り当てるには、配布リストの作成とその管理グループの有効化、ビューの選択、配布リストの権限付与、そのリストへのユーザー追加、そのユーザーの管理者設定、が必要です。

  1. 新規に配布リストを作成します。

    • 管理グループ のオプションにチェックを入れます。

    • 配布リストを管理するユーザーをメンバーとして追加します。

    • 管理者の 管理ビュー ページへ遷移し、 管理者が配布リストを閲覧できるように 配布リストビュー にチェックを入れます。

    • 右上の 保存 をクリックします。

  2. 管理者の 許可を設定 ページを開き、以下の権限を追加します。

    Table 52. 権限
    権限名 ターゲット種類 ターゲット 権限の種類

    以下の権限名を持つ役割で、管理者は配布リストを管理できます。

    listDistributionList

    dl

    DLのメールアドレス

    SD Right

    addDistributionListAlias

    dl

    DLのメールアドレス

    SD Right

    addDistributionListMember

    dl

    DLのメールアドレス

    SD Right

    modifyDistributionList

    dl

    DLのメールアドレス

    SD Right

    getDistributionListMembership

    dl

    DLのメールアドレス

    SD Right

    removeDistributionListMember

    dl

    DLのメールアドレス

    SD Right

    このドメイン権限で、ユーザーのアカウントリストが表示されます。管理者が配布リストに追加するアカウントは、このアカウントリストから選択できます。

    listAccount

    domain

    配布リストのメールアドレス

    SD Right

パスワードを変更する

パスワード変更のみの「委任された管理者」を作成するには、管理者あるいは管理グループを作成し、管理ビューを選択し、Combo権限「setAccountPassword」を付与します。

  1. 以下のビューを選択します。

    • アカウントリストビュー パスワードを変更するアカウントの選択ができます。

    • エイリアスリストビュー アカウント名の代わりにエイリアスを使用しているユーザーを検索できます。

  2. 「許可の設定」ページには、選択してある管理ビュー向けの権限が推奨で表示されます。パスワード変更権限の場合、これら権限は設定しません。 スキップ を選択します。 追加 をクリックして下記権限を追加します。

    権限名 ターゲット種類 ターゲット 権限の種類

    setAccountPassword

    domain

    ドメイン名

    SD Right

“メールを表示”へのアクセス権限

“メールを表示”へのアクセス権限は、アカウント、ドメイン、配布リスト上で付与できます。

権限名 ターゲット種類 ターゲット 権限の種類

adminLoginAs

account, domain, dl

アカウント名、ドメイン名、または配布リストのメールアドレス

SD Right [4]


4. ターゲット上での“メールを表示”権限を否定するには、 否定的権限(拒否) を選択します。

管理者からドメインや配布リストにいるアカウントを閲覧できないようにするには、そのアカウントに 否定的権限(拒否) を設定します。

ユーザーに割り当てられている提供サービスの管理

ユーザーに割り当てられている提供サービス(COS)の閲覧と変更ができるように、ドメイン管理者の役割を拡大できます。ドメインのCOSを管理する権限を登録するには、以下の権限をドメイン管理者アカウントあるいはドメイン管理グループに追加します。

システム定義権限をドメインにある各COSに追加します。

Table 53. 提供サービスのシステム定義権限
権限名 ターゲット種類 ターゲット 権限の種類

listCos

cos

COS name

SD Right

getCos

cos

COS name

SD Right

assignCos

cos

COS name

SD Right

このドメイン権限で、ユーザーアカウントの全般情報に提供サービス情報が表示されます。

zimbraCOSId

domain

ドメイン名

Attribute Right
Verb: Write
AR Target: account

メールボックスのクロス検索の管理

以下の権限名を持つ役割で、アカウントの現在およびアーカイブ内のメール検索を実行する「委任された管理者」の役割を作成します。管理者はメールボックスのクロス検索リクエストの作成・中止・削除・パージ・ステータス確認もできます。

この機能を使用するには、アーカイブとディスカバリ機能がインストールされていなければなりません。
権限名 ターゲット種類 ターゲット 権限の種類

adminConsoleCrossMailboxSearchRights

(combo)

メールボックスのクロス検索が実行されるサーバー名

SD Right

全機能の利用のため、この役割にはアカウント作成機能も含まれています。管理者が検索結果を受け取るターゲットメールボックスを作成できるようにするためです。この役割にアカウント作成機能を持たせたくない場合は、以下の否定的権限も付与します。

権限名 ターゲット種類 ターゲット 権限の種類

CreateAccount

domain

ドメイン名

SD Right [5]


5. ターゲット上でのアカウント作成権限を否定するには、 否定的権限(拒否) を選択します。

メールボックスのクロス検索結果の入ったターゲットメールボックスを管理者に閲覧させたい場合、そのメールボックスだけを閲覧できる権限を付与します。

権限名 ターゲット種類 ターゲット 権限の種類

adminLoginAs

account

メールボックスのクロス検索のターゲットアカウント名

SD Right [6]


6. ターゲット上での“メールを表示”権限を否定するには、 否定的権限(拒否) を選択します。

Zimletを管理する

以下の権限名を持つ役割で、Zimletの作成・配備・閲覧ができる「委任された管理者」の役割を作成できます。

権限名 ターゲット種類 ターゲット 権限の種類

adminConsoleZimletRights

server, domain

サーバ名またはドメイン名

SD Right

adminConsoleAccountsZimletsTabRights

server, domain

サーバ名またはドメイン名

SD Right

リソースを管理する

以下の権限名を持つ役割で「委任された管理者」はリソース作成・管理ができます。

権限名 ターゲット種類 ターゲット 権限の種類

adminConsoleResourceRights

combo

サーバ名、またはドメイン名

SD Right

保存された検索へのアクセス

以下の権限名を持つ役割で「委任された管理者」は管理コンソールのナビゲーションペインにある検索セクションに保存された全ての検索クエリにアクセスできます。

権限名 ターゲット種類 ターゲット 権限の種類

adminConsoleSavedSearchRights

combo

サーバ名、またはドメイン名

SD Right

サーバーのステータスページへのアクセス

以下の権限名を持つ役割で「委任された管理者」はサーバーのステータスページを閲覧できます。この権限の付与だけでなく、管理ビューの グローバルサーバーステータスビュー も選択する必要があります。

権限名 ターゲット種類 ターゲット 権限の種類

adminConsoleServerStatusRights

global

SD Right

グローバル管理者アカウントとして設定されているアカウントにはACLを付与できません。グローバル管理者アカウントは、自動的にZCS上の全権限を保持しています。グローバル管理者アカウントにACLが追加されたとしても、無視されます。「委任された管理者」アカウントがグローバル管理者アカウントへと変更されたら、そのアカウントに紐付いているACLはすべて無視されることになります。

ZCS サーバーの監視

Zimbra Collaboration (ZCS) では、Zimbraサーバーの状態、使用容量、メールのフローの監視のため、以下の機能を提供しています。

  • Zimbra のLoggerパッケージでサーバーの統計やステータスの収集・表示と日次夜間レポートを発行します。

  • メールボックスの割り当て容量監視

  • MTAのメールキュー監視

  • ログファイル

また、特定のエラーメッセージでSNMPトラップを作成し、SNMPのツールで監視することができます。

システム全体のヘルスチェックはこのドキュメントの範囲対象外です。

Zimbra Logger

LoggerにはSyslogの情報収集とレポート作成のツールが含まれています。Loggerのインストールは任意ですが、インストールしていない場合、サーバーの統計やステータス情報は収集されません。

複数の Zimbra Collaboration サーバーをご利用の環境では、Loggerは一つのメールボックスサーバーのみで有効にします。このサーバーはサーバー監視のホストとなります。監視ホストは他のZimbra Collaborationサーバーのステータスをすべて確認し、Zimbraの管理コンソール上に情報を表示します。リアルタイムでサービスのステータス、MTA、迷惑メール対策/ウイルス対策トラフィック、パフォーマンスの統計を表示できます。また、Loggerは日次で、毎日のメッセージ数、平均到達遅延、発生したエラーなどのメール運用状況レポートを作成します。

マルチサーバーの環境では、各サーバーにsyslog設定ファイルをセットアップし、管理コンソール上でサーバー統計が表示できるようにしてください。加えて、Loggerのホストを有効にする必要があります。 Zimbra Collaboration のインストール時にこの設定をしていない場合、今すぐ実行してください。

サーバー統計を有効にする

サーバーの統計を有効にすると、過去の48時間、30日間、60日間、1年間の間に処理したメッセージ分の、インバウンドのメッセージボリューム、インバウンドのメッセージ数、迷惑メール対策/ウイルス対策アクティビティ、ディスクの使用容量を、システム全体やサーバー単位で確認できます。

  1. 各サーバーでRootユーザーにて /opt/zimbra/libexec/zmsyslogsetup を実行します。サーバー統計の収集ができるようにSyslog設定ファイルが更新されます。

  2. Loggerの監視ホストでは、リモートマシンのsyslogメッセージを受けとるために syslog を有効化します。 詳細は https://wiki.zimbra.com/wiki/Configuring-Logger-Host を確認してください。

上記の手順はシングルサーバーの環境では必要ありません。

サーバーステータスを監視する

管理コンソール:

ホーム > 監視

Server Status のページに、すべてのサーバーとサービス、それらのステータス、最後にチェックされたサーバーステータスがリストアップされます。サーバーには、MTA、LDAP、メールボックスサーバーが含まれています。サービスにはMTA、LDAP、メールボックス、SNMP、迷惑メール対策、ウイルス対策、スペルチェック、Loggerが含まれています。

停止しているサーバーを始動するには zmcontrol のCLIコマンドを使用します。管理コンソールからもサービスの開始と停止ができます。

サーバーのサービスの有効化/無効化

管理コンソール:

ホーム > 設定 > サーバー → サーバー名

サーバーのサービスは サーバー → サーバー名 ページで有効化/無効化します。ナビゲーションペインの サービス をクリックし、有効化/無効化するサービスを選択します。

サーバーのパフォーマンス統計

LoggerのパッケージをZimbraのメールボックスサーバーへインストールした場合、サーバー統計には、メッセージ数、メッセージボリューム、迷惑メール対策/ウイルス対策のアクティビティが棒グラフで表示されます。過去の48時間、30日間、60日間、365日間の情報を表示します。

ナビゲーションペインで各サーバー統計を選択すると、すべてのメールボックスサーバーを統合した統計が表示されます。「サーバー統計」にて、特定のサーバーをダブルクリックすると、そのサーバーの関連統計のみ、閲覧できます。また、サーバー固有の情報としてディスクの使用容量、セッション情報、メールボックスの割り当て容量も閲覧できます。

システム全体の情報は次のとおりです。

  • メッセージ数 — メッセージのトランザクション数。トランザクションとは、ユーザーごとの(Postfixによる)メッセージSMTP受信または(mailboxdによる)LMTP配信です。例えば、メッセージ1件が3人へ送信されるとき、トランザクション数は6です。PostfixへのSMTPが3回、mailboxdへのLMTPが3回です。メッセージ数は6回ごとに増分します。

  • メッセージボリューム — 1時間単位と1日間単位で処理したバイトサイズを表示します。グラフは全体のインバウンドデータをバイト単位で表示します。

  • 迷惑メール対策/ウイルス対策アクティビティ — 迷惑メールやウイルスがあるかどうかを検査したメッセージ数と、迷惑メールとしてタグ付けされたまたはウイルスが感染していると判断されたメッセージ数が表示されます。AS/AVの合計は、スキャンされたメッセージごとに1つ増えます。メッセージ1件が3人へ送信されるとき、AS/AVではメッセージ1件しか処理されません。

    メッセージ数と迷惑メール対策/ウイルス対策アクティビティのグラフは、以下の理由によりメッセージ数が異なります。

    • システム構成によってはアウトバウンドメッセージのチェックが必要とされないため、Amavisdのフィルターを通過しない可能性があります。

    • メッセージの宛先へ配信される前に、メッセージはAmavisdで迷惑メールやウイルスがスキャンされています。メッセージ数はメッセージを実際に受信者が受信した件数を表します。

サーバー固有の情報には以下も含まれます。

  • ディスク — 選択したサーバーの使用中のディスク容量と空のディスク容量が表示されます。直近の1時間、1日、1か月、1年間の情報が表示されます。

  • セッション — アクティブなウェブクライアント、管理者、IMAPのセッション情報が表示されます。オープンされているアクティブセッション、ログインユーザー、セッションが作成された日時、セッションが最後にアクセスされた日時を確認できます。

  • メールボックスの割り当て容量 — 各アカウントの情報が、メールボックスサイズの降順に表示されます。詳細は メールボックスの割り当て容量を監視する を参照してください。

Loggerのメールレポートを設定する

Loggerは、メールのアクティビティについてのレポートを毎日23:30に発行し、管理者のメールアドレスへ送信します。

レポートに含まれるアカウント数を設定できます。デフォルトは、送信者アカウントが25、受信者アカウントが25です。

  • 受信アカウントの最大数を変更します。

    zmlocalconfig -e zimbra_mtareport_max_recipients=<数字>
  • 送信アカウントの最大数を変更します。

    zmlocalconfig -e zimbra_mtareport_max_senders=<数字>

ディスク容量の通知を設定する

定期的にディスクの使用容量を確認し、ディスクの空き容量が少ない際にはサービスの継続維持のための対策をとることが重要です。ディスク空き容量が少なくなると、管理者アカウントに警告メールメッセージが自動送信されます。デフォルトの設定では、ディスク使用率85%で警告メッセージが、ディスク使用率95%で重要な警告メッセージが送信されます。

この条件は変更可能です。zmlocalconfig を使用し、警告メッセージのためのディスクのしきい値を変更します。

  • 警告のメッセージ

    zmdisklog_warn_threshold
  • 重要な警告メッセージ

    zmdisklog_critical_threshold

zmcontrolでのサービス起動時にこのしきい値を超えていると、サービスの開始前に警告が表示されます。ディスクをクリーンアップして、空き容量を増やしてください。

サーバーの監視

Zimbra Collaboration サーバーでは、複数のパフォーマンス用統計を収集しているため、問題や負荷の障害のトラブルシューティングに役立ちます。

管理コンソール:

ホーム > 監視 > 高度な統計

高度な統計 のページにて、CPU, IO, mailboxd, MTAのキュー、MariaDBなどのコンポーネントについての統計情報に基づく様々な図表を高度なグラフのオプションで生成できます。

高度な統計グラフを表示するには、グループ項目から1つ選択し、カウンターリストから表示する情報を特定します。

幅広いデータから情報を取得できます。

  • cpu.csv — CPUの使用率。このグループは、CPU使用をトラッキングし続けるカウンターを含みます(iowait, idle, system, user, time等)。 CPU情報はサーバーレベルやプロセスレベルでトラッキングできます。

  • df.csv — ディスクの使用率。ディスクパーティションごとにトラッキングされます。

  • fd.csv — ファイル記述子のカウント。システムファイルの記述子の使用超過時間をトラッキングし続けます。主に「ファイル記述子が足りない」エラーをトラッキングするための機能です。

  • mailboxd.csv — Zimbra Collaboration サーバーとJVMの統計。Mailboxdの統計がほぼ全てです。役に立つカウンター値にはheap_used, heap_free, imap_conn, soap_sessions, pop_conn, db_conn_count があります。

  • mtaqueue.csv —  Postfixのキュー。メッセージ数とバイト単位でのサイズにによって、メールのキューサイズを計算します。

  • proc.csv — Zimbraプロセスのプロセス統計です。例えば、mailboxd/java, MariaDB, OpenLDAP など。

  • soap.csv — SOAPリクエストのプロセス時間。

  • threads.csv — JVMのスレッドカウント。接頭語が一致しているスレッド数を数えます。

  • vm.csv — (vmstatコマンドからの)Linux VMの統計。

  • io-x.csvio.csv — iostat(1) のコマンド (io-x.csviostat -x) からのストアデータ。

DoSのフィルター条件を設定する

過剰な負荷をかけるリクエストはdenial-of-serviceフィルター (DoSFilter) により制限されます。DoSFilterでは、短時間に大量のリクエストを送信しているクライアントを抑制します。

なお、DosFilter は HTTP と HTTPS リクエストにのみ適用されますので、他のプロトコル、たとえば POP3、IMAP、および SMTP には適用されません。ご利用の環境に合わせて設定を変更できます。ZCSではデフォルトでDoSFilterは有効です。DoSFilterの無効化は推奨しません。連続でのログイン失敗を回避する詳細につきましては、 ログインポリシーを管理する をご参照ください。

False Positiveを判断する

時折、Zimbra Connector for Outlook (ZCO)、モバイルActiveSyncのクライアント、あるいはzmprovコマンドを何か 実行することで、DoSFilterが起動されることがあります。そうすると、Zimbraのメールボックスサービスは使用できなくなります。DoSFilterが適用されたかどうかを以下のログから確認できます。

  • /opt/zimbra/log/sync.log

Example 17. DoSFilterを表示している sync.log のエントリ
2013-01-15 15:52:20,426 WARN [qtp1635701107-91:https://x.x.x.x/
Microsoft-Server-ActiveSync?User=zsupport2&DeviceId=Appl5ddddd3NR&DeviceType=iPhone&Cmd=FolderSync][name=zsupport2@domain.com;mid=64;ip=10.1.2.3;Cmd=FolderSync;DeviceID=Appl5K0113UN3NR;Version=12.1;] sync - Service exception com.zimbra.common.service.ServiceException: error while proxying request to target server: HTTP/1.1 503 Service Unavailable
ExceptionId:qtp1635701107-91:https://10.10.0.54:443/Microsoft-Server-ActiveSync?User=zsupport2&DeviceId=Appl5K0113UN3NR&DeviceType=iPhone&Cmd=FolderSync:1358286740426:c5ca7f36bb0a038f Code:service.PROXY_ERROR Arg:(url, STR,"http://mail.domain.com:80/service/soap/SyncRequest"
  • /opt/zimbra/log/zmmailboxd.out

Example 18. DoSFilterを表示している zmmailboxd.out のエントリ
2013-01-15 15:57:32.537:WARN:oejs.DoSFilter:DOS ALERT:ip=127.0.1.1,session=null,user=null

DOSFilterの設定をカスタマイズする

以下の属性を使用して、zmprovでDoSFilterを設定します。これらの属性は、グローバル設定またはサーバー設定として設定できます。サーバーに設定すると、サーバー設定がグローバル設定をオーバーライドします。

設定は変更できますが、デフォルトの設定を推奨します。

属性 説明

DoSFilterの延長期間
zimbraHttpDosFilterDelay-Millis

レート制限を超えたリクエストに与えられる延長期間です。デフォルトの値は-1です。

  • -1 = リクエストを拒否する。

  • 0 = 延長期間なし(直ちに処理)。

  • その他の値 = 延長期間。単位はミリ秒(ms)。

zmprov mcf zimbraHttpDosFilterDelayMillis {x}

1秒間にリクエストできる最大DoSFilter 数
zimbraHttpDosFilterMaxRequestsPerSec

一つの接続の1秒あたりの最大リクエスト数です。この値以外のリクエストは抑制されます。デフォルトの値は30で最小値は1です。

zmprov mcf zimbraHttpDosFilterMaxRequestsPerSec {x}

DoSFilter IP アドレスのホワイトリスト
zmprov mcf zimbraHttpThrottleSafeIPs {x.x.x.x,192.168.x.x}

DoSFilterの適用時、無視されるIPアドレス。デフォルトの値はありませんが、以下のループバックIPはデフォルトでホワイトリストに記載されています。

  • 127.0.0.1

  • ::1

IPアドレスはカンマで区切ります。

zmprov mcf zimbraHttpThrottleSafeIPs {addresses}

上記属性の変更後は、メールボックスサーバーの再起動が必要です。

zmmailboxdctl restart

ZCS 8.0.3 以降のバージョンでのチューニング課題

  • ZCS メンバーサーバー —  シングルのマスターLDAPで管理しているZCSサーバーは自動的にIPアドレスでホワイトリストに記載されます。こうしたホストは GetAllServersRequest から分かります。 zmprov gas として入力してください。

  • 外部プロビジョンのホスト/SOAP API — 外部プロビジョンのホストをIPホワイトリストに追加して、DoSFilterが特定のリクエストを確実にブロックしないようにできます。例えば、メールボックスの再インデックスは、1秒間に複数のリクエストを発生させてDoSFilterを起動させる恐れがあります。

メールキューを使用する

Zimbra MTAのメール受信時、配信管理のため、メールを次のキューに回しします:受信、アクティブ、遅延、保持、破損。

受信 のキューは受信した新着メールを保持します。各メッセージは固有のファイル名で識別されます。アクティブのキューに空きがあると、アクティブキューに移されます。通常動作では、メッセージはこのキューから即座に他のキューに移されます。

アクティブ キューは、送信できる状態のメッセージを保持します。MTAは、アクティブキューに一度に保持できる最大メッセージ数を設定しています。ここから、メッセージはウイルス対策と迷惑メール対策のフィルターに回され、戻ってきてから、他のキューに移されます。

配信できなかったメッセージは 遅延 キューに置かれます。配信失敗の理由は遅延キュー内のファイルに記録されます。このキューは、メッセージ再送信のために頻繁にスキャンされます。設定された最大配信試行回数を超えるとメッセージの送信が失敗します。メッセージは元の送信者にバウンスされます。デフォルトのバウンスキュー保持期間は5日間です。

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

破損 キューには、破損して読み込みできないメッセージが格納されます。

バウンスキュー保持期間を変更する

  • MTAサーバーのバウンスキュー保持期間は5日間に設定されています。このデフォルトのキュー保持期間設定を変更します。

    zmlocalconfig -e bounce_queue_lifetime={#}
  • 恒久的にメッセージを送信者へ返送して、最初に遅延キューに移動することはしません。

    zmlocalconfig -e zimbraLmtpPermanentFailureWhenOverQuota=TRUE

バウンスされたメッセージを送信者に通知する

バウンスキュー保持期間でメッセージを送信者に返送する前に、送信者は、送信メッセージが配信されずに遅延キューにある旨の通知を受け取ることができます。

以下の属性を設定して、送信者に警告メッセージを送信する設定をします。

  • まだキューにあるメッセージのヘッダーに、送信者が受け取るまでの期間を設定します。

    zmlocalconfig -c postfix_delay_warning_time=0h
  • MTAが配信しなかったメッセージのヘッダーに、Postmaster通知の受信者を設定します。

    zmlocalconfig -c postfix_bounce_notice_recipient=postmaster
  • Postmasterに報告されるエラークラスのリストを設定します。

    zmlocalconfig -c postfix_notify_classes=resource,software
こうしたPostfix属性を変更することによる影響の詳細は、Postfixのドキュメントを参照してください。

メールキューを管理コンソールから監視して、配信問題を確認できます。

メールキューを閲覧する

管理コンソール:

ホーム > 監視 > メールキュー

メール配信で問題が生じている場合、管理コンソールの メールキュー ページからメールキューを閲覧し、メール配信問題を改善できるかどうかを検討することができます。メールキューを開くと、その時点での遅延、受信、アクティブ、保持、破損のキュー内容を閲覧できます。メッセージ数、配信元、配信先も閲覧できます。

キューごとの要約ペインで受信者のドメイン、起点IP、送信者のドメイン、受信者アドレス、送信者アドレスによる要約を確認できます。遅延のキューではエラーのタイプからも確認できます。要約の項目を選択すると、メッセージペインで、メッセージのエンベロープ情報の詳細を確認できます。

メッセージペインでは、要約ペインで選択した検索フィルター結果であるメッセージの詳細なエンベロープ情報が表示されます。

以下のメールボックスキューの動作は、キューにあるすべてのメッセージに適用されます。

  • 保持 で、一時的に配信停止したいメッセージを選択します。受信、アクティブ、遅延、破損のメッセージを、この保持キューに移動できます。管理者がマニュアルで別のキューに移さない限り、保待キューに留まります。

  • 解放 で、保持キューにあるメッセージをすべて解放します。こうしたメッセージは遅延キューに移されます。

  • キューへの再配置 で、閲覧中のキューにあるメッセージをすべて再配置します。メッセージの再配置は、設定の問題で遅延していたメッセージを、その問題が修正された後に送信するために使うことができます。メッセージは再度判定されるため、これまでのペナルティはリセットされます。

  • 削除 で、閲覧中のキューにあるメッセージをすべて削除します。

Zimbra MTA、PostfixキューファイルIDは再利用されます。メッセージの再配置や削除では、キューIDではなく、メッセージのエンベロープ情報をメモしてください。メールキューのリフレッシュ時、キューIDが別のメッセージに再利用されることが起こり得ます。

メッセージキューをフラッシュする

サーバーのすべてのメッセージは、フラッシュできます。メールキューのツールバーからフラッシュをクリックすると、配信はただちに、遅延キュー、受信キュー、アクティブキューにある全メッセージについて実行されます。

メールボックスの割り当て容量を監視する

メールボックスの割り当て容量は、ユーザーアカウントにある、メールメッセージ、添付ファイル、カレンダー予定、タスクに適用されます。この上限に達すると、全メールメッセージは拒否されます。ユーザーは、アカウントからメールを削除して、ゴミ箱を空にすることも含めて、容量を下回らせる必要があります。あるいは、管理者が上限を引き上げるという選択肢もあります。

割り当て容量を閲覧する

管理コンソールの サーバー統計 から、個々のアカウントのメールボックスの割り当て容量を確認できます。メールボックスの割り当て容量ページでは、アカウントごとのメールボックスのサイズと使用中の容量を簡単に確認できます。

管理コンソール:

ホーム > 監視 > サーバー統計

  1. 統計を確認したい サーバー名 を選択します。

  2. ナビゲーションペインにて、メールボックスの割り当て容量 を選択します。メールボックスの割り当て容量ページに以下の情報が表示されます。

    • 割り当て容量のカラムは、アカウントに割り当てられているメールボックスの容量を表します。割り当て容量は提供サービスまたは各アカウントに設定できます。

    • メールボックスのサイズのカラムは、現在使用中のディスク容量を表します。

    • 使用中の割り当て容量のカラムは、使用されている容量の割合を表します。

割り当て容量を増減させる

提供サービスまたは各アカウントから、容量のしきい値を設定できます。設定すると、到達時、メールボックスの割り当て容量が上限に近い旨を知らせる警告メッセージがユーザーに自動送信されます。

管理コンソール:

ホーム > 設定 > 提供サービス → 提供サービス名 → 詳細設定
ホーム > 管理 > アカウント → アカウント名 → 詳細設定

  1. 「割り当て容量」のセクションまでスクロールダウンします。

  2. 割り当て容量設定を変更します。

  3. 保存 をクリックします。

MobileSyncの統計を閲覧する

管理コンソールの監視セクションにある MobileSync統計 ページには、Zimbra Collaborationのシステム上で現在接続中のActiveSync端末数が表示されます。

認証の失敗を監視する

辞書攻撃や分散攻撃を防ぐために、zmauditwatch を設定できます。このスクリプトでは、更に高度な攻撃を検出しようとしています。そのため、認証の失敗が起きている場所とその頻度を、Zimbraメールボックスサーバーの全アカウントについて確認します。そして、管理者のメールボックスに警告通知を送信します。

認証の失敗の確認タイプ

  • IP/アカウントのハッシュ確認 — デフォルトでは、IP/アカウントの組み合わせで60秒以内に10回、認証が失敗したら警告メールを送信します。

  • アカウント確認 — デフォルトでは、IPアドレスを問わず60秒以内に15回、認証が失敗したら警告メールを送信します。この確認では、特定のアカウントへのハイジャックベースの分散攻撃を検出しようとしています。

  • IP確認 — デフォルトでは、あるアカウントを問わず60秒以内に20回、認証が失敗したら警告メールを送信します。この確認では、複数アカウントをまたいだ特定のホストベースの攻撃を検出しようとしています。

  • 完全な認証失敗の確認 — デフォルトでは、IPアドレスとアカウントを問わず、60秒以内に1000回、認証が失敗したら警告メールを送信します。デフォルトは、メールボックスサーバーにあるアクティブアカウントの1%になるように、修正する必要があります。

メール警告のトリガーとなるデフォルト値は、以下のzmlocalconfigパラメーターで変更します。

  • IP/アカウントハッシュ値は、zimbra_swatch_ipacct_threshold を変更します。

  • アカウント確認には、 zimbra_swatch_acct_threshold を変更します。

  • IP確認には、 zimbra_swatch_ip_threshold を変更します。

  • 完全な認証失敗の確認には、 zimbra_swatch_total_threshold を変更します。

zimbra_swatch_notice_user には、警告を受け取る必要のあるメールアドレスを設定します。

ログファイルを閲覧する

Zimbra Collaboration の動作やエラーは、syslogデーモン経由で統合されたシステムログとローカルファイルシステム上のZimbra専用ログファイルに記録されます。以下のログファイルがプライマリログです。調査やトラブルシューティングに使用されます。 Zimbra Collaboration の動作が記録されるローカルログは /opt/zimbra/log ディレクトリにあります。

  • audit.log — このログには、ユーザーと管理者の、認証アクティビティ情報とログインの失敗が入ります。加えて、設定の変更をトラッキングできるように管理者によるアクティビティも入ります。

  • clamd.log — このログには、ウイルス対策アプリclamdのアクティビティが入ります。

  • freshclam.log — このログには、clamdのウイルス定義更新に関するログ情報が入ります。

  • mailbox.log — このログは、mailboxdのlog4jサーバーログで、メールボックスサーバーのログが入ります。これには、メールボックスストア、LMTPサーバー、IMAPとPOPサーバー、Indexサーバーが含まれます。

  • myslow.log — このスロークエリーログには、実行に long_query_time 以上の秒数がかかった、メールボックスサーバーの全SQL文が入ります。

    long_query_time/opt/zimbra/conf/my.cnf 内に定義されています。
  • spamtrain.log — このログには、cronから定期的にスケジュールされた zmtrainsa の実行中の出力が入ります。

  • sync.log — このログには、Zimbra Collaboration のモバイルシンク動作についての情報が入ります。

その他のログ

  • /opt/zimbra/jetty/logs/ — ここにJetty固有のアクティビティが記録されます。

  • /opt/zimbra/db/data/<hostname>.err — メッセージストアデータベースのエラーログです。

  • /opt/zimbra/logger/db/data/<hostname>.err — Loggerデータベースのエラーログです。

システムのsyslogに記録されるZimbra Collaboration のアクティビティ

  • /var/log/zimbra.log — Zimbraのsyslogで、Zimbra MTA(Postfix、amavisd、迷惑メール対策、ウイルス対策)、Logger、認証(cyrussasl)、ディレクトリ(OpenLDAP)のアクティビティの詳細が分かります。デフォルトでは、LDAPのアクティビティは zimbra.log にログ出力されます。

Syslog

Zimbra Collaboration は、システムのsyslogデーモンを修正して、メールとローカルsyslogファシリティのデータを /var/log/zimbra.log に取得するようにしています。この修正により、syslogdが、Zimbra Collaboration コンポーネントであるPostfix、Amavis、ClamAV、mailboxd、zmconfigd、Loggerから、 データを取得できます。SNMPモジュールはログファイルのデータを使用して、致命的なエラー用のトラップを作成します。zmloggerデーモンも、このファイルにあるデータを集めて、管理コンソールから Zimbra Collaboration の使用率の統計を提供できるようにしています。

デフォルトでは、mailboxdは出力内容を /opt/zimbra/log/mailbox.log にはくように設定されています。mailboxdがcentralizedsyslogdインフラを利用できるように、グローバルに、またはサーバーで下記を実行します。

zmprov mcf zimbraLogToSysLog TRUE

log4jを使用し、ログ情報をカスタムに設定する

Zimbra Collaboration サーバーは、ログマネージャーに log4j のJavaログパッケージを使用しています。デフォルトでは、 log4j にローカルシステムへログ出力させるように設定しています。他の場所に直接出力するように log4j を設定できます。log4j の利用について詳細は、log4j のウェブサイト Log4j website を確認してください。

ZCSは、log4jの変更をチェックしません。全アカウントのLoggerを削除し、 /opt/zimbra/conf/log4j.properties 内にリロードするには、 zmprov resetAllLoggers コマンドを使用します。

ログの詳細レベル

デフォルトのログレベルは、INFO、WARNING、ERROR、FATALで作成されるログを含めるように設定されています。問題が発生し始めたら、DEBUGやTRACEのレベルを有効にできます。

ログのレベルを変更するには、log4j のプロパティ、 log4j.propertieslog4j.logger.zimbra を編集します。

DEBUGを有効にする場合、特定のカテゴリをデバッグすることもできます。例えば、POP動作に関するデッバグ情報を確認するには、 logger.zimbra.pop=DEBUG を使用します。

log4j 内にあらかじめ定義されているカテゴリ:

zimbra.account

アカウントの操作

zimbra.acl

ACLの操作

zimbra.backup

バックアップと復元

zimbra.cache

Inmemoryのキャッシュ操作

zimbra.calendar

カレンダーの操作

zimbra.dav

DAVの操作

zimbra.dbconn

データベースの接続トレース

zimbra.extensions

サーバー拡張のローディング

zimbra.filter

メールのフィルターリング

zimbra.gal

GALの操作

zimbra.imap

IMAPプロトコルの操作

zimbra.index

Indexの操作

zimbra.io

ファイルシステムの操作

zimbra.ldap

LDAPの操作

zimbra.lmtp

LMTPの操作(受信メール)

zimbra.mailbox

基本的なメールボックス操作

zimbra.misc

その他

zimbra.op

メールボックス状態の変更

zimbra.pop

POPプロトコルの操作

zimbra.redolog

Redoログの操作

zimbra.security

セキュリティイベント

zimbra.session

ユーザーのセッショントラッキング

zimbra.smtp

SMTPの操作(送信メール)

zimbra.soap

SOAPプロトコルの操作

zimbra.sqltrace

SQLのトレース

zimbra.store

メールストアのディスク操作

zimbra.sync

シンククライアントの操作

zimbra.system

スタットアップ/シャットダウン等のシステムメッセージ

zimbra.wiki

Wikiの操作

zimbra.zimlet

Zimletの操作

ログレベルへの変更は直ちに適用されます。
Table 54. ログイベント
レベル ローカル? Syslog SNMPトラップ 使用時

FATAL

Y

Y

Y

アプリケーションを停止するか大多数のユーザーに影響が及ぶほどのかなり深刻なエラーイベントが指定されます。例えば、MariaDBのデータベースに接続できない等。

ERROR

Y

Y

N

アプリケーションが継続実行できるか特定のユーザーのみに影響があるようなエラーイベントが指定されます。例えば、シングルメールボックスのインデックスの破損や、メールボックスからメッセージを削除できない等。

WARN

Y

N

N

潜在的な問題になりそうな状況であるものの回復が可能または無視しても良いものが指定されます。例えば、ユーザーログインの失敗等。

INFO

Y

N

N

アプリケーションの進捗や基本的なトランザクションレベルのロギングを知らせる情報メッセージが指定されます。例えば、サーバーの起動、メールボックスの作成・削除、アカウント作成等。

DEBUG

Y

N

N

お客様が問題をデバッグするのに一般的に役立つようなイベント。

※ いくつかの重要でないメッセージ、例えばサービスの開始メッセージ、はトラップを作成します。

プロトコルトレース

プロトコルのトレースは以下のログカテゴリで使用できます。

zimbra.smtp
zimbra.lmtp
zimbra.soap
zimbra.imap
zimbra.imap-client
zimbra.pop
zimbra.pop-client

mailbox.logを確認する

mailbox.log ファイルには、メールボックスサーバー上で実行されたアクション、例えば、認証セッション、LMTP、POP3、IMAP、Indexサーバーを含めて、全アクションが入ります。 mailbox.log を確認して、サーバーの健康状態のチェックや、問題の識別に役立てます。

mailbox.log は、有効・無効なログイン試行、アカウントのアクティビティ、例えば、メールオープン、アイテムの削除や作成、新着メッセージのインデックス化等と、サーバーの開始・停止などのサーバーのアクティビティを記録します。メールサーバー上のアクティビティの進捗は、INFOとして記録されます。期待したアクティビティ結果にならずエラーが発生した場合、エクセプションがログに記録されます。

シングルアカウントに、ログオプションをセットアップして、1ユーザー分のアカウントアクティビティをトレースできます。これにより、無関係のアカウント分のログメッセージで、mailbox.logがいっぱいにならずに済みます。 詳細は、コマンドラインのユティリティにある zmprov のその他のセクションを参照してください。

ログのパターン

デフォルト設定では、 mailbox.log のログメッセージは以下の Log4j パターンを使用しています:

%d %-5p [%t] [%z] %c{1} - %m%n

このパターンではデータが6ブロックとなります:

  • 日時 (実例: 2018-01-22 19:23:07,100)

  • ログレベル (実例: INFO)

  • スレッド名 (実例: [qtp1043351526-547:https:https://localhost:7071/service/admin/soap/DeleteAccountRequest], [Index-9], など)

  • Zimbra Collaboration の関連

  • コンポーネント名 (実例: soap, mailbox, mbxmgr, など)

  • ログメッセージ 注意: ログメッセージが複数行で記録される場合があります。ログメッセージに例外が含まれている場合、スタックトレースは必ずエラーメッセージの下に新しい行で記録されます。

Log4j パターンの詳細につきましては、 Log4j PatternLayout documentation をご参照ください。

mailbox.log のスレッド名

内部コンポーネントを特定するため、mailbox.log のスレッド名には特定のプレフィックスが付けられます。ほとんどのスレッドは次の条件で指定されます: "{スレッドのプレフィックス}-{スレッド番号}" または "{スレッドのプレフィックス}-{スレッド番号}:{url}".

なお、Zimbra Collaboration にはこれらの {スレッドプレフィックス} 値を使用しております: btpool, pool, LmtpServer, ImapServer,ImapSSLServer, Pop3Server, Pop3SSLServer, ScheduledTask, Timer, AnonymousIoService, CloudRoutingReaderThread, GC, SocketAcceptor, Thread, qtp.

qtp のプレフィックスとなるスレッドは Jetty の QueuedThreadPool により発行しており、異なるネーム条件があります: "qtp{ハッシュコード}-{スレッド番号}:{url}" {ハッシュコード} はスレッドのオーナーとなる QueuedThreadPool のインスタンスのハッシュコード値となります。(詳細につきましては Java プラットフォームのドキュメンテーションから Object::hashCode をご参照ください)

スレッド名の {スレッド番号} の数はスレッドファクトリ毎に一つずつ増加していきます。mailboxd プロセスが停止、または再起動された場合、スレッド番号がリセットされます。

以下の事例のように、SOAPリクエストを処理するスレッドの記録するログメッセージは、スレッド名に送信したリクエストのURLを {url} に記録する場合が多いです。

Mailbox Log Entry for SOAP

Zimbra Collaboration の既知のバグにより、以下の事例のようにスレッド名の {url} 部分に、プロトコルを特定できるプロトコル情報が重複して含まれる場合があります。

[qtp1043351526-547:https:https://localhost:7071/service/admin/soap/DeleteAccountRequest]

  • mailbox.log で Zimbra Collaboration の関連*

ログパターンの [%z] セクションが Zimbra Collaboration の関連性を表しており、`key=value`で属性と値のペアを「;」の文字で区切っています。値に「;」文字が含まれている場合、「;;」として記入されます。たとえば、browser UserAgent のストリングは「;」の文字がよく使われています。実例: "Mozilla/5.0 (Windows NT 10.0; Win64; x64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/61.0.3163.100 Safari/537.36" mailbox.log ではこの UserAgent のストリングは以下のように表示されます:

ua value with double semi-colon

現在、以下の属性と値のペアがサポートされており、異なる順番や組み合わせでログメッセージに記録される場合があります。

  • ip — リクエストする TCP/IP クライアントの IP アドレス

  • oip — 送信元の IP アドレス。NGINX のプロキシ経由でリクエストを送信した場合、この値はクライアントアプリのIPアドレスが含まれますが、ip の属性値はプロキシサーバの IP アドレスとなります。

  • cid — 順番に増加するサーバのコネクションID - 特定のコネクションを監視する場合に役立ちます。

  • id — ターゲットアカウントの ID

  • name — ターゲットアカウントの名前 (メールアドレス)

  • aid — 認証されたアカウント ID。認証したアカウントとターゲットアカウントが異なる場合にのみ表示されます。

  • aname — 認証されたアカウント名。認証したアカウントとターゲットアカウントが異なる場合にのみ表示されます。

  • mid — リクエストしたメールボックスの ID。リクエストが mailbox と関連する場合のみ表示されます。

  • ua  — クライアントのアプリケーション名 (ユーザーエージェントのこと)

  • via — リクエストのプロキシチェインにあるIPアドレスとユーザーエージェントのリスト

  • soapId — 特定の SOAP リクエストによるプロキシホップを監視するための ID

  • msgid — 処理中のメッセージの Message-ID ヘッダー値

  • ds — 処理中のデータソース名

  • port — クライアントが接続されたサーバポート番号

  • oport — リクエストが送信された元ポート番号

  • oproto — リクエスト元のプロトコル。これはユーザーの代理で SOAP リクエストを送信する内部コンポーネントによって行える場合があります。(例:MTA)

以下の事例では、2017年10月25日の00:28にて、IP アドレス 222.173.186.17 を持つ POP3 クライアントが Zimbra Collaboration サーバへ接続し、リクエストが IP 10.1.1.136 を持つローカルプロキシサーバ経由で送信されたことを示しています:

Mailbox Log Entry for POP

以下の事例では、AquaMail のモバイルアプリを使用する user1@mydomain.comIMAP STATUS リクエストが失敗したことを示しています。ユーザー端末の IP アドレスは 72.83.144.255 (oip に記録しており) となっています。リクエストが Zimbra Collaboration nginx proxy から IMAP サーバへ送信され、プロキシの IP アドレスが 10.4.4.138ip および via に記録されている) となっています。

Mailbox Log Entry for IMAP

以下の事例では、LMTP サーバにメッセージ送信を示しています。このログメッセージの IP アドレスはローカルネットワークで実行している Zimbra Collaboration MTA のものとなります。

Mailbox Log Entry for LMTP

以下の事例では、test@mydomain.net のメールボックスからメッセージ ID 462 を削除している MailboxPurge スレッドの処理を示しています。このログメッセージは外部のリクエストではなく、内部プロセスで行うため、ログメッセージに ip, oip, port および via の値が含まれていません。

Mailbox Log Entry for Purge

ハンドラーエクセプションとスタックトレース

アクティビティの進行中にエラーが発生したとき、「handler exception(ハンドラーエクセプション)」がログレコードの最後に追加され、通常のフローを中断したプロセスの実行中に起きたイベントを、管理者に知らせます。何らかのエラーが検出されたというサインです。

Example 19. ハンドラーエクセプション
007-06-25 00:00:10,379 INFO [btpool0-1064] [name=nriers@example.com;mid=228;ip=10.2.3.4;ua=zimbra Desktop/0.38;] SoapEngine - handler exception

時折、スタックトレースが、エクセプションの通知後に表示される場合があります。スタックトレースは、Zimbraの mailboxd サービスにあるスレッドと監視の情報をレポートします。この情報がデバッグに役に立ちます。トレースには、エラーが発生した場所が表れるからです。たいていは、スタックの最後の数件のエントリが問題の原因を示します。 caused by descriptor がログの行に含まれているなら、これが根本原因です。エラーは「501 bad address syntax」のせいで発生しました。

Example 20. スタックトレース
com.example.cs.mailbox.MailServiceException: Invalid address: Jon R
at com.example.cs.mailbox.MailServiceException.internal_SEND_FAILURE (MailServiceException.java:412)
at com.example.cs.mailbox.MailServiceException.SEND_ABORTED_ADDRESS_FAILURE MailServiceException.java:416)
...
at org.mortbay.thread.BoundedThreadPool$PoolThread.run(BoundedThreadPool.java:442)

Caused by: com.example.cs.mailbox.MailSender$SafeSendFailedException: 501 Bad address syntax; chained exception is: com.sun.mail.smtp.SMTPAddressFailedException: 501 Bad address syntax
at com.sun.mail.smtp.SMTPTransport.rcptTo(SMTPTransport.java:1196)
at com.sun.mail.smtp.SMTPTransport.sendMessage(SMTPTransport.java:584)
at javax.mail.Transport.send0(Transport.java:169)
at javax.mail.Transport.send(Transport.java:98)
at com.example.cs.mailbox.MailSender.sendMessage(MailSender.java:409)
at com.example.cs.mailbox.MailSender.sendMimeMessage(MailSender.java:262)
... 30 more
Mailbox ログファイル

mailbox.log ファイルは毎日ローテーションされます。Mailboxのログファイルは /opt/zimbra/log に保存されます。これまでの mailbox.log ファイル名には、そのファイルの作成日が付加されます。日付のないログファイルが現在のログファイルです。これらログファイルは、バックアップや削除が可能です。

メールの問題をトラブルシューティングする

エラーのため、mailbox.log を確認するには、問題が起こっているメールアドレスやサービス名を検索します。また、WARNやERRORのログレベルを確認し、エラーメッセージの内容を確認します。エラーを探すときは、レコードを確認し、問題が記録される前に起こったイベントをトレースします。

システムのクラッシュ

システムクラッシュ時、スタートアップのメッセージを調べ、その後スタートアップメッセージ日付より前にあるエラーを探します。以下の例では2007年6月17日に発生したメモリ不足のエラーを示しています。

Example 21. スタートアップメッセージ
2007-06-25 01:56:18,725 INFO [main] [] soap - Servlet SoapServlet starting up

スタートアップメッセージの前にあるエラーを探します。

Example 22. エラーメッセージ
2007-06-17 20:11:34,194 FATAL [btpool0-3335] [name=samd@example.com;aname=abcadmin@example.com;mid=142;ip=10.3.4.5;ua=zimbraConnectorForBES/5.0.207;] system - handler exception java.lang.OutOfMemoryError: PermGen space
メール配信の問題

"LmtpServer" のサービスを調べます。以下の例では、スタックトレースのレポートに caused by として、受信者のアドレスが拒否されたことが説明されています。アドレスは正確でなければならないからです。

Example 23. メール送信エラー
2007-06-25 10:47:43,008 INFO [LmtpServer-250]
[name=bigen@example.com;mid=30;msgid=<1291804360.35481182793659172.JavaMail.root@example.com>;] lmtp - rejecting message bigen@example.com: exception occurred
com.zimbra.cs.mailbox.MailServiceException: redirect to too failed
at com.zimbra.cs.mailbox.MailServiceException.internal_SEND_FAILURE (MailServiceException.java:412)
at com.zimbra.cs.mailbox.MailServiceException.SEND_FAILURE(MailServiceException.java:424)
at com.zimbra.cs.filter.zimbraMailAdapter.executeActions(zimbraMailAdapter.java:286)
at org.apache.jsieve.SieveFactory.evaluate(SieveFactory.java:151)
at com.zimbra.cs.filter.RuleManager.applyRules(RuleManager.java:177)
at com.zimbra.cs.lmtpserver.zimbraLmtpBackend.deliverMessageToLocalMailboxes(zimbraLmtpBackend.java:325)
at com.zimbra.cs.lmtpserver.zimbraLmtpBackend.deliver(zimbraLmtpBackend.java:140)
at com.zimbra.cs.lmtpserver.LmtpHandler.doDATA(LmtpHandler.java:441)
at com.zimbra.cs.lmtpserver.LmtpHandler.processCommand(LmtpHandler.java:205)
at com.zimbra.cs.tcpserver.ProtocolHandler.processConnection(ProtocolHandler.java:231)
at com.zimbra.cs.tcpserver.ProtocolHandler.run(ProtocolHandler.java:198)
at EDU.oswego.cs.dl.util.concurrent.PooledExecutor$Worker.run(Unknown Source)
at java.lang.Thread.run(Thread.java:619)

Caused by:
com.zimbra.cs.mailbox.MailSender$SafeSendFailedException: 504 <too>: Recipient address rejected: need fully-qualified address ;
chained exception is: com.sun.mail.smtp.SMTPAddressFailedException: 504 <too>: Recipient address rejected: need fully-qualified address
at com.sun.mail.smtp.SMTPTransport.rcptTo(SMTPTransport.java:1196)
at com.sun.mail.smtp.SMTPTransport.sendMessage(SMTPTransport.java:584)
at javax.mail.Transport.send0(Transport.java:169)
at javax.mail.Transport.send(Transport.java:120)
at com.zimbra.cs.filter.zimbraMailAdapter.executeActions(zimbraMailAdapter.java:281)
... 10 more
アカウントエラー - ログインのエラー

mailbox.log は、IMAP、POP3、ZWC上で試行された成功ログイン・失敗ログインをすべて記録します。ログインエラーを探すなら、 "Auth" の検索から始めます。以下の例は、IPアドレス10.4.5.6から誰かが、Zimbraウェブクライアントに管理者としてログインを試みたこと、Windows OS上でFirefoxを使用したことが分かります。ログインは却下されました。そのアカウントが管理者アカウントではなかったためです。

Example 24. アカウントエラー - ログインのエラー
2007-06-25 09:16:11,483 INFO [btpool0-251] [ip=10.4.5.6;ua=zimbraWebClient - FFX.X (Win);] SoapEngine - handler exception
com.zimbra.common.service.ServiceException: permission denied: not an admin account
at com.zimbra.common.service.ServiceException.PERM_DENIED(ServiceException.java:205)
at com.zimbra.cs.service.admin.Auth.handle(Auth.java:103)
アカウントエラー - IMAP・POP関連

IMAPやPOPの問題のためにログを探しているなら、 "ImapServer/Pop3Server" を調べます。以下の例は、sires@example.comの接続試行しようとして起こった致命的なIMAPサーバーエラーを表しています。

Example 25. アカウントエラー - IMAPエラー
mailbox.log.2007-06-19:2007-06-19 15:33:56,832 FATAL [ImapServer-2444] [name=sires@example.com;ip=127.0.0.1;] system - Fatal error occurred while handling connection

メッセージのヘッダーを読む

各メッセージには、送信元からあて先までの、メールの道のりを表すヘッダーが含まれています。この情報は、メッセージに問題があるときにメッセージのルートをトレースするのに使用します。ZimbraのメッセージヘッダーはZimbraのウェブクライアントのメッセージ表示で閲覧できます。メッセージを右クリックして、 元のメッセージを表示 を選択します。

以下の内容がメッセージヘッダーに含まれています。

  • Date — メッセージが送信された日時です。時間を指定するとき、メッセージ検索対象の開始と終了を入力して期間を指定できます。

  • From — 送信者の名前とメールアドレス。

  • To — 受信者の名前とメールアドレス。プライマリ受信者を示します。

  • Message-ID — メールのルートのトレースに使用する一意の番号。

  • In-Reply-To — 返信で返されるメッセージのメッセージIDです。関連メッセージのリンクに使用されます。

  • Received: from — メッセージを送信したホスト名とIPアドレス。MTAからLMTPへのReceived: from情報と、ローカルホストからのReceived: from情報が表示されます。

破損したメールボックスのインデックスを修正する

メールメッセージと添付ファイルは、メールボックスへ追加される前に自動的にインデックス化されます。各メールボックスには紐づくインデックスファイルがあります。このインデックスファイルは、メールボックスからの検索結果を取得するのに必要です。

メールボックスのインデックスファイルが破損した場合や誤って削除された場合、管理コンソールからメッセージを再インデックスすることが可能です。

インデックス破損時、アカウント上でテキスト検索が失敗してもエラーにならないことがあります。インデックス破損の判別をするのにテキスト検索失敗のレポートは、あてにできません。破損インデックスについて、メッセージのインデックスのログを監視する必要があります。サーバーが破損インデックスを検知すると、メッセージが、WARNのログレベルでZimbraのmailbox.logにログ出力されます。ログメッセージは Possibly corrupt index で始まります。このメッセージが表示されたら、管理者が問題を修正する必要があります。問題の修正とは、メールボックスの再インデックスである場合が多いです。

メールボックスの内容の再インデックスに必要な時間は、メールボックス内のメッセージ数によります。再インデックスが実行中もユーザーはメールボックスにアクセスできますが、インデックスされていないメッセージは検索結果に返せないため、検索結果が不完全である可能性があります。

インデックスが破損しているかどうか確認する

特定のメールボックスのインデックスに対するサニティーチェックには、コマンド zmprov verifyIndex を実行します。

zmprov verifyIndex <user@example.com>

問題が検知されると、失敗ステータスが返されるので、インデックスに対する修復を行ないます。

破損されたインデックスを修正・再インデックスする

コマンド reIndexMailbox を使用して、インデックスの修正と再インデックスをします。

zmprov reIndexMailbox <user@example.com> start

started のステータスが返されます。

SNMPの監視と設定

SNMPの監視ツール

サーバー監視用ソフトウェアを実装して、システムログ、CPUとディスク使用容量、その他ランタイム情報を監視したいことがあるかもしれません。

Zimbra Collaboration はSNMPトラップの作成のために、swatchを使用してsyslogの出力を監視します。

SNMPの設定

Zimbra Collaboration には、SNMP監視のインストールパッケージが含まれています。このパッケージは、Zimbra Collaboration設定の部分をなす、各サーバー(Zimbra Collaboration、OpenLDAP、Postfix)で実行する必要があります。

トラップの送信先とするべき宛先ホストは、SNMP設定だけです。

SNMPトラップを作成するエラー

サービスの停止あるいは起動時、 Zimbra Collaboration エラーメッセージがSNMPのトラップを作成します。サードバーティ製のSNMP監視ソフトウェアを使用してそのメッセージを取得し、選択したメッセージをpagerや他の警告システムに転送することができます。

MariaDBを確認する

MariaDBのデータベース健康の検証するためのチェックが毎週、自動で行なわれます。このチェックに約1時間かかります。エラーが見つかると、管理者のアカウントにレポートが送信されます。MariaDBのチェックを実行するレポート名は zmbintegrityreport で、Crontabは週に一度このレポートを実行するように自動設定されます。

MariaDBデータベースのチェック時、このレポートの実行でI/Oを膨大に消費する可能性があります。通常の場合は問題になりませんが、運用に影響が出るようであれば、zmbintegrityreportの実行頻度を変更できます。詳細は ZCS Contrab Jobsを参照してください。

Zimbra Collaborationのソフトウェア更新を確認する

Zimbra Collaborationをインストールすると、Zimbra Collaborationのソフトウェア更新機能は、日に1度最新のZimbra Collaborationバージョンを確認するように自動設定されます。更新があると、管理コンソールの サーバー更新 に設定されているメールアドレスに通知メッセージが送信されます。

Zimbra Collaborationが更新を確認した日時は 更新 のタブに保存され、管理者がZimbra Collaborationバージョンを更新するまでメール通知が継続的に発送されます。更新のメール通知を受信したくない場合、 更新の入手が可能になったときに通知メールを送信 のオプションを無効にします。

以下の内容も設定可能です。

  • 更新をチェックするサーバー — 利用できるサーバーのリストが表示されますが、サーバーは一つだけ設定できます。選択されたサーバーは更新を確認し、www.zimbra.comからの更新レスポンスはLDAPに保存されます。

  • 更新をチェックする間隔 — デフォルトは日に1度です。頻度の間隔は時間、分、秒単位で変更できます。バージョン更新の確認タスクはcron jobに設定されます。頻度の間隔が2時間未満の場合、crontabファイルを直接、修正する必要があります。

  • 更新URL — バージョン更新を確認するためにサーバーが接続するURLのアドレスです。Zimbra Collaborationサーバーがアップデートを確認する場合、バージョン、プラットフォーム、ビルド番号をZimbraへ送信します。通常このURLは変更されません。

  • 更新の通知を受ける場合、更新の入手が可能になったときに通知メールを送信 のオプションを有効にし、送信先と送信元のアドレスを入力します。デフォルトのアドレスは管理者のアドレスです。

  • 汎用的なメールが作成されます。メールの件名と内容は変更できます。

  • サーバーが指定されたURLをポーリングすると、その応答が表示されます。

Outlook用Zimbraコネクタを更新する

Outlook用Zimbraコネクタ(ZCO)のmsiファイルは、管理コンソールにあるZimbraユーティリティのダウンロードページから入手できます。ZCS バージョンが新しくなる前にZCOの新バージョンがリリースされると、管理コンソールから新しいほうのZCOのmsiファイルをZCSサーバーにアップロードできます。アップロードしたファイルは /opt/zimbra/jetty/webapps/zimbra/downloads にアップロードされます。

管理コンソール:

ホーム > ツール、移行 > クライアントのアップロード

  1. アクセス可能なコンピュータに、管理コンソールの クライアントのアップロード ページから新しいZCOのファイルをダウンロードします。

  2. 参照 のボタンをクリックし、アップロードするZCOファイルを選択します。

  3. ZCSを再起動します。

    zmcontrol restart

    または下記を実行します。

    /opt/zimbra/libexec/zmupdatedownload

downloads/index.html のファイルは、最新のZCOクライアントバージョンで更新されます。この新しいファイルは管理コンソールの ホーム > ツール、移行 > ダウンロード のページからダウンロードできます。

サーバーを再起動しないと、ZimbraユーティリティのダウンロードページにあるZCOのダウンロードリンクは、新しいダウンロード対象バージョンを選択しません。

Zimbra Collaboration より送信される通知や警告

サービスステータス変更の通知

サービスの停止あるいは再開時、この通知が送信されます。

サーバー開始の通知メッセージ
件名: Service <サービス名> started on <Zimbraホスト名>

本文: Service status change: <Zimbraホスト名> <サービス名> changed from stopped to running
サーバー停止の通知メッセージ
件名: Service <サービス名> stopped on <Zimbraホスト名>

本文: Service status change: <Zimbraホスト名> <サービス名> changed from running to stopped
ディスク利用状況の通知

ディスク空き容量が少なくなった場合、管理者のアカウントに警告が通知されます。デフォルトでは、ディスクの使用容量が85%に達した場合、注意の警告が送信され、ディスクの使用容量が95%に達した場合、重大な警告が送信されます。

件名: Disk <ボリューム名> at ##% on <Zimbraホスト名>

本文: Disk warning: <Zimbraホスト名> <ボリューム名> on device <デバイス名> at ##%

mysqldが重複のプロセスに実行している際の通知

データベースの破損の原因になりそうなケースを検出するmysqldのプロセスが実行中かどうかを確認するスクリプトが実行されます。1つ以上のmysqldプロセスが実行中だとわかると、メールが作成されます。

件名: ZCS: Duplicate mysqld processes detected!

本文: PID:$pid PPID:$ppid PGRP:$pgrp

CMD: $cmdline

More then $maxcnt mysqld processes are running Parent processes
include: $procs This should be investigated immediately as it may lead to
database corruption

SSL証明書期限切れの通知

毎月初日にリポートが実行され、来たる30日以内に有効期限が満了する証明書を警告します。

件名: ZCS: SSL Certificates approaching expiration!

本文: The Administration Console and CLI Certificate Tools guide provides
instructions on how to replace you self-signed or commercial certificate.

https://wiki.zimbra.com/index.php?title=Administration_Console_and_CLI_Certificate_Tools SSL Certificate expiration checked with $0 on <Zimbraホスト名>.

Daily report (日報)の通知

loggerパッケージがインストールされると、日次のメールレポートがcrontabに自動スケジュールされます。このレポートは毎日管理者のメールボックスに送信されます。

件名: Daily mail report for <日>

<日次のレポートデータ>

データベースの統合性チェック通知

crontabに自動スケジュールされるzmdbintegityreportを週次ベースで実行することで、MariaDBデータベースをチェックします。レポートは自動的に管理者のメールボックスに送信されます。

件名: Database Integrity check report for <Zimbraホスト名>

本文: Generating report can't run $cmd: $!

Database errors found.

$cmd --password=XXXXXXXX

<cmd output>

No errors found

command failed $!

バックアップの完了通知

実行するバックアップタイプの設定時、そのバックアップセッション結果の通知メッセージの受信もセットアップできます。

件名: ZCS BackupReport:SUCCESS

本文: Server: <サーバー名>

Type: incremental

Status: completed

Started: Fri, 2012/07/13 01:00:05.488 PDT

Ended: Fri, 2012/07/13 01:10:09.842 PDT

Redo log sequence range: 2 ..  2

Number of accounts: 500

バックアップと復元 (*)

*Zimbra 8.8 より、本機能は2つの異なるバージョンを提供しています。

Zimbra 8.8 ではスタンダード版と新世代(NG)版を提供しています。Zimbra 8.7 またはそれ以前のバージョンでは、スタンダード版のみを提供しています。以下にスタンダード版の詳細を記載しています。Zimbra 8.8 で本機能の NG版を利用する方法につきましては、本ガイドの NG版専用チャプターをご参照ください。

スタンダード版のバックアップ(クラシックバックアップ)のサポートが終了しており、Zimbra 8.8.12 以降のリリースから削除する予定です。 新しいネットワーク版の NG モジュール、または ZSP へ移管していない環境はお早めに移管いただくよう、推奨しております。

Zimbra Collaboration には、各 Zimbra Collaboration サーバーに設定可能なバックアップマネージャーが備わっており、バックアップと復元の両方を実施できます。バックアップ処理の実行のために Zimbra Collaboration サーバーを停止する必要はありません。

本章では、データのバックアップと復元方法、そして、 Zimbra Collaboration メールボックスサーバーのバックアップと復元のために使用するCLIツールについて説明します。加え、障害復旧に関する情報と一般ガイドも記載します。

メールボックスサーバーのバックアップ

Zimbra Collaboration には、各 Zimbra Collaboration サーバーに設定可能なバックアップマネージャーが備わっており、バックアップと復元の両方を実施できます。バックアップ処理の実行のために Zimbra Collaboration サーバーを停止する必要はありません。シングルユーザーのメールボックス破損時、バックアップマネージャーを使用すれば、全システムの復元を行なわずにそのユーザーのみ復元することができます。完全・増分バックアップは /opt/zimbra/backup に保存されます。

Redoログ

各Zimbraメールボックスサーバーは、redoログを作成します。このログに、最終増分バックアップ時以降メッセージストアサーバーで処理された現在およびアーカイブのトランザクションを格納します。

サーバー復元時、バックアップファイルが完全に復元されてから、すべてのアーカイブにあるredoログと現在のRedoログが再実行されて、システムの不具合が発生する直前まで戻されます。

使用中のredoログファイルが100MBに達すると、そのRedoログはアーカイブディレクトリに移ります。そしてサーバーは新しいredoログを使用し始めます。前回のredoログのコミットされなかったトランザクションはすべて維持されています。クラッシュ時、サーバーを再起動すると、現在のRedoログ が読み込みこまれ、コミットされなかったトランザクションが再適用されます。

増分バックアップ実行時、redoログはアーカイブからバックアップディレクトリに移されます。

バックアップ方法

バックアップ方法には2種類あります。

  • 標準バックアップ は、平日以外に完全バックアップを実行するエンタープライズ企業の環境に適しています。

  • オートグループバックアップ は、一度の全アカウントの完全バックアップ完了までの時間が非常にかかるような大規模な Zimbra Collaboration 環境の場合に推奨します。

標準バックアップ

標準バックアップ方法は、完全バックアップを毎週、増分バックアップを毎日実行します。完全バックアップ処理は、メールボックスの復元に必要な全情報をバックアップします。これには、LDAPディレクトリサーバー情報、データベース、インデックスディレクトリ、各メールボックスのメッセージディレクトリも含まれます。

共有メッセージのバックアップ時、すでにバックアップ内にそのメッセージ用ファイルが存在する場合、そのことがこのアイテムにフラグ付けされるため再度内容がコピーされることはありません。

増分バックアップは、前回の増分バックアップ以降更新されたLDAPデータをバックアップし、全Redoログを収集します。あるメールボックスに完全バックアップがないと分かると増分バックアップ処理がそのメールボックスの完全バックアップを行ないます。

増分バックアップは、Redoログをバックアップのディレクトリに移します。Redoログとは、実行されたアクションごとの記録です。これには、配信された全メッセージの完全コピーや、タグ、連絡先、スレッドなどのメタデータの完全コピーが入ります。

これらのバックアップファイルを使用して、メールボックスサーバーを丸ごと復元、あるいはメールボックスを個別に復元してアカウントとメッセージデータを完全に復元することができます。

LDAPディレクトリは、完全バックアップや増分バックアップの処理の一環としてバックアップされます。アカウント、ドメイン、サーバー、提供サービス、その他のデータなどすべてがバックアップされます。

各メールボックスサーバーは、処理した全トランザクションが記録されるRedoログを作成します。予期せぬシャットダウンが発生すると、以下のようにRedoログを使用します。

  • コミットされないままのトランザクションを確実に残さないように、スタートアップで最新のRedoログを読み込み、コミットされなかったトランザクションを全て再実行し完了させます。

  • サーバー不具合時、直近の完全バックアップ後の書き込みデータを復旧します。

サーバー復元時、バックアップファイルが完全に復元されてから、すべてのアーカイブにあるredoログと現在のRedoログが再実行されて、システムの不具合が発生する直前まで戻されます。

Zimbra MTAのデータはサーバーに短時間しか残らないため、バックアップされません。

また、mailboxdの jetty/etc/*.xml などのカスタム設定もバックアップされません。

バックアップ通知

完全・増分バックアップの実行時、バックアップレポートが管理者アカウントに送信されます。レポートには、バックアップの成功・失敗、バックアップの開始時間・終了時間、バックアップしたアカウント数、Redoログのシーケンス範囲が記されます。

バックアップが失敗すると、エラー情報も追記されます。

オートグループバックアップ

オートグループバックアップ方法は、異なるメールボックスグループの完全バックアップをスケジューリングして個々にバックアップします。オートグループ方法は、全アカウントのバックアップが完了するまでに時間のかかる大規模な Zimbra Collaboration 環境を対象にして設計しています。オートグループバックアップは、完全・増分バックアップを機能的に組み合わせているため、増分バックアップの実行は不要です。各オートグループのセッションが該当のメールボックスグループに完全バックアップを行ないます。オートグループバックアップはCLIでスケジュールして自動実行されるため、マニュアル操作でのオートグループバックアップ実行は推奨しません。

バックアップファイルのディレクトリ構成

バックアップ先は、バックアップターゲットとして知られます。バックアップシステムの場合、メールサーバーのファイルシステムにあるパスがこれにあたります。Zimbraのデフォルトのバックアップディレクトリは /opt/zimbra/backup です。

標準バックアッププロセスで作成されるバックアップのディレクトリ構成の詳細は 標準バックアップのディレクトリ構成に記載されています。同一のターゲットエリアに定期的にスケジュールしたバックアップ先を設定・実行しても、以前のバックアップセッションは上書きされません。

ファイル accounts.xml に全バックアップの組み合わせで全アカウントがリストアップされています。アカウントごとにアカウントID、メールアドレス、そのアカウントの直近の完全バックアップ用ラベルがあります。バックアップのセッションを他の場所へ保存する場合、最新のaccounts.xmlもそこに保存する必要があります。アカウントの復元中、accounts.xmlを使用して、そのアカウントの直近の完全バックアップを参照します。accounts.xmlがないなら、復元する元となるバックアップのラベルを指定する必要があります。

Redoログのディレクトリは /opt/zimbra/redolog/redo.log です。現在のRedoログのファイルサイズが100MBに達すると、その現在のログファイルはアーカイブディレクトリ /opt/zimbra/redolog/archive に移ります。そしてサーバーは新しいredoログを使用し始めます。前回のredoログのコミットされなかったトランザクションはすべて維持されます。クラッシュ時、サーバーを再起動すると、現在のRedoログ が読み込みこまれ、コミットされなかったトランザクションが再適用されます。

Redoの操作は短時間で行なう必要があるため、コピー・削除ではなくディレクトリ移動が実施されます。ソースとターゲットのパスが同じファイルシステムのボリュームに存在するときのみ、ディレクトリを移動できます。つまり、RedoログとRedoログのアーカイブは同じファイルシステムのボリュームになければなりません。アーカイブファイルはRedoログのファイルシステムのサブディレクトリだからです。

増分とオートグループの全バックアップセッションはRedoログと同一のディレクトリに保存します。全Redoログが同一バックアップターゲットで見つかる必要があります。通常の完全バックアップセッションは、別のターゲットディレクトリを使用できます。

Table 55. 基準バックアップのディレクトリ構成

/opt/zimbra/backup

バックアップのデフォルトルートディレクトリです。

accounts.xml/

すべてのアカウント、そのアカウントのメールアドレスファイル・Zimbra ID・直近の完全バックアップラベルがリストアップされています。accounts.xmlは、メールアドレス、そのメールアドレスと現在のZimbra IDとのマッピング、各アカウントの直近のバックアップ情報を管理しています。

sessions/

バックアップセッションのルートディレクトリ。

full-<timestamp>/

完全バックアップのディレクトリ。セッションのタイムスタンプは、ミリ秒を含めたバックアップの開始時間 (GMT) 。サマータイムに対応するためにローカル時間ではなくGMTを使用しています。

session.xml

完全・増分バックアップセッションのバックアップラベルについてのメタデータ、例えば開始時間、完了時間等。

shared_blobs/

バックアップデータ内のアカウント間で共有しているメッセージファイルが入ります。

sys/

グローバルのデータベーステーブルとlocalconfig。

db_schema.xml

グローバルテーブルのデータベーススキーマ情報。各テーブルのダンプファイルは.csv形式のフォーマットです。

localconfig.xml

バックアップ時の /opt/zimbra/conf/localconfig.xml コピー。

<table name>.dat

データベーステーブルのデータダンプ。

LDAP/ldap.bak

LDAPのダンプ。

accounts/

各アカウントのデータはこのサブディレクトリに保存されます。

<…​/zimbraId>/

各アカウントのルートディレクトリ。

meta.xml

アカウントのバックアップに関するメタデータ。

ldap.xml

アカウントのLDAP情報、エイリアス、アイデンティティ、データソース、配布リストなどを含みます。

ldap_latest.xml

このファイルが存在する場合、直近の増分バックアップのldap.xmlへリンクします。

db/

アカウント固有のデータベースのテーブルダンプ。

db_schema.xml

このアカウントのテーブル用のデータベーススキーマ情報。

<table name>.dat

データベーステーブルのデータダンプ。

blobs/

ブロブファイルが入ります。

index/

Luceneのインデックスファイルが入ります。

incr-<timestamp>

増分バックアップのディレクトリ。完全バックアップディレクトリのスキーマと類似していて、これらのメタファイルが含まれます。

session.xml

sys/db_schema.xml

accounts/…​/<zimbraID>/ldap.xml

incr-<timestamp>accounts/…​/<zimbraId>/db/db_schema.xml は入りません。 増分バックアップの場合、アカウントのテーブルをダンプしないからです。

オートグループバックアップの場合、ディレクトリ構成により、完全バックアップセッションへのRedoログファイルが保存されます。増分バックアップのセッションはありません。

管理コンソールでのバックアップと復元

管理コンソールから直接実行できるバックアップと復元の操作が多数あります。左側のナビゲーションペインから 監視 > バックアップ を選択すると全サーバーがリストアップされます。

管理コンソールでバックアップを設定する

バックアップは、管理コンソールからグローバル設定は特定のサーバーの設定として、設定できます。サーバー設定はグローバル設定にオーバーライドします。

グローバル設定の場合、バックアップ結果を受信するメールアドレスが設定できます。デフォルトではその管理者のアカウントに通知を送信します。

オートグループの場合、バックアップの分割グループの数を設定します。

標準バックアップがデフォルトで、自動スケジュールされます。他の変更を付け足す必要はありませんが、オートグループバックアップの実行時はマニュアル操作でのバックアップスケジュール設定が必要です。これにはCLIにアクセスし、 オートグループバックアップをスケジュールする にある手順に従って zmschedulebackup -D を実行し、オートグループバックアップのデフォルトスケジュールを設定します。

オートグループバックアップのスロットルオプション : オートグループバックアップ方法は、一度もバックアップが実行されていないメールボックスを次回予定されたバックアップで自動バックアップします。これは、大規模メールボックス移行・メジャーアップグレードの直後など、全メールボックスの完全バックアップが必要なときは最善ではありません。Throttle automatic backups を有効にすると日次バックアップでのメールボックス数がT/Nに制限されます。N日以内に全メールボックスをバックアップするという制約は守れない一方で、オフ時間帯にバックアップを完了できます。

一度でも全メールボックスがバックアップされたら、スロットルを無効化します。

zmprov mcf zimbraBackupAutoGroupedThrottled TRUE

CLIからのバックアップと復元

Zimbraのバックアップと復元プロセスはCLIコマンドから実行できます。

以下のユティリティを使用して、バックアップのスケジュール作成、完全・増分バックアップ実行、メールサーバーの復元、またはLDAPの復元ができます。

  • zmschedulebackup — このコマンドで完全・増分バックアップのスケジュールや、古いバックアップファイルの削除ができます。

  • zmbackup — このコマンドでZimbra Collaboration メールボックスサーバーの完全・増分バックアップを実行します。このコマンドは、ライブのサーバー上でmailboxdプロセスやメールボックスサーバーの起動中に実行します。このコマンドは、不要となった古いバックアップをマニュアルで削除できるオプションがあります。

  • zmbackupabort —  実行中の完全バックアップを強制的に停止するコマンド。

  • zmbackupabort -r — 実行中の復元を強制的に停止するコマンド。

  • zmbackupquery — 実行中や完了しているバックアップ情報を、ラベルや実行日時を含めて返します。

  • zmrestore — Zimbra Collaboration メールサーバーの完全・増分の復元を実行します。

  • zmrestoreoffline — mailboxdのプロセスが停止している状態で Zimbra Collaboration メールサーバーを復元します。

  • zmrestoreldap — アカウント、ドメイン、サーバー、提供サービスなどのデータを含む、LDAPのディレクトリサーバーを完全に復元します。

こうしたコマンドごとの使用方法や詳細はZimbra CLIコマンド コマンドラインのユティリティ を参照してください。

標準の方法でバックアップする

バックアップ開始時、バックアップするサーバー上でコマンドを実行することも、ターゲットサーバーを指定しリモートから実行することも、または管理コンソールでバックアップを実行することもできます。

標準バックアップをスケジュールする

Zimbra Collaboration がインストールされたときに自動で、完全・増分バックアップの標準の方法でのバックアップスケジュールがCrontabに追加されています。デフォルトスケジュールは、完全バックアップが毎週土曜の午前1時に実行されます。増分バックアップは日曜から金曜の午前1時に実行されます。

デフォルトで、1か月より前のバックアップが深夜0時に削除されます。

バックアップスケジュールを zmschedulebackup コマンドを使用して変更できます。

下記のとおり項目を指定します。項目はスペースで区切ります。

  • 分 — 0 から 59

  • 時間 — 0 から 23

  • 月の日 — 1 から 31

  • 月 — 1 から 12

  • 曜日 — 0 から 7 (または英語名。0と7は日曜日を意味します。)

使用しない値には、アスタリスクを入力します。

Example 26. zmschedulebackup オプションの例
  • 既存の完全・増分バックアップ、バックアップの削除スケジュールをすべて変更します。 -R を使用すると、バックアップのスケジュールがすべて変更されます。スケジューリングするバックアップのセッションを自動削除したいなら、このコマンドの使用時にその削除スケジュールも忘れずにセットしてください。以下は、既存のスケジュールを次のように変更する例です。
    日曜午前1時に完全バックアップを実行、月曜から土曜の午前1時に増分バックアップを実行、毎日正午に古いバックアップを削除。

    zmschedulebackup -R f "0 1 * * 7" i "0 1 * * 1-6" d 1m "0 0 * * *"
  • 現在のスケジュールに完全バックアップを追加します。以下は、木曜の朝1時の完全バックアップを追加する例です。

    zmschedulebackup -A f "0 1 * * 4"
  • バックアップスケジュールを確認します。スケジュールが返されます。

    zmschedulebackup -q
  • スケジュールのコマンドをテキストファイルに保存します。再インストールやアップグレード後、同じスケジュールを簡単に再作成できます。

    zmschedulebackup -s
デフォルトスケジュールに戻すには、以下のコマンドを実行します。 zmschedulebackup -D
デフォルトの標準バックアップのスケジュール

デフォルトのバックアップスケジュールが以下のように表示されます。

Example 27. デフォルトのバックアップスケジュール
0 1 * * 6 /opt/zimbra/bin/zmbackup -f - all
0 1* * 0-5 /opt/zimbra/bin/zmbackup -i
0 0 * * * /opt/zimbra/bin/zmbackup -del 1m

読みかた

完全バックアップを毎週土曜の午前1時に実行します。
0 1 * * * 6 /opt/zimbra/bin/zmbackup -f - all
増分バックアップを日曜から金曜の午前1時に実行します。
0 1* * 0-5 /opt/zimbra/bin/zmbackup -i
作成から1ヶ月経過したバックアップセッションを深夜に自動削除します。
0 0 * * * /opt/zimbra/bin/zmbackup -del 1m
crontableの読みかた

各crontabエントリには、下記6項目がこの順番で入ります。

項目

1

2

3

4

5

6

0

1

*

*

6

/opt/zimbra/bin/zmbackup -f -all

  1. 分 (0-59)

  2. 時間 (0-23)

  3. 月の日 (1-31)

  4. 月 (1-12 または英語名)

  5. 曜日 (0-7 または英語名。0と7は日曜日を意味します。)

  6. 実行する文字列

アスタリスクはワイルドカードとして機能し、項目の全ての候補値に該当します。
管理コンソール:

ホーム > 設定 > グローバル設定 > バックアップ/復元

管理コンソールから、メール通知の受信者の追加や受信者のアドレス変更ができます。

完全バックアップのプロセス

完全バックアップのプロセスは以下の順でメールボックス、データベース、インデックス、LDAPディレクトリをバックアップします。

  1. システムテーブルや localconfig.xml のファイルを含む、グローバルなシステムデータをバックアップします。

  2. バックアップターゲットとなるアカウントごとに、そのLDAPエントリのバックアップを繰り返します。

  3. アカウントのメールボックスをメンテナンスモードへ設定し、一時的にメール配信とユーザーからのアクセスを停止します。

  4. メールボックスをバックアップします。

    1. そのメールボックスの関わる全データのMariaDBダンプを作成します。

    2. そのメールボックスのメッセージディレクトリをバックアップします。

    3. そのメールボックスのインデックスディレクトリをバックアップします。

  5. アカウントのメールボックスをアクティブモードへ戻し、次のアカウントに進みます。

  6. LDAPディレクトリをバックアップします。

完全バックアップは通常、非同期で実行されます。完全バックアップの開始時、実行中のバックアップのプロセスラベルが直ちに表示されます。バックアップはバックグラウンドで継続します。バックアップの実行ステータスは、 zmbackupquery のコマンドでいつでも確認できます。

バックアップファイルは圧縮なしのzipファイルとして保存されます。デフォルトのZipオプションの変更は コマンドラインのユティリティ のzmbackupを参照してください。

増分バックアップのプロセス

増分バックアップはCLIコマンドの zmbackup で実行します。増分バックアップのプロセスを以下に説明します。

  1. システムテーブルや localconfig.xml のファイルを含む、グローバルなシステムデータをバックアップします。

  2. バックアップターゲットとなるアカウントごとに、そのLDAPエントリのバックアップを繰り返します。

  3. 直近のバックアップ以降に作成されたアーカイブRedoログをディレクトリ <バックアップターゲット>/redologs に移します。

    増分バックアップ実行で1時間未満のアーカイブログはバックアップへコピーされ、削除されません。こうしたRedologは、バックアップ後1時間経過したら削除されます。この間隔はlocalconfigキー backup_archived_redolog_keep_time で指定します。デフォルトは3600秒です。

    アカウントに完全バックアップがないとき、バックアッププロセスは増分バックアップの実行が指定されていてもこのアカウントの完全バックアップを行ないます。

  4. LDAPディレクトリをバックアップします。

マニュアル操作でバックアップを実行する

コマンドzmbackupを使用して、次のバックアップ操作を実行します。

  • server1 の全メールボックスをマニュアルでバックアップします。

zmbackup -f -s server1.domain.com -a all
  • 直近の完全バックアップ以降の server1 の全メールボックスをマニュアルで増分バックアップします。

zmbackup -i -s server1.domain.com -a all
  • server1user1 のメールボックスのみマニュアルで完全バックアップします。

zmbackup -f -s server1.domain.com -a user1@domain.com
バックアップのセッションを削除する

バックアップセッションは、ラベルまたは日時によって削除できます。

  • ラベルによる削除は、指定したセッションとそれ以前のセッションをすべて削除します。

  • 日時による削除は、指定した日時より前のバックアップセッションをすべて削除します。

例えば zmbackup -del 7d は今日より7日以前のバックアップをすべて削除します。日(d)、月(m)、または年(y)を指定できます。

特定のバックアップを検索する

個々の完全・増分バックアップがバックアップセッションです。

各バックアップセッションは日時でラベル付けされます。例えば、full20070712.155951.123のラベルは、このバックアップが2007年7月12日の3:59:51.123に作成されたことを表します。

セッションのラベルにはローカル時間ではなくGMTの時間を使用しています。サマータイムを導入している環境でのバックアップ実行時間を正常にするためです。

zmbackupquery コマンドで完全バックアップセッションを検索できます。

  • 特定の完全バックアップセッションを確認します。

zmbackupquery -lb full-20070712.155951.123
  • 指定日以降の完全バックアップセッションを確認します。

zmbackupquery --type full --from "2007/01/01 12:45:45"
  • バックアップディレクトリにあるすべての完全バックアップセッションを確認します。

zmbackupquery --type full
  • 特定の時間の範囲でアカウント復元に適した時を確認します。

zmbackupquery -a user1@example.com --type full --from "2007/07/05 12:01:15" --to "2007/07/12 17:01:45"
バックアップ中にサーバークラッシュ (アボートではない)が原因でバックアップのセッションが遮断されると、中断されたバックアップセッションが一時セッションとして保存されます。一時セッションは <バックアップターゲット>/sessions_tmp のディレクトリに保存されます。rmコマンドを使用し、ディレクトリを削除できます。

完全バックアップを実行中に停止する

  1. バックアップをアボートするためにはバックアップのセッションラベルが必要です。 zmbackup を最初に起動した際にラベルが表示されます。完全バックアップのラベルが不明な場合、 zmbackupquery を使用してラベルを確認します。

  2. 実行中のバックアップを zmbackupabort のCLIコマンドで強制的に終了することができます。バックアップは直ちに停止し、部分的に成功したバックアップとなります。

    • ラベル名を把握している場合、バックアップを停止します。

zmbackupabort -lb full-20070712.155951.123 -s server1
  • ラベル名が不明の場合、バックアップを停止します。

zmbackupquery
zmbackupabort -s server1 -lb full-20070712.155951.123

オートグループ方法でバックアップする

オートグループバックアップ方法は、管理コンソールまたはCLIから設定します。

管理コンソール:

ホーム > 設定 > グローバル設定 > バックアップ/復元 または
ホーム > 設定 > サーバー → サーバー名 → バックアップ/復元

CLIからオートグループバックアップを設定する

特定のサーバーにだけオートグループ方法を使用したくない場合、グローバル設定でバックアップ方法を設定してから、この設定をオーバーライドするサーバー設定で個別に設定します。

オートグループバックアップを設定するにはzmprovを使用し、LDAPの属性を編集します。

zmprov mcf <ldap_attribute> <引数>

zmprov ms を使用して、サーバーレベルで属性を設定できます。

以下のLDAP属性を編集します。

  • zimbraBackupMode —  Auto-Grouped に設定します。デフォルトはStandardです。

  • zimbraBackupAutoGroupedInterval — グループにバックアップセッションを実行する日数または週数を指定します。デフォルトは1日 (1d) です。バックアップ期間は1日以上です。xd (例えば、1d、など) やxw (例えば、1w、など) で入力できます。

  • zimbraBackupAutoGroupedNumGroups — メールボックス全体をグループ分割するグループ数です。デフォルトは7グループです。

オートグループバックアップをスケジュールする

オートグループバックアップスケジュールを設定する必要があります。

zimbraBackupAutoGroupedInterval の設定をベースとした、オートグループバックアップ用のデフォルトスケジュールを設定するには、 zmschedulebackup -D を実行します。

各インターバルで1つのグループがバックアップされます。オートグループバックアップは、サーバーのメールボックス数の変更に合わせて調整します。各バックアップセッションが以下をバックアップします。

  • 一度もバックアップされたことのないメールボックスをすべてバックアップします。新たにプロビジョンされた メールボックスがこれに該当します。

  • スケジュールされたバックアップ期間内にバックアップされなかったメールボックスをすべてバックアップします。例えば、6日後にバックアップするようにスケジュールされていれば、過去5日以内のバックアップされていないメールボックスがバックアップされます。

  • メールボックスが比較的多いとき古いものから順にバックアップします。日次オートグループバックアップの負荷分散のためです。

    例えば、オートグループの期間を日次 (1d) 、グループ数を7に設定すると、初回オートグループバックアップの実行で、全アカウントがバックアップされます。初回バックアップの後、オートグループが再度次の日に実行されます。今回は、新たにプロビジョンされたアカウントと、全アカウントの1/7相当のアカウントがバックアップされます。バックアップ日付が最古のアカウントからバックアップされます。このバックアップは、新たにプロビジョンされたアカウントと、バックアップ中の全アカウントの1/7相当のアカウントが7日間かけてバックアップされます。

共有メッセージのバックアップ時、すでにバックアップ内にそのメッセージ用ファイルが存在する場合、そのことがこのアイテムにフラグ付けされるため再度内容がコピーされることはありません。

バックアップファイルは圧縮なしのzipファイルとして保存されます。デフォルトのZipオプションの変更は コマンドラインのユティリティ のzmbackupを参照してください。

これらのバックアップファイルを使用して Zimbra Collaboration システム全体、または個々のメールボックスのみを復元し、アカウントとメッセージデータの完全な復元ができます。アーカイブRedoログは完全バックアップの一部としてバックアップのセッションに移されます。サーバーがオートグループバックアップから復元されているなら、Redoログが再実行されて、システムの不具合が発生する直前まで戻されます。

バックアップのオプション

バックアッププロセスの設定で、バックアップ内容の選択やMariaDBデータベースのバックアップが可能です。

バックアップに含まれる内容のオプション

以下のバックアップオプションで、完全バックアップのセッション中に検索のインデックス、ブロブ、HSMブロブをバックアップしないように設定できます。

  • zimbraBackupSkipSearchIndex — デフォルトは FALSE です。TRUE のとき、検索インデックスはバックアップされません。検索インデックスのないバックアップからのメールボックス復元後は、メールボックスを再インデックスする必要があります。

  • zimbraBackupSkipBlobs — デフォルトは FALSE です。 TRUE のとき、ブロブはバックアップされません。ブロブがフォールトトレランス対応のストレージにあるときにデータベースデータだけを早急にバックアップするのに役立ちます。この設定は、プライマリーとセカンダリ (HSM) ボリュームにある全ブロブに適用します。

  • zimbraBackupSkipHsmBlobs — デフォルトは FALSE です。 TRUE のとき、HSMボリュームにあるブロブはバックアップされません。 zimbraBackupSkipBlobsFALSE で、HSMボリュームにあるブロブをスキップしたい場合は、これを有効にします。

MariaDBデータベースをバックアップする

Zimbra Collaboration のバックアップ設定で、mysqldumpを実行してバックアップのセッション中にMariaDBデータベースをバックアップできます。これが有効なとき、完全バックアップ、増分バックアップ、オートグループバックアップごとにmysqldump が実行されます。

mysqldumpとは、MariaDBデータベースのある時点のバックアップです。ダンプファイル作成後のデータ変更がバイナリログに記録されます。ある地点に復元するには、バイナリロギングが有効化されていなければなりません。詳細は以下のZimbraのWiki記事、MariaDB Backup and Restore を参照してください。 https://wiki.zimbra.com/wiki/MySQL_Backup_and_Restore

MariaDBのダンプファイルはgzipされ、バックアップのターゲットディレクトリに移されます。ディレクトリを指定していない場合は /opt/zimbra/backup に移されます。

これらのファイルは非常に大きくなる可能性があります。そのため、MariaDBデータベースバックアップファイルごとに、そのMariaDBデータベースの実容量の3倍以上のディスク容量を用意する必要があります。

  • バックアップ時にmysqldump を自動実行させるには、以下を入力します。

zmlocalconfig edit mysql_backup_retention=<N>

N の値は保管するMariaDBのデータベースバックアップの数です。

MariaDBデータベースを復元する方法については、Zimbraサポートへご相談ください。

バックアップ用のディスク容量を管理する

ターゲットのディスクに十分な空の容量が存在しないと、バックアップセッションは失敗します。このセッション中にバックアップされたデータはすべて破棄・削除されます。

バックアップの完了に十分な容量がない可能性があるとき、通知を受け取るように設定できます。

属性 zimbraBackupMinFreeSpace を設定すると、通知によってバックアップセッションの実行が管理しやすくなります。

バックアップセッションの実行前、zimbraBackupMinFreeSpace 属性の値に、バックアップターゲットディスクに必要な空き容量を設定します。属性に設定された値よりもディスクの空き容量が小さいとき、バックアップセッションは実行されません。それを通知するメッセージが管理者に送信されます。

MariaDBデータベースもバックアップする場合、myslqdump のファイルサイズの格納に確実に足る値を設定する必要があります。

この属性の値は、ディスク全体のパーセント (25%など) またはバイト数 (300MB, 50GBなど) で設定できます。デフォルト値は0です。これは、チェックが無効かつバックアップが常に開始可能ということでます。

この属性はグローバルに、またはサーバーごとに設定できます。

  • グローバル設定

zmprov mcf zimbraBackupMinFreeSpace <value>
  • サーバー設定

zmprov ms <zmhostname> zimbraBackupMinFreeSpace <value>

設定した値の空容量さえあれば、バックアップのセッションは実行します。その値より実際のバックアップファイル大きいと、バックアップのセッションは失敗します。バックアップファイルのサイズを監視して、設定した値よりもバックアップ容量が必要な場合は修正する必要があります。

データの復元

以下の3つの復元方法を実行できます。

  • Zimbra Collaboration メールボックスサーバーが起動中にメールボックスを復元する場合、zmrestore コマンドを使用します。

  • zmrestoreoffline — メールサーバーがオフラインの際にメールサーバーを復元する場合、zmrestoreoffline コマンドを使用します。このコマンドはディザスタリカバリに使用します。

  • zmrestoreldap — LDAPディレクトリサーバーの内容を復元する場合、zmrestoreldap を使用します。

復元プロセスではすべてのアカウント、または特定のアカウントを指定することができます。

復元のプロセス

プロセス zmrestore が以下の手順でメールボックス、データベース、インデックス、そしてLDAPのディレクトリを復元します。

  1. リストア対象として指定されたアカウント、または all を指定した場合にバックアップされているすべてのアカウントを取得します。

  2. 各メールボックスに以下の手順を実行します。

    1. 既存データをクリアするため、サーバーに存在するメールボックスを削除します。

    2. 直近の完全バックアップから、対象のメールボックス分にあたるMariaDBデータ、インデックスデータおよびメッセージディレクトリを復元します。

    3. すべての増分バックアップにあるRedoログを直近の完全バックアップから復元したデータに適用します。

    4. メールボックスサーバーのRedoログのアーカイブから、対象のメールボックス分にあたるRedoログを適用します。

    5. 現在のRedoログを適用します。

アカウントの割り当て容量を超えても、アカウントは復元されます。ユーザーが割り当て容量に関するアクションを次回実行した際に、そのユーザーは割り当て容量を超えている旨の警告を受信します。
Microsoft OutlookのZimbraコネクターを利用しているユーザーについて、Zimbraサーバーが復元されたらOutlookクライアントで初回の同期を実行する必要があります。

Example 28. server1 にあるすべてのアカウントを完全に復元する。

直近の完全バックアップとその後に実行された増分バックアップを含みます。

zmrestore -a all
Example 29. server1にある特定のアカウントの復元を実行する。