|
 |
ソフトウェア > Lotus > Lotus Developer Domain > 製品別技術情報 > Lotus Notes/Domino >
LDD Today
スパムを制御する: Lotus Dominoでの詳細なSMTP設定 Part 1
|
|
 |
by
Edmund Stanton Enterprise Software Engineer, IBM Corporation
レベル：中級者
原文の掲載：2004年10月4日
サーバー設定文書、サーバーメール・ルール、およびインバウンド SMTP コマンドと拡張を使用して、スパム・メールを制御する方法を理解しましょう。この記事は、Lotus
Domino のスパム制御手法に関する連続記事のパート 1 です。
進化を続けるテクノロジーの世界では、スパム・メールの量は、ほとんどのメール・システムが制御できないぐらいのスピードで増え続けています。2004
年には、米国の全企業でスパム対策に費やされたコストは約 90 億ドルに達する見込みです。企業は、スパムとみなされるメッセージを識別し隔離するための専用製品を導入してきました。最近の調査では、電子メール全体の
40% 以上がスパムと考えられ、メール・ユーザー一人あたり一日平均 6 通のスパム・メールを受け取るという結果が報告されています。さらに、2007
年までにはスパムの比率が 63% にまで上昇すると予測されています。これらの統計やより詳細な情報は、Spam
Filter Review Web サイトで入手できます。
Lotus は Lotus Domino 4 から、スパム・メールを防止し、Simple Mail Transfer
Protocol (SMTP) メッセージを制限する仕組みに取り組んできました。Lotus Domino
4 では、リレー、インバウンド接続、および送信者のドメインを制御する複数の
Notes.ini パラメータが導入されました。Lotus Domino 5 では、グラフィカル・ユーザー・インターフェース
(GUI) が導入され、Domino のシステム開発者は、サーバー設定文書のフィールドで値を指定できるようになりました。この方法により、Domino
のシステム管理者にとって SMTP の設定が容易になると共に、Notes ユーザーの負担もある程度軽減されました。
Lotus Domino 6 では、メッセージングと DNS ブラックリスト (DNSBL) フィルタリングおよびコンテンツフィルタリングを統合する手法が開発され、大幅な進歩を遂げています。この一連の記事では、サーバーからの不要メールを制限するために
IBM が開発したいくつかのソリューションを紹介し、Lotus Domino 7 でのスパム制御の方法を解説します。パート
1 では、スパム制御に役立つ、サーバー設定文書の設定とサーバーメール・ルールについて説明します。パート
2 では、スパムを制御するサーバー文書の設定と Notes.ini 変数について説明します。また、Lotus
Notes/Domino 7 での機能拡張についても見ていくことにします。この記事は、Domino
システム管理者の経験があり、Lotus Notes と Domino 6 に習熟している読者を想定しています。
ほとんどの Notes ユーザーは、不要なメールを自分で削除したり、フィルタによって排除するよりも、システム管理者にスパム・メールを防止してもらいたい、と考えているようです。スパムを防止する最も効果的な方法は、ユーザーの環境にスパム・メッセージを入り込ませないことです。つまり、SMTP
と Router をそのように設定することが必要になります。どちらの設定も、サーバー設定文書、サーバー文書、および
Domino Server の Notes.ini ファイルで行うことができます。
SMTP タスクは、Domino Server での SMTP listener を制御します。デフォルトでは、SMTP
サービスは再起動後、2分おきに Notes.ini ファイル、サーバー設定文書、およびサーバー文書を自動的にチェックし、変更の有無を調べます。設定の変更を検出すると、変更内容を反映するためにサービスの内部設定を再構築します。
SMTP トラフィックを制御する最も効果的な場所は、サーバー設定文書です。サーバー設定文書には、SMTP
メールにフィルタを設定できるタブがいくつかあります。つまり、スパムの量を減らせることになります。サーバー設定文書の
[ルーター/SMTP] - [制限と制御] - [SMTP インバウンド] タブには、SMTP プロトコルを設定するための
6 つの追加セクションがあります。
インバウンドリレー制御
このセクションでは、図 1 に示すように、Domino がメッセージのリレーを許可または拒否するインターネットドメインを指定できます。Domino
Server でリレー設定を行わないと、サーバーがブラックリスト化され、ブラックリスト・サービスを使用しているドメインにアウトバウンド
SMTP メッセージを送信できなくなります。
「拒否」のフィールドでアスタリスク (*) を指定すると、どの外部インターネットホストまたは
IP アドレスからのメールも、外部インターネットドメインにはリレーされません。また、アスタリスク
(*) を使用して、IP アドレスのサブネットを表すことができます。[次の拡張インターネットドメイン宛てのメッセージのみを許可]
フィールドで指定された IP アドレスまたはホストは、[次の拡張インターネットドメイン宛へのメッセージを拒否]
フィールドよりも優先します。
図 1. SMTP インバウンドリレー制御
[次のインターネットアドレスからのメールのみ、拡張インターネットドメインへの送信を許可]
フィールドで指定された値は、[次のインターネットホストからの拡張インターネットドメイン宛てメールを拒否]
フィールドよりも優先します。Domino の以前のリリースでは、インバウンドリレー制御の「拒否」フィールドのエントリは、競合が発生したときに「許可」フィールドよりも優先されました。
リリース 5 で使用されていたアルゴリズムに戻すには、Notes.ini 変数「SMTPRelayHostsandDomains=値」を設定する必要があります。デフォルトの値は
0 です。この変数の値が 0 の場合は、SMTP インバウンドリレー制御で「許可」と「拒否」のエントリが競合するときに、サーバーは
Domino 5 の規則に従って競合を解決します。
- 0 - SMTP インバウンドリレー制御で「許可」フィールドと「拒否」フィールドのエントリが競合するとき、「許可」フィールドのエントリを優先させます。たとえば、次のように設定すると、ホスト
mail.ibm.com からのメールは、lotus.com 内の宛先を含む任意の宛先へ常にリレーされます。
| フィールド |
エントリ |
| 次の拡張インターネットドメイン宛へのメッセージを拒否 |
lotus.com |
| 次のインターネットアドレスからのメールのみ、拡張インターネットドメインへの送信を許可 |
mail.ibm.com |
- 1 - SMTP インバウンドリレー制御で「許可」フィールドと「拒否」フィールドのエントリが競合するとき、「拒否」フィールドのエントリを優先させます。前の例を使用すると、lotus.com
へのリレーを拒否した場合は、ホスト mail.ibm.com からのメールは、拒否されたドメインへはリレーできません。
インバウンドリレー実施
このセクションでは、リレー制御の詳細設定を見ていきます。図 2 に示すように、SMTP
リレーの詳細設定には次の 3 つのフィールドがあります。
図 2. SMTP インバウンドリレー実施
ホストへ接続のアンチリレーを実行
このフィールドでは、図 1 の SMTP インバウンドリレー制御で設定された内容をサーバーが実施する接続を指定します。次の設定からいずれか
1 つを選択します。
- 外部ホスト (デフォルト): サーバーは、ローカルインターネットドメインの外部から接続してくるホストにのみ、インバウンドリレー制御を適用します。ローカルインターネットドメイン内のホストは、アンチリレーの制限を免除されます。ローカルインターネットドメインは、グローバルドメイン文書
(存在する場合) で定義されるか、ホストサーバーのインターネットドメインとして定義されます。
- すべての接続ホスト: サーバーは、外部インターネットドメインへのメールのリレーを試みるすべてのホストにインバウンドリレー制御を適用します。
- なし: サーバーはインバウンドリレー制御の設定を無視します。すべてのホストからのメールは、常にリレーされます。
アンチリレーチェックからホスト接続の例外
例外リストを作成し、許可されている任意のドメインへのリレーを行うシステムの
IP アドレスまたはホスト名を含めることができます。指定された各例外ホストには、インバウンドリレー制御は実施されません。図
1 のインバウンドリレー制御セクションで指定した制限を免除するホストの IP
アドレスまたはホスト名を入力してください。 IP アドレスを入力するときは、
IP アドレスを角カッコで囲みます。
認証ユーザーの例外
このフィールドでは、サーバーへの接続時にログイン認証情報を提供したユーザーに、インバウンドリレー制御の実施を免除するかどうかを指定します。次のいずれかを選択します。
- 認証されたユーザーにアンチリレーチェックを実行: サーバーは認証済みユーザーにも例外を認めません。認証済みユーザーは、認証されていないユーザーと同じ制限に従います。
- リレーのためすべての認証されたユーザーを許可: 有効な名前とパスワードを使用してログインしたユーザーは、インバウンドリレー制御の適用を免除されます。ローカルインターネットドメイン外部の
ISP アカウントからネットワークに接続する POP3 ユーザーまたは IMAP ユーザーによるリレーを有効にするときに、この設定を使用します。
DNS ブラックリストフィルタ
このセクションでは、図 3 に示す DNS ブラックリストフィルタを使用するかどうかを指定します。有効にすると、Domino
は SMTP 接続要求を受けたときに、接続中のホストが、指定されたサイトのブラックリストに登録されているかどうかをチェックします。接続中のホストがリストで見つかった場合は、Domino
はコンソールメッセージと、Notes Log の [Mail Routing Events] ビューのエントリにイベントをレポートします。コンソールメッセージとログエントリのどちらにも、サーバーの
IP アドレスとホスト名、およびサーバーが登録されていたサイトの名前が含まれています。接続中のホストがいずれか
1 つのブラックリストで見つかると、Domino は設定済みの他のサイトはチェックしません。
図 3. DNS ブラックリストフィルタ
DNS ブラックリストを維持するサービスとしては、誰でも利用できるパブリックなものと、費用を支払って購読するプライベートなものがありますが、どちらを選択してもかまいません。パブリックのブラックリスト・サービスを使用する場合、Domino
はインターネットを介して DNS クエリーを実行します。インターネット・サイトに送信された
DNS クエリーを解決するまでに、非常に長い時間がかかることがあります。インターネット経由で行われる
DNS クエリーのネットワーク待ち時間がパフォーマンスの低下につながる場合は、ゾーン転送を許可するプライベート・サービスを契約するとよいでしょう。ゾーン転送が可能な場合、Domino
は必要な DNS 検索をローカルホストに対して実行できます。ゾーン転送では、サービス・プロバイダーにある
DNS ゾーン・ファイルの内容がローカル・ネットワークの DNS サーバーにコピーされます。
各ブラックリスト・サービスは、それぞれ独自の基準を使用してサーバーをリストに追加します。ブラックリスト・サイトは自動化されたテストとその他の方法を使用して、疑わしいサーバーがスパムを送出しているか、あるいはオープン・リレーとして動作しているかを判断します。より厳しいブラックリスト・サイトでは、自動化されたテストを通過しなかったサーバーに対し、そのサーバーがスパムのソースであるかどうかを検証せずに、すぐにブラックリストに追加します。より緩やかなサイトでは、一定の猶予期間の後、サイトのシステム管理者がサードパーティ・リレーを実行するサーバーを閉じられない場合、またはサーバーが既知のスパマーへのホストとして動作している場合に、そのサーバーをリストに追加します。
DNS ブラックリストに登録されているためにホストからの接続を拒否するときは、エラーメッセージが返されます。このメッセージのテキストを入力できます。デフォルトのエラーメッセージは、ポリシーに基づいて接続が拒否されたことを示します。形式指定子の
%s を使用すると、拒否されたホストの IP アドレスと、ホストが見つかった DNS
ブラックリスト・サイトを表示できます。
たとえば、次のように入力します。
| Your host %s was found in the DNS Blacklist at %s |
|
Domino は接続を拒否するとき、最初の %s をホストの IP アドレスに置き換え、2
番目の %s を DNS ブラックリスト・サイト名に置き換えて、エラーをホストに返します。このため、上の例のようなテキストを入力すると、拒否されたホストは次のようなエラーメッセージを受け取ります。
| Your host 127.0.0.2 was found in the DNS Blacklist at ibmdnsbl.mail-abuse.org |
|
接続中のホストが DNS ブラックリストで見つかったときに行うアクション
次のいずれかの DNS ブラックリスト設定を選択します。
- ログのみ: 接続しているホストをブラックリストで見つけたとき、Domino はホストからメッセージを受け取り、接続しているサーバーのホスト名とIP
アドレス、およびサーバーが登録されていたサイトの名前をサーバーログに記録します。
- メッセージのログとタグ: 接続しているホストをブラックリストで見つけたとき、Domino
はホストからメッセージを受け取り、接続しているサーバーのホスト名と IP アドレス、およびサーバーが登録されていたサイトの名前をサーバーログに記録します。さらに、受け取った各メッセージに、ノートアイテムの
$DNSBLSite を追加します。$DNSBLSite アイテムの値は、ホストが見つかったブラックリスト・サイトになります。システム管理者は、ノートアイテムの
$DNSBLSite を使用して、ブラックリストに登録されているホストから受け取ったメッセージの処理方法を決めることができます。
- メッセージのログと削除: 接続しているホストをブラックリストで見つけたとき、Domino
は接続を拒否し、設定可能なエラーメッセージをホストに返します。
Domino Administrator を使用するか、またはサーバーコンソールで「SHOW STAT
SMTP」コマンドを使用することにより、統計を収集できます。統計を拡張すると、指定した
IP アドレスが設定済みの DNSBL の 1 つで何回見つかったかを知ることができます。拡張された情報を収集するには、サーバーの
Notes.ini ファイルで SMTPExpandDNSBLStats 変数を設定します。
この設定を使用すると、DNS ブラックリストサイトで見つかった各接続ホストごとに、DNS
ブラックリストフィルタ統計が生成されます。
- 0 に設定すると、SMTP サーバーでは、ホストごとの DNS ブラックリストフィルタ統計は生成されません。
- 1 に設定すると、SMTP サーバーで、ホストごとの DNS ブラックリストフィルタ統計が生成されます。この統計は、DNSBL
サイトまたは接続ホストの IP アドレスごとのヒット数の合計を示します。
この Notes.ini 設定は Domino Server に適用されます。この設定がない場合は、SMTP
タスクは、すべてのサイトの DNSBL で見つかった接続ホストの合計数と、設定済みの各サイトの
DNSBL で見つかった接続ホスト数を追跡する統計を維持します。
インバウンド接続制御
このセクションでは、Domino Server へ接続してくるホストまたは IP アドレスを制限します。
Domino では、接続中の任意のホストに対し、DNS での逆引きを行うよう設定できます。この設定により、Domino
は DNS での逆引きを行い、接続中のホストの名前を検証できます。Domino は、接続中のホストの
IP アドレスをホスト名に一致させる PTR レコードを DNS でチェックします。DNS
が利用できない、または PTR レコードが存在しないために、リモートホストの名前を解決できない場合は、Domino
はホストにメールの転送を許可しません。
また、図 4 に示すように、このサーバー上の SMTP サービスへの接続を許可または拒否するホスト名か
IP アドレスを入力できます。ホスト名で入力するときは、完全なホスト名 (特定のサーバーの完全修飾ホスト名)
を指定するか、ホスト名の一部 (ワイルドカードの存在を暗黙的に示す) を指定します。たとえば、[次のホスト名、IP
アドレスの SMTP ホストからの接続のみを許可] フィールドで ibm.com と入力すると、Domino
は *ibm.com で表されるドメイン内のメールホストからの接続だけを受け入れます。つまり、ibm.com
で終わるすべてのホスト名 (たとえば、us.ibm.com や server.ibm.com) を受け入れることになります。Domino
は他のすべての接続要求を拒否します。
図 4. SMTP インバウンド接続制御
インバウンド送信者制御
このセクションでは、インバウンド SMTP メッセージの送信者を制御します。図
5 に示すように、送信者のドメインに DNS での逆引きを有効にすることができます。逆引きを有効にすると、Domino
は送信ホストから受信したMAIL FROM コマンドのドメイン部分に一致する MX、CNAME、または
A レコードを DNS でチェックすることにより、送信者のドメインが存在するか検証します。いずれも一致しない場合、Domino
はそのホストからのインバウンドメールを拒否します。
サーバーがメッセージを許可または拒否する送信元のインターネット・アドレスを指定できます。SMTP
の接続交渉の間に、Domino SMTP listener は、接続中のホストから受信した MAIL
FROM コマンド内のアドレスとこれらのフィールドのエントリを比較します。
図 5. SMTP インバウンド送信者制御
インバウンド受信者制御
このセクションでは、インバウンド SMTP メッセージの受信者を制御します。[Domino
ディレクトリにあるローカルドメイン受信者を確認] フィールドはたいへん役に立つ機能です。このフィールドでは、SMTP
listener が、RCPT TO コマンドで指定された受信者名を Domino ディレクトリのエントリでチェックするかどうかを指定します。有効にすると、SMTP
RCPT TO コマンドで指定されたアドレスのドメイン部分が、設定済みのいずれかのローカルインターネットドメインに一致するとき、SMTP
listener は設定済みのすべてのディレクトリで、指定された受信者が有効なユーザーであるかどうかをチェックします。すべての検索が正しく完了し、一致するユーザーが見つからなかった場合、SMTP
サーバーは、ユーザーが不明であることを示す「550 permanent failure」レスポンスを返します。
| 550 bad_user@yourdomain.com ... No such user |
|
この設定を選択すると、存在しないユーザーに送信されたメッセージ (たとえば、スパム・メッセージや退職した社員宛のメッセージなど)
がMail.box にデッドメールとして蓄積するのを防ぐことができます。ディレクトリの検索が正しく完了しなかった場合は、Domino
はメッセージを受け取ります。これは、ディレクトリが利用できないときに、メッセージを拒否するのを防ぐためです。詳細については、図
6 を参照してください。
図 6. SMTP インバウンド受信者制御
ローカルインターネットドメイン内のインターネットアドレスを指定し、そのアドレスに対して、インターネットからのメールの受信を許可または拒否することができます。また、インターネットからのメールの受信を許可または拒否するアドレスを指定した
Notes グループを作成し、このフィールドでグループ名を指定することもできます。
| メモ: |
上記のいくつかのセクションには、「許可」と「拒否」のフィールドがあります。これらのフィールドは、相互に排他的な関係にあります。「拒否」フィールド内のエントリは、対応する「許可」フィールドを無視します。 |
|
特定のメッセージへのアクションを定義するコンテンツ・フィルタリング・ルールをサーバーに対して作成することができます。指定した条件に一致する新規メールが
Mail.box に到着すると、Domino は指定されたアクションを自動的に実行します。ルールの条件は、メッセージヘッダーの内容またはメッセージ本文の内容に基づきます。条件とアクションのセットを設定することで、スパム・メールや不審なメールをブロックするルールを構築できます。ルールのアクションで明示されている場合を除き、ルールによってメッセージが宛先に配信されない場合でも、送信者または受信者には通知されません。
暗号化されたメッセージ (Notes 暗号化、S/MIME、PGP など) が Mail.box に届いた場合、サーバーメール・ルールは、メッセージ・エンベロープ内の暗号化されていない情報
(送信者、重要度、受信者) に基づいてルールの条件を処理します。しかし、メッセージ本文の暗号化された部分に基づく条件の処理は行いません。ほとんどのルール条件はメッセージ・エンベロープ内の情報に基づいています。ルールがメッセージを処理できないケースでは、サーバーはログには記録しません。
作成したメールルールは、サーバー設定文書の [ルーター/SMTP] - [制限と制御]
- [ルール] タブに保存されます。各サーバーは、起動時に適切なサーバー設定文書からメールルールを取得し、使用する各
Mail.box データベースへのモニターとして登録します。Mail.box が任意のソース
(SMTP プロセス、他のサーバー上の Router、メッセージを投稿したクライアントなど)
から新規メッセージを受信するたびに、サーバーは登録されているメールルールに基づいてさまざまなメッセージフィールドを評価します。各メッセージは、一度だけ評価を受けます。
サーバーメール・ルールを作成する
新規に作成したメール・ルールは、サーバーがそれを再ロードした後で有効になります。Server
タスクがサーバー設定文書を定期的にチェックするときにルールの変更を検出すると、再ロードが自動的に行われます。このチェックは約
5 分おきに行われます。また、Domino コンソールから再ロードを実行することもできます。
サーバーメール・ルールを作成するとき、最初に考慮しなければならない要因がいくつかあります。複数のメールルールを有効にするときは、リスト内でルールを上下に移動することで、ルール間の優先順位を決められます。ルールの先頭には、最も一般的な単語を置くとよいでしょう。一度条件に一致すると、ルール内のそれ以降の条件はチェックされないからです。本当に必要な場合以外は、メッセージの本文は検索しないでください。本文の検索はサーバーの
CPU とメモリに非常に大きな影響を与えるので、Domino Server のパフォーマンスを低下させる原因になることがあります。メールルールの最大数は
100 ですが、Notes.ini 変数によって調整することが可能です。
図 7. [新規ルール] ダイアログボックス
サーバーメール・ルールを作成する最初の手順は、値を調べる (つまり、条件を指定する)
メッセージ項目を決めることです。次の中から選択します。
- 送信者
- 件名
- 本文
- 重要度
- 送信優先度
- 宛先
- CC
- BCC
- 宛先または CC
- 本文または件名
- インターネットドメイン
- サイズ (バイト)
- すべての文書
- 添付ファイル名
- 添付ファイルの数
- フォーム
- 受信者数
- 受信者
調べるメッセージ項目を選択した後は、論理演算子または修飾子を設定する必要があります。次の中から選択します。
- 次を含む時 (文字フィールドの値)
- 次を含まない時 (文字フィールドの値)
- 等しい
- 等しくない
- 次より少ない時 (数値フィールドの値)
- 次より大きい時 (数値フィールドの値)
「And」や「Or」などの条件を追加して、サーバーメール・ルールを変更することもできます。また、オプションとしてサーバーメール・ルールに例外を追加できます。
サーバーメール・ルールを作成する 2 番目の手順は、条件ステートメントに一致するメールを受信したときに実行するアクションを指定することです。選択できるオプションについては、表
A を参照してください。
表 A. サーバーメール・ルールで指定するアクション
| アクション |
説明 |
| ジャーナルする |
Router はメッセージのコピーを設定済みのメールジャーナルデータベースに送信し、メッセージの宛先へのルーティングを続行します。[ルーター/SMTP]
- [詳細] - [ジャーナリング] タブで、ジャーナリングが有効になっている必要があります。 |
| データベースへ移動する |
Router は Mail.box からメッセージを削除し、付随するテキストフィールドで指定されたデータベース
(例: junkmail.nsf) に移動します。指定されたデータベースは、すでに存在する必要があります。メッセージは、宛先へは配信されません。メッセージをジャンクメールデータベースに格納すると、不要または不審な内容をより詳細に調べられます。 |
| メッセージを受け入れない |
Domino はメッセージを拒否しますが、Router は送信エラーレポートを生成しません。メッセージの送信元に応じて、送信者は
NDR (不達レポート) やメッセージが送信されなかったことを示すその他の通知を受け取ることも、受け取らないこともあります。受信
SMTP メッセージを受け取らない場合、Domino は SMTP 永続エラーコードを送信元のサーバーへ返し、メッセージがポリシーに基づいて拒否されたことを示します。SMTP
永続エラー (500 番台のエラー) は、送信者が同じアドレスに再送信を試みると、繰り返して発生するエラータイプです。
送信元のクライアントおよびサーバーの設定に応じて、メッセージの送信者は送信エラーレポートを受け取ることがあります。Notes
配信を介して受信したメッセージについては、Domino はメッセージがメールルールに違反することを示す送信エラーレポートを返します。Notes
Client によって投稿されたメッセージについては、メッセージがメールルールに違反することを示すエラーが送信元のクライアントに表示されます。 |
| メッセージを送信しない |
Domino はメッセージを受け入れますが、宛先には送信せず、指定されている次のオプションに従ってメッセージを処理します。
- 即時削除: 送信者と受信者には通知せずに、Mail.box からメッセージを削除します。
- NDR を送信: 不達レポートを生成し、送信元に返します。Notes Client から送信された
MIME メッセージまたは Notes リッチテキスト形式のメッセージの場合は、別に送信エラーレポートが送信されます。
|
| ルーティング状態の変更 |
Domino はメッセージを受け入れますが、配信しません。配信する代わりに、メッセージの
RoutingState アイテムの値を HOLD に変更することにより、メッセージを保留状態にします。メッセージのルーティング状態をこのように変更すると、Router
はメッセージを Mail.box に無期限に保持し、メッセージの削除や保留の解除といった管理者のアクションを待ちます。 |
Lotus Domino は、一般的ないくつかの ESMTP (Extended Simple Mail Transfer
Protocol) コマンドと拡張をサポートします。これらのほとんどは、サーバー設定文書の
[ルーター/SMTP] - [制限と制御] - [詳細] - [コマンドと拡張] タブで設定できます。各
ESMTP コマンドは、それぞれ異なる RFC (Request For Comment) でサポートされています。SMTP
listener タスクによってサポートされているインバウンド ESMTP コマンドと拡張については、表
B を参照してください。
表 B. インバウンド SMTP コマンドと拡張
| サイズ拡張 (RFC 1427) |
- 有効 (デフォルト) - Domino は接続中のホストに最大メッセージサイズを宣言し、転送を受け入れる前に、送信元ホストによるメッセージサイズの推定値をチェックします。送信元によって、転送するメッセージが最大サイズよりも大きいことが示された場合は、Domino
はメッセージを受け入れないことを示すエラーを返します。
- 無効 - Domino はメッセージの最大サイズを通知せず、転送前にインバウンドメッセージのサイズをチェックしません。
|
| Pipelining 拡張 (RFC 1854) |
- 有効 (デフォルト) - 同じネットワークパケットで複数の SMTP コマンドの受け入れを可能にすることにより、パフォーマンスを向上させます。
- 無効 - 1 つのパケットで複数の SMTP コマンドを受け入れません。
|
| DSN 拡張 (RFC 3461) |
- 有効 - メッセージの失敗、遅延、配信、およびリレーに関する送信状態レポートを送信元に返すことを求める要求をサポートします。低優先度メールの配信時間まで保留されていたメッセージについては、要求に応じて遅延レポートが
SMTP メッセージの送信元へ送信されます。
- 無効 (デフォルト) - SMTP メッセージについては、送信状態通知は返しません。ただし、失敗時の
DSN は返されます。
|
| 8 ビット MIME 拡張 (RFC 1652) |
- 有効 - エンコードされていない多言語文字の受信を許可し、8 ビットメッセージをそのまま受け入れます。
- 無効 (デフォルト) - 8 ビット文字を含むインバウンドメッセージについては、7
ビットの ASCII エンコーディングを使用して送信するよう要求します。
|
| HELP コマンド |
- 有効 (デフォルト) - Help コマンドへのレスポンスとして、サポートされているコマンドの一覧が表示されます。
- 無効 - Help コマンドは無視されます。
|
| VRFY コマンド (RFC 821 セクション 3.3) |
- 有効 - Domino は、ユーザー名を検証するインバウンド要求を受け入れます。
- 無効 (デフォルト) - Domino は、ユーザー名を検証する要求を拒否します。
|
| EXPN コマンド (RFC 821 セクション 3.3) |
- 有効 - 個々の受信者名を表示するために、メーリングリストまたはグループが展開されます。
- 無効 (デフォルト) - リストおよびグループは展開されません。
|
| ETRN コマンド (RFC 1985) |
- 有効 - 他の SMTP ホストからのインバウンドの「pull」要求を受け入れ、呼び出し側サーバーへメッセージを転送します。ETRN
のサポートを有効にすると、リモート SMTP ホストは、Domino Server へのメッセージの送信と同時にメッセージの保留を要求できるので、帯域幅リソースをより有効に活用できます。
- 無効 (デフォルト) - 他の SMTP ホストからのインバウンドの「pull」要求は受け入れません。
|
| TCP/IP ポート上の SSL 接続 (RFC 2487 および RFC 3207) |
- 有効 - STARTTLS コマンドをサポートし、SMTP TCP/IP ポート経由で暗号化された
SSL チャネルの作成を可能にします。
- 必要 - STARTTLS コマンドを発行するホストだけから TCP/IP ポートでのインバウンド
SMTP 接続を受け入れます。
- 無効 (デフォルト) - SMTP TCP/IP ポートでのセキュア SSL 接続を許可しません。
リモート・サーバーからの STARTTLS コマンドを受け入れた後、Domino はサーバーの
SSL ポートの設定を使用して、セッションの認証を管理します。SMTP AUTH コマンドを使用するリモート・ホストを認証するには、SSL
ポートで名前とパスワードによる認証を有効にする必要があります。サーバーの
SSL ポートを設定する方法については、パート 2 の記事で説明します。 |
この記事では、インバウンドリレー制御、ブラックリスト、 SMTP コマンドと拡張など、サーバー設定文書における
Domino の SMTP 設定について解説してきました。また、サーバーメール・ルールとメールジャーナル、スパムを排除するための別の
2 つの方法についても説明しました。パート 2 では、SMTP に関係するサーバー文書の設定と
Notes.ini 変数について解説します。また、Lotus Notes/Domino 7 での新機能についても説明します。
著者について（原文のまま）
Edmund "Ted" Stanton is an Enterprise Software Engineer for Lotus
Software in North America. He has been working with Lotus Domino and extended
products since 2000. He worked in System Integration for Towers Perrin
before joining IBM in 2002. Ted holds a double degree in Computer Science
and Mathematics as well as a minor in Business from Virginia Wesleyan College.
His primary area of expertise includes mail routing protocols and instant
messaging. He has certifications in Domino Document Manager (Domino.doc),
Lotus Instant Messaging (Sametime), Lotus Team Workplace (QuickPlace),
Domino Administrator, Domino Designer, WebSphere server, and Windows 2000.
He is a Primary Area Expert for Lotus Domino Shared Mail and has written
extensively on this topic. He co-authored the IBM Redbook, Lotus Domino 6.5.1 and Extended Products Integration Guide, SG24-6357-00. Ted is also the author of the article, "Integrating voice, email, and fax in a single unified messaging store" on developerWorks: Lotus. Ted is a member of the Lotus Notes/Domino
7 enablement team for Beta testing and documenting new product features.
He is also an active member of a designated focus group involving IBM Business
Partners to identify skills and knowledge required to successfully perform
the role of the Lotus Workplace Messaging System Administrator.
|
|
|
|
|
