V5.06β16 - 秀丸メール・バグ関係 - スレッド01437, 2008/06/13

秀まるお さん　08/06/13 16:29

　V5.06β16をアップロードしました。

　メールの発信元の国を調べるコマンドを追加しました。迷惑メールの発信元を
調べると結構楽しいかもしれません。

http://www.hidemaru.interlink.or.jp/software/bin2/hmmail506b16_signed.exe

RE:01437 V5.06β16

三月さん　08/06/13 19:20

>
>　メールの発信元の国を調べるコマンドを追加しました。迷惑メールの発信元を
>調べると結構楽しいかもしれません。
>

全般的な設定のメール一覧の右ボタンメニューにもほしいですね

プロバイダからのメールにはReceived: がないために
1 ?? (エラー)
になるんですね。

RE:01438 V5.06β16

秀まるお さん　08/06/13 21:40

　ちなみにメールが１通だけの時は、Alt+Enterでメールのプロパティを見ても
らうと、そこに発信元も表示されます。

　右ボタンメニューに出す機能も追加しようと思いますが、デフォルトではその
コマンドは出さないようにしようと思います。

> プロバイダからのメールにはReceived: がないために

　Received:ヘッダが無いメールもあるのですか。その場合はどうしようもない
です。

　あと、ローカルIPアドレス（192.168.XXX.XXXとか）を示すReceived:ヘッダし
か無い場合もエラーになってしまいます。

RE:01439 V5.06β16

EA11R2 さん　08/06/13 22:06

EA11R＠一般ユーザです。

珍しく要望です。

> 　ちなみにメールが１通だけの時は、Alt+Enterでメールのプロパティを見ても
> らうと、そこに発信元も表示されます。
>
> 　右ボタンメニューに出す機能も追加しようと思いますが、デフォルトではその
> コマンドは出さないようにしようと思います。
関連するちょっとした要望なんですが、「ヘッダに追加する」って機能をつけて
もらうのは無理でしょうか。
もちろん、IPアドレスのマッチングテーブルに英略字とかの国名が入っている、
とか、マッチングテーブルの新設が不要であれば、で構わないんですけど…。

例えば、デンマーク発信のメールは信用できない、中国発信のメールは…って時
に、振り分け条件で一括して抹殺できますし。
簡易ヘッダに追加でメール本文と一緒に表示できたり、特定ヘッダ表示で指定す
ればメール一覧に出せたりもできますし。

実装のためのコストと実現内容のバランスが悪いから却下、でも構いませんので、
ご一考していただければ…と。

では、失礼します。

RE:01437 V5.06β16

kahara さん　08/06/13 22:49

kahara　と申します。

いくつか迷惑メールで検証してみましたが、ここで国判定している
ヘッダは、一番最初に付加されたと思われるRecievedヘッダでしょ
うか？

今でも、余計なRecievedヘッダをあらかじめ付加して送ってくるも
のも多く、受信側サーバで一番最初に付加したRecievedヘッダのIP
アドレスで判定しないと誤判定になると思われます。

当方で逆引きを行う際は、そのアカウント毎にどの位置のIPアドレ
スを見るかを変えています。（プロバイダごとに、Recievedヘッダ
のつけ方が異なるため）

この点を含めて、以下をお願いしたいと思います。

・いくつ目のRecievedヘッダを見るかアカウントごとに指定可能と
　する（１～４程度）
　なお、アカウントごとに受信サーバが最初に付けたヘッダを自動
　識別していただけるのであれば、不要となります。
・国別判定を受信時に全部実行可能とする（オプション）
・国別判定結果を拡張ヘッダに記述可能とする（オプション）
　　これは、EA11Rさんと同じものです。

RE:01437 V5.06β16

siniti さん　08/06/14 16:59

>　メールの発信元の国を調べるコマンドを追加しました。迷惑メールの発信元を調
>べると結構楽しいかもしれません。

この機能って楽しめますね。

RE:01437 V5.06β16

おひさん　08/06/14 22:48

おひと申します．
いつもお世話になっております．

表示範囲の対象として，メールアドレス検索(固定値)を使っていますが，
発信元の国識別に変わってしまいました．

β15に戻したら，戻りました．(ので個人的にはセーフ)

RE:01437 V5.06β16

おひさん　08/06/14 22:54

おひと申します．
いつもお世話になっております．

連発でスイマセン．

メールアドレス検索で結果表示後，
検索 -> 検索やり直しすると「find.cpp(3796) error = 1814」
というエラー画面がでます．

