電子メールの自動処理ルール

システム管理者は、サーバーワイドルールとクラスタワイドルールを指定できます。指定する場合、 WebAdmin インターフェイスで［Settings］ セクションの［Queue］ ページを開きます。その後、 ［Rules］ リンクをクリックします。

また、システム管理者は、アカウントルールの指定が可能です。指定する場合、［Account Settings］ ページのリンクをクリックします。

ユーザーは、WebUser インターフェイスを使って、そのユーザーのルールを指定できます。ユー ザーがルールのアクションを指定している場合でも、システム管理者またはドメイン管理者は、その アクションを制限できます。

システム管理者またはドメイン管理者は、ドメインワイドルールを指定できます。指定する場合、 ［Domain Settings］ ページの［Rules］ リンクをクリックします。

ルールの設定については、詳しくは自動処理ルールのセクションを参照してください。

ルールにはそれぞれ一般（基本）条件を使用できます。一般条件の詳細については、ルールのアク ションの説明を参照してください。
ここでは、電子メールの自動処理ルール（キュールール） で使用できる追加の条件について説明しま す。このほか、上記の一般条件も使用できます。

From [is | is not | in | not in] string

この条件を使って、メッセージのFrom アドレスが、パラメータに指定した文字列に一致す るか（is とin）、または一致しないか（is not とnot in） をチェックできます。　

下は、例です。

From is

この条件は、メッセージが、stalker.com のいずれかのサブドメインのアカウントから送られ たメッセージだった（From アドレスがstalker.com のいずれかのサブドメインのユーザーの アドレスだった） 場合、満足されます。

Sender [is | is not | in | not in] string
To [is | is not | in | not in] string
Cc [is | is not | in | not in] string
Reply-To [is | is not | in | not in] string

上記の4 つの条件は、From 条件と基本的に同じです。それぞれ、メッセージのSender、 Reply-To、To、Cc の各アドレスがチェックされます。

上記の条件のいずれも、メッセージに同一種類（例えば、To） のアドレスが複数あった場 合、その中のいずれか１ つのアドレスがパラメータの文字列（のいずれか） に一致したとき （is とin）、または一致しなかったとき（is not とnot in） に条件が満足されます。指定さ れている種類（From） のアドレスがメッセージになかったときには、条件は満足されませ ん。

Any To or Cc [is | is not | in | not in] string

処理は、上記の条件と基本的に同じです。ただし、この条件では、メッセージのTo アドレ スとCc アドレスがすべてチェックされ、その中のいずれか１ つのアドレスがパラメータの 文字列（のいずれか） に一致（is とin）、または一致しなかった（is not とnot in） とき に条件が満足されます。メッセージにTo アドレスとCc アドレスが何もなかったときには、 条件は満足されません。

Each To or Cc [is | is not | in | not in] string

この条件では、メッセージのTo アドレスとCc アドレスの両方がチェックされ、すべてのア ドレスが一致（is とin） または一致しなかった（is not とnot in） 場合、条件が満足され ます。また、メッセージにTo アドレスまたはCc アドレスが何もなかったときにも、条件が 満足されます。

下は、例です。

Each To or Cc in

上の条件は、メッセージのTo アドレスとCc アドレスがすべて、ドメインmycompany.com のアドレス、または、ドメインmydept.mycompany.com のアドレスだった場合、満足されま す。

Return-Path [is | is not | in | not in] string

この条件では、メッセージのリターンパス（またはMAIL FROM） がパラメータの文字列と比較されます。

'From' Name [is | is not | in | not in] string

この条件の処理は、上の条件と基本的に同じです。ただし、リターンパスではなく、From アドレスの中の「アドレスコメント」（実名） がチェックされます。

下は、例です。

'From' Name is

この条件は、From: アドレスが次の場合だったときに満足されます。
From: jsmith@company.com (John J. Smith)
From: "Bill J. Smith" b.smith@othercompany.com
From: Susan J. Smith <susan@thirdcompany.com>

Subject [is | is not | in | not in] string

