カテゴリー: Misc

Adobe Readerの脆弱性は1月から攻撃に利用されていた

Adobe Readerのセキュリティフィックスは2008/2/7にリリースされました。

http://www.adobe.com/support/security/advisories/apsa08-01.html

APSA08-01 Adobe RreaderとAcrobat8のセキュリティアップデート公開 02/07/2008

しかし、次の記事によるとこの脆弱性を利用した攻撃は1月から始まっていたとしています。

http://www.cio.com/article/182055/Attacks_Aimed_At_Adobe_Reader_Acrobat_Flaws_Intensify

In January, iDefense noticed that the malicious PDF document was being delivered through malicious banner advertisements.

この攻撃は悪意のあるバナー広告を利用し、バナーにアクセスしてPDFファイルをダウンロードし開いてしまうと、Zonebac（Symantecの名称）と呼ばれるトロイの木馬がダウンロードされるとしています。
# プラグインで自動的に開いてしまう設定のブラウザは少なくない

2006年から既知のプログラムであり、通常のアンチウィルスソフトで検出可能と思われます。トロイの木馬は実行しなければ被害は発生しないので実際に被害が発生したケースは少ないと考えられます。

追記：
整数オーバフローで任意コード実行だそうです。かなり危険度は高いと考えた方が良いようです。上記の記事では観測された攻撃はダウンローダーでダウンロードしただけだった、考えるべきでしょう。少なくともバナーをクリックしたらPDFが表示されたり、表示されかけた方は念入りにシステムをチェックするべきだと思います。もしステルス型のルートキットなら見つけるのはかなり難しいとは思います… 管理者権限で利用していなければルートキットのインストールやシステム関連設定の変更は難しいのですけどね…

ブログらしくブックマークなどに登録してもらう為のリンク追加

たいした事を書くつもりが無かったので、読んでみたいと思っていただいた方や検索エンジンから見つけて読んでいただける方だけで良い、とブックマークサービスなどに追加するボタンを付けていませんでした。時代が時代なので遅ればせながら付けてみました。
# と言っても自分自身はソーシャルブックマークサービスを利用していません。
# 問題があったら教えてください。

このブログに貼付けたボタン/リンクは、以下のサイトとURLから生成したかURLの情報を参考に作成しました。

他にこれもというサイトがあれば教えてください。リモートのJavaScriptを読み込まないサービスであれば追加したいと思います。

もっと読む

ロケール問題を修復

先日b2evolutionのアップグレードを行った際にロケールファイルの設定に漏れがあり普通に参照すると強制的にISO-8859-1への変換が行われ、????となってしまっていました。

この辺りの仕様はおかしな所もあるので、普通に動作するようパッチを書いて送る事にします。

問題をご連絡頂いた皆さん、ありがとうございました。

追記：
ついでに前から気になっていたURLも修正しました。

http://blog.ohgaki.net/index.php/yohgaki/article

といった感じでしたが

http://blog.ohgaki.net/article

でアクセスできるようにしました。もちろん前のURL形式でアクセスしてもリダイレクトで表示できるようにしています。

追記：
さらにRefererスパム防止機能のため、はてなブックマークからのリンクをクリックするとSPAM防止用ページが表示されていました。この機能を無効にしたので「はてな」からもアクセスが容易になりました。問題を教えてくださった方、ありがとうございます。

最大のP2PネットワークはThePrivateBay

The Pirate Bay Breaks 10 Million Users

10 million simultaneous users represents a number never duplicated by any file-sharing entity. The largest P2P networks, such as FastTrack and eDonkey2000, both topped out with approximately 5 million users.

1000万「同時」ユーザだそうです。これはすごい数です。基本的にはキャッシュを効かせてリバースプロキシの効果を最大限に利用して… といった感じなのだとは思います。しかし、検索機能もあり試しに検索しても遅くないです。

もう少し覗いてい見ると日本のコンテンツはあまりないようですが、海外のコンテンツは豊富なようです。また、アダルトコンテンツが公開のページには無いようでそれが人気の理由なのかな、と思います。

確か一度閉鎖されたことがあるサイトだったと思うので調べるとありました。
http://ccr2.blog9.fc2.com/blog-entry-1761.html
今はどんな状態で運用しているのでしょうね?

