第19章 電子メール

いくつか名前を挙げれば、 mutt, pine, elm そして mail といったコマンドラインプログラムや balsa, xfmail のような GUI プログラム、WWW ブラウザーのようにさらに "洗練された" ものまであります。 これらのプログラムは、email の処理を server daemons を呼び出したり TCP 経由で渡したり、といった手段でローカルの "メールホスト" に任せるだけです。

通常、これは sendmail (FreeBSD のデフォルト) や qmail, postfix もしくは exim といった他のメールサーバーデーモンの一つです。 他にもあるのですが、以上のものが広く使われています。

サーバーデーモンは通常 2 つの機能 - やってくるメールを受け取るのと出ていくメールを配送する、 を持っています。メールを読むために POP や IMAP で接続する、 ということはできません。 そのためにはもう一つデーモンが必要なのです。

いくつかの古いバージョンの sendmail には深刻なセキュリティ問題がありますが、 現在のバージョンを使っていれば特に問題ないことに注意してください。 例のごとく、 どんなソフトウェアを利用する時にも最新の状態にしておくのが大事なのです。

Domain Name System (DNS) とそのデーモンである named は email の配送において大変重要な役割を担ってます。 あなたのサイトからもう一つのサイトへメールを配送するためには、 サーバーデーモンは DNS からそのサイトを探し、 メールの受け取り先のホストを決定します。

メールがあなたに送られた場合にも同じような仕組みになっています。 DNS にはホスト名と IP アドレス、ホスト名とメールホストをマッピングするデータベースがあります。 IP アドレスは A レコードで指定されます。 MX (Mail eXchanger) レコードはあなた宛のメールを受け取るホストを指定します。 あなたのホスト名に対する MX レコードがない場合には、 メールは直接あなたのホストに配送されます。

メールはメールホストが受け取ります。 このホストは送られてきたメールを集め、 (ユーザーが) 読んだりピックアップしたりするために保存します。 保存されているメールをピックアップするにはメールホストに接続する必要があります。 これは POP や IMAP を用いて行なわれます。 メールホスト上で直接メールを読みたい時は POP や IMAP のサーバーは必要ありません。

POP や IMAP のサーバーを走らせるためには 2 つのことをやらなければいけません。

メールホストとは責任をもってメールを配送したり、 あなたのホストや、もしかするネットワークも、に宛てたメールを受け取ったりするホストに与えられる名前です。

アクセスデータベースは、 どのホストまたは IP アドレスがローカルメールサーバに接続できるか、 そして接続の種類は何か、ということを定義します。 ホストは OK, REJECT, RELAY として指定できます。 または、メーラエラーを指定することで、 単に sendmail の エラー処理ルーチンに渡されます。 OK として指定されたホスト (これはデフォルトです) は、 メールの最終宛先がローカルマシンである限り、 このホストへメールを送ることを認められます。 REJECT として指定されたホストは、 すべてのメール接続を拒絶されます。 ホスト名に対して RELAY オプションを指定されたホストは、 このメールサーバを通過して任意の宛先へメールを送ることを認められます。

この例では五つのエントリがあります。 表の左側に当てはまるメール送信者は、表の右側の動作に支配されます。 はじめの二つの例は、エラーコードを sendmail のエラー処理ルーチンに渡します。 メールが表の左側に当てはまると、リモートホストにそのメッセージが表示されます。 次のエントリは another.source.of.spam というインターネット上の特定のホストからのメールを拒絶します。 次のエントリは okay.cyberspammer.com からのメール接続を受け入れます。 このエントリは上にある cyberspammer.com という行よりもさらに厳密です (厳密に一致すればするほど、そうでないものより優先されます)。 最後のエントリは 128.32 から始まる IP アドレスのホストからの電子メールのリレーを認めます。 これらのホストは他のメールサーバに到達できるこのメールサーバを使ってメールを送ることができるでしょう。

このファイルを変更したら、 データベースを更新するために /etc/mail/ ディレクトリで make コマンドを実行する必要があります。

エイリアスデータベースには、 他のユーザ、ファイル、プログラムまたは他のエイリアスに展開される 仮想的なメールボックスの一覧が記載されています。 /etc/mail/aliases において使用できる例をいくつかあげます。

ファイル形式はシンプルです。 コロンの左側にあるメールボックス名は、右側のターゲットに展開されます。 はじめの例は単純に root のメールボックスを localuser のメールボックスに展開し、 それからエイリアスデータベースをもう一度調べます。 一致するエントリがなければメッセージはローカルユーザである localuser に配送されます。 次の例はメールリストです。 ftp-bugs のメールボックスへのメールは joe, eric および paul の三つのローカルメールボックスに展開されます。 リモートメールボックスは user@example.com のように指定できることに注意してください。 次の例はメールをファイル、この場合 /dev/null に書き込みます。 最後の例はメールをプログラムに送ります。 この場合メールのメッセージは UNIX® パイプを通じて /usr/local/bin/procmail の標準入力に書き込まれます。

