Product SiteDocumentation Site

第 11 章 ネットワークサービス、Postfix、Apache、NFS、Samba、Squid、LDAP、SIP、XMPP、TURN

11.1. メールサーバ
11.1.1. Postfix のインストール
11.1.2. 仮想ドメインの設定
11.1.3. 受信と送信の制限
11.1.4. greylisting の設定
11.1.5. 受信アドレスに基づくフィルタのカスタマイズ
11.1.6. アンチウイルスの統合
11.1.7. SMTP 認証
11.2. ウェブサーバ (HTTP)
11.2.1. Apache のインストール
11.2.2. 仮想ホストの設定
11.2.3. よく使われる指示文
11.2.4. ログ解析ソフトウェア
11.3. FTP ファイルサーバ
11.4. NFS ファイルサーバ
11.4.1. 安全な NFS
11.4.2. NFS サーバ
11.4.3. NFS クライアント
11.5. Samba を使った Windows 共有のセットアップ
11.5.1. Samba サーバ
11.5.2. Samba クライアント
11.6. HTTP/FTP プロキシ
11.6.1. インストール
11.6.2. キャッシュの設定
11.6.3. フィルタの設定
11.7. LDAP ディレクトリ
11.7.1. インストール
11.7.2. ディレクトリの書き込み
11.7.3. LDAP を用いたアカウントの管理
11.8. リアルタイムコミュニケーションサービス
11.8.1. RTC サービス用の DNS 設定
11.8.2. TURN サーバ
11.8.3. SIP プロキシサーバ
11.8.4. XMPP サーバ
11.8.5. ポート 443 番でサービスを実行する
11.8.6. WebRTC の追加
ネットワークサービスはユーザが毎日の仕事で直接使用するプログラムです。ネットワークサービスは情報システムの氷山の一角で、この章ではネットワークサービスに注目します。そして、水面下に隠された部分は既に説明したインフラに依存しています。
多くの現代的なネットワークサービスは信頼性と安全性を確保して運用するために暗号化技術を必要としています。特に公開インターネットでは暗号化技術が必要不可欠です。X.509 証明書 (SSL 証明書および TLS 証明書とも呼ばれる場合もあります) は暗号化という目的を果たす際に最もよく使われています。特定のドメインに対する証明書はこの章で紹介するサービス間で共有される場合が多いです。

11.1. メールサーバ

Falcot Corp の管理者は、信頼性と設定の容易さから、電子メールサーバに Postfix を選びました。実際、Postfix の設計により、それぞれのタスクは必要な最低限のパーミッションを持つ単独のプロセスとして実装されることが、強制されます。この制限によりセキュリティ問題を大きく軽減させることが可能です。

11.1.1. Postfix のインストール

