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. Fighting Spam with SPF, DKIM and DMARC
11.1.8. SMTP 認証
11.2. ウェブサーバ (HTTP)
11.2.1. Apache のインストール
11.2.2. Adding support for SSL
11.2.3. 仮想ホストの設定
11.2.4. よく使われる指示文
11.2.5. ログ解析ソフトウェア
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 の追加
Network services are the programs that users interact with directly in their daily work. They are the tip of the information system iceberg, and this chapter focuses on them; the hidden parts they rely on are the infrastructure we already described. They usually require the encryption technology described in 第 10.2 節「X.509 certificates」.

11.1. メールサーバ

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

11.1.1. Postfix のインストール

The postfix package includes the main SMTP daemon. Other packages (such as postfix-ldap and postfix-pgsql) add extra functionality to Postfix, including access to mapping databases. You should only install them if you know that you need them.
Debconf はパッケージのインストール中にいくつかの質問を行います。これに答えることで、/etc/postfix/main.cf 設定ファイルの最初のバージョンが作成されます。
最初の質問はセットアップの形式に関するものです。インターネットに接続されたサーバに関連するのは提案された選択肢のうちの 2 種類だけです。「インターネットサイト」と「スマートホスト付きインターネット」です。「インターネットサイト」は入って来る電子メールを受け取り、外に出る電子メールを直接受信者に送信するサーバに適します。つまり Falcot Corp の場合にうまく適合します。「スマートホスト付きインターネット」は入って来る電子メールを通常通り受け取り、外に出る電子メールを直接受信者のサーバに送信するのではなく中間 SMTP サーバ「スマートホスト」を介して送信するサーバに適します。この選択肢は主に動的 IP アドレスを持つマシンで役に立ちます。なぜなら、多くの電子メールサーバは動的 IP アドレスを持つホストから配送されたメッセージを拒否するからです。この選択肢を選んだ場合、通常スマートホストに自分の ISP の SMTP サーバを設定します。ISP の SMTP サーバは自分の顧客からの電子メールを受け入れ、それを適切に転送するよう常に設定されています。この (スマートホストを使う) 選択肢はさらにインターネットから切断される可能性のあるサーバにも適しています。なぜなら、後から再試行する必要のある未配送メッセージのキューを管理する必要がなくなるからです。
2 番目の質問はマシンのフルネームに関するもので、これはローカルユーザの電子メールアドレスを生成するために使われます。従って、マシンのフルネームとはアットマーク (「@」) のすぐ後ろに付けられるものです。Falcot の場合、この質問には mail.falcot.com と答えるべきです。デフォルトで聞かれる質問は以上ですが、Falcot にとってこの状態の Postfix はまだ十分に設定されていません。このため、管理者は dpkg-reconfigure postfix を実行してさらに多くのパラメータをカスタマイズします。
dpkg-reconfigure postfix を実行したことで追加的に行われる質問の 1 つに、このマシンに関連するすべてのドメイン名を尋ねる質問があります。デフォルトで挙げられるドメイン名のリストには、マシンのフルネームといくつかの localhost の同義語が含まれていますが、主要なドメイン名である falcot.com を手作業で追加する必要があります。より一般的に言えば、この質問の回答には、通常 MX サーバを担当しているマシンに割り当てたすべてのドメイン名を含めるべきです。さらに言い換えれば、DNS の MX レコードを参照した際に電子メールを受け入れるサーバとして登録されているすべてのドメイン名を含めるべきです。この情報は最終的に Postfix 主要設定ファイル /etc/postfix/main.cfmydestination 変数に設定されます。
メール送信における DNS MX レコードの役割

図 11.1 メール送信における DNS MX レコードの役割

インストール中に、このサーバが電子メールの送信要求を受け入れるネットワークを尋ねられる場合があります。デフォルトの設定で、Postfix はマシン自身からの電子メールの送信要求だけを受け入れます。従って、通常はローカルネットワークからの送信要求も受け入れるように設定します。Falcot Corp の管理者はデフォルトの回答に 192.168.0.0/16 を追加しました。この質問が尋ねられなければ、以下の例に示す通り、設定ファイル中の関連する変数 mynetworks にローカルネットワークを追加します。
Local email can also be delivered through procmail. This tool allows users to sort their incoming email according to rules stored in their ~/.procmailrc file. Both Postfix and Exim4 suggest procmail by default, but there are alternatives like maildrop or Sieve filters.
最初のステップの後、以下の設定ファイルが得られます。さらに次の節では、いくつかの特別な機能を追加するための足掛かりとしてこれを使います。

