スレッドメモ

◆ [fj][fj.news.reader] Kanji code in fj

<YAS.04Nov1020516@kirk.is.tsukuba.ac.jp> Yasushi Shinjo (11/1)

In article <yotl3bzvqgxv.fsf@jpl.org>
Katsumi Yamaoka <yamaoka@jpl.org> writes:
> \2021\202j\202M\210+\202"\2021\202F\202M\202H\202"\202q\2026\202a\202H\202"\202E\2027\202)\202K\202&\201BNNTP \202M\202`\202F\202`\202F 8bit

GNUS (オリジナル) で読めません。EUC とか UTF-8 で記事を出す のはやめて欲しいです。(上の行は、GNUS の表示を意図的に再現し たものです。読めないことの迷惑さがわかるかと思います。なにか おかしいかと調べないといけないわけです。)

> 何か規則がありましたか? そうだとすればその目的は?

規則としては、JUNET時代から fj の記事は、JIS でというものが あります。その後、その規則は別に廃止されていません。

http://www.is.tsukuba.ac.jp/~yas/fj/junet-tebiki/J.6.3

MIME の思想と JIS の思想が合わないというのはあります。JIS だ と１つの記事に複数の言語を混ぜても平気な優れた体系です。MIME の Content-Type: は、1 言語だけ。しかも、charset という概念 を間違っているし。charset は文字集合。encoding とは別です。 charset では、JIS も EUC も Shift_JIS も同じで、encoding が 違う。というわけで、MIME は、文字コードもよく知らないバカが 作ったしょうもない規格なわけです。

<b9yfz3us8ms.fsf@jpl.org> Katsumi Yamaoka (11/1)

ぼくはついこの間まで、fj は junet じゃなければいけない、だから技 術的に可能な対策を、できるだけ Gnus に入れておこうと思っていたの ですが、いまだにそんな制約が必要なのかどうかが疑問になりました。 大昔の技術上の制約、または利用者の実態に合わせた決まりごとが存続 することによって、逆に失われるものがあるのではないか、と。

できれば認めていただきたいのですが、ぼくも fj を永く利用している 側の人間で、最初に fj の読み書きに使ったのは Nemacs 3.3.1 と GNUS v3.13 です。その立場からの発言と捉えていただければ幸いなの ですが、いつまでも junet コードに限定する規則を守ることは必要で しょうか?

<YAS.04Nov2212245@kirk.is.tsukuba.ac.jp> Yasushi Shinjo (11/2)

JUNET/fj で「JIS コードを使う」といことは、技術的な議論を積 み重ねて、合意したものです。これを変更するのは、同じくらい議 論を積み重ねて合意を取り直す必要があるでしょう。(国連決議を 無視して既成事実を作るという方法を取るというなら議論は不要な んだけど。)

<yotl654nd09r.fsf@jpl.org> Katsumi Yamaoka (11/3)

では fj の規則に戻って、ユーザに iso-2022-jp charset で扱うこと ができない文字を書くことを、fj に限定して禁止することは可能でしょ うか? 可能だとして、それがもたらすものは何ですか? それを考える と、ぼくは暗い気分になるのです。

ちょっと前だったら、他人から意見を求められたならば、ぼくは新城さ んと似たことを書いたでしょう。それが突然に変わったのは、Gnus の メーリングリストで encoding に関する話しを持ち出したときに、ドイ ツの友人が書いた「NNTP はもともと 8bit だよ」の一言によりました。

<YAS.04Nov6021507@kirk.is.tsukuba.ac.jp> Yasushi Shinjo (11/6)

実はネットニュースの配送は、NNTP だけじゃないんですね。UUCP とか電子メールとか。両方とも最新鋭のニュースシステム INN で サポートされています。

◆ [vine-users] Re: Netscape Mail について (Re: Kernelのアップデート)

[068536] Haruhiko Okumura (11/13)

ちょうどいい機会ですので皆様にお聞きしたいのですが，UTF-8を読めないか たって，どれくらいおられるでしょうか。

GmailがUTF-8なのですが，日常の用に使っていいか迷っています。

[068540] iida@yuichi (11/13)

sylpheedは問題なく読めてます。返信するとiso-2022-jpになります。
OutlookExでも問題ないですね。ただ返信してもutf-8です。
beckyは読めますが返信がダメでした。

[068541] Haruhiko Okumura (11/13)

今UTF-8を使うべきかどうかは，私も自信がありませんが，将来的にUTF-8が使 えたらいいなと思う理由は，使える字の数が多いことです。日本語に限っても， すっかり市民権を得てしまった◯囲み数字などを機種依存にならずに使うのに 便利です。

