ID-code:GdhsmUVjX4g

仔鹿氏の記事 No.18938 より引用.

>Vodafoneではメール不達通知を悪用したスパムがあるようですね。
>
>今度、メール不達通知の本文を削除することで
>スパムを防止するそうです。

送信をブロックするわけではないのですね…。あくまでお客様に受信
していただこうというわけですか…何考えてるんだろう…
と思う鬱状態のねここねこです。

スパムメールの送信量自体を減らしたいのに本文だけ消されても…
でも宣伝サイトへの誘導は出来なくなるから効果はあるのかな…？
Vodafone使ってないから効果がよく判らないや。

各携帯電話キャリアの規格が異なるのでなんとも言えませんが、
同様の手口が他の携帯キャリアに流れ込むだけでは無いかと。
# それはスパマに聞いてみないと判りませんが（聞きたくも無いけど

話は変わり増すが、ゾンビ化したPC以外に素人が立てたオープンリレー
なメールサーバを悪用するケースもたしかに増えてますね。
最近そう思われるメールが着弾するんでうが、本人がよく判って無い
ので説明に苦労しています。
# 勉強せずに不用意にメールサーバ立てるなー！！　とちょっと声を
# 大にして本日はお休みいたします。

失礼致しました

ID-code:w6SZ3BprNCg（本記事は投稿者自身により10/08-21:29に修正されました）

> >Vodafoneではメール不達通知を悪用したスパムがあるようですね。
> >
> >今度、メール不達通知の本文を削除することで
> >スパムを防止するそうです。
>
> 送信をブロックするわけではないのですね…。あくまでお客様に受信
> していただこうというわけですか…何考えてるんだろう…
> と思う鬱状態のねここねこです。

　いや、これは不達通知から本文を削除することにより、
不達通知を利用したspamを送る意味がなくなるので、
このような方法でのspam発信の抑止になるということですので
一応は送信側での抑止方法と言えますし、
「あくまでお客様に受信していただこう」
というのとは違うように思います。

　詳しく説明すると

spam発信者→（１）→全く無関係なサーバ(＠aaa.bbb)
　　　　　　　　　　　　↓
　　　　　　　　　　　（２）
　　　　　　　　　　　　↓
　　　　　　　　　　jushin_higaisha＠ccc.dddの所有者（受信被害者）

（１）で

From:jushin_higaisha＠ccc.ddd
To:SONZAISHINAI＠aaa.bbb
本文：宣伝したい内容

というメールを送ると（２）のエラーメールが届くわけですが
そのようにして受信被害者に送る方法です。
このメリットとして考えられるのは

・実際に被害者達に届けられるのは（２）の経路なので
プロバイダーによる通常の各種発信制限を回避できる場合がある。

・受信被害者が受信の際、詐称されたのではないかと思うので
注目を引くことが出来る

などがあります。
http://antispam.stakasaki.net/laji-yuanzui.html#yuanzui03
のIVでもあります。
（正確には多分Fromでないのだけど詳しくは略）

　このようなspam発信は
英文spamではときどき出ているようです。
私もそれらしきものを受け取ったことがあります。
　ただし手法としてあまり一般的ではなく、その為もあるのでしょう、
電子メールの一般の不達通知（エラーメール）を
本文をつけないようにすることは特に検討されていないようです。

> 各携帯電話キャリアの規格が異なるのでなんとも言えませんが、
> 同様の手口が他の携帯キャリアに流れ込むだけでは無いかと。

　まあこの可能性は否定できないですけど。
ただ、迷惑メール規制２法で、個々のキャリアやISPは
spamを抑止もしくは忌避するような技術的方法の導入を促されているので
とりあえずは自分のところで受けるspamを少しでも少なくするような方法を
「利己的に」採用するのはやむを得ないでしょう。

ID-code:w6SZ3BprNCg（本記事は投稿者自身により10/22-11:02に修正されました）

BIGLOBEに続き、Hi-Hoも偽装アドレスからのメール拒否の技術を
導入し始めました。

http://www2g.biglobe.ne.jp/~stakasa/nospam_bbs/past/log/018123.html#18933
http://www2g.biglobe.ne.jp/~stakasa/nospam_bbs/past/log/018123.html#18943

　該当会社の説明に￥ですが
−−−−
BIGLOBEについては
http://email.biglobe.ne.jp/service04.html
の
BIGLOBEユーザさま宛の迷惑メール受信対策

