CPA-LABテクニカル

おかげさまで、先日、高機能日本語メールライブラリQdmailは、0.9.0aになりました。それなりに使えるようになっていると思います。

次回のメジャーバージョンアップでは、現在、qd_send_mail() としても使用できるよう、鋭意作業中です。

しかし、そのためには、若干、パラメータの指定方法を変えなければならない事態になりそうで、迷っています。Dynamic Drawの品格でも述べたように、ユーザーインタフェイスは、なるべく変えないほうがいいのはわかっているのですが。。。。
こういう設計は、もっと入念にやっておくべきでした。

iPhoneは個人的には魅力はないけれども、Qdmailとしては対応しておきたい。
2年縛りの端末を契約する気になれないのだけど、誰かiPhone貸してくれないかな～。

iPhoneメールについては下記サイトの方々が大変詳しく調べているのだけれど、やっぱり実機がないとわからない部分もあり、どうしましょうかね～。

【iPhone 3Gまとめ】メールはiPhone１台で複数アドレスを利用可能！-め～んずスタジオ － me-n's STUDIOさんによると、@i.softbank.jpでは、デコメの一部については受信可能とのこと。


iPhoneのメール全般については、こちらが詳しい。
iPhoneについて知っておくべきこと【メール編】-MOBILE POWER feat. iPhone

知る人ぞ知る有名ソフトDynamic Draw

Dynamic Draw Professional

図を書くときにいつも使わせてもらっています。
とにかく操作が直感的なので、たいへん便利。
「recursiveの正しい理解CakePHP」の図も、Dynamic Drawを使わせていただいています。

こちらの作者さんは、利用者の事を真剣に考えており、とても頭が下がります。
「直感で使える」というつくりにするのは、かなり大変だと思います。こうしたヒューマンインターフェイスが、ソフト設計では重要ですね。
これだけ便利なフリーソフトを提供していれば、様々な質問も来るかと思うのですが、それにとても丁寧に対応しています。
真に技術力のある方は、品格もあるということでしょう。

Qdmailシリーズも、メソッドを呼び出す時の引数の型や、並び順などにかなり気をつけているつもりなのですが、今から思えば、「しまった、別の指定方法の方がよかった」と思う部分もけっこうあります。しかし、一度リリースすると、インターフェイス部分は修正するのは、かえってユーザーを混乱させることになるため、なかなかできないんですね～。
ソフト内部は

結果が速く正しくでれば、構造、アルゴリズムや内部的なインターフェイスはどうでもいい。

ということなんでしょうけれども、
対人間部分は

体系的で理解しやすく、『変わらないこと』

が重要だと思うのですね。だから、ソフトの設計では、中身よりも、対人間部分を事前に検討することが大事なのでしょうね。
プロの方にとっては当たり前なのでしょうけれども、私のような者がソフトを作ると、どうしても作者オリエンティッドな、ユーザーを考えないインタフェイスを作りがちなんですよね。

こちらが処理しやすい入力をユーザー負担で求めてしまうのです。

なんせ、

人間にとって使いやすい入力　→　コンピューターにとって扱いやすいパラメータ

というヒューマンインターフェイス部分は、プログラマにとって相当の負担だろうな、と思います。

Qdmailは、そのコードの約半分を構造的には本筋ではない、ユーザーからの入力対処＆パラメータ分析に使っています。

ユーザーがプログラマでない一般ユーザーの場合は、プロトタイプをなるべく早くリリースしてユーザーからのフィードバックを得るというのは、大事なのでしょうね。
Qdmailは、対プログラマ相手なので、一般ユーザーほどシビアではないと思うのですが、それでもやはりライブラリとして統一感のあるインタフェイスを提供できているかというと、ちょっと反省点があります。


私が品格なぞ語ってはいかんのですが。
タイトルは「ホッテントリメーカー」でいただきました。

関連リンク
ファンクラブ
使い方事例
窓の杜レビュー

新参者のスポックです。
はじめて知りましたホッテントリメーカー。すごくおもしろいです。。。
ホッテントリメーカー

このタイトルは、ホッテントリメーカーでいただきました。。。。

qdmailでやってみたら、、、、

• 文系のためのqdmail入門　46 users（推定）
• 本当にヤバいqdmailの脆弱性3つ　5 users（推定）
• qdmailにありがちな事
• qdmail信者が絶対に言おうとしない３つのこと　10 users（推定）
• リア充がひた隠しにしているqdmail　15 users（推定）
• 全てを貫く「qdmail」という恐怖　

