 |
|
 |
| |
 |
「導入後の製品FAQ」セレクション
ここではふだん「サポート２」に収録されている「導入後の製品FAQ」の記事の中から、毎週火曜日に週替わりで３つの記事をランダムにセレクトしてご紹介いたします。E-Postシリーズ製品の機能に対する定番的な質問やより習熟するための使い方だけでなく、製品を取り巻く解決ノウハウの豊富さなどを感じ取っていただければ幸いです。
|
2025年6月第1火曜日分
|
 |
|
 |
|
コマンドでエイリアス登録・削除などを操作したいときには
Web管理ツールのCGIプログラム（Web管理CGI）の実行ファイルである Epstuser.exe をコマンドプロンプトから引数付きで実行することにより、アカウント登録・削除だけでなくコンソールベースでエイリアス登録・削除が可能になりました。この新機能は EPST UserCGI v4.26以降で利用可能です。機能を利用したい場合は、事前にWeb管理ツール画面の［システム管理メニュー］→［バージョン情報］より EPST UserCGI 4.26 以降のバージョンになっていることを確認してください。
ここでは、エイリアス登録・削除の機能とコマンドを紹介します。詳細な使い方に関しては、サポート２内の［ダウンロード］−［運用ガイド・関連ドキュメント］コーナーにアップしている『E-Post Mail Server コンソール用管理ツール マニュアル』（PDF）をご覧ください。
エイリアスの一覧（表示）
Epstuser mode=NL domname=[ドメイン名]
エイリアスの登録（実アドレスとの割り当てせず）
Epstuser mode=NA domname=[ドメイン名] aliases=[エイリアス名]
実アドレスの参照（表示）
Epstuser mode=NS domname=[ドメイン名] aliases=[エイリアス名]
実アドレスの設定（割り当て）
Epstuser mode=NS next=P domname=[ドメイン名] aliases=[エイリアス名] mappedto=[実アドレス]
エイリアスの削除
Epstuser mode=ND domname=[ドメイン名] aliases=[エイリアス名]
（実行例）
Epstuser mode=NL domname=testdomain.jp
Epstuser mode=NA domname=testdomain.jp aliases=a1＠testdomain.jp
Epstuser mode=NS domname=testdomain.jp aliases=a1＠testdomain.jp
Epstuser mode=NS next=P domname=testdomain.jp aliases=a1＠testdomain.jp mappedto=real1＠testdomain.jp
Epstuser mode=ND domname=testdomain.jp aliases=a1＠testdomain.jp=
（関連FAQ）
●コマンドでアカウント登録・削除などを操作したいときには
| |
 |
|
 |
