test

Sun Java System Messaging Server 6 2005Q4 管理ガイド

一般的な MTA の問題と解決策

この節では、MTA の設定と操作で一般的に起こりやすい問題と解決策を示します。

TLS の問題

SMTP ダイアログの間に、STARTTLS コマンドが次のエラーを返した場合で、

454 4.7.1 TLS library initialization failure

かつ証明書をインストール済みで pop/imap アクセスを試みている場合は、次のことを確認します。

保護を変更し、証明書をインストールしたら、次のコマンドを実行します。


stop-msg dispatcher 
start-msg dispatcher

再起動でも問題は解決するはずですが、完全にシャットダウンして証明書をインストールしてから操作をやり直すことをお勧めします。

設定ファイルまたは MTA データベースに対する変更が有効にならない

設定、マッピング、変換、セキュリティー、オプション、またはエイリアスファイルに対する変更が有効になっていない場合は、次の手順を実行したかどうかをチェックします。

  1. 設定の再コンパイル (imsimta cnbuild を実行)。

  2. 該当するプロセス (imsimta restart dispatcher など) の再起動。

  3. クライアント接続の再確立。

MTA が、メールを送信するが受信しない

ほとんどの MTA チャネルは、スレーブまたはチャネルプログラムに依存して、着信メッセージを受信します。MTA がサポートしているいくつかの転送プロトコル (TCP/IP や UUCP など) の場合、転送プロトコルが標準サーバーではなく MTA スレーブプログラムをアクティブにしていることを確認する必要があります。ネイティブの sendmail SMTP サーバーから MTA の SMTP サーバーへの置換は、Messaging Server のインストールの際に実行されます。詳細は、『Sun Java Enterprise System 2005Q4 インストールガイド』を参照してください。

マルチスレッド SMTP サーバーの場合、SMTP サーバーの起動はディスパッチャーによって制御されます。ディスパッチャーが SMTP サービスより大きいか等しい MIN_PROCS 値を使用するように構成されている場合は、少なくとも 1 つの SMTP サーバープロセスが常に実行されている必要があります (SMTP サービスの MAX_PROCS 値によっては複数の場合もある)。imsimta process コマンドを使用して、SMTP サーバープロセスがあるかどうかをチェックすることもできます。詳細については、『Sun Java System Messaging Server 6 2005Q4 Administration Reference』の「imsimta process」を参照してください。

ディスパッチャー (SMTP サーバー) が起動しない

ディスパッチャーが起動しない場合は、まず dispatcher.log-* に関連するエラーメッセージがあるかどうか確認します。/tmp/.SUNWmsgsr.dispatcher.socket ファイルの作成やアクセスに関する問題がログで示されている場合は、/tmp 保護が 1777 に設定されていることを確認します。これは、権限で次のように表示されます。


drwxrwxrwt 8 root sys 734 Sep 17 12:14 tmp/
.

また、.SUNWmsgsr.dispatcher.socket ファイルの ls -l を実行して、適切な所有権を確認します。たとえば、このファイルが root によって作成された場合は、inetmail でアクセスすることはできません。

Do not remove the ..SUNWmsgsr.dispatcher.file を削除しないでください。また、存在しない場合は作成しないでください。このファイルはディスパッチャーによって作成されます。保護が 1777 に設定されていないと、ディスパッチャーはソケットファイルを作成およびアクセスできないため、起動または再起動しません。また、Messaging Server とは関連のないほかの問題が発生している可能性もあります。

着信 SMTP 接続時のタイムアウト

着信 SMTP 接続時のタイムアウトは、システムリソースやその割り当てに関連していることがよくあります。次の方法を使用して、着信 SMTP 接続時のタイムアウトの原因を識別することができます。

Procedure着信 SMTP 接続時のタイムアウトの原因を識別するには

手順

  1. 同時に許可する着信 SMTP 接続の数をチェックします。これは SMTP サービスのディスパッチャー設定である MAX_PROCS および MAX_CONNS によって制御され、許可できる同時接続数は MAX_PROCS*MAX_CONNS です。接続数が少なすぎる場合、システムリソースに余裕があれば、この数を増やすことを考慮してください。

  2. 使用できるもう 1 つの方法は、TELNET セッションを開くことです。

    次の例では、ユーザーは 127.0.0.1 ポート 25 に接続しています。接続すると、220 バナーが返されます。次に例を示します。


    telnet 127.0.0.1 25