コンテンツの著作権をもつ方々はこのような状態にどのように対処するか思案が必要でしょう。基本的にはDRM無しで広告収入で儲ける合法的な手法を提供するのが良いと思います。無料コンテンツはビットレートが低い物、ビットレートが高い物は有償で、といった感じが良いのではないかと思います。しかし、ビットレートが高い物を有償化しても、ビットレートの高いデータその物がまた違法に公開されるので意味が無い、となってしまうかも知れません。どう折り合いをつけるか難しいですね。

エントリのコメントに評価をつけてみました

最近のb2evolutionのフィードバック（コメント）には評価を記録できるようになっているので有効にしてみました。辛口評価コメントも歓迎です。どれが役に立ったのか、立たなかったのか、などはいろいろと参考になります。

「書かない日記」の「書かない」には

• 詳しく書かない
• あまり書かない
• きちんと書かない

の3つの「書かない」の意味があるのですが酷すぎる場合はコメントを入れていただければそのエントリ分の追加は努力します。

と書いて今思い出しました。DNS Rebinding攻撃の書きかけエントリに追記するのを忘れていました…

追記：
試しに入れてみるとフィードバックとして取り扱われるのでモデレートされます。SPAM以外は全部公開しているので安心(?)してください。公開してほしくないコメントの場合、非公開で、と書いておいてください。

責任あるDM送信者はどのようにメールを送信すべきか

少し前のエントリ、宛先を個人のメールアドレスに設定しているメルマガは迷惑メールに！の続きです。DM業者はどのようにメールを送信すべきか考えました。

これから書く考えはDM送信側ではなく、DM受信側の視点から考えています。

メールの種類

まず簡単にメールを分類します。受信者から見ると

• 自分のアクションが必要な個人宛メール – 問い合わせ、確認等。
• 経緯などを知らせるだけアクションが不必要なメール – 通知、記録等。
• 情報系のメール – メルマガ、ニュース等。
• スパムメール – 勝手に送ってる迷惑メール。

に分類できると思います。

受信する側から見るとそれぞれ適切であると思われる送付先アドレス設定は次の通りでしょう。

• 自分のアクションが必要な個人宛メール – To: 個人メールアドレス
• 経緯などを知らせるだけでアクションが不必要なメール – CC: 個人メールアドレス または BCC: 個人メールアドレス
• 情報系のメール – To: MLまたは発行者のアドレス
• スパムメール – 迷惑メールなので To: 個人メールアドレス でしょう

自分のアクションが必要な個人宛メール

基本的にプライベートなメール、自分のアクションが必要なメール、必ず目を通しておきたいメールです。ショッピングサイトからのメールでも「受注確認」は確認してもし自分からの注文で無い場合は「キャンセル」というアクションが必要です。この様な場合はToに個人アドレスを設定するのは当然だと思います。

アクションの必要なメールがCC、Bcc、送信元のアドレス宛で送信されてきたら困ります。

経緯などを知らせるだけでアクションが不必要なメール

基本的にプライベートなメールです。自分に経緯を連絡するCCに個人アドレスが載っているのは当然でしょう。特にアクションは必要ないが目を通すだけは通しておいて、といった場合に使う為に用意されています。

皆さんご存知とは思いますがCCとはカーボンコピーの略です。申込書等で1枚目を書くと2枚目、3枚目に写せる紙がありますが写したコピーが「カーボンコピー」です。CCとは写しを意味します。BCCとはブラインドカーボンコピーの略です。ブラインド、つまり見えないカーボンコピーの事です。メールを送信先(To)やカーボンコピー(CC)で送信したユーザに見えない様に送信するメールアドレスを設定します。

情報系のメール

非プライベートなメールです。MLやネットショップのメルマガ、ニュースサイトのメールなどがこの分類のメールになります。これらのメールは個人宛でなく、メルマガや発行者のメールアドレス宛になっている方が受信側にとって便利です。

ネットショップやニュースサイトのメールは「送信者」からするとアクション（広告クリック、商品購入)を取ってほしいメールですが、受信者からみると単なる情報メールです。個人宛に送られてきても何か必ずアクションを取る必要があるメールではありません。

スパムメール

元々スパムなので勝手に何でもするのがスパムメールです。最も効果が高いと期待できる個人宛にメールを送信するのは当然でしょう。まっとうな事業者はスパムメールの真似をする必要はありません。

どう送信すると受信側が便利か?

To, Ccに自分のメールアドレスが設定されているメール全てが個人用のプライベートなメールだと受信者は管理が容易になります。

DMを送信する場合、受信側の立場になってアクションが必要なメールかどうか判断して、個人宛とそれ以外に区別するのが理想的だと思います。しかし、個人的な好みの問題もあるので送信先アドレスを