hal456でやってみたら、、、

• モンスターペアレントからの視点で読み解くhal456　532 users（推定）
• これは凄い! hal456を便利にする33のツール　9 users（推定）
• hal456で年収が10倍アップ

おもしろすぎます。
Cake PHPで制作したそうで。。。。

メールの受信(POP)サーバーの操作ライブラリ＆マルチバイトメールデコーダーのご紹介。

簡単受信サーバー操作ライブラリQdmailReceiver
hal456トップページ

応用すれば、こんなことができます

• 空メール処理
• ブログへのメール投稿
• Spamフィルター
• gmailライクなWEBメール

もちろん、QdmailReceiverは、メールを解析したり、ＰＯＰサーバーを操作するライブラリなので、上記のことをやろうと思えば、他に自分でプログラムを組まなくてはなりません。
しかし、マルチバイト（日本語処理）やメールの解析処理は意外にやっかいなので、それをQdmailReceiverに任せていただければ、かなり労力半減することでしょう。

■CakePHP(1.2RC2)のemailコンポーネント評価

CakePHP 1.2 RC2 がリリースされたので、新しいemailコンポーネントを評価してみた。全般的に言えば、改行コード＆英文周りはかなり改善されており、英語メールを送る分には、大丈夫かと思う。
しかし、一部でマルチバイト非対応となっており、日本語の場合、若干の問題点がある。

1. Content-Transfer-Encoding:ヘッダーは7bit固定＆charsetはutf-8なので、charsetをiso-2022-jpに変更し、本文、ビュー、レイアウトのすべてを自前でiso-2022-jpに変換する必要がある。*1
2. ワードラップ処理がマルチバイト非対応
   __wrapメソッドがマルチバイト非対応なので、文字化けする可能性が大きい。また、「日本語文字列のバイト数取得にstrlenだけではダメな理由-PHP」でも述べたとおり、マルチバイト環境では、文字列のバイト数を得るのに、strlenだけを使うのは、問題がある。
   
3. MIMEエンコードが、マルチバイト文字の途中で強制改行される可能性のあるスクリプトとなっており、長いsubject＆Gmailやbeckeyでタイトルが文字化けする可能性が大きい。*2
4. qmail用がデフォルト？
   mail関数で送る際には、MTAがqmailであればLF,qmail以外のsendmailやPostFixであれば、CRLFである必要があるが、LFがデフォルトとなっている。
   これはこれで賢いやり方で、CRLFをデフォルトにするとqmailの時にエラーがでるけれど、ＬＦがデフォルトであれば、sendmailやPostFixがエラーを出すことはないだろうからだ。
   
5. SMTP送信の場合、　名前＜address@example.com＞　の形式が使えず、＜address@example.com＞　というメールアドレスのみのヘッダーとなる。
   う～ん。どうしてこうしたのでしょうかね。
   

その他の制約

• 本文base64エンコードできない。
• Quoted-Printable非対応
• デコメ送信不可能*3
• MHTL(インラインHTML)メール不可
• 添付ファイルの日本語不可

全般的な感想

相当がんばれば、デフォルトでも日本語は送れないことはないと思うけど、メールひとつ送るのに、がんばりたくないでしょ。

う～ん。mb_send_mail単体のほうがましかな。

Qdmailなら。。。。

高機能マルチバイトメールライブラリQdmailなら、CakePHPのコンポーネントとしても動作します。
上記のemailコンポーネントの弱点はすべて克服されておりますので、一度お試し下さい。

■mb_encode_mimeheader都市伝説

mb_encode_mimeheaderは、なんか使いにくい。文字化けする。とあまり良い評判を聞きません。私も、「使うのはちょっと怖いな」と思っていました。しかし、mb_encode_mimeheaderは正しく設定すれば、きちんと働いてくれます。それを検証したいと思います。

間違ったバッドノウハウ

mb_encode_mimeheaderの有名なバッドノウハウに
PHPmb_encode_mimeheaderは事前にmb_internal_encodingが必要-akiyan.com
というのがあります。その中身は

PHPのmb_encode_mimeheader関数で文字列をエンコードするときは、直前にmb_internal_encoding関数で変換したい文字列のエンコーディングをセットしてから呼ばないとうまく動作しないもよう。エンコードした文字列の後ろのほうが化け化けになってしまう。