postfix パッケージには主要な SMTP デーモンが含まれます。別のパッケージ (たとえば postfix-ldappostfix-pgsql など) は特別な機能を Postfix に追加します。これらのパッケージはマッピングデータベースへのアクセスを可能にします。これらのパッケージは、それが必要と分かっている場合を除いて、インストールするべきではありません。
Debconf はパッケージのインストール中にいくつかの質問を行います。これに答えることで、/etc/postfix/main.cf 設定ファイルの最初のバージョンが作成されます。
最初の質問はセットアップのタイプに関するものです。インターネットに接続されたサーバに関連するのは提案された選択肢のうちの 2 種類だけです。「Internet site」と「Internet with smarthost」です。「Internet site」は、入って来る電子メールを受け取り、外に出る電子メールを直接受信者に送信するサーバに適します。つまり Falcot Corp の場合にうまく適合します。「Internet with smarthost」は、外に出る電子メールを直接受信者のサーバに送信するのではなく、中間 SMTP サーバ —「smarthost」— を介して送信するサーバに適します。この選択肢は主に動的 IP アドレスを持つマシンに便利です。なぜなら、多くの電子メールサーバは動的 IP アドレスを持つホストから配送されたメッセージを拒否するからです。この場合、スマートホストに通常 ISP の SMTP サーバを設定します。この SMTP サーバは常に ISP の顧客からの電子メールを受け入れ、それを適切に転送するように設定されています。この (スマートホストを使う) 選択肢はさらに、永久にインターネットに接続され続けないサーバにも適しています。なぜなら、後から再試行する必要のある未配送メッセージのキューを管理しなくても良くなるからです。
2 番目の質問はマシンのフルネームに関するもので、これはローカルユーザの電子メールアドレスを生成するために使われます。従って、マシンのフルネームとはアットマーク (「@」) のすぐ後ろに付けられるものです。Falcot の場合、この質問には mail.falcot.com と答えるべきです。デフォルトで聞かれる質問は以上ですが、Falcot にとってこの状態の Postfix はまだ十分に設定されていません。このため、管理者は dpkg-reconfigure postfix を実行してさらに多くのパラメータをカスタマイズします。
追加で行われる質問の 1 つに、このマシンに関連するすべてのドメイン名に関するものがあります。デフォルトで挙げられるドメイン名のリストには、マシンのフルネームといくつかの localhost の同義語が含まれていますが、主要なドメイン名である falcot.com を手作業で追加する必要があります。より一般的に言えば、この質問の回答には、通常 MX サーバを担当しているマシンに割り当てたすべてのドメイン名を含めるべきです。さらに言い換えれば、DNS から電子メールを受け入れると回答されるすべてのドメイン名を含めるべきです。この情報の最後に主要な Postfix 設定ファイル — /etc/postfix/main.cf — の mydestination 変数を設定します。
メール送信中の DNS MX レコードの役割

図 11.1 メール送信中の DNS MX レコードの役割

インストール中に、このサーバが電子メールの送信要求を受け入れるネットワークを尋ねられる場合があります。デフォルトの設定で、Postfix はマシン自身からの電子メールの送信要求だけを受け入れます。従って、通常はローカルネットワークからの送信要求も受け入れるように設定します。Falcot Corp 管理者はデフォルトの回答に 192.168.0.0/16 を追加しました。この質問が尋ねられなければ、以下の例に示す通り、設定ファイル中の関連する変数 mynetworks にローカルネットワークを追加します。
ローカル電子メールを procmail を使って配送することも可能です。procmail を使うことで、ユーザは ~/.procmailrc ファイルに書かれたルールに従って入って来る電子メールを仕分けすることが可能になります。
最初のステップの後、以下の設定ファイルが得られます。さらに次の節では、いくつかの特別な機能を追加するための足掛かりとしてこれを使います。

例 11.1 最初の /etc/postfix/main.cf ファイル

# See /usr/share/postfix/main.cf.dist for a commented, more complete version


# Debian specific:  Specifying a file name will cause the first
# line of that file to be used as the name.  The Debian default
# is /etc/mailname.
#myorigin = /etc/mailname

smtpd_banner = $myhostname ESMTP $mail_name (Debian/GNU)
biff = no

# appending .domain is the MUA's job.
append_dot_mydomain = no

# Uncomment the next line to generate "delayed mail" warnings
#delay_warning_time = 4h

readme_directory = no

# TLS parameters
smtpd_tls_cert_file=/etc/ssl/certs/ssl-cert-snakeoil.pem
smtpd_tls_key_file=/etc/ssl/private/ssl-cert-snakeoil.key
smtpd_use_tls=yes
smtpd_tls_session_cache_database = btree:${data_directory}/smtpd_scache
smtp_tls_session_cache_database = btree:${data_directory}/smtp_scache

# See /usr/share/doc/postfix/TLS_README.gz in the postfix-doc package for
# information on enabling SSL in the smtp client.

smtpd_relay_restrictions = permit_mynetworks permit_sasl_authenticated defer_unauth_destination
myhostname = mail.falcot.com
alias_maps = hash:/etc/aliases
alias_database = hash:/etc/aliases
myorigin = /etc/mailname
mydestination = mail.falcot.com, falcot.com, localhost.localdomain, localhost
relayhost = 
mynetworks = 127.0.0.0/8 [::ffff:127.0.0.0]/104 [::1]/128 192.168.0.0/16
mailbox_command = procmail -a "$EXTENSION"
mailbox_size_limit = 0
recipient_delimiter = +
inet_interfaces = all
inet_protocols = all

