Version 5.1
メッセージ転送 |
|---|
| ||||||||
|
|
Version 5.1 |
||||||||||||||||||||||||||||||
|
|
Local Delivery モジュールを設定する場合、CommuniGate Pro の管理者ポートに接続し、［Settings］ セ クションの［LOCAL］ ページを開きます。
送信フローコントロールとは、正規のユーザーから送信されるメッセージを制御することをいいます。 具体的には、CommuniGate Pro のアカウントから送信されるメッセージのうち、AUTH （認証） 処理 を使って、WebUser インターフェイス、MAPI モジュール、POPモジュールのXTND XMIT コマンドを 介し、かつSMTP 経由で送信されるメッセージをカウントし、送信を制御することを指します。［Suspend Account Sending if Sent］ オプションには送信メッセージの最大数、［messages within］ オプ ションには時間の長さを指定します。指定した時間内に送信されたメッセージの数が指定した最大数 を超えたときには、そのアカウントのユーザーによるメッセージの送信処理は一時中断されます。
注意: システムのユーザーの中には、AUTH 処理なしでもSMTP を介してメッセージを送信できる ユーザーもいます。つまり、そのユーザーのアドレスが［Client IP Addresses］ リストに登録されて いる場合、または、ユーザーが読み取り後に送信方式を使っている場合、そのユーザーについては AUTH 処理は実行されません。こういったユーザーから送信されるメッセージは、システムのユー ザーからのメッセージとは判断されず、したがってカウントは行われません。全ユーザーからの送信 メッセージについて送信フローコントロールを行いたい場合、全ユーザーに対してSMTP 認証処理を 強制するという方法を使います。この方法を使用する場合、SMTP の［Settings］ ページの［Force AUTH］ オプションを有効にします。
ルータからLocal Delivery モジュールにアドレスが渡されると、Local Delivery モジュールで、そのア ドレスのドメイン名がチェックされます。ドメイン名が文字列.local で終わっていた場合、Local Delivery モジュールにより、その接尾辞.local が削除された後、メッセージがメインドメインのアカ ウントに格納されます。この場合、そのメインドメインのアカウントの名前としては、メッセージの ドメイン名が使われます。この処理を応用することで、Unified Domain-Wide Accounts（ ドメイン全体 で共通して使用できるアカウント） の作成が可能です。
また、状況によっては、統合ドメインワイドアカウントをメインドメインではなくセカンダリドメイ ンに作成したいこともあります。その場合、接尾辞として.domain を使うことで、メッセージをセ カンダリドメインのアカウントに送ることができます。この処理で、アドレスのローカル部の最後の 部分がセカンダリドメインのアカウントの名前として使われます。
上の処理は、ルータからLocal Delivery モジュールに対して「最初の試行」呼び出しが実行されたとき に行われ、この時点では、上記以外のアドレスの処理は発生しません。
その後、ルータからLocal Delivery モジュールに対して「最終の配信」呼び出しが実行されると、Local Delivery モジュールにより、ドメイン名が空白のアドレス（つまりメインドメイン宛のメッセージ）、 または、ドメイン名がセカンダリドメインの名前であるアドレス（つまりセカンダリドメイン宛の メッセージ） がすべて処理されます。最後に、メッセージが、そのアドレスのローカル部と同じ名前 のアカウントにルートされます。
上記のルーティングは「ドメインのみのルーティング」であり（ ローカル部のルーティングはなし）、 このルーティングはHTTP モジュールでもサポートされています。そのため、Local Delivery モ ジュールでは、ローカル部がLoginPage のアドレスのほか、ドメイン部が空白のアドレス、ドメイ ン部がいずれかのセカンダリドメインの名前またはエイリアスであるアドレスもすべて受け付けら れ、処理されます。
Local Delivery モジュールで、電子メールの送信先がローカルのアドレスであると判定されると、その アドレスに指定されているアカウントが実際に存在するかどうかがチェックされます。ここで、アカウントが存在しなかったときには、そのメッセージ（不明なアカウントへのメッセージ） に対して所 定の処理が行われますが、この処理は、各ドメイン（ メインドメインと各セカンダリドメイン）でそ れぞれ設定されています。Local Delivery モジュールでは、その設定にしたがって処理が実行されます。 ドメインに設定されている処理としては、次の3 種類があります。
ドメインで、「拒否（Rejected） 」オプションが設定されている場合、不明なアカウントへのメッセー ジはすべて拒否され、同時に「不明なアカウント」エラーメッセージがメッセージの送信者に送られ ます。
ドメインで、「廃棄（Discard）」オプションが設定されている場合、不明なアカウントへのメッセージ はすべてアドレスNULL にルートされます。つまり、その場で廃棄され、エラーメッセージが出力さ れることもありません。
ドメインで、「リルート（Reroute to）」オプションが設定されている場合、不明なアカウントへのメッ セージはすべて、指定されているアドレスにルートされます。この場合のアドレスとしては、登録済 みローカルのアカウントの名前、または別のサーバーのアカウントの電子メールアドレスを指定でき ます。どちらの場合も、不明なアカウントは、指定されているアドレス（ リルート先のアドレス） に 置換され、そのアドレスを使ってルータにより再度、アドレス処理が実行されます。
不明なアカウントのリルート先のアドレスには、アステリスク（*） を使用することができます。この アステリスクは、不明なアカウントの名前に置き換えられます。
アドレスに接尾辞として.local が付加されている場合、そのメッセージは、ルータにより単一のロー カルアカウントにルートされます（上記を参照）。この機能を使って、統合ドメインワイドアカウント を作成できます。
統合ドメインワイドアカウントは、クライアントシステムから、サーバーに格納されているメッセー ジを取り出したいときに有用です。取り出しは、CommuniGate Pro のPOP モジュールやCommuniGate Pro RPOPモジュール、その他、同等の機能のソフトウェアで行うことができ、取り出したメッセージ は、ローカルのアドレスに配信することができます。また、クライアントシステムで通常のシングル ユーザーメーラーを使ってサーバー上のメッセージを取り出し、そのメッセージを手動で配信すると いった処理も可能です。
ドメインclient1.com のローカル部はルーティングでは使用されませんが、廃棄されることはありませ ん。ローカル部は、Local Delivery モジュールによってメッセージがアカウントCl1 に格納されるとき に、X-Real-To: ヘッダフィールド（または、Local Delivery モジュールの設定で指定されている フィールド） に挿入されます。
ユーザーは、POP モジュールを使って統合ドメインワイドアカウントに格納されているメッセージを 取り出すことができます。その際、ユーザーは、ユーザー名を指定し、そのユーザー名がX-Real-To ヘッダフィールドに格納されているメッセージだけを取り出すことができます。
統合ドメインワイドアカウントは、通常、メインドメインに作成します。また、接尾辞として.domain
を使うことで、セカンダリドメインに統合ドメインワイドアカウントを作成することもできます。
例えば、アドレスがxxxx%accountname@domainname.domain というメッセージは、domainname
で示されるドメインのaccountname で示されるアカウント（統合ドメインワイドアカウント） に格納
されます。また、この場合、xxx が、このメッセージのX-Real-To フィールドに格納されます。
例えば、ドメインcompany.com のドメイン管理者が次の設定を行ったとします。
不明なアドレスへのメッセージをすべて、*%Unknowns@company.com.domain にリダイレクトす
る（ルータテーブルに定義します）。
この場合、不明なアドレス（アカウント） に宛てられたメッセージはいずれも、アカウント
Unknowns 格納され、また、そのアドレスが各メッセージのX-Real-To ヘッダフィールドに挿入さ
れます。
アドレスがLocal Delivery モジュールで受け取られ、処理が完了すると、そのメッセージがモジュール キューに格納されます。キューに格納されているメッセージは、内容や種類に応じて各モジュールに よって取り出されます。その後、モジュールにより、送信先のアカウントがオープンされ、そのアカ ウントに自動メール処理ルールが設定されているかどうかがチェックされます。
アカウントにルールが設定されている場合、そのルールが適用されます。その際、ルールに指定され ている各条件がそれぞれチェックされ、条件がすべて満たされたときに、そのルールに指定されてい るアクションが実行されます。このアクションの結果、メッセージが所定のメールボックスにコピー されたり、別のアドレスにリダイレクトされたり、自動応答が生成されたり、といった処理が行われ ます。
使用されたルールや満足された条件、条件が満たされたときに実行されたアクションに関する情報 は、Local Delivery モジュールのログレベルを詳細レベルに設定することで確認できます。
アカウントのルールが使用され（ルールが設定されている場合）、そのルールによりメッセージが廃棄 されなかったときには、そのメッセージはアカウントのINBOX メールボックスに格納されます。
アカウントのINBOX メールボックスにメッセージが格納される際、Local Delivery モジュールによ り、メールボックスの現在のサイズがチェックされます。チェックで、メッセージを格納すると、ア カウントのストレージクォータ（最大容量） を超えると判断されたときには、そのメッセージの格納 は拒否されます。
アドレスのローカル部がbox#name （ メールボックス名# アカウント名） の形式で指定されている場 合、そのメッセージは、Local Delivery モジュールにより、指定されたアカウント（name） の指定さ れたメールボックス（box） に格納されます。この処理を「直接メールボックスアドレッシング」と 呼んでいます。
アドレスのローカル部がbox#name の形式のメッセージには、アカウントレベルのルール（アカウン トルール） は適用されません。
直接メールボックスアドレッシングは、ルータテーブルで定義できます。下は、ルータレコードの定 義の例です。; store messages to sales@maindomain ; in the sales mailbox in the Account public@maindomain <sales> = sales#public ; ; store messages to support@client.com ; in the requests mailbox in the Account staff in the hq.client.com Domain <support@client.com> = "requests#staff"@hq.client.com
注意: メールボックスの名前は、大文字と小文字が区別されます。
注意: 上記のように直接メールボックスアドレッシングをルータレコードに定義しておいた場合、そ の直接メールボックスアドレッシングは、POP モジュールで使用されます。つまり、ユーザーは、ク ライアントPOP メーラーでログイン名sales でログインすることで、アカウントメールボックス public のメールボックスsales に接続できます（ただし、ユーザーは、アカウントpublic のパス ワードを入力しなければなりません）。
ドメイン設定で、仮想オブジェクトAll を有効にしておいた場合、アドレスall@ ドメイン名に送信さ れたメッセージは、そのドメインのアカウントのうち、［Accept Mail To All］ オプションが有効になっ ているアカウントのINBOX メールボックスに格納されます。
注意: アドレスall に送信されたメッセージには、アカウントレベルのルールは適用されません。
アドレスall@ ドメイン名の代わりにアドレスall@ メインドメイン名を使用することで、全ドメイン の全アカウントにメールを送信することができます。