# dump.txt 送らなくてスイマセン．再起動はしました．

RE:01437 発信元の国識別の弊害?

Iranoan さん　08/06/15 17:12

　秀まるおさん今日は、Iranoan です。
> メールの発信元の国を調べる
　この発信元の国識別機能の追加で、検索時のコンボ・ボックスにおいて
「(メールアドレス検索)」「(Message-ID 検索)」の順番が変わっています。
変わっているだけなら良いのですが、「全般的な設定」→「メール一覧」→
「表示範囲」の「メール一覧の表示範囲、カスタム設定一覧」で「(メールア
ドレス検索)」「(Message-ID 検索)」で設定していた場合、設定がずれていま
す。つまり、「(メールアドレス検索)」にしていたのが、「発信元の国識別」
になっています。

RE:01445 発信元の国識別の弊害?

秀まるお さん　08/06/15 20:33

　検索条件式での「target=person」が国識別対象で検索してしまうようになっ
てしまったようです。

　レジストリ上の内部的な値は以前と同じ値で互換性を保つようにしてたんです
が、検索条件式の処理をまったく忘れてました。ということでさっそく修正させ
ていただきます。

　おひさんから報告いただいたのも同じ原因だと思います。そっちも再現テスト
などしてみます。

RE:01441 V5.06β16

秀まるお さん　08/06/15 20:41

　Received:ヘッダの調べ方ですが、一番後ろにあるヘッダから順番に調べてい
くような形になってます。

　１．Received:ヘッダの中に「by」があるかどうか見て、無ければ
　　　そのReceived:ヘッダは無視する。
　２．「by」があるとしたら、それよりも前の文字列について後方から
　　　スキャンしていって、

　　　　　[nnn.nnn.nnn.nnn]

　　　または

　　　　　(nnn.nnn.nnn.nnn)

　　　のようなIPアドレスと思わしき物があればそれを取り出す。無ければ
　　　そのReceived:ヘッダは無視する。

　３．IPアドレスがローカル用のアドレス（192.168.xxx.xxxとか）かどうか
　　　調べて、ローカル用ならそのReceived:ヘッダは無視する。

　ってな具合で順番にReceived:ヘッダをスキャンしていきます。

　国識別が特定出来なくても、ローカルIPアドレスでなければそこでスキャンは
終了します。

　これはこれで一応、いろいろ迷惑メールも含んだメールを調べて決めた処理な
んで、これで適当かと思います。

　Received:ヘッダを偽装して、例えば本当は中国から発信してるのに日本から
発信してるように偽装してるようなメールってのは、少なくとも僕は見つけられ
なかったし、仮にそういうのがあったとしても偽装を見破ることは不可能かなぁ
と思います。

> この点を含めて、以下をお願いしたいと思います。

　具体的にReceived:ヘッダを偽装している例とか、特定プロバイダでの
Received:ヘッダの正しい抽出方法の例とか現状の処理で失敗する例とか、いく
つかサンプルが収集出来た段階なら対応してもいいですけど、今の段階で何もサ
ンプルも無くて具体的にどれが正しくてどれが間違いなのかも分からないで処理
を作り込むことは出来ないと思います。

RE:01446 発信元の国識別の弊害?

Iranoan さん　08/06/15 21:48

　秀まるおさん今日は、Iranoan です。
> 　レジストリ上の内部的な値は以前と同じ値で互換性を保つようにしてたんです
> が、検索条件式の処理をまったく忘れてました。ということでさっそく修正させ
> ていただきます。
　よろしくお願いします。

RE:01447 V5.06β16

kahara さん　08/06/16 00:30

kaharaと申します。

サンプルメールを以下宛にお送りします。
maruo@mitene.or.jp

※　追加偽装とは以下のようなものを言っています。

受信サーバが１個のヘッダしか付与しない時、通常であれば

例．１
　①Received:　(nnn.nnn.nnn.nnn)or[nnn.nnn.nnn.nnn]

ここの、[nnn.nnn.nnn.nnn]を見ることで何の問題もありま
せん。

で、スパマーさんによっては、あらかじめReceived:ヘッダ
を付与する場合があり、その時は、

例．２
　①Received:　(nnn.nnn.nnn.nnn)or[nnn.nnn.nnn.nnn]
　②Received:　(mmm.mmmm.mmm.mmm)or[mmm.mmm.mmm.mmm]

