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

どのように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自体の設定の２段階が必要ということのようだ。 そして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をどう使うかを記述した「設定ファイルの名前と場所」を決めること、とある。 名前と場所についてはこの後に説明されている。

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

# postconf smtpd_sasl_path
smtpd_sasl_path = smtpd

/usr/lib/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 → libsasl → 外部認証サービスまたは内部プラグイン → 認証バックエンド

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 -a shadow

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

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.

Plugin	Description
sasldb	Accounts are stored stored in a Cyrus SASL Berkeley DB database
sql	Accounts are stored in a SQL database
ldapdb	Accounts 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で昔使われていた方式で平文で送られることはないが、安全性の詳細はよく知らない。

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

% saslpasswd2 -c -u example.com username

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

% 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

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

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の記述が続くので読み飛ばす。

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

    % 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
    ...

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

smtpd_sasl_tls_security_options = $smtpd_sasl_security_options

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

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

    # 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...

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

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

/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

追加の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)を参照。

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

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認証を使う場合の設定だ。