HI-HOについては
http://home.hi-ho.ne.jp/news_release/2004/1007.html
−−−−
にあります。

　で、BIGLOBEの方ですが実際に試してみました。
一般の広報では「差出人アドレス」となっていますが、
正確にはFromヘッダのアドレスのことではなく
Envelope Fromすなわち受信後にはReturnPathとして
つけられるメールアドレスの偽装を受け付けないようです。

参考：spamとEnvelope Fromについては以下へ
http://ssss.jp/~trombik/email/envelope.html

SMTPの552エラーとなるようです。
　私も詳しくないのでよく知らないのですが
Envelope Fromで名乗られるドメインのMXレコードを引けない場合に
552エラーで拒絶するということなんですかね、多分。

　BIGLOBEは

｜BIGLOBEユーザさま宛の迷惑メール受信対策
｜
｜BIGLOBEでは、BIGLOBEユーザさま宛の大量迷惑メール受信対策を行っています。
｜通常の使い方を行う一般的なBIGLOBEメールユーザさまには影響を
｜与えることなく、大量迷惑メールをBIGLOBEメールサーバが拒否します。
｜
｜差出人アドレスチェックの強化　【NEW!】
｜
｜ 迷惑メール送信者は、差出人アドレスを偽装して迷惑メールを
｜出すことが多くあります。これに対応するため、
｜差出人アドレスが存在しないメールを、迷惑メールと判断し
｜受け付けないようにします。具体的には、DNS(*2)に登録されていない
｜ドメイン名(*3)のメールをBIGLOBEメールサーバが拒否します。
｜ (*2) IPアドレスとホスト名の対応付けを行うデータベース
｜ (*3) メールアドレスの＠マークの右側部分

とあるので、多分それだけだと思うのですが、HIHOの方ですが

｜(1)送信元メールアドレスが架空ドメイン名であるメールの受信拒否
｜DNS※3に登録されていないドメイン名※4からのメールを
｜迷惑メールであると判断し、hi-hoメールサーバにて受信拒否します。

｜(2)ホスト名※5が確認できない IPアドレス※6からのメールの受信拒否
｜ホスト名を確認することができないIPアドレスからのメールを
｜迷惑メールであると判断し、hi-hoメールサーバにて受信拒否します。

このうち、（１）はBIGLOBE同じと考えられますけど（２）は
更に進んで発信元IP（サーバ）の真っ当さを判定するようです。
上の中の「ホスト名※5が確認できない 」というのは発信元IPの
逆引きが出来ないものということなんでしょうかね？
　いや、逆引きしたドメインのMXレコードが引けないIPアドレス？

−−−−−−−−−−−−−−−−−−−−−−−−−−−−
さて、上のような技術の詳細はともかく、BIGLOBEの方の対策なんですけど
私へは現在BIGLOBEのアドレスに月1000通ばかりのspamが来ています。

で、残念ながら上の技術が導入された時点以降の英文spamの量は
ほとんど減っていません。（2004年の８月〜９月の変化に注目）
http://antispam.stakasaki.net/shouhai-fenxi.html#030102
http://antispam.stakasaki.net/img/tongji-ge.gif

　何しろEnveropeFromはYahooなりhotmailなりなんでも
名乗れるわけでして、spammerも架空のドメインを詐称して拒絶されたと分かれば
そういう一般的なドメインを名乗るだけですので
spammerとしてはほとんど痛いものではないでしょう。

　まあこれはそれをするのが無駄と言いたいのではなく、
上の対応はほんの「ささやかな」spam対策に過ぎず、
BIGLOBEさんもそのユーザにもそれを自覚して欲しい、
ということですね。やらないよりゃマシですから。

　そしてその程度は結構多くのサーバが
行い始めているんじゃないんですかね、
特にISPではない企業や学校のサーバで、
サーバ管理人がspam対策に少しでも積極的ならば。

　HIHOの（１）が逆引きをするのなら、
そこまでしているサーバは現時点では多くなさそうで、
少し先進的（？）でしょうか？
仮に逆引き結果がない場合にはどうするんでしょうね。
以前逆引きがないIPを拒絶するという方式には批判的な文章を
見たことがありますけど。
（参考に挙げた「人生ままならず」さんの所だったかな）

ID-code:w6SZ3BprNCg

　ちなみに導入以前に受け取った英文spamのReturnPathの統計を取って
MXレコードが引けないようなドメインがどれくらい
使われていたかを調べれば、どれくらいのspamの抑制になったのか
数値で出せますけど、結構面倒なのでやりません。

