スパムの内容は
> 蒲生4丁目広告
> ☆激安 ! ! ! ソフトの総合商社 そふとはうす
> ☆在宅PCビジネスのご案内
>
> ■ ソフトの総合商社 そふとはうす ■
> Windows日本語製品版です。Macもあります。 単位はす
べ
))))以下、省略((((
というやつで日本語です。(コピーソフトを売りつけるな!)
同様のメールは私のメアドにも届いていたのですが、「スパムだから削除だな」で、
あまり気にして
いませんでしたσ(^_^;)
しかし、今回の件を受けて、ヘッダーを見ていると
わからない部分があったので教えてください。
(都合上、ドメイン、アカウント名を架空のものとします)
・私のメアドは 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
# メアドという言葉を使う人は、アイタタな人間として見えてしまう。
# ホムペとかフォトショとかイラレとかも…
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
> ・Fromは詐称されているのは理解できます。実際の送信者は
> f54xx...@hotmail.com ですか?
とは限りません。Return-Path: には、SMTPプロトコルでの「発信者」情報(エ
ンベロープFROMアドレス)が記録されますが、これは送信者が自由に設定でき
る情報です。詐称は簡単です。
> ・To は実在しないアカウントなのに、何故、私に届いたのでしょうか?
インターネットでのメイルは、SMTPプロトコルでの「受信者」(エンベロープ
TO)に指定されたメイルボックスに届きます。メイルのTo:, Cc:, Bcc: などの
ヘッダはSMTPでの配送先と直接の関係はありません。(メイル送信ソフトがこ
れらのヘッダからエンベロープTOを作る可能性はあります。配送時にはこれら
は「封筒の中身」扱いであり、転送ソフトは見ません。)
前田敦司
MTUはToなんぞ見てませんもん。
SMTPのRCTPで設定されたアドレスに飛ぶだけです。
--
___ わしは、山吹色のかすてーらが大好きでのぅ
[[o o]] ふぉっふぉっふぉ
'J' 森下 お代官様 MaNMOS 英夫@ステラクラフト
PGP Finger = CD EA D5 A8 AD B2 FE 7D 02 74 87 52 7C B7 39 37
> ヘッダーは以下のようになっています
> 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>
「envelope-to をみて届いた」に1票です。
今回のものはうちには来てませんが、毎日100~400通のSPAMをもらってるんで、
なんとなく対処(spam filterのアップデート)に慣れてしまいました。filter
が1通も漏らさず、かつ1通も間違えずにfilterした日は、逆に寂しかったりし
て…。
皆様、たくさんの情報ありがとうございます。
"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
> hanajipon@元ネタ発信者です。
> Fromも詐称されるし、Return-Pathも詐称できる。って事ですね。
> Return-Pathを詐称するには、具体的にどのようにするのでしょうか?
RFC2821 を読めとお答えしておきます。
> (sendmail.cf をいじって、普通はやらないような書き換えルールにするのでしょう
> か?)
コーモリ本(O'Reillyの "Sendmail")を読めとお答えしておきます。
--
mailto:shi...@dd.iij4u.or.jp
Nobuhiro Shibuya at Office
Tokyo Japan
> 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にすぐに対応されちゃいそうに思いますけ
ど。
前田敦司
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
河野真治 @ 琉球大学工学部情報工学科
"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
技術的な話とは違う観点から、以下の情報を 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丁目広告
> > ☆激安 ! ! ! ソフトの総合商社 そふとはうす
> > ☆在宅PCビジネスのご案内
> >
> > ■ ソフトの総合商社 そふとはうす ■
> > Windows日本語製品版です。Macもあります。 単位は
す
> べ
以下がその内容です(一部、抜粋)
> 回答、解説ではありませんが、以下のようなメールが社内の者にしつこ
> く送られてきたので、(最近話題になった)
>
> コンピュータソフトウェア著作権協会の不正コピー情報提供窓口
> http://www.accsjp.or.jp/piracy.html
>
> へ連絡したところピタリと止まったようです。
>
> ご参考になれば幸です。
こういう情報も大変助かります。
情報提供者の方、どうもありがとうございました。
"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
久々に投稿してみました