Linuxサーバー

SMTP認証(SMTP AUTH)をPostfixに導入するためマニュアルを読む

更新日:

自分で建てたPostfixにSMTP認証(SMTP AUTH)を導入しようと思い、 持っている本やインターネットで調べてみたが、いまいち全体像が掴めない。

SMTP認証は文字通りメールを送信するときに認証を行うが、 認証にはSASL(Simple Authentication and Security Layer)が使われる。 SASLはある特定の認証機能を指すものではなく、アプリケーションから様々な認証機能が使えるようにするためのフレームワークである。 SASLとそれを通じて幾つかの認証方式が使えることためわかりづらいのだと思う。

ここはやはりPostfixのマニュアルを読むしかないと思い、 そしてせっかく読むのなら理解した内容を残しておこうと記事にしました。 皆さんの参考にもなれば幸いです。

Postfixには多くのREADMEファイルが付属しています。 私の環境でREADMEファイルは /usr/share/doc/postfix-バージョン番号/README_FILES ディレクトにインストールされています。 今回読むのはSASL_READMEファイル(タイトルは『Postfix SASL Howto」)です。

どのようにPostfixがSASL認証を使用するか

では、実際にマニュアルの記述についてみていきます。 最初の注意書きはサラッと読んで次の部分から見ていきましょう。

How Postfix uses SASL authentication

SMTP servers need to decide whether an SMTP client is authorized to send mail to remote destinations, or only to destinations that the server itself is responsible for. Usually, SMTP servers accept mail to remote destinations when the client's IP address is in the "same network" as the server's IP address.

SMTP clients outside the SMTP server's network need a different way to get "same network" privileges. To address this need, Postfix supports SASL authentication (RFC 4954, formerly RFC 2554). With this a remote SMTP client can authenticate to the Postfix SMTP server, and the Postfix SMTP client can authenticate to a remote SMTP server. Once a client is authenticated, a server can give it "same network" privileges.

Postfix does not implement SASL itself, but instead uses existing implementations as building blocks. This means that some SASL-related configuration files will belong to Postfix, while other configuration files belong to the specific SASL implementation that Postfix will use. This document covers both the Postfix and non-Postfix configuration.

You can read more about the following topics:

* Configuring SASL authentication in the Postfix SMTP server
* Configuring SASL authentication in the Postfix SMTP/LMTP client
* Building Postfix with SASL support
* Using Cyrus SASL version 1.5.x
* Credits

ここに書いてあるのをざっくり要約すると次の通りです。

  • SMTPサーバは、SMTPクライアントがリモートの宛先にメールを送るために認証されているか、サーバ自身が管理する宛先だけにするか決定する必要がある。 一般にPostfixは、Postfixと「同じネットワーク」のクライアントに対しては、リモートの宛先へのリレーを許可する。
  • SASL認証で認証されたクライアントには「同じネットワーク」にある クライアントと同等な特権を与えることができる。
  • Postfix自身はSASL機能を実装してないが、構成部品として、すでにあるSASL実装を使う。 いくつかのSASL関係の設定ファイルはPostfixに含まれる。

ここで「同じネットワーク」と言っているは main.cfのmynetworksパラメータのことを言っているのだろう。

そして詳しく書いてあるトピックがリストされている。 続けてPostfixサーバの設定についての 「Configuring SASL authentication in the Postfix SMTP server」を読んでいこう。

Postfix SMTPサーバーでのSASL認証設定

Configuring SASL authentication in the Postfix SMTP server

As mentioned earlier, SASL is implemented separately from Postfix. For this reason, configuring SASL authentication in the Postfix SMTP server involves two different steps:

* Configuring the SASL implementation to offer a list of mechanisms that are suitable for SASL authentication and, depending on the SASL implementation used, configuring authentication backends that verify the remote SMTP client's authentication data against the system password file or some other database.

* Configuring the Postfix SMTP server to enable SASL authentication, and to authorize clients to relay mail or to control what envelope sender addresses the client may use.

Successful authentication in the Postfix SMTP server requires a functional SASL framework. Configuring SASL should therefore always be the first step, before configuring Postfix.

You can read more about the following topics:

* Which SASL Implementations are supported?
* Configuring Dovecot SASL

o Postfix to Dovecot SASL communication

* Configuring Cyrus SASL

o Cyrus SASL configuration file name
o Cyrus SASL configuration file location
o Postfix to Cyrus SASL communication

* Enabling SASL authentication and authorization in the Postfix SMTP server

o Enabling SASL authentication in the Postfix SMTP server
o Postfix SMTP Server policy - SASL mechanism properties
o Enabling SASL authorization in the Postfix SMTP server
o Additional SMTP Server SASL options

* Testing SASL authentication in the Postfix SMTP server

先ほど書かれていた通り、SASL実装はPostfixと別のコンポーネントなので、 SASL認証の設定には2段階の異なるステップが必要とある。 この2段階のステップの記載は次のようなものだ。

  • SASL認証に適したメカニズムのリストを提供するようにSASL実装を構成する。 リモートSMTPクライアントの認証データを、 システムのパスワードファイルやデータベースなどのデータで検証する認証バックエンドを構成する。
  • Postfix SMTPサーバでSASL認証を有効化し、 メールリレーのためにクライアントを認証するように、 またクライアントが使うエンベロープ送信者アドレスで制御するようにPostfix SMTPサーバを構成する。

ざっくり言うと、SASL実装の設定とPostfix自体の設定の2段階が必要ということのようだ。 そしてSASL実装の設定を最初にするとある。

どのSASL実装がサポートされているか?

Which SASL Implementations are supported?

Currently the Postfix SMTP server supports the Cyrus SASL and Dovecot SASL implementations.

Note

Current Postfix versions have a plug-in architecture that can support multiple SASL implementations. Before Postfix version 2.3, Postfix had support only for Cyrus SASL.

To find out what SASL implementations are compiled into Postfix, use the following commands:

% postconf -a (SASL support in the SMTP server)
% postconf -A (SASL support in the SMTP+LMTP client)

These commands are available only with Postfix version 2.3 and later.

ここはPostfixでどんなSASL実装がサポートされているか?ということが書かれている。 今のところPostfixで使用できるSASL実装としてはCyrus SASLとDovecot SASLの2つがある。

Postfixにコンパイルされ、実際に使えるSASL実装は次のコマンドで調べられるとのこと (2つ目の SMTP+LMTP client については今回は飛ばしていこう)。

% postconf -a (SASL support in the SMTP server)

実際に確認してみる。 私の環境ではCyrus SASLとDovecot SASLが使えるようだ

# postconf -a
cyrus
dovecot

世の中で多く使われているSASL実装は、調べた限りではCyrus SASLのようだ。 Cyrus SASLを使うことで特に不満はなさそうなので、 とりあえずCyrus SASLを理解することに集中する。 そのためDovecot部分は今回は読み飛ばしていこう。

Cyrus SASLの設定

Configuring Cyrus SASL

The Cyrus SASL framework supports a wide variety of applications (POP, IMAP, SMTP, etc.). Different applications may require different configurations. As a consequence each application may have its own configuration file.

The first step configuring Cyrus SASL is to determine name and location of a configuration file that describes how the Postfix SMTP server will use the SASL framework.

