canvas.gif

 

 

POPサーバの概念と機能


メールサーバには送信側のプログラムと受信側のプログラムがあり、それぞれ smtp および pop3 プロトコルを使用して通信する。この送信側のサーバプログラムが Sendmail をはじめとするMTA(Mail Transfer Agent)で、受信側のサーバプログラムとなるのが今回紹介する qpopper をはじめとするPOPサーバである。ちなみにPOP3とは Post Office Protocol version3 の略称であり、MAILBOXへ配信されたメールを取得するためのプログラム群である。

(現在メール受信プロトコルにはPOPの他、IMAPなどがあるがこれについては別項に譲ることにする。)



■ qpopper について

qpopper は現在多くのメールサーバで使われている標準的なPOPサーバである。POPプロトコルの仕様による本質的なセキュリティの弱さを別問題とすれば、qpopperの安定性と基本機能の信頼性は高く評価できるものである。

一方、qpopperrpmで簡単にインストールできるアプリケーションではないため、利用にあたってはtarballの展開とオプションを指定してのコンパイル作業が必要となる。また、新しいバージョンではconfig志向(デーモン志向というべきか)が強まり、ユーザの設定範囲が大幅に広がったことから、経験の少ないユーザはかえってqpopperの利用を敬遠する傾向があるようだ。

しかし、qpopperによるpopサーバの構築は、手順通りに確認しながら行えば必ずしもむずかしいものではない。むしろ初学者にとっては、基本的なpopサーバの機能と構成を知るための格好の学習材料となるだろう。本稿ではRedHat Linux での利用を前提にインストレーションと設定の解説を行う。


インストール


■ ダウンロード

Eudoraのサイトhttp://www.eudora.com/qpopperから qpopper4.0.5.tar.gz /usr/local/src等にダウンロードする。qpopperのアーカイブはそれほど大きなものではなく、むしろこの手のプログラムとしては小さなものに類するのでHDDの容量を気にすることはほとんどないはずである。

ランレベル5でブラウザを使えるサーバならホームページから取得してもよいが、そうでない場合はwget コマンドを使ってアーカイブを取得すればよい。
以下にwgetコマンドの基本的な使い方を示す。


    [root@server root]# wget http://core.ring.gr.jp/archives/net/mail/qpopper/qpopper4.0.5.tar.gz

    --07:40:56--
      http://core.ring.gr.jp/archives/net/mail/qpopper/qpopper4.0.5.tar.gz
               => `qpopper4.0.5.tar.gz'
    core.ring.gr.jp
    DNSに問いあわせています... 完了しました。
    core.ring.gr.jp[203.174.65.19]:80 に接続しています... 接続しました。
    HTTP による接続要求を送信しました、応答を待っています... 200 OK
    長さ: 2,281,284 [application/x-tar]

    100%[====================================>] 2,281,284
        680.66K/s    ETA 00:00

    07:41:00 (680.66 KB/s) - `qpopper4.0.5.tar.gz'
    を保存しました [2281284/2281284]


なおwgetコマンドは基本的にCURRENTディレクトリにファイルをダウンロードする。ローカルのディレクトリを指定してダウンロードしたい場合は-pオプションを使いwget -p /usr/loca/src/ TARGET_URLの書式で指定すればよい。またプロキシを使っている環境やその他の設定を行いたい場合は/etc/wgetrcを編集する。以下にwgetrcよりプロキシ設定部分を示す。



    # You can set the default proxies for Wget to use for http and ftp.
    # They will override the value in the environment.
    http_proxy =
    http://proxy.yoyodyne.com:18023/    ※コメント外し自環境のhttpプロキシを指定
    ftp_proxy = http://proxy.yoyodyne.com:18023/     
    ※コメント外し自環境のftpプロキシを指定

    # If you do not want to use proxy at all, set this to off.
    use_proxy = on   
    ※コメント外す




■ アーカイブの展開

