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

ネットワークサービスはユーザが毎日の仕事で直接使用するプログラムです。ネットワークサービスは情報システムの氷山の一角で、この章ではネットワークサービスに注目します。そして、水面下に隠された部分は既に説明したインフラに依存しています。ネットワークサービスは通常、第 10.2 節「X.509 certificates」に記述された暗号化技術を使用します。

11.1. メールサーバ

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

ALTERNATIVE Exim4 サーバ

Debian はデフォルト電子メールサーバとして Exim4 を使います (そのため Exim4 は Debian の初回インストール時に導入されます)。Exim4 の設定は別のパッケージ exim4-config で提供され、Debconf を使った一連の質問に答えることで自動的にカスタマイズされます。この質問は postfix パッケージの行う質問とよく似ています。

設定は単独の設定ファイル (/etc/exim4/exim4.conf.template) か /etc/exim4/conf.d/ の下に保存された数多くの設定ファイルを通じて行われます。どちらの場合も、update-exim4.conf が設定ファイルをテンプレートとして利用して /var/lib/exim4/config.autogenerated を生成します。実際 Exim4 が使うファイルが /var/lib/exim4/config.autogenerated です。このメカニズムのおかげで、debconf を通じて Exim に設定した値 (/etc/exim4/update-exim4.conf.conf に保存されている値) は管理者や他のパッケージがデフォルトの Exim 設定を変更した場合でも Exim の設定ファイルに反映されます。

The Exim4 configuration file syntax has its peculiarities and its learning curve; however, once these peculiarities are understood, Exim4 is a very complete and powerful email server, as evidenced by the tens of pages of documentation.

→ https://www.exim.org/docs.html

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.cf の mydestination 変数に設定されます。

図 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_tls_security_level=may

smtp_tls_CApath=/etc/ssl/certs
smtp_tls_security_level=may
smtp_tls_session_cache_database = btree:${data_directory}/smtp_scache


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
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
default_transport = smtp
relay_transport = smtp
inet_protocols = all
myorigin = /etc/mailname

SECURITY Snake oil SSL 証明書

The snake oil certificates, like the snake oil “medicine” sold by unscrupulous quacks in old times, have absolutely no value: you cannot rely on them to authenticate the server since they are automatically generated self-signed certificates. However, they are useful to improve the privacy of the exchanges.

In general they should only be used for testing purposes, and normal service must use real certificates. The Let's encrypt initiative offers free and trusted SSL/TLS certificates, which can be generated using the certbot package as described in 第 11.2.2 節「Adding support for SSL」 and then used in postfix like this:

smtpd_tls_cert_file = /etc/letsencrypt/live/DOMAIN/fullchain.pem
smtpd_tls_key_file = /etc/letsencrypt/live/DOMAIN/privkey.pem
smtpd_tls_CAfile = /etc/ssl/certs/ca-certificates.crt
smtpd_tls_CApath = /etc/ssl/certs
smtp_tls_CApath = /etc/ssl/certs

A different way to generate your own certificates using your own certificate authority is described in 第 10.2.2 節「公開鍵基盤、easy-rsa」.

11.1.2. 仮想ドメインの設定

The mail server can receive mails addressed to other domains besides the main domain; these are then known as “virtual“ domains. In most cases where this happens, the emails are not ultimately destined to local users. Postfix provides two interesting features for handling virtual domains.

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 特殊構文を使うことで、そのドメインに含まれるすべての残りの別名をカバーすることも可能です。

[email protected]  [email protected]
[email protected]    [email protected], [email protected]
# 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 フォーマットで保存されます
[email protected] falcot.org/jean/
# Sophie 宛の電子メールは 1 ファイルにすべてのメールを
# 連結する伝統的な "mbox" ファイルに保存されます
[email protected] 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.

CULTURE スパム問題

“Spam” is a generic term used to designate all the unsolicited commercial emails (also known as UCEs) that flood our electronic mailboxes; the unscrupulous individuals sending them are known as spammers. They care little about the nuisance they cause, since sending an email costs very little, and only a very small percentage of recipients need to be attracted by the offers for the spamming operation to make more money than it costs. The process is mostly automated, and any email address made public (for instance, on a web forum, or on the archives of a mailing list, or on a blog, and so on) will be likely discovered by the spammers' robots, and subjected to a never-ending stream of unsolicited messages. Also every contact found at a compromised system is targeted.

