Semantic Web – WordPress

[追記 2008-01-20]
Coreserver.jpさんのサーバでは、共有SSLを利用したとき、ローカルIPアドレスは不定です。また、ドットファイル htaccess によるディレクティブ設定「SSLRequireSSL」も機能しないようです（HTTPSプロトコルでの接続も不可となります）。独自IPを購入取得し、独自ドメインをSSLサーバで運用すると、ディレクティブ設定「SSLRequireSSL」は有効となります。(・・・ここまで)

一般的には、
　<Limit GET POST>
　require valid-user

　　SSLRequireSSL
　　Satisfy all

　</Limit>

などの記述でよいのですが、
Xrea.comさんのサーバでは、SSLサーバのホスト名は ss1.xrea.com (グローバルIP 219.163.200.121) です。一般ユーザが SSL対応のブログページを公開するとき、契約サーバへのアクセスは、必ずSSLサーバからローカルIP経由となります。
サーバ間のローカルIP は、通常 192.168.1.* で、一部のサーバー(s86-s90など)では、IP 219.101.229.* も利用されています。
http://sb.xrea.com/showthread.php?t=8531&highlight=192.168.1

よって、独自ドメインのSSL接続 URL https:⁄⁄ のみ許可するときは、ディレクトリ内に下記(3行だけ)の htaccess アクセス制限ファイルをアップロードして下さい。
注: .htaccess は、ファイル名 (例) _htaccess などで作成し、独自ドメインのトップディレクトリ(index.html, index.rdf, index.xml, atom.xmlなどのあるフォルダ)内へFTPアップロード後に正しくリネームします。

Order deny,allow
Deny from all
Allow from 192.168.1 219.101.229

グローバルIPすべて拒否されますので、非SSL接続  http:⁄⁄ ではアクセスできません。
正しく設定した後もアクセスエラーとなるとき、ブラウザのキャッシュを一旦クリアしてからご確認下さい。

なお、下記のページも参照して下さい。
    AdminCGIPath: TypeKeyトークンを利用するコメント許可、SSL有効法
SSL接続によるURL(例)は下記 CGIPath のようになります。

    AdminCGIPath http：//me.s**.xrea.com/mt/
    CGIPath https://ss1.xrea.com/www.example.com/mt/

    ファイル mt-*.cgiのみ GET (POST) によるアクセスを許可する方法

 SSL暗号通信による Movable Type について
トラックバック, Ping は https プロトコルをサポートしていませんので、エラーとなります。

最新ファイル　Jan 29, 2004
出典元 ftp://rs.internic.net/domain/named.root

オンラインの検索エンジンロボットシミュレーター
http://robot-simulator.seo-tool.jp/
を利用し、自作ブログページをチェックしてみた。
ダイナミック・パブリッシング (ダイナミックなページ), 拡張子 php (aspなどを含む) であれば、検索ロボットは苦手である言われているが、テストを行ったブログは、直ぐに「丸見え」となった。
確かに、ロボットは、画像が不得手のようである。
最も苦手とするCGIやFlashによる動的生成についての検証は行っていないが、flash-optimization-techniques, SEO対応型CGIスクリプトなどを扱う商業サイトも登場している。
利用したシュミレータは http:⁄⁄ だけを対象とするもののようで, https:⁄⁄ (SSLサーバ) のサイトのロボット検索は不明である。
ビジネスのためのサイトでは、当然クライアントのアクセスを増やすために、Search Engine Optimization (検索エンジン最適化、サーチエンジン最適化と訳されている. SEO) の工夫が必要であり、ブログは (TrackBack, ブログサーバを利用すると、さらにロボット検索されやすいので) SEOのために優れたツールである。しかし、ダイアリー・日記のためのページまで等しくロボットの自動巡回 (最適化とは言わなくても) の対象となる必要があるのだろうか？ コメント・TB のスパムだけでなく、便乗したスパムメール、ジャンクメールが増えると、世界中のネットワークに負荷をかけるだけではないだろうか？ SEO とともに、
Search Engine Anti-Optimization, Google’s anti-optimization filter, Google’s Over-Optimization Penalty (OOP) などの非最適化の方法もさらに高性能化、普及してほしい。

