配信ステータス通知メッセージを制御する

配信ステータス通知、すなわちステータス通知は、MTA が差出人に送信する電子メールステータスメッセージで、ポストマスターに送信することもできます。Messaging Server では、通知メッセージの内容や言語をカスタマイズすることができます。また、配信ステータス (たとえば、FAILED、BOUNCED、TIMEDOUT など) の種類ごとに異なるメッセージを作成することもできます。さらに、特定のチャネルから送信されたメッセージに関するステータス通知を作成することもできます。

デフォルトでは、ステータス通知は msg_svr_base/config/locale/C ディレクトリに保存されます (msg_svr_base/config/imta_tailor ファイルの IMTA_LANG 設定で指定)。次のような種類があります。

return_bounced.txt、return_delivered.txt、return_header.opt、return_timedout.txt、return_deferred.txt、return_failed.txt、return_prefix.txt、return_delayed.txt、return_forwarded.txt、return_suffix.txt

*.txt ファイルのメッセージテキストは、1 行につき 78 文字以内である必要があります。これらのファイルには直接変更を加えないてください。これらのファイルは、Messaging Server の現在のバージョンのアップグレード時に上書きされます。ファイルを変更して独自の通知メッセージテンプレートファイル (return_*.txt) として使用する場合は、新しいディレクトリにファイルをコピーし、そちらを編集してください。次に imta_tailor ファイルに IMTA_LANG オプションを設定し、このテンプレートがある新しいディレクトリを指定します。通知ファイルのセットを複数作成する場合は (言語別のセットを作成する場合など)、NOTIFICATION_LANGUAGE マッピングテーブルを設定する必要があります。

ステータス通知を作成および変更するには

通知メッセージは、return_prefix.txt、return_ActionStatus.txt、return_suffix.txt の 3 ファイルのセットで構成されています。

通知をカスタマイズまたはローカライズするには、ロケールまたはカスタマイズ、あるいはその両方のそれぞれに return_*.txt ファイルの全セットを作成し、それを別々のディレクトリに保存します。たとえば、あるディレクトリにはフランス語の通知ファイル、もう 1 つのディレクトリにはスペイン語の通知ファイルを保存し、3 つ目のディレクトリには特殊な不特定多数宛メールに対する通知を保存することができます。

このリリースには、フランス語、ドイツ語、およびスペイン語のサンプルファイルが含まれています。これらのファイルは、ユーザーのそれぞれのニーズに合わせて変更することができます。

日本語などの 2 バイト文字の場合は、日本語でテキストを作成してから、そのテキストを ASCII 形式に変換してから、% 文字がないかどうかをチェックしてください。不測の % 文字が存在する場合は、%% で置き換えてください。

ステータス通知メッセージの形式と構造は次のとおりです。

1. return_prefix.txt には、該当するヘッダーテキストと本文の導入部分が含まれます。米国英語のロケールのデフォルトは以下のとおりです。

   Content-type: text/plain; charset=us-asci Content-language: EN-US This report relates to a message you sent with the following header fields: %H

   US-ASCII 以外のステータス通知メッセージの場合は、charset パラメータと Content-Language ヘッダーを適切な値に変更する必要があります (たとえばフランス語用のファイルでは ISO-8859-1 と fr)。%H は、表 10–9 で定義されているヘッダー置換シーケンスです。

2. return_<ActionStatus>.txt にはステータス専用のテキストが含まれています。ActionStatus は、メッセージの MTA ステータスタイプです。たとえば、デフォルトでは return_failed.txt のテキストは次のようになります。

   Your message cannot be delivered to the following recipients:%R

   return_bounced.txt のデフォルトのテキストは次のようになります。

   Your message is being returned. It was forced to return bythe postmaster.

   The recipient list for this message was:%R

3. return_suffix.txt には結びのテキストが含まれます。デフォルトでは、このファイルは空白です。

配信ステータス通知メッセージをカスタマイズおよびローカライズするには

配信ステータス通知メッセージをローカライズして、言語別に異なるユーザーにメッセージを返すことができます。たとえば、フランス語を使用しているユーザーにフランス語の通知を返すことができます。

ステータス通知メッセージのローカライズまたはカスタマイズは、次の 2 つの手順で行います。

1. ローカライズまたはカスタマイズされた return_*.txt メッセージファイルのセットを作成し、別々のディレクトリに保存します。詳細は、「ステータス通知を作成および変更するには」を参照してください。

