Semantic Web – WordPress

私が最初に取得したインターネットメールのアドレスは、「ぷらら」さんのものでした。常に最先端のセキュリティ対策を目指す大手ISP 「ぷらら」さんの <スパムメール撲滅に向けた取組み> をお知らせします。
  http://www.plala.or.jp/access/living/releases/nr04_dec/0041207_01.html
  http://www.plala.or.jp/access/living/releases/nr04_dec/0041207_02.html
(1) Outbound　Port 25 Blocking [2005/1/31 実施予定]
(2) Rate base spam control
などが2005年１月から導入されます。
また、新規登録に際して、必ず以下の同意が必要となっています (オンライン登録時のユーザー向け表示ページの一部を原文のとおり引用します)。

スパムメールを送信した場合には、スパムメール1通あたり100円をご登録の請求方法に上乗せして、ご請求させて頂きます。
「例」　スパムメールを1万通送信した場合
１００円×１万通＝（請求額）１００万円
また、弊社サービスに影響の生じた場合は上記とは別に「威力業務妨害」等により、刑事告発及び損害賠償請求をさせていただく場合があります。

[追記 2005/1/17]
J.D. パワーアジア・パシフィック社による
2004年日本ブロードバンド・インターネット・プロバイダー顧客満足度調査（PDF）
  http://www.jdpower.co.jp/press/pdf2005/2004JapanISP_J.pdf
もご覧下さい。PDFファイルです。
報道用資料 タイトル
「ISP の顧客満足度、加入後半年未満では @niftyとSo-net、半年以上ではぷららがトップ」

Ping サーバ Technorati http://www.technorati.com/
にメンバ登録し、ブログページを Claim a Weblog すると、サンプルページ
   http://www.osbsd.net/technorati.html
のように、自動検索可能となります。Cosmos Search とよばれているようです。
2004年12月、Technorati さんのサーバ・ページがリニューアルした後、自動登録ツールのバグ?なのか、Cosmos Search Results:の次行のURL(ないし、ブログ・タイトル) に他人のブログページが表示されるようになりました。
Claim a Weblog を繰り返したり、登録を一旦削除しても同じだったので、support宛てメールにてリビルド等を依頼し、解決しました。
Cosmos Search の内容については、すべて正しかったので、ブログページのURLのみ、他人のものが表示されたようです。

セキュアメール　無料キャンペーン(主催: 日本ベリサイン株式会社 協賛: 株式会社ジャストシステム) 期間中のため、spam 対策の１つとしてお知らせいたします。
現在、私は
   · 日本認証サービス株式会社 http://www.jcsinc.co.jp/
   · 日本ベリサイン株式会社 http://www.verisign.co.jp/class1/services.html
発行の個人用電子証明書 (PKI によるデジタル Digital ID)を使用しています。
その用途として、一般的には
   · セキュアメール
   · アクセスコントロール
   · 電子署名
などが可能ですが、主に、セキュアメール (特に、S/MIME メールの電子署名) のために利用しています。
個人メールをセキュアとするだけであれば、ベリサイン社個人用電子証明書は (経験上)取得手続が簡単で、安価と思います。本証明書は、単品「ベリサイン 個人用電子証明書ライセンスシート」として、Just MyShop オンライン購入も可能です(店頭での購入はできません)。
また、セキュアメール　キャンペーン主催者の日本ベリサイン株式会社
    http://www.verisign.co.jp/class1/index.html
にアクセスすると、３ヶ月間無料でトライアル版の体験できます。
株式会社ジャストシステムさん協賛で、「企業内個人様向け」 「2005年2月28日まで」です。
ページ内には [証明書を利用するための環境]：
   · OS＝WindowsXP/ME/98/2000
   · ブラウザ＝Internet Explore5.01(SP2)-6.0
と指定されていますが、主に、メールソフト「Shuriken Pro3 /R.2」
     http://www.justsystem.co.jp/shuriken/product/pro3r2set.html
の動作環境と思います。たとえば、鶴亀メール Ver4.03 [2005年8月9日,「鶴亀メール」から「秀丸メール」となりました]においても本証明書は問題なく利用できますが、Windows XP以上のOSでないと、メールソフト上で証明書の表示はできません（ CryptUIDgViewContext 関数が使えないため、とのことです)

· cron ジョブについて
2005/1/3 現在, Xrea.com さんの サーバ s102, s104 は、cron ジョブが停止しているようです。
自宅サーバ機であれば、サーバ上で cron ジョブ ( 各ユーザが crontab を使う ) などのプロセスがデーモンとしてバックグラウンドで実行されているか ?