• 発行者のアドレス
• 受信者のアドレス

のどちらかから選べるようにすれば良いと思います。

ネットショップなどの場合でも、受注確認などのメールは個人宛、利用して頂いたお客様に対して広告メールを送信する場合は非個人宛をデフォルトとして送信すると受信者側は非常に便利です。

もし全ての事業者が上記の方法でメールを送信するような状況なれば、個人宛(To, CC)に送信されるメールは必要なメールとスパムメールだけになります。

DM送信先を非個人宛にするメリット

一昔前はメールの振り分けがよく行われてきましたが、現在では減少傾向にあるのではないかと思っています。GMailの場合、メールは振り分けでなくフィルタで検索するようになっています。フィルタは振り分けと同じような動作をします。しかし、振り分けとフィルタでは大きな違いがあります。フィルタの場合は常に受信したメール全体が検索対象になります。

GMailの様なシステムでは to: yohgaki@ohgaki.net でフィルタを作成すると個人宛のメールが全部表示されます。

個人宛のメールがバルクメール（不特定多数向けに送信されたメール）であふれると不必要なメールに「迷惑メールを報告」ボタンを押して消してしまうユーザが多数いても不思議ではありません。

DM送信先を個人宛にしなければ迷惑メールとして処理されてしまう可能性を少なくできます。

メルマガを発行者アドレス宛に送信するのは発行者に不利益があるか?

メール利用者には幾つかの段階があると思います。

1. メールを始めたばかりで振り分けなし
2. 自分宛のメールとそれ以外に振り分ける
3. 宛先、送信者、などから更に細かく振り分ける
4. 振り分け自体が面倒になり振り分けなくなる
5. メールを読むのが面倒になり以前ほど使わなくなる
6. 迷惑メール(DM含む)が多くなり別のメールアドレスに変える

これ以外に、「捨てアド」を使う、「目的別アドレス」を使う、などの道もあります。

メルマガなどのバルクメールを送信する方にとって、1の段階のユーザにはどのような送信先であっても不利益を得る事はないはずです。2と3の段階のユーザであれば個人宛にメールを送信しないことにより不利益を得る可能性があります。私は現在4の段階ですが、この状態になると個人宛のメルマガ系のメールが非常に鬱陶しいです。実際、一部のメルマガ系のメールは迷惑メールとして処理しています。

不利益となるどうかは各段階のユーザ比率とユーザのサービス利用率で決まると思われます。正直な予想を書くと、送信先を個人宛から発行者アドレス等に変更するとDM送信者がメールから得られる利益は減少すると思います。

責任ある企業としてのメール送信の仕方

普通の企業はスパマーではありません。企業の姿勢としてメール受信者（お客様）の立場に立ってメールを送信するようにしてほしいです。たとえ広告収入が主体のメールであっても、広告をクリックしてくれるユーザを単なるメール受信者として扱うのではなく、お客様として扱ってほしいです。

普通の企業が受信者の立場でメールを送っていたなら「捨てアド」などが一般化する事もなかったかも知れません。しかし、現状は残念ながら大手であっても限りなくスパムメールに近い方法、と言われても仕方ない方法でメールを送信しているケースは少なくありません。

特に大手企業には「儲かりさえすれば良い」等と考えず、お客様の利便性(と安全性)を第一に考えたWebサイトやメールの使い方をして見本を示してほしいです。

短期的に多少の不利益があっても、誰もが認めるお客様本意のサービスを行う事は長期的に企業の利益となるのではないでしょうか。

DMにぜひ付けてほしい機能

• ワンクリック購読解除リンク
• ワンクリック送信先変更リンク

システム構成にもよりますが、どちらの機能もそれほど正しく実装すれば大掛かりな仕組みは必要ありません。リクエストが本人からかハッシュでシグニチャを確認すれば良いだけです。データベースを利用する方法やクッキーを利用する方法も考えられます。もし実装したい方でどういうことか分からない場合はコメントください。

宛先を個人のメールアドレスに設定しているメルマガは迷惑メールに！

追記：
いろいろ異論がある事は分かっていながら書きましたが、ぼんやりと考えていた事は正確には伝わっていないと思います。このエントリの続きとして責任あるDM送信者はどのようにメールを送信すべきかを書きました。こちらの方が分かりやすいと思います。要はスパマーでないDM送信側は受信側にもっと配慮すべきだと考えています。その方が両方にとって利益になると考えています。
—

