webメールシステムrainloopの導入
さて、新規環境ついでに以前からやりたいと思いつつ手がついていなかったこともいろいろやってみている。そのうちの一つが、webメールシステムの導入である。普段は自宅のPCとタブレットでメーラーにてメールを使用しているが、会社へはどちらも持ち込みできないし、ちょっと出かけるときにタブレットも持ち歩かないこともある。ガラホ持ちだったりするのだが、ブラウザはあるのでwebメールがあればメールを見るだけくらいならできるのになと思うことがたまにある。そんなわけで入れてみた。
どれにしようか
そもそもどんな選択肢があるのだろう？いろいろなサイトをみたところRoundcubeとRainloopがメジャーなようだ。最初はRoundcubeがいいかと思ったが、いろいろみているうちにRainloopの方が良さそうと思えてきたのでそちらにした。
設置が簡単そう、というのが一番大きい理由だ。UIも今風な感じだし。（必ずしも今風がいいとは考えないが）今風といえば、モバイル環境で勝手が良さそうなのもRainloopの方が良さげな印象。まぁRoundcubeは触れてないので実際のところはわかりませんが・・・
まぁ、実際に簡単だった。Rainloop自体の導入は。実際の導入に際してはいろいろハマってしまったが・・・
インストール
pkg search すると見つかったため、pkgによるインストール。お手軽である。ファイル群はapacheのデータフォルダ（phpMyAdmin等とおなじところ）へインストールされて勝手がいい。
/usr/local/www/
apache24/
phpMyAdmin/
rainloop/
と並列に並ぶ感じ。（apache24の下に直接のdataフォルダがある）
設定ファイルは /usr/local/etc 以下に入ったが、何も触ることはなかったような。。。
設定
Apacheの設定
apacheの設定ファイルまでは編集されない。まぁ勝手にされても、だが。
インストールされたフォルダにアクセスできるように設定すればいいだけなので大したことではない。
しかし、今回はこれを機にSSL(https)対応しようと思い、apacheへSSL対応の設定も追加した。さすがにメールのパスワードを平文でやり取りってねぇ。
というわけで、ここでapacheのSSL対応をする。
で、rainloopへのアクセスはhttpsのみとする。
ちなみに、本ブログはこの記事を書いている現在はhttp / https両アクセス可能にしているが、httpsが安定して稼働できていることが確認できたらリダイレクト設定をしようと考えている。
これで動作するはずだと思っていたのだが。。。
起動
通常ユーザ
httpsでアクセスして起動する。httpでアクセスすると403 forbiddenとなる。意図通りの動作である。
この時点では何も設定していないので当然ログインはできない。
管理
管理画面にアクセスしてwebページ上で種々の設定ができる。
まずはadminでログイン。パスワードは決め打ちで"12345″なんだそうな。なので、心配な方はこの初期設定が終わるまではローカルネットからしかアクセスできないようにapacheを設定するとか工夫が必要かも。
まず最初に、言語を日本語にした。日本人なのでｗ。その後、管理用パスワードを変更する。素直に変更を押せばよい。
何も難しいことはない。管理者用のログイン名も変えられるようなので変えておいた。そして、変更後のIDで再ログイン。
その後、ドメインを追加する。
左から「ドメイン」を選択する。
上のボタンを押すとドメインの追加ができそう。
私の環境での情報を入力して、左下の「接続テスト」をしてみる。
スクリーンショットを撮り忘れたが、ここで見事にエラーとなる。。。
ドメイン追加できない
失敗した旨はわかるのだが、何がダメだったのかはよくわからない。が、どうやら今の状態ではドメインの追加ができないのは確実である。このままでは使えないのでエラーの解析とその対策を探る旅に出る。
エラー解析・対策
rainroop視点からアプローチ
とりあえずネット上の情報を漁る。ここで、なぜだか もしかしてオレオレ証明書が原因？ と、勝手な勘違いをしでかす。とりあえず、HTTPのSSL の方の認証のエラーとメールPOP/IMAPのSSL/TLSの認証のエラーがこんがらかってしまって頭が疲れる。で、認証がらみのエラーで出てきたのが、オレオレ認証関係というわけ。
最初は、理屈がわからなく納得できない腹落ちしないものは信用しない姿勢でいたのだが、どうにもわかるような情報もなく、とりあえずオレオレ認証からの卒業の道をたどることを考える。
無料サーバ証明書の導入
Let’s Encryptを入れることに。まぁ、これもいずれオレオレ認証からの卒業を考えたいとの思いはあったので、今がそのタイミングなんだと言い聞かせｗ
導入方法の情報は、非公式？情報サイト「Let’s Encrypt 総合ポータル」の「Let’s Encrypt の使い方」に詳細に書かれている。左記ページに素直に従えば迷うことなく指定の場所にファイルが出来上がるので、ここでは手順は割愛させていただく。
そして、出来上がったファイルへのパスをPostfix、Dovecotの設定ファイルに記載してそれぞれのサービスを再起動。すると、、、通常のメーラーでも受信できなくなった（大泣）幸い、Postfix側は無事に動作しており、外部へのメールの送信はできるし、外部からのメールがローカルのバーチャルホストのデータディレクトリには届くのでとりあえずメーラーで見られないだけで外に迷惑はかからない状態。しかしまぁメーラで見られなければ自分が困るので、なる早で対応せねば。こんなタイミングで通販サイトからの連絡メールが来ていたりするしｗ
rainloopを離れてあがく
まずは通常のメーラーで使えるように復旧させねばならないが、とにかく何が起こっているのかを把握しなければならない。まずはDovecotのエラーログを覗く。と以下のようなエラーが大変な勢いで出力されている。。
Jun 09 07:45:05 imap-login: Info: Disconnected (no auth attempts in 1 secs): user=<>, rip=203.143.121.10, lip=203.143.121.12, TLS handshaking: SSL_accept() failed: error:1408A0C1:SSL routines:ssl3_get_client_hello:no shared cipher, session=</uOuJilurvTLj3kK>
まぁ似たようなエラーに
Jun 04 09:13:16 pop3-login: Info: Disconnected (no auth attempts in 0 secs): user=<>, rip=139.60.163.5, lip=203.143.121.12, TLS handshaking: SSL_accept() failed: error:140760FC:SSL routines:SSL23_GET_CLIENT_HELLO:unknown protocol, session=<9I/WzMVthQiLPKMF>
こんなのがあるが、これは想定通りのエラーなので勘違いしやすい。
しかし、このエラーメッセージにより大変な混乱を招くことになる。ネット上の漁っても意図的にSSLv3の無効化に関する情報しか発見できず、このエラーメッセージの発生によりIMAPへの接続ができなくなったという例が見当たらないのだ。今回なんらそこら辺の変更を施した覚えはない。サーバ証明書を変更し、そのパス設定を変更しただけなのだから。とりあえず途中用事のため外出せねばならず、仕方なくIMAPSを止めた状態で外出。ユーザーが自分しかいないからできるワザｗｗ
帰宅後、再びいろいろあがくが糸口が見えない。SSLv3無効化の話はわかるのだが、その関連の設定を変えてみたところでそもそも無効化された時と同じメッセージが出てしまって接続できていないのだから話が噛み合わない。そもそもSSLv3とかどうでもよく、使えるようになってくれ、と悲鳴を上げる状態に。混乱と発狂。
状況を整理すると、
IMAPに接続しようとすると（上記の）エラーログを残して接続に失敗する
という単純な一点であります。エラーメッセージから確実に言えるのはTLSのハンドシェイクに失敗する、と。
とりあえず、一旦IMAPのみを開けて届いていたメールをメーラーでチェック。注文の品は在庫ありで確保しましたとの連絡。その他、途中で何度か自分が出したテストメール。サーバ間での送受信については正常に動作していることが見て取れ、安心である。
そして、再びIMAPを閉じてIMAPSを開ける。ちなみに、オレオレの頃の認証ファイルを指定してもダメなのだ。後退している。泣けてくる。
そのあたりをいろいろ試すうちに、ふと見えた。Dovecotのssl周りの設定ファイルに不備があるようだ。
まずは正常に稼働していた頃の設定。
ssl_cert = </etc/ssl/skyactiv.jp/server.cer
ssl_key = </etc/ssl/skyactiv.jp/server.key
local_name skyactiv.jp {
ssl_cert = </etc/ssl/skyactiv.jp/server.cer
ssl_key = </etc/ssl/skyactiv.jp/server.key
}
local_name ****.com {
ssl_cert = </etc/ssl/****.com/server.cer
ssl_key = </etc/ssl/****.com/server.key
}
次にLet’s Encryptの認証ファイルを指定した状態。（間違い）
#ssl_cert = </etc/ssl/skyactiv.jp/server.cer
#ssl_key = </etc/ssl/skyactiv.jp/server.key
#ssl_cert = </usr/local/etc/letsencrypt/live/mail.skyactiv.jp/fullchain.pem
#ssl_key = </usr/local/etc/letsencrypt/live/mail.skyactiv.jp/privkey.pem
local_name skyactiv.jp {
#mailサブドメインをつけたオレオレ証明書も作成してみて試す
# ssl_cert = </etc/ssl/mail.skyactiv.jp/server.cer
# ssl_key = </etc/ssl/mail.skyactiv.jp/server.key
ssl_cert = </usr/local/etc/letsencrypt/live/mail.skyactiv.jp/fullchain.pem
ssl_key = </usr/local/etc/letsencrypt/live/mail.skyactiv.jp/privkey.pem
}
local_name ****.com {
# ssl_cert = </etc/ssl/mail.****.com/server.cer
# ssl_key = </etc/ssl/mail.****.com/server.key
ssl_cert = </usr/local/etc/letsencrypt/live/mail.****.com/fullchain.pem
ssl_key = </usr/local/etc/letsencrypt/live/mail.****.com/privkey.pem
}
ここで、参考のため最終的に正常に動作するようになった設定を示す。
local_name mail.skyactiv.jp {
ssl_cert = </usr/local/etc/letsencrypt/live/mail.skyactiv.jp/fullchain.pem
ssl_key = </usr/local/etc/letsencrypt/live/mail.skyactiv.jp/privkey.pem
}
local_name mail.****.com {
ssl_cert = </usr/local/etc/letsencrypt/live/mail.****.com/fullchain.pem
ssl_key = </usr/local/etc/letsencrypt/live/mail.****.com/privkey.pem
}
もともとのサーバの設定はもう何年も前のことなのでうろ覚えだが、クライアントの認証受け入れ時、ドメインが合わないが受け入れるか？的なメッセージが出ていたと思う。特に****.com側でも情報はskyactiv.jpの情報だった記憶があるが、オレオレだしそれで受け入れ許可したらその後使用に差し支えないのでそのままにしていた。
上記から、間違いを自己発見したので記しておこう。
参考として、私の環境では以下の設定でメールサーバーが構築されている。
- メールアドレス
username@skyactiv.jp
username@****.com - IMAPSメールサーバ
mail.skyactiv.jp
mail.****.com
ここで、最初の設定ファイルの問題点を挙げておく。
ssl_cert = </etc/ssl/skyactiv.jp/server.cer （１）local_name外に設定
ssl_key = </etc/ssl/skyactiv.jp/server.key
local_name skyactiv.jp { （２）ホスト名のないドメイン
ssl_cert = </etc/ssl/skyactiv.jp/server.cer
ssl_key = </etc/ssl/skyactiv.jp/server.key
}
local_name ****.com { （２）
ssl_cert = </etc/ssl/****.com/server.cer
ssl_key = </etc/ssl/****.com/server.key
}
ミスを晒すのは恥でもあるが、同じことで悩まれてしまった方にご参考になることがあれば・・・
まず、（２）の箇所にメールサーバの名称を書くべきところ、メールアドレスのドメインを書いているところがミス。なのでmail.****.**でアクセスすると該当するlocal_nameの定義がないことになる。そして、（１）にフェール（のつもりだったんだろう）で入れているものがあるので、常に（１）のファイルを使用していたことになる。
そして、Let’s Encryptの認証ファイルを記述する際に（１）の位置の記述を外したため、使用できるファイルがなく、TLSハンドシェイクできないということになったわけです。
きっと、（２）の記述さえ正しければオレオレ証明書でも問題なく動作したのだろうと思います。が、あえてオレオレ証明書に戻す理由もないのでこのままにしておきます。
どちらにしろ、web側の証明書はオレオレだとブラウザによって警告が出て閲覧ユーザさんに手間かかりますから。
でもまだ、Let’s Encryptの自動更新とか設定してないですけど（笑）
ようやくrainloopに戻る
さて、メーラで正常に受信ができるようになり、今まで手動で受け入れしていたホスト名間違いの証明書でなく正しい証明書で稼働するようになりました。
ここでrainloopに戻り、再びドメイン追加をおこなう。
何事もなかったかのように「接続テスト」を通りました。別のドメインも追加をおこない、ちゃんと使えるようになりました。
ガラホでもアクセスすることはできました。ブラウザ上なのにタッチ前提なUIで使いにくいですが（笑）
今回はDovecotの設定不備でハマってしまいましたが、rainloop自体の導入はあっけないくらい簡単でした。