例 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

# See http://www.postfix.org/COMPATIBILITY_README.html -- default to 2 on
# fresh installs.
compatibility_level = 2



# 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_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 変数でアドレスマッピングファイルを参照します。
virtual_alias_domains = falcotsbrand.com
virtual_alias_maps = hash:/etc/postfix/virtual
/etc/postfix/virtual ファイルはかなり直接的な構文で対応付けを記述します。すなわち、各行には空白で分割された 2 つのフィールドが含まれます。最初のフィールドは仮想エイリアス名、2 番目のフィールドはリダイレクトする電子メールアドレスのリストです。@domain.com 特殊構文を使うことで、そのドメインに含まれるすべての残りの別名をカバーすることも可能です。
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
After changing /etc/postfix/virtual the postfix table /etc/postfix/virtual.db needs to be updated using sudo postmap /etc/postfix/virtual.

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

仮想メールボックスドメイン宛のメッセージはローカルシステムユーザに割り当てられていないメールボックスに保存されます。
仮想メールボックスドメインを有効化するには、virtual_mailbox_domains 変数にそのドメイン名を追加し、virtual_mailbox_maps 変数でメールボックスマッピングファイルを参照します。virtual_mailbox_base パラメータには、メールボックスが保存されるディレクトリを指定します。
virtual_mailbox_domains = falcot.org
virtual_mailbox_maps = hash:/etc/postfix/vmailbox
virtual_mailbox_base = /var/mail/vhosts
virtual_uid_maps (および virtual_gid_maps) パラメータは電子メールアドレスとそれに対応するメールボックスを「所有する」システムユーザ (およびグループ) の対応関係を含むファイルを参照します。すべてのメールボックスを同じ所有者とグループによって所有されるようにするには static:5000 構文を使って固定された UID/GID (ここでは 5000) を割り当てるようにします。
繰り返しになりますが、/etc/postfix/vmailbox ファイルの構文はかなり直接的です。つまり、空白で分けられた 2 種類のフィールドで対応関係を表現します。最初のフィールドは仮想ドメインの 1 つに属する電子メールアドレスで、2 番目のフィールドは関連するメールボックスの場所です (これは virtual_mailbox_base 以下から見た相対ディレクトリパスを指定します)。メールボックスの名前がスラッシュ (/) で終わっていた場合、電子メールは maildir フォーマットで保存されます。一方、そうでなければ伝統的な mbox フォーマットで保存されます。maildir フォーマットはメールボックスを保存するためにディレクトリ全体を使い、それぞれのメッセージは 1 つのファイルとして保存されます。これに対して、mbox フォーマットでは、メールボックス全体が 1 つのファイルに保存されます。「From 」(From の後に 1 つの空白) で始まる行が新しいメッセージの始まる目印です。
# Jean 宛の電子メールは専用ディレクトリ内の 1 ファイルを
# 1 メールに対応付ける maildir フォーマットで保存されます
jean@falcot.org falcot.org/jean/
# Sophie 宛の電子メールは 1 ファイルにすべてのメールを
# 連結する伝統的な "mbox" ファイルに保存されます
sophie@falcot.org falcot.org/sophie

11.1.3. 受信と送信の制限

迷惑メール (スパム) の数が増加したことにより、サーバが受け入れる電子メールの判断基準をますます厳しくすることが要求されるようになっています。この節では Postfix が備えるいくつかの戦略を紹介します。
If the reject-rules are too strict, it may happen that even legitimate email traffic gets locked out. It is therefor a good habit to test restrictions and prevent the permanent rejection of requests during this time using the soft_bounce = yes directive. By prepending a reject-type directive with warn_if_reject only a log message will be recorded instead of rejecting the request.

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

smtpd_client_restrictions 指示文を使うことで、電子メールサーバと通信することを許すマシンを制御することが可能です。
When a variable contains a list of rules, as in the example below, these rules are evaluated in order, from the first to the last. Each rule can accept the message, reject it, or leave the decision to a following rule. As a consequence, order matters, and simply switching two rules can lead to a widely different behavior.

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