2. NOTIFICATION_LANGUAGE マッピングテーブルを設定します。

NOTIFICATION_LANGUAGE マッピングテーブル (msg_svr_base/config/mappings) では、送信元メッセージ (通知が送信される原因であるメッセージ) の属性 (言語、国、ドメイン、アドレスなど) に応じて使用される、ローカライズまたはカスタマイズされた通知メッセージファイルのセットを指定します。

元の差出人のメッセージがパースされ、ステータス通知の種類、ソースチャネル、優先言語、返信アドレス、および 1 人目の受取人が決定されます。テーブルの構築方法によって異なりますが、通知ファイルのセットは 1 つ以上の属性によって選択されます。

NOTIFICATION_LANGUAGE マッピングテーブルの形式は次のとおりです。サンプルのエントリ行は、紙面の都合で折り返されています。実際のエントリは、1 行で記述する必要があります。

NOTIFICATION_LANGUAGE

 dsn-type-list|source-channel|preferred-language|return-address \
|first-recipient $Idirectory-spec

• dsn-type-list は、配信ステータス通知の種類のコンマ区切りリストです。複数の種類を指定する場合はコンマで区切ります。スペースでは区切りません。スペースを使用すると、マッピングテーブルエントリのパターンが終了します。次のような種類があります。

  • failed - 一般的な、永続的配信不能を示すメッセージ (「そのようなユーザーはありません」など)。return_failed.txt ファイルが使用されます。

  • bounced - 手動で「バウンス」した場合に使用される通知メッセージ。ポストマスターを実行します。return_bounced.txt ファイルが使用されます。

  • timedout - MTA が、指定された配信期間内にメッセージを配信できなかったことを示します。メッセージは送り返されます。return_timedout.txt ファイルが使用されます。

  • delayed - MTA が、メッセージを配信できなかったが、引き続き配信を試みていることを示します。return_delayed.txt ファイルが使用されます。

  • deferred - 「delayed」に類似した配信不能通知。ただし、MTA が配信試行を続行する期間は表示されません。return_deferred.txt ファイルが使用されます。

  • forwarded - このメッセージに対して配信確認が要求されていたが、このメッセージは配信確認がサポートされていないシステムに転送されたことを示します。return_forwarded.txt ファイルが使用されます。

• source-channel は通知メッセージを生成するチャネル、つまり現在メッセージがキューに入っているチャネルです。たとえば、メッセージストアの配信キューの ims-ms、送信用 SMTP キューの tcp_local などがあります。

• preferred-language は、処理中のメッセージ (通知を生成中のメッセージ) で使用される言語です。この情報のソースは、第 1 に accept_language フィールドです。このフィールドにない場合は、Preferred-language: ヘッダーフィールドと X-Accept-Language: ヘッダーフィールドが使用されます。標準の言語コードの値のリストは、msg_svr_base/config/languages.txt ファイルを参照してください。

  このフィールドには、空の場合を除き、メッセージの発信者が Preferred-language: ヘッダー行または X-Accept-language: ヘッダー行に指定した内容が入ります。このため、意味のない文字が使用されることもあります。

• return-address は、送信元メッセージのエンベロープ From: アドレスです。これは、通知メッセージの送信先となるエンベロープアドレスであり、使用言語の手掛かりになることがあります。

• first-recipient は、元のメッセージの宛先のエンベロープ To: アドレス (メッセージが複数の受取人に届かない場合は 1 人目の受取人アドレス) です。たとえば、「dan@siroe.com へのメッセージは配信されませんでした」という通知では、報告を受けるエンベロープ To: アドレスは dan@siroe.com です。

• directory-spec は、マッピングテーブルのプローブに一致する場合に使用する return_*.txt ファイルを含むディレクトリです。$I の後ろにディレクトリの指定が続きます。

  たとえば、フランス語の通知ファイル (return_*.txt) が /lc_messages/table/notify_french/ ディレクトリにあり、スペイン語の通知ファイル (return_*.txt) が /lc_messages/table/notify_spanish/ ディレクトリにあるサイトでは、次のようなテーブルを使用できます。各エントリは 1 つまたは複数のスペースで始まり、エントリ間には空白行はありません。

NOTIFICATION_LANGUAGE
 
! 優先言語: 指定されたヘッダー値
!
    *|*|fr|*|*     $I/lc_messages/table/notify_french/
    *|*|es|*|*     $IIMTA_TABLE/notify_spanish/
    *|*|en|*|*     $I/imta/lang/
