ID-code:3i9klsdUSss

Gokurakuです。
以前の件を蒸し返してしまうような話で恐縮なのですが
対応済みと連絡があったはずのIPアドレスから再度迷惑メール
の発信があった件についての続報というか、回答が先方（Freebit）
からありました。
しかし私としてはいまいち納得のいかないので詳しい方にこういう
事があり得るのか教えて頂きたいと思い投稿します。

問題になっている事例はこのような物です
事例１：43.244.168.178からの発信
fbb.ReSET.JP [43.244.168.178]：Freebit直営ISPです。
12/20　20:15　着信
　　　　 22:10　報告
12/22　18:03　該当アカウントは利用停止にしたと連絡あり
12/28　06:05　再度同じIPアドレス[43.244.168.178]より発信あり

事例２：220.150.185.1　からの発信について
12/23　02:59着信→12/23　03:16報告
12/24　06:51着信→12/24　13:21報告
12/25　04:50着信→12/25　10:34報告
12/26　02:13着信→12/26　02:42報告
12/27　14:29　12/26報告の220.150.185.1のアカウントは「停止済み」
12/28　02:08着信→12/28　02:53報告
12/29　06:28着信→12/29　12:07報告

この点について同社に尋ねたところ
Q:貴社の対処済みとはどのようなことを言うのか？
A:弊社では、ご申告の対象となったお客様のアカウントをご利用
停止(*1)にしたのちに、 セッションが存在しているものについて
NTT東西にセッション切断の依頼をしております。
セッション切断作業が完了後にNTT東西より連絡を受け、弊社対応
部署よりご申告を いただいた方に対応結果のご報告を差し上げて
おります。
従いまして、作業手続き上は、対応結果ご報告後に同じお客様の
アカウントから迷惑メール送信が行われることは基本的にござい
ません。
*1　認証IDを無効にし、以降認証要求が通らない処理を行っております

ということだそうです。

そして上記事例の原因としては
「可能性としてはセッション切断前に送信されているメールが
　利用した送信サーバ内のキューに残っており、順次配信された
　ものであると思われます。」

とのことなのですが、私の疑問としては
１：こういったことは本当にあり得るのか
２：多くの場合自前で立てたメールサーバからの発信であるのに
　　セッションが切断された後でもキューが残っていたとして
　　それが送信されるのか？
という点です。
３：また、ごくまれな例外として
「他には稀にですが、複数セッションが存在していた場合に、
　セッションを見つけることができずに漏れが生じるケースが
　ございます。このようなケースでは発見後に再度セッションを
　切断します。」
と書いてあるのですが、こういうごくまれなケースがこう頻繁に
起こりうる物なのでしょうか？

以上の点、わかる方いらっしゃいましたらよろしくお願いいたします

ID-code:y1q6TpM29cI

複数セッションで同一のIPアドレスが割り振られる、というのは認証サーバの異常でもない限りあり得ないと思う
(そういうサービスはReset.jpを見る限り見当たらない)ので、
3のケースが起こりうるのは、前提条件としてFreeBitが単一アカウントの同一メディアでの複数ログインを許可しており、
1.IPアドレスと接続時間からアカウントを割り出し
2.当該アカウントから現在使用しているセッションを割り出し
3.NTTへ当該セッションの切断を依頼
という流れの中で、2の作業がいいかげんで当該IPアドレスのセッションと異なるセッションの切断を依頼した時のみ、ということになるかと。

単一アカウントの同一メディアでの複数ログインを許すと、極端な話多人数で一つのアカウントを使いまわし
できるわけですが、FreeBitってそんなに太っ腹なんでしょうか。

ID-code:oJCj8mad7QE