smtpd_client_restrictions =
    permit_mynetworks,
    warn_if_reject reject_unknown_client_hostname,
    check_client_access hash:/etc/postfix/access_clientip,
    reject_rhsbl_reverse_client dbl.spamhaus.org,
    reject_rhsbl_reverse_client rhsbl.sorbs.net,
    reject_rbl_client zen.spamhaus.org,
    reject_rbl_client dnsbl.sorbs.net
The permit_mynetworks directive, used as the first rule, accepts all emails coming from a machine in the local network (as defined by the mynetworks configuration variable).
The second directive would normally reject emails coming from machines without a completely valid DNS configuration. Such a valid configuration means that the IP address can be resolved to a name, and that this name, in turn, resolves to the IP address. This restriction is often too strict, since many email servers do not have a reverse DNS for their IP address. This explains why the Falcot administrators prepended the warn_if_reject modifier to the reject_unknown_client directive: this modifier turns the rejection into a simple warning recorded in the logs. The administrators can then keep an eye on the number of messages that would be rejected if the rule were actually enforced, and make an informed decision later if they wish to enable such enforcement.
check_client_access 指示文を使うことで、管理者は /etc/postfix/access_clientip ファイルに保存された電子メールサーバのブラックリストとホワイトリストを設定することが可能になります。ホワイトリストに含まれるサーバは信頼され、このサーバから来る電子メールは以降のフィルタリングルールを適用されません。
The last four rules reject any message coming from a server listed in one of the indicated blacklists. RBL is an acronym for Remote Black List, and RHSBL stands for Right-Hand Side Black List. The difference is, that the former lists IP addresses, whereas the latter lists domain names. There are several such services. They list domains and IP addresses with poor reputation, badly configured servers that spammers use to relay their emails, as well as unexpected mail relays such as machines infected with worms or viruses.

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

Each SMTP exchange starts with a HELO (or EHLO) command, followed by the name of the sending email server. Checking the validity of this name can be interesting. To fully enforce the restrictions listed in smtpd_helo_restrictions the smtpd_helo_required option needs to be enabled. Otherwise clients could skip the restrictions by not sending any HELO/EHLO command.

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

smtpd_helo_required = yes
smtpd_helo_restrictions =
    permit_mynetworks,
    reject_invalid_helo_hostname,
    reject_non_fqdn_helo_hostname,
    warn_if_reject reject_unknown_helo_hostname,
    check_helo_access hash:/etc/postfix/access_helo,
    reject_rhsbl_helo multi.surbl.org
最初の permit_mynetworks 指示文を使うことで、ローカルネットワーク上のすべてのマシンならば HELO コマンドの引数にどのような名前を使っても良いことになります。これは重要です。なぜなら、一部の電子メールプログラムは SMTP プロトコルのこの部分を十分適切に尊重せず HELO の引数に無意味な名前を使うからです。
The reject_invalid_helo_hostname rule rejects emails when the EHLO announce lists a syntactically incorrect hostname. The reject_non_fqdn_helo_hostname rule rejects messages when the announced hostname is not a fully-qualified domain name (including a domain name as well as a host name). The reject_unknown_helo_hostname rule rejects messages if the announced name does not exist in the DNS. Since this last rule unfortunately leads to too many rejections, the administrators turned its effect to a simple warning with the warn_if_reject modifier as a first step; they may decide to remove this modifier at a later stage, after auditing the results of this rule.
The reject_rhsbl_helo allows to specify a black list to check the hostname against an RHSBL.
Using permit_mynetworks as the first rule has an interesting side effect: the following rules only apply to hosts outside the local network. This allows blacklisting all hosts that announce themselves as part of the falcot.com network, for instance by adding a falcot.com REJECT You are not in our network! line to the /etc/postfix/access_helo file.

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

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

例 11.4 送信者アドレスの確認

smtpd_sender_restrictions =
    check_sender_access hash:/etc/postfix/access_sender,
    reject_unknown_sender_domain,
    reject_unlisted_sender,
    reject_non_fqdn_sender,
    reject_rhsbl_sender rhsbl.sorbs.net
check_sender_access ルールを使うことで、/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 の形で申告されなければいけないということです。
The reject_rhsbl_sender rule reject senders based on a (domain-based) RHSBL service.

11.1.3.4. 受信者アドレスに基づく受け入れおよび拒否

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

例 11.5 受信者アドレスの確認

smtpd_recipient_restrictions =
    permit_mynetworks,
    reject_unauth_destination,
    reject_unlisted_recipient,
    reject_non_fqdn_recipient,
    permit
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 などの完全なアドレスを使うことが要求されます。
The permit directive at the end is not necessary. But it can be useful at the end of a restriction list to make the default policy explicit.

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

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

