IT

ウェブメーラー再び改修

一昨日改修したばかりだが、またしても一部のSubjectがデコードされない問題発覚。

WILLCOMの**『Pic@nic-Mail 通話明細照会内容更新のお知らせ』が"=?ISO-2022-JP?Q?"**だったので、mimir.pl の mimedecode に追加対処するなり。

## charset=`ISO-2022-JP',encoding=`Q' の encoded-word にマッチするパターン
$match_mime_qp = '=\?[Ii][Ss][Oo]-2022-[Jj][Pp]\?[Qq]\?([^\?]+)\?=';
## charset=`utf-8',encoding=`Q' の encoded-word にマッチするパターン
$match_mime_utf_qp = '=\?[Uu][Tt][Ff]-[78]\?[Qq]\?(.+)=*\?=';
## &bodydecode が使う処理残しデータ用バッファ
$bdebuf = "";
## mimedecode interface ##
sub main'mimedecode {
    local($_, $kout) = @_;
    1 while s/($match_mime)[ \t]*\n?[ \t]+($match_mime)/$1$3/o;
    s/$match_mime/&kconv(&base64decode($1))/geo;
    s/$match_mime_qp/&kconv(&qpdecode($1))/geo;
    s/$match_mime_utf_qp/&kconv(&qpdecode($1))/geo;
    s/(\x1b[\$\(][BHJ@])+/$1/g;
    1 while s/(\x1b\$[B@][\x21-\x7e]+)\x1b\$[B@]/$1/;
    1 while s/(\x1b\([BHJ][\t\x20-\x7e]+)\x1b\([BHJ]/$1/;
    s/^([\t\x20-\x7e]*)\x1b\([BHJ]/$1/;
    $_;
}

これだけなら何て事無かったのだが、さらに「途中から漢字が化ける」という難儀な問題が隠れていた。

4時間ほど頭をひねった結果、’<’,’>‘の文字コードを含む漢字が化ける事に気付いた。“照"の7bits-JIS表現’>H’が、’>H’とサニタイズされてたわけだ。MIMEデコードとUTF-8変換を済ませてからサニタイズするよう common_lib.pl の header_analysis を改修した。

sub header_analysis{
        my $header = $_[0];
        my %header_hash;
        my $i;
        my @tmp_array = split(/\r\n([^\:^\s]+)\s*:/, $header);
        shift(@tmp_array);
        for($i=0; $i<$#tmp_array; $i=$i+2){
                $key = $tmp_array[$i];
                $value = $tmp_array[($i+1)];
                $key = uc($key);
                &Jcode::convert(\$value, "euc");
# bug fix 2006/03/10
#               $value = deltag($value);
                $value =~ s/^\s*//;       # 先頭のスペースを削除
                $value =~ s/\r\n /\r\n/g; # スペースは改行の後のもののみ削除
                $value =~ s/\r\n//g; $value =~ s/\t//g;
#               &Jcode::convert(\$value, $charset);
#               $value = &mimedecode($value, $charset2);
                $value = &mimedecode($value);
                &Jcode::convert(\$value, $charset);
# bug fix 2006/03/10
                $value = deltag($value);
                if(($key eq 'TO' || $key eq 'CC' || $key eq 'REPLY-TO') && exists($header_hash{$key})){
                        $header_hash{$key} .= ", $value";
                }else{
                        $header_hash{$key} = $value;
                }
        }
        if(!exists($header_hash{'FROM'})){ $header_hash{'FROM'} = '(Fromなし)'; }
        if(!exists($header_hash{'SUBJECT'})){ $header_hash{'SUBJECT'} = '(Subjectなし)'; }
        if($header_hash{'SUBJECT'} eq ''){ $header_hash{'SUBJECT'} = '(空文字列のSubject)'; }
        return %header_hash;
}

参照

竹田暁彦のホームページ http://www.ai.is.saga-u.ac.jp/~takeda/

qmail spf 対応

さぁ、次は受信側のSPF対応だというわけで、約1年ぶりにqmailのbuildを実施。アップデートされたという話は聞いてないが、念の為ググってみると、最近は最低限のパッチをセットしたnetqmailからbuildするのが主流なのだそうだ。

まず、netqmail-1.05.tar.gzを展開して./collate.shでパッチ適用した後、qmail-date-localtime、qmail-spf-rc5.patch、qmail-large-dns.patchを適用。手作業でマージする事もなく意外とすんなり片付いたなぁ、と思いつつsetupしたら外からのSMTPが接続できなかった。

でもログをみるとtcpserver的にはOKなので、SMTP認証のqmail-vidaとの連携が怪しい。昔のqmail-vida導入メモを読みなおすと、やはりqmail-vidaにqmail用のパッチがある事がわかった。

このパッチは3ファイル合わせて6ヶ所で適用に失敗したが、.rejファイルに吐出された分を手作業で適用。追加ファイルもコピーしたあとbuildしなおし、netqmail-1.05をsetupしたらOKだった。

[owner@host software]$ tar zxfv ~/archives/netqmail-1.05.tar.gz
netqmail-1.05/
netqmail-1.05/qmail-1.03.tar.gz
  - 一部省略 -
netqmail-1.05/COPYRIGHTS
netqmail-1.05/netqmail-1.05.patch
[owner@host software]$ cd netqmail-1.05
[owner@host netqmail-1.05]$ tar zxfv ~/archives/qmail-vida-0.53.tar.gz
  - 省略 -
[owner@host netqmail-1.05]$ ./collate.sh
You should see 7 lines of text below.  If you see anything
else, then something might be wrong.
[1] Extracting qmail-1.03...
tar: Read 1024 bytes from -
[2] Patching qmail-1.03 into netqmail-1.05.  Look for errors below:
24
[4] The previous line should say 24 if you used GNU patch.
[5] Renaming qmail-1.03 to netqmail-1.05...
[6] Continue installing qmail using the instructions found at:
[7] http://www.lifewithqmail.org/lwq.html#installation
[owner@host netqmail-1.05]$ cd netqmail-1.05
[owner@host netqmail-1.05]$ patch -p1 < ~/archives/qmail-date-localtime.patch
  - 省略 -
[owner@host netqmail-1.05]$ patch -p1 < ~/archives/qmail-spf-rc5.patch
  - 省略 -
[owner@host netqmail-1.05]$ patch -p0 < ~/archives/qmail-large-dns.patch
  - 省略 -
[owner@host netqmail-1.05]$ patch -p0 < ../qmail-vida-0.53/patch/qmail.patch
  - 一部省略 -
2 out of 14 hunks **FAILED** -- saving rejects to file Makefile.rej

2 out of 4 hunks FAILED – saving rejects to file qmail-popup.c.rej

ウェブメーラー改修

一部のSubjectがデコードされない問題発覚。またしてもUTF-8だ。**「メールヘッダーはISO-2022-JPがセオリーだろ~?」**と愚痴ったところで何の解決にもならない。

つか、これも時代の流れってヤツなのかしら?

でもね、mimedecodeがEUCとシフトJISにしか対応してないという問題は昨年解決したはずなのに…と思って見直すと、昨年改修したのは表示のUTF-8対応だった….しょぼん。

というわけで、今回は mimir.pl の mimedecode を改修。ISO-2022-JPをbase64decodeしてるとこをパクって、**"=?utf-8?Q?"**をキャッチしてqpdecodeに喰わせるよう追加すれば良い。

## charset=`utf-8',encoding=`Q' の encoded-word にマッチするパターン
$match_mime_utf_qp = '=\?[Uu][Tt][Ff]-[78]\?[Qq]\?(.+)=*\?=';
## &bodydecode が使う処理残しデータ用バッファ
$bdebuf = "";
## mimedecode interface ##
sub main'mimedecode {
    local($_, $kout) = @_;
    1 while s/($match_mime)[ \t]*\n?[ \t]+($match_mime)/$1$3/o;
    s/$match_mime/&kconv(&base64decode($1))/geo;
    s/$match_mime_utf_qp/&kconv(&qpdecode($1))/geo;
    s/(\x1b[\$\(][BHJ@])+/$1/g;
    1 while s/(\x1b\$[B@][\x21-\x7e]+)\x1b\$[B@]/$1/;
    1 while s/(\x1b\([BHJ][\t\x20-\x7e]+)\x1b\([BHJ]/$1/;
    s/^([\t\x20-\x7e]*)\x1b\([BHJ]/$1/;
    $_;
}

と、こんな感じかな。

しかし、「Yodobashi.com NEWS」ってば、いつからUTF-8でエンコードするようになったんだ?

参照

竹田暁彦のホームページ http://www.ai.is.saga-u.ac.jp/~takeda/

@IT http://www.atmarkit.co.jp/

OP25BとかSPFとか

今や"電子"という冠詞が古臭く思えるほど普及した電子メール。そんな便利なシステムの裏で足を引っ張るのが"スパム"や"ウィルス"、“ボット"による迷惑メール。bravotouring.comでも一日平均400通以上を受信して無駄なCPUパワーを浪費しているのだが、先日JEAGから提言書が発表され、迷惑メール対策に向けての第一歩が踏み出されようとしている。

日毎の推移

2005年のメール受信数グラフ

提言の一つの柱は「Outbound Port 25 Blocking (OP25B)」と呼ばれ、迷惑メールの多くがISPのメールサーバーを経由せず送信先メールサーバの25番ポートに接続して送信される事から、自ネットワーク外への25番ポートの接続を遮断する事で外部へ送信される迷惑メールを抑止する仕組みだ。

これにより自分のISPがOP25Bを導入したからと言ってすぐに自分宛の迷惑メールが減るわけでは無いが、各社が導入する事により全体的に迷惑メールが減る事が期待される。

自宅サーバーを立てて遊んでいるような場合はメールの送信ができなくなる可能性があるもの、ISPのメールサーバーを使用する一般ユーザーへの影響は無い。

2つ目の柱は「送信ドメイン認証技術」で、これには「Sender Policy Framework(SPF)」と「Sender ID」という2種類がある。それぞれ送信ドメインを決定する論理が少し異なるのだが、送信側で設定するSPFレコードは共通なので実はSPFに対応しておけば良かったりする。

Sender IDに関してはマイクロソフトの保持するライセンスを巡ってIETFの場で揉めたのが記憶に新しいが、**「ライセンス・特許使用料を求めない」**事を明確にした事によりExperimentalとして承認されている。ちなみに『Sender ID Framework と知的財産についての概要とよく寄せられる質問』に

Q5: マイクロソフトとライセンス契約を締結する必要があるユーザーは誰ですか? A: ライセンスが、Sender ID Framework の PRA チェック手段を使用して電子メールを確認する組織 (ISP、大企業) に関連する場合だけ、ライセンスを取得する必要があることに注意することが重要です。単に Sender ID レコードを公開するだけの組織には、ライセンスは必要ありません。

と、書かれているように受信側でPRAチェックを使用する場合にはライセンスを取得する必要があるものの、送信側でSPFレコードを公開するだけならばライセンスを取得する必要はないという事だ。

というわけで中途半端なまま放置していたSPF対応のtinydns用dataファイル改修版。

# SOA/NS/A
.bravotouring.com:210.xxx.yyy.zzz:ns1.bravotouring.com:86400
# SOA/NS
.bravotouring.com:210.xxx.yyy.zzz:ns2.bravotouring.com:86400
# MX/A
@bravotouring.com::bunny.e-globaledge.com:10:86400
@bravotouring.com:210.xxx.yyy.zzz:mail.bravotouring.com:20:86400
# A
+bravotouring.com:210.xxx.yyy.zzz:86400
+www.bravotouring.com:210.xxx.yyy.zzz:86400
# TXT
**'bravotouring.com:v=spf1 mx ~all:86400**
'bravotouring.com:Powered by djbdns - http072円//cr.yp.to/djbdns.html

でもって、「Sender ID リソース テクノロジに関するツールと情報」に書かれているように、check-auth@verifier.port25.com宛にテストメールを送信すると、

==========================================================
Summary of Results
==========================================================
mail-from check:   pass
PRA check:         pass
DomainKeys check:  neutral (message not signed)

という返信が返って来たので、確認OKという事だ。めでたしめでたし。

PSEマークを巡る攻防

先日『PSEマークを知ってるかい?』で取上げた「電気用品安全法」について、改めて国会で取上げられている。

土手の菜の花

3/4 筑後川にて

2月24日の「経済産業委員会」と3月1日の「予算委員会第8分科会」で日本共産党の塩川鉄也議員が、3月1日の「予算委員会第7分科会」では民主党の川内博史議員がそれぞれ質問を行った。

ちなみに、どちらも衆議院TVのビデオライブラリで観られる様になっている。

上記質疑によると、中古家電等の販売・リサイクル業者への周知が行われたのも2006年に入ってからであり、そもそも審議会でも中古電気用品については議論されておらず、資料でも触れられていなかった模様。お役人様は**「電気用品取締法の時から中古品を排除していないと解釈している」**と言っていたが、もともと経過措置は在庫品を対象としたものであり、中古品に関して法令集に基づく根拠も示されなかったらしい。

簡単に言うと**「中古家電は蚊帳の外だった」という事であり、中古業者から問合せがあったので慌てて「適用」**となってしまったいうのが実態なのかなぁ。

「電気用品安全法」の趣旨からすると「中古だから安全性が担保されなくて良いとは言えない」という考え方は健全で理解できなくは無い。「電子楽器と炊飯器を一緒にされては困る」と言って楽器関係だけにお目こぼしを求めた音楽関係者にはガッカリ。何かを勘違いしてるんじゃなかろうか。

ただ、川内博史議員が指摘した**「中古業者が電気用品安全法に適合させる為に改造を施して販売した場合に特許や商標侵害で元のメーカーから訴えられる恐れがある」**という問題もはらんでいたり、政府側の答弁に合理的な説得力が欠けるのは事実であり、現実的にはもう少し知恵を絞る必要があるように思える。

「適用を延期すべきだ」という要求に対して、大臣は「残った期間で周知徹底したい」と答えるに留まったが、中古品の買取りがストップしている現実を鑑みても中古家電市場はまさに消滅の危機に瀕していると言え、廃業する業者が処分する資金にも事欠いて不法投棄に走る懸念すらある。とっくの昔に成立した法律の取り扱いに大ドンデン返しが起り得るのかどうか、注目したい。

それにしても迎陽一商務流通審議官の受け答えというのは如何にもお役人的な詭弁でいけすかね~。ガンバレセンセ-。

参照

衆議院TV http://www.shugiintv.go.jp/

日本共産党 http://www.jcp.or.jp/

衆議院議員川内博史の日記 正々堂々blog http://blog.goo.ne.jp/kawauchi-sori/

電気用品安全法に反対します http://antipse.org/

Winny絡みの情報流出

ファイル交換ソフトWinnyに絡んだ情報流出・漏洩事件が後を絶たない。

土手の菜の花

3/4 筑後川にて

ちょっと遡っただけでも京都刑務所の事故、名古屋市消防局の事故、富士通の事故、富士宮信金の事故、海自の事故、NTT東西の事故、モスフードの事故と、ざっと7件を数えている。

特に自衛隊の情報流出は米軍の機密情報を含むという噂も一部にはあり、もしそれが本当だと日本の安全保障だけでなく今後の日米関係にも悪影響を及ぼしかねない深刻な問題に発展する心配もある。

基本的にはコンピューターに関するリテラシーがそれほど高くないユーザーの迂闊な行為が原因だと思われるが、富士宮信金の事故は開発・保守業務を請け負ったNEC関係者の失態だという事から、IT業界の中にはその程度のお粗末な関係者も居るという実態を図らずも露呈した事にもなり、そういう観点でもショックは大きい。

これはWinnyを通して共有する初のマルウェアAntinnyが2003年8月に発生して以降いくつもの情報漏洩事件が発生しているにも関わらず、「アンチウィルスソフトを入れているから大丈夫」と慢心しているユーザーが如何に多いかを物語っているような気がする。

アンチウィルスソフトは常に万全ではなく、新種のマルウェア・ウィルスにはアップデートされるまで無力だという事を理解しておかなければならない。

基本的には**「Winnyでなければできない」**ような事は無いので、使わないのが一番安全だ。Winnyそのものに重大な欠陥があるというワケではないが、Winnyの「一旦ネットワークに流れてしまった後では制御不能」という特性については問題が多い。自分自身もそうなのだが、ユーザーにも非があるとは言え、よもやファイル交換ソフトが国益や国際関係にすら影響を与えかねない事態を招くかもしれないとは作者も思わなかったのだろう。

更にWinnyを使ってなければ安全と言うわけではない。ここに来て「山田オルタナティブ」にも注意するよう警告が発せられている。

「山田オルタナティブ」はWinnyに限らず、メールの添付ファイルやWebサイトからのダウンロードで感染する可能性があるそうだ。つまりはWinnyを使ってないからと言って油断する事なく、感染防止のセオリー「不要不急なファイルはダウンロードしない、開かない」を徹底する事が肝心だ。

参照

ITmedia http://www.itmedia.co.jp/

INTERNET Watch http://internet.watch.impress.co.jp/

MSN-Mainichi INTERACTIVE http://www.mainichi-msn.co.jp/

YOMIURI ON-LINE http://www.yomiuri.co.jp/

山陽新聞 http://www.sanyo.oni.co.jp/

アルプス プロアトラスSV

もちっと続くGARMINのeTrex絡みネタ。今回は地図ソフトのアルプス、プロアトラスSVを買ってみた。

「全国版DVD」はアルプスOnlineショップでの通常売価15,540円。しかしamazon.co.jpで最後の1個だったアップグレード版をGetできたので、9,217円也。他社のゼンリン電子地図帳Zユーザーも対象となるコンペティティブアップグレードにも対応とは嬉しいね。

なぜゼンリン電子地図帳Zを持っていながら今さらプロアトラスSVかと言うと、こいつはGARMINのeTrexを公式にサポートしており、シリアル接続してトラックログを直接ダウンロードできるからだ。

ちなみにプロアトラスSVをインストールしてeTrexを繋いだパソコンをクルマに積めば、現在位置表示に合わせてルート探索ができる(進路案内はできない)そうだが、野生のナビシステムを具備するYANOさんには、そういった必要性は無い。

というわけで、先日のトラックログを取り込んでみたのがこれ。

青ラインがGPSの航跡

Trackking by eTrex and プロアトラスSV

太宰府IC付近のR3を拡大して見たところ、GPSの航跡が上り下りの車線をしっかり識別できているのは驚いた。

2万もしないハンディGPSなのにこれほどの精度とは予想以上。

またカシミール3Dのように速度によって色を変えたりできないのはちょっと見栄えがしないのだが、詳細イメージはやっぱり道路地図っぽい方が見易いのは歴然。

ちなみにカシミール3Dには『山と風景を楽しむ地図ナビゲータ カシミール3D GPS応用編』2,415円の地図を入れたのだが、こっちはこっちで印象が全然違うので、ケースバイケースで使い分ける事になりそうだ。

参照

株式会社アルプス社 http://www.alpsmap.co.jp/

amazon.co.jp http://www.amazon.co.jp/

Origami Project

Microsoftの新しいモバイルデバイスと言われているOrigami Project。

全ては3月9日に明らかに

http://www.origamiproject.com/

当初はappleのiPodキラーとなるメディアプレイヤーと言われていたのだが、ぶっちゃけた話Windows XPを搭載した「ウルトラモバイルPC」らしい。

ちなみに「Origami video: the real deal?」にある写真がプロトタイプという噂だが果たしてどうだか。W-ZERO3みたいなPDAサイズかと思ったが、ふた回りくらい大きいかなぁ。

いずれにせよ、Microsoftがハードウェアそのものを販売するというのはちょっと疑問で、写真が本物だとしてもあくまでもリファレンスモデルに過ぎず、各社が特徴を出したカスタマイズモデルをリリースするのではないかと思うのだが、はてさて。

全ては1週間後の3月9日に明らかになる。

参照

ITmedia http://www.itmedia.co.jp/

Origami Project http://www.origamiproject.com/

mixi300万人突破

SNS(ソーシャルネットワーキングサイト)のmixi(ミクシィ)が、昨年12月6日からの84日間で100万人増えたそうな。

Mixi

mixi

100万からの+100万に4カ月強かかったところを3カ月弱で達成した事になり会員数の伸びは更に加速しているのだが、まぁ新しく招待された人が更に数人を招待していけば指数関数的に延びていくのは当たり前の事であり何も驚くに値しない。ただ、ここ最近の重さを考えると設備増強が追い付いていないんじゃないかと少し心配している。

まだビギナーなのでmixi(ミクシィ)の本質というか良さを感じるところまで至っていないのだが、コミュニティの観点からも拡がる事によって逆に失われるものも多かれ少なかれあるわけで、会員数の急増がどんな風を吹かせるのか注目したい。

参照

ITmedia http://www.itmedia.co.jp/

mixi(ミクシィ) https://mixi.jp/

Google Map対ALPSLAB

地図のアトラスシリーズで知られるアルプス社が、ネットワーク時代における次世代地図サービスのショーケースとしてALPSLABのサービスを開始した。

Movable Type、tDiary、Hiki用のプラグインが提供されていて、こんな感じでWebサイトやブログに地図を貼り付ける事もできるそうだ。

Firefox用の地図検索プラグインも提供されているというのが感じが良い。

この手のサービスは言うまでもなくGoogle ローカルが先行しているが、ベースとなる地図がゼンリンのそれより見易い気がする。

Google ローカルはGoogle ローカルで高く評価しているのだが、なんでもかんでも「Googleで万全」という傾向にユニカルチャーの危うさを感じ始めたところなので、ALPSLABには日本発のコンテンダーとして大いに期待し、また応援したい。

参照

INTERNET Watch http://internet.watch.impress.co.jp/

株式会社アルプス社 http://www.alpsmap.co.jp/

ALPSLAB http://www.alpslab.jp/