Wazoo Posted March 24, 2005 Share Posted March 24, 2005 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 More sharing options...
swingspacers Posted March 24, 2005 Share Posted March 24, 2005 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 withI 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 More sharing options...
heym0n Posted March 24, 2005 Share Posted March 24, 2005 I too have been coming across spam that comes up nothing to do from spamcop but what I found out to work is by waiting a few minutes later and spamcop reports it correctly. Link to comment Share on other sites More sharing options...
Jeff G. Posted March 24, 2005 Share Posted March 24, 2005 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 More sharing options...
mrmaxx Posted March 25, 2005 Share Posted March 25, 2005 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 More sharing options...
StevenUnderwood Posted March 25, 2005 Share Posted March 25, 2005 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 More sharing options...
swingspacers Posted March 25, 2005 Share Posted March 25, 2005 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 More sharing options...
Wazoo Posted March 25, 2005 Share Posted March 25, 2005 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 More sharing options...
mrmaxx Posted March 25, 2005 Share Posted March 25, 2005 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 More sharing options...
swingspacers Posted March 25, 2005 Share Posted March 25, 2005 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 More sharing options...
StevenUnderwood Posted March 25, 2005 Share Posted March 25, 2005 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 More sharing options...
swingspacers Posted March 25, 2005 Share Posted March 25, 2005 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 More sharing options...
Wazoo Posted March 25, 2005 Share Posted March 25, 2005 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 More sharing options...
turetzsr Posted March 25, 2005 Share Posted March 25, 2005 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!! <big g> Link to comment Share on other sites More sharing options...
swingspacers Posted March 25, 2005 Share Posted March 25, 2005 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 Link to comment Share on other sites More sharing options...
navybuff Posted March 26, 2005 Share Posted March 26, 2005 And another: http://www.ok-ref-yes.net/gone.asp http://www.ok-ref-yes.net/nowss.asp http://www.spamcop.net/sc?id=z745956625zef...8fe305f6200420z And another: http://guzzling.net/?aa Link to comment Share on other sites More sharing options...
Wazoo Posted March 26, 2005 Share Posted March 26, 2005 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 ... And another: http://www.ok-ref-yes.net/gone.asp http://www.ok-ref-yes.net/nowss.asp http://www.spamcop.net/sc?id=z745956625zef...8fe305f6200420z 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? And another: http://guzzling.net/?aa 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 More sharing options...
navybuff Posted March 26, 2005 Share Posted March 26, 2005 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 More sharing options...
berryproud Posted March 26, 2005 Share Posted March 26, 2005 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 More sharing options...
Jeff G. Posted March 26, 2005 Share Posted March 26, 2005 berry, you got the spam before the ISP said they fixed it, please chill out. Link to comment Share on other sites More sharing options...
berryproud Posted March 27, 2005 Share Posted March 27, 2005 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 More sharing options...
StevenUnderwood Posted March 27, 2005 Share Posted March 27, 2005 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 More sharing options...
Jeff G. Posted March 27, 2005 Share Posted March 27, 2005 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 More sharing options...
StevenUnderwood Posted March 27, 2005 Share Posted March 27, 2005 You are right, I always have trouble converting to UTC. Link to comment Share on other sites More sharing options...
swingspacers Posted March 27, 2005 Share Posted March 27, 2005 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 More sharing options...
Recommended Posts
Archived
This topic is now archived and is closed to further replies.