本稿ではダウンロードしたアーカイブを/usr/local/src/以下に置くものとして論を進めるが、その他のディレクトリに置く場合は適宜読み替えること。アーカイブを適切なディレクトリに置いたらまずsuを実行し、rootユーザとしてオペレーションを行う。

    # su
    # cd /usr/local/src
    # tar xvfz qpopper4.0.5.tar.gz

アーカイブはqpopper4.0.5以下に展開されるので展開が終了したら、この作業ディレクトリに移動する。

    # cd qpopper4.0.5


■ コンパイルとインストール

コンパイルにあたっては当然Compilerとライブラリが必要である。システムインストール時にパッケージを選択していなかったら、追加インストールしておく。セキュリティ上の理由で実機上にCompilerを置きたくない場合、クローン機の上でコンパイルし、必要ファイルだけを配置することも可能である。
またコンパイルに当たっては必ずREADMEファイルを読み、要求されるライブラリやツールのバージョンを確認しておくこと。(それを満たさない場合は、まずライブラリ等の確保が先決となるので注意。まれにコンパイルできても正しく動作しないことがある。またコンパイル時はOSの環境変数をLANG=Cで英語にしておくこと。これも一般論だが、日本語環境では出力に2バイト文字が入るため、失敗することがある。)

Makefileの修正

Eudoraから提供されているqpopperMakefileは、そのままではRedHatのディレクトリツリーと一致していないので、コンパイルオプションで実行ファイルのパスやマニュアルパスを以下のように指定しておく。

    # ./configure --prefix=/usr --exec-prefix=/usr --enable-specialauth --mandir=/usr/share/man

また、shadow passwordを使用している場合は --enable-specialauth の指定が必須なので注意すること。これを指定しないとパスワード認証で失敗する

コンパイル

qpopperのコンパイルはごく簡単なオペレーションで済む。型通り make make install へと進めばよい。

    # make
    # make install

これらの作業で /usr/sbin popperがインストールされ、オンラインマニュアルが/usr/share/man/man8に配置される。なお、ゼロからやりなおしたい場合はmake realclean makefileをクリーンして元へ戻せるので、恐れずにやってみることが大切である。
(※make realcleanを実行した場合は、ふたたび configure をやりなおす必要がある。以上念のため。)


 設定

■ デーモン定義ファイルの作成

qpopperは通常xinetd経由で起動するデーモンとして設定される。xinetd経由のデーモンとして稼動させるためには、以下のファイルが必要となる。

     /etc/xinetd.d/popper
     /etc/qpopper110.cfg

(pop3sを使う場合→ /etc/qpopper995.cfg)


■ /etc/xinetd.d/popper の作成

xinetd環境で起動する場合はデーモン定義ファイルpopperを作成する。このファイルは./samples に雛型があるので、新たに書き起こすよりもそれを使用するのが無難である。

    # cp ./samples/qpopper.xinetd /etc/xinetd.d/popper
    # cd /etc/xinetd.d
    # vi popper

設定自体はdisable=noにする以外、デフォルトのままでよい。ただし、後半部は pop3s のための設定なので、不要なら # をつけてコメント化する。

    service pop3{
            disable                = no
            flags                   = REUSE NAMEINARGS
            socket_type         = stream
            wait                    = no
            user                   = root
            server                 = /usr/sbin/popper
            server_args          = popper -f /etc/qpopper110.cfg -s
            instances            = 50
            disable                = no
            port                    = 110
            per_source           = 10
    }


 /etc/qpopper110.cfg の作成

popper起動時のconfigファイルを作成する。これも./samplesの配下に雛型が用意されているので、コピーして使用できる。

    # cp ./samples/qpopper.config /etc/qpopper110.cfg

qpopper.configでは設定がすべてコメント化されているので、必要な設定項目から # を外す必要があるが、このファイルにはroパーミッションがセットされているので、次のようにchmodしておく。

    # cd /etc
    # chmod 644 qpopper110.cfg

ro属性を変更したら次の2行から # を外して設定する。

    set shy      = true(デフォルトはfalse バナー情報を隠蔽する)
    set log facility  = local1(ログファシリティの設定:local1 が使用されている場合は local2-7 のどれかに割り付ける)

