メールが使われ始めた当初、テキストによるプレーンメールのやりとりしか存在していませんでしたが、
それから20年近く経つと状況は様変わりし、今ではOutlookを筆頭に、
当然のようにHTMLメールを書くことを要求してくるメーラーが増えてきました。
IT業界に生きる人たち、とりわけ技術リテラシーが高い人達にしてみれば、「HTMLメールを使うなどもってのほか」
という意見が多数派を占めると思います。
もちろんそれには根拠がある訳で、例えば不正なコードを含んだHTMLを閲覧することによって、社内の秘匿情報が外部に流出したり、
その原因となるウイルスが社内ネットワークに侵入されるリスクがあるのは、少しインターネット事情に詳しい人なら当然の知識です。
※世の中には閲覧しただけでウイルスに感染してしまうという悪意あるサイトも存在します。
これは2007年6月20日に発表されたニュースですが、画像を読み込んだだけで、内部に仕込まれた攻撃用スクリプト
(エクスプロイドコード)が実行されるというものも発見されました。
このような状況でHTMLメールを標準機能として提供するベンダーの気が知れません。特にマイクロソフトなどは、
自らシステムの脆弱性について注意を促しているにも関わらず、
自社が提供するOutlookはデフォルト設定がHTMLメールの読み書きです。
マイクロソフトに限らず、インターネットメールを扱うメーラーがHTMLにシフトする理由は分かります。
それは多彩な表現力を獲得するためです。
競合製品でLotusNotesというグループウェアがありますが、
こちらではNotesScriptというものを使ってメールを簡単にデコレートすることが可能です。
HTMLメールがまだ認知されていなかった頃、企業ユーザをベースにNotesはシェアをどんどん拡大していきました。
このNotesを妥当するためにマイクロソフトが世に送り出したのが、Windows Sharepoint Server
(Exchange Serverという方が適切?)です。
こちらもグループウェアですが、HTMLによる装飾が簡単に扱えるようになり、デフォルトで使えるように設定してあります。
(Web上で使うことができるOutlook Web AccessはHTML(XML)前提です)
しかし、ユーザにHTMLメールの使用を強いるということは、ユーザ側に必要以上にセキュリティ対策を強要することに他なりません。
今や、多くの企業のメールサーバでは、スパムフィルターや信頼性が疑われるメール(exe/bat形式ファイルが添付)
を除外するフィルターを導入していますが、それさえも完璧ではありません。前述したように、
画像に攻撃用スクリプトを仕込まれたメールを防ぐことはできないでしょう。
しかし、こういった問題はHTMLメールだからこそ起こることであり、そもそもテキストメールだけでやり取りをすれば、
そのようなリスクは発生しません。
ゆえに、HTMLメールはメールサーバのフィルタでテキストに変換してしまうという企業も実は結構あります。
これだと送信者が意図したようなレイアウトで受信者がメールを見ることができませんから、
だったら最初からテキストメールで送っておけ、ということになりますよね。
はてさて、HTMLメールとテキストメール、どちらが主流派なのか、よろしければ皆さんの意見をお聞かせ下さい。
※このエントリは CNET Japan ブロガーにより投稿されたものです。シーネットネットワークスジャパン および CNET Japan 編集部の見解・意向を示すものではありません。
吉澤準特 on 2007/06/23
多聞さん、コメントありがとうございます。
私が使っているのは2003ですね。この頃からMS社は、Sharepointをグループウェアの中核として周辺のサービスを集約してきたように感じています。
なるほど、山田さんとそういったやりとりがかつてあったのですね。Outlook Express系を使うのはコンシューマですから、これがHTMLメール標準だと言うのはあまりよろしくなかったかなと思います。
人間というのは、一番最初に触れた環境をベースに考えやすいもので、HTMLメールから入った人は、当然のようにHTMLメールを使い続けるため、啓蒙という観点で言えば、デフォルトはテキストメールのままのほうがいいかな、と個人的に感じていました。
また、画像の外部読み込みについては、まさしく最近のメーラーは許可を下すアクションを起こさないと読み込みにいかない仕組みになってますね。好ましいことだと思います。
吉澤準特 on 2007/06/23
HTMLでのデコレートには端末間の解釈の違いがあって不便で、セキュリティには自由度が高すぎて問題なものが使われるのは望ましくないですが、デコレートしたい、表現を豊かにしたいという欲求をテキストメールばかり支持する技術者は軽視しすぎだと感じています。
このギャップを埋めるには、もっとセマンティックで限定的な語彙をもった体系でメールを書けばいいと思います。ヘッダーなどのめたデータを含めそのような仕様が策定されれば、端末間の表現力の違いも代替表現のマッピングによって実現されますし、セキュリティ的な問題もHTMLを使う場合よりも語彙が限定的であるぶん随分マシになると思います。
今、どっちが主流?と言われれば身の回りではテキストメールですが、将来的にリッチな表現を諦めましょうと結論付けて欲しくはないです。
ホワイトリストというアプローチはホワイトリストの維持管理、有志となればそのリスト自体の信頼性が問題になってくると思います。本文内の紹介リンク含め、ざっとWeb上の情報資源と考えると、ブラック&ホワイトリストブックマークのような集合知的アプローチで維持管理コストは減ると思いますが、リストの信頼性の部分は解決できません。
外部のファイ
cm3 on 2007/06/22
吉澤さんのコメント
> 最近はメリットも十分に発揮しているHTMLメールですが、そういったものはほぼ例外なく外部サイトから画像を読み込む作りになっていますよね。
ですが、MHTファイルで画像をMIMEエンコードしてメールに添付して持つような方式で外部サイトの画像を読まない形式もあります。また、最近のメールソフトは標準設定では外部サイトの画像などの資源を読まないので、ある程度配慮されています。
多聞 on 2007/06/22
吉澤さん、こんにちは。
Outlookと一口に言っても、Outlook 98、200、2002、2003、2007とそれぞれ仕様が違います。また、Outlook Expressは別系列のソフトで、用語定義からして違ったりします。
それで、Outkook Expressの標準設定がHTMLなのはよろしくないと山田祥平さんじきじきにお叱りいただいたのは1998年ごろのPDCだった気がします。その時、何も言えなかったのですが、Outlook 98やその後の2000は標準がリッチテキスト(非HTML)だったとかちゃんといえなかったのが今も心残りです。
その後、Outkookはリッチテキストという独自仕様を捨てて、HTMLに変えたようです。いろいろ問題はあるにせよ、これも流れかなという気はしています。
多聞 on 2007/06/22
コメントありがとうございます。
企業メールの中には、書名欄がかっこよくデコレートされていたり、社内ニュースレターが非常に読みやすいレイアウトで整形されていたりと、最近はメリットも十分に発揮しているHTMLメールですが、そういったものはほぼ例外なく外部サイトから画像を読み込む作りになっていますよね。指定したサイトからだけ画像をDLするとしても、そもそも読み出し先のサイトが信用できるか分からないという点がネックです。
これを解決するための一つの方法としては、インターネットコミュニティ全体が共有できるホワイトリストを作るというアプローチがあるのかな、と思います。有志がコンソーシアムを立ち上げて、そこが管理する。うーん、どうでしょう。
吉澤準得 on 2007/06/21
テキストメールが主流だし、今後もそうすべきなのは間違いないでしょう。
しかし、本来であれば利便性も追い求めたいところ。以前、マックユーザーの人がHTMLメールを使いこなして、画像付で社外でのイベントの報告を送ってくれたのを見たときに、こういう機能も本来は使いたいなあと思いました。
セキュリティと利便性をもっと高い部分で両立する方法を模索するべきではないでしょうか?
最適解/プライバシーマーク・個人情報保護Blog on 2007/06/21
ブログにコメントするにはCNET_IDにログインしてください。
このアクセサリはiPhoneでは動作しません
コンテンツ市場14兆円の中身と行方
原宿で野宿を含む15時間 - iPhone行列完全ドキュメント
日本、スラム化の予感
iPhoneでコピー&ペーストを実現する
HP 2133 Mini-Note PC + Ubuntu 8.04.1 LTS Windows Vista Businessとのデュアルブート成功
iPhonista Nightに参加してきました。
現役世代向け:メタボ健診等パブコメ、 9 月 1 日締切!(副題:リンク専門の限界)
CMSは一般のサイトよりも仕様書が重要
weblin(ウェブリン):アニメーションアバターの作り方
府中高校 卓球部関係者 集まれ!!! みんなのお題では、ブロガー同士で質問を出し合いそれに対する回答や意見を集めています。今日はどんな話題が盛り上がっているでしょう?
CNET Japan ブログネットワークは、元はCNET Japanの一読者であった読者ブロガーと、編集部の依頼により執筆されているアルファブロガーたちが、ブログを通じてオンタイムに批評や意見を発信する場である「オピニオンプレイス」、また、オピニオンを交換するブロガーたちが集うソサエティです。
広い視野と鋭い目を持ったブロガーたちが、今日のIT業界や製品に対するビジョンや見解について日々熱く語っています。
CNET Japanやその他サイトが提供するITニュースやコンテンツへの意見や分析、 ビジネスやテクノロジーに対するビジョンや見解について語っていただける方を 募集しています。ご応募はこちらから
ブログの投稿はこちらから(※ブロガー専用)
今年最も活躍したブロガーを表彰します。詳細はこちらから
これは、CNET Japan 編集部の依頼に基づいて執筆されているCNET Japan アルファブロガーによるブログの印です。
CNET Japan ブログネットワーク内で拍手の代わりに使用する機能です。ブログを読んで、感激した・役に立ったなど、うれしいと思ったときにクリックしてください。多くGood!を獲得した記事は、より多くの人に読まれるように表示されます。
[レビュー]高い信頼性を普通に使う地球に優しい電源ユニット--Antec EarthWattsシリーズ EA-650
今週の新製品総チェック:薄さ13.9mmのサイバーショット登場!NEC「LaVie」はデザインモデルが
[レビュー]テレビを持ち歩ける最強ツール--ソニー、Blu-rayレコーダー「BDZ-A70」
cm3さん、コメントありがとうございます。
セマンティックで限定的な言語というのは、NotesでいうNotesScriptですね。同じような思考でMSさんもリッチテキストという仕様を採用したのでしょうが、時代の流れによっていつのまにかHTMLが標準になっていましたね。
ホワイトリストに対する考え方、確かにリスト自体の信頼性を完全なものにすることは不可能ですね。
コストの観点で考えるなら、ウイルスチェッカーなどのツールでメール内のスクリプトに対し、事後的に対応するのが最も現実的なのかもしれません。
まあ、ブラックリストをセキュリティベンダー間で共有し、いち早く定義ファイルを更新する・・・そんなスタイルでしょうか。