 |
|
 |
| |
 |
「導入後の製品FAQ」セレクション
ここではふだん「サポート２」に収録されている「導入後の製品FAQ」の記事の中から、毎週火曜日に週替わりで３つの記事をランダムにセレクトしてご紹介いたします。E-Postシリーズ製品の機能に対する定番的な質問やより習熟するための使い方だけでなく、製品を取り巻く解決ノウハウの豊富さなどを感じ取っていただければ幸いです。
|
2025年5月第2火曜日分
|
 |
|
 |
|
Windowsの「サービス」で「サービスを再起動する」設定しておくことをお薦め
Windows Serverの管理ツール「サービス」の設定でも、E-Post各サービスを開始や停止を行ったり、その挙動を設定することができますが、「サービス」の設定でE-Post各サービスを選択し、右クリックメニューで表示される「プロパティ」を開き、「回復」タブにある「最初のエラー」で「サービスを再起動する」を設定しておけば、万が一のサービス停止時に次善の策として自動再起動を設定できます。「サービスを再起動する」設定をしておくことで、次善の対応策を施しておくことをお薦めします。
ちなみに、万が一の異常発生によるサービス停止時にはその原因を調べなくてはなりませんが、サービス停止時におけるWindowsのイベントビューワの記録にアプリケーションエラーの記録がないかどうか、そのエラーコードはどのようになっているか、確認してください。
| |
 |
|
 |
|
|
|
|
|
SSL/TLS証明書適用後の通信をコマンドプロンプトのコマンドラインで確認する方法
E-Post Mail ServerシリーズにSSL/TLS通信を設定し、SSL/TLS証明書を適用した後、SSL/TLS通信の正常/異常を確認するには、通常の場合にはメーラーで行うと思いますが、「ダウンロード」公開ページに用意してある SSL-Key-SHA2.zip をダウンロード、解凍して得られるWindows用の openssl.exe コマンドにオプションを付け使用することで、SSL/TLS通信での可否を確認することが可能です。コマンドプロンプトから使用します。
---------------------------------------------------------------------
基本例
---------------------------------------------------------------------
[SMTP]
openssl s_client -connect [server-address]:465 -verify 1
openssl s_client -connect [server-address]:25 -verify 1 -starttls smtp
あるいは
openssl s_client -connect [server-address]:587 -verify 1 -starttls smtp
[POP3]
openssl s_client -connect [server-address]:995 -verify 1
openssl s_client -connect [server-address]:110 -verify 1 -starttls pop3
[IMAP4]
openssl s_client -connect [server-address]:993 -verify 1
openssl s_client -connect [server-address]:143 -verify 1 -starttls imap
---------------------------------------------------------------------
※E-Post側でそれぞれの待ち受けポートを可能に設定していることが前提です。
※疎通できればその後 telnetコマンドで同様の通信確認ができます。途中で中断するときは quit で抜けてください。
※証明書を作ったときの正しいCA証明書を指定しないと Verify return code: 20 や Verify return code: 21 などのエラーが表示されます。
エラーを出さないで確認したい場合にはルート証明書などをさらに -CAfile オプションで指定してください。
---------------------------------------------------------------------
ルート証明書を指定する書式と例
---------------------------------------------------------------------
openssl s_client -connect [server-address]:[port番号] -verify 1 -CAfile [証明書ファイル]
openssl s_client -connect [server-address]:465 -verify 1 -CAfile rootcacert_r1.cer
openssl s_client -connect [server-address]:995 -verify 1 -CAfile rootcacert_r1.cer
openssl s_client -connect [server-address]:993 -verify 1 -CAfile rootcacert_r1.cer
---------------------------------------------------------------------
（関連FAQ）
●SMTP/POP3/IMAP4 over SSL/TLS設定方法
|
|
|
|
|
|
|
|
|
|
MXレコードに書かれた複数のMTAのうち優先度の低いサーバに繰り返し接続しエラーを返される
MXレコードに書かれた複数のMTAのうち、常に優先度の低いサーバに接続し、一時的拒絶のエラーを繰り返し返されるという状況の報告が寄せられることがあります。一時的拒絶とはMTA種類によっても異なりますが、400番台のエラー、たとえば「421 Service Temporarily Unavailable」といったエラー応答がその典型的なものです。
E-Postの仕様では、DNSによる名前解決を高速化するため、MXキャッシュデータを作成・利用します。MXキャッシュデータは、接続成功時には継続して保管されます。MXキャッシュデータが削除されるのは接続（コネクト）に失敗したときのみで、接続が失敗した場合のみ、キャッシュ情報のリセット対象とみなしてMXキャッシュファイルを削除します。（EPSTDS v4.65まで）
相手側MTAといったん接続できてしまうと、SMTPの最終的なネゴシェーション結果は400番台の一時的拒絶で終了していても、上で述べたように、保管されているキャッシュ情報は有効とみなし、MXキャッシュデータをそのままにしておきます。同じサーバに継続して接続してしまうのは、そうした動作仕様のためでもあります。
この状況を改善するために、E-Post側で対応策を取るには、該当する送信先のMXキャッシュデータを手動で削除してください。MXキャッシュデータは、[メール作業用フォルダ]\mxcash\フォルダ下に該当ドメインの名の付いた拡張子.mxのデータファイルとして残っています。このキャッシュファイル自体を削除します。
また、MXキャッシュファイルを作らないでまったく利用しないよう設定する方法も有効です。「MXキャッシュの更新間隔」を"0"にしておくと、MXキャッシュファイルを作成せず、参照もしない状態になります。ただし、MXキャッシュを使わない設定にすると、DNSサーバへの参照がその都度発生しますので、負荷が高まることを留意してください。
なお、E-Postのこうした動作仕様に関して、20181224最新差分アップデートで適用される EPSTDS v4.66以降は、MXキャッシュデータの削除タイミングを一時的拒絶や永続的拒絶の場合にも広げ、適用するように仕様が変更されました。MXキャッシュ有効時に接続が成功してもDNSのMXレコードにある全ての送信先に拒絶された場合は、MXキャッシュファイルを削除します。
この改善により、MXレコードに書かれた複数のMTAのうち優先度の低いサーバに繰り返し接続し続けてエラーを返されることは、きわめて少なくなるのではないかと考えています。
（関連FAQ）
●送信先のMXレコードが変更されて以降も更新前の情報にもとづいて送られることがある
●MXキャッシュデータはどう更新されどういうときに削除されるのか
|
|
|
|
|
|
|
| |
|
|
|
|
|
