Jump to content

URLs not reported


trpted

Recommended Posts

Are you going to state that the original e-mail looks anything like what I just looked at in the provided Tracking URL (then clicking on the "View entire message" link) ... I sure don't recognize the format of the body content, espcially when looking at it as something for the parser to chew on ....

A bit later: second link posted while typing my response to the first post .... second link is not a Tracking URL, only the display .... no data to work with, other than going with what I thought I was originally going to do .. Merge this Topic into the existing one dealing with body URL parsing results ....

Link to comment
Share on other sites

  • Replies 147
  • Created
  • Last Reply

heym0n, I don't think you have the full headers. Some Received: lines are missing. The spam you posted only has a Received: line that look like a forgery. Somehow you need to get your system to reveal the full headers, including the Received: line that links the whole thing to the servers in your mailhost configuration.

Alternatively, maybe your server configuration has changed and you need to update your mailhosts, or you received this on an account that you have not yet properly registered with mailhosts?

second link is not a Tracking URL, only the display .... no data to work with
I got the normal tracking URL by removing the ";action=display" from the posted link. It turns out to be the same message, just with all the HTML removed :)
Link to comment
Share on other sites

heym0n,

Are you a USA.NET Customer or a Net[at]ddress Registered User?

Do you normally get email with just one Received Header Line that was Received "by usa.net"?

What email client are you using, on what OS?

Thanks!

Link to comment
Share on other sites

Got another one here... SC doesn't find any URLs in the body, but there ARE URLs....

Tracking URL: http://www.spamcop.net/sc?id=z745788701zed...ce47d97566c42bz

Spamvertised URL:

http://sfbeiradg.net/uMi01tMOsN23nCw406oYK...BAT4=.htm"

And it does appear to be up and running:

$ host sfbeiradg.net

sfbeiradg.net has address 222.36.41.209

$ ping sfbeiradg.net

PING sfbeiradg.net (219.153.0.200) 56(84) bytes of data.

64 bytes from 219.153.0.200: icmp_seq=0 ttl=43 time=865 ms

64 bytes from 219.153.0.200: icmp_seq=1 ttl=43 time=864 ms

Not sure if THAT particular page is up and running as I was going to use Links to try and pull it up and it didn't seem to want to come up immediately so I cancelled it.

Still, my contention is that SC is being "tricked" by spammers using mangled mime headers as follows:

[snip headers]

Received: from columbuslogistics.it (mail.columbuslogistics.it [81.208.124.42])

by imagineeringart.com with esmtp

id 488BDD8A76 for <jaldrich[at]covista.com>; Thu, 24 Mar 2005 23:38:23 -0800

Message-ID: <100101c5310d$7f5eef75$5cdae305[at]columbuslogistics.it>

From: "Casanova R. Locals" <postmarks[at]columbuslogistics.it>

To: x

Subject: Reply: the most cheap Cialis, Viagra delivreed fast

Date: Thu, 24 Mar 2005 23:38:23 -0800

MIME-Version: 1.0

Content-Type: multipart/alternative;

boundary="----=_NextPart_000_0006_7B517CEE.4896FE59"

X-Priority: 3

X-MSMail-Priority: Normal

X-Mailer: Microsoft Outlook Express 6.00.2800.1437

X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1165