となっったものを秀丸メールが受信するため、②のＩＰアド
レスから国別判定すると、意味がなくなってしまうわけです。

Received:の偽装（というか追加）は、送信側であれば勝手
に出来るものでありますが、受信サーバが付与するＩＰアド
レスは偽装出来ないので、この例であれば常に①を調べる
必要があります。

実際にリレーサーバーを経由している可能性もありますが、
今の時代では、そのようなリレーサーバの存在すらまとも
とは見ず、受信サーバに送りつけてきたサーバで判断する、
ということが大勢となっています。

RE:01449 V5.06β16

アルビレオ さん　08/06/16 01:14

ユーザーのアルビレオです。

>Received:の偽装（というか追加）は、送信側であれば勝手
>に出来るものでありますが、受信サーバが付与するＩＰアド
>レスは偽装出来ないので、この例であれば常に①を調べる
>必要があります。
>
>実際にリレーサーバーを経由している可能性もありますが、
>今の時代では、そのようなリレーサーバの存在すらまとも
>とは見ず、受信サーバに送りつけてきたサーバで判断する、
>ということが大勢となっています。

このフォーラムの投稿内容をメール受信する設定にしているのですが、
Received:ヘッダが４つあります。

Received: from vmta111.odn.ne.jp by cmta111.odn.ne.jp with ESMTP ...
Received: from emta111.odn.ne.jp by vmta111.odn.ne.jp with ESMTP ...
Received: from maruo.co.jp ([xxx.xxx.xxx.xxx] [xxx.xxx.xxx.xxx]) ...
Received: from www [127.0.0.1] by maruo.co.jp ...

どうやら受信したISP内でリレーが行われることがあるようです。

Received:の記述形式はメールサーバによってバラバラなこともあって、プログ
ラムによって偽装を見抜くのはほぼ不可能だと思います。
元々それほど信頼できないものと割り切った方がいいんじゃないかと。偽装を見
抜けないことで何か具体的な弊害が出る訳でもないですし。

RE:01450 V5.06β16

kahara さん　08/06/16 07:57

kaharaと申します。

>このフォーラムの投稿内容をメール受信する設定にしているのですが、
>Received:ヘッダが４つあります。
>
>Received: from vmta111.odn.ne.jp by cmta111.odn.ne.jp with ESMTP ...
>Received: from emta111.odn.ne.jp by vmta111.odn.ne.jp with ESMTP ...
>Received: from maruo.co.jp ([xxx.xxx.xxx.xxx] [xxx.xxx.xxx.xxx]) ...
>Received: from www [127.0.0.1] by maruo.co.jp ...

この例では、ODNは常に３つのヘッダを付与しているものと
思われます。

４つ目は、このＭＬのシステムで付加しているようですから
恐らく他のまともなメールには、上の３つのヘッダだけが付
いてきているはずです。

従って、odnの場合でしたら、常に上から３つ目のヘッダ内
のＩＰアドレスで判断すれば良い、となります。

>どうやら受信したISP内でリレーが行われることがあるようです。
>
>Received:の記述形式はメールサーバによってバラバラなこともあって、プログ
>ラムによって偽装を見抜くのはほぼ不可能だと思います。

受信サーバで付与されるヘッダ内のＩＰアドレスに世の中
共通的なもの（127/8, 192.168/16）しかなければ簡単なの
ですが、そうでないＩＰアドレスを含むものもあるので、
非常に大変でしょう。

ただし、サーバごとにほぼ固定（※）されているので、た
とえば、odnユーザであれば、”常に上から３つ目のヘッダ”
を見ればいいので、簡単といえば簡単なのです。

　※　プロバイダのシステム構成の変更に伴って、１つ増え
　　　たところがあり、数日間は前のと増えたのが混在して
　　　いました。

>元々それほど信頼できないものと割り切った方がいいんじゃないかと。偽装を見
>抜けないことで何か具体的な弊害が出る訳でもないですし。

おっしゃるとおりかもしれません。
まあ、雰囲気を見る程度と考えれば、今のままでも良い
のかもしれません。

RE:01440 V5.06β16

秀まるお さん　08/06/16 10:31

　ヘッダに追加する機能は、では「全般的な設定・上級者向け・デコード」に追
加しようと思います。

X-TuruKame-SenterCountry: JP

　みたいなヘッダを追加しようかと思います。

　ちなみに迷惑メールフィルターの方にも実は国識別をする用のワード指定があ
るにはあります。

