ただつらつらと日記が書かれていくようです。

タグ: はてなダイアリーからの移行記事 (14ページ目 (18ページ中))

phpmailerを使うと、MIMEエンコードしたsubjectが改行されない(涙)

PHPからメールを簡単に送りたいなぁと思って、phpmailer(使ったバージョンは、リリースされたてのVer.5.0.0)を使ってみた。

ちらっとソースとドキュメントを読んで、サンプルアプリで使ってみていたら、Subjectの処理で少し気になることがあった。端的に言えば、長いSubjectのメールを送ろうとしたときにMIMEエンコードされた文字列が改行されずに1行になってしまい、その文字列を埋め込んだメールヘッダーがRFCに引っかかってしまう恐れがあるという事象に直面した。

で。

Subjectに日本語を入れたりする場合は、SubjectをMIMEエンコードする必要があるので、PHPのmb_encode_mimeheaderって関数でMIMEエンコードした文字列を作って、それをphpmailerに渡して、どーんとメールを送ってみた。

…すると。

MIMEエンコードされた文字列は生成されたものの、MIMEエンコードされた文字列が1行に連結されてしまっていた(汗)(…強制改行されているとは思いますが、実際は1行です。)

Subject: =?ISO-2022-JP?B?GyRCJDMkbCRPJUYlOSVIJWEhPCVrJE4lNSVWJTglJyUvJUgkMyRsGyhC?= =?ISO-2022-JP?B?GyRCJE8lRiU5JUglYSE8JWskTiU1JVYlOCUnJS8lSCQzJGwkTyVGGyhC?= =?ISO-2022-JP?B?GyRCJTklSCVhITwlayROJTUlViU4JSclLyVIJDMkbCRPJUYlOSVIGyhC?= =?ISO-2022-JP?B?GyRCJWEhPCVrJE4lNSVWJTglJyUvJUgkMyRsJE8lRiU5JUglYSE8GyhC?= =?ISO-2022-JP?B?GyRCJWskTiU1JVYlOCUnJS8lSBsoQg==?=

で、メールに関するお約束のRFC2822にこんな規定がある。ヘッダーに限定されているわけではないが、メールの1行に並べていい文字数には制限があるようだ。

http://www.puni.net/~mimori/rfc/rfc2822.txtより引用:

行の長さの制限

この標準では1行中の文字数に2つの制限がある。それぞれの行の文字はCRLFを除いて、決して998文字以下でなければならず(MUST)、78文字以下であるべきである(SHOULD)。

そんなわけで、MIMEエンコードされたSubjectがずらっと1行に並んでしまうと、うっかり998文字を超えてしまうおそれがあるわけで、なんとか78文字くらいで改行するのがよろしいということだろう。

ちなみに、上で使ったのと同じ文字列をBecky!2.50.07の件名の欄に突っ込んで、メールを送ってみたら、やっぱり適度に改行されていた。

Subject: =?ISO-2022-JP?B?GyRCJDMkbCRPJUYlOSVIJWEhPCVrJE4lNRsoQg==?=
=?ISO-2022-JP?B?GyRCJVYlOCUnJS8lSCQzJGwkTyVGJTklSBsoQg==?=
=?ISO-2022-JP?B?GyRCJWEhPCVrJE4lNSVWJTglJyUvJUgkMxsoQg==?=
=?ISO-2022-JP?B?GyRCJGwkTyVGJTklSCVhITwlayROJTUlVhsoQg==?=
=?ISO-2022-JP?B?GyRCJTglJyUvJUgkMyRsJE8lRiU5JUglYRsoQg==?=
=?ISO-2022-JP?B?GyRCITwlayROJTUlViU4JSclLyVIJDMkbBsoQg==?=
=?ISO-2022-JP?B?GyRCJE8lRiU5JUglYSE8JWskTiU1JVYlOBsoQg==?=
=?ISO-2022-JP?B?GyRCJSclLyVIGyhC?=

ってことは、phpmailerで処理されたsubjectのスペース区切りで繋がっているところが改行になってれば何の問題もなさそうってことか。

