ID-code:6KqhrSZIyvw

こんにちわ。多分これがお初のかも…と思ったので、新規で投稿
させて頂きました。例によってSubjec意味不明文なので、タイ
トルの付けようがなく、こんなタイトルになってます。ＳＰＡＭ
ＣＯＰにほおりこんでもなんか英文で突っ返されるので、どう
したらよいのか、同じのが届いた人が、ちゃんとしたところへ
訴えてているのに任せてばかりです。すいません。フィルターを
すり抜けてしまうので、もうメルアド変えるかとも思うのですが
(管理人さんならどこのプロバか分かると思いますが)メールボッ
クスが変わらないそうなので、プロバごと変えるしかないとも
思ってます。以下が届いたものです。

Return-Path: <dm-0330＠24i.net>
Received: from rcpt-impgw.*******.ne.jp by *******.ne.jp (RCPT_GW)id AAA04843; Mon, 31 Mar 2003 00:49:55 +0900 (JST)
Received: from 24i1953.com (f185.ac123.FreeBit.NE.JP [43.244.123.185])by rcpt-impgw.*******.ne.jp (mnmy/3410050802) with SMTP id h2UFns704830for 私のメルアド>; Mon, 31 Mar 2003 00:49:55 +0900 (JST)
Message-Id: <200303301549.h2UFns704830＠rcpt-impgw.*******.ne.jp>
From: dm-0330 <dm-0330＠24i.net>
To: 私のメルアド
Reply-To: dm-0330＠24i.net
Subject: =?iso-2022-jp?q?=96=A2=8F=B3=91=F8=8DL=8D=90=81=A6=8D=A1=82=B7=82=AE=8C=BB=8B=E0=81I=81I?=
Date: Mon, 31 Mar 2003 00:49:56 +0900
MIME-Version: 1.0
Content-Type: multipart/mixed; boundary="9c221b80-7b93-4399-a0f1-f10d13e9d0fe"
X-UIDL: 799696689950435F980894345F999971805F255

当配信は送信に関する特定商表示義務法律に則り送信しています。
<送信者>
DMmaster企画社　http://dmmster.com
<事業者>
T.H.C. co. http://www.thc100.com
＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿広告＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿

業界No.1のキャッシュバック率！！！
クレジットカードを有効活用！！
キャッシング枠がなくてもショッピング枠があれば今すぐ現金化！！
急な出費！
予定外の出費！
給料日までちょっと必要！
他社への返済！
小さな借り入れ数社を一本化！
カードのリボルビング払いや分割払いを使えば月々の返済も可能！
詳しくはHPにて
http://www.thc100.com
＿＿＿＿＿＿＿＿＿＿＿＿＿広告ここまで＿＿＿＿＿＿＿＿＿＿＿＿＿
あなたのHPを格安にて宣伝致します。
業界No.1の低価格！！
http://dmmster.com
※今後このメールを受信拒否なされる場合このまま返信してください。
以後一切の配信を致しません！

特定商表示義務法律に則り送信って…うそばっかりだと思うのですが…

ID-code:RJzO1k6wm3E

> Subject: =?iso-2022-jp?q?=96=A2=8F=B3=91=F8=8DL=8D=90=81=A6=8D=A1=82=B7=82=AE=8C=BB=8B=E0=81I=81I?=

この部分をシフトJISで置き換えると
未承諾広告※今すぐ現金（（
となりますが、わざと化けるようにしているのかもしれません。

　
＃ｓａｇｅ

ID-code:UlA5wqhE/wI

タキリさん、こんにちは。
表示義務のページはこちらですね。
http://dm-master.sub.jp/torihiki.htm
yyydm＠24i.net
で連絡が取れると思いますので再度連絡を取るのは
どうでしょうか？
とりあえず「マトモ」そうな印象がありますから
アドレスを変える予定があるならチャレンジしても良いかと思います。

それでも芳しくないのならさらに突っ込んだ活動を
お願いします。関連する関係各所へ通報および抗議をまっとうな方法で
粘り強く行う事が法律を厳守しない、違法な業者を排除出来ます。

DMmaster企画社　http://dmmster.com
で書かれている内容を読めば判りますがかなり確信犯でもあるようですし
表示義務のページではまともな表示（ウソかもしれないが）がされています。
どこが確信犯？と思う人がいるとおもいますので「法律に詳しい人」がいましたら
細かい突っ込みお願いします（^^；；


会社というか組織運営を行っていくのでしょうからまっとうな方法でやっていただくか
退席頂くかのどちらかです。
タキリさんが「出来る範囲」でいいと思います。
出来ない範囲、あるいは協力を願う範囲があれば皆が協力を惜しまないでしょう。
私も出来る範囲で手伝いたいと思います。