この条件では、文字列（件名）を指定し、その文字列とメッセージの件名が一致（is）する か、または一致しない（is not）かをチェックできます。

下は、例です。

Subject is

上の条件は、メッセージの件名が次の場合だったときに満足されます。
Subject: we urgently need your assistance
Subject: Urgent!

Message-ID [is | is not | in | not in] string

この条件では、メッセージID が、パラメータに指定した文字列に一致するか（is とin）、 または一致しないか（is not とnot in） をチェックできます。

下は、例です。

Message-ID is not

上の条件は、メッセージID がない場合、またはメッセージID に@ が使われていない場合、 満足されます。

Message Size [is | is not | less than | greater than] number

この条件では、メッセージのサイズ（単位はバイト数） を指定し、そのサイズを下回るメッ セージ、または、そのサイズを上回るメッセージをチェックできます。

下は、例です。

Message Size greater than

上の条件は、メッセージのサイズが100 キロバイトを超えていた場合、満足されます。

Human Generated

この条件では、メッセージが自動メッセージ生成ソフトウェアによって作成されたかどうか をチェックできます。
注意: この条件にはパラメータはありません。したがって、処理コード（演算子） とパラ メータ値（指定した場合） はすべて無視されます。

この条件では、処理時、メッセージヘッダに次のフィールドが置かれていないかどうか チェックされます。このチェックにより、メッセージが自動メッセージ生成ソフトウェアに よって作成されたかどうかが判定されます。

Precedence: bulk
Precedence: junk
Precedence: list
X-List*
X-Mirror*
X-Auto*
X-Mailing-List

この条件では、また、メッセージリターンパスが空白かどうかもチェックされます。

Header Field [is | is not | in | not in] string

この条件では、メッセージのRFC822 ヘッダに、パラメータに指定したヘッダフィールドが 含まれているか（is とin）、または、含まれていないか（is not とnot in） をチェックで きます。この条件ではまた、Add Header 処理（下記を参照） で追加されたヘッダフィールド もチェックされます。

下は、例です。

Header Field is not

Any Recipient [is | is not | in | not in] string

この条件では、メッセージのエンベロープアドレス（ メッセージの「封筒」にかかれている 宛名） が、パラメータに指定した文字列と比較されます。この条件をアカウントレベルの ルール（アカウントルール） として使用した場合、そのアカウントにルートされるアドレス だけがチェックされます。

この条件では、アドレスは、ルーティングテーブル、その他の方法で処理される前の形式で 処理されます。また、アドレスにエイリアスが複数設定されている場合、エイリアスも チェックされます。したがって、パラメータに特定のエイリアスを指定して、アドレスを チェックすることもできます。

中には、メッセージがESMTP ORCPT パラメータを使って別のサーバーに送信されることも あります。このパラメータは通常、リレー/ 転送サーバーで使われ、このパラメータを使う ことで、そのサーバーで作成されるアドレスの形式（送信先のサーバーでオリジナルのアド レスを取得できるかどうか） を指定できます。その後、アドレスがリレー/ 転送サーバー上 で変換されます。

下は、この処理の例です。

• メッセージがいずれかのサーバーで作成され、アドレスuser1@domain1.com に送られま す。
• メッセージがサーバーdomain1.com で受信され、エンベロープアドレスが user2@domain2.com に変換されます（ メール転送）。
• メッセージが、サーバーdomain1.com からCommuniGate Pro サーバーdomain2.com にリ レー送信されます。
• CommuniGate Pro サーバーdomain2.com でメッセージが受信されます。
• CommuniGate Pro サーバーdomain2.com 上で、user2 がuser3 のエイリアスであることが検 出され、メッセージがuser3 にルートされます。

上で、サーバーdomain1.com が最近の高機能サーバーのときには（ESMTP ORCPT パラメー タをサポート）、オリジナルのアドレスがuser1@domain1.com であることがCommuniGate Pro サーバーdomain2.com に通知されます。この場合、CommuniGate Pro サーバーdomain2.com では、文字列<user1@domain1.com> （オリジナルのアドレス） を使って、この条件 （Recipient） が実行されます。