11.1.2. 仮想ドメインの設定

メールサーバは主要ドメインに加えて他のドメイン宛の電子メールを受け取ることが可能です。これらは仮想ドメインとして知られています。これを使う場合のほとんどは、電子メールが永久的にローカルユーザに配送されない場合です。Postfix は仮想ドメインを取り扱う 2 種類の興味深い機能を提供します。

11.1.2.1. 仮想エイリアスドメイン

仮想エイリアスドメインには、エイリアスだけが含まれます。たとえば、電子メールを他のアドレスに転送するだけのアドレスがこれに該当します。
ドメインを有効化するには、virtual_alias_domains 変数にその名前を追加し、virtual_alias_maps 変数でアドレスマッピングファイルを参照します。

例 11.2 /etc/postfix/main.cf ファイルに追加する指示文

virtual_alias_domains = falcotsbrand.com
virtual_alias_maps = hash:/etc/postfix/virtual
/etc/postfix/virtual ファイルは、かなり直接的な構文で、対応付けを記述します。すなわち、各行には空白で分割された 2 つのフィールドが含まれます。そして最初のフィールドは別名、2 番目のフィールドはリダイレクトする電子メールアドレスのリストです。@domain.com 特殊構文を使うことで、そのドメインに含まれるすべての残りの別名をカバーすることも可能です。

例 11.3 /etc/postfix/virtual ファイルの例

webmaster@falcotsbrand.com  jean@falcot.com
contact@falcotsbrand.com    laure@falcot.com, sophie@falcot.com
# The alias below is generic and covers all addresses within 
# the falcotsbrand.com domain not otherwise covered by this file.
# These addresses forward email to the same user name in the
# falcot.com domain.
@falcotsbrand.com           @falcot.com

11.1.2.2. 仮想メールボックスドメイン

仮想メールボックスドメイン宛のメッセージはローカルシステムユーザに割り当てられていないメールボックスに保存されます。
仮想メールボックスドメインを有効化するには、そのドメインを virtual_mailbox_domains 変数の中に含め、virtual_mailbox_maps で指定したメールボックスマッピングファイルで参照します。virtual_mailbox_base パラメータには、メールボックスが保存されるディレクトリが含まれます。
virtual_uid_maps (および virtual_gid_maps) パラメータは電子メールアドレスとそれに対応するメールボックスを「所有する」システムユーザ (およびグループ) の対応関係を含むファイルを参照します。すべてのメールボックスを同じ所有者とグループによって所有されるようにするには static:5000 構文を使って固定された UID/GID (ここでは 5000) を割り当てるようにします。

例 11.4 /etc/postfix/main.cf ファイルに追加する指示文

virtual_mailbox_domains = falcot.org
virtual_mailbox_maps = hash:/etc/postfix/vmailbox
virtual_mailbox_base = /var/mail/vhosts
繰り返しになりますが、/etc/postfix/vmailbox ファイルの構文はかなり直接的です。つまり、空白で分けられた 2 種類のフィールドです。最初のフィールドは仮想ドメインの 1 つに属する電子メールアドレスで、2 番目のフィールドは関連するメールボックスの場所です (これは virtual_mailbox_base 以下から見た相対ディレクトリパスを指定します)。メールボックスの名前がスラッシュ (/) で終わっていた場合、電子メールは maildir フォーマットで保存されます。一方、そうでなければ伝統的な mbox フォーマットで保存されます。maildir フォーマットはメールボックスを保存するためにディレクトリ全体を使い、それぞれのメッセージは 1 つのファイルとして保存されます。これに対して、mbox フォーマットでは、メールボックス全体が 1 つのファイルに保存されます。「From 」(From の後に 1 つの空白) で始まる行が新しいメッセージの始まる目印です。

例 11.5 /etc/postfix/vmailbox ファイル

# Jean's email is stored as maildir, with
# one file per email in a dedicated directory
jean@falcot.org falcot.org/jean/
# Sophie's email is stored in a traditional "mbox" file,
# with all mails concatenated into one single file
sophie@falcot.org falcot.org/sophie

