プラグイン作者です。
少々乱暴なのですが、投稿用のメールに届いたメールは全てユーザID１（又は任意のユーザ）の投稿として処理する事は可能でしょうか。
これ自体は可能ですが、今回の状況の場合、From フィールドのチェックができていないわけで、spam 着信時に spam 投稿されるおそれがあります。
むしろ、元のメールヘッダがどのような記述になっているのかを調査して、きちんと解析するのが、あるべき解決方法だと思いますので、お手数ですが、問題が発生するやり方で、「yuriko-wp-forum＠ゆりこねっと」宛にメール送信をお願いいたします。
海外の携帯電話からメールを送受信する場合は、付属のメーラーを使いプロバイダ等のメールを利用する以外に方法はないので、解決できれば海外在住の方でも気軽にブログ更新ができ、より便利になると思います。
それはそうなのですが、さすがに「海外のあらゆるキャリアと契約して事前に問題を潰しておく」のは不可能ですので、問題発生時に逐次対応するしかありません。従いまして、kawaki さんのご協力が不可欠です。よろしくお願いします。
台湾キャリアということで、文字コードの違いが理由かもしれません。ある程度、文字コードに依存しない検出方法をとっていますが、中文メールはまるで実験していませんので……。
＞lilyfanさま
先ほど、説明のメールと共に合計４通を私の携帯電話から送信致しました。
説明のメールにも記載致しましたが、
添付ファイルありで特定の文字が入っていると、Ktai Entryがメールを受信する際にエラーと返すようです。
どの文字が入る場合にエラーとなるかの詳細はまだ特定できていませんが、今のところ「お外真っ暗」「遅めのお昼」「工事が五月蝿いから」などが件名に入ると投稿できません。
「てすと」という文字を件名にすると、同じ添付ファイル、同じ本文でも投稿可能となります。
また、「ケーブル工事？」という件名にては、同じ添付ファイル、そして別の本文を書きますと投稿できたりエラーになったりします。
＞＞携帯電話を使わずにGmailのサイトから直接メールを送ると添付付きのメールも正常に投稿できます。
この事から、送信する環境（携帯電話の機種など）に依存するのではないかとも考えています。
日本の携帯電話からも上記の文字を入れた場合に正常投稿できるか確認して頂ければと思います。
＞元のメールヘッダがどのような記述になっているのかを調査して、きちんと解析するのが、あるべき解決方法だと思います
妥協策として受信メール全投稿を考えていたのですが、プラグイン作者様が解決に乗り出して頂けるなら私としても心強いです。
こちらこそ、よろしくお願い致します。
先ほど、説明のメールと共に合計４通を私の携帯電話から送信致しました。
受領しました。
こちらでテストしたところ、マルチパートの境界を示す文字列 (boundary 文字列) にシングルクォートが含まれるときがあり、そのときに添付ファイルを解析できず、エラーで止まっていました。
boundary 文字列をダブルクォートで括ればシングルクォートを含むのは問題ないため、Ktai Entry が利用している PEAR の Mail_mimeDecode パッケージのバグと予想されます。
とりあえず、Ktai Entry 側で、無理矢理 boundary 文字列をいじって直すしかないですね。
附属の mimeDecode パッケージを修正することは可能ですが、もしサーバーに mimeDecode がインストールされていればそちらを優先して使う仕組みのため、Ktai Entry に同梱しているパッケージを直しても意味がないのです。(PEAR パッケージ作者にバグレポートを上げる必要があります)
とりあえず、Ktai Entry 側で、無理矢理 boundary 文字列をいじって直すしかないですね。
これですが、post.php の399行目付近の decode_message() 関数先頭に以下のコードを追加してください。
if (preg_match('!^Content-Type: multipart/mixed;.*?boundary="?(.*?)"?$!ims', $message, $boundary, PREG_OFFSET_CAPTURE) && preg_match("/'/", $boundary[1][0])) {
$new_boundary = preg_replace('/[^0-9a-zA-Z+.-]/', '_', $boundary[1][0]); // fix for EPOC Email (Nokia build-in)
$message = substr_replace($message, $new_boundary, $boundary[1][1], strlen($new_boundary));
$message = preg_replace('/^--' . preg_quote($boundary[1][0], '/') . '(--)?$/m', '--' . $new_boundary . '$1', $message);
}
多分これで動くと思います。お手数ですが、修正後、報告をお願いいたします。うまくいけば、次期バージョン (0.9.0 を予定) で採用したいと思います。
この修正はかなりいい加減で、修正した boundary 文字列が、既存の本文と衝突しないことの確認をさぼっています。通常は衝突しないはずなので、まあいいかと思います 😉
＞lilyfanさま
問題の解析及びコードの提供ありがとうございます。
こちらでテストしたところ、マルチパートの境界を示す文字列 (boundary 文字列) にシン
グルクォートが含まれるときがあり、そのときに添付ファイルを解析できず、エラーで止
まっていました。
メールヘッダの誤読というよりも、文字列の処理方法に原因があったわけですね。
プラグインの問題だと思っていましたが、他の場所での問題でしたか。
お手数ですが、修正後、報告をお願いいたします。
post.phpに上記の修正を加え、昨日投稿できなかった同じ条件にてテストを行いました。
その結果、テストを行ったメール全てが正常に投稿できることを確認いたしました。
しばらく様子をみまして、また問題が発生するようならご報告いたします。
トピック作成時の問題は解決しましたので、このトピックは「解決済み」とさせて頂きます。
この度は、本当にありがとうございました。
これで安心してメール投稿が行えます！
メールヘッダの誤読というよりも、文字列の処理方法に原因があったわけですね。
プラグインの問題だと思っていましたが、他の場所での問題でしたか。
プラグインが利用している MIME 解析ライブラリーの問題なので、広い意味ではプラグインの問題です。メーラー側も、広く使われているライブラリーで問題を起こしてしまう文字を使ったというのは、いまいちな気もしますが、RFC には違反していないので、責めるのはかわいそうです。
ということで、PEAR::mimeDecode の作者にバグレポートを出さないといけませんね……。466 行の
$splitRegex = '/([^;\'"]*[\'"]([^\'"]*([^\'"]*)*)[\'"][^;\'"]*|([^;]+))(;|$)/';
を
splitRegex = '/([^;\'"]*([\'"])([^\2]*([^\2]*)*)\2[^;\2]*|([^;]+))(;|$)/';
に直せばよさそうです。