Dovecot部分を読み飛ばして行くと「Cyrus SASLを設定」というタイトルが見つかる。 ここからCyrus SASLの設定方法が書いてあるようだ。

Cyrus SASLフレームワークはSMTP以外のさまざまなアプリケーションからも使えること。 アプリケーションが異なれば、大抵は設定ファイルも異なるファイルになることが書いてある。

そしてCyrus SASLを設定する最初のステップは、 PostfixがSASLをどう使うかを記述した「設定ファイルの名前と場所」を決めること、とある。 名前と場所についてはこの後に説明されている。

Cyrus SASLの設定ファイル名

Cyrus SASL configuration file name

The name of the configuration file (default: smtpd.conf) is configurable. It is a concatenation from a value that the Postfix SMTP server sends to the Cyrus SASL library, and the suffix .conf, added by Cyrus SASL.

The value sent by Postfix is the name of the server component that will use Cyrus SASL. It defaults to smtpd and is configured with one of the following variables:

/etc/postfix/main.cf:
# Postfix 2.3 and later
smtpd_sasl_path = smtpd

# Postfix < 2.3
smtpd_sasl_application_name = smtpd

これが設定ファイルの名前の話だ。 ファイルの名前はデフォルトでsmtpd.confだが変更可能とある。 名前はPostfixがCyrus SASLに渡した値に.confを付け加えた値になるとのこと。

そしてPostfixが渡す値はCyrus SASLを使うサーバコンポーネントの名前で、 デフォルトはsmtpdで、Postfix 2.3以降は次のような変数で設定されるとある。

/etc/postfix/main.cf:
    # Postfix 2.3 and later
    smtpd_sasl_path = smtpd

実際にsmtpd_sasl_pathの値を調べてみるとデフォルトでsmtpdになっている。 つまりコンフィグファイルの名前は.confを加えたsmtpd.confということだ。 これは変更する必要はないだろう。

# postconf smtpd_sasl_path
smtpd_sasl_path = smtpd

Cyrus SASLの設定ファイルの場所

Cyrus SASL configuration file location

The location where Cyrus SASL searches for the named file depends on the Cyrus SASL version and the OS/distribution used.

You can read more about the following topics:

* Cyrus SASL version 2.x searches for the configuration file in /usr/lib/sasl2/.

* Cyrus SASL version 2.1.22 and newer additionally search in /etc/sasl2/.

* Some Postfix distributions are modified and look for the Cyrus SASL configuration file in /etc/postfix/sasl/, /var/lib/sasl2/ etc. See the distribution-specific documentation to determine the expected location.

Note

Cyrus SASL searches /usr/lib/sasl2/ first. If it finds the specified configuration file there, it will not examine other locations.

ここが設定ファイルの場所についての記述だ。 Cyrus SASLが設定ファイルを探す場所は、バージョンやOSで異なるかもしれないが大体は次のどちらかにあるみたいだ。 そして/usr/lib/sasl2/の方が優先されるらしい。

/usr/lib/sasl2/
/etc/sasl2/

調べてみると私の環境では/etc/sasl2/にあった。

# ls -l /etc/sasl2/smtpd.conf
-rw-r--r-- 1 root root 56  8月  6 09:24 /etc/sasl2/smtpd.conf

これでPostfixでCyrus SASLを使う時の設定ファイルがわかった。先に進もう。

PostfixとCyrus SASLとの通信

Postfix to Cyrus SASL communication

As the Postfix SMTP server is linked with the Cyrus SASL library libsasl, communication between Postfix and Cyrus SASL takes place by calling functions in the SASL library.

The SASL library may use an external password verification service, or an internal plugin to connect to authentication backends and verify the SMTP client's authentication data against the system password file or other databases.

The following table shows typical combinations discussed in this document:

authentication backendpassword verification service / plugin
/etc/shadowsaslauthd
PAMsaslauthd
IMAP serversaslauthd
sasldbsasldb
MySQL, PostgreSQL, SQLitesql
LDAPldapdb

Note

Read the Cyrus SASL documentation for other backends it can use.

Cyrus SASLのライブラリであるlibsaslはPostfixにリンクされ、 PostfixとCyrus SASLとの通信はSASLライブラリの関数呼び出しで行われる。

SASLライブラリは外部パスワード認証サービスや内部プラグインを使い、 これらはさらに認証バックエンドに接続される。 そして認証バックエンドはSMTPクライアントの認証データをシステムのパスワードファイルや データベースなどを使って検証する、とある。

つまり、次のような流れだ。なるほど、全体像が少しずつ見えてきた。

Postfix → libsasl → 外部認証サービスまたは内部プラグイン → 認証バックエンド

そしてこの文書で説明される、典型的な組み合わせが表に書いてある。

authentication backendpassword verification service / plugin
/etc/shadowsaslauthd
PAMsaslauthd
IMAP serversaslauthd
sasldbsasldb
MySQL, PostgreSQL, SQLitesql
LDAPldapdb

saslauthdが外部認証サービスと呼ばれているものだ。ここに記載はないがsaslauthdはデーモンでPostfixとは別に起動する必要がある。sasldb、sql、ldapdbが内部プラグインだ。

ここで紹介された組み合わせを1つずつ見ていこう。これはどのデータを使って認証するかを決めるために重要だ。

/etc/shadowは言わずと知れたOSアカウントのパスワードを暗号化して保存しているファイルだ。 したがってOSアカウントと同じデータで認証することになる。 これはつまり、認証されるユーザはOSアカウントを持っている必要もあるということになる。

PAMはUNIX系OSに内蔵されている認証システム(フレームワーク)だ。 PAM自体も様々な認証方式を選べたはずだ。 普通にOSアカウント(つまり/etc/shadow)使って認証もできたはずだし、 KerberosやLDAPも使えたはずだ。 つまり認証をさらにPAMに移譲すれば、PAMの認証方式が使えるようになると思われる。 しかし、PAM自体の設定やその裏の認証環境も構築する必要になってくるので大変そうだ。

したがってPAMを使う理由としては、既に他でPAMを使ったユーザ認証を行っていて、 Postfixの認証もそれらに統合したい場合や、PAM自体の機能も併せて使いたい場合などになろうか。

IMAP serverを使う方法は、IMAP serverにログインできれば認証に成功する方式だ。 つまり認証はIMAPのユーザアカウントを使うということだろう。 IMAP serverを使っている、あるいは使う予定があるなら、検討に値するかもしれない。

sasldbプラグインやsqlプラグインを使う方式は、認証データをデータベースに保持する方法だ。 これらは他のアカウント(OSアカウントやIMAPのアカウント)が必ずしも必要ではないので アカウントの保守がしやすいかもしれない。

ldapdbはLDAPを使って認証するのだろう。別途LDAP環境を構築する必要がありそうだ。

さて、やっと認証方法の組み合わせについてだいぶわかってきたので、 どのような認証バックエンドを使うかある程度絞ってみよう(全てを読むのは大変だ)。 今回は自分用のメールサーバを建てるので、PAMやLDAPのように少し面倒そうなのはやめておこう。 IMAP serverも建てるかどうかわからないの外す。

残るは/etc/shadow、sasldb、MySQL、PostgreSQL、SQLiteだ。 ここからはこれらについて重点的に読んでいこう。

saslauthd - Cyrus SASLパスワード認証サービス

saslauthd - Cyrus SASL password verification service