「迷惑メールを報告」ボタンを押させるな！
http://japan.internet.com/wmnews/20080116/7.html

によると以下が読者によって迷惑メールとして処理されてしまう代表的な原因としています。

1. 配信頻度が読者の忍耐を超えている頻度になっている
2. 内容に魅力を感じなくなり飽きている
3. 内容がミスマッチを起こしている
4. 第一印象のメルマガレイアウトが読む気をなくしている
5. 求めていないセールスプロモーションのメールである
6. 価値を感じないセールスメルマガである
7. 登録時に期待していた内容のメルマガではなかった

個人的にはTo(宛先)が自分のメールアドレスになっているメーリングリスト・メルマガが最も迷惑です。

7,8年前はメーリングリストであれば宛先にはメールリストのアドレスが記載されているのが当たり前でした。確か4,5年前くらいから宛先を個人アドレスに設定したメールリストが急増し、現在は当たり前になってしまいました。メールクライアントを使い始めたばかりのユーザでも「自分宛」、「自分にCC」、「それ以外」くらいは自動振り分けしているので、「自分宛」として送信した方が読まれる確率が高くなるのは当たり前です。

メルマガの内容など、読んでも読まなくてもよいDMと同じです。それを送り手側の勝手な意図で「個人宛」として送るのは非常に迷惑です。親展でもないのに親展とDMに書いて送っているような物です。

親展（しんてん）（英:confidential letter; private）とは、封書などにおいて、宛名となっている本人が自分で封を切って読んでほしいという意味またはそのような扱いのことである。

http://ja.wikipedia.org/wiki/%E8%A6%AA%E5%B1%95

郵便のDMもかなりの数が送られてきますが、さすがに親展でもないのに親展と書いてるDMはほとんど記憶にありません。読んだ側に「何これ?タダのDMじゃないか！」と不快に思われ逆効果だと考えているからではないでしょうか?

メーリングリスト/メルマガが個人のメールアドレス宛に送信されるのは非常に迷惑だ常々感じていました。今まで自分宛の不必要なメルマガはメールクライアントで迷惑メールとして処理させてきました。

状況を少しでも改善するために、今後Google,Yahoo,Hotmailなどの個人アドレスにメルマガを送信してきた場合は全て迷惑メールとして報告する事にします。

今や小手先のメルマガ編集方法だけでは読者の心を捕まえることができない。基本に戻ると「何が大切か」が見えてくる。

個人宛に送信するのは「小手先」テクニックの典型例だと思います。「迷惑メールを報告」ボタンを押させるな！のリストに載っていないのが残念です。

2008年急速に普及する物

年末ということで来年の予測を一つ。2008年急速に普及すると思われる物は64bit版OSだと思います。

メモリが急速に安くなってきており8GB程度のメモリが搭載できるPCであれば安価に購入できます。32bit版Windows/Linuxでは多くのメモリを搭載しても3.1GBから3.6GB程度のメモリしか利用できません。メモリを多く積んだPCを使い切るには64bit版のOSが必須になります。

普通にPCを利用するなら2GB程度のメモリがあれば困る事はほとんど無いはずです。多くのメモリを何に使うかというと仮想環境です。仮想環境などを利用する場合にはメモリを多く搭載していた方が圧倒的に有利です。仮想環境を快適に使うには最低でも3GBのメモリがあった方が良いと思います。複数の仮想環境を実行するなら8GBのメモリでも十分使い切る事ができます。

64bit版Windowsの場合、デバイスドライバの問題があるので急速に多数を占めるような事は無いと考えられますが、現在のように「誰が使っているの？」と思えるほどの少数派では無くなると思います。仮想環境のホストOSは64bit版、ゲストOSは32bit版などと使い分ける方が増えるだろうと考えています。

