 |
|
 |
| |
 |
「導入後の製品FAQ」セレクション
ここではふだん「サポート２」に収録されている「導入後の製品FAQ」の記事の中から、毎週火曜日に週替わりで３つの記事をランダムにセレクトしてご紹介いたします。E-Postシリーズ製品の機能に対する定番的な質問やより習熟するための使い方だけでなく、製品を取り巻く解決ノウハウの豊富さなどを感じ取っていただければ幸いです。
|
2024年7月第2火曜日分
|
 |
|
 |
|
アカウントの追加・削除および年度切り替え時での大幅変更の対応策について
アカウント自体の追加や削除が小規模な場合は、E-Post Mail ServerにあるAccount Managerでアカウントの追加・削除を行います。Account Managerからアカウントの追加を行った場合、アカウント追加時点では、最初のメール着信がまだない状態ではメールボックスフォルダは自動生成されません。着信前でも生成しておきたいときには、右クリックメニューから「エクスプローラ」を選択して実行すると、フォルダが開き、この時点で該当アカウントのメールボックスフォルダが自動生成されます。
アカウントの削除を行った場合は、該当アカウントのメールボックスフォルダも一緒に削除されます。一時的な使用禁止であればアカウント名をリネームして対処します。
一方、年度切り替え時などで大幅に入れ替えがあり、大部分のアカウントのデータの追加・削除・変更がある場合、次のような対応策を推奨します。あらかじめ全アカウントの正しい情報が入っているインポート可能な書式で作成済みのテキストファイルを用意しておきます。
- メールサーバの全サービスプログラムを停止します。
- 現在のアカウントから削除されるアカウントだけ、リスト上からチェックし、削除対象アカウントに対するメールボックスフォルダのフォルダ名をエクスプローラから直接リネームしてください。そのときフォルダ名の先頭部分を"~"を付けるなどしてリネームしておくようにします。
- プログラムインストールフォルダ内にアカウントデータである [ドメイン名].idxという拡張子.idxのファイルがあるのを確認します。このファイルがアカウントデータファイルです。
- 上記 3 で確認したアカウントデータファイル名の先頭部分を"~"を付けるなどしてリネームしてください。あるいは別の場所へ退避させるか移動します。
- Mail Control と Account Manager を開き直し、今まで登録されていたアカウントデータがいったん空になった状態を確認します。
- Account Manager のユーザーインポート機能を利用して全アカウントの正しい情報が入っているテキストファイルのインポートを実行します。
- Mail Control と Account Manager を開き直し、正常にインポートされ、アカウントデータが登録されていることを確認します。
- 上記 2 の手順でリネームしていた削除対象フォルダを探してフォルダを削除してください。一定の時期、残しておく場合は、その限りではありません。
- メールサーバの全サービスプログラムを開始させ再開します。
なお、メールボックスフォルダには、メールデータ（拡張子.MSG）のほか、各アカウントの設定状況に応じて、自動応答・自動転送のメール制御設定ファイル（IMS.CTL）、SMTP認証ファイル（apop.dat）、個人メールフィルタ設定ファイル（mail.dat）、送信先制限設定ファイル（sender.dat）、サイズ制限設定ファイル（size.ctl）などが格納されています。それらの設定ファイルはインポートを行った場合、反映されるのは（apop.dat）と（size.ctl）だけで、その他は対象外です。
（関連FAQ）
●inboxフォルダ（メールボックスフォルダ）配下に格納されるデータファイルについて
また、大幅な入れ替えのため、アカウントデータファイル名をいったんリネームしてから、テキストファイルでインポートする上記の方法を取るときには、一時的にアカウントが存在していない時間が発生してしまいますので、作業にあたっては、事前にメールサーバの全サービスを停止させた状態で行ってください。
サービスを停止しているとき、万が一、内部からアクセスしようとすると接続エラーが表示され、外部からの着信メールについては、サービスが停止状態で応答できないことから、通常ルールならば相手側サーバから一定時間後にリトライされてきます。参考までにE-Postシリーズの場合のリトライ時間間隔は、2分後、4分後、8分後、というような形になっています。
| |
 |
|
 |
