メール認証・TLS・ポート

認証は利用者が誰かを確認し、TLSは通信内容と資格情報を経路上の盗聴・改変から保護する。両者は別の機能である。

SMTP AUTHとDovecot SASL

SMTP AUTHは、メールクライアントがPostfixへ送信者としてログインするためのESMTP拡張である。認証された利用者には、自サーバーのローカルドメイン以外へメールを中継する権限を与えられる。

認証したユーザー名と、SMTPのMAIL FROMで指定するエンベロープ送信元は別の情報である。SMTP AUTHに成功しただけでは、Postfixはその利用者が指定した送信元アドレスを所有しているか確認しない。両者を一致させる場合は、smtpd_sender_login_mapsで利用者と送信元を対応付け、reject_authenticated_sender_login_mismatchで不一致を拒否する。メッセージヘッダーのFrom:はさらに別の情報である。

SASL（Simple Authentication and Security Layer）は、SMTPやIMAPなどのプロトコルから認証方式を利用するための枠組みである。SASL自体がユーザーデータベースを持つわけではない。

この構成ではPostfixがSMTP AUTHの入口となり、認証処理をDovecot SASLへ渡す。DovecotはPAMまたはLDAP passdbでパスワードを検証し、成功または失敗をPostfixへ返す。

flowchart TD
    C["メールクライアント"]
    P["Postfix Submission"]
    D["Dovecot Auth"]
    DB["PAMまたはLDAP passdb"]
    R["SMTP応答<br/>235成功または535失敗"]

    C -->|"AUTH PLAIN / LOGIN"| P
    P -->|"UNIX socketで資格情報を渡す"| D
    D -->|"ユーザー名とパスワードを検証"| DB
    DB -->|"認証結果を返す"| R

PLAINとLOGINはパスワードを安全に暗号化する方式ではない。Base64は文字表現の変換であり暗号化ではないため、TLSなしでは資格情報を経路上から復元できる。

SMTP AUTHを使わない構成

SMTP AUTHを使わなくても、PostfixはTCP 25で自サーバーが担当するドメイン宛てのメールを受信できる。送信側MTAは受信側サーバーの利用者アカウントを持たないため、サーバー間SMTPでは認証を要求しないのが通常である。

SMTP AUTHなしの構成では、Postfix向けのDovecot認証ソケットとTCP 587のSubmissionサービスを使用しない。中継制御は次の順序で評価する。

smtpd_relay_restrictions = permit_mynetworks, reject_unauth_destination

permit_mynetworksはmynetworksに含まれる接続元へ中継を許可する。reject_unauth_destinationは、それ以外の接続元から自サーバーが担当しないドメインへの中継を拒否する。自サーバーが担当するmydestination宛てのメールは、未認証の接続元からでも受信できる。

信頼するクライアントネットワークをmynetworksへ追加すると、そのネットワーク内の端末はSMTP AUTHなしで外部ドメインへ中継できる。接続元アドレスだけで許可を判断するため、管理下にあるネットワークだけを指定する。

SMTP AUTHを使わないことと、IMAPのログイン認証をなくすことは別である。Dovecotは、各利用者のメールボックスを他の利用者から保護するため、IMAP接続では引き続きユーザー認証を行う。

Submissionとサーバー間SMTP

TCP 25は主にMTA同士がメールを配送するSMTPポートである。インターネット上のMTAは事前に共通の利用者アカウントを持たないため、通常はSMTP AUTHを要求しない。宛先ドメイン、DNS、接続元ポリシーなどで受信可否を判断する。

TCP 587はMUAが自分の送信サーバーへメールを提出するSubmissionポートである。利用者をSMTP AUTHで認証し、認証済み利用者に外部ドメインへの中継を許可する。

Postfixではmaster.cfのSubmissionサービスにだけsmtpd_sasl_auth_enable = yesを上書きする。これによりDovecot認証サービスが停止しても、TCP 25のサーバー間受信をSMTP AUTHへ依存させずに済む。

TLSが保護する通信

TLSは接続ごとに適用される。メールが通るすべての区間へ一度に適用される設定ではない。

flowchart TD
    MUA1["送信者のMUA"]
    MTA1["送信側Postfix"]
    MTA2["受信側MTA"]
    MUA2["受信者のMUA"]
    IMAP["Dovecot IMAP"]

    MUA1 -->|"Submission STARTTLS"| MTA1
    MTA1 -->|"SMTP STARTTLS"| MTA2
    MUA2 -->|"IMAP STARTTLS / Implicit TLS"| IMAP