!
! 優先言語の値が指定されていない場合は、ドメイン名の国別コードに
! 基づいて通知を選択します。例: PF= フランス領ポリネシア、BO= ボリビア
!
    *|*|*|*.fr|*   $I/imta/table/notify_french/
    *|*|*|*.fx|*   $I/imta/table/notify_french/
    *|*|*|*.pf|*   $I/imta/table/notify_french/
    *|*|*|*.tf|*   $I/imta/table/notify_french/
    *|*|*|*.ar|*   $I/imta/table/notify_spanish/
    *|*|*|*.bo|*   $I/imta/table/notify_spanish/
    *|*|*|*.cl|*   $I/imta/table/notify_spanish/
    *|*|*|*.co|*   $I/imta/table/notify_spanish/
    *|*|*|*.cr|*   $I/imta/table/notify_spanish/
    *|*|*|*.cu|*   $I/imta/table/notify_spanish/
    *|*|*|*.ec|*   $I/imta/table/notify_spanish/
    *|*|*|*.es|*   $I/imta/table/notify_spanish/
    *|*|*|*.gp|*   $I/imta/table/notify_spanish/
    *|*|*|*.gt|*   $I/imta/table/notify_spanish/
    *|*|*|*.gy|*   $I/imta/table/notify_spanish/
    *|*|*|*.mx|*   $I/imta/table/notify_spanish/
    *|*|*|*.ni|*   $I/imta/table/notify_spanish/
    *|*|*|*.pa|*   $I/imta/table/notify_spanish/
    *|*|*|*.ve|*   $I/imta/table/notify_spanish/
                  

デフォルトの mappings.locale ファイルはインストールによって組み込まれます。これは、通知言語マッピングを有効にするために mappings ファイルに組み込まれます。通知言語マッピングを無効にするには、インクルード行を以下のようにコメントアウトします。

! <IMTA_TABLE:mappings.locale

ファイル内のコメントを読み、必要に応じて変更してください。

生成された通知の国際化

配信ステータス通知および MDN (message disposition notification) の両方に、2 つのオプションファイルが使用できます。これらは、生成された通知をより柔軟に国際化するためのものです。次の 2 種類があります。

IMTA_LANG:return_option.dat (DSN)IMTA_LANG:disposition_option.dat (MDN)

これらのファイルに使用できるオプションを、表 10–10 に示します。

ステータス通知メッセージの追加機能

ステータス通知メッセージの設定に必要な手順は、前の節で説明したとおりです。ここでは、追加機能について説明します。

サイズの大きいメッセージの内容が戻るのをブロックするには

通常、メッセージがバウンスまたはブロックされる場合は、差出人とローカルドメインのポストマスターに通知メッセージでメッセージの内容が戻されます。サイズの大きいメッセージが何通もそのまま戻されると、リソースに負担がかかります。一定のサイズを超えるメッセージの内容が戻るのをブロックするには、MTA オプションファイルで CONTENT_RETURN_BLOCK_LIMIT オプションを設定します。

ステータス通知メッセージのヘッダーから US-ASCII 以外の文字を削除するには

インターネットメッセージヘッダーの本来の形式では US-ASCII 以外の文字は使用できません。メッセージヘッダーに使用されている US-ASCII 以外の文字は「MIME ヘッダーエンコーディング」でエンコードされたものです。MIME ヘッダーエンコーディングについては RFC 2047 に記述されています。したがって、電子メールメッセージの「件名」行は、実際には次のように表されています。

Subject: =?big5?Q?=A4j=AB=AC=A8=B1=AD=B1=B0=D3=F5=A5X=AF=B2?=

電子メールクライアントは、ヘッダーを表示する際にエンコーディングを削除する必要があります。

%H テンプレートは通知メッセージの本文にヘッダーをコピーするので、通常はエンコードされたヘッダーが表示されます。ただし、Messaging Server では、件名の文字セット (この場合は big5) が return_prefix.txt の Content-Type ヘッダー文字セットパラメータにある文字セットと一致する場合は、エンコーディングが削除されます。一致しない場合は、Messaging Server のエンコーディングはそのまま残ります。

通知メッセージの配信間隔を設定するには

キーワード: notices、nonurgentnotices、normalnotices、urgentnotices

配信不能メッセージは、指定したチャネルキューに一定期間保存したあとで差出人に戻されます。また、Messaging Server が配信を試みている期間に、一連のステータスメッセージや警告メッセージを差出人に戻すこともできます。その期間とメッセージの配信間隔は、notices、nonurgentnotices、normalnotices、urgentnotices のキーワードで指定できます。次に例を示します。

