用語辞典・メール

メールサーバー

メールサーバーとは

メールサーバーは、メールの送信、中継、受信、保存などを行うサーバーの総称です。一台の決まった種類ではなく、投稿受付、転送、最終配送、保管、端末への提供という複数の役割をまとめた呼び方です。

英語では役割に応じてmail server(メール・サーバー)、MTA、MSA、MDA、メッセージ保存などと呼び分けます。一つの製品やクラウドサービスが複数役を兼ねることも、役ごとに多数の機器へ分かれることもあります。

メールアプリが「送信済み」と表示するのは、多くの場合、投稿先サーバーがメッセージを受け取った段階です。相手の受信箱への保存や閲覧完了までを保証しません。

利用者の投稿を受け、別のサーバーへ中継し、宛先側で受理して受信箱へ保存する送信・中継・保存・端末同期は別の役割として設計できる
送信者の端末から投稿受付サーバー、中継サーバー、受信サーバー、メールボックス保存庫を経て受信者の端末へ届くメールサーバー群のピクトグラム図解
図1途中のサーバーは、次の相手が一時的に受け取れなければキューへ保存し、規則に従って再試行します。

メール基盤を五つの役割へ分ける

同じ「メールサーバー」という設定名の裏側で、誰から受け、誰へ渡すかを区別する障害調査では、最後に成功した役割と最初に失敗した役割を探す
MSA投稿を受け付ける

利用者のメールアプリを認証し、送信ポリシーを確認して転送へ渡す

MTAサーバー間を中継する

宛先ドメインをDNSで調べ、SMTPで次のMTAへ責任を引き渡す

MDA最終宛先へ配送する

ローカルパート、別名、フィルターを評価し、対象の保存領域へ入れる

Storeメッセージを保管する

フォルダー、既読、検索、容量、保持期間を管理する保存層

Access端末へ提供する

IMAPやPOP3、Webメールなどで利用者が受信内容を取得・同期する

Gateway境界で検査・変換する

迷惑メール、ウイルス、暗号化、規則適用を行い、次の役割へ渡す

図2略称は論理的な役割です。小規模環境では同じホストがすべてを兼ね、大規模環境では一役を多数のサーバーが分担します。

メールアプリは、投稿と受信で異なるサーバー機能を使う

送信時はSMTP投稿サーバーへ接続し、通常はSMTP AUTHで利用者を認証します。受信・同期時はIMAPPOP3、Web APIなどを使います。

同じホスト名、ユーザー名、パスワードを使うサービスでも、ポート、暗号化、操作、エラーは別です。「受信できるから送信設定も正しい」とは限りません。

投稿受付とサーバー間配送は、信頼条件が違う

利用者の端末からの投稿は、契約者だけに中継を許す必要があります。MSAは認証、送信元制限、サイズ、送信量、形式を確認します。一般にsubmission用サービスを使い、認証済みメッセージを配送網へ入れます。

サーバー間SMTPは宛先ドメインのMXへ接続し、世界中の送信サーバーからメールを受けます。誰にでも任意の第三者宛中継を許すopen relay(オープン・リレー)は迷惑メールに悪用されるため、宛先・送信元・認証で中継範囲を制限します。

SMTPは一つのトランザクションごとに責任を引き渡す

送信側サーバーはMAIL FROM、RCPT TO、メッセージデータを順に提示します。受信側が最終成功応答を返すと、そのサーバーが次の配送または保存の責任を受け取ります。

成功応答前に接続が切れた場合、送信側は再試行します。応答が送られたのに送信側へ届かなければ、同じメッセージが再送され重複する可能性もあります。Message-IDだけでなく、配送ログと時刻を合わせて判断します。

一時失敗はキューへ残し、恒久失敗は返送を作る

相手サーバーの停止、接続不能、4xx応答などは一時失敗としてキューに保持し、間隔を空けて再試行します。宛先不存在や明確な5xx応答は恒久失敗として扱い、元のエンベロープFromへ配送状態通知を返します。

返送先が空のnull逆方向経路である配送状態通知へ、さらに返送を重ねません。再試行期間や警告通知は運営ポリシーで異なるため、一時的な遅延と最終不達を分けます。

MXは入口を案内するが、内部構成までは公開しない

MXレコードは外部が接続するメール交換ホストを示します。その背後に負荷分散、迷惑メール検査、複数MTA、保存サービスがあっても、DNSから全体構成は分かりません。

MXの優先度は配送候補の順序であり、サーバーの性能順位ではありません。すべての候補が正しい宛先を扱い、認証・TLS・ログ・時刻同期を一貫して運用できる必要があります。

暗号化は区間ごとで、エンドツーエンド暗号化とは限らない

STARTTLSなどのTLSは、端末と投稿サーバー、MTA同士、端末とIMAPサーバーという接続区間を保護します。各サーバーでは検査、保存、転送のため平文相当を扱う場合があります。

一つの区間だけ暗号化されても、配送経路全体の必須暗号化は保証されません。証明書検証、暗号化必須ポリシー、保存時暗号化、メッセージ自体の暗号化を別々に評価します。

調査では、識別子と時刻を役割ごとにつなぐ

メールアプリの送信時刻、投稿サーバーの待ち行列ID、Message-ID、各Receivedヘッダー、最終応答、受信箱への保存時刻を対応させます。Receivedは通過したサーバーが上へ追加するため、通常は下から上へ時系列をたどります。

送信・投稿・中継・受信・保存・端末同期のどこまで成功したかを分け、アドレス、IP、認証情報、内部名を伏せた上で必要なログだけ共有すると安全です。

役割と配送の確認資料:RFC 5598「Internet Mail Architecture」RFC 5321「SMTP」RFC 6409「Message Submission for Mail」RFC 9051「IMAP4rev2」

関連用語