cles::blog

モダンな qmail を目指す notqmailというプロジェクトが始まったようです。

• notqmail/notqmail

qmail はセキュアで設定しやすい MTA なのですが、今となっては現在のネット環境に必要な機能（SMTP Auth や TLS、IPv6、DKIM など）がほとんど実装されていないので、実際に使おうとするとあちこちから野良パッチをあてて試行錯誤しながらビルドする羽目になります。僕も 2000 年くらいから 2016 年の暮れまで運用していましたが、現在のサーバに移行するときにそれに嫌気が差したので、MTA は postfix に乗り換えてしまいましたが、必要な機能がつくのであれば出戻りしてもいいかなと思っています。

コミュニティ主導のqmailフォークプロジェクト「notqmail」が立ち上げられる | OSDN Magazine

qmailはDaniel Julius Bernstein（djb）氏が1990年代後半に作成したメッセージトランスファーエージェント。最後のアップデートは1998年で、その後qmailの流れをくむnetqmailが登場したものの、やはり2007年よりアップデートされておらず、それぞれがフォークを作成するという状態が続いている。notqmailはこれに対し、集合的な取り組みにしようと呼びかけている。

MTA を qmail から postfix に変更したので、メーリングリストドライバも ezmlm-idx から Mailman に移行することにしました。

† メンバーの移行

ezmlm からのメンバーの一覧は以下のコマンドで取り出すことができますので、このリストを Mailman に登録してやれば OK です。

† アーカイブの移行

ちょっと苦戦したのが、過去メールアーカイブの移行。

過去メールを全て捨てても良いのであれば問題ありませんが、できればそのまま移行したいということで頑張ってみました。

「[mailman-users-jp 2880] fml から Mailman への移行手順」によると、mbox 形式があれば以下のコマンドでアーカイブの移行ができるようです。

つまり、ezmlm のディレクトリから mbox 形式のファイルが生成できさえすれば、移行は簡単にできそうです。これを行ってくれるプログラムを探してみたところ perl で書かれた ezmlm2mbox が見つかったので、今回はこれを使わせてもらうことにします。オリジナルのスクリプトには From: と Date: を書き換えてしまう機能があるようなのですが、余計なことをして欲しくないのでこの機能を殺すように書き換えてから使っています。

diff -u ezmlm2mbox{.org,}

最後に ML のカウンターを引き継ぎます。
ezmlm のカウンターは num というファイルの : の左側の部分なので、以下のコマンドで数値を確認しておきます。

以下のコマンドを打ち込むと mailman の設定を読み込んだ Python のコマンドラインが開きます。

以下の Pyton のコマンドを入力すればカウンタの引き継ぎは完了です。

Let's Encrypt は誰でも無料で利用できる SSL 証明書ですが、有効期間が90日しかない^*1ので定期的な更新の自動化が欠かせません。

これを行うためのクライアントとしてはオフィシャルな Certbot がありますが、実行に sudo を要求するので、レンタルサーバなどで root 権限を持っていない場合には利用することができません。その他にも Python が必要だったりと使い勝手があまりよくありません。というわけで、sudo がなくても実行できるクライアントを探してみたところシェルスクリプトベースの dehydrated(letsencrypt.sh) を見つけました。

自分のサーバやさくらのレンタルサーバでも以下の手順で動作させることができました。

WELLKNOWN ディレクトリの中身のファイルについては HTTPd 経由で外部からアクセスできる必要があります。
これらに問題なくアクセスできれば、 Let's Encript からの証明書が certs/(FQDN) に格納されます。
具体的には

• cert.pem（証明書）
• chain.pem（中間証明書）
• fullchain.pem（証明書＋中間証明書）
• privkey.pem（秘密鍵）

というファイル群ができているはずなので、メールやウェブなどの各種デーモンの設定ファイルから生成された証明書や秘密鍵を使うように設定すればOK。

† 更新の自動化

証明書の更新は cron などで定期的に dehydrated -c を実行してやるだけですが、例えば更新したあとに httpd を graceful したい場合には以下のような hook.sh スクリプトを作って、config の HOOK に設定してやれば、証明書が更新された時だけサービスを再起動するようなことができます。

また、qmail-tls のファイルは以下のような感じで更新できます。

† 2017/02/05 追記

• HTTP ではなく DNS を使った設定についてはこちらから。

• ^*1: 証明書の有効期間が90日間な理由 - Let's Encrypt 総合ポータル

自分が管理しているメールサーバは未だに qmail を使っている関係でメーリングリストドライバが ezmlm だったりするのですが、最近「メールが読める（配信されている）けれども、送信しようとするとエラーになる」と相談を受けたので、念のため qmail-send のログをさらってみると下記のようなエラーログが吐かれているのを発見。

どうやら ezmlm-reject が Subject が空だとお怒りの様子。
これをどうにかして回避できないかと検索してみたら、ちょっと古めですが @IT の記事に下記のような Tips を発見。

実用qmailサーバ運用・管理術（5）：メーリングリストの構築と運用（後編） (2/3) - ＠IT

Subjectが空白かどうかの判定は、editorファイルのezmlm-rejectで行われます（editorファイルは.qmail-ml2の実体）。ezmlm-rejectに-Sオプションを指定することで、空Subjectでの投稿が可能になります。

|/usr/local/bin/ezmlm/ezmlm-reject '/var/ezmlm/ml2'

修正前

|/usr/local/bin/ezmlm/ezmlm-reject -S '/var/ezmlm/ml2'

修正後

これを参考に ezmlm-reject に -S をつけたのでもう大丈夫でしょう。