SubmissionのTLSは、MUAからPostfixまでのメッセージとSMTP AUTH資格情報を保護する。SMTPのTLSはPostfixから次のMTAまでを保護する。IMAPのTLSはMUAからDovecotまでのパスワード、メール一覧、本文、操作内容を保護する。

ある区間でTLSを使っても、別の区間が自動的に暗号化されるわけではない。さらにTLSは通信経路を保護するもので、Maildirに保存されたファイル自体を暗号化する設定ではない。

STARTTLSとImplicit TLS

STARTTLSは、平文プロトコルとして接続した後に、同じ接続をTLSへ切り替える方式である。

SMTP SubmissionではTCP 587へ接続し、EHLO応答のSTARTTLSを確認してからTLSハンドシェイクを行う。Postfixのsmtpd_tls_security_level = encryptをSubmissionへ設定すると、STARTTLSを行わないクライアントからメールを受け付けない。

IMAPではTCP 143へ接続し、STARTTLSコマンドでTLSへ切り替える。Dovecotのssl = requiredは、STARTTLSを行わないIMAPセッションでのログインを許可しない。

Implicit TLSはTCP接続直後からTLSハンドシェイクを始める方式である。IMAPではTCP 993を使う。Dovecotのinet_listener imapsにssl = yesを設定し、TCP 993をImplicit TLS用として待ち受ける。

Opportunistic TLSと必須TLS

サーバー間SMTPのTCP 25では、相手MTAがSTARTTLSを提供すれば暗号化し、提供しなければ平文で配送を続けるOpportunistic TLSが一般的である。

Postfixを受信SMTPサーバーとして動かすsmtpd_tls_security_level = mayは、STARTTLSを提供するが必須にはしない。Postfixを送信SMTPクライアントとして動かすsmtp_tls_security_level = mayは、相手がSTARTTLSを提供すれば利用する。

mayは、相手がSTARTTLSを提供しない場合に平文配送を許す。相手MTAの証明書を配送可否の条件として検証する設定でもないため、受動的な盗聴への対策にはなるが、STARTTLSを取り除く能動的攻撃や相手の真正性までは保証しない。TLS必須化と証明書検証が必要な配送先には、配送先ごとのTLSポリシーを設定する。

公開MXのTCP 25へ一律にencryptを設定すると、STARTTLSを使えない相手MTAとの配送が失敗する。一方、利用者専用のSubmissionでは接続条件を管理できるため、encryptでTLSを必須にする。

auth_allow_cleartext

Dovecotのauth_allow_cleartextは、PLAINやLOGINのように平文パスワードを必要とする認証方式を、TLSで保護されていない接続で許可するか決める。

TLSなし構成ではauth_allow_cleartext = yesが必要である。これを設定しなければ、auth_mechanisms = plain loginを有効にしても、暗号化されていないIMAP接続で認証が拒否される。認証に成功することとパスワードが安全に送られることは別であり、この構成ではパスワードを盗聴できる。

TLSあり構成ではauth_allow_cleartext = noとssl = requiredを組み合わせる。前者は暗号化前のPLAIN・LOGIN認証を拒否し、後者はIMAPセッション全体にTLSを要求する。

Postfix側ではSubmissionにsmtpd_tls_security_level = encryptを設定する。Dovecotのauth_allow_cleartextはDovecotが受けるネットワーク接続を制御する設定であり、PostfixのSubmission接続を暗号化する代わりにはならない。

ポート一覧

TCPポート	プロトコル	接続する側	TLSあり構成
25	SMTP	他のMTA	STARTTLSを任意で提供する
587	SMTP Submission	メールクライアント	STARTTLSを必須にする
143	IMAP	メールクライアント	STARTTLS後にログインする
993	IMAPS	メールクライアント	接続直後からTLSを使う

PostfixとDovecot間のSASL・LMTPは同一ホスト内のUNIXドメインソケットを使うため、TCPポートは開かない。

証明書と名前の検証

PostfixとDovecotには、mail.example.comをSANに含むサーバー証明書と対応する秘密鍵を設定する。クライアントは証明書の署名チェーン、有効期間、接続先ホスト名を検証する。

サーバーはサーバー証明書に続けてIntermediate CA証明書を送る。Root CA証明書はクライアントのTrust Storeへ登録する。証明書の作成とチェーンはServer Certificateの作成を参照する。

PostfixとDovecotは同じホスト名で同じ証明書を利用できるが、各サービス用ディレクトリへ必要な権限で配備する。秘密鍵はroot所有・600とし、サービス起動時にroot権限を持つ親プロセスだけが読み込む。