64bit版Linuxの場合、新たにOSを購入する必要もないので64bit版への移行はあまり敷居が高くありません。FlashPlayerさえ用意されれば移行するユーザが多くなると思います。64bit版のFlashPlayerが無い場合でもVMWare Playerで実行できる32bit版のイメージがそのままダウンロードできるディストリビューションも少なくありません。(OS丸ごとダウンロードするする場合はくれぐれも信頼できるソースのイメージをダウンロードするように注意してください）数年前であれば64bit環境への移行はあまりお勧めできる選択肢ではありませんでしたが今は十分お勧めできる状況です。Linuxユーザの場合、64bit環境への移行は簡単と言えます。
# PAEをサポートしたカーネルなら4GB以上のメモリも利用できます。
# MomongaLinuxの場合、別カーネルとして提供されていますが、
# ディストリビューションによっては自分でビルドしなければ
# ならないと思います。

Mac OSXには64bit版はありません。OSXは元々64bit OSで32bitのアプリケーションもシームレスに実行できます。OSXユーザは64bit環境に移行する必要はありません。あまり意識される事がなかったMac OSXの優れた部分ですが2008年は注目される利点として改めて紹介される事になるかも知れません。

最後にこれを機に64bit版Vistaにアップグレード方が戸惑わない為のTipsを一つ書きます。（32bit版でも同じです）VistaにはUAC（User Access Control)が追加されているので注意が必要です。 「UACを有効にしているとマトモにつかえない」と感想を持たれている方も少なくないかも知れません。これはUACによる「管理者権限で実行オプションを表示するダイアログで実行」した場合と、「本当の管理者アカウントで実行」した場合の結果が異なる事が大きな原因の一ではないかと思います。

例えば、UACで「管理者権限で実行」してもhostsファイル等の変更はそのユーザがログインしている間だけの変更され、再度ログインすればhostsファイルは元通りに復元されます。これはウィルス等がhostsファイルを改ざんし定義ファイルの更新を防ぐ事を防止する為の措置です。UACが有効な場合、WindowsディレクトリのみでなくProgram Filesディレクトリやレジストリも保護されます。UNIX系OSのユーザは管理者ユーザと別に通常ユーザを作成して通常ユーザの方を常用するアカウントとして利用すると思います。通常ユーザではセキュリティ上の理由から予想しづらい保護機能が働いて『何故？？』となってしまう事が予想されます。Vistaで管理者が行うべき作業を実行する場合は「本当の管理者アカウント」でログインして実行するようにします。

ついでにもう一つ。ドメインに参加しているPCの場合、ドメインの管理者アカウントでないと保護機能が働きます。ドメインに参加している場合、必ずドメイン管理者としてログインしてから作業しましょう。

# これらのセキュリティ機能は非常に有用だと思いますが
# Vista不人気の原因でもあるので将来無効化されそうで
# 心配です。

最後にメモリ増設で8GB積もうと考えている方は以下のURLを参考にしてください。
http://pc.watch.impress.co.jp/docs/2007/1127/hot517.htm

Internetに接続されたPCの1/3はLimeWireをインストールしている!?

eMediaWireに掲載されていたレポートによると「Internetに接続されているPCの3台に1台はLimeWireをインストールしている」としています。

File-sharing application LimeWire is now found on more than one-third of all PCs worldwide, according to research jointly published by Digital Music News and BigChampagne. The companies surveyed more than 1.5 million systems for this report.

http://www.emediawire.com/releases/2007/12/emw576418.htm

米国だけの話かと思ったのですが

one-third of all PCs worldwide

LimeWire was found on 36.4% of all PCs, a figure gleaned from a global canvass of roughly 1.66 million desktops.

と世界中の166万台のPCが対象だそうです。少なくとも日本国内のPCでLimeWireがインストールされているPCは非常に少ないと思います。

米国で1/3ならまだしも、世界中で1/3のPCにLimeWireがインストールされている、とするのは少々大げさな気がします。母集団にかなりの偏りがあるのではないかと思います。母集団の偏りは別にしても166万台のうちの60万台ほどのPCにLimeWireがインストールされていたのが事実だとすると驚きです。

米国ではP2P問題は基本的に著作権問題としてして取り扱われ、音楽ファイル等を公開していた個人に対して数千万円の損害賠償請求を認める判決もでています。アメリカの議会ではP2Pネットワークによるファイル共有が国防上の問題として取り上げられていたりします。

一方日本では暴露ウィルスによるファイル流出だけが大きな問題とされ、本質的な問題の議論や理解が進んでいないように感じます。

プログラムのセキュリティ対策と同じで情報を発信する側と受け取る側、両方に効果的な対策が必要だと思います。現在受け取る側の規制としてファイルをダウンロード行為自体を違法とするか議論がされていますが、それよりもまず違法なコンテンツを発信する側に高額な損害賠償金を請求可能にするなどの措置が先に行われるべきだと思います。

参考：
http://arstechnica.com/news.ars/post/20071227-one-third-of-pcs-prefer-limewire.html
http://ja.wikipedia.org/wiki/LimeWire

さすがに1/3と言うのは大げさ過ぎると思い昨年末に書いたこのエントリはお蔵入していました。別の統計を見つけたので公開しました。

