[イプリオの事例紹介] メールサーバ構築案件 （メール認証技術導入、Gmail送信者ガイドライン対応） ｜ 構築編
こんにちは。中の人3号です。
新たにはじまりました「イプリオの事例紹介」シリーズです。このシリーズは株式会社イプリオの業務の内容やサービスの詳細を、私達イプリオがどのように考え、進め、解決していったのか、ということを「事例の紹介」と言う形で、皆さまにお伝えしてまいります。
今回は前回に引き続き「メールサーバ構築案件 （メール認証技術導入、Gmail送信者ガイドライン対応）」の構築編です。サマリー編では本案件の概要をまとめてあります。
※ サマリー編は以下のリンクから。
[ まずは基本的な要件を確認をします ]
「メールサーバ」といっても何が必要となるかは違ってきます。メールサーバなので外部のサーバとの間でSMTPでの通信ができる必要はありますが、他にも考えることは沢山あります。
今回はUNIX系のOS上でのメールサーバの構築に関しての要件を検討します。Windows Serverでメールサーバを構築する場合は別途環境に合わせた検討が必要となります。
メールサーバの要件確認はこんな内容です。
SMTPは何で処理するのか（を考える）
今時は Postfix が一般的なのでこれで作ると楽できる
sendmail を使いたいという要望もあったりはする
sendmail.cf は自由度が高いため、sendmail でしか実現できない機能もある
exim というのもある
あまり触ったことがないので、詳しいことは不明
qmailを使えと言われたら一旦深呼吸して、案件の継続に関して話し合いを持ちましょう
大分前に開発者がサポートを打ち切っていて、コミュニティによるサポートも期待できない状態
既存サービスが独自仕様に依存していると、かなり移行が面倒になる
複数ドメインを扱いたいか（を確認する）
複数のどのドメインにでも同じユーザー（アカウント）がいる形にするならスムースに進む (UNIX系OSでsendmail, postfixあたりを使う場合。システムアカウント+ドメインの形でメールアドレスが利用できるようになる)
ドメインごとにユーザー管理をしたい場合は考える所が出てくる
OS上のユーザーと各メールアドレスのマッピング
そもそもメールのアカウント管理はOSと独立して行う
ユーザーがメールを受け取りたい → 何らかのメール受信プロトコルで通信する必要がある
POP3 が必要か
IMAP4 がいいのか
ウェブメールさえあればいいという場合もある
ユーザーがメール送信したい → 何らかの制限（接続元IP、認証）を行ったSMTP通信をする必要あり
特定の接続元IPならば無認証で送信可能
何らかの認証を行えば送信可能
SMTP認証を行う
認証方式は何を使えるようにするのか
認証に使うユーザー、パスワードのデータベースは何を使うのか
POP before SMTPを使う
POP3接続が成功したIPからの送信を一定期間認める方式
既に廃れているが、とても古いクライアントが残っている場合は必要となる場合もある
ポートは何を使うのか?
SMTP認証ありの場合、587番ポート(submission)か465番ポート(smtps, TLS通信)が一般的
IP制限型の場合、25番ポートを利用する場合もある
メールを転送できるようにしたい
管理者のみ設定変更可能 → aliasesや.forwardで対応
ユーザーにも転送設定を許可する → userminを使って.forwardを編集、またはsieveでの振り分けの一環として転送を許可する
メーリングリストのような同報機能が欲しい
メールサーバ標準の転送機能(sendmail, postfixで言う所のaliasesや.forward)で十分かどうか
メーリングリスト管理ソフトを入れる
MailmanやFMLあたりはこれまでに使ったことがあるので対応しやすい
MajordomoやSympaも聞いたことはあるが使ったことはない（がそれが要件であれば頑張る）
ezmlm? qmailべったりなそんなものは使いたくない…
メールに自動返信したい
仕様に応じて実装することになる
現状で自動返信しているならばその実装を知る必要もある
TLS化は必要か
メール送受信のTLS化は徐々に浸透しているので考慮すべき項目
メール受信プロトコルやSMTP認証はパスワードの受け渡しもあるのでSSL化すべき
既存のメールシステムがTLS化していないので、TLS化不要という場合もある
証明書の購入を勧める
ぶっちゃけるとSMTPでのTLS通信では証明書のチェックを行っていないことが多い。オレオレ証明書でもSTARTTLSでTLS通信に切り替わっていることが結構あってビックリする
スパム、ウイルス対策
商用のアンチウィルスソフトを使うのか?
フリーのアンチウィルスを入れる
ClamAVを使うことが多い
他にもあるが触ったことがない
アンチスパムはどうする
商用のアンチスパムを使うのか?
フリーだとSpamAssassin、rspamdがある
SpamAssassinは古くからあるものなので設定が複雑&若干重い
rspamdは管理しやすい(web GUIで管理可能)が、スパム判定に問題がある
スパム判定部分を事実上使わないで他の機能を生かすような使い方をしている
DKIM, DMARC対応
DKIM は OpenDKIM または rspamd で署名・チェックが可能
DMARC チェックは rspamd で可能
Gmailのメール送信者ガイドライン対策としてSPFも含めて行う必要がある
イプリオではDKIM、DMARC対応を、パッケージ化し一括で導入することができる「メール配送スターターキット」での対応を行います。
バックアップは必要か？
直近のデータに戻すことを想定している場合、最近だと仮想化基盤の上に立てたメールサーバを仮想化基盤のスナップショット機能を使って保存することを提案することが多い
バックアップサーバを別に立ててメールデータをコピーする場合、rsyncで差分バックアップを行う世代バックアップを提案している。rsyncはとても重いのであまりお勧めしたくない
かつてはZFS上にメールデータを置いて差分バックアップを行うシステムを作ったこともある。とても軽いがZFSを使う必要があるのでLinuxだとちょっと厳しい
これらを確定させるため、既存のシステムがあればその仕様を確認、新規であればそれぞれの項目で何が必要なのかお客様から聞き出して要件を定義することになります。
サーバが壊れたとかで要件をキッチリ定義せずに走り出すこともあったりはしますが、その時は走りながら修正していくしかないです。
[ 構築するぞ ]
ここからメールサーバの構築に入りますが、要件を決める際には必ずミドルウェアも検討・決定します。
直近で構築したメールサーバの場合、Postfix, dovecot, rspamd, ClamAV, webmin をインストールしています。
要件の確認
お客さまとのヒアリングや環境等の検証の結果を踏まえてメールサーバリプレイス案件に関するメールサーバ構築に関する要件を決定します。
SMTPサーバ：Postfix
マルチドメインはなし
POP3サーバ：dovecot
複数PCでアカウントを共有しているとのヒアリング結果からの要件として、メールがサーバに残るIMAP4も使えるようにしている
ユーザーが転送設定やサーバ側での振り分けを行う話は出なかったので、managesieveは利用しない
メーリングリスト管理ソフトは不要
同報メールアドレスはaliasesで設定
ウェブメールも不要
イプリオの「メール配送スターターキット」を導入
DKIM, DMARC対応
ClamAVと合わせてアンチウィルスも提供
rspamdも入れるが、日本語スパムで誤判定を出しやすいためスパムチェックとしての本来の用途では使用していない
webminによるアカウント管理
/etc/passwdに登録されたアカウントをメールアドレスとして使用する
インストールと各種設定はそれほど手間がかかりませんが、案外面倒なのがアカウントの登録です。既存のシステムアカウントを持ってくる場合、以下のような問題が出ることがあります。
ユーザーID、グループIDはどうするのか
新システムではプログラムのインストールで作成されたアカウントとユーザーIDが被る場合がある
既存メールサーバでアカウントの登録・削除を繰り返したためユーザーIDやグループIDがバラバラになっている場合、新たに番号を振り直した方が管理しやすくなる
パスワードはそのまま持ってこれるのか
/etc/shadow等に書かれたハッシュ化されたパスワードはハッシュ形式によっては新しいシステムにそのまま移植できないことがある
ハッシュ化されたパスワードを移植できない場合、新パスワードを設定して利用者に通知する必要がある
別の案件では既存のメールサーバのハッシュ化パスワードの形式が古いため、そのままハッシュ化パスワードを持っていけない状態となりました。
この案件では生のパスワードが別に保存されておりそれを使ってパスワード登録を行うことが可能だったため、新パスワードの生成および通知という大事にはならず助かりました。
また、転送(aliasesファイル)の移植も必要です。
aliasesのデータベース形式が移行元と移行先で異なることがあるので、コピー先でnewaliasesコマンドを忘れずに実行しましょう。
事前の動作検証
大抵の案件では既存メールサーバを新サーバに置き換えることになるため、事前の検証では通常のメール配送を使ってのテストができません。
私が検証で行っている方法は次の2つになります。
サーバのSMTPやPOP3、IMAP4に直接接続するツールを使う
SMTPでの動作確認ではtelnetコマンドで接続して直接手でSMTPを流してみたり、swaks というツールでテストメールを送ってみたりしています。 telnetを使った方法だと添付ファイル付きメールの検証(ウィルス検知)が難しいので、そのような時は swaks を使ってみると良いでしょう。 smtps(465番ポート)のようにSSL化した通信で手打ちのSMTPを流してみたい場合はopenssl s_clientを使用しています。 SMTP認証を行う場合、telnet では非常に面倒なので、swaks を使います。
POP3, IMAP4 も動作確認ではtelnetを使って手でプロトコルを流すことが多いです。 受信側のプロトコルの場合、ログイン部分さえなんとかなれば後はメールの内容取得、削除、移動(IMAP4のみ)は手でも簡単に実行できます。
大量のアカウントのログイン確認をしたい場合、telnetではパスワードを毎回打つのが大変になります。 その場合はコマンドラインで動くメールツール、ここではfetchmailを使ってログインできるか確認を行いました。
メールクライアントを使った確認
メール受信で使うPOP3, IMAP4についてはメールクライアントの設定さえどうにかすれば確認できますが、問題はSMTPを使った送信です。
構築中のメールサーバは仮のIPを付けていることが多いので、SPFレコードに登録されていないことがあります。 この場合、大手のメールサーバ(Gmailとか)に送るとSPFチェックにひっかかって場合によってはSPAM扱いされて届かないことがあります。
仮IPもSPFレコードに登録してもらうのが本筋ですがDNSは別の所に依頼しないと変更できない場合も多いので、SPFチェックを厳密に行っていない所(自社ドメインでメインで使っていないもの)にメールを送ってSMTP送信の確認をしています。
これらの確認で問題なければ実際に設置して切り替えることになります。
切り替え
既存メールサーバから置き換える場合、何らかの方法で新メールサーバへメールが送られるようにする必要があります。
DNSのMXレコードを切り替える
新メールサーバ用にグローバルIPとホスト名を割り当て、MXレコードを新メールサーバのホスト名に変更します。
DNSのレコードを変更した場合、最大TTL秒は古いデータを使うクライアントが出るため新旧メールサーバ双方にメールが送られる時間が発生します。
新メールサーバのIPを旧メールサーバのIPに変える
新メールサーバに旧メールサーバのIPを付けてしまいます。 手順としては
旧メールサーバのIPを仮に用意したIPに変える(新メールサーバの仮IPとも異なるものを使用する)
旧メールサーバにログインできることを確認する
新メールサーバのIPを旧メールサーバで使っていたIPに変更する
新メールサーバにログインできることを確認する
動作確認
という形になります。
この方法ではメールサーバが使えない時間帯が発生(旧メールサーバのIP変更～新メールサーバのIP変更)しますが、同時にメールサーバがメールを受け取る時間帯はないのでメールデータの同期が楽になります。
また、VMware ESXi等の仮想化を行っている場合、移行に関連する2つのサーバ(新旧メールサーバ)のリモートコンソールを開いてIP変更を同時に行うことも可能です。 この場合、メールを受け取れない時間帯はほとんどなくすことができます。
動作確認
事前の動作確認同様、メールの送受信テストを行います。
また、外部メールサーバがMXを引いて配送できるようになったので外部メールサーバからの送信テストも実施しています。
データの移行
旧メールサーバのメールボックスに残されたメールを新メールサーバにコピーすることになります。最初に上げた案件ではmbox形式からMaildir形式に変換する必要があったため、
mbox形式のメールデータを新メールサーバへコピー
各アカウントごとにスクリプトを使ってmbox形式のメールデータをMaildir形式へ変換する
ということを行っています。変換スクリプトとしてはperfect_maildir.plを使用しました。ただし、変換対象のmbox形式メールデータの一部に不備があったため、そこを上手く処理できるようスクリプトの一部を変更しています。
[ 稼動後の不具合修正 ]
稼動後のクレームとして上がっていたものは以下の1件くらいでした。
サイズの大きなメールが届かない／送れない
移行後のPostfixのメールサイズ設定を変更していなかったことで発生した不具合でした。 メールサイズ設定を変更することで問題がなくなりました。
もともと弊社で提供するメールサーバは noteのコラム「メールが送れない未来がやってくる？！」 で書いているメール配送スターターキットの形で標準化しているので、この枠に入る要件ならば不具合が出にくいと思います。
[ まとめ ]
直近で行ったメールサーバ構築案件を思い出しながら、メールサーバ構築では何をやっているのかを書き出してみました。案件を振り返る機会はなかなかないので、文書に書き起こしてみると要件定義の重さが結構あるものだと実感しました。
皆さんも案件が終わったら、それに託けて文書化してみると何らかの気付きが得られるかもしれません。
サマリー編は以下のリンクよりご覧いただけます。
[ お問い合わせ ]
本件に関するお問い合わせ、お仕事のご依頼などは「イプリオのお問い合せページ」より、お気軽にご相談ください。
株式会社イプリオのエンジニアズです！ ネットワークやサーバに関わること。お客さまのインターネットでのビジネスを支えるコラムを連載していきます！