Communication between the Postfix SMTP server (read: Cyrus SASL's libsasl) and the saslauthd server takes place over a UNIX-domain socket.

saslauthd usually establishes the UNIX domain socket in /var/run/saslauthd/ and waits for authentication requests. The Postfix SMTP server must have read+execute permission to this directory or authentication attempts will fail.

Important

Some distributions require the user postfix to be member of a special group e.g. sasl, otherwise it will not be able to access the saslauthd socket directory.

The following example configures the Cyrus SASL library to contact saslauthd as its password verification service:

/etc/sasl2/smtpd.conf:
pwcheck_method: saslauthd
mech_list: PLAIN LOGIN

Important

Do not specify any other mechanisms in mech_list than PLAIN or LOGIN when using saslauthd! It can only handle these two mechanisms, and authentication will fail if clients are allowed to choose other mechanisms.

Important

Plaintext mechanisms (PLAIN, LOGIN) send credentials unencrypted. This information should be protected by an additional security layer such as a TLS-encrypted SMTP session (see: TLS_README).

Additionally the saslauthd server itself must be configured. It must be told which authentication backend to turn to for password verification. The backend is selected with a saslauthd command-line option and will be shown in the following examples.

Note

Some distributions use a configuration file to provide saslauthd command line options to set e.g. the authentication backend. Typical locations are /etc/sysconfig/saslauthd or /etc/default/saslauthd.

Postfixとsaslauthdとの間の通信はUNIXドメインソケットで行われる。 saslauthdは通常、/var/run/saslauthd/の中でUNIXドメインソケットを確立し認証要求を待ち受ける。 Postfixはこのディレクトリに読み込みと実行の権限がないと認証に失敗する。

一部のディストリビューションでは、ユーザpostfixが特別なグループ(例えばsasl)のメンバであることを要求する。 そうしなければ、saslauthdのソケットディレクトリにアクセスできない、とある。

そして、パスワード認証サービスとしてsaslauthdを使うCyrus SASLライブラリの設定例が書いてある。

/etc/sasl2/smtpd.conf:
    pwcheck_method: saslauthd
    mech_list: PLAIN LOGIN

次に重要と題された2つの記述が続く。これらは本当に重要だ。

  • saslauthdを使う場合、mech_listにPLAINやLOGIN以外を指定してはいけない。
    saslauthdはこれら2つのメカニズムだけ扱うことができ、クライアントが他のメカニズムを選ぶと認証は失敗する。
  • プレーンテキストメカニズム(PLAIN、LOGIN)は資格情報を暗号化しないで送る。
    TLS暗号化されたSMTPセッションのような追加のセキュリティレイヤーによって、その情報を保護すべきである (TLS_READMEを参照)

加えて、saslauthdサーバ自体を構成する必要がある。 パスワード認証にどの認証バックエンドを使うか伝える必要があり、そのバックエンドはsaslauthdコマンドラインオプションで指定される。とある。 ただし、一部のディストリビューションは、例えば認証バックエンドを指定するsaslauthdコマンドラインオプションを提供するコンフィグファイルを使う。 これらについては、この後に説明があるとのことなので先に進む。

saslauthdで/etc/shadowを使う

Using saslauthd with /etc/shadow

Access to the /etc/shadow system password file requires root privileges. The Postfix SMTP server (and in consequence libsasl linked to the server) runs with the least privilege possible. Direct access to /etc/shadow would not be possible without breaking the Postfix security architecture.

The saslauthd socket builds a safe bridge. Postfix, running as limited user postfix, can access the UNIX-domain socket that saslauthd receives commands on; saslauthd, running as privileged user root, has the privileges required to access the shadow file.

The saslauthd server verifies passwords against the authentication backend /etc/shadow if started like this:

% saslauthd -a shadow

See section "Testing saslauthd authentication" for test instructions.

ここはPostfixがどのように/etc/shadowにアクセスするかが書かれている。

/etc/shadowシステムパスワードファイルへアクセスするにはroot権限が要求される。 Postfix SMTPサーバ(その結果、サーバーにリンクされたlibsaslも)、可能な限り最小の権限で実行する。

この2つの要件を満たすためにsaslauthdソケットは安全なブリッジを構築するとのこと。 saslauthdは特権ユーザrootで実施するためシャドウファイルにアクセスする権限を持ち、 制限されたユーザpostfixで実行されたPostfixは、 saslauthdがコマンドを受信するUNIXドメインソケットにアクセスできる。 つまり、Postfixはsaslauthd経由で/etc/shadowで認証できるようになるということだ。

saslauthdサーバが/etc/shadow認証バックエンドでパスワードを検証するには次のように起動するとある。

% saslauthd -a shadow

saslauthdでPAMを使う

Using saslauthd with PAM

Cyrus SASL can use the PAM framework to authenticate credentials. saslauthd uses the PAM framework when started like this:

% saslauthd -a pam

Note

PAM configuration for the Postfix SMTP server is usually given in /etc/ pam.d/smtp and is beyond the scope of this document.

See section "Testing saslauthd authentication" for test instructions.

PAMは使う予定がないのでサラッと読み飛ばそう。 saslauthdでどの認証バックエンドを使うかは、やはりコマンドラインの引数で指定する。

saslauthdでIMAPサーバーを使う

Using saslauthd with an IMAP server

saslauthd can verify the SMTP client credentials by using them to log into an IMAP server. If the login succeeds, SASL authentication also succeeds. saslauthd contacts an IMAP server when started like this:

% saslauthd -a rimap -O imap.example.com

Note

The option "-O imap.example.com" specifies the IMAP server saslauthd should contact when it verifies credentials.

Important

saslauthd sends IMAP login information unencrypted. Any IMAP session leaving the local host should be protected by an additional security layer such as an SSL tunnel.

See section "Testing saslauthd authentication" for test instructions.

saslauthdとIMAPサーバの組み合わせだ、ここもサラッと読み飛ばす。

saslauthd認証をテストする

Testing saslauthd authentication

Cyrus SASL provides the testsaslauthd utility to test saslauthd authentication. The username and password are given as command line arguments. The example shows the response when authentication is successful:

% testsaslauthd -u username -p password
0: OK "Success."

Note

Sometimes the testsaslauthd program is not distributed with a the Cyrus SASL main package. In that case, it may be distributed with -devel, -dev or -debug packages.

Specify an additional "-s smtp" if saslauthd was configured to contact the PAM authentication framework, and specify an additional "-f /path/to/socketdir/mux" if saslauthd establishes the UNIX-domain socket in a non-default location.

If authentication succeeds, proceed with the section "Enabling SASL authentication and authorization in the Postfix SMTP server".

ここはsaslauthd認証のテストについて書かれている。 Cyrus SASLはsaslauthd認証をテストするためにtestsaslauthdユーティリティを提供する。 ユーザ名とパスワードはコマンドライン引数で与える。 次の例は認証が成功したときのレスポンスを示す。

% testsaslauthd -u username -p password
0: OK "Success."

testsaslauthdプログラムはCyrus SASLのメインパッケージに含まれていないこともあるらしい。 その場合、-devel、-dev、-debugパッケージにあるようだ。

saslauthdがPAM認証フレームワークに接続するように構成されている場合、「-s smtp」を追加で指定するとある。 そして、saslauthdがデフォルトの場所以外でUNIXドメインソケットを確立する場合、「-f /path/to/socketdir/mux」 を追加する。

認証が成功したら、「Enabling SASL authentication and authorization in the Postfix SMTP server」 セクションに進むと良いらしい。

Cyrus SASLプラグイン - 付加的なプロパティプラグイン

Cyrus SASL Plugins - auxiliary property plugins

Cyrus SASL uses a plugin infrastructure (called auxprop) to expand libsasl's capabilities. Currently Cyrus SASL sources provide three authentication plugins.

PluginDescription
sasldbAccounts are stored stored in a Cyrus SASL Berkeley DB database
sqlAccounts are stored in a SQL database
ldapdbAccounts are stored stored in an LDAP database

Important

These three plugins support shared-secret mechanisms i.e. CRAM-MD5, DIGEST- MD5 and NTLM. These mechanisms send credentials encrypted but their verification process requires the password to be available in plaintext. Consequently passwords cannot (!) be stored in encrypted form.

内部プラグインについてはここからだ。

Cyrus SASLは、libsaslの能力を拡張するために(auxpropと呼ばれる)基盤のプラグインを使う。 そしてさらに3つの認証プラグインがあることが書いてある。

sasldb
アカウントはCyrus SASLのBerkeley DB databaseに保存する
sql
アカウントはSQL databaseに保存する
ldapdb
アカウントはLDAP databaseに保存する

そして、これら3つのプラグインはCRAM-MD5、DIGEST-MD5、NTLMなどの共通鍵メカニズムをサポートしている。 これらのメカニズムは資格情報を暗号化して送るが、 認証プロセスではパスワードがプレーンテキストで使えることを要求するとある。 したがって、データベースには暗号化された形式で保存することはできないとのこと。 つまりプレーンテキストで保存しておく必要があるらしい。

さて、ここで重要なのはCRAM-MD5、DIGEST-MD5、NTLMなどが使えるということだ。 このマニュアルを通して出てくる認証メカニズムは、見落としがなければ次の5つだけだ。

    PLAIN LOGIN CRAM-MD5 DIGEST-MD5 NTLM

おそらく、これらが一般的なのだろう。他のメカニズムが使えるのかは今の時点ではわからない。 そもそもクライアント側も対応していなければならない。 この5つであれば大体クライアントも対応しているのかもしれない。

ここで少し横道に逸れて、クライアントとSMTPサーバとの通信の安全性について考えてみよう。 PLAINとLOGINはユーザ名とパスワードを平文で送信するので、盗聴されたらこれらが漏洩する。 従ってこれらを使う場合、通信自体をSSL/TSLやVPNなど暗号化された安全なネットワークで使用する必要があるだろう。 CRAM-MD5とDIGEST-MD5は、昨今MD5の脆弱性が見つかっているので、必ずしも安全とは言えないかもしれない。 しかし、どれくらい危険かも現時点ではよくは知らない。 NTLMはWindowsで昔使われていた方式で平文で送られることはないが、安全性の詳細はよく知らない。

考えては見たが、なんともまとまりのない結論で恐縮であるが、 ただリスクについては十分に検討した方が良いだろう。では気を取り直して次に進もう。

sasldbプラグイン

The sasldb plugin

The sasldb auxprop plugin authenticates SASL clients against credentials that are stored in a Berkeley DB database. The database schema is specific to Cyrus SASL. The database is usually located at /etc/sasldb2.

Note

The sasldb2 file contains passwords in plaintext, and should have read+write access only to user postfix or a group that postfix is member of.

The saslpasswd2 command-line utility creates and maintains the database:

% saslpasswd2 -c -u example.com username
Password:
Again (for verification):

This command creates an account username@example.com.

Important

users must specify username@example.com as login name, not username.

Run the following command to reuse the Postfix mydomain parameter value as the login domain:

% saslpasswd2 -c -u `postconf -h mydomain` username
Password:
Again (for verification):

Note

Run saslpasswd2 without any options for further help on how to use the command.

The sasldblistusers2 command lists all existing users in the sasldb database:

% sasldblistusers2
username1@example.com: password1
username2@example.com: password2

Configure libsasl to use sasldb with the following instructions:

/etc/sasl2/smtpd.conf:
pwcheck_method: auxprop
auxprop_plugin: sasldb
mech_list: PLAIN LOGIN CRAM-MD5 DIGEST-MD5 NTLM

Note

In the above example adjust mech_list to the mechanisms that are applicable for your environment.

ここはsasldbプラグインについての記述だ。 sasldb auxpropプラグインはBerkeley DB database に保存された資格情報に対してSASLクライアントを認証するとある。 データベースの場所は通常/etc/sasldb2とのこと。

sasldb2ファイルはプレーンテキストのパスワードを含み、postfixユーザかpostfixがメンバであるグループだけが読み書きのアクセス権を持つようすべきとある。

データベースの作成や保守にはsaslpasswd2コマンドラインユーティリティを使う。

% saslpasswd2 -c -u example.com username

このコマンドでusername@example.comというアカウントが作成される。 ここでログイン名として、ユーザ名ではなくusername@example.comを指定しなければならない。

Postfixのmydomainパラメータの値を再利用して次にように実行する方法も紹介されている。

% saslpasswd2 -c -u `postconf -h mydomain` username

sasldbデータベースの全ての既存ユーザを一覧表示するにはsasldblistusers2コマンドを使う。

% sasldblistusers2

実際に試してみよう。

# saslpasswd2 -c -u example.com testuser
Password:
Again (for verification):
# sasldblistusers2
testuser@example.com: userPassword
# ls -l /etc/sasldb2
-rw-r----- 1 root postfix 12288  8月  6 10:00 /etc/sasldb2

私の環境では追加のパッケージも必要なく実行できた。

sasldbを使うようにlibsaslを構成するには次のようにするとのこと。

/etc/sasl2/smtpd.conf:
    pwcheck_method: auxprop
    auxprop_plugin: sasldb
    mech_list: PLAIN LOGIN CRAM-MD5 DIGEST-MD5 NTLM

この例のmech_listは単なる例なので、要件に合わせて調整した方が良いとのこと。 PLAINやLOGINはパスワードが平文でネットワークを流れるので、 それを指定する場合は、別途通信を暗号化する必要があるだろう。

この方式は(私の環境では)追加パッケージが必要ないのでかなりお手軽だ。

sqlプラグイン

The sql plugin

The sql auxprop plugin is a generic SQL plugin. It provides access to credentials stored in a MySQL, PostgreSQL or SQLite database. This plugin requires that SASL client passwords are stored as plaintext.

Tip

If you must store encrypted passwords, you cannot use the sql auxprop plugin. Instead, see section "Using saslauthd with PAM", and configure PAM to look up the encrypted passwords with, for example, the pam_mysql module. You will not be able to use any of the methods that require access to plaintext passwords, such as the shared-secret methods CRAM-MD5 and DIGEST- MD5.

ここはsqlプラグインについての記述だ。 MySQL、PostgreSQL、SQLiteといったデータベースに資格情報を保持するときはsql auxprop プラグインを使う。 このプラグインもやはりパスワードをプレーンテキストで保存されていることを要求する。

今回は何百、何千というユーザを扱うわけではないので、 このような本格的なデータベースを使うより、sasldbを使う方が簡単だ。 従って、この後の設定例や設定オプションなどの記述は飛ばして先に進むことにする。

ldapdbプラグイン

The ldapdb plugin

The ldapdb auxprop plugin provides access to credentials stored in an LDAP server. This plugin requires that SASL client passwords are stored as plaintext.

Tip

If you must store encrypted passwords, you cannot use the ldapdb auxprop plugin. Instead, you can use "saslauthd -a ldap" to query the LDAP database directly, with appropriate configuration in saslauthd.conf. This may be documented in a later version of this document. You will not be able to use any of the methods that require access to plaintext passwords, such as the shared-secret methods CRAM-MD5 and DIGEST-MD5.

ldapdbプラグインも使う予定はないので触りだけ見てみよう。 ldapdb auxpropはLDAPサーバの認証情報を使う。 このプラグインもプレーンテキストとしてパスワードを保存することを要求するとのこと。

だいぶ長くなったが、以上がSASL認証設定の2段階のステップのうちの1番目のステップだ。 これから2番目のステップの記述について読んでいこう。

Postfix SMTPサーバーでのSASL認証と認可を有効化する

Enabling SASL authentication and authorization in the Postfix SMTP server

By default the Postfix SMTP server uses the Cyrus SASL implementation. If the Dovecot SASL implementation should be used, specify an smtpd_sasl_type value of dovecot instead of cyrus:

PostfixはデフォルトでCyrus SASLを使うとある。 そのあとはDovecotの記述が続くので読み飛ばす。

Postfix SMTPサーバーでSASL認証を有効化する

Enabling SASL authentication in the Postfix SMTP server

Regardless of the SASL implementation type, enabling SMTP authentication in the Postfix SMTP server always requires setting the smtpd_sasl_auth_enable option:

/etc/postfix/main.cf:
smtpd_sasl_auth_enable = yes

After a "postfix reload", SMTP clients will see the additional capability AUTH in an SMTP session, followed by a list of authentication mechanisms the server supports:

% telnet server.example.com 25
...
220 server.example.com ESMTP Postfix
EHLO client.example.com
250-server.example.com
250-PIPELINING
250-SIZE 10240000
250-AUTH DIGEST-MD5 PLAIN CRAM-MD5
...

However not all clients recognize the AUTH capability as defined by the SASL authentication RFC. Some historical implementations expect the server to send an "=" as separator between the AUTH verb and the list of mechanisms that follows it.

The broken_sasl_auth_clients configuration option lets Postfix repeat the AUTH statement in a form that these broken clients understand:

/etc/postfix/main.cf:
broken_sasl_auth_clients = yes

Note

Enable this option for Outlook up to and including version 2003 and Outlook Express up to version 6. This option does not hurt other clients.

After "postfix reload", the Postfix SMTP server will propagate the AUTH capability twice - once for compliant and once for broken clients:

% telnet server.example.com 25
...
220 server.example.com ESMTP Postfix
EHLO client.example.com
250-server.example.com
250-PIPELINING
250-SIZE 10240000
250-AUTH DIGEST-MD5 PLAIN CRAM-MD5
250-AUTH=DIGEST-MD5 PLAIN CRAM-MD5
...

タイトルは「Postfix SMTPサーバで認証を有効にする」だ。 先ほどとほとんど同じだ。認可がなくなっただけだね。

SASL実装に関係なくSMTP認証を有効にするには次のようにする必要があるとのこと。 つまりCyrus SASL、Dovecot SASLのどちらを使うにしてもこの設定は必要ということだ。

/etc/postfix/main.cf:
    smtpd_sasl_auth_enable = yes

上記の通り設定しよう。 その後「postfix reload」でリロードして設定を読み込ませると、 EHLOコマンドの応答にAUTH capabilityをサーバーが付けて来るようになる。

    % telnet server.example.com 25
    ...
    220 server.example.com ESMTP Postfix
    EHLO client.example.com
    250-server.example.com
    250-PIPELINING
    250-SIZE 10240000
    250-AUTH DIGEST-MD5 PLAIN CRAM-MD5
    ...

これはPostfixにtelnetで接続して、 対話的にEHLOコマンドを試している部分だ。

しかし、Outlook 2003以前のバージョンなど一部のメールクライアントは、 このAUTH capabilityを認識出来ないとある。 そしてその対処法が書かれているが、今時のクライアント大丈夫だと思うので 対処法については飛ばして先に進もう。

Postfix SMTPサーバーポリシー - SASLメカニズムのプロパティ

Postfix SMTP Server policy - SASL mechanism properties

The Postfix SMTP server supports policies that limit the SASL mechanisms that it makes available to clients, based on the properties of those mechanisms. The next two sections give examples of how these policies are used.

PropertyDescription
noanonymousDon't use mechanisms that permit anonymous authentication.
noplaintextDon't use mechanisms that transmit unencrypted username and password information.
nodictionaryDon't use mechanisms that are vulnerable to dictionary attacks.
forward_secrecyRequire forward secrecy between sessions (breaking one session does not break earlier sessions).
mutual_authUse only mechanisms that authenticate both the client and the server to each other.

Postfix SMTPサーバはSASLメカニズムを制限するポリシーをサポートしているとのこと。 SASLメカニズムのプロパティに基づいて、クライアントに何をできる(あるいはできない)ようにするかを決めるものだ。

そしてプロパティとその説明の一覧がある。それは次のようなものだ。

noanonymous
匿名認証を許可するメカニズムは使えない。
noplaintext
ユーザ名とパスワード情報を暗号化しないで送信するメカニズムは使えない。
nodictionary
辞書攻撃を受けやすいメカニズムは使えない。
forward_secrecy
ん〜、どういう意味か理解できない。。。
mutual_auth
クライアントとサーバを相互に認証するメカニズムだけを使う。

これらのポリシーの使い方は、次の2つのセクションに例があるとのことなので、 その部分を読んでいこう。

暗号化されていないSMTPセッション

Unencrypted SMTP session

The default policy is to allow any mechanism in the Postfix SMTP server except for those based on anonymous authentication:

/etc/postfix/main.cf:
# Specify a list of properties separated by comma or whitespace
smtpd_sasl_security_options = noanonymous

Important

Always set at least the noanonymous option. Otherwise, the Postfix SMTP server can give strangers the same authorization as a properly- authenticated client.

ここはパラメータ名(smtpd_sasl_security_options)から察するに、SASLを使い、かつ暗号化されていない場合のポリシーの話だろう。 タイトルは「暗号化されていないSMTPセッション」で、SASLを使わない場合も含むように思えるが、おそらくそれは間違いだろう。

デフォルトのポリシーは、「匿名認証に基づくものを除いて、どんなメカニズムでも許可する」とある。 以下の設定例は、デフォルトのポリシーを明示的に設定した場合の例であろう。

    /etc/postfix/main.cf:
        # Specify a list of properties separated by comma or whitespace
        smtpd_sasl_security_options = noanonymous

少なくともnoanonymousオプションは”常に”設定すべきとある。さもなければPostfixは見知らぬ人にも正当に認証されたクライアントと同じ認可を与えることができてしまうらしい。それは怖い。必ず指定しよう。

暗号化されたSMTPセッション(TLS)

Encrypted SMTP session (TLS)

A separate parameter controls Postfix SASL mechanism policy during a TLS- encrypted SMTP session. The default is to copy the settings from the unencrypted session:

/etc/postfix/main.cf:
smtpd_sasl_tls_security_options = $smtpd_sasl_security_options

A more sophisticated policy allows plaintext mechanisms, but only over a TLS- encrypted connection:

/etc/postfix/main.cf:
smtpd_sasl_security_options = noanonymous, noplaintext
smtpd_sasl_tls_security_options = noanonymous

To offer SASL authentication only after a TLS-encrypted session has been established specify this:

/etc/postfix/main.cf:
smtpd_tls_auth_only = yes

TLSで暗号化されたSMTPセッションで、 PostfixのSASLメカニズムのポリシーを制御する個別のパラメータが幾つかあるらしい。 デフォルトは、暗号化されていないセッションから設定をコピーするだけらしい。

smtpd_sasl_tls_security_options = $smtpd_sasl_security_options

もっと洗練されたポリシーは、 TLSで暗号化されたコネクションの場合だけプレーンテキストメカニズムを許可するポリシーだとある。

/etc/postfix/main.cf:
    smtpd_sasl_security_options = noanonymous, noplaintext
    smtpd_sasl_tls_security_options = noanonymous

暗号化されたセッションでは smtpd_sasl_tls_security_options では匿名認証だけを禁止(noanonymous)して、 暗号化されていないセッションでは smtpd_sasl_security_options でプレーンテキストも禁止(noplaintext)にしている。

TLSで暗号化されたセッションが確立された後にだけSASL認証をオファーするようにするには、 次のように指定するとのこと。

/etc/postfix/main.cf:
    smtpd_tls_auth_only = yes

Postfix SMTPサーバーでSASL認可を有効化する

Enabling SASL authorization in the Postfix SMTP server

After the client has authenticated with SASL, the Postfix SMTP server decides what the remote SMTP client will be authorized for. Examples of possible SMTP clients authorizations are:

* Send a message to a remote recipient.

* Use a specific envelope sender in the MAIL FROM command.

These permissions are not enabled by default.

タイトルは「Postfix SMTP serverでSASL認可を有効にする」。今度は認可についてだ。

クライアントがSASLで認証されたら、 リモートのSMTPクライアントが何を認可(つまり許可)されてるかを決定する、とある。 可能なSMTPクライアントの認可の例は次の通りだ。

  • リモート受信者へメッセージを送信する
  • MAIL FROMコマンドで特定のエンベロープ送信者を使う

これらの許可はデフォルトで有効になっていないとのこと。

メールリレー認可

Mail relay authorization

With permit_sasl_authenticated the Postfix SMTP server can allow SASL- authenticated SMTP clients to send mail to remote destinations. Examples:

# With Postfix 2.10 and later, the mail relay policy is
# preferably specified under smtpd_relay_restrictions.
/etc/postfix/main.cf:
    smtpd_relay_restrictions =
    permit_mynetworks
    permit_sasl_authenticated
    reject_unauth_destination

# Older configurations combine relay control and spam control under
# smtpd_recipient_restrictions. To use this example with Postfix >=
# 2.10 specify "smtpd_relay_restrictions=".
/etc/postfix/main.cf:
    smtpd_recipient_restrictions =
    permit_mynetworks
    permit_sasl_authenticated
    reject_unauth_destination
    ...other rules...

リモートの宛先へメールを送信するために、permit_sasl_authenticated でSASL認証されたSMTPクライアントにリモートの宛先へのメール送信を許可できる、とある。

以下はPostfix 2.10以降で、smtpd_relay_restrictionsによって制御する例だ。

    # With Postfix 2.10 and later, the mail relay policy is
    # preferably specified under smtpd_relay_restrictions.
    /etc/postfix/main.cf:
        smtpd_relay_restrictions =
    	permit_mynetworks
    	permit_sasl_authenticated
    	reject_unauth_destination

smtpd_relay_restrictionsはメールリレーのアクセス制御の設定だ。 これらは「記載された順」にマッチするか調べられる。 この設定は、まずpermit_mynetworksでPostfixと同じネットワーク (mynetworksパラメータのネットワーク)にあるクライアントは許可される。 次にpermit_sasl_authenticatedでSASLで認証されたクライアントも許可される。 最後にreject_unauth_destinationで許可された宛先以外は拒否される。

上記の場合、どれにもマッチしなかった場合はどうなるのだろう? という疑問が浮かんだのでちょっと調べて見た。 smtpd_relay_restrictionsの設定の制限として reject、reject_unauth_destination、defer、defer_if_permit、 defer_unauth_destination のいずれか1つを必ず指定しなければならない。 そうしないとPostfixはメールの受信を拒否するとのこと。 これ以上詳しく調べなかったが、上記の5つのいずれかを指定すれば必ずどれかには 引っかかるのだと思われる。

smtpd_relay_restrictionsで制御しない古い設定の仕方も書いてある。

    # Older configurations combine relay control and spam control under
    # smtpd_recipient_restrictions. To use this example with Postfix >=
    # 2.10 specify "smtpd_relay_restrictions=".
    /etc/postfix/main.cf:
        smtpd_recipient_restrictions =
    	permit_mynetworks
    	permit_sasl_authenticated
    	reject_unauth_destination
    	...other rules...

smtpd_recipient_restrictionsはRCPT TOコマンドに指定される受信者アドレス (エンベロープTO)で制限をかけるパラメータだ。 コメントにある通りリレー制御とスパムメール制御の両方をsmtpd_recipient_restrictions で行うのは古い設定の仕方だ。 バージョン2.10以降は新しくsmtpd_relay_restrictionsが追加されたので、 リレー制御はこちらで行い、スパムメール制御は以前と同様にsmtpd_recipient_restrictions で行うようにするのが望ましい、と他のマニュアルに確か記載があったはずだ。

エンベロープ送信者アドレス認可

Envelope sender address authorization

By default an SMTP client may specify any envelope sender address in the MAIL FROM command. That is because the Postfix SMTP server only knows the remote SMTP client hostname and IP address, but not the user who controls the remote SMTP client.

This changes the moment an SMTP client uses SASL authentication. Now, the Postfix SMTP server knows who the sender is. Given a table of envelope sender addresses and SASL login names, the Postfix SMTP server can decide if the SASL authenticated client is allowed to use a particular envelope sender address:

/etc/postfix/main.cf:
    smtpd_sender_login_maps = hash:/etc/postfix/controlled_envelope_senders

    smtpd_recipient_restrictions =
        ...
        reject_sender_login_mismatch
    permit_sasl_authenticated
        ...

The controlled_envelope_senders table specifies the binding between a sender envelope address and the SASL login names that own that address:

/etc/postfix/controlled_envelope_senders
    # envelope sender           owners (SASL login names)
    john@example.com            john@example.com
    helpdesk@example.com        john@example.com, mary@example.com
    postmaster                  admin@example.com
    @example.net                barney, fred, john@example.com,
mary@example.com

With this, the reject_sender_login_mismatch restriction above will reject the sender address in the MAIL FROM command if smtpd_sender_login_maps does not specify the SMTP client's login name as an owner of that address.

See also reject_authenticated_sender_login_mismatch and reject_unauthenticated_sender_login_mismatch for additional control over the SASL login name and the envelope sender.

次に「エンベロープ送信者アドレスによる認可」だ。

SMTPのデフォルトでは、クライアントは MAIL FROMコマンドに任意のエンベロープ送信者アドレスを指定しても良い。 PostfixはリモートSMTPクライアントのホスト名とIPアドレスだけ知っているが、 リモートSMTPクライアントを使用するユーザが誰かは意識しないことを意味する、 といったことが書かれている。 つまり、ユーザをしMAIL FROMで通知されるアドレスは詐称されているかもしれないが、 Postfixはこれを通常気にしないということだ。 Posfixが気にするのはあくまでもリモートクライアントのホスト名とIPアドレスだけだということだ。

しかしSASL認証を使うと送信者が誰か知ることができるようになる。 エンベロープ送信者アドレスとSASLログイン名の対応表が与えられると、 SASL認証されたクライアントが特定のエンベロープ送信者アドレスを使うことを許可されているかどうかを Postfix SMTPサーバが決定することができる、とある。

次の例がエンベロープ送信者アドレスとログイン名の対応表の設定とそれによって制御する設定例だ。

    /etc/postfix/main.cf:
        smtpd_sender_login_maps = hash:/etc/postfix/controlled_envelope_senders

        smtpd_recipient_restrictions =
            ...
            reject_sender_login_mismatch
    	permit_sasl_authenticated
            ...
        ...

「エンベロープ送信者アドレス」と「そのアドレスを所有するSASLログイン名」 の紐付けを登録するcontrolled_envelope_sendersテーブルは次のようなものだ。

/etc/postfix/controlled_envelope_senders
    # envelope sender           owners (SASL login names)
    john@example.com            john@example.com
    helpdesk@example.com        john@example.com, mary@example.com
    postmaster                  admin@example.com
    @example.net                barney, fred, john@example.com,
mary@example.com

これにより、上述のreject_sender_login_mismatchによる制限は、 smtpd_sender_login_mapsで、MAIL FROMのエンベロープ送信者アドレスの所有者としてSMTPクライアントのログイン名が指定されていないと、 MAIL FROM コマンドのエンベロープ送信者アドレスをリジェクトします。

加えてSASLログイン名とエンベロープ送信者で制御するパラメータとしては、 次のようなものが紹介されている。

reject_authenticated_sender_login_mismatch
reject_unauthenticated_sender_login_mismatch

追加のSMTPサーバーのSASLオプション

Additional SMTP Server SASL options

Postfix provides a wide range of SASL authentication configuration options. The next section lists a few that are discussed frequently. See postconf(5) for a complete list.

PostfixはSASL認証の幅広いコンフィグオプションを提供する。 次のセクションは頻繁に議論されるいくつかをリストする。 完全なリストはpostconf(5)を参照。

デフォルト認証ドメイン

Default authentication domain

Postfix can append a domain name (or any other string) to a SASL login name that does not have a domain part, e.g. "john" instead of "john@example.com":

/etc/postfix/main.cf:
smtpd_sasl_local_domain = example.com

This is useful as a default setting and safety net for misconfigured clients, or during a migration to an authentication method/backend that requires an authentication REALM or domain name, before all SMTP clients are configured to send such information.

Postfixはドメイン部分がないSASLログイン名(例えば"john@example.com"ではなく"john")に、 ドメイン名(または任意の文字列でも)を追加できるとある。

/etc/postfix/main.cf:
    smtpd_sasl_local_domain = example.com

これはデフォルト設定として有用であるということだ。 クライアントの設定ミスや、移行中などで全てのSMTPクライアントがちゃんとした情報を送るように設定される前の セーフティネットになるとのこと。

クライアントまたはネットワークからSASL認証を隠す

Hiding SASL authentication from clients or networks

Some clients insist on using SASL authentication if it is offered, even when they are not configured to send credentials - and therefore they will always fail and disconnect.

Postfix can hide the AUTH capability from these clients/networks:

/etc/postfix/main.cf:
smtpd_sasl_exceptions_networks = !192.0.2.171/32, 192.0.2.0/24

一部のクライアントは、SASL認証をオファーされたらSASL認証を使うことを主張する。 例えクライアントが資格情報を送るように構成されていない場合でさえ。 これだと必ず失敗や切断というる結果になる。

Postfixは、そのようなクライアントやネットワークからAUTH capabilityを隠すことができる、とある。 その設定は次のようにするそうだ。

/etc/postfix/main.cf:
smtpd_sasl_exceptions_networks = !192.0.2.171/32, 192.0.2.0/24

SASLログイン名をメールヘッダーに追加する

Adding the SASL login name to mail headers

To report SASL login names in Received: message headers (Postfix version 2.3 and later):

/etc/postfix/main.cf:
smtpd_sasl_authenticated_header = yes

Note

The SASL login names will be shared with the entire world.

「Received:」メッセージヘッダーでSASLログイン名を報告するには次のようにするとのこと。

/etc/postfix/main.cf:
smtpd_sasl_authenticated_header = yes

こうするとSASLログイン名は全世界でシェアされるようになるそうです。

Postfix SMTPサーバーでSASL認証をテストする

Testing SASL authentication in the Postfix SMTP Server

To test the server side, connect (for example, with telnet) to the Postfix SMTP server port and you should be able to have a conversation as shown below. Information sent by the client (that is, you) is shown in bold font.

% telnet server.example.com 25
...
220 server.example.com ESMTP Postfix
EHLO client.example.com
250-server.example.com
250-PIPELINING
250-SIZE 10240000
250-ETRN
250-AUTH DIGEST-MD5 PLAIN CRAM-MD5
250 8BITMIME
AUTH PLAIN AHRlc3QAdGVzdHBhc3M=
235 Authentication successful

タイトルは「Postfix SMTPサーバでSASL認証をテストする」だ。 サーバ側でテストするには、(例えばtelnetで)Postfixサーバのポートに接続して、 下記に示すように対話することができる。

    % telnet server.example.com 25
    ...
    220 server.example.com ESMTP Postfix
    EHLO client.example.com
    250-server.example.com
    250-PIPELINING
    250-SIZE 10240000
    250-ETRN
    250-AUTH DIGEST-MD5 PLAIN CRAM-MD5
    250 8BITMIME
    AUTH PLAIN AHRlc3QAdGVzdHBhc3M=
    235 Authentication successful

続いてTLSで暗号化されたコネクションで同じように対話的にテストする方法が 書かれているが今回は割愛する。 「SMTP/LMTP client」について書かれている部分も今回は飛ばしていく。

送信者依存のSASL認証の設定

Configuring Sender-Dependent SASL authentication

Postfix supports different ISP accounts for different sender addresses (version 2.3 and later). This can be useful when one person uses the same machine for work and for personal use, or when people with different ISP accounts share the same Postfix server.

To make this possible, Postfix supports per-sender SASL passwords and per- sender relay hosts. In the example below, the Postfix SMTP client will search the SASL password file by sender address before it searches that same file by destination. Likewise, the Postfix trivial-rewrite(8) daemon will search the per-sender relayhost file, and use the default relayhost setting only as a final resort.

/etc/postfix/main.cf:
    smtp_sender_dependent_authentication = yes
    sender_dependent_relayhost_maps = hash:/etc/postfix/sender_relay
    smtp_sasl_auth_enable = yes
    smtp_sasl_password_maps = hash:/etc/postfix/sasl_passwd
    relayhost = [mail.isp.example]
    # Alternative form:
    # relayhost = [mail.isp.example]:submission

/etc/postfix/sasl_passwd:
    # Per-sender authentication; see also /etc/postfix/sender_relay.
    user1@example.com               username2:password2
    user2@example.net               username2:password2
    # Login information for the default relayhost.
    [mail.isp.example]              username:password
    # Alternative form:
    # [mail.isp.example]:submission username:password

/etc/postfix/sender_relay:
    # Per-sender provider; see also /etc/postfix/sasl_passwd.
    user1@example.com               [mail.example.com]:submission
    user2@example.net               [mail.example.net]

* If you are creative, then you can try to combine the two tables into one single MySQL database, and configure different Postfix queries to extract the appropriate information.

* Specify dbm instead of hash if your system uses dbm files instead of db files. To find out what lookup tables Postfix supports, use the command "postconf -m".

* Execute the command "postmap /etc/postfix/sasl_passwd" whenever you change the sasl_passwd table.

* Execute the command "postmap /etc/postfix/sender_relay" whenever you change the sender_relay table.

2つほどセクションを飛ばすとこのセクションが見つかるだろう。 ここを読み進めていく。

Postfixは異なる送信者アドレスに対する異なるISPアカウントをサポートする。 これは一人の人が仕事用や個人用に同じマシンを使う場合や、異なるISPアカウントで同じPostfixサーバを共有する場合に役立つ。

これを可能にするために、Postfixは送信者ごとのSASLパスワードや送信者ごとのリレーホストをサポートする。 下記に示す例では、Postfix SMTPクライアントがSASLパスワードファイルを宛先で検索する前に送信者アドレスで検索する。 同様に、Postfix trivial-rewrite(8) デーモンは送信者ごとのrelayhostファイル、 そして最後の手段としてデフォルトのrelayhost設定を使い検索を実施する。

/etc/postfix/main.cf:
    smtp_sender_dependent_authentication = yes
    sender_dependent_relayhost_maps = hash:/etc/postfix/sender_relay
    smtp_sasl_auth_enable = yes
    smtp_sasl_password_maps = hash:/etc/postfix/sasl_passwd
    relayhost = [mail.isp.example]
    # Alternative form:
    # relayhost = [mail.isp.example]:submission
/etc/postfix/sasl_passwd:
    # Per-sender authentication; see also /etc/postfix/sender_relay.
    user1@example.com               username2:password2
    user2@example.net               username2:password2
    # Login information for the default relayhost.
    [mail.isp.example]              username:password
    # Alternative form:
    # [mail.isp.example]:submission username:password
/etc/postfix/sender_relay:
    # Per-sender provider; see also /etc/postfix/sasl_passwd.
    user1@example.com               [mail.example.com]:submission
    user2@example.net               [mail.example.net]

そのほかに箇条書きでいくつか書かれているが、これらは実際に使うときに読むとしよう。

暗号化されていないSMTPセッション

Unencrypted SMTP session

The default policy is stricter than that of the Postfix SMTP server - plaintext mechanisms are not allowed (nor is any anonymous mechanism):

/etc/postfix/main.cf:
smtp_sasl_security_options = noplaintext, noanonymous

This default policy, which allows no plaintext passwords, leads to authentication failures if the remote server only offers plaintext authentication mechanisms (the SMTP server announces "AUTH PLAIN LOGIN"). In such cases the SMTP client will log the following error message:

SASL authentication failure: No worthy mechs found

Note

This same error message will also be logged when the libplain.so or liblogin.so modules are not installed in the /usr/lib/sasl2 directory.

The insecure approach is to lower the security standards and permit plaintext authentication mechanisms:

/etc/postfix/main.cf:
smtp_sasl_security_options = noanonymous

The more secure approach is to protect the plaintext username and password with TLS session encryption. To find out if the remote SMTP server supports TLS, connect to the server and see if it announces STARTTLS support as shown in the example. Information sent by the client (that is, you) is shown in bold font.

% telnet server.example.com 25
...
220 server.example.com ESMTP Postfix
EHLO client.example.com
250-server.example.com
250-PIPELINING
250-SIZE 10240000
250-STARTTLS
...

Instead of port 25 (smtp), specify port 587 (submission) where appropriate.

「SMTP/LMTP」部分は飛ばして次の「暗号化されていないSMTPセッショ」を読んでいく。 前にも同じタイトルが出てきたが、何が違うのだろう。

デフォルトのポリシーはPostfix SMTPサーバのポリシーより厳格です。 これはプレーンテキストメカニズムは許可されていないし、匿名メカニズムも許可されていない。

/etc/postfix/main.cf:
smtp_sasl_security_options = noplaintext, noanonymous

プレーンテキストのパスワードを許可しないこのデフォルトのポリシーは、 リモートサーバがプレーンテキスト認証メカニズムだけをオファー (SMTPサーバが"AUTH PLAIN LOGIN"を言ってきた)するなら、認証は失敗する。 このような場合、SMTPクライアントは次のようなエラーメッセージをログに記録する。

SASL authentication failure: No worthy mechs found

安全ではないアプローチは、セキュリティ基準を下げ、プレーンテキスト認証メカニズム許可するとのこと。 これの設定例も書かれているが、一般にこれはよくないアプローチだ。次にもっと安全なアプローチが書かれている。

もっと安全なアプローチはTLSセッション暗号化でプレーンテキストのユーザ名とパスワードを保護することとある。 リモートSMTPサーバがTLSをサポートしているかどうかを確認するには、 サーバに接続し、例に示すようにSTARTTLSサポートをアナウンスするかどうかを確認します。

  250-STARTTLS

この部分ですね。

暗号化されたSMTPセッション(TLS)

Encrypted SMTP session (TLS)

To turn on TLS in the Postfix SMTP client, see TLS_README for configuration details.

The smtp_sasl_tls_security_options parameter controls Postfix SASL mechanism policy during a TLS-encrypted SMTP session. The default is to copy the settings from the unencrypted session:

/etc/postfix/main.cf:
smtp_sasl_tls_security_options = $smtp_sasl_security_options

A more sophisticated policy allows plaintext mechanisms, but only over a TLS- encrypted connection:

/etc/postfix/main.cf:
smtp_sasl_security_options = noanonymous, noplaintext
smtp_sasl_tls_security_options = noanonymous

このタイトルも前に出てきたものだ。 Postfix SMTPクライアントでTLSをオンにする設定の詳細についてはTLS_READMEを参照してください。

TLS暗号化されたSMTPセッションでは、smtp_sasl_tls_security_optionsパラメーターは、Postfix SASLメカニズムを制御する。 デフォルトは、暗号化されていないセッションから設定をコピーする。

/etc/postfix/main.cf:
    smtp_sasl_tls_security_options = $smtp_sasl_security_options

より洗練されたポリシーは、TLSで暗号化されたコネクションの場合だけ、プレーンテキストメカニズムが許可される。

/etc/postfix/main.cf:
    smtp_sasl_security_options = noanonymous, noplaintext
    smtp_sasl_tls_security_options = noanonymous

残りはあまり必要な部分ではないので、読むのはここまでとする。 以上がPostfixでSMTP認証を使う場合の設定だ。

-Linuxサーバー
-

Copyright© アナグマのモノローグ , 2024 All Rights Reserved Powered by STINGER.