　そういえばこのような方法の導入を考えるとき
注目すべきなのは仮にIPやドメインが問題性のあるサーバではなくても
それが「spamでない」ことの証明にはほとんどならないということですね。

　すなわち、送信者アドレスのドメインがYahooやhotmailだとしても
本当に送信者がそのサーバを使っているか分からないわけですが
さらに進んでHiHoのような方法で送信サーバがYahooやHotmailであることが分かっても
それが「spamでない」ことの決定的な根拠にはならないということです。

　spam発信をしているサーバのIPアドレスについてデータベースを作っている
SenderBaseのデータ
http://www.senderbase.org/
を見ると、Yahooやhotmailは実際にも発信に悪用されてしまっているわけです。

　これを考えるとき、
私はSenderIDの技術について詳しくは知らないのですが、
仮にそういう技術が導入されても、送信者が本当に
「spamを行うようなユーザではない、spammerを出すようなサーバではない」
ということを確認する、もしくはそういう人にしかIDを与えないと言うのは
それなりにかなり困難を要することではないでしょうか？

　そしてそれをきちんとしない限り、spamの抑止にはほとんどならないでしょう。
技術でspamを出来「にくく」することも重要ですが、
その前にspam行為を行うことのリスクを十分に高くすること、
具体的には処罰（罰則、罰金）を厳しくする、もしくは
大量のメールを送ること自体のコストを高くするなどの
措置を断固として導入することが重要だと考えます。

ID-code:UlA5wqhE/wI

管理人さんこんにちは。ご無沙汰しています。
ちょっと結論部分だけにレスしますが

> 技術でspamを出来「にくく」することも重要ですが、
> その前にspam行為を行うことのリスクを十分に高くすること、
> 具体的には処罰（罰則、罰金）を厳しくする、もしくは
> 大量のメールを送ること自体のコストを高くするなどの
> 措置を断固として導入することが重要だと考えます。

ようするに受け取る側が工夫すべきではなく、送信する側を規制すべきってことですよね。。判りますが。。
メールサーバが簡単に個人で建てられるわけですから
送信コストを高くするのは難しいです。また課金についても（受信者の）国内であればらくでしょうが
実際には難しいでしょう。
そしてどれも「技術的に難しいのでは？」と思います。

法的な面も難しいというか、実効性に乏しいですね。現状で禁止されているにも関わらず
逮捕なり起訴なりされているのは過去に携帯電話会社向けに送信していた人だけですし
今後も新たに厳しい法律が出来たとしても国外からの送信であれば
さらに実効性が無いということです。悲しいですがそういった面は否定できません。

管理人さんの理想には同調しますが、技術的な面を否定するのはどうかと思います。
私も残念ながらISP（ニフ）が用意するフィルターを使わざるを得ない事態になっています。
送信元をランダムに変化させる為に極端な話、.comまとめて規制するしかなく、重要なメールを受け取れない事があり仕方なくそのような方法を取らざるを得なかったです。

ですのでどちらか一方だけではなく、
技術面で出来る範囲はより高度化していく。（勿論送信側も受信側も）
法的な面で出来る範囲もより努力していく。（実効性が高いものに）
受け取る側もより啓蒙していく。（スパムを信用しないとかやたらクリックしないとかフィルタリングのやり方とか）

が大事かと思います。あえてですが強調させて頂きたいと思います。

ID-code:PUnZQgP1buQ

[「spam(迷惑メール)は無視」はもう古い]
http://blog.livedoor.jp/yom/archives/7827667.html

丁度　私も今日　spamの抑止に関する記事を書いて所でした。

やはり、一面的な行動だけでは、高い抑止効果は期待出来ないと思います。
受信者・ISP・行政が、足並みを揃えて抑止に動く事が一番望ましいかと、
特に、高崎様も書いておられる、法的な抑止力の強化が必須ですが、
悲しいかな、今現在　一番期待出来ない面だったりするんですよね・・・。

発信者認証技術ですが、
取り合えず、ゾンビPCを使用しての発信が無力化するだけでも、ちょっとはマシな状況にはなるかと・・・、
もちろん、実用レベルまで行けば、スパマーは、それを掻い潜る新たな手法を考えるのでしょうけど（鬱）

ID-code:DhwQfvzcQAs

Kagoya Internet Routing様のサイトを見ていると
スパム送信防止に下記の様に取り組んでいるようです。

http://www.kagoya.net/usersupport/smtp/