/etc/postfix/main.cf
設定ファイルの最初のバージョンが作成されます。
mail.falcot.com
と答えるべきです。デフォルトで聞かれる質問は以上ですが、Falcot にとってこの状態の Postfix はまだ十分に設定されていません。このため、管理者は dpkg-reconfigure postfix
を実行してさらに多くのパラメータをカスタマイズします。
localhost
の同義語が含まれていますが、主要なドメイン名である falcot.com
を手作業で追加する必要があります。より一般的に言えば、この質問の回答には、通常 MX サーバを担当しているマシンに割り当てたすべてのドメイン名を含めるべきです。さらに言い換えれば、DNS から電子メールを受け入れると回答されるすべてのドメイン名を含めるべきです。この情報の最後に主要な Postfix 設定ファイル — /etc/postfix/main.cf
— の mydestination
変数を設定します。
192.168.0.0/16
を追加しました。この質問が尋ねられなければ、以下の例に示す通り、設定ファイル中の関連する変数 mynetworks
にローカルネットワークを追加します。
procmail
を使って配送することも可能です。procmail
を使うことで、ユーザは ~/.procmailrc
ファイルに書かれたルールに従って入って来る電子メールを仕分けすることが可能になります。
例 11.1 最初の /etc/postfix/main.cf
ファイル
# See /usr/share/postfix/main.cf.dist for a commented, more complete version # Debian specific: Specifying a file name will cause the first # line of that file to be used as the name. The Debian default # is /etc/mailname. #myorigin = /etc/mailname smtpd_banner = $myhostname ESMTP $mail_name (Debian/GNU) biff = no # appending .domain is the MUA's job. append_dot_mydomain = no # Uncomment the next line to generate "delayed mail" warnings #delay_warning_time = 4h readme_directory = no # TLS parameters smtpd_tls_cert_file=/etc/ssl/certs/ssl-cert-snakeoil.pem smtpd_tls_key_file=/etc/ssl/private/ssl-cert-snakeoil.key smtpd_use_tls=yes smtpd_tls_session_cache_database = btree:${data_directory}/smtpd_scache smtp_tls_session_cache_database = btree:${data_directory}/smtp_scache # See /usr/share/doc/postfix/TLS_README.gz in the postfix-doc package for # information on enabling SSL in the smtp client. smtpd_relay_restrictions = permit_mynetworks permit_sasl_authenticated defer_unauth_destination myhostname = mail.falcot.com alias_maps = hash:/etc/aliases alias_database = hash:/etc/aliases myorigin = /etc/mailname mydestination = mail.falcot.com, falcot.com, localhost.localdomain, localhost relayhost = mynetworks = 127.0.0.0/8 [::ffff:127.0.0.0]/104 [::1]/128 192.168.0.0/16 mailbox_command = procmail -a "$EXTENSION" mailbox_size_limit = 0 recipient_delimiter = + inet_interfaces = all inet_protocols = all
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
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
file is quite straightforward: two fields separated with whitespace. The first field is an email address within one of the virtual domains, and the second field is the location of the associated mailbox (relative to the directory specified in virtual_mailbox_base). If the mailbox name ends with a slash (/
), the emails will be stored in the maildir format; otherwise, the traditional mbox format will be used. The maildir format uses a whole directory to store a mailbox, each individual message being stored in a separate file. In the mbox format, on the other hand, the whole mailbox is stored in one file, and each line starting with “From
” (From
followed by a space) signals the start of a new message.
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
permit_mynetworks
指示文により、ローカルネットワーク (mynetworks 設定変数によって定義された) 内のマシンからのすべての電子メールを受け入れるようになります。
warn_if_reject
修飾子を reject_unknown_client
指示文の前に起きました。warn_if_reject
修飾子を付けることで、拒否するのではなく警告をログに記録するようになります。管理者は、このルールが実際強制された場合に拒否されるかもしれないメッセージの数に目を光らせ、後から十分な情報に基づいてこのルールを強制するか否かを決断することが可能です。
/etc/postfix/access_clientip
ファイルに保存された電子メールサーバのブラックリストとホワイトリストを設定することが可能になります。ホワイトリストに含まれるサーバは信頼され、このサーバから来る電子メールは以降のフィルタリングルールを適用されません。
HELO
(または EHLO
) の後に送信元の名前を付けたコマンドを送ります。送信元の名前の妥当性を確認することは興味深いです。
例 11.7 EHLO
の引数に与えられる名前の制限
smtpd_helo_restrictions = permit_mynetworks, reject_invalid_hostname, check_helo_access hash:/etc/postfix/access_helo, reject_non_fqdn_hostname, warn_if_reject reject_unknown_hostname
permit_mynetworks
指示文を使うことで、ローカルネットワーク上のすべてのマシンならば、HELO
コマンドの引数にどのような名前を使っても良いことになります。これは重要です。なぜなら、一部の電子メールプログラムは SMTP プロトコルのこの部分を十分適切に尊重せず、HELO
の引数に無意味な名前を使います。
reject_invalid_hostname
ルールを使うことで、EHLO
で申告されたホスト名が構文的に不正な電子メールを拒否するようになります。reject_non_fqdn_hostname
ルールを使うことで、申告されたホスト名が完全修飾ドメイン名 (ホスト名まで含むドメイン名) でないメッセージを拒否するようになります。reject_unknown_hostname
ルールを使うことで、申告された名前が DNS に存在しないメッセージを拒否するようになります。最後のルールを適用すると、数多くの電子メールが拒否されることになるため、管理者は warn_if_reject
修飾子を付けて警告するだけにしています。管理者は reject_unknown_hostname
ルールの結果を調査した後に、最後の段階で warn_if_reject
修飾子を削除するか判断します。
permit_mynetworks
を使うと、面白い副作用があります。つまり、それ以降のルールがローカルネットワークの外のホストにのみ適用されるようになります。これを使うことで、自分を falcot.com
の一部と申告するすべてのホストをブラックリスト化できます。これを行うには、たとえば falcot.com REJECT You are not in our network!
行を /etc/postfix/access_helo
ファイルに追加します。
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
の形で申告されなければいけません。
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
ルールを使った場合、jean
や jean@machine
宛の電子メールは送信できず、その代わりに jean@machine.falcot.com
や jean@falcot.com
などの完全なアドレスを使うことが要求されます。
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 番目の正規表現はメッセージの件名を操作します。そして、メッセージの件名にウイルス通知が含まれる場合、そのメッセージを拒否しない代わりにすぐに捨てます。
check_policy_service
パラメータを追加的制限として追加することで、postgrey を使うようになります。
smtpd_recipient_restrictions = permit_mynetworks, [...] check_policy_service inet:127.0.0.1:10023
postgrey
デーモンに接続し、対応するメッセージに関する情報をデーモンに送信します。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
ファイル
# 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
clamav
を選びました。主要なパッケージは clamav ですが、arj、unzoo、unrar、lha などのいくつかのパッケージを追加でインストールしました。なぜなら、これらのパッケージはアンチウイルスがそれらのフォーマットで圧縮された添付ファイルを解析する際に必要だからです。
clamav-milter
はアンチウイルスと電子メールサーバの間を接続する作業を担当します。milter (mail filter の略) とは、電子メールサーバに対するインターフェースとして特別に設計されたフィルタプログラムです。milter は標準的なアプリケーションプログラミングインターフェース (API) を使います。API を使うことで、電子メールサーバ外のフィルタの性能が向上します。Milter は 最初 Sendmail に導入されましたが、Postfix がすぐに後に続きました。
dpkg-reconfigure clamav-milter
を実行します。そして「Communication interface with Sendmail」が表示されたら「inet:10002@127.0.0.1
」と答えます。
dpkg-reconfigure clamav-base
を使えばいくつかの重要なパラメータをカスタマイズすることも可能です。
/etc/postfix/main.cf
に以下の指示文を追加します。
# Virus check with clamav-milter smtpd_milters = inet:[127.0.0.1]:10002
service postfix reload
を実行します。これでこの変更が反映されます。
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 を有効化
# 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, [...]