作業が終了したらファイルパーミッションを元に戻しておく。

    # chmod 444 qpopper110.cfg

pop3s が必要なら同様に雛型ファイルをコピーする。このときファイル名はpop3s用に変更する。

    # cp ./samples/qpopper.config /etc/qpopper995.cfg(参考)


ロギング

一般論ではあるが、popサーバに関しては通信にかかわるプライバシーを留意しつつ、ログの採取が必須である。ログ採取にあたっては/etc/xinetd.d/qpopper110.cfgにファシリティを指定すること、/etc/syslog.conf に以下の一行を追加すること、さらに/etc/logrotated.d/qpopperファイルの設定が必要である。また後述するが、ロギングは運用フェーズでの重要な設定事項となるため、必ず検証して動作確認が必要である。

■ 
syslog.conf へのログエントリ追加

qpopperは標準ではロギングが定義されていないため、syslog.confへログエントリを追加する。
ファシリティの設定にあたっては既存のサービスと競合しないように注意したい。たとえばoracleがlocal0を使っていたり、ciscoがlocal7を使っていたりすることあるので、local2-5のような中間位置のファシリティを指定するとよい。いずれにせよファシリティのバッティングが生じるとあとあと面倒なので、必ず事前に調査するべきである。)

    vi /etc/syslog.conf

    local1.*
                                                              /var/log/popper.log

    (注意:空白部分にはtabを使うこと。)

次に空のログファイルを touch しておく。これはsyslogdを再起動したとき/var/log/popper.logが存在しないとエラーになるためである。

    # touch /var/log/popper.log


■ syslog の再起動

ログの設定をsyslogdに通知する。これはsyslogを再起動すればよい。

    # /sbin/service syslog restart

serviceのように通常/usr/sbinに格納されているコマンドは、フルパスで使うのが安全である。RedHatでは/usr/sbinにパスを持っているバージョンが多いが、システムによってはパスが通っていないことがある。


 動作テストとその他の検証

 xinetdの再起動によるpopperの起動

xinetdを再起動してxinetd経由で起動するpopperの設定を読み込ませる。

    # /sbin/service/xinetd restart

ここでソケットを表示させ、110番がオープンしていることを確認しておくとよい。

    # netstat -ant


■ mailコマンドによるテストメールの送信

自分自身のメールスプールにテストメールを送信して、popサーバのテスト準備をする。これはsendmailのようなMTAがデフォルトで動いていることが前提だが、通常のRedHatならば問題ないはずである。

    # mail root@localhost.localdomain(環境に対応のこと)

    Subject:test
    This is a test mail for popper.
    .
    Cc:


■ telnet による接続確認

telnetで直接110番ポートを叩き、POPサーバへの接続を確認する。

    # telnet localhost 110
    Trying 127.0.0.1...Connected to localhost.
    Escape character is '^]'.+OK
    Ready

以上のように出力されたらひとまずOKとする。

    Qpopper (version 4.0.5) at サーバ名 starting.

