 |
|
 |
| |
 |
「導入後の製品FAQ」セレクション
ここではふだん「サポート２」に収録されている「導入後の製品FAQ」の記事の中から、毎週火曜日に週替わりで３つの記事をランダムにセレクトしてご紹介いたします。E-Postシリーズ製品の機能に対する定番的な質問やより習熟するための使い方だけでなく、製品を取り巻く解決ノウハウの豊富さなどを感じ取っていただければ幸いです。
|
2025年4月第3火曜日分
|
 |
|
 |
|
E-Postから他サーバへ送信、そのサーバが自動転送して再びE-Postに送信する場合の要注意点
E-Postから他メールサーバへ送信、そのメールサーバが自動転送処理をするとき、エンベロープFROMをもとのまま書き換えないで再びE-Postに転送すると、意図せずE-Post着信時に拒絶されるケースが起こり得ます。
メールサーバ全般についてふれると、メールサーバ内で自動転送を行うとき、エンベロープFROMを書き換え設定できるもの、元のエンベロープFROMのままで書き換えできないもの、といずれかに分かれます。元のエンベロープFROMのまま書き換えないで再びE-Postに転送するということは、エンベロープFROMはE-Post側に登録されているドメイン名を冠したメールアドレスが使われているということになります。
この場合、他メールサーバで転送させたメールをE-Post側に単に着信させたいだけであっても、実際にはE-Post側に登録されているドメインに含まれる元のアカウントを使ったSMTP送信要求の形になってしまうものと理解してください。E-Post側でSMTP認証を実施していれば、E-PostはSMTP AUTHを要求する形となり、着信させるはずが送信要求の形となり、最終的にエラー「503.5.0.0 Need EHLO before AUTH」で拒絶される結果となってしまいます。
これに対する解決方法は、他メールサーバが自動転送をするときにエンベロープFROMを元のままにせず、書き換えるように設定することです。この場合は他メールサーバがそうした機能を有していることが前提になります。
あるいは別の方法としては、E-Post側に送られてくる自動転送をするメールサーバからの送信要求を無条件許可させるよう中継の制限【effect.dat】にIPアドレスをtrue指定するという方法がその次に考えられます。ただしこの方法ですと、無条件許可を与えるメールサーバが不正中継や不正利用の踏み台になるおそれがなく、またbot等に感染してSPAMをばらまく危険性もまったくなく、絶対的に信頼できるものなのかどうかという大前提が必要になります。うかつな無条件許可は、不正中継や不正利用の踏み台になる可能性が常に背中合わせにあることを理解してください。
| |
 |
|
 |
