提案：Return-Pathと違う場合に警告しては	No.09034
SBNB さん　02/09/20 23:30
続けてすみません。 相変わらず良くウイルスが届きますが、差出人を詐称するウイルスについて、From: は改変されますが、Return-Path:は改変されないようです。 そこで、From:および、Reply-To:とReturn-Path:を比較して、異なっている場合はウ イルスの疑いが強いと思われるので、警告してはどうかと思いました。 他の皆さんはいかがでしょう。賛成の方が多いようでしたらお願いいたします。 どちらにせよウイルススキャンソフトは入れなければならないので無意味なのかもし れませんが、一般的には送信者は不明で対処不可能と言うことになっているので、差 出人が分かる（と、利用者に気づかせる)と言う意味で価値あるかなと思ったりしま した。 まるおさんへ＞ 特に賛同者がいなければお忙しいと思うので回答は無しでかまいま せん。

[ △ ]

RE:09034 提案：Return-Pathと違う場合に	No.09035
ひろ さん　02/09/21 00:04
SBNB さん今日は、ひろです。 > そこで、From:および、Reply-To:とReturn-Path:を比較して、異なっている場合はウ > イルスの疑いが強いと思われる 　私は幾つかの理由で、From を書き換えて送ることがあります。ですから必 ずしも、異なっているからといってヴィールスの疑いが強いわけではありま せん。よって、この提案には賛成できません。

[ △ ]

RE:09034 提案：Return-Pathと違う場合に	No.09036
たるっぱ さん　02/09/21 00:56
SBNBさん こんにちは。たるっぱです。 >そこで、From:および、Reply-To:とReturn-Path:を比較して、異なっている場合はウ >イルスの疑いが強いと思われるので、警告してはどうかと思いました。 そもそもが、まともに届いた場合、サーバが除去すべきヘッダですから あまり意味のない機能追加となってしまうんじゃないかと思います。

[ △ ]

RE:09034 提案：Return-Pathと違う場合に	No.09037
shoko さん　02/09/21 02:52
えーこれって困っちゃいます。だって私たちの場合、全部別のを使ってマーケティン グや分析に使っているんですよ。だから駄目そんなのなんて甘えていいですか？

[ △ ]

RE:09034 提案：Return-Pathと違う場合に	No.09039
きいろいまふらあ さん　02/09/21 05:37
こんばんは。 >そこで、From:および、Reply-To:とReturn-Path:を比較して、異なっている場合はウ >イルスの疑いが強いと思われるので、警告してはどうかと思いました。 個人間のやりとりで送信者が意図的にFrom:および、Reply-To:とReturn-Path:を 違えるケースはさほど多くはないと思いますが、一般的なメーリングリストの メールなどはほとんどがこのパターンになります。したがって「異なっている場 合はウイルスの疑いが強い」というのは、そういったメールをほとんど受信しな い場合に限られるということになりましょう。 例えば私の場合、日々受け取るメールの９割以上は確実にこのパターンです。 そもそもFrom:を詐称するメールを送信するウィルスがいつまで今の仕様でいて くれるか（いつReply-To:やReturn-Path:も同時に詐称する亜種が現れるか）わ からないって話もあります（すでにあるかもしれないし）。 頭ごなしに否定してしまいましたが率直な感想でした。

[ △ ]

RE:09036 提案：Return-Pathと違う場合に	No.09040
きいろいまふらあ さん　02/09/21 05:47
話が横道に逸れてしまいますが、 >>そこで、From:および、Reply-To:とReturn-Path:を比較して、異なっている場合はウ >>イルスの疑いが強いと思われるので、警告してはどうかと思いました。 > >そもそもが、まともに届いた場合、サーバが除去すべきヘッダですから ＲＦＣでそのように規定されているという意味でしょうか？ 実際に私が受け取るメールのほとんどには、これらのヘッダ（Reply-To:と Return-Path:）はついてますので、私が利用しているPOPサーバは、そういった 仕様にはなっていないようです。 そもそも、Return-Path:はともかく、Reply-To:に関しては、相手まで届いてく れないと意味がないような気がするのですが……。 元の（警告を出すという）提案自体に賛同しているわけではないのですが、ちょ っと気になってしまったのでコメントさせていただきました。意味を取り違えて いたらごめんなさい。