以上のようにサーバ名とバージョンが出力されたらNGPOPサーバの機能としてはなんら問題はないのだが、サーバ名およびバージョンが出力されてしまうのは感心できない。shyモードを設定するのはサーバセキュリティが目的なのでこのように出力されてしまう場合は/etc/xinetd.d/qpopper110.cfgを再確認すること。(#をはずしただけでset shy=falesのまま、ということがよくある。)

telnetによるメールボックスの確認

上記
のテストに引き続き、次のPOPコマンドを投入して反応を見る。

    user ユーザー名
    pass パスワード
    stat
    list
    retr
    list
    番号
    quit

※正常な反応が確認されたら、今度はわざと認証されないパスワードを入力してERRを発生させておく。これはsyslog[auth]ログが出力されることを確認するためで、これを実行したのち/var/log/mailに当該エラーに関する[auth]ログがあればOKとする。


 ロギングの検証

設定後、動作確認が終わると一安心するのは人情だが、これはあくまで導入・構築に限った安心であることをお忘れなく。サーバを使う側にとって重要なのは運用・管理フェーズをいかに少ない障害で乗り切れるかにかかっている。万一障害が発生したり何らかのアタックが行われたような場合、ログの参照が必須であるため、仕様どおり確実に採取されているかどうか必ず検証しておかなければならない。

■ ログの確認

    # cat /var/log/popper

先に行った検証のタイムスタンプと通信内容が正しく記録されていたらOK

■ ログのローテーション

/etc/logrotate.d以下にログローテーション用ファイル popperを作成する。

    # cd /etc/logrotate.d
    # vi popper

      /var/log/popper {
          weekly
          compress
          postrotate
              /bin/kill -HUP `cat /var/run/syslogd.pid 2> /dev/null` 2> /dev/null || true
          endscript
      }

ここでは一週間ごとのローテーションでバックログは圧縮する設定とした。設定後はsyslog を再起動し、新しい設定ファイルを読み込ませておくこと。

    # service syslog restart

参考: syslogd を再起動させるのは、ログがローテーションされたとき syslogd がそれまで書き込んでいたログファイルを見失ってしまうからである。このまま放置しておくとそれ以降ログの採取はされなくなってしまうため、syslogd を再起動して新たなログファイルを認識させる必要がある。ログローテーションファイルに postscript を書いておくのはこのためで、上記設定では /bin/kill -HUP `cat /var/run/syslogd.pid 2> /dev/null` 2> /dev/null || true の一行がそれに当たる。すなわち、/var/run以下の.pidファイルからsyslogd のプロセスIDを調べ、HUP シグナルを送る処理を追記すればよい。

■ ローテーションの検証

設定ファイルが正しく記述されていても、設定直後はまだログファイルはローテーションされていない。当たり前のことだが、設定直後はまだローテーションの周期が来ていないからである。ログをローテートさせるためには前回ローテートした日付と現在の日付を比較してローテーション時期を判断する必要がある。Redhat Linuxの場合、前回のローテーションは/var/lib/logrotate.statusに記録されている。新しい設定を検証するにはこのファイルを書換えて
logrotateにローテートする時期が来ていると誤認(?)させればよい。

ここで
logrotateは通常cron.dailyにセットして実行させるプログラムであり、デーモンではないことに留意すること。cronによって毎日決まった時刻に起動されるlogrotateは、まず前回ローテートした日付を記録したファイル/var/lib/logrotate.statusを読み込み、現在の日時と比較する。設定の期日が来ていなければ何もせず、過ぎていればログファイルのローテーションを実行し、logrotate.statusのタイムスタンプを更新する。
/var/lib/logrotate.statusは以下のようなフォーマットで保存されている。

    logrotate state -- version 2"/var/log/messages"
    2004-4-2"/var/log/secure"
    2004-4-2"/var/log/maillog"
    2004-4-2"/var/log/spooler"
    2004-4-2"/var/log/boot.log"
    2004-4-2"/var/log/cron"
    2004-4-2"/var/log/xferlog"
    2004-4-2"/var/log/wtmp"
    2004-4-1"/var/log/rpmpkgs"

このファイルの日付を『ローテーションの周期分以上』過去へ戻して上書きしておけば、起動したlogrotateをまんまとだますことができる。これを確認するには次のようにlogrotateをコンフィグファイル指定つきで起動する。

    # /usr/sbin/logrotate /etc/logrotate.conf

これによって/var/lib/logrotate.status の変更した日付が現在の日付になっており、新しく popper が入っていればlogrotateの動作はOKである。ただし、logrotateをだましてログファイルを出力させたとしても、それは初回のログが作られただけであることに注意されたい。本当にローテーションが実行されることを確認するためには/var/lib/logrotate.statusに新しく記述されたpopperの日付を再度過去に戻し、logrotateを実行する必要がある。

    # service syslog restart
    # /usr/sbin/logrotate /etc/logrotate.conf

これによって /var/log 以下に新しい popper popper.1.gz ができていたら今度こそ検証完了。




 

 

Copyright(c) 2003 My Company. All rights reserved. www.suzu841.com / mrs.suzu841.com