WordPress はユーザ数が多いだけに、必要なものはたいていプラグインとして用意されている非常に使いやすいCMSだと思いますが、毎回動的にしかページを作れないという点にはちょっと不満を持っていました。

nginx や Vernish などのプロキシサーバを別に立ててキャッシュさせる方法を試そうと思っていたのですが、はまりポイントが多いらしく躊躇していました。そんな時に Really Static というプラグインを見つけたときから、今回の話は始まります。

Really Static プラグインの問題点

Really Static プラグインは、ブログの記事の HTML を PHP の curl 関数でダウンロードして static フォルダの中に置いておき、それ以降は PHP で動的に HTML を作るのではなく、静的な HTML ファイルを返す、といった事をしてくれるプラグインです。ちょうど、Ruby on Rails のページキャッシュみたいなイメージですね。

インストールも設定も難しくなく、HTML のダウンロードも WP-cron で少しずつ行われるため、完全に WordPress 内に閉じた環境で実現できるすぐれたプラグインだと思いますが、（私にとっては）ひとつだけ大きな欠点がありました。

それは、Really Static プラグインがサイトの構造(URL)を変えてしまうことでした。
例えば、http://blog.bluegold.me/sample という URL の記事に対して、Really Static の導入後にアクセスすると http://blog.bluegold.me/static/sample.html に 301 redirect されてしまいます。
さらには他のページに書かれたリンクも静的ファイルの URL を直接さすように変更されてしまうので、一度導入してしまうと、後で使うのをやめるときに元に戻すのが難しくなってしまうのではないかと思いました。

最初は Really Static プラグインに手を入れて、リンクの URL を変更させないようにしようと思ったんですが、コードを読むと仕組みは意外と単純だったので、Wordpress に統合することを考えなければ、nginx の try_files だけで、似たようなことが出来ることに気がつきました。

nginx の機能を使う

nginx の try_files はリクエストを処理する際に実際のファイルを探す順番を記述する nginx に固有の設定項目で、Apache では mod_rewrite の複雑なルールを駆使して実現できるようなことをシンプルなルールで記述できるようにしたものです。

現在のこのブログの nginx.conf には以下のような記述がされています。

location {
  gzip_static on;
#  try_files /system/maintenance.html /static/$uri/index.html $uri /index.php?q=$uri&$args;
  try_files /system/maintenance.html /static/$uri/index.html$args $uri /index.php?q=$uri&$args;
}

具体的な設定は WordPress のパーマリンクの設定で変わります。
$uri にはリクエストされた URL のパスの部分が入っています。リクエストを処理する際は以下を順番に調べていって、最初に見つかったものを返します。

※ 2011/01/30 追記
静的HTML化した投稿を表す /static/$url/index.html には $args も付けておかないと、プレビューが出来ませんでしたので修正しました。

• メンテナンス画面(/system/maintenance.html)
• 今回追加した静的HTMLのキャッシュ
• css や画像などの静的ファイル
• それ以外は WordPress に処理を渡す

この設定だけで静的なHTMLファイルの配信は出来るようになります。

静的HTMLの作成

あとはブログの各記事を HTML としてダウンロードするだけです。

$ wget -r --follow-tags=a http://blog.bluegold.me

（あくまでも例なので、自分のサイト意外にはやらないでくださいね。）

静的HTMLに変換しておくことで、このくらい速くなりました。(それぞれ３回試行)

実はこのブログは WPtouch プラグインも使っているので、このままでは iPhone 用の画面が表示されません。
この対処法はまた次回。

URLの切替には自作のプラグインを使っています。記事にした当時は stylesheet_uri と template_directory_uri の置き換えをするだけのものでしたが、今は WP_PLUGIN_URL も置換えて、プラグインが追加するスタイルや画像も CloudFront から配信しています。

ここまではわりと簡単に実装できていたのですが、メディアライブラリ(uploads ディレクトリ)に置いた画像ファイルは記事の中身を書き換える必要があるため、なかなか手を出せずに1年くらい放置していましたが、最近、WordPress Amazon S3 Plugin というものがあるのを知り、さっそく試してみました。

このプラグインのセットアップは簡単で、plugins ディレクトリに置いて有効化したあとで、Amazon S3 の認証情報と画像を置くバケツ名を指定するだけです。