というものです。
そして、

// 元のエンコーディングを保存
$orgEncoding = mb_internal_encoding();
// 変換したい文字列のエンコーディングをセット
mb_internal_encoding($targetEncoding); 
// エンコーディング実行
$encodedString  = mb_encode_mimeheader($targetString, $targetEncoding, 'B', "\n");
// 保存しておいたエンコーディングに戻す
mb_internal_encoding($orgEncoding); 

というコードが掲載されています。
それを検証しようとした、
mb_internal_encoding()は必須か?」に対しての疑問と検証-よくきたblog
というのもあります。

しかしながら、このバッドノウハウは間違っており、検証した方も、残念ながら、検証になっていません。

正しいバッドノウハウ

そこでPHP5.2.4のソースコードを読みつつ、動作検証をしてみました。
その結果、mb_encode_mimeheaderを使う時の正しいバッドノウハウは、

mb_encode_mimeheaderに渡す文字列の文字コードとmb_internal_encodingは一致させておかなければならない。

というものです。
必ずしも、最終のターゲットエンコーディングとmb_internal_encodingを一致させる必要はありません。
ん、最初のノウハウと何が違うのかって？
次章でよ～く考えてみましょう。

結論から

文字コードが３つでてきますので、整理しましょう。

1. mb_internal_encodingの文字コード
2. mb_encode_mimeheaderに渡す文字列の文字コード
3. mime変換する最終文字コード

この中で、１と２が一致している必要があるだけであって、３は独立していてＯＫです。
２→３の文字コード変換は、mb_encode_mimeheaderがきちんとやってくれます。

正しくいえば、mb_encode_mimeheaderは「２の文字コードは１と同じであるとして、１→３のパラメータでもって、２の文字列を変換」します。つまり、　

mb_convert_encoding($word,$target_encoding,mb_internal_encoding());

という動作が、mb_encode_mimeheaderには含まれています。
（特殊な条件の時のみ、無変換となる）

間違っているバッドノウハウは、１と３を一致させようというもので、２についての言及がありません。偶然に２についても同じ文字コードであれば文字化けすることはないのですが、２が（１,３）と違うコードの場合、正しくエンコードされません。

1=2となるように、文字コードを設定しましょう。

（さらに、mb_languageもjaに設定しておけば間違いがありません。）

本来は、mb_encode_mimeheader関数にて　2の「渡す文字列の文字コード」を指定できるような仕組みがあればいいのですが、残念ながらそうなっていません。
１のmb_internal_encodingを指定することで、2の「渡す文字列の文字コード」を間接的に指定することになります。

注

この結論は、下記テストコードと、PHP5.2.4本体のmb関係のソースを読んでのことですが、C言語のソースは私も理解できない部分もあり、結論が間違っている可能性もあるかも知れません。その際はご指摘いただければ幸いです。

■テストコード

続きを読む

■長文でテストしてみる。

続きを読む

■PHPの本体コードを読んでみる。

続きを読む

■WEB上の間違った情報（主なもの）

以下は、googleで、mb_encode_mimeheader のキーワードで検索した時に、比較的上位に出てくるページや、他に多く引用されているページにつき、私の見解を書いています。決して、けなしているわけではありません。ただ、私の得た結論が正しいとするならば、間違った情報をそのままにしておくと、また私のような無駄な時間を費やしてしまう人がでてくるであろう、という予測のもとに、「この情報は私が正しいと思う結論に対して、間違っている」ということを指摘するものです。
PHPのバージョン違いによるものもあるかも知れません。私が検証したのはPHP5.2.4ですので、それより前のPHPでは挙動が違うのかも知れません。（一応、PHP4.4.7でもテストコードを動かしてみて、結論は変わらないという心証はえているのですが、4.4.7についてはPHPソースまでは読んでいません。）
またPHP5.2.4であっても私の見解が間違っている可能性もあります。その際は、ご指摘いただければ幸いです。

• PHPのmb_encode_mimeheaderは事前にmb_internal_encodingが必要-akiyan.com

この記事の冒頭で紹介したページです。1=3という間違った結論です。多くのWEBサイトがこのページを引用しています。この記事のバージョン5.1.2ではこうだったのでしょうか？

• mb_internal_encoding()は必須か?」に対しての疑問と検証-よくきたブログ