すべてのシステム管理者はスパムフィルタを使ってこの迷惑行為に立ち向かうことを試みます。しかし、もちろんスパマーはスパムフィルタを対処するように調整を続けます。一部のスパマーはさまざまな犯罪組織によりワームに感染させられたマシンのネットワークを借りるかもしれません。最近の統計によればインターネット上を流れるすべての電子メールの 95% 超がスパムであると推定されています!

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.

TIP access テーブル

The restriction criteria include administrator-modifiable tables listing combinations of senders, IP addresses, and allowed or forbidden hostnames. These tables can be created using a copy of the /usr/share/doc/postfix/examples/access file shipped with the postfix-doc package and explained in access(5). This model is self-documented in its comments, which means each table describes its own syntax.

The /etc/postfix/access_clientip table lists IP addresses and networks; /etc/postfix/access_helo lists domain names; /etc/postfix/access_sender contains sender email addresses. All these files need to be turned into hash-tables (a format optimized for fast access) after each change, with the sudo postmap /etc/postfix/file command.

The check_client_access directive allows the administrator to set up a blacklist and a whitelist of email servers, stored in the /etc/postfix/access_clientip file. Servers in the whitelist are considered as trusted, and the emails coming from there therefore do not go through the following filtering rules.

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.

TIP ホワイトリストと RBL

ブラックリストには過去に異常が発生した正当なサーバが含まれることもあります。この場合、そのようなサーバからのすべての電子メールは拒否されます。これを受け入れるには /etc/postfix/access_clientip によって定義されたホワイトリストの中にそのサーバをリストするしかありません。

Prudence therefore recommends including in the whitelist(s) all the trusted servers from which many emails are usually received.

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 a lot of 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. Accepting or Refusing Mails Based on the Announced Sender

各メッセージには送信者アドレスが必要です。送信者アドレスは 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 テーブルで指定した一部の送信者を特別扱いすることが可能です。このルールは一部の送信者をホワイトリストやブラックリストに入れることを意味します。

The reject_unknown_sender_domain rule requires a valid sender domain, since it is needed for a valid address. The reject_unlisted_sender rule rejects local senders if the address does not exist; this prevents emails being sent from an invalid address in the falcot.com domain, and messages emanating from [email protected] are only accepted if such an address really exists.

最後に、reject_non_fqdn_sender ルールを使うことで、完全修飾ドメイン名を持たないアドレスから送信されたと称する電子メールを拒否します。具体的には、user@machine からの電子メールを拒否します。すなわち、送信者アドレスは必ず [email protected] または [email protected] の形で申告されなければいけないということです。

The reject_rhsbl_sender rule reject senders based on a (domain-based) RHSBL service.

11.1.3.4. Accepting or Refusing Mails Based on the Recipient

各メッセージには少なくとも 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 ルールを使った場合、jean や jean@machine 宛の電子メールは送信できず、その代わりに [email protected] や [email protected] などの完全なアドレスを使うことが要求されます。

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

BACK TO BASICS 正規表現

The regular expression term (shortened to regexp or regex) references a generic notation for expressing a description of the contents and/or structure of a string of characters. Certain special characters allow defining alternatives (for instance, foo|bar matches either “foo” or “bar”), sets of allowed characters (for instance, [0-9] means "any digit", and . — a dot — means "any character"), quantification (s? matches either s or the empty string, in other words 0 or 1 occurrence of s; s+ matches one or more consecutive s characters; and so on). Parentheses allow grouping search results.

The precise syntax of these expressions varies across the tools using them, but the basic features are similar.

→ https://en.wikipedia.org/wiki/Regular_expression

最初の正規表現は電子メールソフトウェアに関するヘッダを確認します。そして GOTO Sarbacane (大量の電子メールを送信するソフトウェア) が見つかったら、メッセージを拒否します。2 番目の正規表現はメッセージの件名を操作します。そしてメッセージの件名にウイルス通知が含まれる場合、そのメッセージを拒否しない代わりにすぐに捨てます。

これらのフィルタを使うことは諸刃の剣です。なぜなら、一般的過ぎるルールを設定すれば結果的に適切なメールを失うことになるからです。そのような場合、メッセージが失われるだけでなく、送信者は望まない (そして煩い) エラーメッセージを受け取ることになるでしょう。

11.1.4. greylisting の設定