[ △ ]

RE:09034 提案：Return-Pathと違う場合に	No.09042
ながさわ さん　02/09/21 06:57
こんにちは、長澤です。 >相変わらず良くウイルスが届きますが、差出人を詐称するウイルスについて、From: >は改変されますが、Return-Path:は改変されないようです。 色々なコメントは他の方々に任せて（笑）。 Klez.Hは既にReturn-Path:を詐称していますね。

[ △ ]

RE:09040 提案：Return-Pathと違う場合に	No.09044
たるっぱ さん　02/09/21 08:25
きいろいまふらあさん こんにちは。たるっぱです。 >>そもそもが、まともに届いた場合、サーバが除去すべきヘッダですから > >ＲＦＣでそのように規定されているという意味でしょうか？ >実際に私が受け取るメールのほとんどには、これらのヘッダ（Reply-To:と >Return-Path:）はついてますので、私が利用しているPOPサーバは、そういった >仕様にはなっていないようです。 誤解を与えるような書き方をしてすみません。 私が述べているのはReturn-Pathヘッダについてのみです。 RFC2821で、MTAによって付加・消去されることが規定されています。 意味合いからすると、メール受信者に渡す必要のないヘッダで、実際私の受け 取るメールからは削除されています。 しかし、消去しないシステムがRFC違反かというと、そんなことはなく、実装 に任されていたはずです。

[ △ ]

RE:09035 提案：Return-Pathと違う場合に	No.09045
SBNB さん　02/09/21 10:09
ひろさんこんにちは、SBNBです。 >　私は幾つかの理由で、From を書き換えて送ることがあります。 べつにFromを変えても残りのヘッダで区別できれば問題ないように思います。嫌なら 機能をきればいいだけではないか。。。 >異なっているからといってヴィールスの疑いが強いわけではありません。 幾つか調べてみましたら、確かに正常そうなメールでも3つのヘッダが全て異なるも のもありまして、簡単に実装したら出来るものでもなさそうでした。

[ △ ]

RE:09042 提案：Return-Pathと違う場合に	No.09046
SBNB さん　02/09/21 10:13
こんにちは、長澤さん、SBNSです。 >Klez.Hは既にReturn-Path:を詐称していますね。 これはどこで分かりますか? ウイルススキャンソフトの会社のサイトなんかにあるの でしょうか。私の送信実験では詐称は不可能でした。サーバー自体がウイルスにやら れていれば可能かもしれませんが一般的なプロバイダでは無理ではないでしょうか。

[ △ ]

RE:09039 提案：Return-Pathと違う場合に	No.09047
SBNB さん　02/09/21 10:16
きいろいまふらあさん、こんにちは >一般的なメーリングリストのメールなどはほとんどがこのパターンになります。 なるほど、私はメーリングリストはつかっていないので気づきませんでした。 ＞（いつReply-To:やReturn-Path:も同時に詐称する亜種が現れるか） たしかに、いつ現れるか分からないですね。私のところのプロバイダに限っては詐称 しても、プロバイダで正確なものに直してくれましたので、ウイルス側で詐称しても 詐称不可能かと思っています。

[ △ ]

RE:09037 提案：Return-Pathと違う場合に	No.09048
SBNB さん　02/09/21 10:19
>私たちの場合、全部別のを使ってマーケティングや分析に使っているんですよ。 Return-Pathも変えるんですか? どのように変えられるのでしょう。判別するのに何か手立てがあればいいですが。

[ △ ]