私と同様の疑問を持ち、akiyan.comさんの記事を検証しています。しかし、環境が、internal='euc-jp',input='utf-8',target='utf-8'では文字化け、internal='utf-8',input='utf-8',target='utf-8'で文字化けなし、ということを検証しているのみで、十分ではありません。

• phpでmb_encode_mimeheader()を使う際の注意点-ケイケンラボ

1=2=3と設定しないと文字化けする、という間違った情報です。丁寧に「mb_encode_mimeheader() ですが、文字コードの変換まではしてくれない為」と書かれていますが、これも間違いです。上のほうに書いたように、むしろ原則として、文字コードの変換をします。

• Re: mb_encode_mimeheader() default encoding-Tep-j-develop

非常に有益なテストコードです。この記事の次の記事の方が

しかも、これらの結果が異なるんですね。
mb_encode_mimeheader($str, 'ISO-2022-JP');
mb_encode_mimeheader(mb_convert_encoding($str,'JIS','EUC'),'ISO-2022-JP');

と述べていらっしゃいますが、mb_internal_encoding('EUC-JP');なので、スクリプトをEUC-JPで保存していれば、上段は1=2となり正常稼働しますが、下段は1≠2なので当然文字化けします。もし、このスクリプトをUTF-8で保存して実行すれば、上段も文字化けするでしょう。
また、同じスレッドで、

mb_encode_mimeheader 自体は、文字コードの変換はしてくれないと思っていたんですが。

という発言もありますが、このように思っている人は多いのではないでしょうか。
繰り返しになりますが、原則として文字コードの変換がなされます。

• mb_encode_mimeheader()の使い方-ぱんぴーまっしぐら

こちらは逆に、「mb_encode_mimeheader()に渡す文字列はISO-2022-JPに変換するな。」という結論を導いていらっしゃいますが、間違いです。最初のスクリプトが、１≠２になっているだけであり、2=iso-2022-jpとしているからではありません。しかも、次のスクリプトでは、1=2=iso-2022-jp と設定し、結果も正しいのに、「mb_encode_mimeheader()に渡す文字列はISO-2022-JPに変換するな。」というのは、論理的に正しくありません。mb_encode_mimeheader()に渡す文字列はISO-2022-JPに変換しても、１＝２を守る限り大丈夫です。

正しい考察

PHPのmb_encode_mimeheaderは事前に-ryuzi_kambe の？Ｄ
こちらは、私と同じ結論です。そちらにも書いてある通り、mb_encode_mimeheaderに”from-encoding”を指定するパラメータがないのが、混乱のもとになっていると思います。

混乱する考察

mb_encode_mimeheaderについては、そのソースコードのエンコードを書いていないスクリプトの場合、情報が不足するため混乱の元となります。mb_encode_mimeheaderに言及する多くのWEBサイトでは、ソースコードの文字コードに触れおらず、暗黙のうちにEUC-JPやShift_Jisが前提だったりします。
おまけに、inputされる文字列の文字コードさえも記載のないページもあります。
そのようなページはあまりに多いので、ここでの引用は省略します。

開発者さま

ぜひ、このようなバッドノウハウをなくすために、mb_encode_mimeheaderにて、引数に渡す文字列のエンコードであるfrom-encodingを指定できるようにお願いいたします*2。
たったこれだけで、この大混乱を収束することができます。。。


しかしながら、マルチバイト関係のPHP本体のソースをみると、すごく複雑です。c言語で、マルチバイトを自在に処理するのは至難の業ですね。mb_convet_encodingをおっかけると、あの組み合わせの多さに、それだけで萎えてしまいます。それに果敢に挑戦された開発者の方はすごいです。mb*関係に係わった関係者の方々に感謝と尊敬の意を表します。

■覚書

続きを読む

php.ini が

mbstring.language = Japanese

であり、かつ、mbstring.internal_encodingが未設定の場合、PHPは、mbstring.internal_encodingが、文字コードEUC-JPであるとみなして動作する。*1
ちなみに、languageの設定さえない場合は、ISO-8859-1のようだ。

時代は、UTF-8だと思いますので、UTF-8でソースコードを書く時には、

mbstring.internal_encoding　= UTF-8

を忘れずに。

可搬性を重視した場合

