[SC-Help] Re: Spamvertised websites not being reported

[Mike Easter]

John Richards wrote:
> "Mike Easter"

>> www.spamcop.net/sc?id=z751591717zfa06fc1f8af24f8dc5f353a1671eae51z

>> If the nameservice is pokey, then SC can't do the DNS and so it
>> can't go to ripe, so you might've seen something different.

> Yeah, I saw something different (i.e. analysis failure), which is why
> I included the spamcop URL which documents what I saw.

Actually the tracker 'stores' the original spamitem, and then it
reparses the item when/each time/ the tracker is accessed;  so if the
result of a resolution or a lookup changes from one time to the next,
one person can see something different from another.

Which is why I pasted in the result of what I saw.

> If there is a problem with pokey nameservice, why doesn't spamcop's
> analysis say so, instead of leaving us in the blind.

All SC knows is that the hostname doesn't resolve [in a reasonable time
for the SC nameserver];  it doesn't know if the nameservice is pokey or
non-existent/dead, and it assumes non-existent.

If you want an analysis of the quality or speed or defects of the
nameservice, you have to research the target more than SC is going to
do.

What SC sez when it doesn't have time to fool with an item already
reported is:

Resolving link obfuscation
http://pharmacy.hgarcaj.ws/fjkghfdjk?yk.ku4tla1z8imsfklgjfg
http://pharmacy.hgarcaj.ws/?2q4w4a3rg7feomyhdfjkgh

Reports regarding this spam have already been sent:
Re: 220.117.34.234 (Administrator of network where email originates)
   Reportid: 1400903853 To: abuse at kornet.net
Re: Forwarded Spam (User defined recipient)
   Reportid: 1400903856 To: spam at uce.gov
Re: 220.117.34.234 (Third party interested in email source)
   Reportid: 1400903855 To: spamcop at imaphost.com

If reported today, reports would be sent to:
Re: 220.117.34.234 (Administrator of network where email originates)
abuse at kornet.net
Re: 220.117.34.234 (Third party interested in email source)
spamcop at imaphost.com

<no offfer to report the spamvertised sites>

... which indicates that it didn't report the spamvertised sites and
that it didn't resolve the hostname that time when I accessed the
tracker.

What you see during the parse, before the report, when it can't resolve
in a timely fashion is:

Finding links in message body
Recurse multipart:
   Parsing text part
   Parsing HTML part

Resolving link obfuscation
http://pharmacy.hgarcaj.ws/fjkghfdjk?yk.ku4tla1z8imsfklgjfg
http://pharmacy.hgarcaj.ws/?2q4w4a3rg7feomyhdfjkgh

Please make sure this email IS spam:

or, sometimes it will say that it can't resolve the item.

I don't know if the language of the verbose has changed lately.

> I don't recall this
> problem happening prior to a few months ago. Now it happens
> frequently.
> Something has changed.

Maybe it is bailing on some items sooner, right after it finds them and
sez "Resolving link obfuscation".

If it is 'behind' and has its priorities assigned to not be waiting very
long for spamvertiser resolution.

My opinion is that SC prioritizes source naming above spamvertiser
notification;  since its spamvertiser notification has no teeth and its
SCbl is an important function.

-- 
Mike Easter
kibitzer, not SC admin