私としては、こんな苦労はしなくても、SMTPポートを直接開いて送信してしまったほうが後腐れなくて、すっきりして、爽快なんですが・・・ポートを開くとなると、IDやPWをどこかに保存しておかなければいけません。(もしかしたら自動取得できるのかもしれませんが、どうせ面倒でしょうし、そうなるとどっちが良い方法かわからなくなってきます。)ユーザーさんにも設定してもらわなければいけませんし、極力ファイルに保存しておきたくありません。ステップメールやメールマガジンのように大量配信する場合は、PHPのmail関数は不適切ですから、SMTPポートを開きます。一度に送信するのが1通や2通の場合は、ユーザーさんの設定を軽くしたいな、と思います。Qdmailに組み込まれているソースを使いやすいようにアレンジして、試してみました。動いているっぽいです。確かに、qmailのときはステータス111を返し、sendmailでは1を返してきます。ソースにある100はどんなときに返ってくるんだろう?まぁ今の状態より、より正確な自動判定ができると思うので、導入しようと思います。今の手動で設定する方法も残しておくつもりです。世の中思わぬ動きをするサーバーがあるかもしれません。自動判定できない場合に備えて手動も残しておいたほうが安心です。今機能があるんですから。知る人ぞ知る、qmailのバグに振り回されてます。いえ、振り回されているのは私ではなく、ツールのユーザーさんと言うべきかもしれません。Eメールには、メール送信形式に事実上の世界標準というのがあります。ネットビジネス便利ツールでは、この形式でメールを送信しています。これも当たり前ですが。ところが、qmailにはせっかく世界標準形式で送信しても、わざわざその形式を崩して送信する、という厄介なバグがあります。メーラーの作者は、qmailのバグを吸収するように作ってくださっています。qmailがおかしな形式のメールを送信しても、受信側のメーラがなんとかしてくれているのです。一部のメーラーでは吸収しれくれないので、qmail+吸収しないメーラーの組み合わせになったとき、メールがきちんと表示されない現象に見舞われてしまいます。これはメーラー側が悪いわけではなく、そもそも標準形式に従っていない方が悪いのです。ネットビジネス便利ツールでも、qmailを使っている場合無理やりバグを打ち消すという機能を付けています。使っているMTAがqmailの場合、オンにしてもらうとバグを打ち消してくれます。本当は自動で判別できればよいのですが、以前調iniファイルを調べる以外方法が見つかりませんでしたiniファイルだけでは100%判定できないのです。本来は他者の作ったバグは、対応する責任も義務もありません。qmailのバグに関して言えば、ベストはqmailの修正、次はパッチを当てるのがいいでしょうか。そんなことを言っていては世の中回らないこのもままあるので、対応しているわけです。ユーザーさんも困られるのは分かってますし。メーラーの作者も同様でしょう。これに関して文句を言われる筋合いは全くないわけです。こちらでできる最大限をやっているのですから。システム関係に明るくない人はなかなか理解しがたく、こちらに文句を言いたくなるのだとは思いますが・・・この件に関して、ほぼ同時に二人のユーザーさんから連絡がありました。一人の方はすぐに理解されたようですが、もう一方が・・・まぁ私も困っておられるだろうと慌ててメールを返信したため、もう一方のメールの内容を見落としてしまったのも悪いのですが(書き方が引用に見えてしまい、スルーしてしまいました。)、まるで理解できていない(しようとしていない)様子です。やれやれ、困った人です。この方以前にも、自分が良く理解できていないことが原因なのに、ワーワー言って来られて、迷惑をかけられたことがあります。前任者との引継ぎがうまくできていないないことが原因だったのです。引継ぎしてくださいな。あちらの会社内部の問題に付き合わされたのに、最後にお礼の一言すらありませんでした。自分が客だから、こちらが何でもすべきとでも思っているのかしら。いう教育している会社なんでしょう???qmailのバグを打ち消す機能をお教えしたのですが、確認の方法がないとか、自分のお客さんに魅惑がかかっているとか言ってきました。迷惑をかけているのでしょう。迷惑をかけているのは私ではなく、その方のほうです。qmailのバグですから、qmailが迷惑をかけているのでしょうけど、そんなことを言い始めるとバグのあるMTAをインストールしユーザーに使わせているサーバー会社、もっと言えばそのサーバーを選んだその方の責任もあるわけですよ。言って、こちらも迷惑かけられてます。ありますが、まぁ自分で調べてくださいな。いう人には、協力しようという気がおきないですよね。私の責任の範囲でしたら、もちろん嫌でも協力しますが、他者のこしらえたバグですしねぇ。今回のことを受け、マニュアルをもう少し注意を促す書き方に変更しました。こちらにできるのはそれくらいです。qmailを使わない方法もありますが、設定を少しでも簡単にしたいツールに関しては、この方法は見送ってました。導入したほうがいいかなぁ。導入しても注意事項を読まない人は、どんな状況でも読みません。いう人が、後で困ったことになり、周りに毒を撒き散らすんだよなぁ・・・いつも思うのですが、自分の責任の範囲を超えてでもこの人には協力しよう!と思える人、淡々と必要なことのみを連絡する人、必要最低限の話もしたくなく早く縁を切りたい人がいますね。実社会だけでなく、メールだけのお付き合いでも全く同じです。私もいい意味で気持ちよく人を巻き込めるようになりたいものです。同時に言ってこられたお二方、よく見るとまず間違いなく同じ会社の方です。同じドメイン、同じ会社名です。隣の席の方が別々に言ってこられたとも考えられます。引継ぎがちゃんとできないのに、外部にワーワー言って迷惑をかけ、お礼も言わないような会社です。ありうる・・・しかも、少し落ち着いてから調べてみたのですが、どうしても購入履歴が確認できないんです。別人が購入したと考えたいのですが、嫌な考えも浮かんできてしまいます。今回のことがだけが原因ではないのですが、ネットビジネス便利ツールでは、前々から考えていたライセンスを、順次導入していきます。正規のユーザーさんとこちらの権利の両方を守るためです。購入履歴が確認できないお問い合わせに関しては、対応もしません。今後は徹底していきます。コメントTop↑PHPコーディングクッキーが有効かどうか2012年04月01日Webページにアクセスしてきたブラウザで、クッキーが受け入れられたかどうかチェックできないか調べてみました。PHPより、JavaScriptの方が適切なのかもしれませんが、色々な端末・ブラウザが出てきているので、できればサーバー側で行いたいです。クッキーをセットするのは、【setcookie】関数ですが、この関数の戻り値では、クッキーが受け入れられたかどうかは分かりません。調べるには、クッキーをセット、いずれかのページへ遷移、セットしたクッキーがあるかどうかチェックするしかないようです。クッキーセット後、ページを遷移しなくても確かめられれば楽なんですが。自分自身のURLに【?mode=check】を付加して遷移(他のクエリがある場合、後ろに付加)、$_GET[’mode’]が存在していれば、クッキーの値をチェック、キー:DUMMY=値:OKなら、クッキーを削除し、trueを返す、クッキーがセットされていないければ、falseを返す。今回の開発はMySQLでやているのですが、どうもDBへの入出力で文字化けが起こります。今まで、サイトはEUC-JPでコーディングしていたのですが、MySQLはUTF-8ですし、UTF-8だからMySQLで動かしたいので、なんとかUTF-8の文字化けを解消したいです。調べると、解決方法が見つかりました。$objMySQLConID);これでOKなようです。