一方、サーバーdomain1.com からオリジナルのアドレスがCommuniGate Pro サーバー domain2.com に通知されなかったときには（ESMTP ORCPT パラメータなし）、文字列 <user2@domain2.com> を使って、この条件（Recipient） が実行されます。

この条件は、エンベロープアドレスのうち少なくても１ つが該当すれば、満足されます。

Each Recipient [is | is not | in | not in] string

この条件は、上の条件と基本的に同じです。ただし、この条件は、すべてのエンベロープア ドレス（アカウントレベルのルールの場合、そのアカウントにルートされるすべてのエンベ ロープアドレス） が該当したときに満足されます。

Source [is | is not | in | not in] string

この条件では、メッセージが「信頼」できるソースからのメッセージ（つまり、［Client IP Addresses］ リストに登録されているネットワークアドレスのコンピュータからSMTP を介し て送信されたメッセージ） であるかどうか、または、「正規」のソースからのメッセージ （SMTP、WebUser、MAPI、POP XMIT、ルールなどを介して、そのオリジナルの送信元が検 証、認証されたメッセージ） であるかどうかをチェックできます。

下は、例です。

Source isis notinnot in

Security [is | is not | in | not in] string

この条件では、メッセージが暗号化されているかどうか、また、署名付きであるかどうかを チェックできます。指定できる文字列（string）は次の通りです。

SMIME:encrypted	メッセージがS/MIME 標準を使って暗号化さ れているかどうかをチェック。
SMIME:signed	メッセージがバイナリS/MIME 標準（PKCS7） を使ってデジタル署名されているかどうかを チェック。
signed	メッセージがデジタル署名されているかどう かをチェック。
	上記以外の場合、空白。

下は、例です。

Security isis notinnot in

The following conditions can be used in Server-Wide Rules only:

Any Route [is | is not | in | not in] string

この条件では、メッセージの「エンベロープ受取人」アドレス（サーバー内部で使われるア ドレス情報で、この情報を使ってサーバー上でメッセージが配信されます） をチェックでき ます。処理では、受取人のアドレスのルーティング情報と、パラメータに指定した文字列が 比較されます。

この条件は、エンベロープ受取人アドレスのうち（複数指定した場合）、いずれか１ つが一致すれば満足されます。

アドレスのルーティング情報は、次の形式で表されます。

module(queue)address

上で、moduleはアドレスのルート先のモジュールの名前、queueはアドレスのルート（格納） 先のキュー、addressはキューの中のアドレスです。
例えば、エンベロープ受取人アドレスがuser@domain の場合、そのアドレスのルーティン グ情報は次のようになります。

SMTP(domain)user@domain		（domain がリモートドメインの場合）
LOCAL(user)		（domain がメインドメインの場合）
LOCAL(user@domain)		（domain がCommuniGate Pro のセカ ンダリドメインの場合）

WebAdmin インターフェイスの［Router］ ページには［Test］ ボタンがあります。この条件を 使用する場合、あらかじめ［Test］ ボタンを使ってアドレスがどのようにルートされるかを 確認し、その後、条件を定義するのが効率的です。

Each Route [is | is not | in | not in] string

この条件は基本的に上記の条件と同じですが、メッセージのエンベロープアドレスがすべて 一致した場合（または、すべて一致しなかった場合） に満足されます。

ルールにはそれぞれ、単一もしくは複数のアクション（またはアクションなし） を定義できます。 ルールに指定した条件がすべて満足された場合、定義したアクションが実行されます。

ルールにはそれぞれ一般（基本）アクションを使用できます。一般アクションの詳細については、ルールのアクションの説明を参照してください。ここでは、電子メールの自動処理ルール（キュー ルール）で使用できる追加のアクションについて説明します。このほか、上記の一般アクションも使 用できます。

Stop Processing