例 11.6 DATA の確認

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

11.1.3.6. 拒否応答の送信段階

Although the above commands validate information at various stages of the SMTP exchange, Postfix sends the actual rejection as a reply to the RCPT TO command by default.
これは不正な EHLO コマンドが原因でメッセージを拒否する場合でも、Postfix はメッセージの送信者と受信者を知った後に拒否応答を送信することを意味しています。こうすることで、すぐにトランザクションを拒否するよりも明確なログを残すことが可能です。加えて、多くの SMTP クライアントはトランザクションの最初の方の SMTP コマンドの失敗を予期していませんから、RCPT TO の後に拒否応答を返したとしても問題になることは少ないです。
こうすることによる最後の利点は SMTP 交換のさまざまなステージの間にやり取りした情報を総合的に検討することが可能であるという点です。これにより、パーミッションをきめ細かく調整することが可能です。たとえば、ローカル送信者のふりをする外部接続を拒否することなどが可能です。
The default behavior is controlled by the smtpd_delay_reject rule.

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

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

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

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

例 11.8 /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」はフィルタリング技術です。「greylisting」を使うことで、最初にメッセージを一時的なエラーコードとともに拒否し、少しの遅延の後に何回か試行すれば許可するというような挙動が可能です。「greylisting」は特にワームとウイルスに侵された数多くのマシンが送信するスパムに対して効果的です。なぜなら、ワームやウイルスは完全な SMTP エージェントとして振る舞うことはほとんどない (エラーコードを確認して失敗したメッセージを後から再試行することはほとんどない) ですし、特に収集されたアドレスのほとんどは実際のところ無価値なアドレスであるという点を考慮すると、再試行は時間の無駄にしかならないからです。
Postfix それ自身は greylisting 機能を提供しませんが、あるメッセージを受け入れるか拒否するかの決定を外部プログラムに委任する機能を提供します。postgrey パッケージには greylisting 機能を提供するプログラムが含まれ、このプログラムはアクセスポリシー委任サービスへのインターフェースとして設計されています。
postgrey がインストールされると、postgrey はデーモンとして実行され、ポート 10023 番をリッスンします。この後 Postfix の設定に check_policy_service ルールを追加することで、Postfix は 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.9 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.10 /etc/postfix/recipient_access ファイル

# 無制限に受信するアドレス
postmaster@falcot.com  permissive
support@falcot.com     permissive
sales-asia@falcot.com  permissive

# 特権ユーザに対する積極的なフィルタリング
joe@falcot.com         aggressive

# メーリングリスト管理者用の特別なルール
sympa@falcot.com       reject_unverified_sender

# デフォルトの greylisting 設定
falcot.com             greylisting

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

数多くのウイルスが電子メールの添付ファイルとして配布されているため、会社のネットワークの入口にアンチウイルスをセットアップすることは重要です。なぜなら、啓発活動にも関わらず、明らかに疑わしいメッセージの添付ファイルを開けてしまうユーザがいるからです。
Falcot の管理者は自由なアンチウイルスとして clamav を選びました。clamav の主パッケージは clamav ですが、arjunzoounrarlha などのいくつかのパッケージを追加でインストールしました。なぜなら、これらのパッケージはアンチウイルスがそれらのフォーマットで圧縮された添付ファイルを解析する際に必要だからです。
clamav-milter はアンチウイルスと電子メールサーバのやり取りを仲介する作業を担当します。milter (mail filter の略) は電子メールサーバに対するインターフェースとして特別に設計されたフィルタプログラムです。milter は標準的なアプリケーションプログラミングインターフェース (API) を使います。API を使うことで電子メールサーバの外にあるフィルタを使うよりも性能が向上します。milter は 最初 Sendmail に導入されましたが、すぐ後に Postfix にも導入されました。
clamav-milter パッケージをインストールしたら、milter をデフォルトのポートではない適当な TCP ポートで実行するように再設定するべきです。これを行うには、dpkg-reconfigure clamav-milter を実行します。そして「Sendmail とのコミュニケーションインターフェイス」が表示されたら「inet:10002@127.0.0.1」と答えます。
ClamAV の標準的な設定は多くの状況に適合しますが、dpkg-reconfigure clamav-base を使えばいくつかの重要なパラメータをカスタマイズすることも可能です。
最後の段階で、最近設定したフィルタを使うように Postfix を設定します。これは /etc/postfix/main.cf に以下の指示文を追加するだけで簡単に設定できます。
# clamav-milter を使ったウイルスチェック
smtpd_milters = inet:[127.0.0.1]:10002
If the antivirus causes problems, this line can be commented out, and systemctl reload postfix should be run so that this change is taken into account.
これで Postfix を介して送信されるすべてのメッセージはアンチウイルスフィルタを通過するようになります。