PHPのmb_encode_mimeheaderで生成した文字列を出力してみたら、ちゃんと改行が入っていた(汗)ので、犯人はphpmailerさんですか…と(汗)で、phpmailerに渡されたSubjectがどうなっているのか追いかけてみたら、送信するときにCreateHeader()って関数が呼びされていて、その中でSubjectが以下のように加工されていた。

if($this->Mailer != 'mail') {
$result .= $this->HeaderLine('Subject', $this->EncodeHeader($this->SecureHeader($this->Subject)));
}

で、このSecureHeader()ってメソッドは何をやっているのかというと。。。

/**
* Strips newlines to prevent header injection.
* @access public
* @param string $str String
* @return string
*/
public function SecureHeader($str) {
$str = str_replace("\r", '', $str);
$str = str_replace("\n", '', $str);
return trim($str);
}

あ、改行コードを吹っ飛ばしてるじゃん…(汗)このメソッドを回避してみたら、Becky風にほどよく改行された。

でも、これ、Header Injectionを回避するためのサニタイズをやっているようなメソッドっぽい…、このメソッドを呼び出す限りは、RFC2822の998文字越えをやらかしてしまいそうだし、このメソッドを回避してSubjectを作ると、Header Injectionに直面するリスクを抱えるってことだろうか。

でも、基本的にはシステムが生成したメールを送信するだけなので、悪意思ったSubjectってのはやってこないような気もするが…。ま、ちょっとHeader Injectionについて調べてみよう。

追記:

phpmailerにセットする前に改行コードを外す処理を追加しておけば、phpmailerの中でSecureHeader()を呼び出す必要はないんじゃないかって気がしてきた。とはいえ、phpmailerを直してしまうと、バージョンアップの時にややこしいことになりそうだし…。うーむ。

Doblog、サービス終了

NTTデータのDoblogがやっぱりサービス終了らしい。そりゃ、一切アクセスできない状態で2ヶ月止めてて、サービス再開しても使いたいと思うユーザは少ないだろうなぁと。そんなわけで、サービス終了は、ある程度、予想範囲内だったような気がする。

…とはいえ。

ニュース | NTTデータ公式サイトより

復旧作業の終了を受け、今後のDoblogについて検討した結果、Doblog開設時の目的である、ブログシステムを構築するための技術的知見、およびコミュニティサービスを運用・運営するためのノウハウの蓄積については十分に達成できたものと考え、サービスを終了するという判断をいたしました。

この終了の判断に関する記述の中に、Doblogを使っていたユーザに対する配慮が一切ないのが、SIerらしいなぁという印象を受けた。

ま、「Doblogのサービス終了のお知らせ」を読んでみると、Doblogのユーザから集めたクレームやエンハンスリクエストを元にして拡張したDoblogのアプリケーションを企業内Blogのエンジンとして売るくらいの腹づもりだったんだろうなぁと何となく想像しているけれど、NTTデータ的には、その辺がご破算になっただけなんだろうな。

さて、JavaBlackさんのエントリーの 真・Doblog終了のお知らせ – カレーなる辛口Javaな転職日記より

これはNTTデータとしては最低最悪なスキャンダルで,「NTTデータといえば,小規模なブログサービスも満足に運用できなかった,あの会社だよね?そんな怪しげな会社に任せて本当に大丈夫?」と訪ねられたら,NTTデータの営業は一体なんと答えるつもなんでしょう?

「あれは、Doblogを運用委託していた協力会社がやらかしたんですよ。ある意味、うちも被害者なんですよ。御社向けのシステムにはちゃんと実績のある協力会社を使いますから、ご安心ください」的な弁明をするんではないか、に一票(汗)

さか枝で朝うどん

とりあえず実家に帰ってきたので、朝食を食べに、自転車で10分くらいの「さか枝」に行ってみた。

到着したのが、10時前だったので客はまばらだったけど、一見、サラリーマン風のおじさんとかがうどんをすすりながら新聞を眺めていたのは大丈夫なのか…と一瞬思ったが、香川県に事業所を構える企業や役所では、従業員に自由にうどんを食べに行く休憩時間を与えなくてはならないという県条例があるから仕方ない(…いや、そんな条例ないっす…たぶん汗)。さか枝の周りは、県警とか県庁とかがあって、以前、公務員の中抜けが問題になったりしたけど、香川県職員のうどん抜けとか、ちょっとアレかなぁ…と余計な心配を少々。