設定が完了した後はしばらく待っていると、wp-cron の仕組みを使い、誰かがアクセスしてきた時にバックグラウンドで画像ファイルを Amazon S3 にアップロードしていきます。(アップロードする画像はキューに入れられ、順番に処理されていくようです。)

画像ファイル毎に Amazon S3 へのアップロード状況が記録され、正常に保存された画像ファイルの URL は次回に表示される時から Amazon S3 の URL に置換えられます。

非常に簡単に使えて効果の高いプラグインなのですが、このブログの環境ではいくつか問題がありました。

画像ファイルが完全URLで指定されている事が想定されている。

このプラグインでは画像ファイルへの URL が http:// から始まる完全 URL で書かれている事を想定しているのですが、当ブログでは、ある記事では完全 URL、別の記事ではルート相対URL、という感じで記事ごとに画像の URL の書き方がバラバラでした。
このため、画像への URL を探す正規表現にマッチしない画像がたくさん出てきてしまいました。

メディアライブラリから画像を「投稿に挿入」していれば、完全URLで書かれるので普通に使っていれば問題は無かったはずなんですが。。。

しかたがないので、これはプラグインのソースに手を入れてルート相対URLでも書き換えられるように修正しました。

CloudFront の URL に対応していない。

このプラグインは画像ファイルのURLを http://>バケツ名<.s3.amazonaws.com という場所に変更するのですが、私のデータは Amazon S3 の中でも北米東海岸のサーバに置かれているため、ファイルの送信にちょっと時間がかかります。どうせなら国内の CloudFront のサーバから配信したいので、以下のようにソースを修正しました。wp-cdn.bluegold.me はヂストリビューションに付けた CNAME です。