11.1.3. 受信と送信の制限

迷惑メール (スパム) の数が増加したことにより、サーバが受け入れる電子メールの判断基準をますます厳しくすることが要求されるようになっています。この節では Postfix に含まれるいくつかの戦略を紹介します。

11.1.3.1. IP に基づくアクセス制限

smtpd_client_restrictions 指示文を使うことで、電子メールサーバと通信することを許すマシンを制御することが可能です。

例 11.6 クライアントアドレスに基づく制限

smtpd_client_restrictions = permit_mynetworks,
    warn_if_reject reject_unknown_client,
    check_client_access hash:/etc/postfix/access_clientip,
    reject_rbl_client sbl-xbl.spamhaus.org,
    reject_rbl_client list.dsbl.org
上に挙げた例のように、変数に複数のルールのリストを設定する場合、これらのルールは最初から最後まで順番に評価されます。それぞれのルールはメッセージを受け入れ、拒否し、次のルールに決定を任せることが可能です。その結果、順番が重要になります。単純に 2 つのルールを入れ替えることで、挙動が全く違うものになる場合があります。
最初のルールとして使われている permit_mynetworks 指示文により、ローカルネットワーク (mynetworks 設定変数によって定義された) 内のマシンからのすべての電子メールを受け入れるようになります。
2 番目の指示文により、完全に適切な DNS 設定のないマシンからの電子メールを通常拒否するようになります。ここで適切な設定とは、IP アドレスが名前に解決でき、その名前が IP アドレスに解決できることを意味しています。この基準は厳しすぎる場合が多いでしょう。なぜなら、多くの電子メールサーバは IP アドレスに対応する逆引き DNS を持っていないからです。このため、Falcot 管理者は warn_if_reject 修飾子を reject_unknown_client 指示文の前に起きました。warn_if_reject 修飾子を付けることで、拒否するのではなく警告をログに記録するようになります。管理者は、このルールが実際強制された場合に拒否されるかもしれないメッセージの数に目を光らせ、後から十分な情報に基づいてこのルールを強制するか否かを決断することが可能です。
3 番目の指示文を使うことで、管理者は /etc/postfix/access_clientip ファイルに保存された電子メールサーバのブラックリストとホワイトリストを設定することが可能になります。ホワイトリストに含まれるサーバは信頼され、このサーバから来る電子メールは以降のフィルタリングルールを適用されません。
最後の 2 つのルールにより、ブラックリストに含まれるサーバからのメッセージを拒否するようになります。RBL は Remote Black List の頭字語です。そして、ブラックリストは複数存在しますが、どれも、スパマーが電子メールを中継するために使う下手に設定されたサーバ、ワームやウイルスに感染したマシンのような本来の意図と異なりメール中継させられているサーバ、がリストされています。

11.1.3.2. EHLO または HELO コマンドの妥当性確認

SMTP でメールを送信するには、サーバに HELO (または EHLO) の後に送信元の名前を付けたコマンドを送ります。送信元の名前の妥当性を確認することは興味深いです。

例 11.7 EHLO の引数に与えられる名前の制限

smtpd_helo_restrictions = permit_mynetworks,
    reject_invalid_hostname,
    check_helo_access hash:/etc/postfix/access_helo,
    reject_non_fqdn_hostname,
    warn_if_reject reject_unknown_hostname
最初の permit_mynetworks 指示文を使うことで、ローカルネットワーク上のすべてのマシンならば、HELO コマンドの引数にどのような名前を使っても良いことになります。これは重要です。なぜなら、一部の電子メールプログラムは SMTP プロトコルのこの部分を十分適切に尊重せず、HELO の引数に無意味な名前を使います。
reject_invalid_hostname ルールを使うことで、EHLO で申告されたホスト名が構文的に不正な電子メールを拒否するようになります。reject_non_fqdn_hostname ルールを使うことで、申告されたホスト名が完全修飾ドメイン名 (ホスト名まで含むドメイン名) でないメッセージを拒否するようになります。reject_unknown_hostname ルールを使うことで、申告された名前が DNS に存在しないメッセージを拒否するようになります。最後のルールを適用すると、数多くの電子メールが拒否されることになるため、管理者は warn_if_reject 修飾子を付けて警告するだけにしています。管理者は reject_unknown_hostname ルールの結果を調査した後に、最後の段階で warn_if_reject 修飾子を削除するか判断します。
最初のルールに permit_mynetworks を使うと、面白い副作用があります。つまり、それ以降のルールがローカルネットワークの外のホストにのみ適用されるようになります。これを使うことで、自分を falcot.com の一部と申告するすべてのホストをブラックリスト化できます。これを行うには、たとえば falcot.com REJECT You are not in our network! 行を /etc/postfix/access_helo ファイルに追加します。