RE:09044 提案：Return-Pathと違う場合に	No.09049
SBNB さん　02/09/21 10:22
たるっぱさん、SBNBです。 >消去しないシステムがRFC違反かというと、そんなことはなく、実装 >に任されていたはずです。 なるほど、消さなくても良いのですね。 現状では受取人が簡単に差出人が分かる唯一の手がかりなので、全世界でウイルスに は困っているはずなので、ひょっとすると削除しない方法へ進むかもしれませんね。

[ △ ]

RE:09034 提案：Return-Pathと違う場合に	No.09050
SBNB さん　02/09/21 10:30
SBNBです。皆様コメントありがとうございます。 ご意見を頂きまして私のほうも調べてみました。 簡単にFromとReply-ToとReturen-Pathを比較するだけでウイルスかどうかを区別する のは不可能のようです。 鶴亀がウイルスに強いとか、ウイルスに配慮していると言うようなうたい文句があっ たように思っていますので、私としては、他のメールソフトにない（と私が勝手に思 っていて知らないだけかもしれませんが)、そういう機能があればもっと強く宣伝で きると思いました。 実際、このような機能を実装するとなると、かなり面倒なことになりそうだと思いま した。Delivered-To: 、Errors-To: などメールアドレスの入るヘッダもほかにもあ るようですので、これらを組み合わせてやる必要があるし、企業ユーザか、一般的な プロバイダかなど、ドメイン名で思考ルーチンを変えたりする必要もありそうです。 また、場合によっては、「このアドレスの場合は、このドメインの場合は例外として 警告しない」なんてオプションまで必要になって、実装そのものがただではすまなく なりそうです。てっきり簡単に出来るものだと思ってましたが、実際そこまでやって メリットあるのかちょっと疑問です。 コメントありがとうございました。

[ △ ]

RE:09044 提案：Return-Pathと違う場合に	No.09052
きいろいまふらあ さん　02/09/21 12:28
たるっぱさん、おはようございます。 >私が述べているのはReturn-Pathヘッダについてのみです。 >RFC2821で、MTAによって付加・消去されることが規定されています。 >意味合いからすると、メール受信者に渡す必要のないヘッダで、実際私の受け >取るメールからは削除されています。 なるほどです。納得です。 >しかし、消去しないシステムがRFC違反かというと、そんなことはなく、実装 >に任されていたはずです。 これまた納得です。 丁寧な説明ありがとうございました。よくわかりました。 ＃読み返すと、最初の時点でReturn-Path:のことと気づくべきでした。

[ △ ]

RE:09049 提案：Return-Pathと違う場合に	No.09053
たるっぱ さん　02/09/21 14:09
SBNBさん こんにちは。 たるっぱです。 >現状では受取人が簡単に差出人が分かる唯一の手がかりなので、全世界でウイルスに >は困っているはずなので、ひょっとすると削除しない方法へ進むかもしれませんね。 Return-Path削除の是非は別として、Return-Pathを今後も手がかりにできるか というと、首を傾げざるを得ません。 Return-Pathヘッダの、そもそもの元は、送信時にクライアントがサーバに渡 すコマンドです。 昨今のウィルス(というかワーム)はSMTPクライアント機能を備えてますから、 詐称するのは難しくないはずです。 Return-Pathに手がかりを残してしまったのは、ワームと動作としては"バグ" なんだろうと思いますよ。

[ △ ]

RE:09053 提案：Return-Pathと違う場合に	No.09054
たるっぱ さん　02/09/21 14:27
たるっぱです。 >Return-Pathに手がかりを残してしまったのは、ワームと動作としては"バグ" >なんだろうと思いますよ。 訂正です。 Return-PathをFromと別にしているのは、エラーメールが被害者のアドレスに 届いて、悪さがバレないようにするためで、ワームの"仕様"でしたね。 失礼しました。 しかし、Return-Pathヘッダを元にセキュリティ対策を施すのは、皆さん仰っ ているような理由で難しいことは変わりないです。