このファイルを変更したら、 データベースを更新するために/etc/mail/ ディレクトリで make コマンドを実行する必要があります。

これは sendmail(8) がローカルホスト名として認めるホスト名のリストです。 sendmail がメールを受け取るすべてのドメインやホストにこのファイルを置いてください。 たとえば、このメールサーバは example.com というドメインおよび mail.example.com というホストへのメールを受け取るとすると、 local-host-names ファイルの内容は次のようになるでしょう。

このファイルを更新したら、変更を読み込むために sendmail(8) を再起動する必要があります。

sendmail の主設定ファイルである sendmail.cf は、電子メールアドレスの書き換えから、 リモートメールサーバへ拒絶メッセージを送ることまで sendmail の全般的な動作をすべて制御します。 当然、そのようなさまざまな役割によりこの設定ファイルは大変複雑で、 その詳細についてはこの節の少し範囲外です。好運なことに、 標準的な構成のメールサーバではこのファイルをめったに変更する必要はありません。

sendmail の主設定ファイルは sendmail の機能と動作を決定する m4(1) マクロから構築できます。 詳細については /usr/src/contrib/sendmail/cf/README を参照してください。

このファイルを更新したら、その変更を反映するために sendmail を再起動する必要があります。

virtusertable は仮想ドメインおよび仮想メールボックスに対するアドレスを実際のメールボックスと対応づけます。 これらのメールボックスにはローカル、リモート、 /etc/mail/aliases に定義されたエイリアス、 またはファイルを使用できます。

上の例では example.com ドメインへの対応づけをしています。 このファイルはファイルの下までファーストマッチ (訳注: 一致するルールが複数ある場合、 一番最初に一致したルールが適用されること) で処理されます。 はじめの行では root@example.com を ローカルの root メールボックスに対応づけています。 次のエントリでは postmaster@example.com を noc.example.net ホスト上の postmaster メールボックスに対応づけています。 最後に、今までのところでは example.com に関して何も一致しない場合、最後のエントリと一致するでしょう。 これは example.com の誰かに送ったすべてのメールが一致します。これは joe のローカルメールボックスに対応づけられています。

さまざまな MTA が利用できます。 FreeBSD Ports Collection から探しはじめるのがよいでしょう。 もちろん、どんな場所からでも、あなたが利用したい MTA が FreeBSD で動作する限りすべて自由に使えます。

新しい MTA をインストールすることからはじめましょう。 新しい MTA をインストールすると、 あなたの要求が実際に実現したかどうか決める機会が与えられます。さらに、 サービスを sendmail から引き継ぐ前に 新しいソフトウェアを設定する機会が与えられます。これを行う場合、 新しいソフトウェアが /usr/bin/sendmail のようなシステムバイナリを上書きしようとしないことを確認してください。 そうしないとあなたが設定する前に新しいメールソフトウェアが本格的に動作しはじめてしまいます。

あなたが選択したソフトウェアを設定する方法についての情報は、 その MTA の文書を参照してください。

sendmail を起動するために使用されていた手続きは、 4.5-RELEASE と 4.6-RELEASE の間で著しく変更されました。 したがって、それを無効にするための手続きは微妙に違います。

起動時に新しい MTA を起動するには二つの選択肢があります。 ここでも、あなたが稼働させている FreeBSD のバージョンに依存します

sendmail プログラムは UNIX® システム上の標準ソフトウェアとして本当にどこでも利用できるので、 これがすでにインストールおよび設定されているとみなしている ソフトウェアもあるかもしれません。 この理由により、代替となる MTA の多くは sendmail コマンドラインインタフェースと 互換性のある実装を提供しています。 これを "差し込む" ことによって、 sendmail の置き換えとして代替 MTA を使用することが容易になります。

したがって、あなたが互換メーラを使用しているときには、 /usr/bin/sendmail のような標準 sendmail バイナリを実行しようとするソフトウェアが、 実際にはその代わりにあなたの選択したメーラを実行しているということを 確かめる必要があるでしょう。 好運なことに、FreeBSD はこの仕事をする mailwrapper(8) と呼ばれるシステムを提供しています。

インストールされたまま sendmail が稼働しているときには /etc/mail/mailer.conf には以下のような記述があるでしょう。

このことは、これらのうちどの共通コマンド (sendmail 自身のような) が実行されても、 システムは mailer.conf を確認して、 代わりに /usr/libexec/sendmail/sendmail を実行する sendmail という名前の mailwapper のコピーを呼び出すことを意味します。 このようなシステムでは、デフォルトの sendmail が呼び出されたときに、 どのバイナリが実際に実行されるかを変更するのが簡単になります。