Trying 127.0.0.1...
Connected to 127.0.0.1.
Escape character is ’^]’.
220 budgie.sesta.com --Server ESMTP (Sun Java System Messaging Server 6.1 
(built May  7 2001))

    接続して 220 バナーを受信しても、その他のコマンド (ehlo や mail from など) が応答を不正としない場合は、imsimta test -rewrite を実行して設定が正しいことを確認する必要があります。

  3. 220 バナーの応答が遅い場合や、SMTP サーバーで pstack コマンドを実行すると次の iii_res* 関数 (名前解決検索が実行されていることを示す) が表示される場合があります。


    febe2c04 iii_res_send (fb7f4564, 28, fb7f4de0, 400, fb7f458c, fb7f4564) + 
42c febdfdcc iii_res_query (0, fb7f4564, c, fb7f4de0, 400, 7f) + 254

    このような場合は、localhost/127.0.0.1 のような一般的なペアでも、ホストが名前解決のリバース検索を行う必要があることも考えられます。このようなパフォーマンスの低下を回避するには、/etc/nsswitch.conf ファイルでのホストの検索順を並べ替えてください。このためには、/etc/nsswitch.conf ファイルの次の行を変更します。


    hosts: dns nis [NOTFOUND=return] files

    変更後は次のようになります。


    hosts: files dns nis [NOTFOUND=return]

    /etc/nsswitch.conf ファイルでこのような変更を行うと、複数の SMTP サーバーで不要な検索を実行する必要がなく、少数の SMTP サーバーでメッセージを処理するため、パフォーマンスを向上させることができます。

  4. 着信 SMTP over TCP/IP メールを処理しているチャネル (通常は、tcp_local と tcp_intranet) 上に slave_debug キーワードを設定することもできます。これを実行したあと、最新の tcp_local_slave.log-uniqueid ファイルを見直して、タイムアウトになったメッセージの特性を識別します。たとえば、受取人の数が多すぎる着信メッセージがタイムアウトになった場合は、チャネル上で expandlimit キーワードを使用することを考慮してください。

    システムが過負荷になっていて拡張されすぎている場合は、タイムアウトを完全に回避するのは難しくなります。

メッセージがキューから取り出されない

TCP/IP 配信中に発生したエラーは、一時的なことがよくあります。通常、MTA は、問題が発生したときにメッセージを残し、それを定期的に再試行します。大規模なネットワークでは通常、あるホスト上で定期的な機能停止が起こっても、ほかのホスト接続は適切に作動しています。問題を検証するには、配信試行に関連するエラーのログファイルを調べます。「smtp_open の致命的なエラー」のようなエラーメッセージが記述されていることもあります。このようなエラーは特別なものではなく、通常はネットワークに関する一時的な問題と関連しています。TCP/IP ネットワークに関する問題をデバッグするには、PING、TRACEROUTE、NSLOOKUP のようなユーティリティーを使用します。

次の例は、メッセージが xtel.co.uk への配信待ちでキューに入ったままになっている理由を確認するためのステップを示しています。メッセージがキューから取り出されない理由を確認するには、MTA が TCP/IP 上で SMTP メールを配信するために使用するステップを再作成することができます。


% nslookup -query=mx xtel.co.uk (手順 1)
            
Server: LOCALHOST
Address: 127.0.0.1

Non-authoritative answer:
XTEL.CO.UK  preference = 10, mail exchanger = nsfnet-relay.ac.uk (手順 2)

% telnet nsfnet-relay.ac.uk 25 (手順 3)
Trying... [128.86.8.6]
telnet: Unable to connect to remote host: Connection refused

  1. NSLOOKUP ユーティリティーを使用して、MX レコードが存在する場合、どの MX レコードがこのホストに存在しているかを確認します。MX レコードが存在していない場合、直接ホストへの接続を試みる必要があります。MX レコードが存在している場合、指定された MX リレーに接続する必要があります。MTA は MX 情報を優先して処理します (優先して処理しないように設定されている場合は除く)。「TCP/IP MX レコードのサポート」も参照してください。

  2. この例では、DNS (ドメインネームサービス) は xtel.co.uk の指定された MX リレーの名前を返しています。これは MTA の実際の接続先になるホストです。複数の MX リレーがリストにある場合、MTA は各 MX レコードを、優先度がもっとも低いものから順に、連続して試行します。

  3. リモートホストへの接続がある場合は、SMTP サーバーのポート 25 への TELNET を使用して、受信 SMTP 接続を受け入れているかどうかチェックする必要があります。

    注 –

    ポートを指定しないで TELNET を使用すると、リモートホストが通常の TELNET 接続を受け入れることがわかります。これは、SMTP 接続を受け入れることを示すわけではありません。多くのシステムは、正規の TELNET 接続は受け入れても SMTP 接続は拒否します。または、その逆になります。そのため、常に SMTP ポートのテストを行う必要があります。

    前述の例では、リモートホストは SMTP ポートへの接続を拒否しています。これが、MTA がメッセージの配信に失敗した理由です。この接続は、リモートホストの設定ミスやリモートホスト上での何らかのリソース不足のために拒否されることがあります。このような場合は、ローカルで問題解決を行うことはできません。通常は、MTA にメッセージの再試行を続けさせることになります。