“Greylisting” is a filtering technique according to which a message is initially rejected with a temporary error code, and only accepted after a further delivery attempt with some delay. This filtering is particularly efficient against spam sent by the many machines infected by worms and viruses, since this software rarely acts as a full SMTP agent (by checking the error code and retrying failed messages later), especially since many of the harvested addresses are really invalid and retrying would only mean losing time.

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

Each time Postfix reaches this rule in the rule set, it will connect to the postgrey daemon and send it information concerning the relevant message. On its side, Postgrey considers the IP address/sender/recipient triplet and checks in its database whether that same triplet has been seen recently. If so, Postgrey replies that the message should be accepted; if not, the reply indicates that the message should be temporarily rejected, and the triplet gets recorded in the database.

greylisting の主な不都合は正当なメッセージの配送が遅れる点です。この欠点が許容できない場合もあります。さらに、送信するメールのほとんどが正当な場合、greylisting はサーバの負荷を増加させます。

IN PRACTICE greylisting の欠点

理論上 greylisting はある送信者からある受信者に送信される最初のメールだけを対象にしており、greylisting による典型的な遅延時間はほぼ数分程度です。しかしながら、実際は少し違います。一部の大きな ISP は複数の SMTP サーバを運用します。このようなサーバ群からメッセージを送信することを考えます。1 回目の送信要求を出すサーバはその送信要求を拒否されますが、2 回目の送信要求を出すサーバは 1 回目のサーバと違う可能性があります。これが起きた場合、2 回目の送信要求を出すサーバは greylisting のおかげでもう一度一時的なエラーメッセージを受け取ります。同様に、3 回目の送信要求を出すサーバが既に受信側の greylisting データベースに登録済みのサーバに一致するのには数時間かかる可能性があります。なぜなら、通常 SMTP サーバは再試行が失敗した場合に遅延時間を増やすからです。

その結果、同じ送信者からであっても送信要求を行う IP アドレスは毎回変わるかもしれません。もっと言えば、送信者アドレスさえも変わる可能性があります。たとえば、多くのメーリングリストサーバはエラーメッセージ (bounce として知られます) を取り扱うために送信者アドレス内の追加的な情報を符号化します。メーリングリスト宛に送信される新しいメッセージは greylisting を通過することが必要かもしれません。これは新しいメッセージが送信者のサーバに (一時的に) 保存されることを意味します。とても巨大な (数万人が登録する) メーリングリストの場合、これは問題になることがあります。

これらの欠点を軽減するために、Postgrey は複数の SMTP サーバを運用するサイトのホワイトリストを管理しています。ホワイトリストに登録されている送信者から送信要求のあったメッセージは greylisting を通過することなしにすぐに受け入れられます。このリストを自分の要求に適用することは簡単です。なぜなら、ホワイトリストは /etc/postgrey/whitelist_clients ファイルに保存されているからです。

GOING FURTHER milter-greylist を使った選択的 greylisting

メール配送の遅延時間が長くなるという greylisting の欠点を低減するには、既にスパムの発生源と考えられている (DNS ブラックリストに載せられている) サブネットのクライアントだけを対象に greylisting を使います。postgrey ではこの機能を使うことができませんが、milter-greylist でこの機能を使います。

この機能を利用する場合、DNS ブラックリストに載っていたからと言って必ず拒否されるわけではなくなるので、より広範囲におよぶブラックリスト (たとえば pbl.spamhaus.org や dul.dnsbl.sorbs.net など) を使うことが妥当です。そのようなブラックリストには、ISP クライアントからのすべての動的 IP アドレスも含まれます。

Since milter-greylist uses Sendmail's milter interface, the postfix side of its configuration is limited to “smtpd_milters = unix:/var/run/milter-greylist/milter-greylist.sock”. The greylist.conf(5) manual page documents /etc/milter-greylist/greylist.conf and the numerous ways to configure milter-greylist. You will also have to edit /etc/default/milter-greylist to actually enable the service.

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 ファイル

# 無制限に受信するアドレス
[email protected]  permissive
[email protected]     permissive
[email protected]  permissive

# 特権ユーザに対する積極的なフィルタリング
[email protected]         aggressive

# メーリングリスト管理者用の特別なルール
[email protected]       reject_unverified_sender

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

11.1.6. Integrating an Antivirus Filter

The many viruses circulating as attachments to emails make it important to set up an antivirus solution at the entry point of the company network, since despite an awareness campaign, some users will still open attachments from obviously shady messages.

SECURITY Controversial Discussion of Anti-Virus Software