コマンド ps
ps aux | grep "ジョブ名"
[PATH]/crontab -l (例 /usr/bin/crontab -l)

などで確認できます。しかし、一般的なレンタルサーバでは、確認用のコマンドを利用できないことが多いので、何らかの理由で サーバが一部のプロセスを停止しているか? 現在サポート様へ問合わせ中です。
[追記 2005/1/12] s106サーバ では、cron ジョブは正常作動しています。広告免除サービス (免除権) をサーバ間で移動した場合であっても、cron ジョブの反映まで数時間かかります。 因みに、ディスク容量表示の反映まで24時間程度かかります。
[追記 2005/1/17] s107サーバ: cron ジョブは正常作動しています。
[追記 2005/1/24] s111サーバ: cron ジョブは正常作動しています。
[追記 2005/2/1] s112サーバ: cron ジョブは正常作動しています。
なお、(s100 以降の) s101, s103, s105 サーバ の cron ジョブは、未確認です。
バイナリーファイルのインストール、データーベースなどの設定前に (特に、Movable Type 管理者の方で、予約投稿を予定されている場合)、ご契約サーバの crontab 作動状態の確認をおすすめいたします。
[追記] crontab (cron ジョブ) のみをローカルネットワーク上の別サーバで作動させることが可能のようです。( s102 サーバについては、ユーザー個別に) 別サーバで設定していただきました。
[追記 2005/2/23] s114サーバ: cron ジョブは正常作動しています。
[追記 2005/3/30] s139サーバ: cron ジョブは正常作動しています。

Xrea.com さんの 110台余りのサーバの中で、２つのサーバ s101, s102 は特別な仕様となっているようです。
     Athlon64 3500+ 1GB RAID1 (Perl5.8.3 / PHP5.0.3 / MySQL4.1.7 / PgSQL 7.4.5 )
   http://sb.xrea.com/showthread.php?&threadid=4443
Movable Type 新規インストールの際、
データベース MySQL 使用時、mt.cfg 設定: 文字コード (PublishCharset) utf-8 は使用できません。
UTF-8 として、mt-load.cgi を実行すると、

テンプレートを設定しています…
データの設定中に以下のエラーが発生しました:
Insertion test failed on SQL error Duplicate entry ’1-’ for key 2

となります。
文字コード (PublishCharset) EUC-JP とする必要があります ( 2005/1/3 確認済み) 。
MySQL4.1 新機能による影響のようです。データベースをみると、
  phpMyAdmin version 2.6.0-pl3 SQL Dump では、sql ファイルは、UTF-8 Unicode (utf8) で作成・エクスポートされます。
  MySQL dump version 10.8 をみると、dump ファイルは、ujis (EUC-JP) で作成・エクスポートされます。
「第48回 MySQL 4.0から4.1へのアップグレード 、トラブってませんか?」
鶴田展之氏 2004/12/21
   http://pcweb.mycom.co.jp/cgi-bin/print?id=25624
などが参考となりそうです。
つまり、s101 サーバでの報告
   http://sb2.xrea.com/showthread.php?p=64430
と同様の設定エラー が s102 サーバにおいても発生しますので、mt.cfg の文字コード (PublishCharset) は 必ず EUC-JP とする必要があります (PublishCharset Shift_JIS は未確認です)。
再構築後、atom.xml のエンコードをみると、"EUC-JP"なので、mt.cfg の文字コード設定が反映しています（当たり前ですが）。
   <?xml version="1.0" encoding="EUC-JP" ?>
これでは、MySQL 4.1系の高機能を利用できるようになっても、
   http://shellscript.biz/archives/000023.html
過去エントリー(2004年09月20日)のとおり、「文字コードEUC-JPでは、エントリーの記述内容次第で、再構築後にRSS、Atomに対応しなくなることがあります。」ので、ブログページの質は低下してしまう。
因みに、MySQL 4.0.23 の s104 サーバなどでは、従来どおり 文字コード utf-8 設定可能です。
[重要! 追記 2005/4/24] s101-s150 すべて4.1系 (MySQL4.1.7) のサーバ と表示変更されています (バージョンアップ完了)。
  http://sb.xrea.com/showthread.php?&threadid=4443
s104, s106, s107, s111, s112, s114, s139 では、MySQL Client API version 4.17, かつ 文字コード utf-8 設定可能となっています。ただし、s103、他サーバについては未確認です。