*** 212,218 ****
  if (file_exists ( $mediaInfo [ 'cache' ] ) === TRUE) {
          $fileContents = file_get_contents ( $mediaInfo [ 'cache' ] );
          if ($fileContents == 'done') {
!           $cdnUrl = "http://{$this->s3BucketName}.s3.amazonaws.com/" . $mediaInfo [ 'path' ];
            $the_content = str_replace ( $mediaInfo [ 'url' ], $cdnUrl, $the_content );
          }
  } else {
--- 214,221 ----
 if (file_exists ( $mediaInfo [ 'cache' ] ) === TRUE) {
         $fileContents = file_get_contents ( $mediaInfo [ 'cache' ] );
         if ($fileContents == 'done') {
! //       $cdnUrl = "http://{$this->s3BucketName}.s3.amazonaws.com/" . $mediaInfo [ 'path' ];
!           $cdnUrl = "http://wp-cdn.bluegold.me/" . $mediaInfo [ 'path' ];
             $the_content = str_replace ( $mediaInfo [ 'url' ], $cdnUrl, $the_content );
         }
 } else {

このプラグインは非常に簡単に使えるので、Amazon S3 のアカウントを持っている人にはお勧めできますね。

複数の WordPress を１つのホストで稼働させる際に XCache Object Cache Plugin for WordPress 2.5+ を使用すると、オブジェクトキャッシュが混ざってしまうようです。

このサイトではhttp://blog.bluegold.me用とhttp://mama.bluegold.me用に２つの WordPress を稼働させています。それぞれ専用のデータベースを持つ独立したブログになっていますが、双方でオブジェクトキャッシュを有効にしたところ、しばらくして blog.bluegold.me 側の WordPress の管理コンソール(wp-admin)にログインできなくなりました。

XCache をインストールしてからは時間が経っていたので関係しているとは全く思わずに、MySQL 側でパスワードを何度も更新してログインを試みたり、WordPress 2.7.2 2.7.1 にバージョンを上げたばかりだったので、仕様が変わったのかと調べてみたりしたものの原因は分かりませんでした。

管理コンソールいろいろなIDとパスワードを入力しているうちに、blog.bluegold.me のユーザ名(bg)を入力すると「ユーザ名が違います」を表示されるのに、mama.bluegold.me 側のユーザ名(papa)を入力すると「パスワードが違います」と表示される事に気がつきました。ありえない事が起きているのが分かってきたので、試しにpapa の正しいパスワードを入力してみたところログインに成功し、bgのダッシュボードが表示されました。

ここでキャッシュが悪さをしている事がわかったので、オブジェクトキャッシュの使用を止めて、キャッシュをクリアするために PHP の FastCGI のプロセスを再起動しました。

調べてみると、やはり同じような問題を抱えている人はいるようで、以下のサイトに詳しく書かれていました。ユーザ情報が混在するのは仕様なんですかね．．．
http://jamescoletti.com/multiple-wordpress-installs-and-object-cache-collision

このブログは今のところ自宅に置いてあるサーバで運用しています。
手直にあるので管理は簡単なのですが、自宅の回線はアップストリームの帯域幅が大きくないので、ページを表示するさいの画像読み込みの遅延が以前から気になっていました。

このサイトでは以下のように nginx を設定することで、可能な限り静的なコンテンツの使用する帯域幅を小さくしようとしていますが、それでもファイル転送量のほとんどは画像ファイルになっています。

location / {
    if (-f $request_filename) {
        expires 30d;
        break;
    }
}
location ~* ^.+\.(html|css|txt|tar|bmp|rtf|js)$ {
    gzip_static on;
    expires 30d;
}

以前から画像を外部のサイトに置いて転送負荷を減らそうと考え、一部の画像をflickrに置いたりしていますが、これはという解決策がありませんでした。

最近、仕事関係で Amazon のウェブサービスについて調べていてAmazon CloudFrontというサービスがあるのを知り、WordPress のテーマの画像を置いてみたらどうなるのかを調べてみました。

Amazon CloudFront は Amazon の提供するウェブサービスの１つで、いわゆるCDNです。Amazon S3に保存したファイルをインターネット上に分散配置されたキャッシュサーバに置く事で、静的なコンテンツを高速に配信する事ができるようになっています。

有料のサービスなので利用には Amazon Web Service のアカウントが必要になりますが、以下のように安価な価格設定になっているので費用対効果は高いと思います。

United States

$0.170 per GB – first 10 TB / month data transfer out

$0.010 per 10,000 GET Requests

Japan

$0.221 per GB – first 10 TB / month data transfer out

$0.013 per 10,000 GET Requests

Amazon S3 の使い方はいろんな場所で説明されているので省きます。使用しているテーマのディレクトリから画像や css, js ファイルを CloudFront に配備してください。
S3 に置いたファイル（オブジェクト）に対して Everyone の Read 権限を与える必要がある点だけ注意してください。
Firefox のプラグイン S3OrganizerはCloudFront にも対応しているのでお勧めです。

CloudFrontに置いたファイルをWordPressから参照する方法はテーマファイル次第ですが、私のサイトで作ってもらったテーマでは bloginfo(‘template_directory’); と bloginfo(‘stylesheet_url’); の２つの値を変更するだけで大丈夫そうでした。
私はWordPressもPHPも詳しくなく、この二つの値を変更する「正しい方法」が分からなかったため適当にプラグインを書いてみました。
（こうやって野良プラグインが増えていくんだろうな）

プラグインのソースは以下の通りです。

<?php
/*
 * Plugin Name: CloudFront
 * Plugin URI: http://blog.bluegold.me/cloudfront
 * CloudFront plugin is a plugin designed to help you drastically speed up your blog's load time by loading content onto Amazon CloudFront.
 * Version: 0.1
 * Author: Blog Bluegold.me
 * Author URI: http://blog.bluegold.me
 * */

$cdn_base = "__EDIT_HERE__";

function    filter_cdn_css($url) {
    global $cdn_base;
    return $cdn_base . "/style.css";
}

function    filter_cdn_template_dirctory($url) {
    global $cdn_base;
    return $cdn_base;
}

add_filter('stylesheet_uri','filter_cdn_css');
add_filter('template_directory_uri','filter_cdn_template_dirctory');
?>

これを WordPress の wp-content/plugins/cloudfront/cloudfront.php という名前で保存するだけです。

今日はちょっと時間があったので文字化けの原因について調べてみました。

日本語の文字を含んだ広告を作成してWPAdsのデータベースを直接見てみたところ正常に保存されているようなので、原因は管理ページの表示部分にあると予想して wpads-options.php を見たところ、以下のようなコードになっていました。

<tr>
    <td valign="top">Description</td>
    <td>
        <input name="banner_description" type="text" size="50" value="<?php echo htmlentities($banner->banner_description);?>" /><br />
        Any text that helps you identify this banner
    </td>
</tr>
<tr>
    <td valign="top">HTML Code</td>
    <td>
        <textarea name="banner_html" rows="6" cols="80"><?php echo htmlentities($banner->banner_html);?></textarea><br />
        Copy and paste the HTML code to show the ad (for example, the Google AdSense code)
    </td>
</tr>

どうもhtmlentities()によるエスケープ処理で日本語が化けてしまっているようです。htmlentities() は文字コードを省略されると ISO-8859-1 として処理されるようなので、正しく処理するように ‘UTF-8’ を渡します。（ついでに XSS の問題がありそうなので ENT_QUOTES オプションを追加。）

修正後のソースは以下のようになります

<tr>
    <td valign="top">Description</td>
    <td>
        <input name="banner_description" type="text" size="50" value="<?php echo htmlentities($banner->banner_description, ENT_QUOTES, 'UTF-8');?>" /><br />
        Any text that helps you identify this banner
    </td>
</tr>
<tr>
    <td valign="top">HTML Code</td>
    <td>
        <textarea name="banner_html" rows="6" cols="80"><?php echo htmlentities($banner->banner_html, ENT_QUOTES, 'UTF-8');?></textarea><br />
        Copy and paste the HTML code to show the ad (for example, the Google AdSense code)
    </td>
</tr>

patch: wpads-utf8.patch

計測方法は以下のコードを footer.php に追加するだけです。

<?php if (is_user_logged_in()) { ?>
    <?php echo get_num_queries(); ?> queries in <?php timer_stop(1); ?> seconds.
<?php } ?>

結果は以下のようになりました。
トップページを3回表示させた時の時間です。

24 queries in 0.540 seconds.
24 queries in 0.545 seconds.
24 queries in 0.550 seconds.

WordPressで24 queriesは多いのか少ないのかは分かりませんが、1ページ作るのに 0.5 秒は非力なこのマシンでもちょっと遅いか。

そこで、MySQLのクエリキャッシュを有効にする事にしました。
このブログのサーバ機はメモリが256MBしかないので、いままでは無効にしていました。

my.cnfの具体的な設定値は以下の通り。

query_cache_limit=1M
query_cache_min_res_unit=4k
query_cache_size=16M
query_cache_type=1

同じようにトップページを3回表示させたところ、若干の速度向上がありました。
微妙と言えば微妙ですが。。。

24 queries in 0.512 seconds.
24 queries in 0.510 seconds.
24 queries in 0.510 seconds.

PHPアクセラレータにはeAcceleratorやAPCなどいろいろとあるようですが、今回は使った事のないXCacheを使ってみます。XCacheはバイトコードのキャッシュの他にPHPの変数をキャッシュする機能があるので、この機能をWordPressで使うように設定も行います。

XCacheのビルドは以下の通り簡単に行うことができます。

wget http://xcache.lighttpd.net/pub/Releases/1.2.2/xcache-1.2.2.tar.gz
gzip -dc xcache-1.2.2.tar.gz | tar xvf -
cd xcache-1.2.2
./configure --enable-xcache
make
make install

php.ini ファイルにXCacheの設定を記述します。
ソースに付属しているサンプルの xcache.ini からあまり変えていません。

[xcache-common]
zend_extension = /usr/local/lib/php/extensions/no-debug-non-zts-20060613/xcache.so

[xcache]
xcache.shm_scheme =        "mmap"
xcache.size  =               22M
xcache.count =                 1
xcache.slots =                8K
xcache.ttl   =             86400
xcache.gc_interval =         600

xcache.var_size  =            2M
xcache.var_count =             1
xcache.var_slots =            8K
xcache.var_ttl   =             0
xcache.var_maxttl   =          0
xcache.var_gc_interval =     300

xcache.test =                Off
xcache.readonly_protection = Off
xcache.mmap_path =    "/dev/zero"
xcache.coredump_directory =   ""
xcache.cacher =               On
xcache.stat   =               On
xcache.optimizer =            On

xcache.size は使用するアプリケーションの種類によって調整した方がよいと思います。XCacheはeAcceleratorなどと違い、キャッシュは全てメモリ上に持つようなので大きめに設定しておいた方が良いかもしれません。

バイトコードのキャッシュは以上の設定でphpのFastCGIを再起動するだけで使用出来ますが、変数のキャッシュを利用するにはアプリケーション側で対応する必要があります。WordPressにはXCache for WordPressというプラグインがあるようですが、最近のバージョンのWordPressでは動作しないようなので、XCache Object Cache Plugin for WordPress 2.5+を使用する事にしました。

インストールは簡単ですが、XCache Object Cache Plugin for WordPressは通常のWordPressのプラグインとはインストールするパスが異なるので注意が必要です。プラグインのファイルは object-cache.php １つだけで、これをWordPressのコンテントディレクトリ（通常は xp-content ディレクトリ）に置きます。私も最初は説明を読まずに他のプラグインと同じように xp-content/plugins ディレクトリに置いて、しばらく悩みました。

このようにバイトコードと変数の双方がキャッシュされている事を確認出来ます。これだけで体感出来る程度には速度が向上するので、導入する価値はあると思います。

gmail と uuencode をキーワードに Google で検索した所、mutt を使うのが一般的らしい。
↓のように ‘-a’ キーワードで添付するファイルを指定するだけで添付ファイルとして扱ってくれます。

mutt -a name.afz -a mysql_name.afz -s "name backup `date`" to_address

複数の添付ファイルにも対応しているので、この方法で問題ないかとも思ったのですが、１つだけ問題がありました。mutt では Envelope From を引数で変更することが出来ず、muttrc/.muttrc に別途設定する必要があります。

なんかめんどくさそうな感じがしたので、結局は Ruby でフィルタプログラムを書くことにしました。

以下のような物になりました。

#!/usr/bin/env ruby
#
# sendmail.rb</p>

require 'rubygems'
require 'tmail'
require 'net/smtp'
require 'nkf'
require 'etc'
require 'socket'
require 'optparse'


def usage( status, msg = nil )
  output = (status == 0 ? $stdout : $stderr)
  output.puts msg if msg
  output.print(&lt;&lt;EOS)
Usage: cat msg | #{File.basename $0} [-j|--ja] [-s <subject>] [-f <from>] <to>

  -s,--subject=sbj   subject of the message. (default=(none))
  -f,--from=from     from address.
  -a,--attachment=file attachment
  -j,--ja            handle japanese message. (default=off)

EOS
  exit status
end

def main(args)
  subject = nil
  from = guess_from_address()
  to = []
  attachments = []
  ja_locale = false

  OptionParser.new do |opt|
    opt.banner = "Usage: #{$0} [options]"

    opt.on('-s', '--subject=subj', 'subject of the message. (default=(none))') do |arg|
      subject = arg
    end
    opt.on('-f', '--from=from', 'from address.') do | arg|
      from = arg
    end
    opt.on('-j', '--ja', 'handle japanese message. (default=off)') do
      ja_locale = true
    end
    opt.on('-a', '--attachment=file', 'attachment') do |arg|
      attachments &lt;&lt; arg
    end

    to = opt.parse!(args)
  end

  usage(1) if to.empty?

  setup_mail(from, to, subject, $stdin.read, ja_locale, attachments)
end

def setup_mail( from, to, subject, body, ja_locale, attachments )
  mail = TMail::Mail.new
  mail.date = Time.now
  mail.from = from
  mail.to = to
  mail.subject = subject if subject
  mail.mime_version = '1.0'

  # 本文の処理
  if attachments.empty?
    message = mail
  else
    message = TMail::Mail.new
    message.transfer_encoding = '7bit'
  end
  if ja_locale
    message.body = <span class="caps">NKF.</span>nkf('-j', body)
    message.set_content_type 'text', 'plain', 'charset' =&gt; 'iso-2022-jp'
  else
    message.body = body
    message.set_content_type 'text', 'plain'
  end

  # 添付ファイルの処理
  unless attachments.empty?
    mail.parts.push(message)

    attachments.each do |filepath|
      body = nil
      File.open(filepath) { |f| body = f.read } rescue nil
      next if body.nil?

      attachment = TMail::Mail.new
      filename = File.basename(filepath)

      encoded_body = [body].pack('m').chomp.gsub(/.{76}/, "\\1\n")
      attachment = TMail::Mail.new
      attachment.body = encoded_body
      attachment.transfer_encoding = 'base64'
      attachment.set_content_type('application', 'octet-stream', 'name' =&gt; filename)
      attachment.set_content_disposition('attachment', 
                 'filename' =&gt; filename)

      mail.parts.push(attachment)
    end

    mail.write_back
  end

  puts mail.encoded

  mail
end

def guess_from_address
  user = getlogin()
  unless user
    $stderr.puts 'cannot get user account; abort.'
    exit 1
  end
  if domain = (Socket.gethostname || <span class="caps">ENV</span>['HOSTNAME'] || <span class="caps">ENV</span>['HOST'])
    user + '@' + domain
  else
    user
  end
end

def getlogint
  begin
    require 'etc'
    Etc.getlogin
  rescue LoadError
    <span class="caps">ENV</span>['LOGNAME'] || <span class="caps">ENV</span>['USER']
  end
end

main(ARGV)

TMail のサンプルの sendmail.rb をほぼそのまま使っています。
引数　’-a’ で添付ファイルを指定出来るように変更しました。（getopts が deprecated になっていたので optparse で書き直しています。）

バックアップの作成に使用した afio には、バックアップ対象のファイルを個別に圧縮する機能があります。圧縮に使用する外部プログラムは引数で変更出来るので、これを利用して暗号化を行います。

まずは、下のような暗号化用のフィルタを作成します。

#!/bin/sh
# encrypt_filter.sh

opt="-pass env:FILTER_PASSWORD"

if [ -r /etc/wp_backup_password ]; then
    opt="-pass file:/etc/wp_backup_password"
fi
gzip -c | openssl enc -e -aes-256-cbc $opt

次に afio に　-P オプションでフィルタプログラムを使用させます。

afio -ovz -Z -U -P encrypt_filter.sh backup.afz

これでバックアップファイルが作成される際に個別のファイル毎に暗号化されるようになります。

/etc/wp_backup_password ファイルが暗号鍵になります。このファイルはバックアップを元に戻す時に必要になるので安全な場所に保管しておかないといけません。パスワードファイルの中身はなんでも構わないので、うちのサイトでは以下のようにしてランダムに作成しています。

dd if=/dev/urandom of=/etc/wp_backup_password bs=256 count=1

このファイルはバックアップを行うアカウント以外からは読み込めないようにパーミッションを設定しておく必要があります。

暗号化とかは後で考えるとして、とりあえず下のようなスクリプトを書いてみました。

#!/bin/sh

AFIO=/usr/local/bin/afio
MYSQLHOTCOPY=/usr/bin/mysqlhotcopy
SENDMAIL=/usr/sbin/sendmail

WORKDIR=/var/tmp
WWWDIR=/var/www
LOGDIR=/var/log

if [ -f /etc/wp_backup ]; then
    . /etc/wp_backup
fi

if [ ${MYSQL_USER:-nothing} = "nothing" ]; then
    exit 1
fi
if [ ${MAIL_FROM:-nothing} = "nothing" ]; then
    exit 1
fi

function cleanup() {
    rm -rf $WORKDIR/mysql
    rm -f $WORKDIR/$name.afz
    rm -f $WORKDIR/mysql_$name.afz
}
trap "cleanup" EXIT

name=${1:-blog}

if [ ! -d $WORKDIR/mysql ]; then
    mkdir $WORKDIR/mysql
fi

(
echo "BACKUP START: `date`"

# backup mysql
$MYSQLHOTCOPY -u $MYSQL_USER -p $MYSQL_PASSWORD $name $WORKDIR/mysql

cd $WORKDIR/mysql
find $name | $AFIO -ovz -Z -U $WORKDIR/mysql_$name.afz

# backup wordpress
cd $WWWDIR
find $name | $AFIO -ovz -Z -U $WORKDIR/$name.afz

echo "BACKUP FINISHED: `date`"
) >> $LOGDIR/wp_backup.log 2>&1

# send the backup files
(
cat <<__END__
From: $MAIL_FROM
To: $MAIL_TO
Subject: $name backup `date`

blog name: $name
date: `date`

`uuencode $name.afz < $WORKDIR/$name.afz`

`uuencode mysql_$name.afz < $WORKDIR/mysql_$name.afz`

__END__
) | $SENDMAIL -f $MAIL_FROM -t $MAIL_TO

exit 0

バックアップを Gmail に送信する事はできたので問題は解決したかと思ったんですが、Gmail は uuencode の添付ファイルを認識しないんですねぇ。手元の Apple Mail でも認識していないので単に時代遅れなだけか。

もう少し考えねば