> この点について同社に尋ねたところ
> Q:貴社の対処済みとはどのようなことを言うのか？
> A:弊社では、ご申告の対象となったお客様のアカウントをご利用
> 停止(*1)にしたのちに、 セッションが存在しているものについて
> NTT東西にセッション切断の依頼をしております。
> セッション切断作業が完了後にNTT東西より連絡を受け、弊社対応
> 部署よりご申告を いただいた方に対応結果のご報告を差し上げて
> おります。
> 従いまして、作業手続き上は、対応結果ご報告後に同じお客様の
> アカウントから迷惑メール送信が行われることは基本的にござい
> ません。
> *1　認証IDを無効にし、以降認証要求が通らない処理を行っております
>
> ということだそうです。
>
> そして上記事例の原因としては
> 「可能性としてはセッション切断前に送信されているメールが
> 　利用した送信サーバ内のキューに残っており、順次配信された
> 　ものであると思われます。」

ただ単に、回答をした担当者が無知なのでしょう。
いい加減な回答ってのは、よくある事です。

> とのことなのですが、私の疑問としては
> １：こういったことは本当にあり得るのか
> ２：多くの場合自前で立てたメールサーバからの発信であるのに
> 　　セッションが切断された後でもキューが残っていたとして
> 　　それが送信されるのか？
> という点です。
> ３：また、ごくまれな例外として
> 「他には稀にですが、複数セッションが存在していた場合に、
> 　セッションを見つけることができずに漏れが生じるケースが
> 　ございます。このようなケースでは発見後に再度セッションを
> 　切断します。」
> と書いてあるのですが、こういうごくまれなケースがこう頻繁に
> 起こりうる物なのでしょうか？
>
> 以上の点、わかる方いらっしゃいましたらよろしくお願いいたします

ISPが対処済みのIPアドレスから再度　spamが届くと言うのは、そんなに珍しい事ではありません。
これは、対処が行われていない訳ではなく、アカウントを削除しても、ADSLなどで接続が継続されていた場合、接続が継続されてしまうのです。
これは、システム上の不具合の様で、色んな所から、同様の回答を頂いています。

ID-code:3i9klsdUSss

Gokurakuです。

antithesis様、黄泉様回答ありがとうございます。
やはり同社は対処フロー自体に問題があるというのは
間違いのないことのようですね。

黄泉様の回答でちょっとわからないところがあるのですが

> これは、対処が行われていない訳ではなく、アカウントを削除しても、ADSLなどで接続が継続されていた場合、接続が継続されてしまうのです。

この部分なのですが、これはセッションのことを言っておられるの
でしょうか？Freebitは「NTT東西に依頼してセッションを切断した
上で報告者に連絡している」と回答しているのですが

> これは、システム上の不具合の様で、色んな所から、同様の回答を頂いています。

これのいろんな所ということは、問題は各ISPではなくて常時接続
関連（特にＡＤＳＬ）のシステム（？）にあると理解すればよろしい
のでしょうか？

こういったことにはとことん疎いもので、お手数ですがよろしく
お願いいたします

ID-code:oJCj8mad7QE

> 黄泉様の回答でちょっとわからないところがあるのですが
>
> > これは、対処が行われていない訳ではなく、アカウントを削除しても、ADSLなどで接続が継続されていた場合、接続が継続されてしまうのです。
>
> この部分なのですが、これはセッションのことを言っておられるの
> でしょうか？Freebitは「NTT東西に依頼してセッションを切断した
> 上で報告者に連絡している」と回答しているのですが
セッションも含めたと言うのが正しいと思います。

> > これは、システム上の不具合の様で、色んな所から、同様の回答を頂いています。
>
> これのいろんな所ということは、問題は各ISPではなくて常時接続
> 関連（特にＡＤＳＬ）のシステム（？）にあると理解すればよろしいのでしょうか？
その通りです。

古くからspamの撲滅活動をしていた方の多くが、認知されている事象だと思います。
なので、特に驚く事では無いです。

とは言っても、私もインターネットへの接続を利用しているだけの立場に過ぎず、
その問題点の詳細は解りません。

ID-code:8Kp7IZG1uFQ

> そして上記事例の原因としては
> 「可能性としてはセッション切断前に送信されているメールが
> 　利用した送信サーバ内のキューに残っており、順次配信された
> 　ものであると思われます。」
>
> とのことなのですが、私の疑問としては
> １：こういったことは本当にあり得るのか
> ２：多くの場合自前で立てたメールサーバからの発信であるのに
> 　　セッションが切断された後でもキューが残っていたとして
> 　　それが送信されるのか？
> という点です

