OpenPGPに理論上のセキュリティホール 76
ストーリー by Oliver
まさに数学的な問題 部門より
まさに数学的な問題 部門より
k3c 曰く、 "Blowfish暗号化アルゴリズムの考案者として知られるBruce Schneier氏らが発表した論文によれば、OpenPGP準拠の暗号化ソフトウェア(PGPやGnuPGなど)の大半に、理論的に攻略可能なセキュリティホールがあるとのこと。
概略の説明がInternet Watchの記事に出ているが、要するに、ある人(A氏)の公開鍵で暗号化したメッセージに少しだけ改変を施し、これをA氏に復号化させ(当然意味不明のメッセージになる)、複合後のメッセージを入手できれば、暗号化される前のメッセージを復元できるということらしい。…復号後意味不明のメッセージになった場合には、送ってきた相手にその内容を晒すことは避けるべきということか。そもそも送っても、相手だってどうしようもないだろう。悪意がない限りは…。
ところでこのような詐欺的手口が成立するためには、暗号化された文書を何らかの方法で入手し、しかも改変後のメッセージををA氏が復号化して送り返さなければならないため、かなり成立しにくいような気もする。しかし将来、PGPやGnuPGが標準的な暗号化ツールとして普及したとき、セキュリティに理解のない利用者がこのような攻撃の犠牲になる可能性がないとは言えないだろう。今でも実際、メールに返信するのにわざわざ元のメールを全文引用する人もいることだし…。
なお、論文では、OpenPGPの仕様を修正することも提案されている。"
傾向と対策 (スコア:1)
・解読したゴミメッセージを送り主に送り返さない
で、十分と言うことですよね？
で、もしやってしまったとしても
・PGP自体が破られたわけではない
・解読されるのは「送り返したメッセージ」だけ
・内容が圧縮されたメッセージは解読できないことが多い
ということの様ですね。Inpress Watchを読む限りは。
# PGPを使ったことが全然ないのであてにならないと思いますが。
# 「元の論文」自体もよんでないし。
Re:傾向と対策 (スコア:1)
>解読されるのは「送り返したメッセージ」だけ
については、送り返した意味不明のメッセージと改竄前の暗号文との差分から「秘密鍵」を類推出来る、ということではないでしょうかね?
で、秘密鍵を作り出せたなら、暗号メールを改竄出来るくらいですからいつでも経路の途中で盗聴し放題なのでしょう。
いや、間違った解釈かも知れませんが、ココまで大事になっていることからしてそのように判断するべきかと。
-+- 想像力を超え｢創造力｣をも凌駕する、それが『妄想力』!! -+-
Re:傾向と対策 (スコア:2, 参考になる)
Re:傾向と対策 (スコア:1)
素人考えでは、オリジナルの暗号文と完全な復号文と更に公開鍵があるならば、秘密鍵も生成可能なのかと思っておりますが…
まあ、いずれにしても今回の発見により、より安全性の高いモノになっていくのでしょうから、コレの迅速な遂行を希望したいですね。
-+- 想像力を超え｢創造力｣をも凌駕する、それが『妄想力』!! -+-
Re:傾向と対策 (スコア:1, 参考になる)
> あるならば、秘密鍵も生成可能なのかと思っておりますが…
いや、公開鍵暗号はまさにコレが難しいから成立するわけであって...
だってそもそも送信者が「完全な復号文」から受信者の「公開鍵」を
使って「オリジナルの暗号文」を作り出すわけでしょ？なので受信者
が公開鍵を公開した時点で、適当な文章を使えばこの三つは求まって
しまうので、その三つから秘密鍵が生成できたらかなり困ります。
違いますかね？
Re:傾向と対策 (スコア:1)
良かった、コレで「PGPが破られてはいない」「秘密鍵が露呈する訳ではない」と云うことについても同意出来ます。送付先に成り代われると云うことでなく、発信元と同等の情報を得られるってだけのことですね。確かにその通りです。
で、PGPを自ら使うような「意識の高い利用者」であれば、不用意に復号済の全文を送り返すなんて間抜けたコトはそうそう発生しないので(つか、単純に「送り直せ」ってだけの一行メールで済ませそう)、今回の穴を衝いた盗聴は実際は相当困難である訳ですな。更に、これだけ大々的に公表されたのであればほとんどのPGP系利用者が注意・警戒することになりそうですから、その分もこの穴を衝くのは難しいことになりますね。
ウムウム。
-+- 想像力を超え｢創造力｣をも凌駕する、それが『妄想力』!! -+-
Re:傾向と対策 (スコア:1)
Re:傾向と対策 (スコア:1, 興味深い)
メーラーなんかで外部コマンドとしてPGPを実行し、結果を作業ファイルとして容易に連想できるファイル名やディレクトリに保存したりする場合ってことね。
ということで、作業ファイル作るときはファイル名をわかりにくくしておくという対策も必要かと＞PGPを外部コマンドとして使うツール作者諸兄
Re:傾向と対策 (スコア:3, すばらしい洞察)
そもそも、特定の位置に中間ファイルを生成するようになっていて、そのファイルを入手する事ができるのであれば、わざわざ壊れたメッセージを送り付けなくても壊れていない暗号化ファイルを送ってデコードされたファイルを入手できるって事でしょ。
全部ダダ漏れなのに、ゴミメッセージの流出だけ気にしても仕方ないですね。
ところで、いつも思うのですが、この「固定位置にファイルを作るのは脆弱」という主張(?)は何か違和感を感じてしまいます。
ランダムなファイルパスであれ、特定のファイルパスであれ、本来漏らすべきでないファイルが流出するという事は、その流出経路側の問題であって、そこにファイルを置いた側が「脆弱だ」と指摘されるような事なのでしょうか？
「穴の開いたバケツで水を汲むと水が漏れるので、バケツは使わないで、タライとか洗面器、コップなどを使いましょう。」
と言われても「はいそうですか」と従うのではなく「穴の開いたバケツなんか使うな」と普通は言いませんか？
でも、本当にそう言っちゃうと「でもウチのバケツは穴が開いてるんです」「穴の開いたバケツを使ってる人がたくさんいるんです」とか言われちゃうんですよねぇ・・・
Re:傾向と対策 (スコア:1)
パーミッションが正しくないとかの、そのファイルを作成する側の問題であれば、そのファイルを作ったソフト自身（ファイルを置いた側）の問題ですから「脆弱である」という指摘は的を射ていると思いますが、そのソフトとは全く関係無い、他のソフトのバグによって漏れてしまうのに「固定ディレクトリに置いた方が悪い」と言われてしまうのはどうかな？という事を書いたのでした＞(#146306)
Re:傾向と対策 (スコア:1)
public_html とか？
wild wild computing
差分攻撃? (スコア:1)
PGPって、アルゴリズムにべったり依存してないと思っていたので、「そんなん、アルゴリズム変えればいいじゃん」とか楽観視してたのですが、甘い?
それは差分攻撃とは言わなかったような (スコア:2, 参考になる)
差分攻撃は選択平文攻撃の一つで、
元論文の Abstract には「選択暗号文攻撃に対する脆弱性」と書いてあるから、
ここで言う攻撃に差分攻撃は当てはまらない。
# mishimaは本田透先生を熱烈に応援しています
特定実装ではなくアルゴリズムそのものにバグを見つけ (スコア:1)
誤記訂正 (スコア:1)
氏のお名前を綴り間違えておりました。正しくは、
Bruce Schneier
です。nが余計。お詫びして訂正いたします。修正しておいて頂けるとありがたいです＞編集者どの
Re:誤記訂正も間違っていた… (スコア:1)
回避方法として (スコア:1)
「同じ鍵でかまわないので、２段にする」
という回避策は効果があるのでしょうか？
識者のコメントを待ちます。
鍵が破られていないという前提では、問題点を衝いても得られる情報は、１段解読状態の文だけという思いつきです。
２段暗号化の相関などは一切考慮していません。
...教えてクンもーどになってしまった。
Copyright (c) 2001-2014 Parsley, All rights reserved.
Re:回避方法として (スコア:0)
あれは違うかぎで３回だっけ？
3DESの場合 (スコア:1)
参考:3DES [e-words.ne.jp].
3DESは鍵長を長くすることが目的であって、今回の 偽暗文の復号とからめるつもりはありませんでした。
十分な検討なしに、へたな方法を回避方法かのように出すのは害悪というツッコミは歓迎
Copyright (c) 2001-2014 Parsley, All rights reserved.
元のメールを全文引用 (スコア:0)
という文化圏が存在するらしい。
某T社の関連会社とか某T社の関連会社とか
Re:元のメールを全文引用 (スコア:2, おもしろおかしい)
「恣意的な引用の仕方は不愉快です」
とかでフレームになる罠
Re:引用の罠（ややおふとぴ） (スコア:1)
全文引用して、「注意喚起」なんて本文にしかないようなメールは著作権違反になるような気が。
今回のトピックでは基本的に避けられるようですが、今後なにか全文残しているとまずいセキュリティホールにもなるかもしれないし、全文引用しないほうがいい気がするんですが。どうでしょう？
/.configure;oddmake;oddmake install
Re:引用の罠（ややおふとぴ） (スコア:0)
相手が日に数百通のメールを連日こなしているなどで内容を覚えていない場合、全文引用したほうが業務の負担を軽くできるという勝手な思いやりもあります。
-----Original Message-----
引用というものは、１）出典が明記され、２）量的質的に本文が引用を上回っていないとならない
Re:引用の罠（ややおふとぴ） (スコア:1)
著作権って、(親告罪とかいうんだったですよね)やられた側が「これは駄目！」と訴えてはじめて
違反とかが成立するんだったような気が。
だから、メールについては、やりとりしてる両者が「こーゆーものなんだ」と思い込んでいる限り
誰も訴えたりしない、のではないかと。
>契約などの重要案件は何に対しての返信なのかを明確にするために全文引用するべきと考えます。
それは In-Reply-To: だか References: だかを使うものじゃないのでしょうか？
#ヘッダが信じられないなら、引用した本文(全文)だって信じる理由が無くなりますよね？
あとは「Thread表示をサポートしてないメーラーを使わない」ことによって
ビジネスの(^^;効率は上がるのではないかと愚考します。
Re:引用の罠（ややおふとぴ） (スコア:1)
ええと。俺、話題を勘違いしてるのかな。
#既に暗号化の問題ではないけど。
送る側から見ればそうですが、受け取る側から見れば両方が捏造される可能性
(つまり送り手がワルモノである可能性)が片方だけ捏造される可能性と大差ないはず
なので、同じにしか見えないのではないか、と思いました。
引用元の元メールと、引用した文字列とが、
一致してればそもそも問題なしだし、
少し違っていれば信用すべきは元メールしか有り得ないし、
大きく違っていれば「ヘッダが間違ったメールを参照してるんでねーの？」だし、
結局全文引用が「安全」性をあげたことにはならないような気がするんですが…
一般に、単に情報のバイト数(!)を増やしただけでは、信頼性は上がらないですよね。
てゆーか、なまじ上がったような気がするので、却って心配になるです。
>>あとは「Thread表示をサポートしてないメーラーを使わない」ことによって
>>ビジネスの(^^;効率は上がるのではないかと愚考します。
>いや、同感です。メールアプリケイションをブラウザとして使う場合に於いてはですが。
使う場合以外ってのがどういうのかは、ちょっと俺、知識が無いです。
ブラウザってのは、ここではメールログ(?)のブラウザ、のことですよね。
まあメーラー(?)ってのはたぶんメールブラウザを指すんだと思います。
Re:引用の罠（ややおふとぴ） (スコア:1)
＃わたしは、全文の「転送」なら許す立場です。
＃・・・もちろん、全部の文章に細かくコメントをつけるなら、
＃必要性があるので、全文の引用も認めないわけではありませんし、
＃全文の各部分にコメントつける必要があれば自分でもやりますが、
＃後ろに連ねて巻物式にデータサイズだけ大きくて、
＃文面全体を長くするのは勘弁してもらいたい立場でもあります。
>安全性については、全文引用がないままメールのやり取りが
>続いたときに途中のある時点で通信経路の不具合か何かで
>メールの文章が化けた結果元の文章とは違う意味になってしまい、
人為的な改変以外に、文字化けなどの発生で元の文章と違う意味になる
というのは考えすぎに思えます。
それこそ人為的な捏造だと思いますが。
＃しかし、たった一度のデータ化け発生で、即誤解？？
＃「ばけてて読めなかったから、ごめん、もう一度書いて」って
＃頼んで、相手の意図を問い合わせることもしないの？
＃そもそも、コミュニケーション手段はe-mailだけじゃない。
＃全文引用しないから理解できないんじゃなくて、双方の
＃コミュニケーション能力が低くてまともに会話できてないだけ、
＃ってこともあるので、全文引用で無意味に安心するのは
＃間違ってると思う。
時には、自分で咀嚼して、理解した中から発しなければならない
言葉も必要って事を、わたしは言いたい。
>メール発信者とメール受信者が知らない内にメール発信者と
>メール受信者が意図しない内容のやり取りが行われて
>どちらか一方にとって不利な結果になる可能性があって。
ここも、納得できない。
＃前にも挙げたとおり、コミュニケーション手段はe-mailだけじゃない。
言った、言わない、で論争になるのは、よくあることだけど、
e-mailの全文引用で解決できる問題じゃない。
これこそコミュニケーションで解決する問題ではないですか？
＃知らないうち、ってのも納得いかない。
＃双方の誤解や思い込み、記憶違いで話がこじれることも多々あるけど、
＃相手や自分の記憶をよく確認すればすむことじゃない？
＃その補足として、過去のe-mailを使うのはわたしもよくやるし。
＃でも、それを常に、他者の労力を割いてまで続けるのは無意味だと思う。
>もしそういう事実が発覚したときにメールのやり取りの中で
>いつからそうなのかを分かりやすくして
それはその様な事実に気づいてからすればいいこと。
日常レベルでその労力を他のヒトに押しつける必要性がどこにあるの？
＃あと、もらったメールを容易に破棄しないことが大切。
>原因究明の無駄な労力を消費しないために
その様な事実があったならば、それは無駄な労力じゃない。
＃日常からそんな労力を払ったり払わせるのが無駄って言わない？ねぇ？
>重要なメールは常に全文引用をすることで
>結果的に安全性を高めていることになると考えているという
>ことです。
結果的に？
関係者の労力、資源、リソースを払わせるのなら、もっと確実な
方法を取るべきでは？
＃しかも、安全性なんてなんにも高まってません。
＃送受信のデータ増大で無駄なだけ。
どうせなら逐一双方が参照できるweb(メンバー限定公開でOK)に
載せて、後で時刻と内容を互いに確認できるようにするとか、
そこまでしないと意味を成さないのでは？
>引用することで前のメールと異なっていることがすぐに
>判別するのであればそのあとメールのやり取りが暫く続いて
>からメールの改変が明らかになるよりも確実でより安全だと
>いうことです。
所詮テキスト、たった一つ改行文字を入れただけでデータが
同一でない事になってしまいますよ。
＃チェックの労力だけが大きくて、改変防止策などがないから、
＃それこそ労力の無駄に思えますが。
重要なのは文章ではなく、メールのやり取りで交換している概念や
意志、目的や合意事項などの文章で表現するしかないものでしょう？
それを確認するのに文章の同一性にこだわっても意味がないのでは？
双方の合意が取れているかわからないのであれば、相手に正面切って
尋ねるしかないでしょう？
＃「あんたは私が意図しているこういうことを理解しているか？」
＃ってね。
＃そこで誤解があれば、その時点で双方の理解している事項に
＃すり合わせていけばよいことでしょ？
あと、前にも書いたけど、全文引用が連鎖のように続く
---- redbrick
Re:引用の罠（ややおふとぴ） (スコア:1)
In-Reply-To: ヘッダがあれば、引用がなくても何に対しての返信かは分かります。だからそういう目的での全文引用は全く必要がない。
まともなメーラーならIn-Reply-To: とReferences: からスレッドを生成してくれるのでヘッダを自分で見る必要もありません。
そもそも相手のシグネチャを引用しない、というがマナーのはずなのですが、全文引用する人はシグネチャ部分を削ることすらしないですね。
Re:引用の罠（ややおふとぴ） (スコア:1)
# 数学は科学の女王にして奴隷
それ言われたことあるし(笑) (スコア:1)
「意見を改謬してませんか?」ってね。
「参加者全員があなたの書いた原文を読むことが出来るのだから、問題ない筈だ」
と反論したら、納得してくれましたけど。
gy0
T社とは関係ないけどうちの会社もそうだなぁ (スコア:2, 興味深い)
「それがビジネス上の習慣」だとかわけの分からない事を言い出す奴もいるし。
身近にいる人物の傾向からすると全文引用したがる人って相手が何を言いたいのかよく読まない人が多いような気がする。
引用すべきポイントを絞るという作業は相手の意思の要点を探る作業でもあるわけで、単に簡潔明瞭にするだけじゃあないんだけどなぁ。
Re:T社とは関係ないけどうちの会社もそうだなぁ (スコア:1, すばらしい洞察)
Re:元のメールを全文引用 (スコア:1)
対人口比率だったら、全文引用する文化圏の方が大きいような気もする。
引用する材料 (スコア:1)
>という文化圏が存在するらしい。
外交文書に「関しては」ごく自然なプロトコール(本来の意味)ですよね？
#元話題から逸れます。
意味不明な復号がなされた場合に利用者に判断させずに、
「破壊/攻撃などが行われた可能性があります」
と他の経路を提案することが第一になるような実装が薦められるのでしょうか。
もちろん、意味不明な復号も工夫すれば(あるいは詳しい人は)取り出せる口は用意しておく必要はあります。
利用者の裾野が広がったときに、危険度の判断ができない人を救いとるような仕組みが必要だと感じます。
#すでに私がそうなりつつあるのは、ひみつ。
Copyright (c) 2001-2014 Parsley, All rights reserved.
Re:元のメールを全文引用 (スコア:1)
> という文化圏が存在するらしい。
> 某T社の関連会社とか某T社の関連会社とか
コメント全文引用失礼。
返信元メールを全文引用することはそれなりにメリットがあります。
1) どのメールに対する返信か一目瞭然
議論を展開している場合など、似た文脈のメールの一部引用は
参照元を間違う可能性あり(Referを解釈しないメーラもある)
2) 突っ込みたい部分が一部であるときは、必要な部分に突っ込むだけですむ
前後を自分で説明しなおす必要がない
引用符をつけておけば自分と相手のコンテキストは分離可能
3) 全文読んでいるというアピール
ま、読まない人はいるけども、だ
読んでることを後で証明する一手段だね
4) 議論の経過がわかる
全文引用しておけば、2,3ステップ前のメールも含まれる
ので、わざわざ探す必要がない
とはいえ、どんな場合でも適切かと言うとそれはいえない。
ただ、ビジネスでは 3) の意味合いが強いように思える。
自分のストレージだけでなく相手のストレージにも
証拠を残しておくという意味が強いのではないかと思います。
# 逆に全文引用した相手に向かって「読んでるはずだろ」
# と、詰め寄ることも可能
ネットワークの帯域は広くなってきたし、ストレージもうなるほどある。
そんな現代だからこそ生まれた一種の富豪文化では？
別に悪いとは思わない。そういう使い方もあるというだけのこと。
# 時と場合は考えてっていうだけ
# 特に技術系MLになんかでは好まれないだろうな・・・
Re:元のメールを全文引用 (スコア:1)
引用とそれに対する返事を交互に書くという慣れた人がよく使うスタイルを、この手の区切り以降に全文写すタイプのメイラーの使用者が真似したりすると、何百行もある写しの途中に何やら書き込まれたりしていることもあったりするわけです。その手のをいくつか貰ったりしてしまったので、区切り以降にもなにかあるんじゃないかと探すようになってしまったのでした。
どれほどの手間と時間と苦痛を相手に与えることになっているのかわかって欲しいものだが…
Re:元のメールを全文引用(オフトピ) (スコア:1)
議論が続いた後に転送してもらったり，相談を受けても
経緯がわかる．その程度の利用価値ですが，それなりに．
It's not who is right, it's who is left.
Re:元のメールを全文引用(オフトピ) (スコア:1)
>>経緯がわかる．その程度の利用価値ですが，それなりに．
でも 20～30 step くらい平気で全文引用の全文引用が繰り返されたものは、
転送されてきてもちょっと読む気がなくなります。
議論の途中で発生した添付ファイルまで全て添付しっぱなしだったり。
Re:元のメールを全文引用(オフトピ) (スコア:1)
上から読むのなら楽なんだけどなぁ．．．
Re:元のメールを全文引用(オフトピ) (スコア:1)
＃要点を絞ることすらせずに「引用」などというのは、愚かさを
＃宣伝してるだけと思う。
>ACさんが触れてない 4) には若干価値があるかと．
わたしは利に比べて大きすぎる害しかないと思いますが・・・。
なんでかってーと、議論の並列性や並時性を全く無視してるから。
>議論が続いた後に転送してもらったり，相談を受けても
>経緯がわかる．その程度の利用価値ですが，それなりに．
たった一筋の議論の流れがわかったところで、かすかな意味しか
成さない気がします。
他の、ほとんど同じ時間で起こった別の流れは、こうされると
読めませんよね？
＃議論や対話は必ずしも一対一、ピンポン方式で起こるわけではない。
---- redbrick
Re:元のメールを全文引用 (スコア:0)
私の記憶が確かなら、重電五社だったらＭ、Ｓ、Ｆ、Ｈ、Ｍｅと思う。
某Ｍ社関係者ですがうちらもいっしょです、全文引用。
チェーンメールも全文引用で転送されるので、かなり笑えます。
Re:元のメールを全文引用 (スコア:1, 興味深い)
困ること、ではないですが、
極端な例では「賛成します」というのが100行の中に1行だけで
(しかも冗長な文の途中で)他全部引用ってのはどうかと。
多分引用の仕方の問題でしょう。
やり方によっては「要点が薄れる・ぼやける」場合もあります。
でも、それって一部引用の場合にもありえますね。
細切れになりすぎて意図が歪曲される場合が。
Re:元のメールを全文引用 (スコア:1)
(1)トラフィックが増えます.
(2)mailサーバのディスクを消費します.
Re:元のメールを全文引用 (スコア:1)
思うのですが・・・自分が書いた内容が帰ってく
るんでしょ？
taka4
Re:どこでお尻になりました？ (スコア:5, 参考になる)
論文ではいくつかのケースに分類して攻撃の成否を論じています。
(1) データを暗号化する前に圧縮しない場合
PGP, GnuPGとも解読可能。いずれもデフォルト設定では暗号化の前に圧縮するようになっているが、例外として、データがPGP/GnuPGに投入される前にZIP圧縮されている場合、暗号化前/復号後には圧縮/展開しないようになっており、解読が可能となる。
(2) データを圧縮する場合
平文の場合は暗号化の前にデータが圧縮される。この場合、PGPでは解読不可になる。GnuPGではデータ改変により暗号化時に圧縮していないように見せかけ、復号時に圧縮を解かないように動作させることができる。攻撃者がデータ改変を元にもどした後で圧縮を解けば、圧縮+暗号化前の元データが得られる。
※ 但し、この場合は復号時の整合性チェックにひっかかってGnuPGから警告メッセージが出るそうです。論文では警告が出ればユーザが気づいて、復号後の(壊れたように見えるデータを)攻撃者に送り返さないだろう、という展開になっていますが、警告をあやしむ心得のある人はそもそも復号後のデータがおかしかった時点で怪しんで対処するだろう、ということで、警告が出ても返信への全文引用するヒトはいるのではないか、と私は思います。
また、PGPから送られたデータをGnuPGで復号する場合にはデータの整合性チェックが行われず警告は出ないそうです。
(3) PGP, GnuPG以外の実装
OpenPGPの仕様では、圧縮しないという設定を(他の実装との互換性確保のために)実装しなければならない(MUST)としている。(PGPとGnuPGはこの点でOpenPGPの仕様に違反している)圧縮していなければ攻撃が可能なのは上のとおりであり、仕様が脆弱性を含むように書かれている。
というわけで、PGP(Network Associatesはもうメンテしないようなことを言ってましたね…)、GnuPGともデフォルト設定でも解読されうるケースがあります。と論文には書かれています。ワタシが実際に試したわけではありませんが。
Re:どこでお尻になりました？ (スコア:1, 参考になる)
Re:どこでお尻になりました？ (スコア:1, すばらしい洞察)
タコに限らず、人を育てないコミュニティーに発展はないぞ。
最新のGnuPGには効かない攻撃 (スコア:1, 参考になる)
Re:どこでお尻になりました？ (スコア:0)
> おまえみたいに知ったかぶりで使うと怪我するってこったな。
デフォルトなら怪我しないのか、それとも怪我をさせたいがためのデフォルト推奨なのか。
前者なら「参考になる+1」なんだけどね。
Re:どこでお尻になりました？ (スコア:0)
> 聞きかじっただけでしったかぶりすんなよ。
他の方も指摘されていますけど、その「しったかぶり」と言い切れる論拠を示さないと、#146054 AC さんの発言は”フレームのもと”か”余計なもの”にしか
Re:どこでお尻になりました？ (スコア:0)
こういうのがいるからOEで所かまわずHTMLメールを
送る初心者がいなくならないんだろうな…。