The usage of virus scanners, or so called antivirus software, is controversial. There is usually a gap between the release of some piece of malware and the addition of detection rules to the antivirus database. During this gap, there is no software-based protection. Further, the usage often requires to run additional software, for example, to uncompress archives and scan all kinds of executables, which drastically increases the exploit potential of the antivirus software itself. Usage of such software solutions can therefor never replace awareness campaigns and simple behavioral rules (never open unsolicited sent attachments, etc.).

The Falcot administrators selected clamav from the homonymous package.

clamav-milter はアンチウイルスと電子メールサーバのやり取りを仲介する作業を担当します。milter (mail filter の略) は電子メールサーバに対するインターフェースとして特別に設計されたフィルタプログラムです。milter は標準的なアプリケーションプログラミングインターフェース (API) を使います。API を使うことで電子メールサーバの外にあるフィルタを使うよりも性能が向上します。milter は最初 Sendmail に導入されましたが、すぐ後に Postfix にも導入されました。

clamav-milter パッケージをインストールしたら、milter をデフォルトのポートではない適当な TCP ポートで実行するように再設定するべきです。これを行うには、dpkg-reconfigure clamav-milter を実行します。そして「Sendmail とのコミュニケーションインターフェイス」が表示されたら「inet:[email protected]」と答えます。

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.

IN PRACTICE アンチウイルスのテスト

Once the antivirus is set up, its correct behavior should be tested. The simplest way to do that is to send a test email with an attachment containing the eicar.com (or eicar.com.zip) file, which can be downloaded online:

→ https://2016.eicar.org/86-0-Intended-use.html

このファイルは、本物のウイルスではなくテストファイルです。市場に出ているすべてのアンチウイルスソフトウェアはこのファイルをウイルスと判定しますから、これを使うことでインストールの正しさを確認できます。

これで 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.

CAUTION Controversial Discussion

Like any other tool, the following standards have limits and real effects if put to use. They can (and should) lead to emails being rejected or even just discarded. If that happens to some legitimate emails (sometimes sent from a misconfigured SMTP server), it usually causes anger and a lack of understanding by the user. Therefore these rules are often applied as a "soft fail" or a "soft reject", which usually means that failing the checks only leads to adding a (header) mark to the affected email. There are people who think that this makes these standards "broken by design". Decide for yourself and be careful about how strict you choose to apply these standards.

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:

→ http://www.open-spf.org/SPF_Record_Syntax

→ https://tools.ietf.org/html/rfc7208

→ https://en.wikipedia.org/wiki/Sender_Policy_Framework

The following is a sample DNS entry which states that all the domain's Mail Exchange Resource Records (MX-RRs) are allowed to send email for 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.

→ http://dkim.org/

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:

→ https://tools.ietf.org/html/rfc6376

→ https://en.wikipedia.org/wiki/DKIM

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 that contain your domain as the sending host fail to validate using DKIM and SPF.

→ https://dmarc.org/overview/

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:[email protected]"
# host -t TXT _dmarc.yahoo.com
_dmarc.yahoo.com descriptive text "v=DMARC1; p=reject; pct=100; rua=mailto:[email protected]; ruf=mailto:[email protected];"

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:

→ https://tools.ietf.org/html/rfc7489

→ https://en.wikipedia.org/wiki/DMARC

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-modules と sasl2-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.

EXTRA 認証済み SMTP クライアント

多くの電子メールクライアントはメッセージを送信する前に SMTP サーバに対して認証依頼する機能を持っており、適切なパラメータを設定するだけで簡単に SASL 認証機能を使うことが可能です。クライアントが SASL 認証機能を持たない場合、ローカル Postfix サーバを使い、リモート SMTP サーバに電子メールを中継するようにローカル Postfix サーバを設定することが次善策です。この場合、ローカル Postfix が SASL を使って認証するクライアントになります。以下に必要なパラメータを示します。

smtp_sasl_auth_enable = yes
smtp_sasl_password_maps = hash:/etc/postfix/sasl_passwd
relay_host = [mail.falcot.com]

/etc/postfix/sasl_passwd ファイルには、mail.falcot.com サーバに認証を依頼する際に使うユーザ名とパスワードを含めます。以下に例を示します。

[mail.falcot.com]   joe:LyinIsji

すべての Postfix のマッピングファイルについて言えることですが、postmap コマンドを使ってこのファイルを /etc/postfix/sasl_passwd.db に変換しなければいけません。

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