http://internet.watch.impress.co.jp/cda/news/2008/01/23/18207.html
これによると

これに対してGnutella互換サーバントは世界的に多く分布しており、中でも米国が約175万ノードで49％を占める。ヨーロッパ各国も約23％と多かった。日本でも約10万9,000ノードあった。

となっています。米国でもたった175万ノードなら「1/3のPCにLimeWireがインストールされている」のは大げさな数値になります。母集団に問題、例えば大学生のPCだけ調べた等、であれば納得できるかも知れない数値ではありますが…

追記

最大のP2PネットワークはThePrivateBayだそうです。

このブログのIE6でのレイアウトの崩れを修正

一応IE6/IE7でこのブログを自分で見た事があるのですがオーバーフローが発生した場合のページを見ていませんでした。b2evolutionに付属してきたevopressテンプレートのスタイルシートをそのまま使用しているのですがIE6でIE6/Firefox/Opera等と同等に表示するためにblockquoteのCSS定義に

width: 400px;
overflow: hidden;

追加しました。IE6の方は一つ前のエントリなどは非常に読みづらかったと思います…
# 今使っているのは2.2.0Beta版なので多少の不具合は仕方ないです。

時間があれば自分でスタイルシートを確認したいところですが当分その時間がとれそうにないです。問題があったらぜひ教えてください。下のContactリンクからWebフォームから送信できます。

SquirrelMailパッケージの改竄はやはり攻撃目的

前のエントリで改竄は大きなセキュリティ上の問題ではない旨説明がされている、と紹介しましたが新リリースのアナウンス部分に新しい情報が追加されていました。

http://www.squirrelmail.org/index.php

Due to the package compromise of 1.4.11, and 1.4.12, we are forced to release 1.4.13 to ensure no confusions. While initial review didn’t uncover a need for concern, several proof of concepts show that the package alterations introduce a high risk security issue, allowing remote inclusion of files. These changes would allow a remote user the ability to execute exploit code on a victim machine, without any user interaction on the victim’s server. This could grant the attacker the ability to deploy further code on the victim’s server.

リモートファイルインクルードが可能になっていたらしいです。1.4.11は9月末にリリースされたパッケージなのでかなりの期間、危険なパッケージが公開されていた可能性があります。

利用されている方はバージョンアップしておいた方がよいと思います。また影響範囲が分からないので新しいバージョンがリリースされた場合に直ぐにアップデートできるよう準備する方がよいでしょう。

SquirrelMailのサイトでは前のニュースで影響が少ないとしていた部分は、追記として危険な問題がある事を明記しておかないと勘違いするユーザも少なからず発生するような気がします…

日本仕様のメールアドレス…

言いたいことのほとんどが書いてある素晴らしいブログ記事です。

ドコモもauもいいかげんにメールアドレス設定の仕様を直せ。
http://neta.ywcafe.net/000799.html

ドコモもauもいいかげんにメールアドレス設定の仕様を直せ。の続きと補足
http://neta.ywcafe.net/000803.html

AuはMNPを機会にDoCoMoの独自仕様メールアドレスと同じにしたと記憶しています。いい加減にしてほしい、と強く感じたのでよく覚えています。KDDIに至ってはDion等でも他のメールサーバやクライアントで受信できないメールアドレスを作成できるようにしているようです。まさに嘘を隠すためにまた嘘をついている状態です… しばらくすれば事態は良くなると思っていたのですが悪くなっているようです…

ルールを守りたくないなら中国のように独自TLDでも作って（そういった計画があったと聞いていますがその後どうなったかは不明）その中でやれば良いでしょう。ユニバーサルに使えない自爆メールアドレスを作ってしまうのはエンドユーザの問題ではなく、サービス提供者の姿勢の問題だと思います。

いくら技術が分からない人間でも「他のキャリアの電話をかけようとした時に電話できなかったら困りますよね?同じよう他のメールサーバ宛にメール送信しようとしたときにメールが送信ができなかったら困りますよね?」といった単純な議論も通用し無いのでしょうか? すでに作ってしまったメールアドレスを強制的に変えるのは難しくても、新しいアドレスは標準に則ったアドレスのみ許可するのは簡単です…

RFCが絶対か、というとRFC通りに作ると動かなくなるものもあるのでそこは適当に対処しなければならない場合もあります。しかし、わざわざ動かなくなる（メールの送受信に問題発生する可能性がある）メールアドレスを作れるようにするのは責任ある企業として適当な対応とは言えないと思います。