[ △ ]

RE:09049 提案：Return-Pathと違う場合に	No.09055
Firak さん　02/09/21 16:28
ふぃらくです。 >たるっぱさん、SBNBです。 > > >>消去しないシステムがRFC違反かというと、そんなことはなく、実装 >>に任されていたはずです。 > >なるほど、消さなくても良いのですね。 >現状では受取人が簡単に差出人が分かる唯一の手がかりなので、全世界でウイルスに >は困っているはずなので、ひょっとすると削除しない方法へ進むかもしれませんね。 　というか、削除する実装の方が少ない、少なくともSendmailは、パラメータフ ァイルを変更してリコンパイルしないとできなかったと思います。 　 　昔、というかほんの数年前までは、Return-Pathは、何処かで一度設定された ら中継サーバでは、新たに付加しないのが原則でした。 　しかしスパム対策として、最終配送者がReturn-Pathを設定するというように 実装が変更されています。 　確かにメールの送達という点からは、届いてしまえばいらないヘッダですが、 最近はセキュリティ面から積極的に残す方が多いとおもいます。 　Sendmailは、ヘッダ中にReturn-Pathが記述されていても、削除して新たにエ ンベローブのFromを元に作成します。 　といっても、エンベローブのFromも直接Sendmailのコマンドをたたけば詐称で きますので、ウイルスがReturn-Pathを詐称するは、論理的には可能です。 　 　僕は、ウイルスメールを発見したら、Return-Pathを確認し、さらに最初に付 加されたReceived: を確認します。 　同じドメインの場合は、Return-Pathが本来の発生元として、そちらに警告を 送るようにしています。 　 　Return-PathとFromが異なった場合に、エラーを出すという実装をすると、僕 のようにFromを詐称して運用している人が結構いますから、ウイルスメールでは ないものからも警告が出るケースが多発すると思います。 　結局、オプションにしないといけないと思いますが、あえてオプションを付け てまで実装するメリットは感じません。 　 =========================== ふぃらく xxxxx@net.email.ne.jp ===========================

[ △ ]

RE:09050 提案：Return-Pathと違う場合に	No.09057
秀まるお2 さん　02/09/21 19:50
鶴亀メール作者の斉藤秀夫です。 　僕の xxxxxxxx@nifty.ne.jp には毎日多数のウィルスが届いてますが、特に完 全にウィルスを除去する振り分け設定を完成させている訳でもなく、振り分けさ れなかった物があったら振り分け条件を追加する作業を手でやってます。 　Return-Path:を利用してもやはり100%のチェックは無理ということで、これは これで貴重な情報ありがとうございます。 　とりあえず、「メールサイズが何々バイト以上なら」という振り分け条件をサ ポートして、さらに、リモートメールの所から振り分けアクション（例えばサー バーから削除とか）を実行できるようにしたいなぁということだけ考えてます。 　暇を見ていろいろ考えてみます。

[ △ ]

RE:09057 提案：Return-Pathと違う場合に	No.09064
秀まるお2 さん　02/09/22 21:47
その後気づいたんですけど、Return-Path:の内容とFrom:部分が違っていると いうのは、ウィルスチェックのヒントとしては使えるようには思います。現状の 振り分け設定ではそういう「XXXXヘッダとXXXXヘッダの中身が一致しない」のよ うな指定は出来ませんが、そういう事が出来ればウィルス除去のための強力な機 能になる可能性はあると思います。 　他にもContent-Type:ヘッダ中のBoundary=のクセとか、何か画期的な振り分け 方法があるのかもしれません。

[ △ ]