11.1.7. Fighting Spam with SPF, DKIM and DMARC

The high number of unsolicited email sent every day led to the creation of several standards, which aim at validating, that the sending host of an email is authorized and that the email has not been tampered with. The following systems are all DNS-based and require the administrators to not only have control over the mail server, but over the DNS for the domain in question too.

11.1.7.1. Integrating the Sender Policy Framework (SPF)

The Sender Policy Framework (SPF) is used to validate if a certain mail server is allowed to send emails for a given domain. It is mostly configured through DNS. The syntax for the entry to make is explained in detail at:
The following is a sample DNS entry which states that all the domain's Mail Exchange Resource Records (MX-RRs) are allowed to email the current domain, and all others are prohibited. The DNS entry does not need to be given a name. But to use the include directive it must have one.
Name: example.org
Type: TXT
TTL:  3600
Data: v=spf1 a mx -all
Let's take a quick look at the falcot.org entry.
# host -t TXT falcot.org
falcot.org descriptive text "v=spf1 ip4:199.127.61.96 +a +mx +ip4:206.221.184.234 +ip4:209.222.96.251 ~all"
It states, that the IP of the sender must match the A record for the sending domain, or must be listed as one of the Mail Exchange Resource Records for the current domain, or must be one of the three mentioned IP4 addresses. All other hosts should be marked as not being allowed to send email for the sender domain. The latter is called a "soft fail" and is intended to mark the email accordingly, but still accept it.
The postfix mail server can check the SPF record for incoming emails using the postfix-policyd-spf-python package, a policy agent written in Python. The file /usr/share/doc/postfix-policyd-spf-python/README.Debian describes the necessary steps to integrate the agent into postfix, so we won't repeat it here.
The configuration is done in the file /etc/postfix-policyd-spf-python/policyd-spf.conf, which is fully documented in policyd-spf.conf(5) and /usr/share/doc/postfix-policyd-spf-python/policyd-spf.conf.commented.gz. The main configuration parameters are HELO_reject and Mail_From_reject, which configure if emails should be rejected (Fail) or accepted with a header being appended (False), if checks fail. The latter is often useful, when the message is further processed by a spam filter.
If the result is intended to be used by opendmarc (第 11.1.7.3 節「Integrating Domain-based Message Authentication, Reporting and Conformance (DMARC)」), then Header_Type must be set to AR.
Note, that spamassassin contains a plugin to check the SPF record.

11.1.7.2. Integrating DomainKeys (DKIM) Signing and Checking

The Domain Keys Identified Mail (DKIM) standard is a sender authentication system. The mail transport agent, here postfix, adds a digital signature associated with the domain name to the header of outgoing emails. The receiving party can validate the message body and header fields by checking the signature against a public key, which is retrieved from the senders DNS records.
The necessary tools are shipped with the opendkim and opendkim-tools packages.
First the private key must be created using the command opendkim-genkey -s SELECTOR -d DOMAIN. SELECTOR must be a unique name for the key. It can be as simple as "mail" or the date of creation, if you plan to rotate keys.

例 11.11 Create a private key for signing E-Mails from falcot.com

# opendkim-genkey -s mail -d falcot.com -D /etc/dkimkeys
# chown opendkim.opendkim /etc/dkimkeys/mail.*
This will create the files /etc/dkimkeys/mail.private and /etc/dkimkeys/mail.txt and set the appropriate ownership. The first file contains the private key and the latter the public key, that needs to be added to the DNS:
Name: mail._domainkey
Type: TXT
TTL:  3600
Data: "v=DKIM1; h=sha256; k=rsa; s=email; p=[...]"
The opendkim package in Debian defaults to a keysize of 2048 bit. Unfortunately some DNS servers can only handle text entries with a maximum length of 255 characters, which is exceeded by the chosen default keysize. In this case use the option -b 1024 to chose a smaller keysize. If opendkim-testkey succeeds, the entry has been successfully set up. The syntax of the entry is explained here:
To configure opendkim, SOCKET and RUNDIR must be chosen in /etc/default/opendkim. Please note that SOCKET must be accessible from postfix in its chrooted environment. The further configuration is done in /etc/opendkim.conf. The following is a configuration excerpt, which makes sure that the Domain "falcot.com" and all subdomains (SubDomain) are signed by the Selector "mail" and the single private key (KeyFile) /etc/dkimkeys/mail.private. The "relaxed" Canonicalization for both the header and the body tolerates mild modification (by a mailing list software, for example). The filter runs both in signing ("s") and verification ("v") Mode. If a signature fails to validate (On-BadSignature), the mail should be quarantined ("q").
[...]
Domain                  falcot.com
KeyFile                 /etc/dkimkeys/mail.private
Selector                mail

