RPOP モジュール

CommuniGate Pro サーバーでダイアルアップ接続（動的IP アドレス） を使用しているときには、SMTP を介してリモートホスト（ISP） からメッセージを受信することはできません。その場合でも、RPOP モジュールを使うことで受信が可能になります。つまり、RPOP モジュールでは、リモートホスト （ISP） のアカウントを指定し、そのアカウントに対してポーリングを行うことができます。このポー リングを介してメッセージを取り出し、CommuniGate Pro サーバーのメールボックスにメッセージを 格納することができます。

RPOP モジュールは、インターネット接続がフルタイムのときでも有用です。例えば、ユーザーによっ ては異なるサーバーにアカウントをいくつも用意しているユーザーもおり、こういったユーザーは、 必要なときにRPOP モジュールを介して各アカウントをポーリングし、CommuniGate Pro の自分のア カウントにメッセージを格納できます。

RPOP モジュールでは、統合ドメインワイドアカウントもサポートしています。統合ドメインワイド アカウントを使用する場合、ISP などのリモートホストに統合ドメインワイドアカウントを作成し、そ のアカウントに、ドメイン宛のメッセージをすべて格納します。その後、統合ドメインワイドアカウ ントのメッセージを取り出し、メッセージヘッダのアドレス情報を使って個々のアカウントに配信し ます。RPOP モジュールでは、複数の統合ドメインワイドアカウントに対してポーリングすることも できます。

RPOP モジュールの動作は、Web ブラウザを使って設定できます。

インターネットを介してメッセージが送信される際、メッセージの差出人と受取人に関する情報が メッセージに挿入されますが、この情報をメールエンベロープと呼んでいます。メッセージがSMTP を介して送信される場合、このエンベロープは、プロトコルコマンドシーケンスの形で送られます。 また、メッセージがUUCP を介して送信されるときには、エンベロープは追加ファイルの形で送られ ます。エンベロープの情報は通常、メッセージヘッダの情報と同じです。ただし、次の2 点が異なり ます。

• メッセージヘッダにはBcc アドレスはありませんが、エンベロープにはあります。
• メーリングリストのメッセージの場合、そのメッセージヘッダには加入ユーザー（購読ユー ザー） のアドレスは記録されません。

メッセージがメールボックスに格納される際、差出人のエンベロープ情報がメッセージヘッダ （Return-Path フィールド） に追加されます。これに対し、受取人のエンベロープ情報は、通常はメッ セージヘッダには追加されません。

RPOP モジュールにより、統合ドメインワイドアカウントからメッセージが取り出される際、メッセー ジのエンベロープが再構築され、その後、最終の受取人に配信されます。ここで、メッセージにReturn- Path ヘッダフィールドがあったときには、そのフィールドのアドレスがエンベロープに差出人アドレ スとして格納され、同時にメッセージのReturn-Path ヘッダフィールドが削除されます（Return-Path ヘッダフィールドは、メッセージが最終の受取人に配信されるときに再作成されます）。

統合ドメインワイドアカウントをメールシステム上に作成しており、そのメールシステムに、エンベ ロープに格納されている受取人アドレスをヘッダフィールドにコピーする機能がある場合、PROP に よるメッセージの配信は、SMTP による配信と同程度の信頼性で実行されます。
［Unified Domain-Wide Accounts］ パネルの［Special Header］ フィールドにヘッダフィールドの名前（例 えば、X-Real-To） を入力してある場合、RPOP モジュールによって統合ドメインワイドアカウントか らメッセージが取り出される際、そのヘッダフィールドが検索されます。検索後、そのヘッダフィー ルドのアドレスがエンベロープ（新規に作成されるエンベロープ） に挿入され、このアドレスに向け てメッセージが送信されます。この場合、そのヘッダフィールド自体は、メッセージから削除されま す。エンベロープに挿入されるアドレスにはいずれも「失敗時にレポート」フラグが追加されます。 そのため、メッセージの配信が失敗したときには、オリジナルの差出人（ メッセージのReturn-Path フィールドに格納されているアドレス） にエラーレポートが送信されます。

RPOP モジュールでは、メッセージの取り出し後、To:、Cc:、Bcc: の3 つのヘッダフィールドが検 索されます。各フィールドにアドレスが格納されている場合、アドレスはいずれも、CommuniGate Pro のローカルのアカウントにルートされます。

アドレスがSMTP などのモジュールにルートされる場合、または、アドレスのルーティングが不可能 な場合（例えば、不明のユーザー名エラーなど） には、差出人にはエラーメッセージは送信されませ ん。この場合、アドレスは無視されます。

メールシステムで、エンベロープの受取人アドレスがメッセージヘッダに追加されない（ したがって、 特殊ヘッダフィールドを使用できない） 場合、配信可能なアドレスには「失敗時にレポートしない」 フラグが追加されます。そのため、そのアドレスのメッセージが何らかの理由で失敗したときでも、 オリジナルの差出人にエラーレポートが送信されることはありません。

To:、Cc:、Bcc: のいずれのアドレスも処理できなかった（配信不可能） だったときには、RPOP モ ジュールにより、メッセージがメインドメインのポストマスター（postmaster） アカウントに送信さ れます。

上記のように、RPOP モジュールではTo:/Cc: ヘッダフィールドの解析（検索） が行われますが、こ の処理は、上記のようなシステムでは問題が起こります（エンベロープの受取人アドレスがヘッダ フィールドに追加されないため、アドレス情報の収集ができません）。また、システムによっては、ア カウントが統合ドメインワイドアカウントの場合、適切に処理されないこともあります。例えば、メッ セージの送信先として、同じドメインのユーザー3 人が指定されている場合、こうしたシステムでは、 統合ドメインワイドアカウントのメールボックスに内容が同じメッセージが3 つ格納されることがあ ります。また、メッセージにはそれぞれ3 人のユーザーのアドレスが格納されており、したがって、 ユーザーはそれぞれ、同じ内容のメッセージを3 つ受け取ることになります。

上記の重複配信の問題（また、Bcc ヘッダフィールドやメーリングリストに関連して起こる問題） は、かなり深刻です。そのため、統合ドメインワイドアカウントを使用する場合、事前に、プロバイ ダのメールシステムを調査し、そのシステムで、統合ドメインワイドアカウントにメッセージが格納 される際、エンベロープ情報がヘッダフィールドとして追加されるかどうかを確認することが必要で す。この処理が行われる場合、特殊ヘッダ機能（［Special Header］ オプション） を使用するようにし ます。