したがって、sendmail の代わりに /usr/local/supermailer/bin/sendmail-compat を実行させたいのなら、次のように /etc/mail/mailer.conf を変更してください。

あなたのやりたいようにすべてを設定しおえたら、 もはや必要のない sendmail のプロセスを終了して新しいソフトウェアに関するプロセスを起動するか、 単に再起動してください。 再起動することによって、新しい MTA が起動時に正しく立ち上がるように システムが設定されているかどうか確認することもできるでしょう。

恐らく、そのホストは実際には別のドメインにあるのでしょう。 例えば foo.bar.edu ドメインにいて、 bar.edu というドメイン内の mumble というホストにアクセスしたいとします。 この時は単に mumble ではなく mumble.bar.edu と FQDN で参照しなければなりません。

そもそも、BSD BIND のリゾルバー (resolver) ではこのようなことが可能でしたが、 FreeBSD に入っている最新版の BIND では自分のドメイン以外に対する FQDN でない省略形は許されません。 従ってホストを mumble と曖昧に指定した場合は mumble.foo.bar.edu という名前があればそれになり、 そうでなければ root ドメインから検索されます。

これは、 mumble.bar.edu と mumble.edu ということなったドメイン名に対してホスト名のサーチがおこなわれていた以前の振る舞いとは異なったものです。 このような事が悪い例もしくはセキュリティホールとみなされる理由については RFC 1535 を見てください。

/etc/resolv.conf で

と書いてある行を

と書き換えることで上のようなことができます。 しかし、RFC 1535 にあるように検索順序が "内部 (local) と外部 (public) の管理の境界" をまたがないようにしてください。

sendmail FAQ に次のように書いてあります。

sendmail FAQ は http://www.sendmail.org/faq にありますので、 メールの設定に "おかしなこと" があれば常に読んでください。

LAN 上にある FreeBSD マシンを、 インターネットに接続したいとします。FreeBSD マシンは、その LAN でのメールゲートウェイになります。FreeBSD マシンは専用線接続ではありません (訳注: ダイアルアップ接続など)。

これには、少なくとも二つの方法があります。 一つは UUCP を使うことです。

もう一つの方法は、あなたのドメインに対するセカンダリ MX サービスを提供する常時稼働のインターネットサーバを用意することです。 たとえば、あなたの会社のドメインが example.com で、 ISP があなたのドメインに セカンダリ MX サービスを提供するために example.net ドメインを 用意するとしたら次のようにします。

最終的なメール受信先としては、 一つのホストだけが定義されるべきです (example.com 上の /etc/mail/sendmail.cf ファイルに、 Cw example.com を追加します)。

送信側の sendmail が、 メールを配送しようとしている時、モデムの接続を介してあなたのところ (example.com) に接続しようとします。大抵の場合、 あなたのマシンがオンラインでないために、 接続はタイムアウトしてしまうでしょう。 sendmail プログラムは自動的に、 たとえばあなたのインターネットプロバイダなどのセカンダリの MX サイト (example.net) にメールを配送するでしょう。 セカンダリ MX サイトは定期的にあなたのホストに接続し、 プライマリ MX ホスト (example.com) にメールを配送しようとするでしょう。

ログインスクリプトとして、 このようなものを使うとよいでしょう。

ユーザごとにログインスクリプトを作りたい場合には、 上記のスクリプトの代わりに、 sendmail -qRexample.com を使用することもできます。 このようにすると、 キューの中の example.com に対するすべてのメールは、すぐに強制的に処理されます。

さらに、次のような改良もできます。

以下は、FreeBSD Internet service provider’s メーリングリスト から抜粋してきたメッセージです。

FreeBSD がインストールされたデフォルトの状態では、 sendmail は動作しているホストからのメールだけを送るように設定されています。 たとえば POP3 サーバがインストールされているとすると、 ユーザは学校や職場など他のリモートの場所からメールを確認することが できます。しかし、彼らは外部からそのホスト以外へのメールを 送ることはやはりできません。 通常、メールを送ろうとしてから少しすると、 5.7 Relaying Denied というエラーメッセージの書かれたメールが MAILER-DAEMON から送られてくるでしょう。

これを解決する方法はいくつかあります。 一番の正攻法は /etc/mail/relay-domains リレードメインファイルにあなたの ISP のアドレスを書くことです。 これをするのに簡単な方法は次のとおりです。