ID-code:/q8xmlI5ru2

　ええっと、以前

> ここんとこ毎日こういったSubjectが意味不明のが届いてます。
> メールソフトは、ポストペット2001です。

と書いていらっしゃいましたが、タイトルが化けるのには
このせいもあるのではないかという気がします。

> もうメルアド変えるかとも思うのですが
> (管理人さんならどこのプロバか分かると思いますが)メールボッ
> クスが変わらないそうなので、プロバごと変えるしかないとも
> 思ってます。以下が届いたものです。

　まる氏の言うとおり、メアドを変えることを考えているくらい、
ましてやネット業者を変えることを考えているくらいなら
「受信拒否」すなわち「送信停止」メールを
発信者に出すことを勧めます。
その理由、あるいは注意点などは
ムトー氏spam対応向けに書いた内容ですが

「受信拒否と抵抗と」
http://earth.endless.ne.jp/users/stakasa/spam/tebie/sizimimomo_keyi2.html

を参考にして下さい。

ID-code:2.VnsRR1iE6

メールフォームより問い合わせたところ迅速な対応でした。

極悪スパマーではなさそうですね！？

ID-code:/q8xmlI5ru2（本記事は04/11-23:00に修正されました）

> メールフォームより問い合わせたところ迅速な対応でした。
>
> 極悪スパマーではなさそうですね！？

　この投稿ですが後に書き込まれた
http://bbs.spamstop.net/wforum.cgi?mode=allread&no=11208&page=0#11399
と同一のパソコンから投稿されております。
　上の11399に関してはムトー氏の投稿であることが
他情報から判明した結果、この10969もムトー氏あるいは
その関係者であることがほぼ確実だと思われます。

　このスパム送信にムトー氏自身が関係していると言うことは．．．
なるほど、それで

> 極悪スパマーではなさそうですね！？

こういうお言葉ですか。

　別掲示板で、ネットに対する不信感を
表明しておられたようですが
そういう行為を昨年10月から
一貫してこの掲示板でやっておられるのは
一体どなたなのでしょうね。

　いつもながら残念です。
＃ｓａｇｅ

ID-code:TTg6WE0Kn1k

> すり抜けてしまうので、もうメルアド変えるかとも思うのですが
> (管理人さんならどこのプロバか分かると思いますが)メールボッ
> クスが変わらないそうなので、プロバごと変えるしかないとも
> 思ってます。以下が届いたものです。

たぶんここで変えられますよ。手数料取られますが。
http://support.biglobe.ne.jp/jimu/mailchange.html

でもそれよりまず皆さんが言われるように「送信停止」の
メールを送られることをお勧めします。
＃ｓａｇｅ

ID-code:6KqhrSZIyvw

皆様、いろいろとアドバイス有難うございました。
題名通り、一応送信停止のメールを折り返し出してみました。
それでも来る様でしたら、家族にも事情を明かして(家族会員で
私が親会員扱いになってます)相談して、メルアド変更だけにするか
プロバごと変えるか決めようと思ってます。

…といっている側から、新たに迷惑メールが来ました。白い粉や
七福メルマガと似たようなもので、この送信会社のとは違うみたい
ですけど。

＞石頭さま
　　管理人さん以外にも、どうしてプロバイダーわかったのでしょう
　　か？？？またどこかでプロバイダーが分かる失敗したのでしょう
　　か？所詮、どんなに隠しても、分かる人には分かってしまうもの
　　なのですね。ネットをやっている以上、もう逃れられないのかな。
＃ｓａｇｅ

ID-code:u1Lvh1tSM.k（本記事は04/01-02:06に修正されました）

ブラックキャットです。

使っているプロバイダとかは、みんなヘッダにヒントがあります。
自分の所を隠してヘッダを貼り付ける理由は
スパマーに逆恨みされないためと聞いたことがあります。
スパマー対処は、スパマー側のヘッダがあればある程度は
解析が可能ですので、ヘッダを貼り付ける事で
答えがわかるわけです。
（今回のヘッダの貼り付け方はＯＫです♪）