DNS を使用しない TCP/IP ネットワーク上で Messaging Server が稼動している場合は、最初の 2 つの手順を省略することができます。代わりに、TELNET を使用して、問題となっているホストに直接アクセスすることができます。MTA が使用するホスト名と同じホスト名を使用する際は、注意してください。ホスト名を確認するには、MTA の最後の試行に関連するログファイルを確認します。ホストファイルを使用している場合は、ホスト名情報が正しいことを確認する必要があります。ホスト名ではなく DNS を使用することを、強くお勧めします。

TCP/IP ホストへの接続をテストする場合、インタラクティブテストを使用して問題が発生しないのであれば、ほぼ確実に、問題は MTA が最後にメッセージを配信しようとしたあとに解決されています。該当するチャネルで imsimta submit tcp_channel を再度実行して、メッセージがキューから取り出されているかどうかを確認することができます。

新しいチャネルを作成するには

状況によっては、リモートドメインに問題が発生し、このサーバー宛のメールが大量にあると、配信できないメッセージで送信チャネルキューがいっぱいになることがあります。MTA はこれらのメッセージの再配信を定期的に試行するので (再試行の頻度と回数は backoff キーワードで設定可能)、通常の状況では操作は必要ありません。ただし、多くのメッセージがキューに溜まると、配信できないメッセージのバックログを処理するためにすべてのチャネルジョブが使用され、ほかのメッセージが適時に配信されなくなることがあります。

このような場合は、独自のジョブコントローラプールで実行されている新しいチャネルにこれらのメッセージを再ルーティングすることもできます。これによって処理の競合が回避され、ほかのチャネルはそれぞれのメッセージを配信できるようになります。次に、この手順を説明します。ここでは siroe.com というドメインを仮定しています。

Procedure新しいチャネルを作成するには

手順

  1. tcp_siroe-daemon という新しいチャネルを作成し、pool キーワードの新しい値を追加します。

    チャネルは /msg_svr_base/config/imta.cnf のチャネルブロックセクションに作成されます。このチャネルには、通常の送信 tcp_* チャネルと同じチャネルキーワードを設定します。通常、これはすべての送信 (インターネット) トラフィックを処理する tcp_local チャネルです。siroe.com は外部のインターネット上にあるので、これがエミュレートするチャネルになります。新しいチャネルは次のようになります。

    tcp_siroe smtp nomx single_sys remotehost inner allowswitchchannel     \
dentnonenumeric subdirs 20 maxjobs 7 pool SMTP_SIROE maytlsserver      \
maysaslserver saslswitchchannel tcp_auth missingrecipientpolicy 0      \    
tcp_siroe-daemon

    新しいキーワードと値のペア pool SMTP_SIROE に注目してください。これは、このチャネルへのメッセージでは SMTP_SIROE プールのコンピュータリソースだけを使用するように指定しています。また、新しいチャネルの前後には空白行が必要です。

  2. imta.cnf ファイルの書き換えルールセクションに 2 つの書き換えルールを追加して、siroe.com 宛の電子メールをこの新しいチャネルに送信します。

    新しい書き換えルールは次のようになります。


    siroe.com     $U%$D@tcp_siroe-daemon
.siroe.com      $U%$H$D@tcp_siroe-daemon

    これらの書き換えルールは、(host1.siroe.com や hostA.host1.siroe.com などのアドレスも含む) siroe.com 宛のメッセージを、tcp_siroe-daemon という正式なホスト名を持つ新しいチャネルに送信します。これらのルールの書き換え部分 $U%$D および $U%$H$D は、メッセージの元のアドレスを保持します。$U は、元のアドレスからユーザー名をコピーします。% は区切り文字で、ユーザー名とドメインの間の @ です。$H は、パターン内のドットの左側にあるホスト/ドメイン指定のうち、一致しない部分をコピーします。$D は、ドメイン指定のうち、一致する部分をコピーします。

  3. SMTP_SIROE という新しいジョブコントローラプールを定義します。

    /msg_svr_base/config/job_controller.cnf に、次の内容を追加します。


    [POOL=SMTP_SIROE]