いつもの「かけうどん(中)とてんぷら(小えびのかきあげ)」を注文して、代金は270円。相変わらず、劇的な安さだなぁと思いつつ、これでも、私が高松にいた頃と比較すると値上げしたんじゃないかと思う。

f:id:y_fudi:20090424094200j:image

さて、店内を眺めてみると、さりげなくゴールデンウィークの営業予定が貼ってあったので、ゴールデンウィークにさか枝に訪れる予定の県外の皆さんに、さか枝のゴールデンウィークの営業情報を!

f:id:y_fudi:20090424095100j:image

  • 4月29日(水) お休み
  • 4月30日(木) 通常通り
  • 5月1日(金) 通常通り
  • 5月2日(土) 通常通り
  • 5月3日(日) 通常通り
  • 5月4日(月) 通常通り
  • 5月5日(火) お休み
  • 5月6日(水) お休み

*1:…いや、そんな条例ないっす…たぶん汗

結局、SunがOracleに買収された。

結局、Oracleなのか…って、それなりに驚いたけど。

Oracle、Sunを買収 – ITmedia NEWS

てか、Sunを買収して、Oracleはどうなりたいんだろう、とふと思った。あくまでアプリケーション屋さんであるならば、SparcやSolarisなんかは余計な資産だと言える(ハードウェア周辺だけを分割して、どこかに売却とか?)し、IBMやHP辺りとは逆のパターン(ソフトウェア->ハードウェアって方向性で)の垂直統合として、「Oracle、ハードウェアも始めました(笑)」なんてことになるのか。

ま、RDBMSだけを見れば、上位ラインナップとしてのOracleと、その下のMySQLって棲み分け感というか、フルラインナップ感はOracleにとって魅力的なのかもしれない。むしろ、Oracleとしては、オープンソースコミュニティを背景にOracle帝国の繁栄を脅かしかねないMySQLを取り込んで、コントロール下に置くことのメリット感を感じてるんじゃないかと、個人的には思ったりする。InnoDBやBerkleyDBをOracleに買収された時点(Oracleに目を付けられた時点ってことになろうかと)で、ある程度の運命は決まっていたのかもしれず。

しかし、IT業界にあの赤いロゴの入った名刺を持ってうろうろする人が増えるんだろうなぁと思ったり、MySQLってどうなっちゃうんだろうって思うと、なんかちょっと気が滅入ったりしないでもない今日この頃。

3ware 9650SEの先のHDDをsmartdに監視させてみた

とりあえず、9650SEの先は3つドライブが刺さっていて、smartdのヘルスチェックでこけたら、rootにメールを送るように設定してみた。/etc/smartd.confに以下の記述を追加。

/dev/twa0 -H -m root -d 3ware,0
/dev/twa0 -H -m root -d 3ware,1
/dev/twa0 -H -m root -d 3ware,2

…設定しおわって自己満足に浸っていたら、そもそもRAID Arrayは、3wareの3dmが監視していることに気がついて、あんまり意味ないじゃんってことで、orz。

カフェ・ハイチ@大崎ゲートシティのドライカレー

都内某所のデータセンターの帰り、上司と大崎ゲートシティの「カフェ・ハイチ」に寄って、ドライカレーとハイチコーヒーでランチしてきました。

f:id:y_fudi:20090408123900j:image

ドライカレーは、見た目で、辛いかなぁ…と思ったら、そうでもなくて、ちょっと拍子抜け(汗)したけれど、しっかりした旨みがあって、少し固めに炊かれたごはんとの相性が良くて、さくさくと完食。

食後のコーヒーは「ハイチコーヒー」。ハイチコーヒーって、飲んだことがなかったので、少々、びびりながら飲んでみたら、心地よい苦みがあっておいしかったし、砂糖とクリームの他にラム酒の小瓶が付いていて、ラムを数滴を入れたら、ぐんと風味がまろやかになって、スターバックスのシアトル系のコーヒーとかと一風変わった感じで堪能できました。