|
|
|
|
|
外部からメールが届かない
外部のSMTPサーバーがメールを自身のSMTPサーバーへ届けるためには、〈アカウント〉＠〈ドメイン〉の〈ドメイン〉部分を参照して、このドメインの設定しているDNSの情報より、どのマシンへ接続するかを判定しています。
外部から自身のSMTPサーバへ届かない場合は、自身が公開しているDNSサーバーの設定の下記のいずれかが、「外部のネットワーク」より、参照できるかを確認してください。
1. MXレコード
2. Aレコード
「外部のネットワーク」より、正しく登録されているか否かを確認するには、Aレコード登録の有無を調べるには、pingコマンドにて〈ドメイン〉を調べて、応答が返るか否かをチェックします。また、MXレコード登録の有無は「nslookup」にて、自身のドメインについて、MXレコードが返されるか確認してください。
（例）
nslookup -type=mx domain.jp
注意）確認は必ず「外部のネットワーク」より行って下さい。
|
|
|
|
|
|
|
|
|
|
UID値の上限に達していたときの非対応メーラーの動きとその対応方法について
IMAP4使用時において、メッセージが管理されるUID値は、メールボックスフォルダのフォルダごとに管理されていますが、UID値が上限値である（UID値=4294967295）に達してしまっているとき、非対応のメーラーを使っているときには、サーバ側の操作対応が必要なことがあります。メッセージが管理されるUID値に関する説明と、E-Post側の動作と非対応のメーラーであるOutlook側の動き、そして対応方法の提示をします。
- UID値の上限値および、E-Post側とOutlook側の動きの推測について
IMAP4プロトコルでは、メッセージがUID値によって管理されます。E-PostシリーズのIMAP4用メールボックスでは、INBOXフォルダ下にできる "uid" ファイルにその連番情報が書き換えられていきます。サブフォルダにもそれぞれ "uid" ファイルができ、連番情報が管理されることになります。このうち、いちばん問題になる可能性があるのは、受信トレイにあたるINBOXフォルダ下のUID値です。
あるユーザー様から、メールが届いても、Outlook2013側がメールを認識できず、処理ができないというサポート案件がありました。IMAP4ログを調べたところ、UID FETCHの命令でUIDの上限値である32bitの値（4294967295）いっぱいで要求している次のような記録が見つかりました。
[31/Jan/2016:08:55:55] abcdef from 192.168.xxx.xxx UID FETCH
97316:4294967295 (UID FLAGS RFC822.SIZE BODY.PEEK[] INTERNALDATE)
このUID値については、IMAP4プロトコルを規定したRFCのひとつ、RFC2060に規定があります。RFC2060では「2.3.1.1. ユニーク識別子(UID)メッセージ属性」項目では、"A 32-bit value assigned to each message,"＝「各メッセージに割り当てられた32ビット値で...」とされています。32ビット値ですから、最大値 4294967295 となります。ちなみに、RFCの規定では、上限値に達したあとのルールは一切決められておりません。
E-Postシリーズでは、この上限値に達したあとは、最初に戻って "1" から発番していく動きをするように開発されています。しかし、Outlook2013などのIMAP4クライアントソフト（メーラー）では、UID値が上限に達した際の動きがどのようになっているかは、おそらく対応はまちまちであろうと推測され、中にはその処理もまったく想定されていないものがあると推測されます。
報告された現象は、UIDの上限値に達したためそれ以上メールが届いても、Outlook2013側が認識できない、あるいは処理ができない状態なのではないかと推測されました。ちなみに、UIDの上限値 4294967295 に達してしまったことについて、このような値になってしまうことは、通常の使い方をする限り、あまり考えられないことではあるのですが、この値になっている現状から、次のような対応策を提示いたしました。
- 対応策方法について
受信トレイにあたるE-PostのIMAP4用メールボックスであるINBOXフォルダのリネームを行います。
(1) クライアント側のメーラーを閉じておく。
(2) E-PostのIMAP4用メールボックスであるINBOXフォルダのフォルダ名をリネームする。
例）OLD_INBOX
※半角英数字の文字でのリネームを推奨。全角文字にしたいときは "UTF-7の拡張版" でエンコードしなくてはならないため煩雑になる。
(3) クライアント側のメーラーを起動し、メールの再同期を行う。新しいメールを受信してみて、受信トレイに表示されるか確認する。
このとき、自動的に新しいINBOXフォルダが生成されます。"uid" ファイルも、新しく "1" から自動的にふり直されます。新着したメールは、新しいINBOXフォルダに入ります。
なお、受信トレイに利用してきたフォルダ名を上記例で "OLD_INBOX" にリネームしましたが、そのフォルダがメーラーの画面からそのまま表示されていて、メッセージも読めることを確認してください。念のため、作業はバックアップを取った上で行ってください。なお、サービスの停止・開始などの操作は必要ありません。
IMAP4使用時のメールボックスフォルダの位置は、次の記事を参考にしてください。
（関連FAQ）
●方式の違いによるメールボックスフォルダの作成位置について
|
|
|
|
|
|
|
| |
|
|
|
|
|
