Postfix は Web プロキシではなくメールリレーに向ける

relayhost = proxy.example.net:3128 はもっともらしく見えるが、両端が会話を始めた途端に破綻する。Postfix は SMTP の相手を期待する。3128 の Web プロキシは HTTP プロキシ要求を期待する。どちらも待っていた会話を得られない。

ネットワークが承認済みのメールリレーを提供しているなら、代わりにその SMTP サービスを設定する。典型的な形は次のとおり。

relayhost = [smtp-relay.example.net]:587

ホスト名とポートは例である。角括弧はそのリレー名に対する MX 検索を抑止する。HTTP CONNECT、TLS、認証を追加するものではない。リレーが要求する submission、SASL、TLS の設定は別途行う。

2 つのアカウントが異なることもある。Web プロキシが受け付けたパスワードが自動的にメール送信の資格情報になるわけではなく、リレーは接続を受け入れた後でも送信者を拒否できる。

承認された唯一の経路がトンネルならどうするか

HTTP プロキシは、宛先とポートを許可していれば SMTP を CONNECT 経由で 運べる。だからといって任意の SMTP クライアントが CONNECT を生成するわけではない。curl のようなツールには明示的なプロキシトンネルのオプションがあるが、Postfix の relayhost を設定するのは別のインターフェースだ。

固定の SSH 転送や専用のローカル転送アダプターは、承認済みの SMTP サービスをローカル TCP エンドポイントとして公開できる。その設計では Postfix がエンドポイントと SMTP で話し、アダプターがもう一方の転送を担う。範囲を限定し、想定するメールサーバーの TLS アイデンティティを保つこと。接続先を loopback に変えると名前ベースの証明書ポリシーに影響しうる。

ネットワーク運用者が提供するサービスがメールリレーなら、そちらを選ぶ。キュー、送信者ポリシー、配送エラーに SMTP を理解する居場所を与える。Web プロキシの設定だけでは、これらのメール機能を一つも提供しない。