|
|
|
|
|
配送できなかったメールをログで確認する方法
配送できなかったメールをログにおいて確認する方法とそれに付随する解説をまとめました。
内部から外部へのメールを送ろうとして配送できなかったメールを確認する場合、大きくは２段階、まずEPSTRSが行うSMTP受領時、続いてEPSTDSが行うSMTP配送時と２回に分けてログを調べることが大事です。
（※事例にあげるメッセージIDおよび送信元ドメイン、宛先ドメインは架空のもの）
（１）EPSTRSが行うSMTP受領段階について
EPSTRSが行うSMTP受領段階がうまく行っているのかを調べるには、acceptlog（マシン接続ログ）→inlog（SMTP受信ログ）、ないしはacceptlog（マシン接続ログ）→receivelog（SMTP受信詳細ログ）を順に追って調べます。
特にacceptlogで'abort'されている記録がある場合は、その詳細理由や原因を知るためにはreceivelogの内容を調べる必要があります。acceptlogで見つけた同じメッセージIDでreceivelogを検索し調べます。
ちなみに、acceptlogで'ok'されている記録があるときは問題なく受領されていることを表します。inlogに記載されているものはすべて'ok'で受領されたものばかりです。
受領が問題なかったことが確認できれば続く（２）の配送段階での処理内容を調べます。
（参考FAQ）
●接続マシンログ（acceptlog）で abort されている理由を知るには
●acceptlogにメッセージIDが出ているのにreceivelogに見つからないケースがある理由
（２）EPSTDSが行うSMTP配送段階について
前段階の受領はうまく行っているのに、結果的にうまく送信ができていないようなときは、配送段階に何らかの問題があったと想定し、下記にあげるログからその理由と原因を調べます。
仮に配送段階に問題がなく、相手側のサーバが受信している記録がsenderlogから見つかったときは、こちら側には問題はなく、相手側サーバの問題があるという判断切り分けをして調べます。
調べるログは、senderlog（配送時の詳細ログ）やfaillog（配送失敗ログ）です。
【配送失敗ログ−faillogの例】
B0000123123＠test-sample00.jp send fail on [16/May/2018:11:18:39]
from info＠test-sample00.jp to user1＠test-sample01.jp ※1 [Unable to deliver to destination domain] ※2
B0000123123＠test-sample00.jp send fail on [16/May/2018:11:18:39]
from info＠test-sample00.jp to user2＠test-sample01.jp ※1 [Unable to deliver to destination domain] ※2
※１）仮に宛先をメールクライアントからTO,CC,BCCを区別して送信した場合でも、ログではエンベロープTOの内容に基づいて記録されるため、TO,CC,BCCの区別はされません。
※２）記載される配送失敗の理由はリトライの最終回においての失敗理由が記載されます。リトライ途中の理由はここに記載されず、senderlogを見る必要があります。言い換えるとここに記載される理由が本当の配送失敗理由だとは限りません。
（関連FAQ）
●senderlog と faillog に記載された配送失敗の理由が異なる
●送信できなかったエラーメールの内容とfaillogの内容が異なる
【配送時の詳細ログ−senderlogの例その１】
[11:08:39:119] [B0000123123-R0001] ※3 [test-sample01.jp] GetTryServer:()
（中略）
[11:09:11:404] [B0000123123-R0001] ※3 ConnectHost:
winsock connect failed. (socket error code=10061) ※4
※３）メッセージIDの後の枝番付き"-R0001"はリトライを表わします。
※４）socket error code=10061は、相手先MTAへの接続ができないケース。socket error code=10060なら、DNSサーバを参照できなかったりDNSサーバの動作状況に問題があるケースです。
（関連FAQ）
●ログに記録されるメッセージIDの後の枝番種類について
●senderlogに送信リトライのたび"socket error code=10060"のエラーが記録される場合
●senderlog に"421 Service Temporarily Unavailable"と"451 Requested action aborted: error in processing. (code=0/0)"が記録される理由について
●Winsock エラーコード表
【配送時の詳細ログ−senderlogの例その２】
[11:18:39:184] [B0000123123-R0001] [001]:ReturnMail Start:domain:
[test-sample00.jp] smtp server:[192.168.0.xx]
[11:18:39:200] [B0000123123-R0001] [001]:ReturnMail Completed.
[11:18:39:231] [B0000123123-R0001-E001] [test-sample00.jp] GetTryServer:() ※5
[11:18:39:231] [B0000123123-R0001-E001] [test-sample00.jp] GetTryServer:
(ltime(13170910719)-otime(13170910719))/30=(0)
[11:18:39:231] [B0000123123-R0001-E001] [test-sample00.jp] GetTryServer:()
※５）この部分はエラーメールの生成と送信元への送信を表わします。
（関連FAQ）
●senderlogに"GetTryServer:(xxxx)/120=(0)"が記録される意味について
【SMTPローカル送信ログ−outlocallogの例】
B0000123123＠test-sample00.jp sent on [16/May/2018:11:18:39]
to 192.168.0.xx from - to user＠test-sample00.jp ※6
B0000123123＠test-sample00.jp sent on [16/May/2018:11:18:39]
to 192.168.0.xx from - to user＠test-sample00.jp ※6
※６）エラーメールの送信元への送信を表わします。"from - to [送信元アドレス]"というように、fromの後が空白なのは、E-Postが自動で生成したメールのためです。
（関連FAQ）
●SMTPローカル送信ログ（outlocallog）などのログで fromアドレスが空白になっているケースがあるのはなぜ？
|
|
|
|
|
|
|
|
|
|
存在しないアカウントに大量メールなどメール攻撃に対する総合的な手だてはどうしたらよいか
外部のサーバから、存在しないアカウント宛に大量のメールが送りつけられてくると、膨大な数の user unknown のエラー応答を返すことになります。放置していると、サーバが存在していると解釈され、さらに続けて大量のメールが送りつけられてくる事態となり、より攻撃を受ける確率が高くなります。E-Post Mail Server / E-Post SMTP Serverシリーズに実装された機能をフル稼働し、以下にあげる設定を試みてみたり設定内容を確認するなど、総合的な手だてを講じてください。ここではまとめガイドとして紹介します。
- ORDBサイトの指定
E-Post Mail Control「中継の制限」タブにある「ORDBによる制限」設定を使い、有力なORDBサイトを最低でも一つは設定されることをお薦めします。これだけでも効果は絶大です。
たとえばスパムコップを指定されるときは、"bl.spamcop.net" を指定します。
ORDBサイトの情報によって拒絶された結果は、acceptlog（接続マシンログ）に理由といっしょに記載されます。
（関連FAQ）
●ORDBによる制限（ordb.dat）設定
- 特定のIPアドレスからの接続を拒否
E-Post Mail Control「接続の制限」タブにある「マシン毎の中継」【effect.dat】設定を使い、接続時の拒否を設定します。
acceptlog（接続マシンログ）に記録されている同じIPアドレスから大量に不正に接続を試みてあるもの、結果的にabortされているものを見つけてください。
ORDBサイトの情報でももれてくるもの、新しく不正に試みてくるものをその都度、指定する段取りでかまいません。
IPアドレスを指定して、「マシン毎の中継」【effect.dat】に以下の指定をします。
---------------------
[IPアドレス] false
---------------------
この設定の結果、指定されたIPアドレスから接続された時点で "550 5.1.7 Please, mail from a valid IP or Domain address." のエラー応答を返して一切拒絶するようになります。
ユーザーの存在を確認してからエラー応答を返すより、接続時点での”門前払い”に該当しますので、はるかに効果的かつ強力です。
（関連FAQ）
●特定のIPアドレスからの不正アクセスが大量に発生、これを拒否するには
- VRFYコマンドは無効のまま
E-Post Mail Control「サービス制御」タブにある「VRFY,EXPNコマンドに応答」チェックボックスは初期値オフ＝無効のままにしておいてください。万が一、有効にしますと、ユーザーの存在をコマンドベースで確認できるようになり、セキュリティが格段に下がってしまいます。
- メールフィルタ設定でSURBLサイトを指定
お薦めするのは、E-Post Mail Control「メールフィルタ」タブにあるメールフィルタ設定【mail.dat】でRBL: で任意のSURBL方式サイトを指定することです。下記記事の【ケース１】に書かれている内容例に従って指定します。「サポート２」にアップしているE-Post Mail Serverシステム運用ガイドも参考にしてください。
（関連FAQ）
●メールフィルタ（mail.dat）の設定事例
- 個人アカウント単位で使用可能になった【effect.dat】を有効に利用する
個人アカウント単位で受信するメールドメインが決まっている場合、受信許可するよう記述されたドメイン名からの受信だけが許可され、その他外部からのすべてのドメインからやってくるメールを拒絶するといったことができるようになりました。それが個人アカウント単位での【effect.dat】機能です。ヘッダレベルでなく、エンベロープFROMのレベルでチェックされるのでセキュアであり非常に強力です。
2015年8月以降に公開された最新差分アップデートを適用すると、個人アカウント単位での【effect.dat】に該当する機能が追加され、利用できるようになります。
（関連FAQ）
●個人アカウント単位で【effect.dat】を有効にする機能が新しく追加実装されました
- SMTP認証「認証接続ロックアウト機能」を有効にする
メールを大量に送りつけてくる攻撃の最終目的は、アドレスの存在を確認できたものから、認証パスワードを見破り、メールアドレスを不正利用、なりすまし、踏み台にしての大量配信です。
そうした事態を防御するため、2016年12月以降に公開された最新差分アップデートを適用すると、SMTP認証・POP3認証・IMAP4認証における「認証接続ロックアウト機能」が新機能として実装されました。
それぞれの認証において、総当たり攻撃が頻繁に見られるような場合には、この機能を有効にすることで、攻撃遮断をする実施を検討してください。
POP3認証あるいはIMAP4認証は一見すると無関係に思えるかもしれませんが、実際に認証パスワードを破ろうとする入口として使われる手口も非常に多いため、一緒に紹介します。
（関連FAQ）
●acceptlog / receivelogで大量に特定IPアドレス群からSMTP認証の総当たりを受けていることを見つけた場合
●〔新機能〕SMTP認証時の「認証接続ロックアウト機能」について
●〔新機能〕POP3認証時の「認証接続ロックアウト機能」について
●〔新機能〕IMAP4認証時の「認証接続ロックアウト機能」について
- SMTP接続時の「IPロックアウト機能」を有効にする
メールを大量に送りつけてくる単純な攻撃ではなく、サーバダウンが目的としか思えないような破壊的な攻撃、たとえば1秒間に100回以上を越える連続的な接続を試みるいわゆるDDos攻撃も増えてきました。こうしたDDos攻撃のような連続無差別攻撃に対して有効なセキュリティ対策を強化するため、2019年6月以降に公開された最新差分アップデートでは上記SMTP認証時の認証接続ロックアウト機能に加える形で、SMTP接続時の「IPロックアウト機能」が新機能として追加されました。
IPロックアウト機能では一定の時間（サンプリング間隔）の間に設定回数以上の連続した接続に対し、設定されたロックアウト時間の間、接続を拒絶します。このIPロックアウト機能により、特定のIPアドレスから繰り返されるDDos攻撃のような連続無差別攻撃に対しても、接続そのものを自動的に遮断できるようになります。その結果、サーバーの負荷を高めずにセキュリティ対策を強化できます。
2019年6月以降に公開された最新差分アップデートでは、合わせてPOP3接続時およびIMAP4接続時での「IPロックアウト機能」も実装されています。SMTPだけではなくPOP3やIMAP4へのDDos攻撃もかなり見られるようになりましたのでこの機能を使って有効な対策を取るようにしてください。
このIPロックアウト機能は、2019年6月以降の販売される製品パッケージの中には既に実装されています。
IPロックアウト機能を使用するには、以下の記事を参考にしてください。
（関連FAQ）
●〔新機能〕SMTP接続時の「IPロックアウト機能」について
●〔新機能〕POP3接続時の「IPロックアウト機能」について
●〔新機能〕IMAP4接続時の「IPロックアウト機能」について
|
|
|
|
|
|
|
| |
|
|
|
|
|