詳細はヘッダーを確認しないと判断できませんが、
セッション切断前に送信されたメールが、経路上のサーバー(通常、受信者のISPのサーバー)上で
遅延していたというのはあり得るでしょう。
ISPによってはユーザーが読み出すサーバーまで多段になっていることもあり、
SPAMが集中した時には数時間の遅延と言うのはめずらしくないと思います。
着信時刻ではなく、送信者が直接送信先のサーバーへ接続したと思われる時刻を
Receivedヘッダーから確認してみてはいかがでしょう。

ID-code:3i9klsdUSss

Gokurakuです。
ぺるしゃさんレスありがとうございます。
問題の３通分のヘッダはこのようになってます。
これを見る限りでは私にはそんなに遅延が起こっているようには思えません。
さらに言えば事例１では４日以上、事例２でも２日近くに達しており
これが遅延であった場合相当問題になりそうな遅延であると思うのですが、
いかがでしょうか？

事例１（12/28　06:05着信の物）

Return-Path: <5yuki_mlservice＠docomo.ne.jp>
Received: from localhost by ms36 with LMTP for <########＠rso-net.ne.jp>; Wed, 28 Dec 2005 06:05:42 +0900
Received: from sendmail.s1.ha (178.168.244.43.fbb.ReSET.JP [43.244.168.178])
by mx17.ms.so-net.ne.jp with ESMTP id jBRL5f4l009870
for <#########＠so-net.ne.jp>; Wed, 28 Dec 2005 06:05:41 +0900 (JST)
Received: from PC-G04 ([192.168.11.5])
by sendmail.s1.ha (8.12.8/8.12.8) with SMTP id jBRLGC6J008134
for <########＠so-net.ne.jp>; Wed, 28 Dec 2005 06:16:12 +0900
Date: Wed, 28 Dec 2005 06:16:12 +0900
Subject: =?ISO-2022-JP?B?jaGCt4KuiKeCpoLpjaGCt4Kug4SC6oLpgUmCtYKpguCWs5e/gUmCu4LxgsiCzILBgsSBY4FJgUg=?=
From: 5yuki_mlservice＠docomo.ne.jp
To: ########＠so-net.ne.jp
Message-ID: 20051228060217
Content-Type: text/plain; charset="SHIFT_JIS"
Content-Transfer-Encoding: 7bit
MIME-Version: 1.0


事例２（12/28　02:08着信の物）
Return-Path: <bnoanoa14＠55mail.cc>
Received: from localhost by ms36 with LMTP for <########＠so-net.ne.jp>; Wed, 28 Dec 2005 02:08:02 +0900
Received: from hyper_s_class552158754_lookserver772_serebusystem03_woman-s-class.tv (1.185.150.220.ap.yournet.ne.jp [220.150.185.1])
by mx16.ms.so-net.ne.jp with SMTP id jBRH81RN029360
for <########＠so-net.ne.jp>; Wed, 28 Dec 2005 02:08:01 +0900 (JST)
Date: Wed, 28 Dec 2005 02:08:01 +0900 (JST)
Delivered-To: <########＠so-net.ne.jp>
Received: from unknown (HELO serebusystem03_woman-s-class.tv) (524.687.587.954) by 0 with SMTP;28 Dec 2005 6:19:24 +0900
Message-ID: 20051228013119.72985mail＠mail.hyper_s_class552158754_lookserver772_serebusystem03_woman-s-class.tv
From: bnoanoa14＠55mail.cc
To: #########＠so-net.ne.jp
Subject: =?iso-2022-jp?B?SBskQiRLNj1MIyROJCIkaz9NSn0kS08vSnMbKEI=?=
MIME-Version: 1.0
Content-Type: text/plain;
charset="iso-2022-jp"
Content-Transfer-Encoding: 7bit