このアクションについては、詳しくは自動処理ルールのセクションを参照してください。こ のアクションを定義しておくと、ルールが終了しメッセージがINBOX メールボックスに格 納されます。

Discard

このアクションは、ルールの最後のアクションとして定義しなければなりません。このアク ションを定義しておくと、ルールが終了します。また、他のルール（優先度が下位のルー ル） も実行されません。条件で選択されたメッセージは破棄され、したがって、INBOX メー ルボックスに格納されることはありません。ただし、配信通知（Delivery Notification） は メッセージの送信者に返送されます（設定されている場合）。

下は、例です。

IF From is *that_annoying_guy@*
THEN
Discard

Reject With [error message text]

このアクションについては、詳しくは自動処理ルールのセクションを参照してください。　 パラメータには文字列を指定でき、その場合、この文字列がメッセージテキストとして使わ れます。拒否されたメッセージを格納することもできます。方法は、まず、Store アクショ ンを定義し、その後、このReject アクションを定義します。

下は、例です。

IF Subject is *UCE*
THEN
Reject   please do not send such messages here

Mark flagName [, flagName...]

このアクションでは、メッセージのフラグを指定し、そのフラグをセットまたはリセットで きます。通常、メッセージのフラグ（のセット） は初めは空です。ただし、メッセージに何 らかの記録済みメディア（ボイスメール、ビデオメール） が格納されているときには、メ ディアフラグがセットされています。