++!cnjp ... 発信国が日本以外
++!casa ... 発信国が日本以外のアジア
++!c=XXYYZZ... ... 発信国がXXまたはYYまたはZZ...
++!c!XXYYZZ... ... 発信国がXXでもYYでもZZでもない

　の４種類あります。「!c=」と「!c!」についてはまだ仕様変更するかもしれな
いのでヘルプには書いてありませんけど。

RE:01451 V5.06β16

秀まるお さん　08/06/16 11:39

　添付ファイルで送っていただいたメールですが、これを僕が見た限りでは、
Received:ヘッダを偽装しているメールというのは無いと思います。

　たぶんkarahaさんが「偽装されてる」と解釈されてる物は、実際の発信元から
一度中国を経由されてるメールではないかと思います。主に「Coremail」という
やつがばらまいてるやつだと思いますけど。

　これはこれで、たしかにCoremailに乗っ取られたパソコンはそこ（アメリカや
日本）にあって、そこから発信されてるはずなので、Received:ヘッダの解釈と
してはそれで合ってるのかなぁと思います。

　あと、

Received: from localhost ...

　みたいなのも、これも偽装してる訳じゃなくて本当にlocalhost上にsmtpサー
バーが動作していて、それを経由して発信されてるメールであって、そういうの
は現状の秀丸メールでうまく解釈出来ています。

　Received:ヘッダの解釈的には、今のところ僕が見た感じでは、僕の現状の処
理の方で間違いないと思いますけど。迷惑メールをうまく判定させるためという
意味では、メールがどこを経由してるかも見て、例えば中国を経由してるならそ
れはそれで迷惑メールと判定すべきという話もあるかと思います。それをやると
したら、「発信元の国」ってことで１つの国を特定するんじゃなくて、「発信元
および中継した国」ってことで複数の国識別を返す仕組みを作って、それで判定
させるのがいいかもしれないです。

　とりあえず、Received:ヘッダに"(Coremail)"を含んでいたら迷惑メール扱い
してしまう作戦を入れてしまうといいようですけど。

RE:01451 V5.06β16

秀まるお さん　08/06/16 11:44

　あとあと、迷惑メール判定という意味では、送っていただいたメールのうち迷
惑メール判定されなかったのは１通だけでした。

　その１通は、中国発のメールでした。出会い系のメールのようです。

　なので、それについては

「会え+待って+http:++!body<999++!cnjp」

　みたいな迷惑ワードを標準で追加して、それで対応しようと思います。

RE:01453 V5.06β16

たまちゃん さん　08/06/16 11:52

>「発信元の国」ってことで１つの国を特定するんじゃなくて、「発信元
>および中継した国」ってことで複数の国識別を返す仕組みを作って、それで判定
>させるのがいいかもしれないです。

迷惑メール判定プログラム（メールソフトを仲介するいわゆるプロキシ型のもの）の
中には，DNSBLを参照するものがあります。

その中には発信元だけではなく，途中経路に怪しいアドレスがあれば「クロ」の判定
をつけるものもあります。

随分以前に紹介した SpamPal というプログラム

http://www.spampal.org/

がそうで，「クロ」の判定をどう処理するかはユーザに任されています。秀丸メール
のユーザの山田さんが日本語のページをまとめられています。

http://homepage3.nifty.com/yamada_ken1/starthp/subspampal.html

RE:01453 V5.06β16

kahara さん　08/06/16 21:25

kaharaと申します。

>　添付ファイルで送っていただいたメールですが、これを僕が見た限りでは、
>Received:ヘッダを偽装しているメールというのは無いと思います。
>
>　たぶんkarahaさんが「偽装されてる」と解釈されてる物は、実際の発信元から
>一度中国を経由されてるメールではないかと思います。主に「Coremail」という
>やつがばらまいてるやつだと思いますけど。
>
>　これはこれで、たしかにCoremailに乗っ取られたパソコンはそこ（アメリカや
>日本）にあって、そこから発信されてるはずなので、Received:ヘッダの解釈と
>してはそれで合ってるのかなぁと思います。

添付したメールで、Received:ヘッダの２つ目があるものについては
以下の２つの解釈が成り立ちますが、判定不可能なので、残念ながら
「合っている」とは言えないのです。
①１つ目のサーバを経由してきた
②１つ目のサーバが、最初のヘッダをあらかじめ付与してリレーした
　ようにみせかけた（偽装）