ＩＳＰにはプロバイダ内の中継ＭＴＡが必ずありますので
そこから推測したのだと思います。
(ちなみに、rcpt-impgw.*******.ne.jpという名前は
ISP-BIGLOBEの持つ、受信用の中継ＭＴＡです。
送信用はrcpt-expgw.*******.ne.jpと記憶してます）

＊僕のセカンドプロバイダという罠もあるが（笑）
（−−−罠は、−−−というオチという意味です？）

ID-code:TTg6WE0Kn1k

> ＞石頭さま
> 　　管理人さん以外にも、どうしてプロバイダーわかったのでしょう
> 　　か？？？またどこかでプロバイダーが分かる失敗したのでしょう
> 　　か？所詮、どんなに隠しても、分かる人には分かってしまうもの
> 　　なのですね。ネットをやっている以上、もう逃れられないのかな。

分かった理由はブラックキャットさんが仰っているとおりです。
私もBIGLOBEユーザですのでヘッダを見てすぐに分かりました。
もしかして秘密でした? だとしたらすみませんでした。m(_ _)m
＃ｓａｇｅ

ID-code:VZYXNtkShLg

　「未承諾広告※今すぐ現金！！」でしたら２２日に届きましたが、
３１日には（私のところへは）届いていません。

> 訴えてているのに任せてばかりです。すいません。フィルターを
> すり抜けてしまうので、もうメルアド変えるかとも思うのですが

　このフィルターというのは、プロバイダー側で Subject が
「未承諾広告※」から始まるメールを受信しないようにしているという
意味でしょうか？

だとすれば、一般的なＢエンコーディングではないため、
フィルターをすり抜けてしまっているのだと思います。

最近この手のスパムが多いですし、お使いのプロバイダーに、
このスパムはSubject が「未承諾広告※」から始まっているらしいのに、
フィルタをすり抜けてしまう、
こういうエンコードのものにも対応して欲しい、と問い合わせしてみては？


　ま、それはそれとして、「未承諾広告※」表記のあるスパムを
フィルタリングするだけでかなりスパムが減りそうなのでしたら、
ポストペットで受信する前に他のソフトでチェックするという手も
あると思います。（面倒ですけど。）

私は使った事ないのですけど、専用のソフトとしては
http://www.forest.impress.co.jp/library/spammailkiller.html
などが有名ですかね。

> (管理人さんならどこのプロバか分かると思いますが)メールボッ

　私も同じプロバイダーを使っているので、どこなのか分かります(^^;
でも会社や大学のアドレスじゃなくて、大手プロバイダーなんですし、
そう気にする必要もないと思うのですけど。

ID-code:ZevxLkY54WY

うちにも、本日着弾しました。

うちはＩＩＪのメールを使用中ですが、フィルタの設定で、Subjectに「未承諾広告」が含まれるものを自動的に捨てているのですが、すりぬけてしまいました。
このSubjectのエンコーディングがおかしいのですね。

Subject: =?iso-2022-jp?q?=96=A2=8F=B3=91=F8=8DL=8D=90=81=A6=8D=A1=82=B7=82=AE=8C=BB=8B=E0=81I=81I?=
となっていて、メールソフトからは
未承諾広告※今すぐ現金！！
のように見えます。

うちも、ＩＩＪに「こういうエンコーディングに対応してほしい・・・」って問い合わせてみます。

それにしても、
「当配信は送信に関する特定商表示義務法律に則り送信しています。」
って、確かに、メーラーからは「未承諾広告※」にみえるけど、すり抜けを狙って変なエンコーディングをするというのも、なんだかなーって感じです。

「こちらから一方的に送りつけて不愉快になられて方、誠に申し訳ありませんｍ（_ _）ｍ」
そう思うんだったら送るなって感じ。
顔文字もよけい不愉快度を倍増させています。

ID-code:VZYXNtkShLg

> このSubjectのエンコーディングがおかしいのですね。

　おかしいといいますか、日本ではあまり使われてない方式
という事になると思います。

> Subject: =?iso-2022-jp?q?=96=A2=8F=B3=91=F8=8DL=8D=90=81=A6=8D=A1=82=B7=82=AE=8C=BB=8B=E0=81I=81I?=

　考えてみれば、とりあえずフィルタに上の文字列の
「未承諾広告※」部分を登録すれば、弾けそう。

# 面倒なんで、どこまでが「未承諾広告※」か確認するのはパス(^^;、

> って、確かに、メーラーからは「未承諾広告※」にみえるけど、すり抜けを狙って変なエンコーディングをするというのも、なんだかなーって感じです。

　いえ、おそらくすり抜けを狙っているのではなく、
単にお馬鹿な（あるいは海外製の）送信ソフトを使っているんだと思います。
というのも、ヘッダだけじゃなくて本文もＱエンコードとなっていますから。
通常は、こういう事はしません。（設定でも間違えてない限り。）

あと、Content-Type が multipart/mixed;（添付ファイル付きメールとか）と
なっているくせに、シングルパートしかないのも変。
環境によっては、本文が添付ファイルとして表示されかねないと思う。

　以前はこんなの見かけなかったのですが、
最近は急に、このタイプが増えてます(-_-メ;)
（あえて言えば小山美智子のが似てるけど、それとも少し違う。）
＃ｓａｇｅ

ID-code:Q67v8MbS60g（本記事は04/06-17:28に修正されました）

こんにちは、リンゴです。

この変なエンコーディングについての説明があります。

Quoted Printable【クォーテッド・プリンタブル】
http://www.atmarkit.co.jp/icd/root/24/5784924.html

略してQエンコーディングと呼ばれることもあるようです。（厳密には少し違うようですがほぼ同じ？）
このエンコーディング方式の特徴は日本語などの文字を=XXという形式に変換して
すべて半角英数記号（キャラクタコード）にしてしまうことです。

わざわざこのエンコーディングを使う目的はいくつかあるような気がしますが、
ひとつには海外のサーバを通りやすくする目的がありそうです。
あとは本質的にテキストであることを認識して、メーラーがテキストに戻して表示してくれることを
期待していると思われます。

また、マルチパートになっているのは、メールの形式上は添付ファイルとなっているためでしょう。


参考までに、以前、私が受け取ったものをソースのまま載せておきます。
メーラーでは添付部分が（テキストのため基本的には安全に）自動展開されるので、
表示上はマルチパートの添付ファイルを示している詳しい部分が見えなくなるようです。
（このあたりはメーラーの種類によって動作が違うと思われます。）
--------------------------------------------------------------------
Return-Path: <dm-matr333＠24i.net>
Delivered-To: xxxx＠yyyy.ne.jp
Received: from 24i1534.com (fb170120.ot.FreeBit.NE.JP [61.203.170.120])
by yyyy.ne.jp (Postfix) with SMTP id 3017817E7
for <xxxx＠yyyy.ne.jp>; Wed, 26 Mar 2003 20:05:50 +0900 (JST)
From: master-dm <dm-matr333＠24i.net>
To: xxxx＠yyyy.ne.jp
Reply-To: dm-matr333＠24i.net
Subject: =?iso-2022-jp?q?=96=A2=8F=B3=91=F8=8DL=8D=90=81=A6=8D=A1=82=B7=82=AE=8C=BB=8B=E0=81I=81I?=
Date: Wed, 26 Mar 2003 20:05:56 +0900
MIME-Version: 1.0
Content-Type: multipart/mixed; boundary="0b33956b-da71-473c-9e4c-8ea06504ede6"
Message-Id: <20030326zzzzzzzzzzz.zzzzzzzz＠yyyy.ne.jp>
X-UIDL: g>%#!E92"!MED!!Rp5!!


This is a multi-part message in MIME format

--0b33956b-da71-473c-9e4c-8ea06504ede6
Content-Type: text/plain; charset=iso-2022-jp
Content-Transfer-Encoding: quoted-printable

<=91=97=90M>
DMmaster
http://dmmster.com
=94z=90M=92=E2=8E~=82=CD=82=B1=82=CC=82=DC=82=DC=95=D4=90M=82=B5=82=C4=82=AD=
=82=BE=82=B3=82=A2

<=8E=96=8B=C6=8E=D2>
T.H.C. co.

=81=94=81=94=81=94=81=94=81=94=81=94=81=94=81=94=81=94=81=94=81=94=81=94=81=94=
=8DL=8D=90=81=94=81=94=81=94=81=94=81=94=81=94=81=94=81=94=81=94=81=94=81=94=
=81=94=81=94

=8D=A1=82=B7=82=AE=8C=BB=8B=E0=82=AA=97~=82=B5=82=A2=95=FB=81I
=83J=81[=83h=82=CD=8E=9D=82=C1=82=C4=82=E9=82=AF=82=C7=83L=83=83=83V=83=93=83=
O=98g=82=AA=82=C8=82=A2=95=FB=83V=83=87=83b=83s=83=93=83O=98g=82=C5=8C=BB=8B=
=E0=82=C9=81I
=8B}=82=C8=8Fo=94=EF=81I=8B=8B=97=BF=93=FA=82=DC=82=C5=91=AB=82=E8=82=C8=82=A2=
=81I=91=BC=8E=D0=82=D6=82=CC=8Ex=95=A5=82=A2=81I

=8F=AC=82=B3=82=C8=8E=D8=82=E8=93=FC=82=EA=82=F0=88=EA=96{=89=BB=81I=81I

=83J=81[=83h=82=CC=83=8A=83{=95=A5=82=A2=82=F0=8Eg=82=A6=82=CE=8C=8E=81X=8A=
y=82=C8=95=AA=8A=84=82=E0=89=C2=94\=81I=81I

=8F=DA=82=B5=82=AD=82=CDHP=82=C9=82=C4

http://www.thc100.com

=81=94=81=94=81=94=81=94=81=94=81=94=81=94=81=94=81=94=81=94=81=94=81=94=81=94=
=8DL=8D=90=81=94=81=94=81=94=81=94=81=94=81=94=81=94=81=94=81=94=81=94=81=94=
=81=94=81=94



--0b33956b-da71-473c-9e4c-8ea06504ede6--


--------------------------------------------------------------------
＃ｓａｇｅ

ID-code:VZYXNtkShLg

> このエンコーディング方式の特徴は日本語などの文字を=XXという形式に変換して
> すべて半角英数記号（キャラクタコード）にしてしまうことです。

　あのー、それって Base64 も一緒なんですけど…(^^;
（=XX ではないにしろ。）

　えっと、日本語のメールをやりとりする場合、
本文は iso-2022-jp とし、ヘッダはそれを Base64 エンコーディングするのが
一般的だったはずです。（まぁ、違う場合もありますけど。）

で、この場合は、ヘッダを Base64 ではなく、quoted-printable でエンコード
しているため、プロバイダーのフィルタに引っ掛からなかったという話ですよね。

> わざわざこのエンコーディングを使う目的はいくつかあるような気がしますが、
> ひとつには海外のサーバを通りやすくする目的がありそうです。

　本文を Shift_JIS とした場合はそうです。
でも普通に iso-2022-jp とすれば、問題ないような。

そういえば、某電子メール広告社のスパムは、本文が生の Shift_JIS
だったりします。途中で文字化けしている場合もあるだろうなー。
Content-Type も不親切だから、受信者側で表示できない可能性もありそうだし。

> また、マルチパートになっているのは、メールの形式上は添付ファイルとなっているためでしょう。

　ここ、意味が分からないんですが、テキスト部分が１個あるだけなのに、
ヘッダではマルチパートだと名乗っているのは、
（というより、そもそもマルチパートにしているのが）
変なメールだなーと思うだけです。

> This is a multi-part message in MIME format
>
> --0b33956b-da71-473c-9e4c-8ea06504ede6
> Content-Type: text/plain; charset=iso-2022-jp
> Content-Transfer-Encoding: quoted-printable

　一応、この部分も見ています。
でも、text/plain のパートが１個あるだけなら、
わざわざこんな事するのは変だと思うので。

# 仕様上、こういうのも正しいのかまでは、知りません(^^;
＃ｓａｇｅ

ID-code:NrppobISv22

ヘッダの各フィ−ルドの詳細が解説されているので参考にどうぞ
インターネットメールの注意点
http://www02.so-net.ne.jp/~hat/imail/cover.html
ヘッダフィールド一覧
http://www02.so-net.ne.jp/~hat/imail/xfields.html

解り易いです。
＃ｓａｇｅ

ID-code:Q67v8MbS60g

こんばんは、リンゴです。

白梟様。

> > わざわざこのエンコーディングを使う目的はいくつかあるような気がしますが、
> > ひとつには海外のサーバを通りやすくする目的がありそうです。
>
> 　本文を Shift_JIS とした場合はそうです。
> でも普通に iso-2022-jp とすれば、問題ないような。

そうなんです。確かに少し変です。
そこで、もう少し調べてみました。

以下、技術的に少々専門的な内容になります。
ご了承ください。

まず、マルチパートの部分のヘッダを見ると、

> > This is a multi-part message in MIME format
> >
> > --0b33956b-da71-473c-9e4c-8ea06504ede6
> > Content-Type: text/plain; charset=iso-2022-jp
> > Content-Transfer-Encoding: quoted-printable

となって、一見するとISO-2022-JPが使われているように見えます。
しかし、その本文を調べると、実際にはShift_JISコードで記述されていることがわかります。
ISO-2022-JPに切り替えるエスケープシーケンスが全く入っていません。
つまり、ISO-2022-JPというのは見せかけだけで、実態はShift_JISになっています。

charsetの情報を単純に信用して処理するメーラーなら文字化けしてしまいますが、
8ビットコードを自動認識かデフォルト文字コードでShift_JISとして処理する機能があれば、
ちゃんと表示できると思われます。
そしてメジャーなメーラー（OEなど）でShift_JIS自動認識がサポートされていれば、
スパマーにとって問題はないということなのでしょう。

Shift_JISでは、ほとんどの日本語文字が8ビットであるため、それを避けるために7ビットエンコーディングの
Quoted Printableが必要になるわけです。
Base64やuuencodeなどを使わない理由は、あくまでも変換元がバイナリでなくテキストとして
扱わせたいためと思われます。

これはタイトル部分についても同じです。
例えば、タイトル中のコードは
=96=A2=8F=B3=91=F8=8DL=8D=90=81=A6=8D=A1=82=B7=82=AE=8C=BB=8B=E0=81I=81I
となっていますが、これは次のように2バイトづつ全角一文字に対応しています。
（偶然、7ビットの半角英数文字になる部分は=XX形式になっていません。）

=96=A2　　未
=8F=B3　　承
=91=F8　　諾
=8DL　　　広
=8D=90　　告
=81=A6　　※
=8D=A1　　今
=82=B7　　す
=82=AE　　ぐ
=8C=BB　　現
=8B=E0　　金
=81I　　　　！
=81I　　　　！

こんなことがわかったからと言っても、何かの役に立つのかどうかわかりませんが、
とにかく、今回、文字コードの指定すらいいかげんなものであることだけはわかりました。


ありがとうございました。
＃ｓａｇｅ

ID-code:VZYXNtkShLg

> となって、一見するとISO-2022-JPが使われているように見えます。
> しかし、その本文を調べると、実際にはShift_JISコードで記述されていることがわかります。
> ISO-2022-JPに切り替えるエスケープシーケンスが全く入っていません。
> つまり、ISO-2022-JPというのは見せかけだけで、実態はShift_JISになっています。

　そう言われて確認してみると、確かに Subject・本文ともに Shift_JIS と
なっているようです。
そこまでチェックしていませんでしたm(__)m

　ついでに、色々見ている過程で見つけたのですが、
ISO-2022-JP をＱエンコーディングした場合と、
Shift_JIS をＱエンコーディングした場合では、
パッと見て区別できるほどに異なるものなのですね。
http://www.watch.impress.co.jp/Internet/www/article/980525/mojibake.htm
知らなかったので、勉強になりました。

> charsetの情報を単純に信用して処理するメーラーなら文字化けしてしまいますが、
> 8ビットコードを自動認識かデフォルト文字コードでShift_JISとして処理する機能があれば、
> ちゃんと表示できると思われます。
> そしてメジャーなメーラー（OEなど）でShift_JIS自動認識がサポートされていれば、
> スパマーにとって問題はないということなのでしょう。

　しかしこれだと、指示通り素直に解釈するメーラーだと「未承諾広告※」が
表示できないわけで、ポスペ等で上手くデコードできなかった場合や
フィルタリングに失敗した場合は、結果的に表示義務違反としての報告と
してもよさそうな…。
多くの環境では表示できるとはいえ、表示できなかった場合の非は送信者に
あるんだもの。

もっとも、デコード前の Subject と、どこが問題なのか軽く説明を
加えないと、データ通信協会や日産協の担当者の方に理解して貰えない
でしょうけど。


　それと、ポストペットでデコードに失敗したり、
プロバイダーでフィルタリングに失敗するのは、
てっきりＱエンコードに対応してないためだと思っていたのですが、
中身が Shift_JIS だとすると、他にも可能性が考えられます。

1. Subject のＱエンコードに対応してない。
2. (1) は大丈夫なんだけど、Subject 内に Shift_JIS が使われる事を想定してない。
3. (2) まで大丈夫なんだけど、Shift_JIS のＱエンコーディングを想定してない。
4. (3) まで大丈夫なんだけど、Subject の文字コード自動判別を行っていない。
5. (4) まで大丈夫なんだけど、ISO-2022-JP を自称しているため、自動判別しなかった。
＃ｓａｇｅ

ID-code:Q67v8MbS60g

こんばんは、リンゴです。

> 　ついでに、色々見ている過程で見つけたのですが、
> ISO-2022-JP をＱエンコーディングした場合と、
> Shift_JIS をＱエンコーディングした場合では、
> パッと見て区別できるほどに異なるものなのですね。
> http://www.watch.impress.co.jp/Internet/www/article/980525/mojibake.htm
> 知らなかったので、勉強になりました。

私も勉強がてら、この変なQuoted Printableを解読するツールを作ってみました。
よろしければお試しください。
http://bbs.spamstop.net/wforum.cgi?no=11417&reno=11300&oya=10963&mode=msgview&page=12


> 　しかしこれだと、指示通り素直に解釈するメーラーだと「未承諾広告※」が
> 表示できないわけで、ポスペ等で上手くデコードできなかった場合や
> フィルタリングに失敗した場合は、結果的に表示義務違反としての報告と
> してもよさそうな…。
> 多くの環境では表示できるとはいえ、表示できなかった場合の非は送信者に
> あるんだもの。
>
> もっとも、デコード前の Subject と、どこが問題なのか軽く説明を
> 加えないと、データ通信協会や日産協の担当者の方に理解して貰えない
> でしょうけど。

そうですね。法律上は「タイトルと本文で同じエンコーディングを使うこと」というくらいの
漠然とした規定しかなかったような。。。
しかし、ISO-2022-JPと宣言しておきながら、実はShift_JISを使っているわけですので、
使用文字コードを偽装しているという点では、一種の表示義務違反に該当するかもしれませんね。
ヘッダどおりの本当に正しい処理をすれば、文字化けしてしまうということですので。


> 　それと、ポストペットでデコードに失敗したり、
> プロバイダーでフィルタリングに失敗するのは、
> てっきりＱエンコードに対応してないためだと思っていたのですが、
> 中身が Shift_JIS だとすると、他にも可能性が考えられます。
>
> 1. Subject のＱエンコードに対応してない。
> 2. (1) は大丈夫なんだけど、Subject 内に Shift_JIS が使われる事を想定してない。
> 3. (2) まで大丈夫なんだけど、Shift_JIS のＱエンコーディングを想定してない。
> 4. (3) まで大丈夫なんだけど、Subject の文字コード自動判別を行っていない。
> 5. (4) まで大丈夫なんだけど、ISO-2022-JP を自称しているため、自動判別しなかった。

恐らく、そんなところでしょう。
とにかく、ヘッダ情報をあまりあてにせず、二重に変換を試みるような念入りな設計でないと
解読できないでしょうね。

ありがとうございました。
＃ｓａｇｅ

ID-code:/q8xmlI5ru2（本記事は04/08-03:37に修正されました）

> こんにちわ。多分これがお初のかも…と思ったので、新規で投稿
> させて頂きました。例によってSubjec意味不明文なので、タイ

　このスレッドの内容に関してＦＡＱに反映させました。
有意義なやり取り、有り難うございました。

Ｑ．タイトル（あるいは本文）がわけの分からない文字で書いてあり、読めないのですが。これはスパムでしょうか？
http://www2g.biglobe.ne.jp/~stakasa/spam/spam-FAQ.html#ti_buming

　なお、「プロバイダーのフィルタが効かない」との話ですが
どなたかがアドバイスしているように、分からない文字列
「96=A2=8F=B3=91=F8=8DL=8D=90」
（未承諾広告）
をフィルタリングに設定してみて下さい。

　それにより、うまくフィルタリングが出来る可能性もあります。
是非報告して下さいませ。うまく行く場合にはそれに関しても
FAQに反映させて頂きます。御協力願います。

ID-code:/q8xmlI5ru2

> Ｑ．タイトル（あるいは本文）がわけの分からない文字で書いてあり、読めないのですが。これはスパムでしょうか？
> http://www2g.biglobe.ne.jp/~stakasa/spam/spam-FAQ.html#ti_buming

　なお、上で文字化けを直すソフトを紹介していますが
Web上でそれを行うことの出来る良いツールないでしょうか？
できたらそういうサイトも紹介したいです。
（私が自分で提供するというつもりはないです）

ID-code:UlA5wqhE/wI

管理人さん、おはようございます。

> 　なお、上で文字化けを直すソフトを紹介していますが
> Web上でそれを行うことの出来る良いツールないでしょうか？
> できたらそういうサイトも紹介したいです。

ちょっと気になったので探してみました。
ちなみに秀丸なんかのエディタでも直せるようですね。（知らなかったです）

研究しているサイト
http://www.kaiteki-net.com/nettrouble/mojibake/mojibake6.html
ハングル・メール送受信支援ツール "ピョンジ" for Windows Version 2.00

http://www.seochon.net/hangul/phyeonji.htm
（これはハングルのメールの文字化けを解消、送受信するソフトのようです）

で、これが翻訳？文字化けを直すサイトですね。でも検証していませんので
該当するデータをお持ちの方はお試しして報告をお願いします。


http://www.kanzaki.com/docs/jis-recover.html

＊大事な事ですがプライバシーポリシーが書いていますので確認の上御利用ください。


ざっと探してみたのであれ？と思うところがありましたらご指摘ください。

ID-code:Q67v8MbS60g（本記事は04/12-23:28に修正されました）

こんばんは、リンゴです。

> > 　なお、上で文字化けを直すソフトを紹介していますが
> > Web上でそれを行うことの出来る良いツールないでしょうか？
> > できたらそういうサイトも紹介したいです。
〜略〜
> で、これが翻訳？文字化けを直すサイトですね。でも検証していませんので
> 該当するデータをお持ちの方はお試しして報告をお願いします。
> 
> 
> http://www.kanzaki.com/docs/jis-recover.html
> 
> ＊大事な事ですがプライバシーポリシーが書いていますので確認の上御利用ください。

まる様の紹介されたページでは普通の文字化けなら解読できそうなんですが、
問題のスパムの変なShift_JISのQuoted-Printableを解読できなさそうですね。
WWW上でも探してみたのですが、それらしいのがみつからなかったので
勉強も兼ねて自分で作ってみました。

JavaScriptとVBScriptで作りましたので、自分のPCのブラウザ上で実行できます。
ですので、プライバシーの心配（？）もありません。
インターネットエクスプローラ6.0かネットスケープ4.7で動くはずです。
IEとNCで処理が違うので、decodeボタンが２種類用意してあります。
Windows XPのIE6.0とNC4.78では動作確認しました。他の環境では動作しないこともあります。
なお、対応しているのは一応Shift_JISのQuoted-Printableだけです。
（一目見たところでは=のやたら多い文字化けです。）
ご了承下さい。

下の--8<--の間を切り取ってqdecode.htmlなどのHTMLファイル名にして保存して下さい。
なお、下記プログラムはCGIではないので、一応、ローカルファイルとしても使えますが、
サイトに掲載するなど、ご自由にお使い頂いて構いません。

使い方
　　[Test]クリックまたはinput欄にコードを貼りつけた後、
　　[NC4.7 decode]または[IE6.0 decode]をクリックしてください。
　　output欄に結果が表示されます。

--------8<--------8<--------8<--------8<--------8<--------8<--------
<html>
<head>
<title>Decode Quoted Printable</title>
<meta HTTP-EQUIV="content-type" CONTENT="text/html; charset=Shift_JIS">
<script langage="javascript">
<!--
function qdecode(src)
{
  var buf = '';
  for(var i = 0; i < src.length; ++i) {
    if(src.charAt(i) == '=') {
      if(i < src.length - 1 && src.charAt(i + 1) == '\r') {
        i += 2;
      } else if(i < src.length - 2) {
        var sch = "%" + src.substr(i + 1, 2);
        var tch = unescape(sch);
        if(sch != tch) {
          buf += sch; i += 2;
        } else {
          buf += src.charAt(i);
        }
      } else buf += src.charAt(i);
    } else if(src.charAt(i) == '%') {
      buf += escape("%");
    } else buf += src.charAt(i);
  }
  var trg = unescape(buf);
  return trg;
}
// -->
</script>
<script language="VBScript">
<!--
option explicit

private function QDecode(strEnc)
  dim strArr(), bytes(), n, i, j, k, ch, hex, bflag
  n = len(strEnc): redim strArr(n - 1), bytes(n - 1): j = 0
  for i = 1 to n step 1
    ch = mid(strEnc, i, 1): bflag = 0
    if ch = "=" then
      hex = "&H" + mid(strEnc, i + 1, 2)
      if isNumeric(hex) then
        bytes(j) = cByte(hex): j = j + 1: i = i + 2
      elseif i < n - 2 Then
        if asc(mid(strEnc, i + 1, 1)) = &H0D _
           and asc(Mid(strEnc, i + 2, 1)) = &H0A then
          i = i + 2
        else bflag = 1
        end if
      else bflag = 1
      end if
    else bflag = 1
    end if
    if bflag = 1 then bytes(j) = asc(ch): j = j + 1
  next
  k = 0
  for i = 0 to j - 1 step 1
    if bytes(i) < &H80 then
      strArr(k) = chr(bytes(i)): k = k + 1
    else
      strArr(k) = chr(bytes(i) * &H100 + bytes(i + 1) - &H10000)
      k = k + 2: i = i + 1
    end if
  next
  redim preserve strArr(k - 1)
  QDecode = join(strArr, "")
end function

private sub QDecode_onClick()
    document.dqp.trg.value = QDecode(document.dqp.src.value)
end sub
-->
</script>
</head>
<body>
<h1>Decode Quoted Printable</h1>
<form name="dqp">
input:<br>
<textarea name="src" rows="10" cols="60"></textarea><br>
<input type="button" value="Reset" onClick="javascript: document.dqp.src.value=''; true;">
<input type="button" value="Test" onClick="javascript: document.dqp.src.value='=96=A2=8F=B3=91=F8=8DL=8D=90=81=A6\n=82=A0=82=A2=82=A4=82=A6=82=A8=\n=82=A9=82=AB=82=AD=82=AF=82=B1\n=82=B3=82=B5=82=B7=82=B9=82=BB=\n=82=BD=82=BF=82=C2=82=C4=82=C6\n=82=C8=82=C9=82=CA=82=CB=82=CC'; true;">
<br>
output:<br>
<textarea name="trg" rows="10" cols="60"></textarea><br>
<input type="button" value="NC4.7 decode"
  onClick="javascript: document.dqp.trg.value=qdecode(document.dqp.src.value); true;">
<input type="button" value="IE6.0 decode" name="QDecode">
<input type="button" value="Reset" onClick="javascript: document.dqp.trg.value=''; true;">
</form>
</body>
</html>
--------8<--------8<--------8<--------8<--------8<--------8<--------
＃ｓａｇｅ