Mongersテクニカルトーク#10をみてます(現在進行形)。groupがみられるのは便利。*1たまたまですが、Perlアプリケーションフレームワークの話題。知らないだけでいくつかあるらしい。考えることはみんな一緒らしい。メンテ時間が取れないのが悔しくなってきますね。問題発生ある方より、メール投稿利用時に長い日本語タイトルを付けると、途中に半角スペースが入ってしまうというバグ報告を受けました。=?ISO-2022-JP?B?GyRCRys+YUcrPmFHKz5hRys+YUcrPmFHKz5hRys+YUcrPmFHKz5hGyhC?=のようにMIMEエンコードが長くなり空白が入ったときに、この空白がデコードされてもそのまま残ってしまうことが原因です。やっつけならこの空白を除去するだけで良いのですが、やっつけプログラムは最低なのできちんと調査してみました。Format」には次のように規定されています。行の長さの制限それぞれの行の文字はCRLFを除いて、決して998文字以下でなければならず(MUST)、78文字以下であるべきである(SHOULD)。長いヘッダフィールドそれぞれのヘッダフィールドは(略)単一論理行である。便宜のため、文字数制限のために、ヘッダフィールドの一部であるフィールドボディは複数行に分割して表現でき、これをfoldingと呼ぶ。どこであれfoldingのホワイトスペース(WSPではない)があるとき、WSP(SPACE/0x20またはTAB/0x09)の前にCRLFを挿入してよい。testは以下のように表現できる。WSPがすぐ後に続くあらゆるCRLFを単に削除することでなされる。RFCの規定に従い、最初に例示したメールヘッダは次のように復元されます。=?ISO-2022-JP?B?(略)?=ここまでは正しい復元過程であり、やっつけ実装として考えた「単純に複数行ヘッダの2行目以降の先頭空白の除去」は誤りであることがわかります。bbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbというように78文字の制限を超えてメールヘッダが作られました。単純な先頭空白除去では、このような改行位置が半角の文になっているメールを受信した際に問題が発生します*1。そもそもRFCの規定で「CRLFを単に削除する」となっているのですから、そこは正しく従わねばなりません。ちなはにnPOPはこの実装でした。MIMEの規定では「長い日本語タイトルの途中に空白が入る問題」はどこに実装の誤りがあるのでしょうか。2047「非ASCIIテクストのためのメッセージヘッダ拡張」を参照します。'encoded-word'は、いわゆるMIMEエンコードのことです。822により次にように定義されています。あってもなくても良い。elementの少なくとも1つ以上の繰り返し。SPACE(又はTAB)"の1つ以上の繰り返しは削除すべしということになります。正しいメールヘッダ復元の実装Perl正規表現で次にように行います。/ieg;ベース64デコード関数は別に用意してください。])+上記が、linear-white-spaceに相当します。])+の方が良いと思います。規定を先に適用して、先に改行コードを除去してから、MIMEエンコード間の空白除去を行っても動作としては変わりません。実装を最後に示します。ServerLimitを設定しているにも関わらず、またデータベース接続エラーが。それとも仕様??検索してみても、同様の報告しかみつかりませんでした*2。1000を越えたときに、古いプロセスがうまく殺せていないようです。影響しているかどうかは不明です。して様子をみようと思います。されないせいと思われます。MySQLではコネクションを永続させても、MySQL側が自動的にタイムアウトをして接続を切る。