[068542] y_shiro (11/14)

* so-net webメールでの閲覧
受信しようとすると

エラー
WebMailサービスではご利用いただけない形式のメールがメールボックス に届いています。メールソフトで現在受信しているメールを受信してメー ルサーバーからメールを削除した後で再度ご利用ください。

と表示されてメールは見られませんでした。しかし、netscapeのwebメールから 日本語で送ったメールが全て見られないというわけではないようです。

* 鶴亀メール(Windows)での閲覧 (http://hide.maruo.co.jp/software/tk.html)
自宅にて、先ほどのso-netのwebメールで見られなかったメールを鶴亀メールで 受信するとちゃんと表示されました。詳しいことはわかりませんが、受信したと きのログをみると

Content-Type: text/plain; charset=iso-2022-jp (original=utf-8)

となっていて、受信時に文字コードが自動で変換されているようでした。 返信はiso-2022-jpとなっていました。

[068544] Daigoro Toyama (11/14)

KMail 1.5.4 (KDE 3.1.5) を使っておりますが、ちゃんと読めております。tilde が 化けますが、これは他の文字コードでも起きる問題なので、UTF-8 読み込みに関 する問題ではないようです。

[068551] KITA Toshihiro (11/14)

> Emacs系はどうなんでしょう？ 私の環境はすぐにいじってしまうのでよくわか
> らないですが，デフォルトではMule-UCSが入っておらずUTF-8なメールが読め
> なかったような気がします（今は違っているかもしれません）。

Vine 3.0 でもデフォルトではダメですね。 でも，apt-get install Mule-UCS をして，.emacs.my.el 等に1行
(require 'un-define)
と書くだけで，Vine 2.6/3.0 の emacs + Mew でもちゃんと読めます。
# そろそろ最初から Mule-UCS が入っててもいいような気もしますが。

[068552] Haruhiko Okumura (11/14)

> 今後メールソフトへの utf8 対応へのニーズ/圧力は高まりそうな
> 気がします。

少し前は件名に日本語を使っただけで叱られていたのが今は誰もそんなこと言 わないですし，UTF-8も今後急速に市民権を得ることが期待できそうですね。

インプリメンタの皆様，ぜひUTF-8をサポートしてください。

[068553] SAWAMI Hiroaki (11/14)

開発ブランチである 21.3.50 では既に UTF-8 が扱えるようになってま す。安定版では次期リビジョンを待ちましょう。

◆ [memo] Yahoo!を装った日本語フィッシングメール

[7884] Yudai Yamamoto (11/15)

昨日（11/14（日））の午後に、Yahoo!Mailのアドレス宛に「Yahoo! JAPAN - 有料コンテ ンツご利用停止に関するお知らせ」というメールが入っていたの ですが、どうも、フィッシングのようです。

結局、このメールにひっかかると、
１）Yahoo!のＩＤ、パスワード、暗証番号（セキュリティキー）
２）クレジットカードの番号、有効期限、カード名義、裏面の番号
が、だまし取られます。

実は、会員番号が変更になったクレジットカードでYahoo!関係の支払いを行って いたため、「変更忘れた！」と思ってあわててしまい、見事にひっかかってしま いました。
有効なカード番号を入れてもエラーになったので気がつき、カード会社に連絡 しました。
カード会社によると、他にも同様の連絡があったようです。

[7890] TAKAGI, Hiromitsu (11/15)

なぜこのようなことができたのか、また、なぜ私のYahooIDをURLに埋め込むこと ができたかですが、JavaScriptを使っているためです。私のYahooIDも、Webメー ルの画面からJavaScriptのプログラムによって切り出し処理をしているいるよう です。

そもそも、WebメールでJavaScriptが動いてしまうこと自体がよろしくありませ ん。つまり、端的に言えば、クロスサイトスクリプティング脆弱性があるという ことです。

HTMLの記述が可能なサービス（HTML対応Webメールを含む）においては、さまざ まなケースへの対応が必要です。いろいろなタグ、いろいろなシートの記法に、 スクリプトが動く機能がありますから、それらのどれもが動かないようにフィル タリング対策する必要があります。どうやら、以前から知られていたある方法が 対策漏れになっているようです。

Yahoo! Japanは、この脆弱性を修正するべきでしょう。

また、HTML対応Webメールのサービスを提供している他の事業者も、同様の被害 （また別の被害も）を避けるために、同じ脆弱性がないか調査して、修正するべ きでしょう。

[7891] 岩田尚一 (11/15)

と言うことは「ハッカーや攻撃者から身を守ることができる3 つのステップ」
http://www.microsoft.com/japan/security/incident/settings.mspx
の３ステップともちゃんとやっていれば、少なくとも今回のものには 騙されないと言うことになるのでしょうか？

[7892] TAKAGI, Hiromitsu (11/15)

そのようです。

幸い、スクリプトをオフにしても Yahoo! mail は使えるようですので、ステッ プ1 にしたがって、インターネットゾーンを「高」にしていれば大丈夫のようで す。

ただし、ステップ2にしたがって、yahoo.co.jp を信頼済みサイトに登録してし まうと、元の木阿弥ですので、そうしてはなりません。

また、ステップ3のメールをテキスト表示にというのをやっていても、Webメール がHTML対応だったらどうしようもありません。

[7893] TAKAGI, Hiromitsu (11/15)

また、このケースでは、通常のフィッシングと異なり、詐欺メールが Yahoo! mail 内にあるのですから、メールの表示方法に対する対策で、元から絶つこと ができるはずです。

9月下旬というかなり前から同じ手口が出ていた（同じかどうかは未確認ですが） のであれば、ユーザにただ注意を呼びかけるだけではなしに、自らのシステムの クロス際とスクリプティング脆弱性を修正すべきところ、それを怠ってきたとい うことでしょう。

◆ [memo] メールを開くだけで偽サイトに誘導するフィッシング詐欺メール

[7913] YAMAMOTO Yoshinori (11/16)

Internet Watchの記事によると、新たなフィッシング詐欺メールが 発見されたそうです。

▼メールを開くだけで偽サイトに誘導〜新たなフィッシング詐欺メール発見
http://internet.watch.impress.co.jp/cda/news/2004/11/16/5420.html

以下、この記事から少し引用しますが、

> このメールは開封されると、密かにスクリプトを実行して被害者
> のPCのホストファイルを書き換える。

これはhostsファイルを書き換えるという意味だと思いますが、hosts が書き換えられるとURLを偽装しなくても偽サイトへの誘導が可能に なりますので、アクセス先のURLを確認する方法では偽サイトである ことを見破れないことになります。

[7917] TAKAGI, Hiromitsu (11/16)

> ちょっと懸念しているのは、このような手法を使われる可能性があ
> るとなると、アクセス先のURLの偽装を見破るだけでは十分ではない
> ため、「フィッシングに騙されない方法」を実践するのがいささか
> 面倒になることです。

そんなことはありません。そもそも、

http://internet.watch.impress.co.jp/cda/news/2004/11/16/5420.html
| このメールは開封されると、密かにスクリプトを実行して被害者のPCのホスト
| ファイルを書き換える。

ということが起きるのは異常な事態、つまり、そのメールソフトにセキュリティ 欠陥があるということなのですから、パッチがリリースされているならば、常に それを適用しておくことです。

phishingの高度な手口が出現したときに、「防ぎようがない」という思考に陥る ことは危険です。とるべき対策はまず常日頃からの脆弱性パッチの適用であるこ とが第一原則であることを、周知徹底するべきです。

phishingによって詐称された事業者が、顧客に注意喚起するときに、広報担当者 が IT素人であると、「こんなの防ぎようがない」という思考に陥り、単に、 「当社からお客様に直接メールで連絡することはありません」というとおり一辺 倒のテンプレート文章を、サイトに貼り付ける対応だけで満足してしまうという ことが起こります。

Webサイト側にクロスサイトスクリプティング脆弱性がある場合にも、phishging 詐欺に騙されやすくなるわけですが、サイト運営者が「phishingは防ぎようがな い」という素人考えに終始すれば、その脆弱性が修正されることもなくなるわけ です。

マスメディアは、高度な手口に対して防ぎようがないかのような印象を抱かせる 報道をするのはやめるべきです。 （これまでにも、一般的に、新たな高度な手口のウィルスが登場すると、防ぎよ うがないかのような報道をして、ウィルス対策ソフトの売り上げに貢献してきた わけですが、やるべきことは脆弱性パッチの適用です。）

やはり、脆弱性がある限りどうしようもないのですから、まずとにかく、脆弱性 パッチを適用することです。

未知の脆弱性が心配であるなら、HTMLメールを使わないなど、脆弱性の影響を受 けやすい設定を無効にすること、というのが基本となるでしょう。

それを推進するためには、HTMLメールマガジンが百害あって一利なしであるとい う社会的合意を確立させ、まともな企業はHTMLメールマガジンを提供しない態度 を堅持するべきでしょう。