Product SiteDocumentation Site

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

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

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're 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. 受信アドレスに基づくフィルタのカスタマイズ

上の 2 つの節で、様々な制限方法を見直しました。これらの制限方法はスパムの受信量を減らすためのものですが、欠点もあります。このため、受信者毎にフィルタのセットをカスタマイズする事が普通のやり方になりつつあります。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
アンチウイルスによって問題が起こる場合、この行をコメントアウトして、/etc/init.d/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
[... type jean's password twice ...]
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,
[...]