スモールビジネスのIT日誌

• (2011-11-09 06:50:28)

メール送信数の制限果

引越の動機は、メール送信数の制限。スパム対策と思われる。よいことだ。

プロバイダーさんがこのような制限をかけてくれればやりたい放題のスパム業者に何らかのプレッシャや制限を与える。大きな効果はないにしても模倣犯程度の動機の人々にはある程度の抑止効果がある。

不便な運用は負担

とはいえ、当社のビジネスがこの制限で業務に影響を受ける。

オーバーしたら時間をおいてやり直す？時間をおく間に他の仕事をし出すともう忘れる。不便である。

プロバイダー引っ越し

メール送信数の制限があるプロバイダーがほとんどだが、案外、明文化していないプロバイダーさんもたくさんある。

すべてすぐに動き出す予定だった

フォルダーごと軽くコピーしてDNSの向きを変えると「すべてすぐに動き出す」予定だった。

また、引越のタイミングで、コンテンツのアップグレードも実施した。大きな変更は、今まで平分のみのhtmlをphpコードが含まれるコンテンツにした。

そして、はまった。

行っても戻ってデッドロック

(1)ブログシステムが動作しなくなった。原因は不明。phpのバージョン違いか？自分で解決できず戻すことに

(2)元に戻し、かつ新しいコンテンツをオーバーライトすると今度は文字化け発生。php5.2をphph5.3にアップグレードすると文字化けは解消するものの、今後はブログシステムエラーとなる。

他にもオリジナルコンテントに含まれるフルパス問題もあって、体力と時間を消耗した。

一言で言えば、「行っても戻ってデッドロック状態」に陥った。

結果的解決策：Mailサーバを新規に、文字化けはmbstring設定

試行錯誤の結果、

(1)Mailサーバを新規プロバイダーへ切り離し、コンテントはそのまま残した。

(2)phph5.3をphp5.2に戻し(ブログ用)、php.iniでmbstring設定を変更して、とりあえず直る。

mbstring設定

文字化けは、どうせ、いつものように日本語のマルチバイト関連設定が原因なので、mbstring設定で「変化があるかも？」くらいの予想はできる。

しかし、いかんせん、原理もメカニズムもわからない。何が何だかわからないのが日本語の文字コード問題。それが専門の人は仕方ないが、我々は近寄らない方が安全。

原理は不明だが、試行錯誤の結果、mbstring.internal_encoding の変更で現状動作している。

mbstring.language

mbstring.internal_encoding ->utf-8

mbstring.encoding_translation

mbstring.func_overload

mbstring.http_input

mbstring.http_output