RE:09064 提案：Return-Pathと違う場合に	No.09065
SBNB さん　02/09/22 23:03
秀まるお2さん> SBNBです。 >そういう事が出来ればウィルス除去のための強力な機 >能になる可能性はあると思います。 力不足ですぐに実現できる話ではなくてすみません。 私自身はノートンにウイルスチェックさせて、そうするとレポートのテキストが添付 ファイルになるので、それを検出して、秀丸に渡して、ウイルス名などを取得してIP Aへの報告書を自動作成させています。 （良い振り分け条件があるのなら、それも良いですね） 詐称するメールについては、警告も出来きずにずっとほうってあったわけですが、ヘ ッダを見ていると何ヶ月も同じReturn-Pathから届くわけです。（頭に来て?）真剣に 調べたら、Return-Pathが送信者だと分かって、気づいてもらえたと言う事例があり ました。 某マイクロソフトのネットですと、サーバー管理者の方からも今まで気づいていなか ったと言う投稿がありまして、これって、メールソフトで検知したらなんて思いまし た。 >　他にもContent-Type:ヘッダ中のBoundary=のクセとか、何か画期的な振り分け方 >法があるのかもしれません。 何かいい案がないかとここにいらっしゃる詳しい皆さんとサイトー企画さんに期待し ています。今のところ、何か出来そうで出来ない感じですが、将来何かの役に立てば 嬉しいです。

[ △ ]

RE:09065 提案：Return-Pathと違う場合に	No.09076
秀まるお2 さん　02/09/22 23:44
うう、素早いコメントありがとうございます。 　僕個人は、現在のアンチウィルスソフトのようなやり方はいずれ破綻すると確 信しております。ただ、そう思ってはいるものの、他に適当な解決策があるかと 言えば、現状の鶴亀メールのようなやり方「実行可能添付ファイルを除去するや り方」しか思いつかないという情けない状況です。 　実は秀丸担当には別の仕事として、何か画期的なセキュリティ対策ソフトを開 発せよと指令を出した所です。個人的にも「PEH00775」宛に届くウィルス除去で かなり苦労させられてます。（３日放置するとメールボックスがパンクします） 　なんとかしたいと思う毎日ですが、とりあえず子守に追われてバグ修正の時間 すら取れない状況だったりします。（っといいつつなんだかんだで機能追加とか パソコンの静音化とかはしてるけど）

[ △ ]

RE:09076 提案：Return-Pathと違う場合に	No.09078
tnobu2 さん　02/09/23 00:28
他の方が書かれていたと思いますが、From:とReturn-Path:が違うのは メーリングリストではほとんど当たり前ですし、他のヘッダの内容から ウィルスが含まれているのを推定するのも困難だと思います。 実際には複数の条件から判断することになるのでしょうが、どういう条件 で警告するのかを判断するのは、日々変化し進化するウィルスには対応 しきれないでしょう。 判定条件を広げすぎると誤判定の警告がうるさくなりますし、逆に狭め すぎるとザルになってしまいます。 現在のアンチウィルスソフトの方法の是非はともかくとして、そういう 処理は、別ツールに任せるべきだと思います。 鶴亀メールでのウィルス対策は現状でも十分だと思います。

[ △ ]

RE:09046 提案：Return-Pathと違う場合に	No.09085
ながさわ さん　02/09/23 20:42
こんにちは、長澤です。 >ウイルススキャンソフトの会社のサイトなんかにあるの >でしょうか。 たいていのウィルス対策ソフトベンダは『差出人を詐称する』と書い てあると思いますが？　逆に『Return-Path:は詐称しない』なんて書 いてしまったが為に、お詫び文章を掲載するにまでなってしまった企 業はいくつかありますが（毎○新聞なんかだね）。 >私の送信実験では詐称は不可能でした。 え？ウィルスを作って送ったんですか!?（爆） >サーバー自体がウイルスにやら >れていれば可能かもしれませんが一般的なプロバイダでは無理ではないでしょうか。 そんな一般的なプロバイダを経由する差出人詐称ウィルスなんて太古 のお話をしていたんですか。 スミマセン。私はてっきり、今トレンドのSMTPエンジン搭載ウィルス などのお話だと思っていました。

[ △ ]

---