notices 1 2 3

この例では、すべてのメッセージについて、一時的な配信不能のステータス通知メッセージが 1 日目と 2 日目に送信されます。メッセージが 3 日たってもまだ配信されない場合は、差出人に返されます。

urgentnotices 2,4,6,8

この例では、優先度の高いメッセージについて、一時的な配信不能の通知が 2、4、6 日目に送信されます。メッセージが 8 日たってもまだ配信されない場合は、差出人に返されます。

MTA オプションファイルの RETURN_UNITS オプションでは、時間 (1) または日 (0) で単位を指定することができます。デフォルトは日 (0) です。RETURN_UNITS=1 に設定した場合は、通知を 1 時間おきに受信するには、返送ジョブが 1 時間おきに実行されるようにスケジュールする必要もあります。返送ジョブが 1 時間ごとに実行されると、このジョブによって mail.log* ファイルも 1 時間ごとにロールオーバーされます。mail.log ファイルが 1 時間ごとにロールオーバーされないようにするには、imta.tailor ファイルの IMTA_RETURN_SPLIT_PERIOD テイラーファイルオプションを 24 に設定します。返送ジョブのスケジュールは、local.schedule.return_job configutil パラメータで制御します。

notices キーワードが指定されていない場合は、デフォルトでは、ローカルの l チャネル用の notices 設定が使用されます。ローカルチャネル用の設定がない場合は、デフォルトでは、notices 3, 6, 9, 12 が使用されます。

ステータス通知メッセージに代替アドレスを含めるには

キーワード: includefinal、suppressfinal、useintermediate

MTA が通知メッセージ (バウンスメッセージ、配信確認メッセージなど) を生成するとき、元の形式の受取人アドレスと、変更された最終的な形式の受取人アドレスの両方が MTA に提示される場合があります。元の形式の方が通知メッセージの受取人 (通知メッセージの場合は元のメッセージの差出人) によって認識される可能性が高いため、MTA は、常に元の形式を通知メッセージに含めます。

includefinal および suppressfinal チャネルキーワードは、MTA が最終的な形式のアドレスを含めるかどうかを制御するためのものです。外部に対して内部のメールボックス名を隠しているサイトでは、最終的な形式のアドレスを含めないことをお勧めします。このようなサイトでは、元の形式の外部用アドレスのみをステータス通知メッセージに含めるほうが適しています。デフォルトは includefinal であり、最終的な形式の受取人アドレスが含められます。suppressfinal を使用すると、元の形式のアドレスが存在する場合、MTA は最終的な形式のアドレスをステータス通知メッセージに含めません。

useintermediate キーワードでは、リストの展開後、ユーザーメールボックス名を生成するまでの間に作成された中間形式のアドレスを使用します。この情報を入手できない場合は、最終形式が使用されます。

ポストマスターへのステータス通知メッセージを送信、ブロック、指定するには

デフォルトでは、Errors-to: ヘッダー行やエンベロープ From: アドレスが空白であるためにエラーが返されるか、警告をまったく送信できない場合を除いて、障害および警告のステータス通知メッセージのコピーがポストマスターに送信されます。ポストマスターへの通知メッセージの配信の詳細については、以後の節および表 10–11 で説明する多数のチャネルキーワードで制御できます。

返送された配信不能メッセージ

キーワード: sendpost、nosendpost、copysendpost、errsendpost

長期間にわたってサービスが支障をきたしている場合や、アドレスが不正確な場合は、チャネルプログラムがメッセージを配信できないことがあります。このような場合、MTA チャネルプログラムは、配信不能の理由を説明する文と一緒にメッセージを差出人に返送します。さらに、配信できないメッセージのコピーをすべてローカルポストマスターに送るように設定することも可能です。これはメッセージ配信障害を監視するのに便利ですが、ポストマスターにとっては大量のメールを処理しなければならないことにもなります (表 10–11 を参照)。

警告メッセージ

キーワード: warnpost、nowarnpost、copywarnpost、errwarnpost

メッセージの返送に加えて、MTA では、配信できないメッセージに関する詳細な情報を記載した警告を送信することができます。通常、この警告メッセージは notices チャネルキーワードが指定するタイムアウトに基づいて送られますが、配信試行に失敗したときに送られることもあります。警告には、問題点の説明と配信試行を継続する時間枠が記載されます。また、多くの場合、該当するメッセージのヘッダーと最初の数行も含まれます。