他の環境でも動作させることを考えれば、これらの項目は、php.iniで設定するのでなく、自分のスクリプトの初期設定で行うほうがよい。だって、レンタルサーバーであれば、languageの設定がjapaneseと保証されているわけでもないし、文字コードもphp.iniでどう設定されているかは、千差万別（のはず）だからだ。
よって、日本語のコードであれば、必ず初期設定スクリプトで、

mb_language( 'ja' );
mb_internal_encoding( 'UTF-8' );

を設定しましょう。

なぜ今？

何を当たり前のことをお思いでしょうけど、mbstring.internal_encodingを未設定、またはEUC-JPのままで、UTF-8でコードを書くと思わぬ誤動作が生まれる可能性がある、ということで。。。。次回に続く。

■さらば、mail,mb_send_mail関数

続きを読む

Qdmailは原則としてPHP標準のmail関数を使用している*1。
このPHPのmail関数は何かとクセがあり*2、特に改行コードでは苦労させられた。
マニュアル(mail)を熟読すれば、載っていることばかりだけど、今後のために整理しておく。

改行コード

インターネットメールの世界では、改行コードは原則として、CRLFである。それは、RFC2822を参照されたい。SMTPサーバーに直接渡す時は、これでＯＫ。
しかし、PHPのmail関数には時と場合により、LFで渡さなければならない時がある。
特に、ヘッダーと本文の改行コードは分けて考える必要があるので、注意すること。

mail関数の改行コード注意点

• 本文の改行コードはLFで渡すこと*3。
• ヘッダーの改行コードは、原則としてCRLFだが、MTA（送信サーバー）によっては、LFで渡さなければならない場合がある。現在、LFで渡さなくてはならないMTAは、qmailであることが判明しているが、他もあるかも知れない。qdmailとqmailをごちゃごちゃにしないよう留意を。

混乱しがちな点

本文はLF。
subject以外のヘッダーはCRLFで渡さなくてはならないのが、面倒なところ。

たぶんlinux,unix系のサーバーは、OS標準の改行コードがLFであることから、このようにしているように思うけど、それならヘッダーもLFで渡すようにすればいいのに。。。。

こちら（PHPのmail()のできの悪さ-よくきたblog）でもご指摘ありますが、ちょっと、その実装は。。。。

Windows版の制限

to引数

Windows版のmail関数は、第1引数のtoでは、

name<address@example.com>

が使えず、

address@example.com

しか許されない。
私の環境では、sendmaneというsendmailのラッパーを使わせていただいてるので、この制限はないけれど。

ピリオドだけの行

PHP が SMTP サーバと直接通信をする際、ピリオドから 始まる行は無視されます

FromとReturn-Path

Windows では、From ヘッダを設定すると Return-Path も設定されます。

送信サーバーがqmailかどうかの判別

Qdmail0.8.6aでは、ini_get('sendmail_path');でもってPHP.iniのsendmail_pathを読み取り、そこに、qmailという文字列があるかどうかで判別している。
これだと誤判別もあり得るので、他にもっといい判別方法があったら、ぜひ教えて下さい。

参考にさせていただいたサイト

qmail の RFC 違反
PHPのmail()のできの悪さ-よくきたblog

簡単にテキストメールを送りたいだけなのに。。。という要望をかなえるためのPHPメール関数。
簡単軽量PHP日本語テキストメール関数-QdSimpleMail
制約の多いmb_send_mailの代替関数を目指しました。
Qdmailは、いろいろ機能を欲張りすぎたので、3000行を超えるソースコードになってしまいましたが、QdSimpleMailは、たったの200行強。

なんとなく動作が不安定なPHPのmb_encode_mimeheaderを使わずに、自作のMIMEエンコーディング関数で動作しています。

特徴

続きを読む

Qdmail開発覚書。インターネットメールで日本語を使用する場合、iso-2022-jp(JIS)と呼ばれる文字セットを使用することが一般的である。しかし、日本語メールの処理をしようとして、iso-2022-jpで文字列処理を行うと、エスケープシーケンスのせいで、ものすごい非効率、場合によってはエラーが発生する可能性がある。ちなみにutf-8,euc-jp,shif-jisは原則としてエスケープシーケンスを使用しないので大丈夫である。

どんな不具合？どんな非効率？

'あい' ＝＝ 'あ' . 'い'　が　false になる時

続きを読む

Qdmailシリーズのライセンスを、CakePHPと同じMIT Licese に変更しました。
多くの人に使ってもらったほうがいいということで。