X-AntiVirus: Checked by Dr.Web (http://www.drweb.net)

This is a multi-part message in MIME format.

------=_NextPart_000_0006_7B517CEE.4896FE59

Content-Type: text/plain

Content-Transfer-Encoding: 7bit

------=_NextPart_000_0006_7B517CEE.4896FE59

Content-Type: text/html

Content-Transfer-Encoding: quoted-printable

------=_NextPart_000_0006_7B517CEE.4896FE59--

<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.0 Transitional//EN">

<HTML><HEAD>

<META HTTP-EQUIV="Content-Type" CONTENT="text/html; charset=Windows-1252">

[snip body]

As you can see, there are "extra" mime headers, which is probably designed to break SC but show up just fine in MS Lookout and LookOut Express, etc.

A SamSpade browser session reveals that the spamvertised URL is just forwarded using dns-forward2.com to freehostedpages.com.

I LARTed everyone I could find related to the dns-forward, the original URL and the end URL. Hopefully this site will be closed down completely, not just the referring page!

Link to comment
Share on other sites

For me, right now, that domain resolved to 218.7.112.242 and is not pingable:

C:\>ping sfbeiradg.net

Pinging sfbeiradg.net [218.7.112.242] with 32 bytes of data:

Request timed out.

Request timed out.

Request timed out.

Request timed out.

Ping statistics for 218.7.112.242:

Packets: Sent = 4, Received = 0, Lost = 4 (100% loss),

C:\>

Link to comment
Share on other sites

It resolves fine from my location, in the same way as posted my mrmaxx. The problem is that SpamCop does not even see the URL and therefore does not try to resolve it.

The culprit is this one extra MIME line:

------=_NextPart_000_0006_7B517CEE.4896FE59--

When you take it out, SpamCop suddenly finds the link just fine:

http://www.spamcop.net/sc?id=z745815702z76...91e517973c6429z

Link to comment
Share on other sites

Got another one here... SC doesn't find any URLs in the body, but there ARE URLs....

Tracking URL: http://www.spamcop.net/sc?id=z745788701zed...ce47d97566c42bz

Still, my contention is that SC is being "tricked" by spammers using mangled mime headers as follows:

[snip headers]

Content-Type: multipart/alternative;

boundary="----=_NextPart_000_0006_7B517CEE.4896FE59"

[snipped even further]

This is a multi-part message in MIME format.

------=_NextPart_000_0006_7B517CEE.4896FE59

Content-Type: text/plain

Content-Transfer-Encoding: 7bit

------=_NextPart_000_0006_7B517CEE.4896FE59

Content-Type: text/html

Content-Transfer-Encoding: quoted-printable

------=_NextPart_000_0006_7B517CEE.4896FE59--

<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.0 Transitional//EN">

<HTML><HEAD>

<META HTTP-EQUIV="Content-Type" CONTENT="text/html; charset=Windows-1252">

[snip body]

As you can see, there are "extra" mime headers, which is probably designed to break SC but show up just fine in MS Lookout and LookOut Express, etc.

It's not "mangled MIME headers, it's an issue with the cinstruct of the spam (body) itself.

It resolves fine from my location, in the same way as posted my mrmaxx. The problem is that SpamCop does not even see the URL and therefore does not try to resolve it.

The culprit is this one extra MIME line:

------=_NextPart_000_0006_7B517CEE.4896FE59--

When you take it out, SpamCop suddenly finds the link just fine:

http://www.spamcop.net/sc?id=z745815702z76...91e517973c6429z

Which of course runs afoul of the "material alteration" rule. Granted that there is data existing, and it is spammer material, but .... properly rendered by an e-mail client, this would/should appear as a "blank" e-mail wih an HTML attachment. The parser is seeing this "end boundary" line and following normal RFC standards, is making the call that the "end of the message" has been found. Not trying to discount all the other issues, just pointing out that the recipient of this particular spam shouldn't be able to see the spamvertised URLs either. (Whereas in my case, receiving and looking at e-mail "as Plain Text only" I do see the spam contents and notice this 'problem' right off the bat.)

Link to comment
Share on other sites

It's not "mangled MIME headers, it's an issue with the cinstruct of the spam (body) itself.

Which of course runs afoul of the "material alteration" rule.  Granted that there is data existing, and it is spammer material, but .... properly rendered by an e-mail client, this would/should appear as a "blank" e-mail wih an HTML attachment.  The parser is seeing this "end boundary" line and following normal RFC standards, is making the call that the "end of the message" has been found.  Not trying to discount all the other issues, just pointing out that the recipient of this particular spam shouldn't be able to see the spamvertised URLs either.  (Whereas in my case, receiving and looking at e-mail "as Plain Text only" I do see the spam contents and notice this 'problem' right off the bat.)

25976[/snapback]

Well, I hate to be the bearer of bad news, Wazoo, but it shows up just fine here in my MS LookOut 2000 client. Maybe you can pass the word on to Julian, et al that the spammers appear to be intentionally breaking SC by adding extra mime headers. Maybe the parser could be tweaked a bit to look for more data past these extra mime headers??? I think it's pretty clear now that spammers know how SC works and are trying to get around it by doing stuff so that the spam actually works but SC doesn't parse it correctly.

Link to comment
Share on other sites

Which of course runs afoul of the "material alteration" rule.

Which is why I cancelled the report (and of course, it's not my own spam) :) .

Does it make a difference that the MIME boundary that Outlook seems to overlook has "--" in the end, unlike the boundary defined in the header and used in other places in the same message?

EDIT: I just looked it up. It means that this was the final body part. So it looks like a bug in Outlook if it overruns this?

Link to comment
Share on other sites

Does it make a difference that the MIME boundary that Outlook seems to overlook has "--" in the end, unlike the boundary defined in the header and used in other places in the same message?

25978[/snapback]

Yes. The trailing -- indicates "no further body parts will follow". You should contact Mcrosoft and explain that there is a security risk in the way they are handling MIME boundries.

According to the RFC I found with this information, there may be newer RFC's covering this, however: http://www.faqs.org/rfcs/rfc1521.html

The encapsulation boundary following the last body part is a

distinguished delimiter that indicates that no further body parts

will follow.  Such a delimiter is identical to the previous

delimiters, with the addition of two more hyphens at the end of the

line:

              --gc0p4Jq0M2Yt08jU534c0p--

Link to comment
Share on other sites

Thanks for clarifying this. RFC 1521 looks obsolete and has been replaced by RFC 2046 (and other RFCs). It preserves the language you quoted. Further down it says:

There appears to be room for additional information prior to the

first boundary delimiter line and following the final boundary

delimiter line.  These areas should generally be left blank, and

implementations must ignore anything that appears before the first

boundary delimiter line or after the last one.

(emphasis added). So SpamCop seems to be doing it right and Outlook doing it wrong.
Link to comment
Share on other sites

Well, I hate to be the bearer of bad news, Wazoo, but it shows up just fine here in my MS LookOut 2000 client.  Maybe you can pass the word on to Julian, et al that the spammers appear to be intentionally breaking SC by adding extra mime headers. Maybe the parser could be tweaked a bit to look for more data past these extra mime headers??? I think it's pretty clear now that spammers know how SC works and are trying to get around it by doing stuff so that the spam actually works but SC doesn't parse it correctly.

I'm having some issues parsing this bit of additional data. I took another look at your Tracking URL and I don't see the normal signs of the provided spam having been processed by the "two-part entry form" that was developed as a hack to get around the MIME handling issues of Outlook ..??? (Pointing out that Julian knows only too well the problems with MIME) .. Thus, I'm left wondering how you are actually obtaining the spam that has the MIME lines mis-positioned and further, how are you submitting these spam items? There may be much more to this part of the "missing the URLs" in this case.

Link to comment
Share on other sites

Thanks for clarifying this. RFC 1521 looks obsolete and has been replaced by RFC 2046 (and other RFCs). It preserves the language you quoted. Further down it says:

<snip>

So SpamCop seems to be doing it right and Outlook doing it wrong.

25981[/snapback]

...Shocking, absolutely shocking!! :D <big g>
Link to comment
Share on other sites

mrmaxx, maybe you can solve your problem by updating Outlook. I have tested the exact message you posted, and it comes up as completely blank for me in the most recent versions of Outlook and Outlook Express. These programs now seem to respect the MIME specifications just fine and ignore everything behind the final boundary delimiter.

The good news is, if the spam was really sent as posted, the spammer has wasted his time for all recipients who have properly working email clients :P

Link to comment
Share on other sites

kind of silly to make another posting to simply add another URL (with no corresponfing Tracking URL??) .. so I snagged the data from your second post (which also didn't 'need' the previous post quoted in full) .. added that data to the first post .. deleted the second ... then started looking stuff up ...

whois -h whois.crsnic.net ok-ref-yes.net ...

Redirecting to COMPUTER SERVICES LANGENBACH GMBH DBA JOKER.COM

whois -h whois.joker.com ok-ref-yes.net ...

domain: ok-ref-yes.net

status: lock

organization: DL Int

owner: David Learner

email: davidlearner007[at]yahoo.com

address: 15 Hillview Gardens

city: London

state: --

postal-code: NW4 2JJ

country: GB

admin-c: davidlearner007[at]yahoo.com#0

tech-c: davidlearner007[at]yahoo.com#0

billing-c: davidlearner007[at]yahoo.com#0

nserver: ns1.educate-2.com

nserver: ns2.educate-2.com

registrar: JORE-1

created: 2005-03-22 00:45:52 UTC JORE-1

modified: 2005-03-23 14:59:29 UTC JORE-1

expires: 2006-03-21 19:45:52 UTC

source: joker.com

Take care of the Yahoo e-mail address, then contact GoDaddy ....

03/25/05 23:51:30 Slow traceroute www.ok-ref-yes.net

Trace www.ok-ref-yes.net (221.5.250.111) ...

219.158.3.77 RTT: 218ms TTL: 16 (No rDNS)

219.158.10.106 RTT: 246ms TTL: 16 (No rDNS)

221.5.254.106 RTT: 243ms TTL: 16 (No rDNS)

221.5.254.3 RTT: 413ms TTL: 16 (No rDNS)

221.5.254.162 RTT: 243ms TTL: 16 (No rDNS)

221.5.248.219 RTT: 414ms TTL: 16 (No rDNS)

221.5.250.111 RTT: 417ms TTL:112 (ok-ref-yes.net ok)

Note the very slow reaction time involved in getting there ...

03/25/05 23:53:00 Browsing http://www.ok-ref-yes.net/

Fetching http://www.ok-ref-yes.net/ ...

GET / HTTP/1.1

Host: www.ok-ref-yes.net

<html><head><title>The American Refinance Mortgage Specialist</title>

Complaint to the FTC at least?

whois -h whois.opensrs.net guzzling.net ...

Registrant:

NA

Berggasse 19

Wien, na A-1090

AT

Domain name: GUZZLING.NET

Administrative Contact:

Zenger, Mathias zabavno2k[at]yahoo.com

Berggasse 19

Wien, na A-1090

AT

+43.131945317

Technical Contact:

Zenger, Mathias zabavno2k[at]yahoo.com

Berggasse 19

Wien, na A-1090

AT

+43.131945317

Registration Service Provider:

Tucows/Opensrs, sales[at]opensrs.org

416-535-0123

http://referrals.tucows.com/

Registrar of Record: TUCOWS, INC.

Record last updated on 17-Mar-2005.

Record expires on 24-Feb-2006.

Record created on 24-Feb-2005.

Domain servers in listed order:

NS1.ALON587.COM 219.138.7.185

NS2.ALON587.COM 219.138.7.186

Domain status: ACTIVE

pretty much the same as above .... However, some of it may have already been accomplished?

03/26/05 00:05:36 Slow traceroute guzzling.net

Trace guzzling.net failed, no such host

03/26/05 00:06:39 Browsing http://guzzling.net/

Host guzzling.net doesn't exist, trying 127.0.0.1 instead

Link to comment
Share on other sites

03/26/05 00:06:39 Browsing http://guzzling.net/

Host guzzling.net doesn't exist, trying 127.0.0.1 instead

25995[/snapback]

May be silly, but I thought I was paying to have spamcop lookup this stuff. I have looked up everything you mention here and got the same results, except one, http://guzzling.net.

Server Used: [ whois.opensrs.net ]

guzzling.net = [ 222.47.183.57 ] Registrant:

NA

Berggasse 19

Wien na A-1090

AT

Domain name: GUZZLING.NET

Administrative Contact:

Zenger Mathias zabavno2k[at]yahoo.com

Berggasse 19

Wien na A-1090

AT

43.131945317

Technical Contact:

Zenger Mathias zabavno2k[at]yahoo.com

Berggasse 19

Wien na A-1090

AT

43.131945317

Registration Service Provider:

Tucows/Opensrs sales[at]opensrs.org

416-535-0123

http://referrals.tucows.com/

Registrar of Record: TUCOWS INC.

Record last updated on 17-Mar-2005.

Record expires on 24-Feb-2006.

Record created on 24-Feb-2005.

Domain servers in listed order:

NS1.ALON587.COM 219.138.7.185

NS2.ALON587.COM 219.138.7.186

Domain status: ACTIVE

222.47.183.57 = [ ]

inetnum: 222.32.0.0 - 222.63.255.255

netname: CRTC

descr: CHINA RAILWAY TELECOMMUNICATIONS CENTER

descr: 22F Yuetan Mansion Xicheng District Beijing P.R.China

country: CN

admin-c: LQ112-AP

tech-c: LM273-AP

status: ALLOCATED PORTABLE

changed: hm-changed[at]apnic.net 20030902

mnt-by: MAINT-CNNIC-AP

mnt-lower: MAINT-CN-CRTC

mnt-routes: MAINT-CN-CRTC

source: APNIC

route: 222.32.0.0/11

descr: CHINA RAILWAY TELECOMMUNICATIONS

country: CN

origin: AS9394

mnt-by: MAINT-CN-CRTC

changed: wangpei[at]crc.net.cn 20040402

source: APNIC

person: LV QIANG

nic-hdl: LQ112-AP

e-mail: crnet_mgr[at]chinatietong.com

address: 22F Yuetan Mansion Xicheng District Beijing P.R.China

phone: 86-10-51890499

fax-no: 86-10-51890674

country: CN

changed: ipas[at]cnnic.net.cn 20041208

mnt-by: MAINT-CNNIC-AP

source: APNIC

person: liu min

nic-hdl: LM273-AP

e-mail: crnet_tec[at]chinatietong.com

address: 22F Yuetan Mansion Xicheng District Beijing P.R.China

phone: 86-10-51848796

fax-no: 86-10-51842426

country: CN

changed: ipas[at]cnnic.net.cn 20041208

mnt-by: MAINT-CNNIC-AP

source: APNIC

Spamcop can not resolve this and return these results, but I can...

Just wondering what is going on...

Link to comment
Share on other sites

Please forgive me if this is the wrong place to post this...

I got a reply from spamcop about a spam I reported...here it is....

SpamCop v 1.418.2.2 © Ironport Systems Inc., 1998-2005 , All rights reserved.

Here is your TRACKING URL - it may be saved for future reference:

http://www.spamcop.net/sc?id=z746102558z3b...52dcdbbcf35aadz

Tracking message source: 24.203.217.72:

Routing details for 24.203.217.72

[refresh/show] Cached whois for 24.203.217.72 : abuse[at]videotron.ca

Using abuse net on abuse[at]videotron.ca

abuse net videotron.ca = abuse[at]videotron.ca

Using best contacts abuse[at]videotron.ca

ISP has indicated spam will cease; ISP resolved this issue sometime after Saturday, March 26, 2005 8:50:49 AM -0600

Message is 2 hours old

24.203.217.72 not listed in dnsbl.njabl.org

24.203.217.72 not listed in dnsbl.njabl.org

24.203.217.72 listed in cbl.abuseat.org ( 127.0.0.2 )

24.203.217.72 is an open proxy

24.203.217.72 not listed in query.bondedsender.org

24.203.217.72 not listed in iadb.isipp.com

Finding links in message body

Parsing HTML part

Resolving link obfuscation

http://iefgqellmnautfhw.jmbeheldgm.ws/?hwp...fctlgdbhbelbfas

http://hczvirysmgwxzfqh1qng401ygxjqy21.elreposteg.ws/

host hczvirysmgwxzfqh1qng401ygxjqy21.elreposteg.ws (checking ip) = 222.51.91.252

host 222.51.91.252 (getting name) no name

http://azwpdheieqrckewxpwtmao74m3pw4qp.jmbeheldgm.ws/

http://wfopfhtbdkogaess1qng401ygxjqy21.elreposteg.ws/

host wfopfhtbdkogaess1qng401ygxjqy21.elreposteg.ws (checking ip) = 200.149.11.61

host 200.149.11.61 (getting name) no name

http://fkabkpvuhchqazsf.elreposteg.ws/?apc...itygatzmfkhyuze

host fkabkpvuhchqazsf.elreposteg.ws (checking ip) = 222.47.183.53

host 222.47.183.53 (getting name) no name

http://soiewzwlfviydofc.elreposteg.ws/?apc...hvyzvtnyiikkldf

host soiewzwlfviydofc.elreposteg.ws (checking ip) = 222.51.91.252

host 222.51.91.252 (getting name) no name

Tracking link: http://hczvirysmgwxzfqh1qng401ygxjqy21.elreposteg.ws/

No recent reports, no history available

Resolves to 222.51.91.252

Routing details for 222.51.91.252

[refresh/show] Cached whois for 222.51.91.252 : crnet_mgr[at]chinatietong.com crnet_tec[at]chinatietong.com

Using abuse net on crnet_mgr[at]chinatietong.com

abuse net chinatietong.com = postmaster[at]chinatietong.com, crnet_mgr[at]chinatietong.com, crnet_tec[at]chinatietong.com

Using best contacts postmaster[at]chinatietong.com crnet_mgr[at]chinatietong.com crnet_tec[at]chinatietong.com

Tracking link: http://wfopfhtbdkogaess1qng401ygxjqy21.elreposteg.ws/

No recent reports, no history available

Resolves to 200.149.11.61

Routing details for 200.149.11.61

[refresh/show] Cached whois for 200.149.11.61 : mail-abuse[at]nic.br fneves[at]registro.br

Using abuse net on mail-abuse[at]nic.br

abuse net nic.br = mail-abuse[at]nic.br, antispambr[at]abuse.net, postmaster[at]nic.br

Using best contacts mail-abuse[at]nic.br antispambr[at]abuse.net postmaster[at]nic.br

antispambr[at]abuse.net redirects to spambr[at]admin.spamcop.net

I refuse to bother postmaster[at]nic.br

Tracking link: http://fkabkpvuhchqazsf.elreposteg.ws/?apc...itygatzmfkhyuze

No recent reports, no history available

Resolves to 222.47.183.53

Routing details for 222.47.183.53

[refresh/show] Cached whois for 222.47.183.53 : crnet_mgr[at]chinatietong.com crnet_tec[at]chinatietong.com

Using abuse net on crnet_mgr[at]chinatietong.com

abuse net chinatietong.com = postmaster[at]chinatietong.com, crnet_mgr[at]chinatietong.com, crnet_tec[at]chinatietong.com

Using best contacts postmaster[at]chinatietong.com crnet_mgr[at]chinatietong.com crnet_tec[at]chinatietong.com

Tracking link: http://soiewzwlfviydofc.elreposteg.ws/?apc...hvyzvtnyiikkldf

No recent reports, no history available

Resolves to 222.51.91.252

Routing details for 222.51.91.252

[refresh/show] Cached whois for 222.51.91.252 : crnet_mgr[at]chinatietong.com crnet_tec[at]chinatietong.com

Using abuse net on crnet_mgr[at]chinatietong.com

abuse net chinatietong.com = postmaster[at]chinatietong.com, crnet_mgr[at]chinatietong.com, crnet_tec[at]chinatietong.com

Using best contacts postmaster[at]chinatietong.com crnet_mgr[at]chinatietong.com crnet_tec[at]chinatietong.com

Finding IP block owner:

Routing details for 24.203.217.72

[refresh/show] Cached whois for 24.203.217.72 : abuse[at]videotron.ca

Using abuse net on abuse[at]videotron.ca

abuse net videotron.ca = abuse[at]videotron.ca

Using best contacts abuse[at]videotron.ca

If reported today, reports would be sent to:

Re: 24.203.217.72 (Administrator of IP block - statistics only)

abuse[at]videotron.ca

Re: 24.203.217.72 (Third party interested in email source)

spamcop[at]imaphost.com

Re: http://fkabkpvuhchqazsf.elreposteg.ws/?apcfcra9... (Administrator of network hosting website referenced in spam)

postmaster[at]chinatietong.com

crnet_mgr[at]chinatietong.com

crnet_tec[at]chinatietong.com

Re: http://hczvirysmgwxzfqh1qng401ygxjqy21.elrepost... (Administrator of network hosting website referenced in spam)

postmaster[at]chinatietong.com

crnet_mgr[at]chinatietong.com

crnet_tec[at]chinatietong.com

Re: http://soiewzwlfviydofc.elreposteg.ws/?apcfcra9... (Administrator of network hosting website referenced in spam)

postmaster[at]chinatietong.com

crnet_mgr[at]chinatietong.com

crnet_tec[at]chinatietong.com

Re: http://wfopfhtbdkogaess1qng401ygxjqy21.elrepost... (Administrator of network hosting website referenced in spam)

Internal spamcop handling: (spambr)

mail-abuse[at]nic.br

My question is why was this not reported?? The isp said the spam would cease but it obviously Has not!! Do we just take the isp's word for it and stop reporting?? They can continue to send spam now without getting reports?? I am confused about this...if the spam had stopped why and I still getting it?? Thanks in advance for your time.

Link to comment
Share on other sites

berry, you got the spam before the ISP said they fixed it, please chill out. :)

26008[/snapback]

I dont' know what you mean by "chill out." But I got another one TODAY. Fixed it huh?? So before I "chill out" could someone that has some REAL advice please tell me why this is happening?? Also why is this forum so full of idiots?? "Chill out." Thats real intelligent advice. I suggest you go back to your Jr. High homework and leave the forum to adults. "Chill out." Haven't heard that one since I was 12. Nice.

Link to comment
Share on other sites

But I got another one TODAY.

You got spam from the exact same source (24.203.217.72) and the date it was sent (not when you received it) was after March 26, 2005 8:50:49 AM -0600? Please post the tracking URL only please.

From your original:

0: Received: from 24.203.217.72 (HELO modemcable072.217-203-24.mc.videotron.ca) (24.203.217.72) by mta305.mail.scd.yahoo.com with SMTP; Sat, 26 Mar 2005 05:05:11 -0800 (25-mar-2005:21:05:11)

ISP has indicated spam will cease; ISP resolved this issue sometime after Saturday, March 26, 2005 8:50:49 AM -0600 (26-mar-2005:02:50:49)

As Jeff stated, the spam was sent to you almost 6 hours before the ISP took action. That is actually pretty good response time from an ISP. If you are a paid account holder, you are allowed to appeal the ISP response if nobody has appealed the ISP response already. In that case a deputy will look over the evidence and start sending reports again, but the timing needs to be correct.

Link to comment
Share on other sites

Actually, it appears that the spam was sent 1 hour 45 minutes 38 seconds before the ISP said the issue was fixed. The spam was sent Sat, 26 Mar 2005 05:05:11 -0800 (13:05:11 UTC), and the ISP indicated spam woul cease after Saturday, March 26, 2005 8:50:49 AM -0600 (14:50:49 UTC).

And if berryproud uses an ad-hominem attack here or via PM again, or emails me, it will be reported.

Link to comment
Share on other sites

Jeff, I know you did not mean it that way, but in some circles asking someone to "chill out" or to "calm down" is considered an insult. The English language is used in many different ways by different people, and sometimes such misunderstandings occur. I guess the best we can do is to try to follow the tips in the FAQs, especially numbers 4 and 7.

As for the time stamping, if you look at the tracker now the time when the ISP resolved the issue seems to have changed:

ISP has indicated spam will cease; ISP resolved this issue sometime after Sunday, March 27, 2005 05:49:40 -0500

Does that mean that this was appealed and then the ISP reported again to have resolved this issue?

A suggestion: Would it make sense to set up the system in such a way that a message with a time stamp that clearly indicates that it was sent after the ISP resolved the issue triggers an automatic appeal? After all, it is clear evidence that the issue was not resolved.

Link to comment
Share on other sites

Archived

This topic is now archived and is closed to further replies.


×
×
  • Create New...