スパムメールのヘッダーでわからな い部分があります

[hanajipon]

こんにちは。
sendmail-8.11.6-11.1 を使ってメールサーバを運営してます。
ユーザから「誰にも公開していない、作ったばかりのメアドにスパムが届いた」と報
告を受けました。

スパムの内容は
> 蒲生4丁目広告
> ☆激安 ! ! ! ソフトの総合商社　そふとはうす
> ☆在宅ＰＣビジネスのご案内
>
> ■　ソフトの総合商社　そふとはうす　■
> Ｗｉｎｄｏｗｓ日本語製品版です。Ｍａｃもあります。 単位はす
べ
））））以下、省略（（（（

というやつで日本語です。（コピーソフトを売りつけるな！）
同様のメールは私のメアドにも届いていたのですが、「スパムだから削除だな」で、
あまり気にして
いませんでしたσ(^_^;)

しかし、今回の件を受けて、ヘッダーを見ていると
わからない部分があったので教えてください。
（都合上、ドメイン、アカウント名を架空のものとします）

・私のメアドは f...@hoge.jp である。とする。

ヘッダーは以下のようになっています
Return-Path: <f54xx...@hotmail.com>
TO: null...@hoge.jp
From: "a" null...@hoge.jp

null...@hoge.jp は実在しません。Return-Pathのメアドは一部、伏字にしていま
す。

・Fromは詐称されているのは理解できます。実際の送信者は
f54xx...@hotmail.com ですか？
・To は実在しないアカウントなのに、何故、私に届いたのでしょうか？

以上、ご教示のほど、お願いします。

---
hanajipon @ mail.goo.ne.jp

[Hiroki Kashiwazaki]

柏崎＠北海道です。

# メアドという言葉を使う人は、アイタタな人間として見えてしまう。
# ホムペとかフォトショとかイラレとかも…

At Wed, 17 Mar 2004 11:10:44 +0900,
hanajipon wrote:

> ・To は実在しないアカウントなのに、何故、私に届いたのでしょうか？

Bcc に f...@hoge.jp が指定されていたに一票。

--
柏崎 礼生 (Hiroki Kashiwazaki)@HUIIC
Ph.D candidate in the Division of Electronics & Information
Engineering, Hokkaido University
mailto:r...@cc.hokudai.ac.jp
Tel:+81-11-706-2998

[MAEDA Atusi]

"hanajipon" <hana...@mail.goo.ne.jp> writes:

> ・Fromは詐称されているのは理解できます。実際の送信者は
> f54xx...@hotmail.com ですか？

とは限りません。Return-Path: には、SMTPプロトコルでの「発信者」情報(エ
ンベロープFROMアドレス)が記録されますが、これは送信者が自由に設定でき
る情報です。詐称は簡単です。

> ・To は実在しないアカウントなのに、何故、私に届いたのでしょうか？

インターネットでのメイルは、SMTPプロトコルでの「受信者」(エンベロープ
TO)に指定されたメイルボックスに届きます。メイルのTo:, Cc:, Bcc: などの
ヘッダはSMTPでの配送先と直接の関係はありません。(メイル送信ソフトがこ
れらのヘッダからエンベロープTOを作る可能性はあります。配送時にはこれら
は「封筒の中身」扱いであり、転送ソフトは見ません。)

前田敦司

[Hideo Sir MaNMOS Morishita]

In article <c38c35$aj8$1...@nn-os102.ocn.ad.jp>,
"hanajipon" <hana...@mail.goo.ne.jp> writes:
> ・To は実在しないアカウントなのに、何故、私に届いたのでしょうか？

MTUはToなんぞ見てませんもん。
SMTPのRCTPで設定されたアドレスに飛ぶだけです。

--
___ わしは、山吹色のかすてーらが大好きでのぅ
[[o o]] ふぉっふぉっふぉ
'J' 森下 お代官様 ＭａＮＭＯＳ 英夫＠ステラクラフト
PGP Finger = CD EA D5 A8 AD B2 FE 7D 02 74 87 52 7C B7 39 37

[Tetsu]