[...]
Canonicalization        relaxed/relaxed
Mode                    sv
On-BadSignature         q
SubDomains              yes

[...]
Socket                  inet:12345@localhost

[...]
UserID                  opendkim
It is also possible to use multiple selectors/keys (KeyTable), domains (SigningTable) and to specify internal or trusted hosts (InternalHosts, ExternalIgnoreList), which may send mail through the server as one of the signing domains without credentials.
The following directives in /etc/postfix/main.cf make postfix use the filter:
milter_default_action = accept
non_smtpd_milters = inet:localhost:12345
smtpd_milters = inet:localhost:12345
To differentiate signing and verification it is sometimes more useful to add the directives to the services in /etc/postfix/master.cf instead.
More information is available in the /usr/share/doc/opendkim/ directory and the manual pages opendkim(8) and opendkim.conf(5).
Note that spamassassin contains a plugin to check the DKIM record.

11.1.7.3. Integrating Domain-based Message Authentication, Reporting and Conformance (DMARC)

The Domain-based Message Authentication, Reporting and Conformance (DMARC) standard can be used to define a DNS TXT entry with the name _dmarc and the action, that should be taken, when emails, which contain your domain as sending host, fail to validate using DKIM and SPF.
Let's have a look at the entries of two large providers:
# host -t TXT _dmarc.gmail.com
_dmarc.gmail.com descriptive text "v=DMARC1; p=none; sp=quarantine; rua=mailto:mailauth-reports@google.com"
# host -t TXT _dmarc.yahoo.com
_dmarc.yahoo.com descriptive text "v=DMARC1; p=reject; pct=100; rua=mailto:dmarc_y_rua@yahoo.com;"
Yahoo has a strict policy to reject all emails pretending to be sent from a Yahoo account but missing or failing DKIM and SPF checks. Google Mail (Gmail) propagates a very relaxed policy, in which such messages from the main domain should still be accepted (p=none). For subdomains they should be marked as spam (sp=quarantine). The addresses given in the rua key can be used to send aggregated DMARC reports to. The full syntax is explained here:
The postfix mail server can use this information too. The opendmarc package contains the necessary milter. Similar to opendkim SOCKET and RUNDIR must be chosen in /etc/default/opendmarc (for Unix sockets you must make sure, that they are inside the postfix chroot to be found). The configuration file /etc/opendmarc.conf contains detailed comments and is also explained in opendmarc.conf(5). By default, emails failing the DMARC validation are not rejected but flagged, by adding an appropriate header field. To change this, use RejectFailures true.
The milter is then added to smtpd_milters and non_smtpd_milters. If we configured the opendkim and opendmarc milters to run on ports 12345 and 54321, the entry in /etc/postfix/main.cf looks like this:
non_smtpd_milters = inet:localhost:12345,inet:localhost:54321
smtpd_milters = inet:localhost:12345,inet:localhost:54321
The milter can also be selectively applied to a service in /etc/postfix/master.cf instead.

11.1.8. 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 コマンドを使います。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.12 /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_sasl_authenticated,
    permit_mynetworks,
    reject_unauth_destination,
[...]
It is usually a good idea to not send passwords over an unencrypted connection. Postfix allows to use different configurations for each port (service) it runs on. All these can be configured with different rules and directives in the /etc/postfix/master.cf file. To turn off authentication at all for port 25 (smtpd service) add the following directive:
smtp      inet  n       -       y       -       -       smtpd
    [..]
    -o smtpd_sasl_auth_enable=no
    [..]
If for some reason clients use an outdated AUTH command (some very old mail clients do), interoperability with them can be enabled using the broken_sasl_auth_clients directive.