|
|
|
|
|
ヘッダ行が252byte以上のメールをメーリングリストで再配送するとき、ヘッダが途切れたり本文が文字化けをしたりすることがある
ヘッダ行が252byte以上のメールをメーリングリストからメーリングリストへ再配送するとき、ヘッダが途切れたり本文が文字化けを起こしたりするケースがあることが判明しました。
これはヘッダの行が252byte以上のメールをメーリングリストからメーリングリストへ再配送するとき、EPSTDSが余計な空白行を出力することが原因です。これによりヘッダの途切れや本文の文字化け、あるいはメールのエンコード異常といった現象を引き起こすことにつながります。
この問題の対策が取られているのは、EPSTDSのバージョン4.71以降です。「サポート２」より最新差分アップデートプログラムを適用し、最新のモジュールに置き換えてください。なお、以降の最新版では累積的に適用されています。
対策が取られたEPSTDSの修正点
--------------------------------------------------------------------
[EPSTDS]
v4.71 2020.06.10
1.配送メールのヘッダ行が252byte以上だと不正な改行が追加される不具合の修正。
--------------------------------------------------------------------
対策を取るには以下の最新差分を適用してください。今後これ以降の版では累積的に適用されます。
[64bit版]
・E-Post Mail Server Enterprise II (x64) 20200610差分 掲載日: 2020-06-30
・E-Post Mail Server Standard (x64) 20200610差分 掲載日: 2020-06-30
・E-Post SMTP Server Enterprise II (x64) 20200610差分 掲載日: 2020-06-30
・E-Post SMTP Server Standard (x64) 20200610差分 掲載日: 2020-06-30
[32bit版]
・E-Post Mail Server Enterprise II 20200610差分 掲載日: 2020-06-30
・E-Post Mail Server Standard 20200610差分 掲載日: 2020-06-30
・E-Post SMTP Server Enterprise II 20200610差分 掲載日: 2020-06-30
・E-Post SMTP Server Standard 20200610差分 掲載日: 2020-06-30
|
|
|
|
|
|
|
|
|
|
E-PostシリーズはNetBIOSを利用するのか？NetBIOSを停止してよいか？
E-Postシリーズは、Windows Serverに実装されているNetBIOS（NetBIOS over TCP/IP）を利用するのか？NetBIOS（NetBIOS over TCP/IP）のサービスを停止してよいか？という質問を受けたことがあります。
E-Postシリーズは、名前解決のためにNetBIOS（NetBIOS over TCP/IP）の機能は一切利用されていませんし、NetBIOSで使われるポートも使いません。
下記の２つの使用状況を除いて、NetBIOS（NetBIOS over TCP/IP）を止めた場合でも、基本的なメールサーバとしての動きができなくなるといったことはありません。この下記の２つはNetBIOSありきの環境を前提に動作していると考えます。
(1) ユーザー管理でActive Directory連携をしているとき
(2) E-Post方式クラスタ環境を構築していて、メール作業用フォルダとしてネットワーク共有ドライブを指定しているとき
上記の使用状況やその環境ではない、たとえばユーザー管理がSoft Accout（E-Post独自方式）であり、シングルサーバ環境では、NetBIOS（NetBIOS over TCP/IP）を止めた場合でもメールサーバの動きとして特別に問題になるようなことは基本的にありません。
実際にNetBIOSサービス停止を試して確認しました。「インターネットプロトコル（TCP/IP v4）」のプロパティから「詳細設定」を開き、ネットワーク「WINS」タブにある「NetBIOS over TCP/IP を無効にする」チェックボックスオンにして動作を確認してみたところ、ユーザー管理がSoft Accout（E-Post独自方式）であり、シングルサーバ環境である場合、メールサーバの動きとして特段の変化や支障になるような問題はありませんでした。
☆ ☆
このNetBIOS（NetBIOS over TCP/IP）とやや関連する問題にふれてみます。
hostsファイルにメールサーバに設定する自分のメールドメイン名とマシンのIPアドレスを記述しているかどうかによって、inlogやacceptlogなどの各種ログやReceived:ヘッダに記載されるマシン名（あるいはメールドメイン名）が変わる結果になりますので留意してください。
●hostsファイルに自分のメールドメイン名とマシンのIPアドレスを記述している場合（下記FAQ記事参照）
→hostsファイルに記述している「自分のメールドメイン名」だけがinlogやacceptlogなどの各種ログに記載されます。また同様の書式でReceived:ヘッダにも記載されます。
例）test-sample.jp
●hostsファイルに自分のメールドメイン名とマシンのIPアドレスを記述していない場合
→「コンピュータ名．E-Postに設定している内部メールドメイン名」のスタイルでinlogやacceptlogなどの各種ログに記載されるケースがあります。また同様の書式でReceived:ヘッダにも記載されます。内部メールドメインが複数設定されているマルチドメインの場合はAccount Managerに登録されているドメイン名のうち、昇順で最初に見つかるものが優先的に使われます。
例）SV1.test-sample1x.jp
※このときNetBIOSのコンピュータ名（あるいはホスト名）が引用され、ログやReceived:ヘッダに記載されることがあるため、関連事項としてふれました。
（関連FAQ）
●hostsファイル記述の必要性と有用性について
●Received:ヘッダに該当しない別のドメイン名が表示される
●inlog / outlog / outlocallog の行頭に記載される＠より右側のサーバ名称は何によっている？
●HELOコマンドで送出するホスト名がFQDN（ホスト名＋ドメイン名）になっていない
|
|
|
|
|
|
|
| |
|
|
|
|
|