On Wed, 17 Mar 2004 11:10:44 +0900
"hanajipon" <hana...@mail.goo.ne.jp> wrote:

> ヘッダーは以下のようになっています
> Return-Path: <f54xx...@hotmail.com>
> TO: null...@hoge.jp
> From: "a" null...@hoge.jp

あー、うちにも来てます～。うちの Return-Path は yahoo.co.jp
でした～。詐称してますね、確実に。しかも何度もきてます。

特定商取引の規定の中に、未承認広告って、SUBJECT にいれなさい
よとか、きまってるのに行儀のわるいめーるだなー。ってその前に
コピー品だし、ってことで、一応所轄の県警のインターネットの犯
罪窓口にご連絡をさしあげてます。

adsl-*******.****.pacbell.net (*** は伏字ってことで)からメー
るが幾度となくくるので、MXが逆引きできるサーバからの接続要求
以外拒否したいと思ってるのですが、そんな方法ってあるんでしょ
うか？？
＃　SMTP接続してきた接続元は、MXに登録されてなくてはならない
＃　（ただし、allow設定に指定されているIPは許可）
ってのをm4で実現なんてできますか？

あ、でも、MXに登録されてないメール配送サーバなんてこの世の中
には沢山あるから、そんなことした日にゃぁ大混乱かもしれないで
すね…。なんかspamよけのいい方法ないかなぁ…

とりあえず、ordb.org と jippg.org に頼るしかないのかなぁ…
→不正送信を行うIP避け

--
Tetsu <tets...@hotmail.com>

[TATSUMI Takeo]

東京農工大学・神戸大学の辰己です。

「envelope-to をみて届いた」に1票です。

今回のものはうちには来てませんが、毎日100～400通のSPAMをもらってるんで、
なんとなく対処(spam filterのアップデート)に慣れてしまいました。filter
が1通も漏らさず、かつ1通も間違えずにfilterした日は、逆に寂しかったりし
て…。

[hanajipon]

hanajipon＠元ネタ発信者です。

皆様、たくさんの情報ありがとうございます。

"MAEDA Atusi" <maeda...@ialab.is.tsukuba.ac.jp> wrote in message
news:m3hdwow...@nospam.maedapc.cc.tsukuba.ac.jp...

> "hanajipon" <hana...@mail.goo.ne.jp> writes:
>
> > ・Fromは詐称されているのは理解できます。実際の送信者は
> > f54xx...@hotmail.com ですか？
>
> とは限りません。Return-Path: には、SMTPプロトコルでの「発信者」情報(エ
> ンベロープFROMアドレス)が記録されますが、これは送信者が自由に設定でき
> る情報です。詐称は簡単です。

Fromも詐称されるし、Return-Pathも詐称できる。って事ですね。
Return-Pathを詐称するには、具体的にどのようにするのでしょうか？
（sendmail.cf をいじって、普通はやらないような書き換えルールにするのでしょう
か？）

> > ・To は実在しないアカウントなのに、何故、私に届いたのでしょうか？
>
> インターネットでのメイルは、SMTPプロトコルでの「受信者」(エンベロープ
> TO)に指定されたメイルボックスに届きます。メイルのTo:, Cc:, Bcc: などの
> ヘッダはSMTPでの配送先と直接の関係はありません。(メイル送信ソフトがこ
> れらのヘッダからエンベロープTOを作る可能性はあります。配送時にはこれら
> は「封筒の中身」扱いであり、転送ソフトは見ません。)

この件に関しては皆様のご指摘どおり、
・sendmail コマンドで言うところのパラメータ recipient が指定された所に届
く
・Bccを使っている
等ですね。
＃タコな質問をしてしまってすみません。
＃はずかしい(*-_-*)

結局、スパム送信者のメールアドレスなんて、わからないし、わかっても意味が無い
という事に
なるのかな？
ヘッダーを見るなら Receivedフィールドを見て、
・どのIPアドレスから
・何時に
という所までしか特定できない。
後の対処としては、そのIPの管理者にメールを送るぐらい。

この認識、あってます？

---
hanajipon @ mail.goo.ne.jp

[Nobuhiro Shibuya at Office]

hanajipon wrote:

> hanajipon＠元ネタ発信者です。

> Fromも詐称されるし、Return-Pathも詐称できる。って事ですね。
> Return-Pathを詐称するには、具体的にどのようにするのでしょうか？

RFC2821 を読めとお答えしておきます。

> （sendmail.cf をいじって、普通はやらないような書き換えルールにするのでしょう
> か？）

コーモリ本(O'Reillyの "Sendmail")を読めとお答えしておきます。
--
mailto:shi...@dd.iij4u.or.jp
Nobuhiro Shibuya at Office
Tokyo Japan

[MAEDA Atusi]

"hanajipon" <hana...@mail.goo.ne.jp> writes:

> Fromも詐称されるし、Return-Pathも詐称できる。って事ですね。
> Return-Pathを詐称するには、具体的にどのようにするのでしょうか？
> （sendmail.cf をいじって、普通はやらないような書き換えルールにするのでしょう
> か？）

spammerはsendmailを使わないんじゃないかと思いますが…
SMTP的にはとても簡単です。
telnet 自分のメイルサーバ 25
とかやって、メイルを送ってみれば分かります。

> 結局、スパム送信者のメールアドレスなんて、わからないし、わかっても意味が無い
> という事に
> なるのかな？
> ヘッダーを見るなら Receivedフィールドを見て、
> ・どのIPアドレスから
> ・何時に
> という所までしか特定できない。

「信頼できるサーバのつけた」Received: フィールドならば、意味のある情報
でしょう。IPアドレスまで詐称するような手間はふつうかけないでしょうから。

それ以前についていたReceived:は信用できません。

> 後の対処としては、そのIPの管理者にメールを送るぐらい。

うむむ。まあ、そうですね。効果が期待できるかどうかは…

# Received:も見ないで、詐称に使われたドメインの管理者に文句を送ってくる
# やつの多いことったら。spammerと同じくらい害があると思うのですが。

ユーザレベルの対策だと、
・収集されるような場所にメイルアドレスを公開しない。
・Message-ID:, Subject:, To:, Cc:, エンコーディング、MIME typeでのフィ
ルタリング
・Bayesian filterを使ったフィルタリング
くらいでしょうか。

MTAレベルでは、tarpitting, spam throttling, teergrubingなど提案されま
したが、どれもいまいちです。今もっとも効果がありそうなのは grey
listingでしょうか。これもspammerにすぐに対応されちゃいそうに思いますけ
ど。
前田敦司

[Shinji KONO]

河野真治 @ 琉球大学情報工学です。

In article <m2llm0x...@qed.decode.waseda.ac.jp>, TATSUMI Takeo <tt...@cc.tuat.ac.jp> writes

> 今回のものはうちには来てませんが、毎日100～400通のSPAMをもらってるんで、
> なんとなく対処(spam filterのアップデート)に慣れてしまいました。filter
> が1通も漏らさず、かつ1通も間違えずにfilterした日は、逆に寂しかったりし
> て…。

僕もそんなものですが、間違えるのは、一日数通ですね。SPAM を
逃すのは問題ないんですが、必要なのを junk に落されるのは、め
んどう。もっとも、そういうのは、それほど緊急性が高くないのが
普通なんで良いんですけど。

ただ、一応、junk のSubjectにも目を通さなきゃならんのが大変。

なんか、やっぱり、自分にメールを送って良いよ鍵みたいなのがあ
って、それを使って、やっぱり変なものを送って来たら、その鍵ご
とブロックするみたいな方式がいいかなぁ。

---
Shinji KONO @ Information Engineering, University of the Ryukyus
河野真治 @ 琉球大学工学部情報工学科

[hanajipon]

hanajipon です。

"MAEDA Atusi" <maeda...@ialab.is.tsukuba.ac.jp> wrote in message

news:m3d67bs...@nospam.maedapc.cc.tsukuba.ac.jp...

> "hanajipon" <hana...@mail.goo.ne.jp> writes:
> 「信頼できるサーバのつけた」Received: フィールドならば、意味のある情報
> でしょう。IPアドレスまで詐称するような手間はふつうかけないでしょうから。
>
> それ以前についていたReceived:は信用できません。

IPアドレスの詐称もできるのですね。
となると、もはや何も信用できない。スパム送信先を特定するのは不可能という
認識でいたほうが良さそうですね。

> > 後の対処としては、そのIPの管理者にメールを送るぐらい。
>
> うむむ。まあ、そうですね。効果が期待できるかどうかは…

そうですね。まぁ期待はしていません。

> # Received:も見ないで、詐称に使われたドメインの管理者に文句を送ってくる
> # やつの多いことったら。spammerと同じくらい害があると思うのですが。

この辺は、私も同感です。
ワクチンソフトなどで
「ウィルスを発見しました！送り主は xxx です！」
などと詐称されたアドレスを表示したりしませんか？
私もそれほどスキルがあるとは思いませんが初心者が見たら、そのアドレスに
メールとかしたりしないのかなぁ。

> ユーザレベルの対策だと、
> ・収集されるような場所にメイルアドレスを公開しない。
> ・Message-ID:, Subject:, To:, Cc:, エンコーディング、MIME typeでのフィ
> ルタリング
> ・Bayesian filterを使ったフィルタリング
> くらいでしょうか。
>
> MTAレベルでは、tarpitting, spam throttling, teergrubingなど提案されま
> したが、どれもいまいちです。今もっとも効果がありそうなのは grey
> listingでしょうか。これもspammerにすぐに対応されちゃいそうに思いますけ
> ど。

もうこのあたりから、ついて行けてません。
もっと勉強します。

---
hanajipon @ mail.goo.ne.jp

[hanajipon]

hanajipon @ 元ネタ発信者です。

技術的な話とは違う観点から、以下の情報を e-mail で頂きました。

"hanajipon" <hana...@mail.goo.ne.jp> wrote in message
news:c38c35$aj8$1...@nn-os102.ocn.ad.jp...

> こんにちは。
> sendmail-8.11.6-11.1 を使ってメールサーバを運営してます。
> ユーザから「誰にも公開していない、作ったばかりのメアドにスパムが届いた」と
報
> 告を受けました。
>
> スパムの内容は
> > 蒲生4丁目広告
> > ☆激安 ! ! ! ソフトの総合商社　そふとはうす
> > ☆在宅ＰＣビジネスのご案内
> >
> > ■　ソフトの総合商社　そふとはうす　■
> > Ｗｉｎｄｏｗｓ日本語製品版です。Ｍａｃもあります。 単位は
す
> べ

以下がその内容です（一部、抜粋）
> 回答、解説ではありませんが、以下のようなメールが社内の者にしつこ
> く送られてきたので、(最近話題になった)
>
> コンピュータソフトウェア著作権協会の不正コピー情報提供窓口
> http://www.accsjp.or.jp/piracy.html
>
> へ連絡したところピタリと止まったようです。
>
> ご参考になれば幸です。

こういう情報も大変助かります。
情報提供者の方、どうもありがとうございました。

[Eisaku YAMAGUCHI/山口 榮作]

山口と申します．

"hanajipon" <hana...@mail.goo.ne.jp> writes:

> hanajipon です。

>
> > 「信頼できるサーバのつけた」Received: フィールドならば、意味のある情報
> > でしょう。IPアドレスまで詐称するような手間はふつうかけないでしょうから。
> > それ以前についていたReceived:は信用できません。
> IPアドレスの詐称もできるのですね。
> となると、もはや何も信用できない。スパム送信先を特定するのは不可能という
> 認識でいたほうが良さそうですね。

そうではなくて，Received:というヘッダ部分も捏造できるのです．
信頼できるホストへのReceived:ヘッダの記録が，送信者が確かに利用した
（送信者に利用された）ホストであって，更に遡ることができるReceived:
ヘッダは，信頼できる情報ではありません．

RFC 2821, 2822あたりを理解して，実際にtelnetでsmtpを喋ってみれば
理解いただけるでしょう．

--
山口 榮作 <eis...@ist.aichi-pu.ac.jp>
PGP Key fingerprint = FAD0 3EB2 D9E5 F10F 9627 4106 04F6 639F E579 53EB
久々に投稿してみました