たいした事を書くつもりが無かったので、読んでみたいと思っていただいた方や検索エンジンから見つけて読んでいただける方だけで良い、とブックマークサービスなどに追加するボタンを付けていませんでした。時代が時代なので遅ればせながら付けてみました。
# と言っても自分自身はソーシャルブックマークサービスを利用していません。
# 問題があったら教えてください。
このブログに貼付けたボタン/リンクは、以下のサイトとURLから生成したかURLの情報を参考に作成しました。
他にこれもというサイトがあれば教えてください。リモートのJavaScriptを読み込まないサービスであれば追加したいと思います。
先日b2evolutionのアップグレードを行った際にロケールファイルの設定に漏れがあり普通に参照すると強制的にISO-8859-1への変換が行われ、????となってしまっていました。
この辺りの仕様はおかしな所もあるので、普通に動作するようパッチを書いて送る事にします。
問題をご連絡頂いた皆さん、ありがとうございました。
追記：
ついでに前から気になっていたURLも修正しました。
http://blog.ohgaki.net/index.php/yohgaki/article
といった感じでしたが
http://blog.ohgaki.net/article
でアクセスできるようにしました。もちろん前のURL形式でアクセスしてもリダイレクトで表示できるようにしています。
追記：
さらにRefererスパム防止機能のため、はてなブックマークからのリンクをクリックするとSPAM防止用ページが表示されていました。この機能を無効にしたので「はてな」からもアクセスが容易になりました。問題を教えてくださった方、ありがとうございます。
The Pirate Bay Breaks 10 Million Users
10 million simultaneous users represents a number never duplicated by any file-sharing entity. The largest P2P networks, such as FastTrack and eDonkey2000, both topped out with approximately 5 million users.
1000万「同時」ユーザだそうです。これはすごい数です。基本的にはキャッシュを効かせてリバースプロキシの効果を最大限に利用して… といった感じなのだとは思います。しかし、検索機能もあり試しに検索しても遅くないです。
もう少し覗いてい見ると日本のコンテンツはあまりないようですが、海外のコンテンツは豊富なようです。また、アダルトコンテンツが公開のページには無いようでそれが人気の理由なのかな、と思います。
確か一度閉鎖されたことがあるサイトだったと思うので調べるとありました。
http://ccr2.blog9.fc2.com/blog-entry-1761.html
今はどんな状態で運用しているのでしょうね?
コンテンツの著作権をもつ方々はこのような状態にどのように対処するか思案が必要でしょう。基本的にはDRM無しで広告収入で儲ける合法的な手法を提供するのが良いと思います。無料コンテンツはビットレートが低い物、ビットレートが高い物は有償で、といった感じが良いのではないかと思います。しかし、ビットレートが高い物を有償化しても、ビットレートの高いデータその物がまた違法に公開されるので意味が無い、となってしまうかも知れません。どう折り合いをつけるか難しいですね。
最近のb2evolutionのフィードバック（コメント）には評価を記録できるようになっているので有効にしてみました。辛口評価コメントも歓迎です。どれが役に立ったのか、立たなかったのか、などはいろいろと参考になります。
「書かない日記」の「書かない」には
の3つの「書かない」の意味があるのですが酷すぎる場合はコメントを入れていただければそのエントリ分の追加は努力します。
と書いて今思い出しました。DNS Rebinding攻撃の書きかけエントリに追記するのを忘れていました…
追記：
試しに入れてみるとフィードバックとして取り扱われるのでモデレートされます。SPAM以外は全部公開しているので安心(?)してください。公開してほしくないコメントの場合、非公開で、と書いておいてください。
少し前のエントリ、宛先を個人のメールアドレスに設定しているメルマガは迷惑メールに！の続きです。DM業者はどのようにメールを送信すべきか考えました。
これから書く考えはDM送信側ではなく、DM受信側の視点から考えています。
まず簡単にメールを分類します。受信者から見ると
に分類できると思います。
受信する側から見るとそれぞれ適切であると思われる送付先アドレス設定は次の通りでしょう。
基本的にプライベートなメール、自分のアクションが必要なメール、必ず目を通しておきたいメールです。ショッピングサイトからのメールでも「受注確認」は確認してもし自分からの注文で無い場合は「キャンセル」というアクションが必要です。この様な場合はToに個人アドレスを設定するのは当然だと思います。
アクションの必要なメールがCC、Bcc、送信元のアドレス宛で送信されてきたら困ります。
基本的にプライベートなメールです。自分に経緯を連絡するCCに個人アドレスが載っているのは当然でしょう。特にアクションは必要ないが目を通すだけは通しておいて、といった場合に使う為に用意されています。
皆さんご存知とは思いますがCCとはカーボンコピーの略です。申込書等で1枚目を書くと2枚目、3枚目に写せる紙がありますが写したコピーが「カーボンコピー」です。CCとは写しを意味します。BCCとはブラインドカーボンコピーの略です。ブラインド、つまり見えないカーボンコピーの事です。メールを送信先(To)やカーボンコピー(CC)で送信したユーザに見えない様に送信するメールアドレスを設定します。
非プライベートなメールです。MLやネットショップのメルマガ、ニュースサイトのメールなどがこの分類のメールになります。これらのメールは個人宛でなく、メルマガや発行者のメールアドレス宛になっている方が受信側にとって便利です。
ネットショップやニュースサイトのメールは「送信者」からするとアクション（広告クリック、商品購入)を取ってほしいメールですが、受信者からみると単なる情報メールです。個人宛に送られてきても何か必ずアクションを取る必要があるメールではありません。
元々スパムなので勝手に何でもするのがスパムメールです。最も効果が高いと期待できる個人宛にメールを送信するのは当然でしょう。まっとうな事業者はスパムメールの真似をする必要はありません。
To, Ccに自分のメールアドレスが設定されているメール全てが個人用のプライベートなメールだと受信者は管理が容易になります。
DMを送信する場合、受信側の立場になってアクションが必要なメールかどうか判断して、個人宛とそれ以外に区別するのが理想的だと思います。しかし、個人的な好みの問題もあるので送信先アドレスを
のどちらかから選べるようにすれば良いと思います。
ネットショップなどの場合でも、受注確認などのメールは個人宛、利用して頂いたお客様に対して広告メールを送信する場合は非個人宛をデフォルトとして送信すると受信者側は非常に便利です。
もし全ての事業者が上記の方法でメールを送信するような状況なれば、個人宛(To, CC)に送信されるメールは必要なメールとスパムメールだけになります。
一昔前はメールの振り分けがよく行われてきましたが、現在では減少傾向にあるのではないかと思っています。GMailの場合、メールは振り分けでなくフィルタで検索するようになっています。フィルタは振り分けと同じような動作をします。しかし、振り分けとフィルタでは大きな違いがあります。フィルタの場合は常に受信したメール全体が検索対象になります。
GMailの様なシステムでは to: yohgaki@ohgaki.net でフィルタを作成すると個人宛のメールが全部表示されます。
個人宛のメールがバルクメール（不特定多数向けに送信されたメール）であふれると不必要なメールに「迷惑メールを報告」ボタンを押して消してしまうユーザが多数いても不思議ではありません。
DM送信先を個人宛にしなければ迷惑メールとして処理されてしまう可能性を少なくできます。
メール利用者には幾つかの段階があると思います。
これ以外に、「捨てアド」を使う、「目的別アドレス」を使う、などの道もあります。
メルマガなどのバルクメールを送信する方にとって、1の段階のユーザにはどのような送信先であっても不利益を得る事はないはずです。2と3の段階のユーザであれば個人宛にメールを送信しないことにより不利益を得る可能性があります。私は現在4の段階ですが、この状態になると個人宛のメルマガ系のメールが非常に鬱陶しいです。実際、一部のメルマガ系のメールは迷惑メールとして処理しています。
不利益となるどうかは各段階のユーザ比率とユーザのサービス利用率で決まると思われます。正直な予想を書くと、送信先を個人宛から発行者アドレス等に変更するとDM送信者がメールから得られる利益は減少すると思います。
普通の企業はスパマーではありません。企業の姿勢としてメール受信者（お客様）の立場に立ってメールを送信するようにしてほしいです。たとえ広告収入が主体のメールであっても、広告をクリックしてくれるユーザを単なるメール受信者として扱うのではなく、お客様として扱ってほしいです。
普通の企業が受信者の立場でメールを送っていたなら「捨てアド」などが一般化する事もなかったかも知れません。しかし、現状は残念ながら大手であっても限りなくスパムメールに近い方法、と言われても仕方ない方法でメールを送信しているケースは少なくありません。
特に大手企業には「儲かりさえすれば良い」等と考えず、お客様の利便性(と安全性)を第一に考えたWebサイトやメールの使い方をして見本を示してほしいです。
短期的に多少の不利益があっても、誰もが認めるお客様本意のサービスを行う事は長期的に企業の利益となるのではないでしょうか。
システム構成にもよりますが、どちらの機能もそれほど正しく実装すれば大掛かりな仕組みは必要ありません。リクエストが本人からかハッシュでシグニチャを確認すれば良いだけです。データベースを利用する方法やクッキーを利用する方法も考えられます。もし実装したい方でどういうことか分からない場合はコメントください。
追記：
いろいろ異論がある事は分かっていながら書きましたが、ぼんやりと考えていた事は正確には伝わっていないと思います。このエントリの続きとして責任あるDM送信者はどのようにメールを送信すべきかを書きました。こちらの方が分かりやすいと思います。要はスパマーでないDM送信側は受信側にもっと配慮すべきだと考えています。その方が両方にとって利益になると考えています。
—
「迷惑メールを報告」ボタンを押させるな！
http://japan.internet.com/wmnews/20080116/7.html
によると以下が読者によって迷惑メールとして処理されてしまう代表的な原因としています。
1. 配信頻度が読者の忍耐を超えている頻度になっている
2. 内容に魅力を感じなくなり飽きている
3. 内容がミスマッチを起こしている
4. 第一印象のメルマガレイアウトが読む気をなくしている
5. 求めていないセールスプロモーションのメールである
6. 価値を感じないセールスメルマガである
7. 登録時に期待していた内容のメルマガではなかった
個人的にはTo(宛先)が自分のメールアドレスになっているメーリングリスト・メルマガが最も迷惑です。
7,8年前はメーリングリストであれば宛先にはメールリストのアドレスが記載されているのが当たり前でした。確か4,5年前くらいから宛先を個人アドレスに設定したメールリストが急増し、現在は当たり前になってしまいました。メールクライアントを使い始めたばかりのユーザでも「自分宛」、「自分にCC」、「それ以外」くらいは自動振り分けしているので、「自分宛」として送信した方が読まれる確率が高くなるのは当たり前です。
メルマガの内容など、読んでも読まなくてもよいDMと同じです。それを送り手側の勝手な意図で「個人宛」として送るのは非常に迷惑です。親展でもないのに親展とDMに書いて送っているような物です。
親展（しんてん）（英:confidential letter; private）とは、封書などにおいて、宛名となっている本人が自分で封を切って読んでほしいという意味またはそのような扱いのことである。
http://ja.wikipedia.org/wiki/%E8%A6%AA%E5%B1%95
郵便のDMもかなりの数が送られてきますが、さすがに親展でもないのに親展と書いてるDMはほとんど記憶にありません。読んだ側に「何これ?タダのDMじゃないか！」と不快に思われ逆効果だと考えているからではないでしょうか?
メーリングリスト/メルマガが個人のメールアドレス宛に送信されるのは非常に迷惑だ常々感じていました。今まで自分宛の不必要なメルマガはメールクライアントで迷惑メールとして処理させてきました。
状況を少しでも改善するために、今後Google,Yahoo,Hotmailなどの個人アドレスにメルマガを送信してきた場合は全て迷惑メールとして報告する事にします。
今や小手先のメルマガ編集方法だけでは読者の心を捕まえることができない。基本に戻ると「何が大切か」が見えてくる。
個人宛に送信するのは「小手先」テクニックの典型例だと思います。「迷惑メールを報告」ボタンを押させるな！のリストに載っていないのが残念です。
にFreeBSD7上でのPostgreSQLとMySQLのベンチマークが載っています。
PostgreSQL 8.2.4 – 11ページ
ピーク性能でおよそ5400transactions/secほど。
MySQL 5.0.45 – 15ページ
ピーク性能でおよそ3800transactions/secほど。
Kernelの主要な部分すべてがパラレルに動作するようになったため、かなり高速（数値にして数倍）になったようです。
グラフからもPostgreSQLの方がかなり良い性能であることが分かりますが、PDFファイル（16ページ）によると
On this benchmark PostgreSQL is 35% – 45% faster thanMySQL at all loads
とPostgreSQLの方が全般的に良い性能だったそうです。PostgreSQL 8.3は確実に8.2よりもさらに良い性能を期待できると思います。MySQLも5.1や6.0を利用した方が良い性能が期待できるのかも知れません。
このPDFのベンチマークはデータベースの性能を計る為のベンチマークではなく、OSの性能を計る為のベンチマークです。データベースサーバ設定、SQL文やテーブル構成などが不明なのでデータベースの性能のベンチマークとしては参考値くらいでしかありません。MySQLのテストではMyISAMを使っていると思われますが、MyISAMならこれくらいの性能差は普通です。
年末ということで来年の予測を一つ。2008年急速に普及すると思われる物は64bit版OSだと思います。
メモリが急速に安くなってきており8GB程度のメモリが搭載できるPCであれば安価に購入できます。32bit版Windows/Linuxでは多くのメモリを搭載しても3.1GBから3.6GB程度のメモリしか利用できません。メモリを多く積んだPCを使い切るには64bit版のOSが必須になります。
普通にPCを利用するなら2GB程度のメモリがあれば困る事はほとんど無いはずです。多くのメモリを何に使うかというと仮想環境です。仮想環境などを利用する場合にはメモリを多く搭載していた方が圧倒的に有利です。仮想環境を快適に使うには最低でも3GBのメモリがあった方が良いと思います。複数の仮想環境を実行するなら8GBのメモリでも十分使い切る事ができます。
64bit版Windowsの場合、デバイスドライバの問題があるので急速に多数を占めるような事は無いと考えられますが、現在のように「誰が使っているの？」と思えるほどの少数派では無くなると思います。仮想環境のホストOSは64bit版、ゲストOSは32bit版などと使い分ける方が増えるだろうと考えています。
64bit版Linuxの場合、新たにOSを購入する必要もないので64bit版への移行はあまり敷居が高くありません。FlashPlayerさえ用意されれば移行するユーザが多くなると思います。64bit版のFlashPlayerが無い場合でもVMWare Playerで実行できる32bit版のイメージがそのままダウンロードできるディストリビューションも少なくありません。(OS丸ごとダウンロードするする場合はくれぐれも信頼できるソースのイメージをダウンロードするように注意してください）数年前であれば64bit環境への移行はあまりお勧めできる選択肢ではありませんでしたが今は十分お勧めできる状況です。Linuxユーザの場合、64bit環境への移行は簡単と言えます。
# PAEをサポートしたカーネルなら4GB以上のメモリも利用できます。
# MomongaLinuxの場合、別カーネルとして提供されていますが、
# ディストリビューションによっては自分でビルドしなければ
# ならないと思います。
Mac OSXには64bit版はありません。OSXは元々64bit OSで32bitのアプリケーションもシームレスに実行できます。OSXユーザは64bit環境に移行する必要はありません。あまり意識される事がなかったMac OSXの優れた部分ですが2008年は注目される利点として改めて紹介される事になるかも知れません。
最後にこれを機に64bit版Vistaにアップグレード方が戸惑わない為のTipsを一つ書きます。（32bit版でも同じです）VistaにはUAC（User Access Control)が追加されているので注意が必要です。 「UACを有効にしているとマトモにつかえない」と感想を持たれている方も少なくないかも知れません。これはUACによる「管理者権限で実行オプションを表示するダイアログで実行」した場合と、「本当の管理者アカウントで実行」した場合の結果が異なる事が大きな原因の一ではないかと思います。
例えば、UACで「管理者権限で実行」してもhostsファイル等の変更はそのユーザがログインしている間だけの変更され、再度ログインすればhostsファイルは元通りに復元されます。これはウィルス等がhostsファイルを改ざんし定義ファイルの更新を防ぐ事を防止する為の措置です。UACが有効な場合、WindowsディレクトリのみでなくProgram Filesディレクトリやレジストリも保護されます。UNIX系OSのユーザは管理者ユーザと別に通常ユーザを作成して通常ユーザの方を常用するアカウントとして利用すると思います。通常ユーザではセキュリティ上の理由から予想しづらい保護機能が働いて『何故？？』となってしまう事が予想されます。Vistaで管理者が行うべき作業を実行する場合は「本当の管理者アカウント」でログインして実行するようにします。
ついでにもう一つ。ドメインに参加しているPCの場合、ドメインの管理者アカウントでないと保護機能が働きます。ドメインに参加している場合、必ずドメイン管理者としてログインしてから作業しましょう。
# これらのセキュリティ機能は非常に有用だと思いますが
# Vista不人気の原因でもあるので将来無効化されそうで
# 心配です。
最後にメモリ増設で8GB積もうと考えている方は以下のURLを参考にしてください。
http://pc.watch.impress.co.jp/docs/2007/1127/hot517.htm
eMediaWireに掲載されていたレポートによると「Internetに接続されているPCの3台に1台はLimeWireをインストールしている」としています。
File-sharing application LimeWire is now found on more than one-third of all PCs worldwide, according to research jointly published by Digital Music News and BigChampagne. The companies surveyed more than 1.5 million systems for this report.
http://www.emediawire.com/releases/2007/12/emw576418.htm
米国だけの話かと思ったのですが
one-third of all PCs worldwide
LimeWire was found on 36.4% of all PCs, a figure gleaned from a global canvass of roughly 1.66 million desktops.
と世界中の166万台のPCが対象だそうです。少なくとも日本国内のPCでLimeWireがインストールされているPCは非常に少ないと思います。
米国で1/3ならまだしも、世界中で1/3のPCにLimeWireがインストールされている、とするのは少々大げさな気がします。母集団にかなりの偏りがあるのではないかと思います。母集団の偏りは別にしても166万台のうちの60万台ほどのPCにLimeWireがインストールされていたのが事実だとすると驚きです。
米国ではP2P問題は基本的に著作権問題としてして取り扱われ、音楽ファイル等を公開していた個人に対して数千万円の損害賠償請求を認める判決もでています。アメリカの議会ではP2Pネットワークによるファイル共有が国防上の問題として取り上げられていたりします。
一方日本では暴露ウィルスによるファイル流出だけが大きな問題とされ、本質的な問題の議論や理解が進んでいないように感じます。
プログラムのセキュリティ対策と同じで情報を発信する側と受け取る側、両方に効果的な対策が必要だと思います。現在受け取る側の規制としてファイルをダウンロード行為自体を違法とするか議論がされていますが、それよりもまず違法なコンテンツを発信する側に高額な損害賠償金を請求可能にするなどの措置が先に行われるべきだと思います。
参考：
http://arstechnica.com/news.ars/post/20071227-one-third-of-pcs-prefer-limewire.html
http://ja.wikipedia.org/wiki/LimeWire
さすがに1/3と言うのは大げさ過ぎると思い昨年末に書いたこのエントリはお蔵入していました。別の統計を見つけたので公開しました。
http://internet.watch.impress.co.jp/cda/news/2008/01/23/18207.html
これによると
これに対してGnutella互換サーバントは世界的に多く分布しており、中でも米国が約175万ノードで49％を占める。ヨーロッパ各国も約23％と多かった。日本でも約10万9,000ノードあった。
となっています。米国でもたった175万ノードなら「1/3のPCにLimeWireがインストールされている」のは大げさな数値になります。母集団に問題、例えば大学生のPCだけ調べた等、であれば納得できるかも知れない数値ではありますが…
追記
最大のP2PネットワークはThePrivateBayだそうです。
一応IE6/IE7でこのブログを自分で見た事があるのですがオーバーフローが発生した場合のページを見ていませんでした。b2evolutionに付属してきたevopressテンプレートのスタイルシートをそのまま使用しているのですがIE6でIE6/Firefox/Opera等と同等に表示するためにblockquoteのCSS定義に
width: 400px;
overflow: hidden;
追加しました。IE6の方は一つ前のエントリなどは非常に読みづらかったと思います…
# 今使っているのは2.2.0Beta版なので多少の不具合は仕方ないです。
時間があれば自分でスタイルシートを確認したいところですが当分その時間がとれそうにないです。問題があったらぜひ教えてください。下のContactリンクからWebフォームから送信できます。
前のエントリで改竄は大きなセキュリティ上の問題ではない旨説明がされている、と紹介しましたが新リリースのアナウンス部分に新しい情報が追加されていました。
http://www.squirrelmail.org/index.php
Due to the package compromise of 1.4.11, and 1.4.12, we are forced to release 1.4.13 to ensure no confusions. While initial review didn’t uncover a need for concern, several proof of concepts show that the package alterations introduce a high risk security issue, allowing remote inclusion of files. These changes would allow a remote user the ability to execute exploit code on a victim machine, without any user interaction on the victim’s server. This could grant the attacker the ability to deploy further code on the victim’s server.
リモートファイルインクルードが可能になっていたらしいです。1.4.11は9月末にリリースされたパッケージなのでかなりの期間、危険なパッケージが公開されていた可能性があります。
利用されている方はバージョンアップしておいた方がよいと思います。また影響範囲が分からないので新しいバージョンがリリースされた場合に直ぐにアップデートできるよう準備する方がよいでしょう。
SquirrelMailのサイトでは前のニュースで影響が少ないとしていた部分は、追記として危険な問題がある事を明記しておかないと勘違いするユーザも少なからず発生するような気がします…
言いたいことのほとんどが書いてある素晴らしいブログ記事です。
ドコモもauもいいかげんにメールアドレス設定の仕様を直せ。
http://neta.ywcafe.net/000799.html
ドコモもauもいいかげんにメールアドレス設定の仕様を直せ。の続きと補足
http://neta.ywcafe.net/000803.html
AuはMNPを機会にDoCoMoの独自仕様メールアドレスと同じにしたと記憶しています。いい加減にしてほしい、と強く感じたのでよく覚えています。KDDIに至ってはDion等でも他のメールサーバやクライアントで受信できないメールアドレスを作成できるようにしているようです。まさに嘘を隠すためにまた嘘をついている状態です… しばらくすれば事態は良くなると思っていたのですが悪くなっているようです…
ルールを守りたくないなら中国のように独自TLDでも作って（そういった計画があったと聞いていますがその後どうなったかは不明）その中でやれば良いでしょう。ユニバーサルに使えない自爆メールアドレスを作ってしまうのはエンドユーザの問題ではなく、サービス提供者の姿勢の問題だと思います。
いくら技術が分からない人間でも「他のキャリアの電話をかけようとした時に電話できなかったら困りますよね?同じよう他のメールサーバ宛にメール送信しようとしたときにメールが送信ができなかったら困りますよね?」といった単純な議論も通用し無いのでしょうか? すでに作ってしまったメールアドレスを強制的に変えるのは難しくても、新しいアドレスは標準に則ったアドレスのみ許可するのは簡単です…
RFCが絶対か、というとRFC通りに作ると動かなくなるものもあるのでそこは適当に対処しなければならない場合もあります。しかし、わざわざ動かなくなる（メールの送受信に問題発生する可能性がある）メールアドレスを作れるようにするのは責任ある企業として適当な対応とは言えないと思います。
ブログアプリを更新したのでダッシュボート機能が使えるようになりました。
最近のコメント、未公開のブログ、最近編集したブログが参照できるようになりました。かなり公開し忘れていたブログがありました。
いくつは削除して、いくつかは記録の為に公開状態にしました。2,3年前のブログも含まれているので多少場違い（時期違い）な感じがするかと思います。
一つ困った事は以前のブログではタイトルをクリックすると参考にしたURLへリンクされていたのですが、現在は各ブログのページが表示されます。近いうちにテンプレートを修正したいと思います。
ちょっと試してみたらb2evlution 2.1.0 betaでも結構まともに動作するようなので1.10.3から2.1.0 betaにしてみました。
B2Evolution
http://b2evolution.net/
前の設定ファイル
conf/_basic_conf.php
をコピーして、ロケールファイル
conf/_locales.php
にutf-8を設定し、インストール用スクリプトを実行しただけです。
# この環境は全ての文字エンコーディングをUTF-8に統一しています。
スキンの互換性は無いので作り直す必要があります。
あまりテストしていないので問題があるかも知れません。問題があったら教えてください。
追記：
メール送信には以前にあった問題があったのですが、仮想サーバ単位で設定していたmbstring.languageとmbstring.func_overload設定を削除するとUTF-8形式で正しくメール送信できるようになりました。これは前の環境でも同じ設定を行うとメール送信に問題がなくなるのかも知れません。
RSSのURLが変わったような気がします。Atom, RSS1でRSSで購読されている方はURLを変更してください。
リンクが正しく表示されない状態をかなり長く放置していたのですがバージョンアップで直ったようです。日本語テキスト中のWikiへのリンクなども正しく表示できるようです。
ちなみにこの環境は
です。
前のバージョンのb2evolutionはあまりお勧めできるものでは無かったですが、2.1.0は日本語環境でもかなりそのまま使えるような感じです。
Canon iP7500をMomongaLinuxから利用するには
http://www.canon-sales.co.jp/drv-upd/bj/bjlinux260.html
に掲載されているフィルタをインストールしてCUPSのプリンタ設定ページからドライバを選択すれば利用できるようになります。
バイナリrpmを入れても良いのですが、以前にうまく動作しなかった事があるのでSRPMからインストールすることにします。
このcnijfilter-commonはlibxml（obsoleteなパッケージです）が必要なので、どこかから適当なSRPMを拾ってきます。rpmbuildコマンドでビルドするとlibtoolでエラーが発生するので/usr/sbin/libtoolで上書きします。書き換えていれば問題無くビルドできました。
次にcnijfilterのビルドですが、まずcups-devel, gtk+1-develをインストールしておきます。他にも必要な開発用パッケージがあるかもしれません。必要な物はインストールします。
%installセクションの
install -c -s -m 755 ${PR_ID}/database/* ${RPM_BUILD_ROOT}%{_libdir}/bjlib
の-sオプションを削除します。ライブラリでもないファイルに-s(stripオプション)が付いているのでエラーになります。後はrpmbuildでビルドして出来上がったrpmを全部インストールします。
CUPSは再起動しないと新しいドライバを読み込まないので再起動します。その後、プリンタメーカでCanonを選択するとcnijfilterがサポートするプリンタ（Canon PIXUS iP4200 / PIXUS iP6600D / PIXUS iP7500 / PIXUS MP500)が一覧に表示されるようになります。
サポートディストリビューションはSUSE Linux 10.0、Turbolinux FUJIとなっていますが同じ手順でFedoraなどにもインストールできると思います。ここにRedHat系のOSが載っていないのはサポート負荷軽減の為?と勘ぐりたくなります。Libxml2を使うように書き換えればもっと簡単に多くのディストリビューションで使えるようになると思います。
Canonのページを見るとUSBからの接続しかできないような記述になっていますがネットワークプリンタとして接続できればLPDでもIPPでも印刷できます。
MomongaLinux3以来のインストールでしたが以前よりインストールが簡単になっていました。以前はインストール済みのライブラリ（確かlibpngとか）を強制的に別バージョンに見せてインストールしたと思うのですが今回はそのような荒技を使わなくても普通にインストール出来ました。
Mac OSXにはiP7500用のドライバがあるのですがこのドライバはMacのUSBポートに直接iP7500が刺さっていないと動作しない代物です。OSXもCUPSを使っています。CUPSのフィルタならOSXでも使えるはずなので余裕があるときにインストールしてみたいと思います。
追記：
とりあえずビルドした物を公開しました。よろしければどうぞ。
http://wiki.ohgaki.net/index.php?Momonga%20Linux%2FCanon%20Printer