（12/29　06:28着信）
Return-Path: <d_sarina1＠yahoo.co.jp>
Received: from localhost by ms36 with LMTP for <#########＠so-net.ne.jp>; Thu, 29 Dec 2005 06:28:07 +0900
Received: from lovelove-kameriasex552158754_lookserver772_womansystem01_woman-kameria-love.tv (1.185.150.220.ap.yournet.ne.jp [220.150.185.1])
by mx23.ms.so-net.ne.jp with SMTP id jBSLS6gK012929
for <#########＠so-net.ne.jp>; Thu, 29 Dec 2005 06:28:06 +0900 (JST)
Date: Thu, 29 Dec 2005 06:28:06 +0900 (JST)
Delivered-To: <#########＠so-net.ne.jp>
Received: from unknown (HELO system1_woman-kameria-love.tv) (158.125.452.357) by 0 with SMTP;29 Dce 2005 6:19:24 +0900
Message-ID: 20051229055108.59055mail＠mail.lovelove-kameriasex552158754_lookserver772_womansystem01_woman-kameria-love.tv
From: d_sarina1＠yahoo.co.jp
To: #########＠so-net.ne.jp
Subject: =?iso-2022-jp?B?GyRCIVo/SEJON0BMcyFbM1okNyRGNEpDMTliPH1GfhsoQg==?=
MIME-Version: 1.0
Content-Type: text/plain;
charset="iso-2022-jp"
Content-Transfer-Encoding: 7bit

ID-code:8Kp7IZG1uFQ

> これを見る限りでは私にはそんなに遅延が起こっているようには思えません。
> さらに言えば事例１では４日以上、事例２でも２日近くに達しており
> これが遅延であった場合相当問題になりそうな遅延であると思うのですが、
> いかがでしょうか？

確かに遅延は起こっていないようですね。

>Received: from sendmail.s1.ha (178.168.244.43.fbb.ReSET.JP [43.244.168.178])
>by mx17.ms.so-net.ne.jp with ESMTP id jBRL5f4l009870
>for <#########＠so-net.ne.jp>; Wed, 28 Dec 2005 06:05:41 +0900 (JST)

この部分がスパマーがso-netのサーバーに直送をした時刻ですね。
明らかに、43.244.168.178というIPアドレスを持つ端末がネット上に存在していたことを意味します。
「28 Dec 2005」はGokurakuさんが対処報告を受け取った後ですね。

考えられることは
・so-netの時計が狂っている
　　これはまずありえないでしょうね。スパマーのPCの時計はかなり狂っているようですが。
・アカウント停止後、他のアカウントで接続したら同じIPだった
　　可能性は低そうで意外と高いかも。
　　ISPにもよりますが、地域ごとに付与されるIPアドレス範囲が決まっていることが多いようです。
　　したがって、アジトを移動せずに別契約で繋げば同じIPアドレスが付与される可能性もあるということです。
　　実際、GoogleでこのIPアドレスを検索すると、何パターンかの晒し物が見つかります。
・フリービットが嘘の回答をしている
　　これは何とも言えないですね。でも、報告の内容を疑いだすと何もできなくなってしまう気も。
こんなところでしょうか。

ただ、少なくともヘッダーを見た限りでは、Gokurakuさんへの回答にあった
>「可能性としてはセッション切断前に送信されているメールが
> 利用した送信サーバ内のキューに残っており、順次配信された
> ものであると思われます。」
これはまずありえないと考えます。

>「他には稀にですが、複数セッションが存在していた場合に、
>　セッションを見つけることができずに漏れが生じるケースが
>　ございます。このようなケースでは発見後に再度セッションを
>　切断します。」
> と書いてあるのですが、こういうごくまれなケースがこう頻繁に
> 起こりうる物なのでしょうか？

どのような送信システムを使っているかにも左右されるのではないでしょうか。
多数のセッションを張るようなシステムが(スパマーの間で)普及しているなら
そういうこともあるのかもしれません。

確かにフリービットの対応には疑問の残るところが多いですが、
あまりに疑心暗鬼になりすぎると、SPAMをなくすための活動を続けていく気力を無くしてしまいそうで、そちらの方が気がかりです。