さらに、警告メッセージのコピーをすべてローカルポストマスターに送るように設定することも可能です。これはメッセージ配信障害を監視するのに便利ですが、ポストマスターにとっては大量のメールを処理しなければならないことにもなります。warnpost、copywarnpost、errwarnpost、nowarnpost キーワードは、警告メッセージを postmaster に送ることを制御するために使用されます (表 10–11 を参照)。

空白のエンベロープ返信アドレス

キーワード: returnenvelope

returnenvelope キーワードは 1 つの整数値をとり、これはビットフラグのセットとして解釈されます。ビット 0 (値 = 1) は、MTA によって生成された返送通知のエンベロープアドレスを空白にするか、あるいはローカルポストマスターのアドレスを入れるかを制御します。このビットを設定した場合は、ローカルポストマスターのアドレスを使用することになり、ビットをクリアすると空白アドレスを使用することになります。

RFC 1123 では空白アドレスの使用が義務付けられています。ただし、一部のシステムでは空白エンべロープ From: アドレスを適切に処理できないため、このオプションが必要な場合があります。

ビット 1 (値 = 2) は、MTA がすべての空白エンベロープアドレスをローカルポストマスターのアドレスに置き換えるかどうかを制御します。これは、RFC 821、RFC 822、あるいは RFC 1123 に準拠しないシステムを扱うために使用されます。

ビット 2 (値 = 4) は構文的に不正な返信アドレスを禁止します。

ビット 3 (値 = 8) は mailfromdnsverify キーワードと同じです。

ポストマスター返送メッセージの内容

キーワード: postheadonly、postheadbody

チャネルプログラムまたは定期的なメッセージ返送ジョブがメッセージをポストマスターと差出人の両方に返送する場合は、ポストマスターへのコピーには、メッセージ全体を含めることも、ヘッダーだけを含めることもできます。ポストマスターへのコピーをヘッダーに限定することで、ユーザーメールのプライバシーのレベルを高めることができます。ただし、ポストマスターやシステム管理者は一般に root システム権限を使用してメッセージの内容を読むことができるため、このキーワードを使用してもメッセージのセキュリティーを完全に保証することにはなりません (表 10–11 を参照)。

チャネルポストマスターアドレスの設定

キーワード: aliaspostmaster、returnaddress、noreturnaddress、returnpersonal、noreturnpersonal

デフォルトでは、MTA がバウンスメッセージやステータス通知メッセージを作成する際に使用されるポストマスターの返信アドレスは、postmaster@local-host です。この local-host の部分は、ローカルホストの正式な名前 (ローカルチャネルの名前) で、ポストマスターの個人名は「MTA e-Mail Interconnect」です。この場合、ポストマスターのアドレスの選択には注意してください。不正なアドレスを選択すると、高速のメッセージループが発生し、非常に多数のエラーメッセージが返されることになります。

RETURN_ADDRESS オプションと RETURN_PERSONAL オプションを使用すると、MTA システムでポストマスターのアドレスと個人名をデフォルトに設定できます。また、チャネルごとに制御する必要がある場合は、returnaddress および returnpersonal の各チャネルキーワードを使用できます。returnaddress と returnpersonal は、それぞれポストマスターのアドレスと個人名を指定する引数をとります。noreturnaddress と noreturnpersonal はデフォルトであり、デフォルト値が使用されます。このようなオプションが設定されていない場合は、RETURN_ADDRESS オプションと RETURN_PERSONAL オプションでデフォルトを設定します。これらのオプションが設定されていない場合は、通常のデフォルト値が使用されます。

aliaspostmaster キーワードがチャネルに指定されている場合は、正式なチャネル名におけるユーザー名 postmaster (大文字のみ、小文字のみ、またはその両方) 宛のすべてのメッセージは、postmaster@local-host にリダイレクトされます。local-host には、正式なローカルホスト名 (ローカルチャネルの名前) が入ります。インターネット標準規格では、メールを受け付ける DNS のすべてのドメインに、メールを受信する有効なポストマスターアカウントを設定する必要があります。このため、各ドメインに個別のポストマスターアカウントを設定するのではなく、ポストマスターの責務を一元化する場合はこのキーワードが便利です。つまり、returnaddress は、MTA がポストマスターからの通知メッセージを生成する際に使用するポストマスターの返信アドレスを制御し、aliaspostmaster は、MTA がポストマスター宛のメッセージを処理する方法を制御します。