• the Media flag - if the message contains a voicemail or videomail (if the message has the audio/*, video/*, or multipart/voice-message Content-Type).
• the Hidden flag - if the message header contains the Sensitivity field with the private value.

フラグ名（flagName） を指定しておくと、そのフラグがメッセージに設定されます（名前 はセットで指定できます）。一方、フラグ名の逆名を指定しておくと、そのフラグが削除さ れます。
Store in アクションの結果、メッセージがメールボックスに格納される場合、または全ルールが適用されたためメッセージがINBOX に格納される場合、このアクションで指定したフ ラグとともにメッセージが格納されます。

下は、例です。

IF Sender is *list*
THEN
Mark Flagged,Read

Add Header header fields

このアクションでは、メッセージにRFC822 ヘッダフィールドが追加されます。デフォルト では、Return-Path フィールドが追加されます。このフィールドは、メッセージのエンベ ロープのリターンパスをもとに自動的に生成されます。
指定したフィールドは、Store アクションでメッセージがメールボックスが格納される際、 また、すべてのルールの実行後、メッセージがINBOX メールボックスに格納される際、そ のメッセージのフィールドとして格納されます。

下は、例です。

IF Subject is *purchase*order*
THEN
Add Header X-Special-Processing: order

Add Header アクションでは、X-Color フィールドを追加することもできます。X-Color フィー ルドは、WebUser インターフェイスで検出されます。このフィールドがある場合、メール ボックスのメッセージがハイライトされます。

下は、例です。

IF Header Field is X-Spam: *
THEN
Add Header X-Color: red

Tag Subject tag

このアクションに文字列（tag） を指定しておくと、その文字列が件名（Subject） ヘッダ フィールドに追加されます。
メッセージの保存、送信、コピー、外部プログラムへの送信の際、ここで指定したタグが件 名ヘッダフィールドの先頭に挿入されます。

下は、例です。

IF From is ceo@mycompany.dom
THEN
Tag Subject [CEO]

このTag Subject アクションは、複数作成して同じメッセージに使用することもできます。そ の場合、直前に使用されたTag Subject アクションのタグが先頭に追加され、その次のTag Subject アクションのタグが2 番目に（その後も同じ） 追加されます。最後にメッセージの件 名が配置されます。

注意: 以下のアクションではいずれも、自動的にオリジナルのメッセージが破棄されること はありません（オリジナルのメッセージはINBOX に格納されます）。したがって、メッセー ジをINBOX に残さないで別のメールボックスにリダイレクトしたい場合、Redirect アクショ ンを指定し、その後、Discard アクションを指定します。

Store in mailbox name

このアクションでは、アカウントのメールボックスを指定し、そのメールボックスにメッ セージをコピーできます。指定するメールボックスは、既存のメールボックスでなければな りません。

下は、例です。

IF From is developer@partner.com
THEN
Store in DeveloperBox
Discard

パラメータのメールボックスの名前（mailbox name） を~user_name/mailbox_name の形式で指定した場合、メッセージは、user_name で示されるアカウントのmailbox_name で 示されるメールボックスに格納されます。この形式で指定する場合、そのメールボックスに ついて［Insert］ （挿入） アクセス権がなければなりません。

下は、例です。

IF Subject is *Make*$*
THEN
Store in ~postmaster/abuse
Discard

指定したメールボックスがオープンできない場合、または、指定したメールボックスにメッ セージを格納できない場合、ルール処理は終了します（Stop Processing アクションの処 理と同じです）。

Store Encrypted in mailbox name

このアクションの機能は、Store in アクションと基本的には同じです。ただし、メッセージ はS/MIME 暗号化形式に変換された後、保存されます。

Redirect to addresses

このアクションでは、パラメータに単一もしくは複数の電子メールアドレスを指定し、その アドレスにメッセージをリダイレクトできます。電子メールアドレスを複数指定する場合、 各アドレスをコンマ（,） で区切ります。
指定したアドレスは、メッセージのTo/Cc フィールドの内容として使われます。ただし、ア ドレスの接頭辞として文字列[bcc] を付加しておくと、この置き換えは行われません。
リダイレクトされるメッセージのリターンパス（Return-Path） として、カレントのアカウン トの電子メールアドレスが挿入されます。または、このアクションをサーバーワイドルール またはクラスタワイドルールで使用している場合、アドレスとしてMAILER-DAEMON が挿 入されます。また、同じアドレス（カレントのアカウントの電子メールアドレスまたは MAILER-DAEMON） がメッセージヘッダのSender フィールドに挿入されます。
Return-Path フィールド（ある場合） は、X-Original-Return-Path フィールドに変更されます。
Return-Receipt-To フィールドとErrors-To フィールドは削除されます。
Message-ID、Date、Sender の各フィールド（ある場合） の名前はそれぞれ、X-Original- Message-ID、X-Original-Date、X-Original-Sender に変更されます。
Date フィールドとMessage-ID フィールドが新たに作成されます。

Forward to addresses

このアクションでは、アドレスを指定し、そのアドレスにメッセージを転送できます。この アクションは、上のRedirect アクションと基本的に同じですが、リターンパスアドレスは、 Sender フィールドには挿入されません。代わりに、リターンパスアドレスは、新規のFrom アドレスとして使われます。
既存のFrom フィールドは、その名前がX-Original-From フィールドに変更されます。

Mirror to addresses

このアクションでは、アドレスを指定し、そのアドレスにメッセージをミラー（ リダイレク ト） できます（ このアクションの場合、ヘッダの変更は最低限に抑えられます）。
リダイレクトされるメッセージのリターンパスは、そのまま維持されます。
Resent-From ヘッダフィールドが追加されます。このフィールドには、カレントのユーザー の電子メールアドレスが格納されます（実名は格納されません）。このアクションをサー バーワイドルールまたはクラスタワイドルールで使用している場合、Resent-From ヘッダ フィールドには、アドレスとしてMAILER-DAEMON が挿入されます。
Return-Path フィールド（ある場合） は、X-Original-Return-Path フィールドに変更されます。
Return-Receipt-To フィールドとErrors-To フィールドは削除されます。

Reply with message text

このアクションでは、テキストを指定し、そのテキストを応答メッセージ（自動応答メッ セージ） として使用できます。応答メッセージは、オリジナルのメッセージのReply-To フィールドに指定されているアドレスに送信されます。Reply-To ヘッダフィールドが空の場 合、応答メッセージは、オリジナルのメッセージのFrom フィールドに指定されているアド レスに送信されます。

応答メッセージには、Subject: Re: オリジナルのメッセージの件名とIn-Reply-To: オリジナルのメッセージID　の2 つのヘッダフィールドが自動的に追加されます。

パラメータ（ メッセージテキスト） には、マクロ記号を使用できます。指定したマクロ記号 は、応答メッセージが作成されるときに実際のデータに置き換えられます。使用できるマク ロ記号と処理は、次のとおりです。

^S を指定した場合、オリジナルのメッセージの件名に置き換えられます（形式は、オリ ジナルのメッセージと同じです）。
^s を指定した場合、オリジナルのメッセージの件名に置き換えられます（形式は、MIMEデコード形式が使われます）。
^F を指定した場合、オリジナルのメッセージのFrom アドレスに置き換えられます（形式は、オリジナルのメッセージと同じです）。
^f を指定した場合、オリジナルのメッセージのFrom アドレスに置き換えられます（形式は、MIME デコード形式が使われます）。
^T を指定した場合、オリジナルのメッセージのDate フィールドの内容に置き換えられます。
^I を指定した場合、オリジナルのメッセージのMessage-ID フィールドの内容に置き換えられます。
^R を指定した場合、オリジナルのメッセージのTo フィールドの内容に置き換えられます（形式は、MIME デコード）。
^r is substituted with the E-mail address of the current Account.

下は、例です。

Reply with

Dear ^F! We got your message ^I on ^T. It will be processed shortly and you will be contacted within 1-2 days. Respectfully, Human Resources.

メッセージのヘッダに文字列を挿入したい場合、パラメータ（ メッセージテキスト） の前に "+" 記号を付加し、その下の各行に文字列を指定します（下記の例を参照）。これで、"+" 以 下の各行がヘッダに挿入されます。なお、"+" 記号を使用する場合、Subject フィールドも入 力しなければなりません。理由は、この処理の場合、Subject: Re: オリジナルのメッ セージの件名とIn-Reply-To: オリジナルのメッセージID　の2 つのヘッダフィールド が自動的に応答メッセージに追加されなくなるためです。

"+" 行の下の部分には、Subject フィールドのほか、To、Cc、Bcc の各フィールドも指定で きます。指定した場合、応答メッセージは、各フィールドのアドレスにも送信されます（な お、Bcc フィールドを指定した場合、そのアドレスに応答メッセージは送信されますが、Bcc フィールド自体はメッセージヘッダから削除されます）。

"+" 行の下の部分にFrom フィールドを指定しなかった場合、通常のFrom フィールドにア カウントのアドレスが挿入されます。From フィールドを指定したときには、Sender フィールドにアカウントのアドレスが挿入されます。

"+" 行の下の各ヘッダフィールドには、^S などのマクロ記号も使用できます。

記述が終われば、"+" 行の下の部分の最後に空白行を挿入します。これで、"+" 行の下の部分 と本文（ メッセージテキスト） が区切られます。

Reply with

+Reply-To: special@mycompany.com Subject: your message about ^S X-URL-Ref: http://www.mycompany.com Bcc: statistics@mycompany.com Dear ^F! We got your message ^I on ^T. It will be processed shortly and you will be contacted within 1-2 days. Respectfully, Human Resources.

テキストの前にキャラクタセットを示す文字列（[charsetName] ） を指定しておくと、テ キストが、そのキャラクタセットに変換されます（非ASCII 文字はすべてUTF-8 キャラクタ セットで保存されます）。キャラクタセットを示す文字列を指定しなかったときには、受信 メッセージで指定されているキャラクタセットが使用されます。受信メッセージにキャラク タセットが指定されておらず、このルールがアカウントレベルのルールだった場合、アカウ ントWebUser プレファレンスで指定されている優先キャラクタセット（Preferred Charset） が使われます。

テキストの先頭に"+" 記号を付加する場合（上の例）、まずキャラクタセットを示す文字列 （[charsetName] ） を指定し、その後、"+" を入力します。

ヘッダ（"+" 記号の部分） にMIME-Version フィールドとContent-Type フィールドを指 定しなかったときには、この2 つのフィールドは自動的にメッセージに追加されます。

Reply to All with message text

このアクションは、上記のReply with と基本的に同じですが、応答メッセージは、オリジナ ルのメッセージのTo: とCc: の各フィールドに指定されているアドレスすべてに送信されま す。

React with message text

このアクションは、Reply with アクションと似ていますが、メッセージ本文の上にヘッダ （ と空白行） を指定できます。ヘッダとしては、To、Cc、Bcc の各フィールド（任意の数だ け指定可） のほかSubject フィールド、また任意の数のフィールドを指定できます。
メッセージは、指定したアドレスに送信されます。

ヘッダとメッセージ本文には、マクロ記号（上記を参照） を使用できます。

From、Sender、MIME-Version、Content-Type の各フィールドは、Reply with アクショ ンと同じように扱われます。

下は、例です。

React with

To: 123456@pager.mycompany.com (my pager) Cc: "My Home Account" <myhome@provider.com> FYI: message ^I was received from ^F. Its Subject was: ^S

また、テキストの前にキャラクタセットを示す文字列（[charsetName] ） を指定すること もできます。

下は、例です。

React with

[ISO-8859-1]To: myhome@provider.com (my Home Account) MIME-Version: 1.0 Content-type: text/html; charset=ISO-8859-1 <HTML><BODY> Nachricht <B>^I</B> wurde empfangen von ^F <P>Das Betreff war: <I>^S</I> </BODY></HTML>

Execute command line

パラメータにコマンドを指定し、そのコマンドを別個のOS プロセス（ タスク） として実行 できます。
実行時、メッセージテキスト（ヘッダと本文） がタスクに送られます。メッセージテキスト は、そのタスクの標準入力（ stdin） として使われます。
注意: タスクでは、標準入力データストリーム全体が読み込まれなければなりません。そう でない場合、このExecute アクションは失敗します。

コマンドテキスト（コマンドライン） には、下記のように、接頭辞として[FILE] タグを付 加できます。

[FILE] myprogram parm1　（myprogram ＝プログラム名、parm1 ＝パラメータ1）

この接頭辞を付加した場合、タスクの標準入力は空（閉鎖） の状態になり、次の文字列（-f はフラグ、fileid はメッセージファイルの名前で、ベースディレクトリからの相対パス） がコマンドテキストの末尾に追加されます。
The string -f Queue/fileid.msg 例えば、下記の文字列がコマンドテキストの末尾に付加されます。

-f Queue/12002345.msg

注意: 通常、一般のユーザーにはベースディレクトリへのアクセス権は付与されていませ ん。その場合、接頭辞[FILE] は、サーバーワイドルールでのみ使用できます。

コマンドテキストには、下記のように、接頭辞として[RETPATH] タグを付加できます。

[RETPATH] myprogram parm1

この接頭辞を付加しておくと、下記の形式で、コマンドテキストの末尾に文字"-p" とメッ セージのリターンパスアドレスが追加されます。

-p "address@domain.com"

コマンドテキストには、下記のように、接頭辞として[RCPT] タグを付加できます。

[RCPT] myprogram parm1

この接頭辞を付加しておくと、下記の形式で、コマンドテキストの末尾に文字"-r" とメッ セージの受取人アドレスのリストが追加されます。

-r "address1@domain1.com" "address2@domain2.com"

コマンドテキストには、下記のように、接頭辞として[ORCPT] タグを付加できます。　

[ORCPT] myprogram parm1

この接頭辞を付加しておくと、下記の形式で、コマンドテキストの末尾に文字"-r" とメッ セージの受取人アドレスのリストが追加されます。この接頭辞の場合、受取人アドレスが、 「オリジナルの受取人」パラメータ（ESMTP ORCPT パラメータ） とともに提供された場合、 そのオリジナルのアドレスが使われます。　

-r "origAddress1@domain1.com" "origAddress2@domain2.com"

注意: [RCPT] と[ORCPT] は同時に使用することはできません。

A command text in an Account-Level Rule can be prefixed with the [ACCNT] tag:

[ACCNT] myprogram parm1

When this prefix is specified the -u string followed by the Account name is added to the command text:

-u "accountName@domainName"

A command text in a Server-Wide Rule can be prefixed with the [ROUTE] tag:

[ROUTE] myprogram parm1

When this prefix is specified the string -R followed by the Routed recipient addresses is added to the command text:

-R "LOCAL(accountName@domainName)" "SMTP(example.com)user@example.com"

See the conditions section for the Route data format information.

コマンドテキストには、接頭辞として[STDERR] タグを付加できます（下記を参照）。

コマンドテキストには、上記の接頭辞を任意の順番で複数指定することができます。ただ し、追加の順番は決まっています。例えば、[FILE]、[RETPATH]、[RCPT] の3 つの接頭辞を

指定した場合、その順番にかかわらず、まず-f フラグとそのパラメータ、次に-p フラグと そのパラメータ、最後に-r フラグとそのパラメータという順番で追加されます。

タスクが完了すると、タスクの終了コードがチェックされます。チェックで、終了コードが 0 の場合、アクションの処理は成功したと解釈されます。この場合、次のアクションが実行 されます。タスクの終了コードが0 以外だった場合、メッセージに対する処理は拒否され、エラーコー ド（"automated processing failed"） が出力されます。また、タスクの標準エラー チャンネルから出力されたデータが、タスクの終了コードとともにログに記録されます。　
コマンドラインに接頭辞[STDERR] が付加されていたときには、標準エラーチャンネル（あ る場合） に書き込まれたデータを使って、エラーレポートが生成されます。

タスクの標準出力から出力されるデータのサイズは（プログラムでデータが出力される場 合）、4K バイトを超えないようにしなければなりません。このサイズを超えると、その情報 がログに記録された後、データが廃棄されます。

タスクの実行中、その処理がCommuniGate Pro サーバーで監視されます。タスクが2 分以内 に完了しなかった場合、その処理は中断されます。

Execute アクションをアカウントレベルのルールで使用した場合、アカウントのOS ユーザー 名設定を使ってOS ユーザー名が生成されます。また、タスクは、OS ユーザー環境で実行 されます。

CommuniGate Pro をUnix システムで動作させている場合、タスクには、Unix システムで使わ れているユーザーID、グループID、グループセットが割り当てられます。また、タスクの カレントディレクトリとしては、Unix のユーザーホームディレクトリが使われます。
MS Windows、AS/400、BeOS のいずれかでCommuniGate Pro Server を動作させている場合、 Execute アクションをアカウントレベルのルールで使用することはできません。

Execute アクションのタスクがサーバーワイドルールで実行される場合、そのタスクは、 CommuniGate Pro サーバーの独自の環境で起動されます（つまり、ベースディレクトリがカ レントディレクトリとして使われます）。

下は、例です。

Execute

myscript --myoption -f requests/archive

ExternalFilter

This action tells the Server to pass the message to an External Filter program. This action can be specified only in the Server-Wide Rules. The parameter specifies the name of the External Filter program to use.

下は、例です。

ExternalFilter

McAfee

Accept Request options

このアクションを使って、サーバーから外部フィルタプログラムにメッセージを渡すことが できます。このアクションは、サーバーワイドルールでのみ使用が可能です。パラメータと しては、外部フィルタのプログラム名前を指定します。

サーバーワイドルールの場合、その処理は、Enqueuerコンポーネントを介してログに記録されます。 ログレベルを［Low-Level］ または［All Info］ に設定しておくと、使用されたルールと実行さ れたアクションを確認できます。

一方、ドメインワイドルールとアカウントルール（アカウントレベルのルール） の処理は、Local Deliveryモジュールを介してログに記録されます。上記と同じく、ログレベルを［Low-Level］ ま たは［All Info］ に設定しておくと、使用されたルールと実行されたアクションを確認できます。