11.1.3.3. 申告された送信者に基づく受け入れおよび拒否

各メッセージには送信者があり、これは SMTP プロトコルの MAIL FROM コマンドで申告されます。さらに繰り返しになりますが、さまざまな異なる方法でこの情報の有効性を判断します。

例 11.8 送信者の確認

smtpd_sender_restrictions = 
    check_sender_access hash:/etc/postfix/access_sender,
    reject_unknown_sender_domain, reject_unlisted_sender,
    reject_non_fqdn_sender
/etc/postfix/access_sender テーブルを使うことで、一部の送信者を特別扱いすることが可能です。このテーブルは一部の送信者をホワイトリストやブラックリストに入れることを意味します。
reject_unknown_sender_domain ルールを使うことで、送信者アドレスに適切なドメインが含まれることを強制することが可能です。なぜなら、適切なアドレスならば必ず適切なドメインを含むからです。reject_unlisted_sender ルールを使うことで、アドレスが存在しないローカル送信者を拒否します。さらに reject_unlisted_sender ルールを使うことで、falcot.com ドメイン内の不正なアドレスから電子メールが送信されること避けることが可能で、joe.bloggs@falcot.com というアドレスが本当に存在するならば、そのアドレスから放出されるメッセージは受け入れられるようになります。
最後に、reject_non_fqdn_sender ルールを使うことで、完全修飾ドメイン名を持たないアドレスから送信されたと称する電子メールを拒否します。具体的には、user@machine からの電子メールを拒否します。すなわち、このアドレスは必ず user@machine.example.com または user@example.com の形で申告されなければいけません。

11.1.3.4. 受信アドレスに基づく受け入れまたは拒否

各電子メールには少なくとも 1 つの受信アドレスが必要です。SMTP プロトコルではこれを RCPT TO コマンドで申告します。送信アドレスに対して行った確認よりも関係性は低いとは言うものの、受信アドレスの正当性を確認することは当然です。

例 11.9 受信アドレスの確認

smtpd_recipient_restrictions = permit_mynetworks, 
    reject_unauth_destination, reject_unlisted_recipient, 
    reject_non_fqdn_recipient
reject_unauth_destination は基本的なルールで、受け入れ要求のあったメッセージが自分たち宛であることを確認します。そしてこのサーバにないアドレス宛のメッセージを拒否するようになります。このルールがない場合、サーバはスパマーが迷惑メールの送信に使う第三者中継サーバになります。このため reject_unauth_destination ルールは必須で、リストの最初に近い位置に置くのが最良です。そうすれば、メッセージの宛先をチェックする前に、他のルールがそのメッセージの受け入れを許可することを避けられます。
reject_unlisted_recipient ルールを使うことで、存在しないローカルユーザ宛のメッセージを拒否するようになります。これは道理に適ったルールです。最後に、reject_non_fqdn_recipient ルールを使うことで、完全修飾ドメイン名でないアドレスを拒否されるようになります。さらに reject_non_fqdn_recipient ルールを使った場合、jeanjean@machine 宛の電子メールは送信できず、その代わりに jean@machine.falcot.comjean@falcot.com などの完全なアドレスを使うことが要求されます。

11.1.3.5. DATA コマンドに関連付けられた制限

SMTP の DATA コマンドはメッセージ内容の前に送信されます。次に来るものはさておき、厳密な意味では DATA コマンドはいかなる情報も提供しません。とは言っても、確認することは可能です。