job_limit=10

    これは、最大 10 個のジョブを同時に実行できる SMTP_SIROE というメッセージリソースプールを作成します。このプール定義とほかのプール定義の間に空白行を入れないでください。ジョブおよびプールの詳細については、「ジョブコントローラ」を参照してください。

  4. MTA を再起動します。

    次のコマンドを発行します。imsimta refresh

    これは設定を再コンパイルし、ジョブコントローラとディスパッチャーを再起動します。

    この例では、内部ユーザーから大量の電子メールが siroe.com という特定のリモートサイト宛に送られます。何らかの理由で、siroe.com は一時的に、着信 SMTP 接続を受け入れることができず、電子メールを配信できない状態です。このような状況はまれなことではありません。

    siroe.com 宛の電子メールが届くと、配信できないメッセージで送信チャネルキュー (通常は tcp_local) がいっぱいになります。MTA はこれらのメッセージの再配信を定期的に試行するので (再試行の頻度と回数は backoff キーワードで設定可能)、通常の状況では操作は必要ありません。

    ただし、多くのメッセージがキューに溜まると、siroe.com 宛のメッセージのバックログを処理するためにすべてのチャネルジョブが使用され、ほかのメッセージが適時に配信されなくなることがあります。このような場合は、独自のジョブコントローラプールで実行されている新しいチャネルに siroe.com 宛のメッセージを再ルーティングすることもできます (「ジョブコントローラ」を参照)。これによって、siroe.com 宛のメッセージで使用されている処理リソースの競合が回避され、ほかのチャネルはそれぞれのメッセージを配信できるようになります。次に、新しいチャネルを作成してこの状況に対処する手順を説明します。

MTA メッセージが配信されない

メッセージ転送に関する問題のほかに、2 つの一般的な問題があります。この問題はメッセージキューにある未処理のメッセージに起因することがあります。

  1. キューキャッシュはキューディレクトリにあるメッセージと同期しません。MTA キューサブディレクトリにある配信待ちのメッセージファイルは、メモリー内キューキャッシュに入れられます。起動時にチャネルプログラムは、このキューキャッシュを調べて、キューにあるどのメッセージを配信するかを確認します。メッセージファイルがキューの中にあっても、対応するキューキャッシュエントリがない場合もあります。

    1. 特定のファイルがキューキャッシュにあるかどうかをチェックするには、imsimta cache -view ユーティリティーを使用します。ファイルがキューキャッシュにない場合は、キューキャッシュを同期させる必要があります。

      キューキャッシュは、通常は 4 時間ごとに同期されます。必要に応じて、imsimta cache -sync を使用してキャッシュを手動で再同期することができます。同期が終わると、チャネルプログラムは、新しいメッセージが処理されたあとで、元の未処理メッセージを処理します。デフォルト (4 時間) を変更する場合は、sync_time= timeperiod を追加することで、ディレクトリ /msg_svr_base/config にある job_controller.cnf ファイルを変更する必要があります。ここで、timeperiod は、キューキャッシュを同期させる頻度です。timeperiod は 30 分より長くする必要があります。次の例では、job_controller.cnf のグローバルなデフォルト (Global defaults) を指定するセクションに sync_time=02:00 を追加することで、キューキャッシュの同期間隔が 2 時間に変更されます。


      ! VERSION=5.0
