![]() |
Version 5.1 |
||||||||||||||||||||||||||||||
|
|
メールサーバーでは、グローバルドメインネームシステム(DNS) を使って、メッセージの送信先の コンピュータ、またはメールサーバー(転送の場合) のネットワークアドレスを取得するという処理 が行われます。そのため、ドメインネームシステムのMX レコードと呼ばれるレコードには、メッセー ジの送信先のドメイン(電子メールアドレスの@ 記号の右側の部分) が登録されていることが必要で す。また、MX レコードには、そのドメインに対応するコンピュータの名前、つまり、メッセージを最終 的に受信するコンピュータの名前も格納されています。例えば、MX レコードには、ドメイン company.com に宛てられたメッセージはコンピュータmail.company.com に送信する、また、ドメイン enduser.com に宛てられたメッセージはコンピュータprovider.com に送信する、という情報が記録され ています。
DNS では、単一のドメインについて複数のMX レコードが存在する(つまり、同一のドメインに対応 するコンピュータが複数存在し、それぞれ優先度は別個) こともあります。その場合、優先度が最高 のコンピュータでメッセージの受信が不可能のときには、優先度が次に高いコンピュータ(バックアッ プメールサーバーと呼ばれます) にメッセージが送信されます。その後、バックアップメールサーバー からメッセージがプライマリサーバーに送信されます。
DNS 上で、メッセージの送信先のコンピュータ(またはメールサーバー) の名前が取り出される際、 メッセージを受信したメールサーバーとDNS との間で再度、通信が行われます。この通信により、 メッセージの次の送信先となるメールサーバーの名前がネットワーク(IP) アドレスに変換されます。 このネットワークアドレスは、DNS のA レコードに格納されています。各A レコードは、コンピュー タの名前と、そのネットワーク(IP) アドレス( インターネット上のグローバルのアドレス) の対で 構成されています。
上記のようにして、次の送信先となるメールサーバーの名前がネットワーク(IP) アドレスに変換さ れ、そのネットワークアドレスが、メッセージを受信したメールサーバーで受け取られると、そのメー ルサーバーと次の送信先のメールサーバーとの間でSMTP 接続が確立されます。続いて、次の送信先 のメールサーバーにメッセージが転送されます。その後、メッセージがすべて、そのメールサーバー ( ドメイン) に送信されると接続が閉じます。
メッセージにアドレスが複数あり、そのアドレスのドメインがいずれも同じであるときには、SMTP モジュールを介して、そのドメインのメールサーバーに送信されるメッセージは通常、1 つです。メッ セージを受信したメールサーバーでは、その単一のメッセージをもとに、そのドメインの受取人すべ てに対してメッセージが配信されます。ただし、こうしたアドレスの数が非常に多いときには、SMTP モジュールにより、アドレスがいくつかのグループに分割され、各グループ(それぞれ、アドレスの セットを格納) がメールサーバーに送られます。
また、送信先のドメインが同じメッセージが複数ある場合、SMTP モジュールにより、そのドメイン のメールサーバーに対して複数の接続がオープンされ、各接続を介して複数のメッセージが同時に送 信されます。
メールサーバーを使用しており、そのメールサーバーを使ってメッセージを受信したい場合、ドメイ ン名をドメインネームシステムに登録しなければなりません。登録は、通常、インターネットサービ スプロバイダ(ISP) に依頼することで可能です。この登録により、メールサーバーが動作している コンピュータの名前がDNS レコードに記録されます。
SMTP モジュールの機能は、設定が可能です。設定する場合、Web ブラウザでCommuniGate Pro サー バーに接続し、[Settings] セクションの[SMTP] ページを開きます。なお、SMTP モジュールの設 定を行う場合、[Can Modify Settings] アクセス権が必要です。
[Log] オプションでは、SMTP モジュールによってサーバーログに記録される情報の範囲( ログレベ ル) を指定できます。通常、このオプションは[Major] ( メッセージ転送レポート) または[Problems] ( メッセージ転送/ 非致命的エラー) にしておきます。一方、SMTP モジュールに問題が発生している と思われるときには、[Low-Level] または[All Info] に設定します。この場合、それぞれ、プロトコ ルの低レベルの情報またはリンクレベルの情報がシステムログに記録されます。なお、問題が解決す れば、ログレベルを元に戻します。[Low-Level] または[All Info] のままにしておくと、システムロ グの各ファイルのサイズが急速に大きくなります。
SMTP モジュールによりシステムログに記録されたレコードには、所定のタグが付けられます。具体 的には、受信接続に関するログレコードにはSMTPI タグが、送信接続に関するログレコードには SMTP タグが付加されます。また、バックアップサーバーのウェイアップに使われた接続の場合、そのレコードにはSMTPW タグが付加されます。
インターネットを介してメッセージを送信する場合、使用しているサーバー上にインターネットに対 するTCP/IP リンクが存在していなければなりません。メッセージがリモートホストに転送される場 合、SMTP モジュールにより、このTCP/IP リンク(ネットワーク) を介してリモートホストに接続 が確立されます。その後、SMTP プロトコルを使ってメッセージが送信されます。
SMTP モジュールからインターネット経由でメッセージが送信される場合、メッセージをいずれかの メールサーバーに転送するか、または受取人に直接配信するかがSMTP モジュールによって判別され ます。この処理は、DNS MX レコードを介してインターネット上の受信元ホストを検索するという方 法で行われます。
[Forward to] オプションの右側のテキストフィールドには、転送メールサーバーの名前のほか、 そのサーバーのIP アドレスを指定することもできます。送信メッセージはすべて、SMTP モ ジュールにより、ここで指定した転送メールサーバーに送信され、その後、最終の受取人アド レスに配信されます。
注意: 指定する転送メールサーバーの名前は、メールドメイン名(DNS のMX レコード) では なく、実際のコンピュータ( メールサーバー) の名前(DNS のA レコードに登録されている名 前) でなければなりません。例えば、プロバイダのドメイン名がprovider.com であっても、 そのプロバイダのメールサーバーの名前はmail.provider.com であることもあります。この 場合、mail.provider.com を入力しなければなりません。したがって、転送メールサーバー の名前を指定する場合、プロバイダに確認することが必要です。
注意: 上記のように、転送メールサーバーの名前の代わりに、そのIP アドレスを指定すること もできます。その場合、IP アドレスは、コンマで区切って複数指定することもできます。この ように指定したときには、SMTP から最初のIP アドレスに対して接続が実行され、その接続が 失敗した場合、次のIP アドレスに対して接続が試行されます。
注意: 指定する転送メールサーバーがクラスタバックエンドサーバーの場合、[Forward To] の テキストフィールドにはアステリスク(*) を入力することができます。この場合、アステリス クは、クラスタの全フロントエンド( [Cluster Settings] ページで設定可能) と解釈され、した がって、全フロントエンドが転送メールサーバーとして使用されます。
注意: メッセージの受取人アドレスのドメイン名にIP アドレスが使われている場合(つまり、 user@[12.34.56.78] の形式)、そのメッセージは、IP アドレスが12.34.56.78 であるホストに 直接送信されます。これは、[Forward To] オプションに転送メールサーバーを指定してある ときでも同じです。そのため、同一のLAN 上の各メールサーバーがドメインネームシステム に登録されていなくても、ドメイン名がIP アドレスの電子メールアドレスを使うことで、そ のLAN 上でメッセージの直接交換が可能になります。
この設定は、通常、CommuniGate Pro サーバーのIP アドレスが動的IP アドレスで、また、指定 した転送メールサーバーからATRN メソッドを使ってメッセージを受信する場合に必要です。 ATRN 方式によるメッセージの受信の際にもユーザー名とパスワードが必要ですが、どちらも、 送信の際に必要なユーザー名とパスワードと通常は同じです。
このオプションを選択した場合、メッセージは直接、受取人のコンピュータに送信されるか、ま たは、受取人のコンピュータに「もっとも近い」リレーホストに送信されます。したがって、受 取人は、メッセージをすぐに読むことができます。つまり、転送メールサーバーは使用されず、 通常はメッセージの送信が遅滞することはありません。
CommuniGate Pro サーバーのキューにメッセージが複数格納されており、メッセージの送信先のドメ インがすべて同じ場合でも、通常、SMTP モジュールにより、そのドメインのメールサーバーに対し て接続が確立され、メッセージが1 つずつ送信されます。ここで、確立された接続の速度が遅く、しかも、サイズが大きいメッセージがキューにあった場合、そのメッセージの送信に時間がかかり、他 のメッセージは待機状態に置かれます。こういった場合、SMTP モジュールで確立される接続数(チャンネル数) を増やすことで、サイズの 大きいメッセージと、他のメッセージを並行してメールサーバーに送信できます。この設定は、 [Channels/Host] オプションで可能です。
ダイアルアップリンクの場合のSMTP モジュールの送信処理は、TCP アクティビティスケジュールを 使って制限できます。TCP アクティビティスケジュールを設定している場合、そのスケジュールにし たがって、送信ネットワーク接続が実行されます。SMTP キュー(SMTP モジュールのキュー) に格納 されている送信メッセージは、送信ネットワーク接続が確立した時点で実際に送信されます。
送信ネットワーク接続が確立されると、SMTP モジュールにより、そのキューに格納されているメッ セージがすべて送信されます。
送信ネットワーク接続の確立後、キューに格納されているメッセージがすべて送信されますが、場合 によっては、メッセージの送信が失敗することもあります。こういったメッセージ(またはホストのキューの全メッセージ) は、その送信を一時延期し、その後、送信がリトライされるように設定でき ます。この設定は、[Retrying] パネルを使って行います。
SMTP モジュールからリモートサイトに対してメッセージが送信される際、その送信がセキュア(暗 号化) 接続を使って実行されるように設定できます。この機能は、企業のオフィスが複数あり、各オ フィスの間でインターネットを介して電子メールを交換する場合にとくに有効です。
この設定は、[Send Encrypted (SSL/TLS)] パネルを使って行います。[To Domains] リストには、ド メインの名前を指定します。ここで指定したドメインに対して、CommuniGate Pro サーバーからセ キュア接続を介してメッセージが送信されることになります。
[To Domain] リストでは、ワイルドカードとしてアステリスク(*) も使用できます(上記のパネル を参照)。
CommuniGate Pro のSMTP モジュールから、リストに指定されたドメインのリレーサーバーに接続が 実行される際、そのリレーサーバーでプロトコル拡張コマンドSTARTTLS がサポートされているか どうかチェックされます。サポートされている場合、STARTTLS コマンドを使って、そのリレーと の間でセキュア接続が確立されます。
セキュア接続の確立の際、CommuniGate Pro のSMTP モジュールにより、所定の信頼証明書(のセッ
ト) を使ってリモートリレー(サーバー) の証明書の有効性がチェックされます。
ここで、リモートリレーの証明書の件名(Subject) に格納されているcn(カモンネーム)フィール
ドの値がリモートサイトの名前か、またはリモートリレーの名前と同じであれば、証明書は有効と判
断されます。ただし、問題が生じることもあります。例えば、ドメインcompany.dom のMX レ
コードがrelay1.company.dom で、アドレスがrelay1.company.dom のコンピュータ(サー
バー)のメインのDNS 名がsmtp.company.dom だった場合、そのサーバーの証明書は、その名前
で発行されます(cn フィールドの値がsmtp.company.dom である証明書が発行されます)
この問題は、ルータレコードを使って、トラフィックをすべてsmtp.company.dom ( リレー) を介して ドメインcompany.dom にルートするという方法で解決できます。ルータレコードは、次のようにな ります。
この処理については、詳しくは、このセクションの後述のルーティングの説明を参照してください。
注意: セキュア接続を利用することで、CommuniGate Pro サーバーとリモートリレーの間でメッセー ジを安全に交換することができます。ただし、末端対末端でセキュリティを確保することが重要であ り、したがって、次の点に注意が必要です。一方、[To Domains] リストに指定されているドメインのリレーサーバーで、プロトコル拡張コマンド STARTTLS がサポートされていない場合、または、リレーサーバーの証明書の件名の"cn" フィールド の値がリモートサイトのドメイン名またはリレーサーバーの名前と同じでなかったときには、そのド メインに対するメッセージの送信はすべて拒否されます。この処理により、非セキュアリンクでのメッ セージ送信が回避されます。
送信メッセージが転送メールサーバーを介して送信されるように設定してある場合([Forward to] オ
プション)、リストにアステリスク(*) を入力しておくと、その転送メールサーバーとの通信は必ず、
暗号を使って行われます。
また、同じく、転送メールサーバーを介してメッセージが送信されるように設定してある場合
([Forward to] オプション)、その転送メールサーバーの証明書の件名はチェックされません。
送信接続がポート465 (非標準ポートへの送信を参照) に対して実行された場合、TCP/IP 接続の確 立後、すぐにセキュア(SSL/TLS) プロトコル接続が開始されます。
インターネットを介して送信、または、クライアントメーラーアプリケーションから送信されたメッ セージはいずれも、SMTP プロトコルを使ってサーバーで受信されます。インターネット経由でメッ セージを受信する場合、使用しているサーバー(CommuniGate Pro サーバー) とインターネットとの 間にTCP/IP リンクが存在しなければなりません。さらに、そのサーバーのドメイン名とIP アドレス がDNS レコードに登録されていることが必要です。
メッセージの受信に関する設定(チャンネル、リスナーなど) を行う場合、SMTP の[Settings] ページの[Receiving] リンクをクリックします。クリック後、SMTP の受信に関する設定ページが開 きます。
注意:CommuniGate Pro のSMTP モジュールでは、上記のメーラーやサーバーとは違って、非 ASCII メッセージ(送信メッセージ) をMIME 形式に変換するという処理は行われません。した がって、SMTP モジュールからは、8BITMIME 機能に関する通知を他のサーバーに送信する必要 はありません(RFC1652 に準拠しています)。ただし、最近のインターネットは完全に8 ビットトランスペアレント/ クリーンであり、この関係から、8BITMIME 機能の通知を有効にしておく のが安全です。有効にしておくことで、外部のサーバー上で、8 ビットメッセージをMIME メッ セージに変換するという不要な処理が回避されます。
メッセージの送信者/ 送信元(MAIL FROM プロトコルコマンドを介して送信されたリターンパス) がローカルオブジェクト(ローカルドメインのアカウント、グループ、メーリングリストのいずれ か) だった場合、そのドメインがオープンされると同時に、そのドメインの[SMTP Force AUTH] オプションの設定値がチェックされます。
[SMTP Force AUTH] オプションが何らかの有効な値(nobody 以外) に設定されており、クライアン
トメーラーからSMTP AUTH コマンドが送られてこなかったときには、そのメッセージは拒否されます。したがって、このオプションを使って送信元メーラーのIP アドレスの認証が可能です。
注意: [SMTP Force AUTH] オプションでは、クライアントIP アドレスのうち「正規」のアドレスだ
けがチェックされます。一時的にクライアントアドレスとして処理された「暫定クライアントIP ア
ドレス」はチェックされません。
注意: [SMTP Force AUTH] オプションの使用には注意が必要です。例えば、ユーザーが何らかの メールリレーサーバーを使ってメッセージを送信し、そのメッセージのリターンパスが CommuniGate Pro のアカウント名だったとします。この場合、[SMTP Force AUTH] オプションが有 効で、メッセージの送信先がCommuniGate Pro サーバーだったときには、そのメッセージは拒否さ れます。これは、メールリレーサーバーでは、送信者(CommuniGate Pro のアカウント) を認証でき ないためです。
注意: 通常、サーバーでSMTP AUTH 機能がアドバイズされているときに限ってメーラーからAUTH コマンドが送信されます。そのため、[SMTP Force AUTH] オプションを使って送信者認証を行う場 合、サーバーでSMTP AUTH 機能がアドバイズされていることが必要です。
RCPT TO(受信メッセージの受取人アドレス) コマンドの内容がローカルのアカウントの場合、ア カウントのドメイン設定を使って、そのアカウントの現在の状態をチェックできます。現在の状態の チェック後、そのアカウントに対してすぐにはメッセージを配信できないときには(例えば、スト レージクォータが上限を超えているときなど)、その受取人アドレスは拒否されます。応答コードと しては「暫定失敗」(4xx) が使用されます。
CommuniGate Pro サーバーでダイアルアップリンクを使用する場合、CommuniGate Pro サーバーのド メイン名のMX レコードとして少なくても、もう1 つMX レコードがDNS に存在しなければなりませ ん。このMX レコードには「バックアップ」メールサーバー(通常は、ISP のメールサーバー) を指 定します。CommuniGate Pro サーバーがオフライン(ダイアルアップリンク非使用) の場合、 CommuniGate Pro のドメインに対して送信されるメッセージはすべて、このバックアップメールサー バーに送信されます。
バックアップメールサーバーに格納されているメッセージは、CommuniGate Pro サーバーに送信され るように設定できます。この場合、リトライ(取り出し) 時間は通常、30 分に設定します。したがっ て、少なくても、この時間はCommuniGate Pro サーバーをオンラインにしておき、この間にバック アップサーバーからメッセージの受信が可能になるようにします。
バックアップサーバーのメッセージは、SMTP モジュールからバックアップサーバーに対してETRN ( リモートキュー開始) コマンドを送信することで取り出すことができます( ウェイクアップ)。この コマンドがバックアップサーバーで受信されると、直ちにバックアップサーバーに格納されている メッセージがCommuniGate Pro サーバーに送信されます。
注意: バックアップサーバーの名前は、 メールドメインの名前( ドメイン名) ではなく、実際のコン ピュータ(サーバー) の名前(DNS のA レコード) でなければなりません。例えば、プロバイダのド メイン名がprovider.com で、そのプロバイダのメールサーバーの名前がmail.provider.com の こともあります。したがって、実際のサーバーの名前は、プロバイダに確認することが必要です。ま たは、CommuniGate Pro サーバーのドメインのMX レコードをチェックしても分かります。DNS では、 通常、サーバーのMX レコードの優先度が最高で、優先度が次に高いMX レコードがバックアップサー バーです。
SMTP モジュールのウェイクアップはTCP アクティビティスケジュールによって制限されますので、 このスケジュールの確認も必要です。
上記のように、ETRN ( リモートキュー開始) コマンドを使って、リモートのバックアップサーバーの キューからメッセージを取り出すことができますが、ただし、このコマンドは、サーバー(CommuniGate Pro サーバー) のアドレスが静的IP アドレスのときにのみ使用できます。
CommuniGate Pro サーバーのアドレスが動的IP アドレスの場合、ETRN コマンドは無効です。これは、 動的IP アドレスの場合、バックアップサーバーからはCommuniGate Pro サーバーのIP アドレスが不 明であるためです。その結果、バックアップサーバーでは、CommuniGate Pro サーバーに対して接続 を確立することができません。
CommuniGate Pro サーバーのアドレスが動的IP アドレスのときには、オンデマンドメールリレー方式 を使って、バックアップサーバーからメッセージを取り出すことが必要です。
オンデマンドメールリレーでは、まず、CommuniGate Pro サーバーからバックアップサーバーに対し て接続が実行され、認証後、CommuniGate Pro サーバーからATRN コマンドが送信されます。続いて、 両方のサーバー間で所定の処理が実行され、その後、バックアップサーバーから同じチャンネルを介 してメッセージがCommuniGate Pro サーバーに送られます。したがって、バックアップサーバー側で は、CommuniGate Pro サーバーに対して接続を開く必要はありません。
上のように、バックアップサーバーでは接続が開かれませんが、ATRN コマンドの送信元のサーバー、 つまりバックアップサーバーのメッセージを取り出しを行うサーバーの検証は必要です。そのため、 CommuniGate Pro サーバーからバックアップサーバーに対して名前とパスワードを提供し、その名前 とパスワードがバックアップサーバーで受諾される必要があります。これで、CommuniGate Pro サー バーからATRN コマンドを送信できるようになります。
ATRN コマンドの送信前に必要となる名前とパスワードについては、リモートサーバー(バックアッ プサーバー) の管理者に問い合わせてください。
CommuniGate Pro のSMTP モジュールでは、認証方式としてAUTH CRAM-MD5 が使用され、パスワー ドは暗号化されて送信されます。そのため、リモートサーバーでCRAM-MD5 方式がサポートされて いない場合、クリアテキストの認証ログイン方式を使用しなければなりません。
また、バックアップサーバーでオンデマンドメールリレーがサポートされていないときには、統合ド メインワイドアカウントを使ってメッセージを取り出すことができます。統合ドメインワイドアカウ ントについては、詳しくは本マニュアルの「RPOPモジュール」のセクションを参照してください。
RFC2645 では、ATRN サービスのポートとして、特殊ポート番号366 を使うように推奨しています。
バックアップサーバーで、このポートがサポートされている(または、標準SMTP ポートである25
以外のポート) 場合、[Send Wakeups] の[To] フィールドに、このポート(366) を指定します。
指定する場合、サーバー名とポート番号をコロンで区切ります。下は、例です。
mail.provider.dom:366
また、[Send Encrypted(SSL/TLS)] の[To Domains] リストにバックアップサーバーを登録すること で、バックアップサーバーとCommuniGate Pro サーバーの間でセキュア接続が実行されるようになり ます。
以上のようにして、[Retrieving from a Backup Server] パネルで設定が完了すると、SMTP の [Settings] ページに[Wake Up Now] ボタンが表示されます。このボタンをクリックすると、すぐに ウェイクアップセッション( メッセージの取り出し) が開始されます。
SMTP モジュールはLMTP プロトコルをサポートしています。LMTP プロトコルは、SMTP モジュー ルの全ポートでデフォルトでサポートされています。したがって、LMTP をサポートするため特に ポートを設定する必要はありません。
LHLO LMTP コマンドが受信された場合、SMTP モジュールのモードは自動的にLMTP モードに切り 替わります。
CommuniGate Pro サーバーは、ダイアルアップシステムのバックアップメールサーバーとして使用す ることもできます。ダイアルアップシステムでは、オンラインのときにはメッセージを通常どおり受信できますが、オフラインの場合、メッセージはバックアップサーバー(CommuniGate Pro サー バー) で受信され、格納されることが必要です。バックアップサーバーに格納されているメッセージは、その後、ダイアルアップシステムからイン ターネットに対して接続を実行し、特殊リモートキュー開始コマンド(ETRN コマンド、RFC1985 で 規定) を送信することで取り出すことができます。または、CommuniGate Pro サーバーに対して、ダ ミーの電子メールメッセージを特殊なアドレスに送信するという方法で取り出すこともできます。
ダイアルアップシステムからCommuniGate Pro サーバーにETRN コマンドが送信されると、 CommuniGate Pro サーバーでは、ETRN コマンドのパラメータに指定されているホスト( ドメイン) の メッセージがすべて収集され、各メッセージがダイアルアップシステムに送られます。この処理は、 ETRN コマンドの受信後、すぐに実行され、CommuniGate Pro サーバーからの応答コマンド(認証) も 不要です。
CommuniGate Pro のSMTP モジュールではETRN コマンドをサポートしており、この仕様により、 CommuniGate Pro サーバーをバックアップメールサーバーとして使用することができます。ETRN コ マンドは常時、有効であるため、バックアップサーバーとして使用する場合でもとくに設定の必要は ありません。
SMTP モジュールでは、ルータを使ってETRN のパラメータ( ドメイン名) が処理されます。つまり、 ETRN コマンドの実行時、ETRN のパラメータ( ドメイン名) にウェイクアップユーザー名(架空の名 前) が追加され、通常の形式の電子メールアドレス(wakeup@etrn-parameter) が作成されます。 その後、ルータで、このアドレスがSMTP ホストにルートされると、SMTP モジュールによって、そ のホストのキューが解放(ウェイクアップ) されます。
例えば、ルーティングテーブルで、ドメインclient.com がmail.client.com にルートされるように定義 しておいた場合、ドメインclient.com に向けられたメールはすべて、mail.client.com のキューに格納 されます。ETRN コマンドのパラメータはルータで処理されるため、client.com のETRN コマンド ( ドメイン名としてclient.com を指定したコマンド) により、mail.client.com のキューが解放されま す。
ダイナミッククラスタ環境では、いずれかのクラスタメンバーでETRN コマンドが受信された場合、 すべてのクラスタメンバーのドメインのキューが解放されます。
CommuniGate Pro のSMTP モジュールでATRN コマンドが受信されると、ATRN コマンドの送信元が 認証済み(正規のユーザー) であるかどうかが検証されます。認証済みであると判定された場合、SMTP モジュールにより、そのコマンドに指定されているドメインのキューが解放され、キューのメッセー ジがすべて、その接続(確立済み) を介してATRN コマンドの送信元に送信されます。SMTP モジュー ルのATRN 機能は、デフォルトで有効になっており、設定もとくに必要ありません。ただし、ATRN コマンドを使う場合、次の点に注意が必要です。
ATRN コマンドのパラメータは(指定する場合)、ETRNコマンドと同じように処理されます。
RFC2645 では、ATRN サービスのポートとして特殊TCP ポート366 を使うように推奨しています。 CommuniGate Pro のSMTP モジュールでは、ATRN サービスには、SMTP モジュールのリスナーのポー トであれば、任意のポートを使用できます。ただし、RFC2645 準拠を考慮して、SMTP リスナー設定 にポート366 を追加し、このポート366 を使用することもできます。
旧バージョンのMicrosoft Exchange サーバーではATRN コマンドはサポートされておらず、代わりに TURN コマンドがサポートされています。このTURN コマンドの処理は、パラメータなしのATRN コ マンドの処理と同じで、ATRN コマンドと同じく認証が必要です。また、ATRN コマンドと同様、解 放されるドメインのキューの名前は、正規のユーザーの名前と同じでなければなりません。
上記のように、バックアップサーバー(CommuniGate Pro サーバー) に格納されているメッセージは、ETRN コマンドまたはATRN/TURN コマンドで取り出すことができますが、そのほか、Communi- Gate Pro サーバーに対してダミーの電子メールメッセージを特殊なアドレスに送信するという方法で 取り出すこともできます。特殊なアドレスとは、domainName-wakeup@serverDomain で、この アドレスに任意のメッセージを送信します。domainName にはドメイン名を指定し、ここで指定した ドメインのキューのメッセージが取り出されます。serverDomain は、CommuniGate Pro サーバーのメ インドメインの名前です。
ダイナミッククラスタ環境では、いずれかのクラスタメンバーで、この電子メール( ウェイクアッ プ電子メール) が受信された場合、すべてのクラスタメンバーのドメインのキューが解放されます。
メールの送信先のホストに応じて、メールをSMTP モジュールのキューに一時的に保持しておき、そ の後、送信先(受信元) のサーバーからETRN コマンドやウェイクアップ電子メールが送られてきた ときに送信することができます。この機能は例えば、受信元のサーバーが対称ダイアルオンデマンド ラインで動作していたり、その受信元サーバーについて何らかのトラフィックが発生したときにリン クが自動的に確立されるように設定されている場合に有効です。
リモートシステムからメッセージがSMTP モジュールで受信され、そのメッセージがSMTP モジュー ルによって別のホストに送信されることをリレーと呼んでいます。
SMTP モジュールではリレーが可能ですが、その「濫用」を防ぐため、リレー機能に制限を設定する ことができます。
例えば、送信先がhostName ( ドメイン名) のメッセージがあり、このメッセージが専用IP アドレス (12.34.56.78) を使って送信される場合、メッセージは通常とは異なり、キューhostName には格 納されません。この場合、メッセージは、キューhostNameではなくキュー@12.34.56.78:hostName に格納されます。
専用IP アドレスを利用することで、CommuniGate Pro のドメインから送信されるメッセージを必要 に応じて制御できます。例えば、CommuniGate Pro のいずれかのドメインのIP アドレスがリモート ホストのブラックリストに登録されているとします(そのドメインのユーザーがリモートホストを 「濫用」しているようなときには、ブラックリストに登録される可能性があります)。
この場合、CommuniGate Pro のドメインのうち、そのドメインとは別のドメイン(の専用IP アドレ ス) を使って、そのリモートホストにメッセージが送信されるようにすることで、リモートホストで メッセージの配信が遅延されたり、拒否されたりすることはなくなります。
ETRN コマンドは、ホスト名キュー(キューhostname) だけでなく専用IP アドレス付きキュー (キュー@12.34.56.78:hostName)に対しても有効です。
SMTP モジュールに接続が実行され、その接続がCommuniGate Pro のブラックリストに登録されて いるホストからの接続だった場合でも、直ちに接続が拒否されることはありません。この場合、ま ず、SMTP コマンドであるMAIL FROM が受け付けられ、続いて、そのホストから送信された受取人 (RCPT TO) アドレスが処理されます。 その後、受取人アドレス(複数の場合、各アドレス) にblacklisted というドメイン名が付加さ れます。つまり、受取人アドレスがuser@domain の場合、user%domain@blacklisted に変換 されます。最後に、変換後の受取人アドレスがルータで処理されます。その場合、ルータテーブル (ルーティングテーブル) にドメインblacklisted に関するルールが定義されていなかったときに は、そのアドレスは拒否され、同時にエラーコードが出力されます。
なお、ルータテーブルには、ドメインblacklisted に関するルールとして、次のルールがデフォル
トで定義されています。
<blacklist-admin*@blacklisted> = postmaster
上のルールにより、ブラックリストに登録されているホストから送信されたメッセージのうち、アド
レスblacklist-admin に送られたメッセージは、そのドメインを問わず、すべてpostmaster (ポス
トマスター) にルートされます。つまり、この種のメッセージは受け取られることになります。この
ルールは、いわば「ホワイトホール」の機能を果たし、このルールを定義しておくことで、ブラック
リストに登録されているユーザーは、ブラックリストに登録されていることについて、ポストマスターに問い合わせることができるようになります。このルール行をルータテーブルから削除すると、ブラッ
クリストに登録されているホストからのメッセージはすべて拒否されます。
SMTP モジュールで、ブラックリストに登録されているホストからのメッセージが処理される際、ルー タテーブルにblacklist-admin@blacklisted の定義行があるかどうかがチェックされます。こ の行(デフォルトまたはユーザー定義) があったときには、そのホストにエラーコードが送信されま す。このエラーコード(レポート) には、blacklist-admin@serverdomain というアドレスに メッセージを送信すると、そのホスト(ブラックリストに登録されているホスト) からのメッセージ も受け付けられるという説明が記載されています。したがって、そのホストのユーザーは再度、 blacklist-admin@serverdomain 宛てにメッセージを送信し、ブラックリストの登録に関してポ ストマスターに問い合わせることができます。
デフォルトでは、エラーレポートにはblacklist-admin@serverdomain というアドレスが挿入さ れますが、このアドレスは変更することができます。
下記は、ブラックリストに登録されているホストとSMTP モジュールとの間のSMTP セッションの例 です。C: はホストからのコマンド、S: はSMTP モジュールからの応答です。
ルータ テーブル | |
---|---|
SMTP プロトコル |
C: MAIL FROM: user@host
S: 250 user@host sender accepted C: RCPT TO: somebody@somehost S: 591 Your host [10.1.1.1] is blacklisted. No mail will be accepted C: RCPT TO: abuse@somehost S: 591 Your host [10.1.1.1] is blacklisted. No mail will be accepted C: RCPT TO: blacklist-admin@somehost S: 591 Your host [10.1.1.1] is blacklisted. No mail will be accepted .... |
ルータ テーブル |
<abuse*@blacklisted> = postmaster |
SMTP プロトコル |
C: MAIL FROM: user@host
S: 250 user@host sender accepted C: RCPT TO: somebody@somehost S: 591 Your host [10.1.1.1] is blacklisted. No mail will be accepted C: RCPT TO: abuse@somehost S: 250 abuse%somehost@blacklisted will leave Internet C: RCPT TO: blacklist-admin@somehost S: 591 Your host is blacklisted. No mail will be accepted .... |
ルータ テーブル |
<blacklist-admin*@blacklisted> = postmaster |
SMTP プロトコル |
C: MAIL FROM: user@host
S: 250 user@host sender accepted C: RCPT TO: somebody@somehost S: 591 Your host [10.1.1.1] is blacklisted. Send your questions to blacklist-admin@mycompany.com. C: RCPT TO: abuse@somehost S: 591 Your host [10.1.1.1] is blacklisted. Send your questions to blacklist-admin@mycompany.com. C: RCPT TO: blacklist-admin@somehost S: 250 blacklist-admin%somehost@blacklisted will leave Internet .... |
SMTP モジュールでは、メッセージのうちアドレスがdomain name-wakeup のメッセージは、直ち に(つまり、最初のルータ呼び出し時、以下同様) 受け付けられます。この種のメッセージは、SMTP モジュールのキューに格納され、ドメイン名(domain name) で示されるドメインのキューのウェ イクアップ要求にしたがって処理されます。
また、SMTP モジュールでは、メッセージのうちアドレスのドメイン名がIP アドレス(つまり、 [xx.yy.zz.tt] の形式) で指定されているメッセージも直ちに受け付けられます。この場合、アド レスのドメイン名がIP アドレスで、そのIP アドレスが角カッコで囲まれていないときには、ルータによって自動的に角カッコが付加されます。また、IP アドレスがローカルドメインのIP アドレスの ときには、ルータにより、そのIP アドレスがドメイン名に変換されます。角カッコの追加とIP アド レスの変換はどちらも、その後のモジュールの呼び出しの前に実行されます。
SMTP モジュールでは、アドレスのドメイン部が接尾辞.smtp で終わっている場合、そのメッセー ジも直ちに受け付けられます。この接尾辞は、接尾辞.viaと同じように処理されます。接尾辞 .smtp は廃止予定です。
SMTP モジュールでは、アドレスのドメイン部が接尾辞.smtpq で終わっている場合、そのメッセー ジも直ちに受け付けられます。この接尾辞は、接尾辞.relayと同じように処理されます。接尾辞 .smtpq は廃止予定です。
さらに、送信先のアドレスのドメイン名にドット(.)が一つ以上ある場合、そのメッセージも直ち に受け付けられます。[Forward to] オプションが選択されているときには、この種のアドレスはす べて、指定されている転送サーバードメインにリルートされます。
また、上記の処理の前に、アドレスに@ 記号があるかどうかチェックされます。ここで、@ 記号が まったくなく、代わりに単一もしくは複数の% 記号があった場合、一番右側の% 記号が@ 記号に変 換されます。
メールサーバーによっては、受信SMTP メールを非標準ポートで受信するように設定されているもの もあります。CommuniGate Pro のSMTP モジュールでは、こういったメールサーバーにメッセージを 送信することもできます。この送信は、電子メールアドレスのドメイン部に、その非標準ポートの番 号を付加することで可能です。または、アドレスをルートして、非標準ポートの番号が付加されるよ うにします。
ルートの方法としては、次の2 種類があります。サーバー管理者は、WebAdmin インターフェイスの[Monitors] セクションでSMTP モジュールのア クティビティを監視できます。[SMTP Monitor] ページは、送信(Sending)、待機(Waiting)、受信 (Receiving) の3 つのフレームに分かれています。
下記は送信フレームの例です。ここにはアクティブの送信SMTP 接続の状態が表示されます。