例 11.10 DATA の確認

smtpd_data_restrictions = reject_unauth_pipelining
reject_unauth_pipelining 指示文を使うことで、1 つ前に送信されたコマンドに応答する前に、送信者が次のコマンドを送ったメッセージを拒否するようになります。この防御は、スパマーロボットの使う一般的な最適化に対向するものです。なぜなら、スパマーはサーバからの応答の結果を気にせず、可能な限り短い時間で可能な限り大量の電子メールを送信することだけに注目しているからです。

11.1.3.6. 制限の適用

上のコマンドを使うことで、SMTP 交換のさまざまな段階で情報が検査されるにも関わらず、Postfix が実際の拒否を送信するのは、RCPT TO コマンドに対する応答の段階です。
これは、不正な EHLO コマンドが原因でメッセージを拒否する場合でも、Postfix はメッセージの送信者と受信者を知った後に、拒否応答を送信することを意味しています。こうすることで、すぐにトランザクションを拒否する場合よりも、より明確なログを残すことが可能です。加えて、多くの SMTP クライアントはトランザクションの最初の方の SMTP コマンドの失敗を予期していませんから、RCPT TO の後に拒否応答を返したとしても問題になることは少ないです。
こうすることによる利点の最後は、SMTP 交換のさまざまなステージの間にやり取りした情報を収集することが可能であるという点が挙げられます。これにより、パーミッションをきめ細かく調整することが可能です。たとえば、ローカル送信者のふりをする外部接続を拒否するなどが可能です。

11.1.3.7. メッセージ内容に基づくフィルタリング

メッセージ内容を確認することにより、妥当性確認と制限システムが完成します。Postfix は電子メール本文や電子メールヘッダの内容に対して確認を適用し、その妥当性を識別することが可能です。

例 11.11 内容に基づくフィルタの有効化

header_checks = regexp:/etc/postfix/header_checks
body_checks = regexp:/etc/postfix/body_checks
どちらのファイルにも、正規表現 (regexps または regexes としても知られる) のリストおよび、電子メールヘッダ (または本文) がその正規表現にマッチする場合に実行する動作の対応リストが含まれます。

例 11.12 /etc/postfix/header_checks ファイルの例

/^X-Mailer: GOTO Sarbacane/ REJECT I fight spam (GOTO Sarbacane)
/^Subject: *Your email contains VIRUSES/ DISCARD virus notification
最初の正規表現は電子メールソフトウェアに関するヘッダを確認します。そして GOTO Sarbacane (大量の電子メールを送信するソフトウェア) が見つかったら、メッセージを拒否します。2 番目の正規表現はメッセージの件名を操作します。そして、メッセージの件名にウイルス通知が含まれる場合、そのメッセージを拒否しない代わりにすぐに捨てます。
これらのフィルタを使うことは諸刃の剣です。なぜなら、一般的過ぎるルールを設定すれば、結果的に適切なメールを失うことになるからです。そのような場合、メッセージが失われるだけでなく、送信者は望まない (そして煩い) エラーメッセージを受け取ることになるでしょう。

11.1.4. greylisting の設定

「Greylisting」はフィルタリング技術です。この技術を使うことで、最初にメッセージを一時的なエラーコードとともに拒否し、少しの遅延の後に何回か試行すれば許可するというような挙動が可能です。このフィルタリングは特にワームとウイルスに侵された数多くのマシンが送信するスパムに対して効果的です。なぜなら、ワームやウイルスは完全な SMTP エージェントとして振る舞うことはほとんどない (エラーコードを確認して失敗したメッセージを後から再試行することはほとんどない) ですし、特に収集されたアドレスのほとんどは実際のところ無価値なアドレスであるという点を考慮すると、再試行は時間の無駄にしかならないからです。
Postfix それ自身は greylisting 機能を提供しませんが、あるメッセージを受け入れるか拒否するかの決定を外部プログラムに委任する機能を提供します。postgrey パッケージには greylisting 機能を提供するプログラムが含まれ、アクセスポリシー委任サービスへのインターフェースとして設計されています。
postgrey がインストールされると、postgrey はデーモンとして実行され、ポート 10023 番をリッスンします。この後 Postfix を設定します。check_policy_service パラメータを追加的制限として追加することで、postgrey を使うようになります。
smtpd_recipient_restrictions = permit_mynetworks,
    [...]
    check_policy_service inet:127.0.0.1:10023