高機能日本語メールライブラリQdmail(CakePHP対応)
簡単SMTP送信Qdsmtp
高機能メールデコーダー、POPクライアントQdmailReceiver


なんせ
SendMail in Windows Server-らふぁろぐ -技術メモ変-
という方もいるので。ライセンスの問題で使ってもらえないなんて悲しいですからね。

メール受信をきっかけにCakePHPコントローラーを起動する　では、その名の通り、コントローラーをメール受信で起動させた。
ここでは、CakePHP1.2で導入されたシェル機能(shell)を利用し、CakePHPのシェルをメール受信をきっかけに起動させてみる。

順番としては次のようになる。

続きを読む

とある、逆引き～PHPをWEBで発売している会社さんから、改訂版のお知らせが届いた。
ら、衝撃の事実がっ！

続きを読む

■デコメはどうやって、画像を特定するのか

通常のhtmlメールで例えばgif画像を指定するには、次のようにする。

<img src="http://example.com/hoge/images/filename.gif">

このファイル名でどの画像ファイルを表示するか、一意に特定される。

では、デコメはどう指定するか。

続きを読む

あるメールを受け取って、自動的に差出人に対してメールを返す、という動作の代表例として空メールがあるかと思います。
Qdmail,QdmailReceiverを利用すれば、たった10行で空メールを実現することができます。

続きを読む

■QdmailReceiverについて

PHPで、日本語での空メールや多機能転送メールを簡単に実現したり、POPメールボックス操作でWEBメールを実現できたりします。主にメールのMIMEデコード機能、POP操作機能から成り立っています。その他、様々な用途が考えられるでしょう。
Pear::Mail,Pear:MIMEなどで同様の機能は実現できますが、メールの仕組みを理解していないと難しいです。Qdmailシリーズは、「初心者には簡単に、上級者には詳細に」のポリシーのもと、簡単使用方法と、詳細使用方法の両方を使うことができます。
簡単にメールのデコードができるので、例えば、取得したメールをヘッダーと本文まるごとデータベースに保存しても、すぐに内容を取り出すことができます。
gmailのようなWEBサービスも比較的簡単に実現できるでしょう。

というものです。

詳しくはこちらをどうぞ。
マルチバイトメール解析-QdmailReceiver POP付

日本語（マルチバイト）の処理において、その文字数ではなく、バイト数を取得したい場合があります。
マルチバイトは必ずしも1文字2バイトとは限らず、EUC-JPでは概ね2バイトだけど特殊文字で3バイトの場合があり、UTF-8では概ね3文字バイトで表されるけれども、そうでない場合もある。
マルチバイト文字はエスケープシーケンス等様々な理由で、日本語の文字数×nでは答えがでないのです。
もっと単純な話でいえば、シングルバイト文字とマルチバイト文字が混ざった文字列のバイト数は、もちろん文字数×nでは求めることができません。

■まず現状での最善策をご紹介

続きを読む

■CakePHPシェル機能を使用せずに、空メールを実現する-さくらインターネット編

CakePHPにはシェル機能というものがあり、コマンドラインからCakePHPを利用できる。
この機能を利用して、CakePHPをメール受信をきっかけにリアルタイム処理することもできる。
例えばこちらの記事はそう。Writing Some Code-メール受信からのシェル機能実行
しかし、学習の量は少なければ少ないほど効率がいい。
あることを実現するのに、別の事柄を学ぶよりも、これまでの延長線上で可能な方がいい。
(ただし、WEBブラウザから直接叩かれることも想定されるのでご注意を 参考：CakePHPシェルの使い方)
というわけでここでは、CakePHPのシェル機能は使わずに、普通のControllerを、メール受信をきっかけに起動することをやってみたい。
1.2betaで動作確認をしていますが、1.1でも動作するはずです。
これはさくらインターネットで試していますが、".mailfilter"の部分さえ、ご自分の環境に合わせて設定できれば、後は同じです。さくらインターネットと同じ環境ではない人は、こちらの阿部辰也のブログ――人生はひまつぶし。-メール受信時に perl スクリプトを起動して自動処理させる方法が参考になるでしょう*1。

続きを読む

空メールや転送メールなどで、メールの受信をきっかけにPHPプログラムを実行させたいときがあるかと思います。
メールサーバーによって設定が異なるので、ここでは、さくらインターネット(sakura internet)での設定を覚書。

続きを読む