このファイルを作成または編集したら、 sendmail を再起動してください。 もしあなたがサーバ管理者でメールをローカルに送りたくないか、 ポイントを使用して他のマシン (や、さらに他の ISP) の クライアントまたはシステムへ送りたい時は、とても効果があります。 さらに、あなたが一つあるいは二つだけのメールアカウントを 設定している場合でもこれは非常に有用です。 追加すべきアドレスがたくさんある場合には、 単にこのファイルをあなたの好きなテキストエディタで開いて、 そして一行に一つずつドメインを追加してください。

これで、リストに掲載されているすべてのホスト (ユーザがあなたのシステムにアカウントを持っていると規定する) からあなたのシステムを通るすべてのメールは送信に成功するでしょう。 これはあなたのシステムから SPAM を送ることを認めることなく、 リモートであなたのシステムからメールを送ることをユーザに 認めるためのとてもよい方法です。

あなたのマシンに FreeBSD を普通にインストールして、 /etc/resolv.conf ファイルを設定するか、 またはネームサーバを走らせれば、 他のホストへ電子メールを送ることができるようになります。 あなたのホスト宛のメールをあなた自身の FreeBSD ホスト上の MTA (たとえば sendmail) に配送するようにしたい場合には、次の二つの方法があります。

上のどちらを選ぶ場合でも、自分のホストに直接メールが配送されるようにするには恒久的で 静的 な IP アドレス (ほとんどの PPP ダイアルアップ設定で用いられる動的なアドレスではなく) を持っていなければなりません。 もしファイアウォールの中にいるならば、 SMTP トラフィックが通過してくれないといけません。 もし自分のホストでメールを直接受け取りたいならば、 次の二つのうちのどちらかができていることを確認してください。

上のどちらかが設定されていれば、 自分のホストでメールを受け取ることができるでしょう。

次のコマンドを実行してみてください。

もしあなたのマシンが上記のメッセージだけを出力したならば、 yourlogin@example.FreeBSD.org へのメールは問題なく配送されるでしょう (sendmail が example.FreeBSD.org 上で正しく動作していると仮定します)。

上記のメッセージの代わりに、

というメッセージが出力された場合は、 あなたのホスト (example.FreeBSD.org) に宛てたメールは全て直接配送されずに hub 上の同じユーザー名に配送されます。

上の情報は DNS サーバーが扱います。 メールルーティング情報をもつ DNS レコードは、 Mail eXchange エントリーです。 MX エントリが存在しない場合には、IP アドレスにしたがって、 直接宛先ホストに配送されます。

freefall.FreeBSD.org の現時点での MX エントリは、次のようになっています。

freefall は多くの MX エントリを持っています。 一番 MX の値の小さいホストが利用可能な場合は直接メールを受け取ります。 もしなにかの理由でアクセスができない時には、 他のホスト (ときどき "バックアップ MX" と呼ばれます) が一時的にメールを受け取ります。そして、 より値の小さいホストが利用可能になったときにメールを渡し、 最終的に一番値の小さいホストに渡ります。

使い勝手をよくするためには、代替の MX サイトは、それぞれ 別の経路でインターネットへ接続しているとよいでしょう。 インターネットプロバイダまたは他の関連サイトが、このサービスを 提供することができます。

"メールホスト" (メールサーバーとしても知られています) をセットアップするためには、 いろいろなワークステーションに宛てた全てのメールを受ける必要があります。 基本的には、あなたのドメイン内 (この場合だと *.FreeBSD.org) のすべてのホスト名宛てのすべてのメールを "受け取って"、 そのメールをあなたのメールサーバーに配送し、 ユーザーがマスタメールサーバ上でメールをチェックできるようにします。

話を簡単にするために、あるユーザーのアカウントはどのマシンでも同じユーザー名にすべきです。 そのためには adduser(8) を使ってください。

使用する予定のメールホストは、 各ワークステーションごとにメール交換が できるように設定されていなければなりません。 これは DNS の設定で次のように行なうことができます。

これは、ワークステーションの A レコードがどこを指していようとも そのワークステーション宛てのメールをメールホストに転送する、というものです。

自前で DNS サーバを運用しているのでなければ、 この作業は自分では行えません。自分で DNS サーバを運用しないとかできないという場合は、 あなたの DNS を提供しているインターネットプロバイダなどに依頼して 作業を行ってもらってください。

もしバーチャル電子メールホストを運用するなら次の情報が役に立つでしょう。 例として、あなたには自分のドメイン、ここでは customer1.org、 を持っている顧客がいるとしましょう。 あなたは customer1.org 宛ての全てのメールを mail.myhost.com というメールホストに集めたいとします。 DNS エントリーは次のようになるでしょう。

customer1.org に対して電子メールを送りたいだけなら、 A レコードは必要ありません。

やらなければいけない最後のことは、 メールホスト上の sendmail に対してどんなドメインやホスト宛のメールを受け取るのか、 を教えることです。いくつかの方法がありますが次のどちらかでいいでしょう。