この②はスパマー側の古典的なかく乱手法として有名です。

また、迷惑メールを（商売的に）リレーさせるようなサーバが、まと
もな（＝本当の送信元が分かるような）ヘッダを付与する確率は、非
常に低いと思います。

多少話がそれますが、怪しい送信サーバをブロックするような場合、
仮に①のようなオープンリレーであっても止めてしまおう、というの
が、今流です。

RE:01453 V5.06β16

kahara さん　08/06/16 21:52

kaharaと申します。

話の方向がずれますので、２つに分けました。

>　添付ファイルで送っていただいたメールですが、これを僕が見た限りでは、
>Received:ヘッダを偽装しているメールというのは無いと思います。
>
>　たぶんkarahaさんが「偽装されてる」と解釈されてる物は、実際の発信元から
>一度中国を経由されてるメールではないかと思います。主に「Coremail」という
>やつがばらまいてるやつだと思いますけど。
>
>　これはこれで、たしかにCoremailに乗っ取られたパソコンはそこ（アメリカや
>日本）にあって、そこから発信されてるはずなので、Received:ヘッダの解釈と
>してはそれで合ってるのかなぁと思います。

アメリカや日本の一般ユーザのＰＣを乗っ取って、ボットネットを
構築して自分の配下にある中国のサーバ経由で送っている、などと
思っているようでしたら、大間違いです。

たしかに、ボットネットは一般のＰＣを乗っ取りますが、今までの
例では、そのＰＣを送信サーバ化して直接送って来ますし、それら
のＰＣを制御するサーバは、ボット運営者にとって生命線ですから
非常にたくみに隠しています。
一般的にはＩＲＣサーバといわれていますし、メールサーバでは
ありえません。

このようなヘッダが詐称されていないということは、実際にアメリ
カや日本から送っていて、しかも、わざわざ中継サーバを経由させ
ているわけですが、わざわざ中継させる意味も必要性もないため、
そのような実態はまずないでしょう。
（中継サーバを皆がブロックしたらおしまいになるだけ）

実際に中継させるとしたら、そこでヘッダをごまかして、本当の発
信元を詐称するくらいしか考えられないのですが、この場合には、
実際の発信元は分かりません。

”あくまで迷惑メールに関する限り”、受信サーバから見て１個前
のReceived:ヘッダについては、
①実際に中継されていて、ヘッダ付与そのものが詐称されていない
　としても、その中の情報である一つ前のサーバ情報は、限りなく
　詐称されている。
②実際には中継などされておらず、ヘッダ付与そのものが詐称付与
　されている。
と考えるのが妥当です。

従って、迷惑メールにおいては、現在の仕様で、受信側サーバ以外
が付与したヘッダから発信国を調べることは、ほとんど意味が無い
と言わざるを得ません。

ただ、最近の迷惑メールでは、このようなヘッダ付与がそれほど
多くないようなので、そうしたメールに対しては、バッチリです。

RE:01458 V5.06β16

kahara さん　08/06/16 22:54

kaharaと申します。

今回の送信元国識別を、無意識のうちに迷惑メール対策と捉えて
熱くなってしまい、申し訳ありませんでした。
（特定アカウント以外では、国外からの日本語メールなんて受け
　る必要ないので、こういった機能がメールソフト側で実装され
　そうな感激のあまり）

普通のメールの発信国識別にも使えるわけですし、その意味で、
迷惑メールの判定における多少の誤差も許容範囲でしょうし、
現状仕様のままで結構です。

いろいろお騒がせしました。

RE:01459 V5.06β16

秀まるお さん　08/06/16 23:07

　なんだか僕もよく分かってないので、とりあえず経験的にというか、迷惑メー
ル判定精度的に有益ならヨシってことで、今のまま様子見させていただくことに
します。

RE:01455 V5.06β16

秀まるお さん　08/06/16 23:11

　すでにそういうソフトがあるということで…。

　とりあえず僕的には現状の「++!cnjp」、つまり「発信元が日本以外である」
という条件を使えるだけでも今まではじけなかったメールがかなり多くヒットさ
せられるようになったので、それでヨシとさせていただいて、しばらく様子見と
いうか、またそれで迷惑判定出来ないメールがあるようならまた対策を考えるっ
て作戦にさせていただこうと思います。

RE:01460 V5.06β16

kahara さん　08/06/16 23:19

kaharaと申します。

了解しました。
現時点では、迷惑メール対策とは捉えないよにします。