/etc/postfix/main.cf 設定ファイルの最初のバージョンが作成されます。
mail.falcot.com と答えるべきです。デフォルトで聞かれる質問は以上ですが、Falcot にとってこの状態の Postfix はまだ十分に設定されていません。このため、管理者は dpkg-reconfigure postfix を実行してさらに多くのパラメータをカスタマイズします。
dpkg-reconfigure postfix を実行したことで追加的に行われる質問の 1 つに、このマシンに関連するすべてのドメイン名を尋ねる質問があります。デフォルトで挙げられるドメイン名のリストには、マシンのフルネームといくつかの localhost の同義語が含まれていますが、主要なドメイン名である falcot.com を手作業で追加する必要があります。より一般的に言えば、この質問の回答には、通常 MX サーバを担当しているマシンに割り当てたすべてのドメイン名を含めるべきです。さらに言い換えれば、DNS の MX レコードを参照した際に電子メールを受け入れるサーバとして登録されているすべてのドメイン名を含めるべきです。この情報は最終的に Postfix 主要設定ファイル /etc/postfix/main.cf の mydestination 変数に設定されます。
192.168.0.0/16 を追加しました。この質問が尋ねられなければ、以下の例に示す通り、設定ファイル中の関連する変数 mynetworks にローカルネットワークを追加します。
procmail を使うことも可能です。procmail を使うことで、ユーザは ~/.procmailrc ファイルに書かれたルールに従って入って来る電子メールを仕分けすることが可能になります。
例 11.1 最初の /etc/postfix/main.cf ファイル
# より完全なコメント付きの設定ファイルは /usr/share/postfix/main.cf.dist を参照してください
# Debian 固有の設定方法になりますが、myorigin にファイル名を指定した場合、
# 指定ファイルの最初の行を値として使用します。Debian のデフォルトは
# /etc/mailname です。
#myorigin = /etc/mailname
smtpd_banner = $myhostname ESMTP $mail_name (Debian/GNU)
biff = no
# .domain の追加は MUA が行います。
append_dot_mydomain = no
# "delayed mail" 警告メールを送信するには以下の行を有効化してください
#delay_warning_time = 4h
readme_directory = no
# TLS パラメータ
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
# smtp クライアントで SSL を有効化するための情報を見るには postfix-doc
# パッケージに含まれる /usr/share/doc/postfix/TLS_README.gz を参照してください。
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 = allvirtual_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 # 以下の仮想エイリアスは一般的なエイリアスです。このファイルで # 指定されていない falcotsbrand.com ドメインに含まれるすべての # アドレスを指定したことになります。これらのアドレス宛の電子メール # は falcot.com ドメインに存在する同名のユーザに転送されます。 @falcotsbrand.com @falcot.com
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 つの空白) で始まる行が新しいメッセージの始まる目印です。
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.orgpermit_mynetworks 指示文により、ローカルネットワーク (mynetworks 設定変数によって定義されています) 内のマシンからのすべての電子メールを受け入れるようになります。
reject_unknown_client 指示文により、完全に適切な DNS 設定のないマシンからの電子メールを通常拒否するようになります。ここで適切な設定とは、IP アドレスが名前に解決でき、その名前が同じ IP アドレスに解決できることを意味しています。この基準は厳しすぎる場合が多いでしょう。なぜなら、多くの電子メールサーバは IP アドレスに対応する逆引き DNS を持っていないからです。このため、Falcot の管理者は warn_if_reject 修飾子を reject_unknown_client 指示文の前に置きました。warn_if_reject 修飾子を付けることで、拒否するのではなく警告をログに記録するようになります。管理者は、このルールが実際強制された場合に拒否されるかもしれないメッセージの数に目を光らせ、後から十分な情報に基づいてこのルールを強制するか否かを決断することが可能です。
check_client_access 指示文を使うことで、管理者は /etc/postfix/access_clientip ファイルに保存された電子メールサーバのブラックリストとホワイトリストを設定することが可能になります。ホワイトリストに含まれるサーバは信頼され、このサーバから来る電子メールは以降のフィルタリングルールを適用されません。
reject_rbl_client 指示文を使うことで、指定したブラックリストに含まれるサーバからのメッセージを拒否するようになります。RBL は Remote Black List の頭字語です。ブラックリストは複数存在しますが、どのブラックリストにもスパマーが電子メールを中継するために使う下手に設定されたサーバ、ワームやウイルスに感染したマシンのような本来の意図と異なりメール中継させられているサーバがリストされています。
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_hostnamepermit_mynetworks 指示文を使うことで、ローカルネットワーク上のすべてのマシンならば HELO コマンドの引数にどのような名前を使っても良いことになります。これは重要です。なぜなら、一部の電子メールプログラムは SMTP プロトコルのこの部分を十分適切に尊重せず HELO の引数に無意味な名前を使うからです。
reject_invalid_hostname ルールを使うことで、EHLO で申告されたホスト名が構文的に不正な電子メールを拒否するようになります。reject_non_fqdn_hostname ルールを使うことで、申告されたホスト名が完全修飾ドメイン名 (ホスト名まで含むドメイン名) でないメッセージを拒否するようになります。reject_unknown_hostname ルールを使うことで、申告された名前が DNS に存在しないメッセージを拒否するようになります。reject_unknown_hostname ルールを適用すると数多くの電子メールが拒否されることになるため、管理者は 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 ファイルに追加します。
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_sendercheck_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 の形で申告されなければいけないということです。
RCPT TO コマンドで申告されます。送信者アドレスに対して行った確認よりも関係性は低いとは言うものの、受信者アドレスの正当性を確認することは当然です。
例 11.9 受信者アドレスの確認
smtpd_recipient_restrictions = permit_mynetworks,
reject_unauth_destination, reject_unlisted_recipient,
reject_non_fqdn_recipientreject_unauth_destination は基本的なルールで、受け入れ要求のあったメッセージが自分の管理するユーザ宛であることを確認します。すなわち、このサーバにないアドレス宛のメッセージを拒否するということです。このルールを指定しなかった場合、サーバがスパマーによって迷惑メールを送信するための第三者中継サーバとして使われる可能性が出てきます。このため reject_unauth_destination ルールは必須で、ルールリストの先頭に近い位置に置くのが最良です。そうすれば、メッセージの宛先をチェックする前に、他のルールがそのメッセージの受け入れを許可することを避けられます。
reject_unlisted_recipient ルールを使うことで、存在しないローカルユーザ宛のメッセージを拒否するようになります。これは道理に適ったルールです。最後に、reject_non_fqdn_recipient ルールを使うことで、完全修飾ドメイン名でないアドレスを拒否するようになります。さらに reject_non_fqdn_recipient ルールを使った場合、jean や jean@machine 宛の電子メールは送信できず、その代わりに jean@machine.falcot.com や jean@falcot.com などの完全なアドレスを使うことが要求されます。
DATA コマンドはメッセージ内容の前に送信されます。DATA コマンドの後に送信されるメッセージ内容はさておき、厳密な意味では DATA コマンドはいかなる情報も提供しません。とは言っても、確認することは可能です。
reject_unauth_pipelining 指示文を使うことで、1 つ前に送信されたコマンドに応答する前に送信者が次のコマンドを送ったメッセージを拒否するようになります。この防御はスパマーロボットの使う一般的な最適化に対抗するものです。なぜなら、スパマーはサーバからの応答の結果を気にせず、可能な限り短い時間で可能な限り大量の電子メールを送信することだけに注目しているからです。
RCPT TO コマンドに対する応答の段階です。
EHLO コマンドが原因でメッセージを拒否する場合でも、Postfix はメッセージの送信者と受信者を知った後に拒否応答を送信することを意味しています。こうすることで、すぐにトランザクションを拒否するよりも明確なログを残すことが可能です。加えて、多くの SMTP クライアントはトランザクションの最初の方の SMTP コマンドの失敗を予期していませんから、RCPT TO の後に拒否応答を返したとしても問題になることは少ないです。
例 11.11 内容に基づくフィルタの有効化
header_checks = regexp:/etc/postfix/header_checks body_checks = regexp:/etc/postfix/body_checks
例 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 番目の正規表現はメッセージの件名を操作します。そしてメッセージの件名にウイルス通知が含まれる場合、そのメッセージを拒否しない代わりにすぐに捨てます。
postgrey はデーモンとして実行され、ポート 10023 番をリッスンします。この後 Postfix の設定に check_policy_service ルールを追加することで、Postfix は postgrey デーモンを使うようになります。
smtpd_recipient_restrictions = permit_mynetworks,
[...]
check_policy_service inet:127.0.0.1:10023postgrey デーモンに接続し、対応するメッセージに関する情報をデーモンに送信します。Postgrey は IP アドレス/送信者/受信者の三つぞろいを考慮し、同じ三つぞろいが最近データベースに登録されたか否かをデータベースで確認します。最近登録されていた場合、Postgrey はメッセージを受け入れるべきであると応答します。さらに、最近登録されていなかった場合、Postgrey はメッセージを一時的に拒否するべきであると応答し、三つぞろいをデータベースに登録します。
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 ファイル
# 無制限に受信するアドレス 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
clamav を選びました。clamav の主パッケージは clamav ですが、arj、unzoo、unrar、lha などのいくつかのパッケージを追加でインストールしました。なぜなら、これらのパッケージはアンチウイルスがそれらのフォーマットで圧縮された添付ファイルを解析する際に必要だからです。
clamav-milter はアンチウイルスと電子メールサーバのやり取りを仲介する作業を担当します。milter (mail filter の略) は電子メールサーバに対するインターフェースとして特別に設計されたフィルタプログラムです。milter は標準的なアプリケーションプログラミングインターフェース (API) を使います。API を使うことで電子メールサーバの外にあるフィルタを使うよりも性能が向上します。milter は 最初 Sendmail に導入されましたが、すぐ後に Postfix にも導入されました。
dpkg-reconfigure clamav-milter を実行します。そして「Sendmail とのコミュニケーションインターフェイス」が表示されたら「inet:10002@127.0.0.1」と答えます。
dpkg-reconfigure clamav-base を使えばいくつかの重要なパラメータをカスタマイズすることも可能です。
/etc/postfix/main.cf に以下の指示文を追加するだけで簡単に設定できます。
# clamav-milter を使ったウイルスチェック smtpd_milters = inet:[127.0.0.1]:10002
service postfix reload を実行します。こうすることでアンチウイルスが無効化されます。
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 回入力します ...]
ln -sf /var/spool/postfix/etc/sasldb2 /etc/sasldb2 コマンドを使って /etc/sasldb2 を Postfix の使うデータベースを指すシンボリックリンクにします。
postfix ユーザを sasl グループに追加して、SASL アカウントデータベースにアクセスできるようにします。Postfix で SASL を有効化するには、いくつかの新しいパラメータが必要です。また、SASL 認証されたクライアントが自由に電子メールを送信することを許可するには、smtpd_recipient_restrictions パラメータを設定します。
例 11.15 /etc/postfix/main.cf の中で SASL を有効化
# SASL 認証を有効化します
smtpd_sasl_auth_enable = yes
# SASL 認証を適用するドメインを定義します
smtpd_sasl_local_domain = $myhostname
[...]
# reject_unauth_destination の前に permit_sasl_authenticated を
# 追加すれば、SASL 認証済みユーザが送信したメールの中継が許可されます
smtpd_recipient_restrictions = permit_mynetworks,
permit_sasl_authenticated,
reject_unauth_destination,
[...]