オーダーするときに、「ドライカレー」と「ペパーポット」っていうハイチ風ハヤシライスとで悩んだので、次回はペパーポットを食べにゲートシティに立ち寄ろうかと(笑)

Cafe HAITI|カフェ・ハイチ

IBM、Sunの買収を断念?

IBMがSunを買収しようとしているということだったが、IBMが価格を引き下げたために、Sunが交渉から降りると言われていた…が、やっぱりSunが買収提案を蹴ったみたいだ。

とはいえ、Sunもこのままではいられないはずなので、「次」を探しに行くはずだろうなぁ。個人的には、DELLの動きが気になるような気がしないでもない。Solarisのような、x86で動くUNIXって、DELLにとっては魅力的だろうし、これまでのDELLが主戦場としていた「x86+LinuxやWindows」の向こう側のハイエンドな世界にもSolaris/SPARCなら食い込めそうだし。

ジャストシステムがキーエンス傘下に

ジャストシステムの経営状況が芳しくないのは知っていたけれど、キーエンスがジャストシステムに出資する意図がよくわからないなぁ…と思ってたら、弊社のとある偉い人(笑)がたまたま通りがかかったので、個人的に意見を聞いてみた。

  • 両者にシナジーがあるような気がしない。
  • キーエンスもジャストシステムも一点突破型(ジャストシステムは日本語関連のソフトウェア、キーエンスはセンサーなどの電子機器に集中しているってことだろう)だから、経営陣が”合う”のではないか。

とのこと。

なるほど、事業的なシナジーが見えない会社間で出資が成立するってことは、経済合理性を超えたところで、経営陣同士(特に創業者?)が深くつながっていたりするんだろうか。

Wikipediaによれば、キーエンスの創業者の滝崎武光さんは、1945年生まれで、ジャストシステムの創業者の浮川和宣さんは1949年生まれ。年齢は近いような印象を受けるが…どういう背景があるんだろう。気になるなぁ。

追記:

キーエンスがジャストシステムを傘下に、45億円出資によると、

キーエンスからはジャストシステムに対して打診があり、協業の可能性を協議してきたのだという。

…とのこと。ふーん、キーエンス側からの打診ってのはちょっと意外だな。

Amazon.co.jpでMobile Edyが使えなかった。

Amazon.co.jpでお買い物をして、MobileEdyで支払うようにして、ケータイでメールを受信したら、iアプリ起動用の文字列がなんとなく壊れてた(これまでもMobileEdyは使っていたんだけど、iアプリが起動できなかったのは初めてだから、なんとなーく送ってくる文字列がおかしいのかな…と)

いつもなら、「お支払いはこちら」ってリンクがあって、それをクリックすればMobileEdyのiアプリが起動してささっと支払い完了となるんだけど、そこにiアプリ起動用の文字列がそのまま表示されてた。

–B:A

TEXT=”お支払いはこちら”

ADF=”http://xxxxxxxxxxx(bitwalletなドメインのURL)”

“P”=”an=xxxxxxxxxxxxxxx(なんかの文字列)”

結局、あがいてもしかたなさそうだったので、「お支払い番号をお届けします」メールに書かれていたURLを開き直して、pay-easyで支払うことにした。

…なんだかなぁ…。

2009/04/30追記:

Edyを運営しているbitwalletのサイトに密かにこんなこと(ドコモ携帯電話でMobileEdy(オンライン決済)をご利用のお客様へ(掲載日:2009年4月8日))がリリースされていた。

電子マネー「楽天Edy(ラクテンエディ)」 | お知らせ

どうやらDoCoMoのケータイで、「『メールヘッダ情報受信設定』を“付加する”」に設定していると、

ドコモのおサイフケータイでMobileEdy(オンライン決済)をご利用頂く際に、「決済開始メール」の“お支払いはこちら”リンクが正常に機能せず、お支払い画面に移動できない(お支払いができない)

とのこと。対策はこれを”付加しない”に設定するしかないとのこと(汗)

*1:これまでもMobileEdyは使っていたんだけど、iアプリが起動できなかったのは初めてだから、なんとなーく送ってくる文字列がおかしいのかな…と

« Older posts Newer posts »