サーバーマネージャーを起動します。
サーバ管理タブを開き「POP3・MTA」タブを開きます。
POP認証
POP3の認証方式を「プレーンとAPOP認証の同時利用」又は「APOP認証のみ」の選択を行います。
「APOP認証のみ」を選択した場合は、メールクライアントがAPOP認証に対応していない場合、メールクライアントでのメール受信が出来なくなりますので注意してください。
AUTH単独に応答しない
POP3 で認証を行う際に、認証メカニズムを指定しない AUTH コマンドが発行された際の応答を変更します。
応答しないにチェックを入れていない場合は、認証方式をサーバー側で対応している認証メカニズムをクライアントに通知し、チェックが入っている場合は -ERR 応答を行います。
この設定は、サーバー側の能力を確認する CAPA コマンドを使わずに AUTH コマンドで確認を行おうとするメールクライアント向けの機能です。
AUTH 単独で認証方式を確認するという方法は、確認した範囲の RFC では正式に定義されている方法では無い（見つからない）為、いくつかのサーバーでの独自拡張だと思われます。
一部のクライアントが応答することにより正常に認証ができなくなるケースがありますので、必要に応じて on / off の切り替えを行って下さい。不特定のクライアントが利用する場合は ON を推奨します
POP3 Simple Authentication and Security Layer(SASL)
POP3 で USER コマンドでの認証以外に SASL 認証を行う場合に利用します。
PLAIN / LOGIN / CRAM-MD5 の３種類に対応しています。
PLAIN / CRAM-MD5 は正式に認証方式が定められていますが、LOGIN 認証はサーバーによって実装が違うケースがありますので、LOGIN 認証で失敗するクライアントがある場合は、PLAIN / CRAM-MD5 の組み合わせをお試し下さい。
全て OFF にした場合は SASLでの認証はできず USER 認証のみとなります。
POP3受信制限
サーバからクライアントがPOP3を行う際に「サーバ側からPOP3で送信するメールを制限します」（クライアント側から見て受信制限）
制限をしない
文字通り制限を行いません。
指定日数以前を削除
POP3に「ログインした時点」で指定された日数を経過したメールを削除します。(日付の確認はファイルのタイムスタンプで行われます)
アカウント情報２の設定にある「保存日数」と違う点は「アカウントの保存日数」は「POP3からログアウトした時点で指定された日数を経過したメールを削除します。」アカウント情報２で設定されている場合は、日数を過ぎたメールでも読み出すことができ、ログアウトした時点で削除されます。
こちらの「POP3受信制限」はログインした時点で削除処理が行われますので期限を過ぎたメールは読み出すことができません。
サーバ上から完全に削除されますので、設定にはご注意下さい。
指定日数以前を送信しない
期限を過ぎたメールはPOP3で読み出すことができなくなります。ただしサーバ上には残っていますので、製品版付属の Webmail では閲覧が可能です。
多くのメーラーは一度受信したメールを再度受信しないように LIST/UIDL コマンドにてサーバ上のメールの確認を行います。
この確認処理でサーバ上のメールが少ない場合は無視できる処理量ですが、多くのメールがサーバ上に残っている場合は確認だけでかなりのサイズをダウンロードする必要がでてきます。本機能を設定しますと、LIST/UIDL/TOP/RETR 等のコマンドで期限を過ぎたメールを処理対象外としサーバへの負荷を軽減することができます。（特に Webmail をご利用になられている場合で受信メールボックスに大量のメールを残している場合に効果的です）
APOPポートを有効
POP3 とは別に APOP ポート（ポート番号112）を有効にする際にチェックを入れます。
APOP ポートは通常の POP3 ポートと機能は殆ど同じで設定も共通になっています。
唯一、APOP ポートでのログイン方法は「APOP認証」又は「POP AUTH」認証のみとなります。通常のプレーン認証を行うことはできません。
メールボックスチェック
ファイルチェック無効
POP3 へログインする際のメールボックスのチェックでファイルチェックを省略することによりCPU/HDD負荷を下げ応答速度を上げます。ファイルチェックを無効にすることに以下のデメリットが発生します。
Spool フォルダ以下の eml ファイルの移動や削除がエクスプローラやツールからできなくなります。
チェックが OFF の際にはログインする際に uidl.txt と実ファイルを比較し存在しない場合のメールは自動的に無効にします。ON にした場合はこのチェックが行われませんのでファイルが存在しない場合でもメールがカウントされ、TOP/RETR コマンド（メール読みだしコマンド）にエラー応答します。ただしチェックが ON の場合に TOP/RETR コマンドでエラーになった場合は自動的に uidl.txt の更新が行われますので一度 POP3 よりログアウトし再度ログインした場合は正常に動作するようになります。（自動uidl.txtの更新は該当するメールのみ行われます。２通実ファイルが存在しない場合は２回、１０通存在しない場合は１０回エラーが発生します。これは仕様です）
チェックを ON にしている際にまとめて eml ファイルの削除や移動を行う場合は、サーバを停止し「スプール状況」より「UIDL整理」を行ってください。
UIDチェック有効
POP3 へログイン後、メール一覧を取得する際に、UID に対応する eml ファイルが存在するかを確認します。UIDチェックを有効にすることに以下のメリット・デメリットが発生します。
PMailServer2 がメールを管理する uidl.txt が外因的な理由（ファイルの破損、更新のタイムアウト等）により破損していたり内容の整合性が正しく無い場合であっても、PMailServer2 は処理の高速化の為、その内容を出力します。
リターン（エラー）メール
SMTP経由で送信
チェックを入れることによりリターン（エラー）メールを SMTP 経由でローカルユーザーに送信します。
チェックが入っていない場合はメールボックスに直接生成されます。
エラーメールの転送（フォワード）を行いたい場合などに利用します。特に必要の無い場合はチェックを入れないで下さい。
ローカル以外にも送信 (PMS2のみ)
PMailServer2 は原則としてローカルアドレス以外にエラーメールを送りませんが、このオプションを有効にすることにより、送信者のアドレスがローカルユーザーで無い場合でもエラーメールを送るようになります。
主に中継サーバーにエラーメールを送らせたい場合に利用します。
エラーメールを送るアドレスはプロトコル上で指定されたメールアドレスとなります。
エラーメールの書式は PMailServer2 のエラーメールと同一です。
DSN形式で送る (PMS2のみ)
エラーメールに Delivery Status Notification(配信状態通知)を添付します。
DSN には、RFC3464 に従って、配信でエラーが発生した状況が記録されます。
（原則として、エラーメールのみに対して処理が行われますので、正常に送信ができた場合は、DSN は返って来ません）
DSNにオリジナルの添付 (PMS2のみ)
エラーメールが送られる際に、送信を行った元のメールを添付してエラーメールを返します。
送信サイズの制限を行っていない状態で、大きな添付ファイルを送った際にエラーになりますと、そのままのメールを受信することになりますので注意して下さい。
送信アドレス
未指定を指定した場合はメールヘッダ中の「Return-Path」「From」共に空欄として「<>」が設定されます。(*1)（デフォルト動作）
送信アドレスを指定した場合は、指定されたアドレスが「Return-Path」「From:」に設定されます。
(*1) エラーメールを SMTP経由で送信する設定を行っている場合、PMailServer2 の SMTP側の設定によって、Return-Path と From が書き換えられる場合があります。同じく SMTP側の設定により、メールヘッダにいくつかのヘッダが追加される場合もあります。
原則として、PMailServer2 はエラーメールをローカルアカウントへのみ送信を行いますが、エラーメールに対して処理を行いたい場合、error_addon.txt(Pro版のみ)をご利用になられる場合に、メールアドレスが指定されている必要がある場合に設定します。
ドメイン別送信アドレスを指定
マルチドメインで運用を行っている場合に、ドメイン別に上記の送信アドレスを指定する場合に利用します。
編集ボタンをクリックすると下記の画面が表示されます。
リストの左側をクリックし各ドメインに対応した送信アドレスを入力します。
メールアドレスが入力されている場合は、入力されたメールアドレスが送信アドレスとなります。
未入力の場合は、上記の送信アドレスが指定されます。(送信アドレスが未設定の場合は、空メール（システム）になり、指定されている場合は、送信アドレスに指定されたメールアドレスが適用されます。
ローカル外受信
中継設定などを行っている場合に送信者のメールアドレスがローカルアドレスで無い場合に、代わりにエラーメールを受け取るローカルのメールアドレスを指定します。
未指定の場合に送信者がローカルユーザーで無い場合はエラーメールはロストします。サーバ全体で一つだけ指定ができます。
PMailServer2 は仕様上エラーメールを外部に配信することをしません。
エラー件名
PMailServer2 がユーザーに対して発行するリターン（エラー）メールの件名を設定します。
デフォルトは「Mail Transfer ERROR!」です。日本語を設定することも可能です。
ペンディングタイミング
PMailServer2 がユーザーに対して発行するペンディングメールの送信タイミングを選択します。
タイミングは、MTA 再送カウンタで指定されている数値のいずれか１つです。(数値１に対して約２秒。送信は１回のみ）
-1 を指定した場合は、ペンディングメールを送りません。
ペンディング件名
ペンディングメールの件名を設定します。
外部への送信を禁止
イントラネット用に構築した場合などで外部にメールの配信が行われると困る状況の際にお使い下さい。
外部への送信を禁止にした場合、外から中へのメール、中から中へのメールの配信は行われますが、中から外への配信は全て拒否されます。
Webmail から送信した場合、送信できた旨が表示されますが MTA の段階で遮断しています。
応答が無い場合も次の MX を参照する(PMailServer2 のみ)
PMailServer2 はデフォルトの動作（チェック無し）で、MTA に接続が出来なかった場合は次の MTA を参照し、接続が出来たがなんらかのエラーが発生した場合は、再送信処理を行うようになっています。
滅多にありませんが、稀に Proxy や Firewall 自体は生きているが、その先のサーバが停止している場合、接続はするが MTA 自身とは通信ができない。というケースがありますが、このオプションを有効にした場合、「接続が出来たが応答が無かった場合、再送処理をせずに次に MTA があればそちらに接続する」ようになります。
DNS の応答が無い場合も再送処理(PMailServer2 のみ)
PMailServer2 はデフォルトの動作（チェック無し）で、配信時に DNS を参照し、応答が無い場合又は登録されていない場合は再送処理をせずに即座にエラーメールとして処理を行います
このオプションを有効にした場合、エラー処理とせず再送処理を行い、再送処理でも配信が出来なかった場合にエラーメールとして処理を行うようになります。
localhost への同時接続数(PMailServer2 のみ)
MTA がローカルホストへ同時に接続する最大数を設定します。0 で制限を行いません。
通常は制限をする必要はありませんが、NIC や CPU の性能が低い場合、サーバーの負担を軽減することができます。
ただし、その分配信速度は低下します。
ロストメールの保存
MTA が配信、又は転送を行う際に、配信先で 4xx エラーが発生し再試行を試みても送信が出来なかった場合、又は 5xx エラーが発生したメールを lost フォルダに保存する設定です。
imd をセットで保存
eml だけでは無く、imd ファイルもセットで保存を行います。
eml / imd をセットで Spool フォルダに戻すことにより再送信することができます。
指定アカウントへ通知
ロストメールが発生した場合、指定アカウントに通知を行います。
この通知メールは、「リターンメールの SMTP 経由で送信」の設定に関わらず SMTP を経由せずに直接メールボックス内に生成されます。
MTA で処理を行う際に、SMTP(Webmail含む）とメーリングリストの配信でどちらを優先するかを指定します。
通常
優先度を設定しません。MTA が検知した順番に配信処理が行われます。
SMTP/Webmail優先
SMTP(Webmail)から送信されたメールが優先的に配信処理されます。
メーリングリスト優先
メーリングリストが配信するメールが優先的に配信処理されます。
メーリングリストを運用している場合に設定します。
特に多くの登録があるメーリングリストを運用している場合にメーリングリストのメールで配信処理が埋まり通常のメール処理が滞る場合があります。その場合には、SMTP/Webmail優先の設定にすることによりメーリングリストの配信中であっても通常のメールが優先して配信されるようになります。
（ただし、再配信処理が行われるメールが、更に優先されますので、必ずしも設定した通りの優先順位になるとは限りません。）
MTA で処理を行う際に、SMTP(Webmail含む）とメーリングリストの配信でどちらを優先するかを指定します。
通常
優先度を設定しません。MTA が検知した順番に配信処理が行われます。
SMTP/Webmail優先
SMTP(Webmail)から送信されたメールが優先的に配信処理されます。
メーリングリスト優先
メーリングリストが配信するメールが優先的に配信処理されます。
メーリングリストを運用している場合に設定します。
特に多くの登録があるメーリングリストを運用している場合にメーリングリストのメールで配信処理が埋まり通常のメール処理が滞る場合があります。その場合には、SMTP/Webmail優先の設定にすることによりメーリングリストの配信中であっても通常のメールが優先して配信されるようになります。
（ただし、再配信処理が行われるメールが、更に優先されますので、必ずしも設定した通りの優先順位になるとは限りません。）
MTA で配信処理を行う時刻をカンマとハイフンで指定します。
0-8 とした場合は 0時台から8時台の間 MTA 処理が行われます。
0-8,12,13,15-19とした場合は 0時台から8時台、12時台、13時台、15時から19時台に MTA 処理が行われます。
CPU負荷(PMailServer2 Pro版のみ)
サーバー機の CPU負荷(*1)がしきい値を超えた場合、MTA 処理を軽減させサーバー全体の負荷を下げることができます。
ただし、しきい値を超えた場合、MTA 処理速度を低下させる為、配信が若干遅くなります。
PMailServer2 の MTA はできる限り高速化している為、自サーバー内で永久ループが発生するような状況の場合（ローカルユーザー同士がフォワードを行ったり、自動返信を設定している場合など。それ以外に大量の配信処理が発生し、且つ対象が自サーバーである場合）サーバーのスペックにもよりますが、サーバー機の CPU パワーを食い尽くし、場合によってはサーバーがフリーズ状態になる場合があります。
この状態になりますとコンソールからの操作も非常に重くなり、リモートなどの場合は接続もままならない状態になります。
(*1)CPU負荷は全コアの平均値(4コアである場合は 4コアの負荷の平均値)となりますので、PMailServer2 以外のソフトウェアによる負荷であっても、制御が行われます。
上記図は、意図的に永久ループを発生し自サーバーへ大量の配信が行われている状況です。
4コアCPU の平均負荷が 70%から90% を示しており、最低ラインも 50%を超える高止まりしている状況になっています。
上記図は、同じ状況で、CPU負荷が 80% を超えた場合にリミッターを ON にした設定です。
上限は同じですが、高止まりはしていない状況になっています。
CPU負荷がしきい値を下回った状態で本来の処理に戻り、再度上回った場合はリミットがかかるようになります。
常時遅くなる訳では無く、負荷が高まった場合にのみ制限がかかるようになっていますので、大量の負荷がかかっていない状態であれば配信速度の低下は起こりません。
Spool クリーンアップ(PMailServer2 のみ)
Spool フォルダになんらかの原因(*1)で、eml のみ 又は imd のみのファイルが存在した場合、該当するファイルのタイムスタンプと比較し、指定時間経過後に削除を行います。
(*1) 頻度は低いですが OS の Explorer や Shellエクステンションやアンチウィルス等のソフトが該当ファイルにアクセスしたタイミングとサーバー本体のアクセスが重なった場合、片方のみが削除され、もう片方が残ってしまう場合があります。これはファイルオープンの仕様上避けられません。
Version 2.28b より削除を行う条件が変更となりました。
MTAウェイト(PMailServer2 のみ)
Spool フォルダにある配信用の eml ファイルを確認する間隔を設定します。通常は変更する必要はありません。
主に配信頻度（速度ではありません）を上げる場合にチューニング用に設定します。
特に大量のメールを配信しない場合に設定を変更すると無駄に CPU パワーを使います。
排他的処理のウェイトを解除する
特定の仮想環境下で MTA に不具合が生じた為、対策として入れてあるウェイトですが、対策が必要でない環境の場合、パフォーマンスを大きく下げますので、大量にメールを配信する場合で、更に配信頻度を上げる必要がある場合にのみウェイトを解除して下さい。
MTA強制再起動(PMailServer2 のみ)
なんらかの理由(*1)により MTA の特定のスレッドが指定した時間終了をしなかった場合、該当スレッドの再起動を行います。
(*1) 現在確認されている状況としては STARTTLS for MTA で極稀に TLS通信の初期化及びハンドシェイク中に schannel.dll から応答が返って来ないケースが認められます。
該当スレッドの再起動は最初正常な手続きにより終了を試みますが、スレッド自体が完全にフリーズしている場合は、サーバー本体よって強制終了されその上で初期化されます。スレッド中で確保されたメモリは破棄されない可能性があり（いわゆるメモリリーク状態）PMailServer2 側以外の原因によってフリーズが発生していた場合は、同じ処理が繰り返される可能性があります。
指定アカウントへ通知でアカウント（メールアドレスではありません）を指定することにより、スレッドの再起動が行われたことを管理者に通知可能になっていますので、管理者は必要に応じて原因の調査及びサービスの再起動を行うことを推奨します。MTAプロセス強制再起動(PMailServer2 のみ)
マルチプロセスモードの際に MTA に指定されているプロセスが停止した場合に、MTAが割り当てられているプロセスのみの強制再起動を行います。
この設定を有効にした場合、Data フォルダに mtacheck.dat というファイルが生成されます。
このファイルには MTA のチェック用のタイムスタンプが書き込まれ、このタイムスタンプが更新されてなくなってから一定時間経過後にプロセスの再起動を行います。
（原始的な方法ですが、プロセス自体に異常が発生した場合、プロセス内では処理できなくなる可能性がある為です）
またプロセスが再起動された場合、指定アカウントへ通知を行います。
Trashフォルダ
SMTPフィルタにて処理されTrashフォルダに保存されたメールの数とファイルの消去を行います。
Trashフォルダを開いてエクスプローラから削除しても同じですが、ファイル数が多い場合にゴミ箱に捨てる処理に時間がかかる為、直接ファイル消去を行います。
Cacheフォルダ
指定した日付以前のcacheフォルダの中身を削除します。
（ゴミ箱に入れずに直接削除します）
SMTPフィルタデータの更新
data フォルダ内の serverfilter.txt を指定したファイルで更新を行います。
serverfilter.txt はサーバ起動時に読み込みが行われる為、更新にはサーバの再起動が必要となります。その為「サーバの停止」「ファイルの更新（上書き or 変更）」「サーバの起動」の順番で更新を行う必要がありますが、その手順を一括して行う為の機能です。
また、Pro版で「フィルタの学習機能」を利用されている場合、サーバに読み込まれたデータで常時順番の更新が行われる為、サーバ起動中に serverfilter.txt を更新してもメモリ中のフィルタデータで更に上書きが行われます。この際にサーバ側が自動更新を行っている為、serverfilter.txt を手動で開いた場合サーバ側からフィルタデータの更新が出来なくなる場合があります。
このような場合はこちらのメニューから更新を行うことによりサーバの停止時間を最短にし、かつ安全に更新を行うことができます。
Webmail / IMAP4 フォルダ処理
PMailServer2 の Webmail や IMAP4 のフォルダは仮想フォルダ形式を取っていますので、親フォルダを削除しても、その子フォルダは削除されません。（親が無くなった時点でルート上に配置されます）
本オプションで、親フォルダを削除した場合の子フォルダの削除の扱いを変更することができます。
サーバー状況は MTA の配信状況のレポートメールを送る機能です。
送信先アドレス
レポートの送信先のメールアドレスを指定します。
MTA状況
「指定時間毎に配信レポートを送信する」にチェックを入れている場合に、1時間単位で MTA の配信状況のレポートを指定した宛際に送信を行います。
配信レポートは、xx時00分の１時間単位で計測が行われます。(例外として初回起動時のみ次に xx時00分に送信されます）)
サービスの開始が 12:30 だった場合、１回目は 12:30 〜 14:00 までの 1.5時間分の結果が送られ、その後１時間ごとに送られます。
MTA警告
「1時間辺りのメール数が指定数を超えたら警告」にチェックを入れている場合に、メール計測範囲は配信レポートと同様です。
ただし、指定数に達した時点で即時送信が行われます。
送信を行った時点で数量はリセットされ、再度同一時間内に指定数に達した場合は再度送信が行われます。