!IMTA job controller configuration file
!
!Global defaults
tcp_port=27442
secret=N1Y9[HzQKW
slave_command=NULL
sync_time=02:00

      imsimta cache -sync を実行したあとに、imsimta submit channel を実行してメッセージのバックログを空にすることができます。メッセージのバックログが大きい (1000 以上) 場合、チャネルを空にするのに時間がかかることがあるので、注意してください。

      キューキャッシュの情報の概要については、imsimta qm -maint dir -database -total を実行してください。

    2. キューキャッシュを同期させてもメッセージがまだ配信されない場合は、ジョブコントローラを再起動する必要があります。これを行うには、imsimta restart job_controller コマンドを使用します。

      ジョブコントローラを再起動すると、メッセージのデータ構造がディスク上のメッセージキューから再構築されます。

      注意 – 注意 –

      ジョブコントローラの再起動は最後の手段です。ほかの手段をすべて使用し尽くすまでは実行しないでください。

      ジョブコントローラの詳細については、「ジョブコントローラ」を参照してください。

  2. 処理するログファイルを作成できないために、チャネル処理プログラムの実行は失敗します。アクセス権、ディスク容量、および制限容量をチェックします。

メッセージがループしている

メッセージがループしていることをMTA が検出すると、そのメッセージは .HELD ファイルとして保持されます。詳細については、「.HELD メッセージを診断して整理する」を参照してください。場合によっては、MTA がメッセージループを検出できないときもあります。

最初のステップは、メッセージがループしている理由を確認することです。問題のメッセージのコピー (MTA キュー領域にあるとき)、問題のメッセージに関連する MTA メールログエントリ (該当チャネルの MTA 設定ファイルで logging チャネルキーワードが有効になっている場合)、および該当チャネルの MTA チャネルのデバッグログファイルを確認します。問題のメッセージの From: および To: アドレス、Received: ヘッダー行、およびメッセージ構造 (メッセージ内容のカプセル化の種類) を確認して、発生したメッセージループの種類を特定することができます。

一般的によくある原因として、以下のものがあります。

  1. ポストマスターアドレスが壊れている。

    MTA では、電子メールを受信するために、ポストマスターアドレスが正しく機能しなければなりません。ポストマスターへのメッセージがループしている場合は、メッセージを受信できるアカウントをポイントする適切なポストマスターアドレスが設定されているかどうかチェックします。

  2. Received: ヘッダー行の削除が、MTA によるメッセージループの検出の妨げとなっている。

    通常のメッセージループの検出は、Received: ヘッダー行に基づいています。Received: ヘッダー行が MTA システム自体で明示的に、あるいはファイアウォールのような別のシステム上で削除されている場合、メッセージループを適切に検出できなくなることがあります。このような場合は、Received: ヘッダー行が知らないうちに削除されていないかどうかチェックします。また、メッセージがループしている根本的な原因もチェックします。考えられる原因は、システム名の割り当ての問題 (システムが自分の名前の変形を認識しないように設定されている場合)、DNS の問題、該当するシステムに承認可能なアドレス情報がないこと、あるいはユーザーアドレス転送エラーなどです。

  3. ほかのメッセージングシステムによる通知メッセージの処理が正しくなく、通知メッセージに応答して再度カプセル化されたメッセージが生成されています。

    インターネット規格では、通知メッセージ (メッセージ配信やメッセージバウンスのレポート) にメッセージループを防ぐための空のエンベロープ From: アドレスがあることを必要としています。ただし、メッセージングシステムによってはこのような通知メッセージを正しく処理しない場合もあります。このようなメッセージングシステムは、通知メッセージを転送またはバウンスするときに、新しいエンベロープ From: アドレスを挿入することがあります。これがメッセージループの原因になることもあります。解決策は、通知メッセージを正しく処理していないメッセージングシステムを修復することです。

.HELD メッセージを診断して整理する

メッセージがサーバーまたはチャネル間でバウンスされていることを MTA が検出すると、配信は停止され、メッセージは /msg_svr_base/data/queue/channel にある、サフィックスが .HELD のファイルに格納されます。通常、メッセージのループが発生するのは、各サーバーまたはチャネルがメッセージの配信をほかのサーバーやチャネルが担当するとみなしたときです。

たとえば、エンドユーザーが、2 つの別々のメールホスト上のメッセージを互いのホストに転送するオプションを設定しているとします。sesta.com アカウントに対して、varrius.com アカウントへのメール転送を有効にしています。また、この設定が有効であることを忘れて、varrius.com アカウントに対して sesta.com アカウントへのメール転送を有効にしています。

ループは、MTA の設定に誤りがあるために発生することもあります。たとえば、MTA ホスト X は、mail.sesta.com のメッセージがホスト Y に送信されるとみなします。しかし、ホスト Y はホスト X が mail.sesta.com のメッセージを処理すべきとみなし、結果としてホスト Y はホスト X にメールを返信することになります。

このような場合、MTA はメッセージを無視し、それ以上配信は試行されません。このような問題が発生したときは、メッセージ内のヘッダー行を見て、サーバーまたはチャネルがメッセージをバウンスしているかどうか確認します。必要であればエントリを修正してください。

imsimta qm release を実行するか、または次の手順に従って .HELD メッセージを再試行することもできます。

  1. 拡張子 .HELD を 00 以外の任意の 2 桁の数字 (たとえば、06) に変更します。

    注 –

    .HELD ファイルの名前を変更する前に、メッセージのループが停止していることを確認してください。

  2. imsimta cache -sync を実行します。このコマンドを実行すると、キャッシュが更新されます。

  3. imsimta submit channel または imsimta run channel を実行します。

これらの手順は何回か実行することが必要かもしれません。これは、Received: ヘッダー行が蓄積され、それによってメッセージに再度 .HELD とマークが付けられている可能性があるためです。

受信したメッセージがエンコードされている

MTA が送信したメッセージは、エンコードされた形式で受信されます。次に例を示します。

Date: Wed, 04 Jul 2001 11:59:56 -0700 (PDT)
From: "Desdemona Vilalobos" <Desdemona@sesta.com> 
To: santosh@varrius.com
Subject: test message with 8bit data 
MIME-Version: 1.0
Content-type: TEXT/PLAIN; CHARSET=ISO-8859-1
Content-transfer-encoding: QUOTED-PRINTABLE

2=00So are the Bo=F6tes Void and the Coal Sack the same?=

これらのメッセージは、MTA デコーダコマンド imsimta decode を使用すれば、デコードされて表示されます。詳細については、『Sun Java System Messaging Server Administration Reference』を参照してください。

RFC 821 で定義されているように、SMTP プロトコルで送信できるのは ASCII 文字 (7 ビット文字セット) のみです。実際、ネゴシエーションが行われていない 8 ビット文字の転送は SMTP 経由では無効であり、いくつかの SMTP サーバーでさまざまな問題の原因になることがあります。たとえば、SMTP サーバーが計算量の多いループに陥ってしまうことがあります。メッセージは何度も繰り返し送信されます。8 ビット文字は SMTP サーバーをクラッシュさせることがあります。最終的に、8 ビット文字セットは、8 ビットデータを扱えないブラウザやメールボックスに大きな損害をもたらす可能性があります。

以前に使用されていた SMTP クライアントには、8 ビットデータを含むメッセージを処理するときのオプションが 3 つしかありませんでした。メッセージを配信不能として差出人に返送するオプション、メッセージをエンコードするオプション、RFC 821 の直接違反でメッセージを送信するオプションです。しかし、MIME および SMTP 拡張の出現により、現在では、ASCII 文字セットを使用することによって 8 ビットデータをエンコードする標準のエンコーディングがあります。

前述の例で受取人は、MIME コンテンツタイプが TEXT/PLAIN のエンコードされたメッセージを受信しています。リモート SMTP サーバー (MTA SMTP クライアントからのメッセージの転送先) は、8 ビットデータの転送をサポートしていません。元のメッセージに 8 ビット文字が含まれていたため、MTA はメッセージをエンコードする必要があります。

SSR (Server-Side Rules) が作動していない

フィルタは、メールメッセージに適用される 1 つ以上の条件付きアクションで構成されています。フィルタはサーバー上に保存されて評価されるため、SSR (Server-Side Rule) と呼ばれることがよくあります。

この節では、SSR に関する次の情報について説明します。

「ユーザーレベルのフィルタをデバッグするには」も参照してください。

SSR ルールをテストする


# imsimta test -rewrite -debug -filter user@domain

出力では次の情報を探します。


mmc_open_url called to open ssrf:user@ims-ms
   URL with quotes stripped: ssrd: user@ims-ms
Determined to be a SSRD URL.
   Identifier: user@ims-ms-daemon
Filter successfully obtained.

一般的な構文の問題

ユーザーが電子メールの送信ボタンを押したときの応答が遅い

ユーザーがメッセージを送信するときに遅延がある場合は、メッセージキューディスクのサイズ不足が原因でディスクの入出力が低下している可能性があります。ユーザーが電子メールクライアントの送信ボタンを押したとき、メッセージキューへのメッセージのコミットが完了するまで、MTA はメッセージの受信確認を完全には受け入れません。メッセージキューのサイズ設定については、『』を参照してください。

アドレスのローカル部分または受信フィールド内のアスタリスク

MTA は、アドレスのローカル部分および作成する受信フィールド内の ASCII 文字のみではなく 8 ビット文字もチェックし、アスタリスクで置き換えるようになりました。