Postfix はルールセットの中にあるこのルールに到達したら、postgrey デーモンに接続し、対応するメッセージに関する情報をデーモンに送信します。Postgrey は IP アドレス/送信者/受信者の三つぞろいを考慮し、同じ三つぞろいが最近データベースに登録されたか否かをデータベースで確認します。最近登録されていた場合、Postgrey はメッセージを受け入れるべきであると応答します。さらに、最近登録されていなかった場合、Postgrey はメッセージを一時的に拒否するべきであると応答し、三つぞろいをデータベースに登録します。
greylisting の主な不都合は、正当なメッセージの配送が遅れる点です。これは常に受け入れられる欠点とは限りません。また、送信するメールのほとんどが正当な場合、greylisting はサーバの負荷を増加させます。

11.1.5. 受信アドレスに基づくフィルタのカスタマイズ

第 11.1.3 節「受信と送信の制限」および第 11.1.4 節「greylisting の設定」では、さまざまな制限方法を見直しました。これらの制限方法はスパムの受信量を減らすためのものですが、欠点もあります。このため、受信者ごとにフィルタのセットをカスタマイズすることが普通のやり方になりつつあります。Falcot Corp では、greylisting は多くのユーザにとって興味深いものでしたが、電子メールを素早く受け取りたい一部のユーザ (たとえば技術サポートサービスなどの) にとっては仕事の妨げになります。同様に、商業サービスにとっては、ブラックリストに載っているかもしれない一部のアジアプロバイダから送信された電子メールを受信できない点は問題となります。従って、商業サービス用のアドレスに対してはフィルタリングを行わず、これらの送信者と連絡が取れるようにするほうが好都合でしょう。
Postfix は「制限クラス」の概念を使ってフィルタをカスタマイズします。制限クラスは smtpd_restriction_classes パラメータの中で宣言され、smtpd_recipient_restrictions と同じやり方で使用されます。check_recipient_access 指示文は与えられた受信者と制限の適切なセットを対応付けるテーブルを定義します。

例 11.13 main.cf 内の制限クラスの定義

smtpd_restriction_classes = greylisting, aggressive, permissive

greylisting = check_policy_service inet:127.0.0.1:10023
aggressive = reject_rbl_client sbl-xbl.spamhaus.org,
        check_policy_service inet:127.0.0.1:10023
permissive = permit

smtpd_recipient_restrictions = permit_mynetworks,
        reject_unauth_destination,
        check_recipient_access hash:/etc/postfix/recipient_access

例 11.14 /etc/postfix/recipient_access ファイル

# Unfiltered addresses
postmaster@falcot.com  permissive
support@falcot.com     permissive
sales-asia@falcot.com  permissive

# Aggressive filtering for some privileged users
joe@falcot.com         aggressive

# Special rule for the mailing-list manager
sympa@falcot.com       reject_unverified_sender

# Greylisting by default
falcot.com             greylisting

11.1.6. アンチウイルスの統合