Shuriken Pro3 /R.2 によるメール送信に際して、「標準のニックネーム」なし、または、英数文字のニックネーム での使用を推奨します。「鶴亀メール」側にバグがある [2005年8月9日,「鶴亀メール」から「秀丸メール」となりました]ようですので、 鶴亀メールにて受信するとき、送信者のニックネームが日本語であり、X-Mailer: JsvMail 5.* (Shuriken Pro3) であれば、電子署名の検証の一部でエラー表示となります。
Shuriken Pro3 /R.2　[ベリサイン セキュリティメールセット]購入使用中ですが、
Shuriken Pro3 アップデートモジュール 更新ファイル(2004.11.18更新) spr3up09.exe
http://www3.justsystem.co.jp/download/shuriken/up/win/030418.html?m=jui16b01
を実行しアップデートしても、MUA 鶴亀メール Version 3.71へのテスト送信では (電子署名)、
==
電子署名は正しく検証されました。
署名者： *** ****
署名者メールアドレス： ***@***.***.**.**
発行者： *** Service CA
(タイプA) ○ 証明書のメールアドレスとメールの送り主は一致しています。
(タイプB) × !!!!メールの送り主と証明書のメールアドレスが一致しません。
　 メールの送り主: =?ISO-2022-JP?B**********JTobKEI=?=
○ 証明書は有効期限内です。
○ 証明書パス(certificate chain)に問題はありません。
==
と表示されます。「標準のニックネーム」 の無、有(英数文字) は(タイプA)、有(日本語)は (タイプB) となります。
Fromメールヘッダーの例
(例) タイプA From: nickname<no-mail@example.xx.com>
(例) タイプB From: 日本語ニックネーム<no-mail@example.xx.com>
Shuriken Pro3/R.2バージョン 5.5.6.0 の[アカウントの設定]⇒[送信]⇒[標準のニックネーム]を入力すると、送信メールヘッダー情報の From: に組み込まれるようです。「ニックネーム」はメールヘッダー情報のOrganization: などを利用し、From: と区別にして送信すれば、解決するはずです。
【株式会社ジャストシステム様からのご回答の一部 2004/11/26追記】

おそらく、鶴亀メール側において、署名と差出人(From)のメールアドレスを比較する際、Fromヘッダの解析が正しく行われていないために発生していると考えられます。

RFC-2822 の規定によると、Fromヘッダには、To/Cc/Bccなどと同様の書式が使えます。ニックネーム（RFC-2822では、display-name ）に日本語が使えない、という制限はなく、Shuriken側が生成するFromアドレス表記に問題はございません。

認証　送信元　　　　送信先
○　　鶴亀メール　鶴亀メール
○　　Shuriken　　Shuriken
○　　鶴亀メール　Shuriken
△　　Shuriken　　鶴亀メール
バージョン 5.5.6.0(2004.11.18更新)
【仕様変更項目】
==
S/MIMEでの署名検証時に電子証明書内に記述されているメールアドレスとメールのFrom欄のメールアドレスが異なる場合に、自動で警告表示するようにいたしました。
==
との事。MUA Shuriken で受信すると、すべて警告は出ないであろうが、他のMUAでは「なりすまし」とみなされる可能性が残っています。
[追記 204/12/17]
鶴亀メール Version 4.00 となったが、
× !!!!メールの送り主と証明書のメールアドレスが一致しません。
については、不変ではあるが、他の表示内容がより具体的、かつ詳細となった。

○ このメールは改ざんされてません。
・・・・・
・・・・・
証明書パス:
・・・
　　・・・・

電子証明書が表示され、(一部エラーがあっても) 改竄がないと判れば、送信元が疑われなくて済みそうである。

mt.cgiなどを含むMovable Type [MT] ベーシックディレクトリへのアクセス制限(コントロール)ファイル .htaccess ３タイプ (例)
－ブラウザでの閲覧、投稿、TrackBackなどに不具合の発生しない制限範囲について
# (タイプ 1) ユーザー (ウェブログ著者) が独自ドメイン内に [mt]ディレクトリを設置したとき
# 通常のインストール方法
<Files *.cfg>
      <Limit GET POST>
      Order deny,allow
      Deny from all
    </Limit>
   </Files>
# (タイプ 2-a) 独自ドメイン内・外に[mt]ディレクトリを設置したとき
# :ユーザー (ウェブログ著者) 専用[mt]ディレクトリ(独自ドメイン外)
<Files *.*>
      <Limit GET POST>
      Order deny,allow
      Deny from all
      Allow from 【ウェブログ著者の固定IPアドレス】
    </Limit>
   </Files>
# (タイプ 2-b) 独自ドメイン内・外に[mt]ディレクトリを設置したとき
# :一般利用者 (クライアント) の専用[mt]ディレクトリ (独自ドメイン内)
<Files *.*>
      <Limit GET POST>
      Order deny,allow
      Deny from all
    </Limit>
   </Files>
<Files mt-*.cgi>
      <Limit GET POST>
      Order allow,deny
      Allow from all
    </Limit>
   </Files>
==
[解説]
# タイプ 2-a, タイプ 2-b は Xrea.com さんのサーバなど独自ドメインをサブディレクトリに設定できるサーバ環境が必要です。
単一のDB をダブルインストールしたMTで操作するために、【AdminCGIPath】を利用します。詳しくは、
   http://shellscript.biz/archives/000016.html
をご覧下さい。
# ファイル mt-*.cgi の中で、mt-load.cgi, mt-check.cgi, mt-upgrade*.cgiはインストール時のみ必要です (セキュリティ上、インストール完了後これらのファイルは削除します) 。
# mt-tb.cgiなどのTrackBack脆弱性の問題は、
「アプリケーション・レベルのコールバック機能」によるフラグイン
http://as-is.net/blog/archives/000902.html
の他、
http://blog.bulknews.net/mt/archives/001165.html
http://as-is.net/blog/archives/000897.html
をご覧下さい。
# 用語「ユーザー、ウェブログ著者」は、Movable Type 3.1 などの「ライセンス」に関する日本語ページから引用しました。
http://www.movabletype.jp/get_movable_type_personal.shtml