先日、ghettoVCB.sh を設定して ESXi のホットバックアップが取れるようにしたときに、メール通知機能を設定してみたもののメールが飛んできませんでした。experimental と書いてあるのであまりツッコミ入れてはいけない部分なのでしょうが、やっぱり不便なのでちょっと原因を調べてみることにしました。

まず、メール送信の部分をチェックして見ると、 nc の出力が /dev/null に捨てられているところがあったので、この部分をファイルにリダイレクトして内容を確かめてみます。

最後の行は qmail の吐いているエラーで、改行コードとしてLFだけ^*1の行をみつけたので qmail がメールを飛ばしてくれないというオチでした。これを黙らせるには、改行コードを CR + LF に統一するしかないのですが、デフォルトでつかえるコマンドが極端に少ない ESXi だったので多少手こずりましたが、 awk を使ってこんな感じで改行コードを統一してみました。これで qmail を使っていても ghettoVCB.sh の処理結果をメール通知することができます。

• ^*1: SMTP では改行コードは CR + LF である必要があるので。

STARTTLS の実装に脆弱性が見つかった情報がJVNで公開されています。

JVNVU#555316: 複数の STARTTLS 実装に脆弱性

複数の STARTTLS 実装には、中間者攻撃 (man-in-the-middle attack) によって、コマンドを挿入される可能性があります。本脆弱性は、暗号文通信への切り替えがアプリケーションより下位の層で行われていることに起因しています。

問題なのはこのJVNにはほとんど情報がでていないことで、元ネタの「US-CERT Vulnerability Note VU#555316」を読むと結構広範なプロダクトに影響がありそうな感じ。postfix にアップデートが出たりしてた^*1のもどうやらこの問題に対するアップデートですね。

で、もしやと思って探してみたのですが、Qmail-TLS patchにも影響ある^*2ようです。 qmail で STARTTLS 対応している場合にはチェックしておいた方が良さそうな感じ。 qmailは どうしても拡張が全部パッチになってしまっているので、 qmail 自体にセキュリティ問題が生じなくても、あたっているか、あたっていないかをいちいち確認しながらパッチのセキュリティfixを追いかけていくのは正直しんどいです。やっぱりこういうの見てると qmail 終わりかなぁ。

• ^*1: Plaintext command injection in multiple implementations of STARTTLS (CVE-2011-0411)
• ^*2: Qmail-TLS Information for VU#555316

JPRS から qmail が DNS の応答サイズが大きい場合にうまく取り扱えない問題についてのお知らせが出ていたのでメモ。

qmail/netqmailにおける512バイトを超えるDNS応答の不適切な取り扱いについて^*1

近年、DNSSECの本格運用開始やIPv6、SPFなどの技術の普及により、DNS応答のサイズが増大する傾向にあります。これにより、これまで潜在していた512バイトを超えるDNS応答の不適切な取り扱いが顕在化し、予期しない障害が発生する場合があります。
現時点において、メール配送ソフトウェアの一つであるqmail、及びqmailにいくつかのバグ修正や機能拡張を実施したnetqmailには本件に該当するバグが存在することが判明しており、特定のドメイン名あての電子メールの配送ができなくなる障害の発生が確認されています。

これ、確かDJBはバグと認めてなかったような気がしますが、かなり前から知られているバグですよね。
最近になって騒がれだしたというのは、実際、メールがうまく送れないという事象が多発したりしているんだろうと思います。

qmailは実際に使えるように運用しようとすると、かなりの数のパッチを当てる羽目になります。正直、これから新規にインストールするのはオススメできない状態になっているのですが、僕のところではまだ現役です。確認しましたが、このお知らせで触れられているパッチは既にあたっていました。次にサーバを借りる時には postfix にしようかなと思っています。別に qmail 自体はどうでもいいんですが、 postfix に vpopmail にあたるようなものがあるかどうかが問題なんですよね。

• ^*1: via qmail/netqmailにおける512バイトを超えるDNS応答の不適切な取り扱いについて(セキュリティホール memo)

「qmail で作る快適メールサーバー」が公開されていたのでメモ。元ネタはおそらくこの書籍だと思いますが、こちらは既に絶版になっているようです。こうやって絶版本を復活させる試みは面白いですね。

最近は qmail を新規に導入することは少ないと思いますが、既に導入されているサーバで .qmail を書かなければいけないようなときに「第7章 .qmail ファイルの利用」あたりは役に立つかもしれません。ざっと読んだ感じでは、パッチ関連は qmail を使っている（というか、netqmailでインストールしている）人であれば既知のものが多いと思います。

新しくメールサーバを作ったので、仕上げにオープンリレーになっていないかを下記のサービスでチェック。

　・第三者中継チェック RBL.JP
　・Mail relay testing

今どきよっぽどおかしな設定をしなければ、メールサーバーがオープンリレーになる事はないと思いますが。

サーバで"yum update"を実行したら、（たぶん）opensslがアップデートされた副作用でqmailのSSL/TLS接続ができなくなってしまったのでトラブルシュートしてみました。

手始めにopensslを使ってsmtpサーバに接続するとhandshake failureで接続できず。普通のSSLを使っていない場合には普通に接続できるのでSSL関連の障害であることは間違いがないようです。

とりあえず、SSLのエラーが起きていることは分かりましたがこれだけでは何の手がかりにもならないので、プロトコルを変更してて色々試してみたところ、SSLv2に固定したときにエラーがno cipher listに変化することがわかりました。

Cipherに関する設定項目はqmail-smtpd.cとqmail-remote.cのソースを眺める限り、control/tlsserverciphers、control/tlsclientciphersしかありません。これまではファイルがなくてもうまく動いていたので気にしていませんでしたが、ひとまずこのファイルを作成してみることに。