数多くのウイルスが電子メールの添付ファイルとして配布されているため、会社のネットワークの入口にアンチウイルスをセットアップすることが重要です。なぜなら、啓発活動にも関わらず、一部のユーザは明らかに疑わしいメッセージの添付ファイルを開くことができるからです。
Falcot 管理者はフリーのアンチウイルスとして clamav を選びました。主要なパッケージは clamav ですが、arjunzoounrarlha などのいくつかのパッケージを追加でインストールしました。なぜなら、これらのパッケージはアンチウイルスがそれらのフォーマットで圧縮された添付ファイルを解析する際に必要だからです。
clamav-milter はアンチウイルスと電子メールサーバの間を接続する作業を担当します。milter (mail filter の略) とは、電子メールサーバに対するインターフェースとして特別に設計されたフィルタプログラムです。milter は標準的なアプリケーションプログラミングインターフェース (API) を使います。API を使うことで、電子メールサーバ外のフィルタの性能が向上します。Milter は 最初 Sendmail に導入されましたが、Postfix がすぐに後に続きました。
clamav-milter パッケージをインストールしたら、milter をデフォルトのポートではない適当な TCP ポートで実行するように再設定するべきです。これを行うには、dpkg-reconfigure clamav-milter を実行します。そして「Communication interface with Sendmail」が表示されたら「inet:10002@127.0.0.1」と答えます。
ClamAV の標準的な設定はほとんどの状況に適合しますが、dpkg-reconfigure clamav-base を使えばいくつかの重要なパラメータをカスタマイズすることも可能です。
最後の段階で、最近設定したフィルタを使うように Postfix を設定します。これは簡単です。/etc/postfix/main.cf に以下の指示文を追加します。
# Virus check with clamav-milter
smtpd_milters = inet:[127.0.0.1]:10002
アンチウイルスによって問題が起こる場合、この行をコメントアウトして、service postfix reload を実行します。これでこの変更が反映されます。
これで Postfix を介して送信されるすべてのメッセージはアンチウイルスフィルタを通過するようになります。

11.1.7. SMTP 認証

電子メールを送信するには、SMTP サーバにアクセスする必要があります。さらに、電子メールを送信するには上で設定した SMTP サーバが必要です。ローミングユーザの場合、SMTP クライアントの設定を定期的に変更する必要があるかもしれません。なぜなら、Falcot の SMTP サーバは明らかに会社に所属しない IP アドレスから受け取ったメッセージを拒否するからです。2 つの解決策が存在します。すなわち、ローミングユーザが自分のコンピュータに SMTP サーバをインストールするか、雇用者としての認証を済ませた後に会社のサーバを使うかのどちらか一方です。自分の SMTP サーバをインストールするという解決策は推奨されません。なぜなら、コンピュータは永久的に接続されているわけではないからです。さらに、問題の起きた際にメッセージを再送信することができないからです。われわれは認証を行うという解決策に注目します。
Postfix の SMTP 認証は SASL (Simple Authentication and Security Layer) を使っています。SASL を使うには、libsasl2-modulessasl2-bin パッケージをインストールすることと、SASL データベースに SMTP サーバの認証に必要なパスワードをユーザごとに登録すること、が必要です。これを行うには、saslpasswd2 コマンドを使います。このコマンドはいくつかのパラメータを取ります。-u オプションは認証するドメインを定義します。これは Postfix 設定の smtpd_sasl_local_domain パラメータと一致しなければいけません。-c オプションはユーザを作成します。-f は SASL データベースをデフォルト (/etc/sasldb2) とは異なる場所に保存することが必要な場合、データベースファイルの位置を指定します。
# saslpasswd2 -u `postconf -h myhostname` -f /var/spool/postfix/etc/sasldb2 -c jean
[... jean のパスワードを 2 回入力 ...]
SASL データベースは Postfix ディレクトリの中に作成されなければいけない点に注意してください。整合性を確保するために、ln -sf /var/spool/postfix/etc/sasldb2 /etc/sasldb2 コマンドを使って /etc/sasldb2 を Postfix の使うデータベースを指すシンボリックリンクにします。
この後に Postfix が SASL を使うように設定します。postfix ユーザを sasl グループに追加して、SASL アカウントデータベースにアクセスできるようにします。Postfix で SASL を有効化するには、いくつかの新しいパラメータが必要です。また、SASL 認証されたクライアントが自由に電子メールを送信することを許可するには、smtpd_recipient_restrictions パラメータを設定します。

例 11.15 /etc/postfix/main.cf の中で SASL を有効化

# Enable SASL authentication
smtpd_sasl_auth_enable = yes
# Define the SASL authentication domain to use
smtpd_sasl_local_domain = $myhostname
[...]
# Adding permit_sasl_authenticated before reject_unauth_destination
# allows relaying mail sent by SASL-authenticated users
smtpd_recipient_restrictions = permit_mynetworks,
    permit_sasl_authenticated,
    reject_unauth_destination,
[...]