From g.hyde at bigNOSPAMpond.net.au Sun Jan 3 05:42:40 2010 From: g.hyde at bigNOSPAMpond.net.au (Geoffrey Hyde) Date: Sun Jan 3 05:45:09 2010 Subject: [Scspamcop] Does SpamCop get the notify for this spamitem correct? Message-ID: http://www.spamcop.net/sc?id=z3626426070z3c9761597acb839e635bf8649b3ac69ez It routes it to an internal btinternet address at SC. But should it be more "trusting" of the second Received: line, and continue on to getting some kind fo resolvable address out of the 3rd bogus-looking Received: line? It looks to me as if bt just use bad/nonocompliant traceline stamping methods, and SC should attempt to derive some sort of notify out of that bogus-looking traceline. What is the point of reporting a btinernet source if all that is going to happen is that btinternet's servers are going to wind up reported for being the source of a spamitem because they don't stamp their tracelines properly/compliantly? Now if it's because it's some spammer trick and SC isn't falling for it, I could understand why not. I do sometimes wonder though if SC should be looking at tracelines that don't quite add up properly. Cheers ... Geoffrey Hyde From MikeE at ster.invalid Sun Jan 3 11:09:33 2010 From: MikeE at ster.invalid (Mike Easter) Date: Sun Jan 3 11:10:07 2010 Subject: [Scspamcop] Re: Does SpamCop get the notify for this spamitem correct? References: Message-ID: Geoffrey Hyde wrote: www.spamcop.net/sc?id=z3626426070z3c9761597acb839e635bf8649b3ac69ez Subject: Does SpamCop get the notify for this spamitem correct? Short answer: not precisely, but it is a good notify. Longer answer: SC sez 81.138.226.38 is the source - to notify abuse@btopenworld.com 81.138.226.38 rDNS host81-138-226-38.in-addr.btopenworld.com But, that IP is a mailserver; and the parser is designed to notify a source user IP behind a relaying mailserver. As you know, the examination of your provider's tracelines requires discarding the top line - a seemingly bizarre way to initiate header parsing. After that discard, using my style of abbreviating headers for illustration we see: from manorparktrading.co.uk ([81.138.226.38]) by nschwingx06p.mx.bigpond.com from User ([86.43.102.104]) by manorparktrading.co.uk In fact, there is a mailserver mail.manorparktrading.co.uk DNS 81.138.226.38 = rDNS So, in my analysis, 86.43.102.104 no rDNS of eircom.net relayed the item via the manorparktrading mailserver, so SC should find the eircom IP as the source and notify abuse@eircom.net and not find the mailserver the source. In a minute I'll check and see if the parse for a nonmailhosted account gives a more accurate result. -- Mike Easter kibitzer, not SC admin From MikeE at ster.invalid Sun Jan 3 11:22:31 2010 From: MikeE at ster.invalid (Mike Easter) Date: Sun Jan 3 11:25:08 2010 Subject: [Scspamcop] Re: Does SpamCop get the notify for this spamitem correct? References: Message-ID: Mike Easter wrote: > Geoffrey Hyde wrote: > Subject: Does SpamCop get the notify for this spamitem correct? > > Short answer: not precisely, but it is a good notify. > from manorparktrading.co.uk ([81.138.226.38]) by > nschwingx06p.mx.bigpond.com > from User ([86.43.102.104]) by manorparktrading.co.uk > So, in my analysis, 86.43.102.104 no rDNS of eircom.net relayed the item > via the manorparktrading mailserver, so SC should find the eircom IP as > the source and notify abuse@eircom.net and not find the mailserver the > source. > > In a minute I'll check and see if the parse for a nonmailhosted account > gives a more accurate result. ... and the answer is that the parser (also) fails to chain back to the source for a nonmailhosted account as well; however in a nonmailhosted account the parser tries much harder to get back to the source IP. http://www.spamcop.net/sc?id=z3627794766z43c34e78b95c9abfa906ec68e1376da cz Since the rDNS of the mailserver's IP doesn't even look like the name it stamps in the traceline, SC can't work it out correctly. That is, SC can't figure out that 81.138.226.38 is a proper mailserver for manorparktrading.co.uk -- the algo isn't written cleverly enough to determine that. In this case we can say "It is just a dumb algo." This statement I made earlier is not correct/accurate: Mike Easter wrote: > In fact, there is a mailserver mail.manorparktrading.co.uk DNS > 81.138.226.38 = rDNS mail.manorparktrading.co.uk DNS 81.138.226.38 81.138.226.38 rDNS host81-138-226-38.in-addr.btopenworld.com (the latter rDNS I had said correctly earlier, I shouldn't have added the cite above). -- Mike Easter kibitzer, not SC admin From V at nguard.LH Sun Jan 3 18:57:16 2010 From: V at nguard.LH (VanguardLH) Date: Sun Jan 3 19:00:08 2010 Subject: [Scspamcop] Re: Does SpamCop get the notify for this spamitem correct? References: Message-ID: Mike Easter wrote: > As you know, the examination of your provider's tracelines requires > discarding the top line - a seemingly bizarre way to initiate header > parsing. How do you know the 1st (top or last prepended) Received header is supposed to get discarded? How would SC know that? From MikeE at ster.invalid Sun Jan 3 20:43:11 2010 From: MikeE at ster.invalid (Mike Easter) Date: Sun Jan 3 20:45:08 2010 Subject: [Scspamcop] Re: Does SpamCop get the notify for this spamitem correct? References: Message-ID: VanguardLH wrote: > Mike Easter wrote: > >> As you know, the examination of your provider's tracelines requires >> discarding the top line - a seemingly bizarre way to initiate header >> parsing. > > How do you know the 1st (top or last prepended) Received header is > supposed to get discarded? How would SC know that? I know it because I have seen a number of GH's headers from his posts here. SC knows it because he is mailhosted. If you compare the verbose of the parse of GH's tracker with the verbose of the tracker I posted for the parse of a nonmailhosted account of the same spam, you can see the difference in the algo's logic for the two types of parses. However, in this particular case, the parser broke the chain prematurely on both the mailhosted and the nonmailhosted parse because of the configuration of the mailserver's rDNS and its traceline stamp in the 'by' field. Its rDNS wasn't what it was calling itself in the traceline. (Overstating or exaggerating the difference.) Basically the parser's logic for mailhosted is configured to 'accept anything' as long as it is consistent with the mailhosts headers, the top part, but 'accept nothing' (which isn't obvious - easily chained) beyond that - it is 'reluctant' to construct a chain past the mailhost's headers. Thus the parser's chaining is extremely 'tight' for mailhosted parses. That also makes it very tight about not accepting any bogus lines. The parser's logic for nonmailhosted is configured to try very hard to chain every step of the way - every traceline; given that the parser is 'inclined' to be very careful to not name servers as sources. It - the parser - wants to chain past/thru' a server even if the server is relaying promiscuously, because that promiscuous relaying listing is not SC's 'job'. That is considered by the logic to be the job of the open relay listers, so SC is configured to logically chain past an open relay to get to the source behind it, and submit the open relay to the relay testers. Presumably that logic of reluctance to list servers is to prevent the 'problems' which would be caused by a server getting itself SCbl listed. -- Mike Easter kibitzer, not SC admin From g.hyde at bigNOSPAMpond.net.au Mon Jan 4 02:31:38 2010 From: g.hyde at bigNOSPAMpond.net.au (Geoffrey Hyde) Date: Mon Jan 4 02:35:08 2010 Subject: [Scspamcop] Re: Does SpamCop get the notify for this spamitem correct? References: Message-ID: "Mike Easter" wrote in message news:hhqffs$sf2$1@news.spamcop.net... > Geoffrey Hyde wrote: > www.spamcop.net/sc?id=z3626426070z3c9761597acb839e635bf8649b3ac69ez > > Subject: Does SpamCop get the notify for this spamitem correct? > > Short answer: not precisely, but it is a good notify. > > Longer answer: > > SC sez 81.138.226.38 is the source - to notify abuse@btopenworld.com > 81.138.226.38 rDNS host81-138-226-38.in-addr.btopenworld.com > > But, that IP is a mailserver; and the parser is designed to notify a > source user IP behind a relaying mailserver. > > As you know, the examination of your provider's tracelines requires > discarding the top line - a seemingly bizarre way to initiate header > parsing. After that discard, using my style of abbreviating headers for > illustration we see: > > from manorparktrading.co.uk ([81.138.226.38]) by > nschwingx06p.mx.bigpond.com > from User ([86.43.102.104]) by manorparktrading.co.uk > > In fact, there is a mailserver mail.manorparktrading.co.uk DNS > 81.138.226.38 = rDNS > > So, in my analysis, 86.43.102.104 no rDNS of eircom.net relayed the item > via the manorparktrading mailserver, so SC should find the eircom IP as > the source and notify abuse@eircom.net and not find the mailserver the > source. > > In a minute I'll check and see if the parse for a nonmailhosted account > gives a more accurate result. Thank you for your analysis, and further analysis, Mike, I wonder if I should put in a request for SpamCop admins to do something about it - if indeed they will do anything at all. What SpamCop should be doing is trying to figure out how to notify those servers hiding behind the noncompliant tracelines and more accurately name the source so that the ISP's responsible can do something about it instead of getting an innocent mailserver blocklisted. Cheers ... Geoffrey Hyde From eschrama at spamcop.net Sun Jan 10 15:43:11 2010 From: eschrama at spamcop.net (Ejo) Date: Sun Jan 10 15:45:08 2010 Subject: [Scspamcop] greylist filtering Message-ID: I like this greylisting, it reduces the load from the pump and dump spammers. Noticed that there are quite a lot within certain domains like ms21.hinet.net ms29.hinet.net and *.ocn.ne.jp Ejo From asterix at no_where.net Sun Jan 10 16:36:37 2010 From: asterix at no_where.net (Asterix) Date: Sun Jan 10 16:40:09 2010 Subject: [Scspamcop] Re: greylist filtering References: Message-ID: <1jc4k2k.1yl12d9566v8uN%asterix@no_where.net> Ejo wrote: > I like this greylisting, it reduces the load from the pump and dump > spammers. Noticed that there are quite a lot within certain domains like > ms21.hinet.net ms29.hinet.net and *.ocn.ne.jp Pump'n'dump? Haven't see them in years, pro'lly thanks to graylists. -- I recommend Macs to my friends, and Windows machines to those whom I don't mind billing by the hour From nobody at spamcop.net Sun Jan 10 17:53:56 2010 From: nobody at spamcop.net (bar0) Date: Sun Jan 10 17:55:07 2010 Subject: [Scspamcop] Re: greylist filtering References: <1jc4k2k.1yl12d9566v8uN%asterix@no_where.net> Message-ID: "Asterix" wrote in message news:1jc4k2k.1yl12d9566v8uN%asterix@no_where.net... > Ejo wrote: > >> I like this greylisting, it reduces the load from the pump and dump >> spammers. Noticed that there are quite a lot within certain domains like >> ms21.hinet.net ms29.hinet.net and *.ocn.ne.jp > > Pump'n'dump? Haven't see them in years, pro'lly thanks to graylists. See very few now, but why would P&D spammers be hit harder than pecker spammers or mugumailers by grey listing? From nobody at spamcop.net Sun Jan 10 20:12:56 2010 From: nobody at spamcop.net (Steven Underwood) Date: Sun Jan 10 20:15:08 2010 Subject: [Scspamcop] Re: greylist filtering In-Reply-To: References: <1jc4k2k.1yl12d9566v8uN%asterix@no_where.net> Message-ID: "bar0" wrote in message news:hidlq8$43p$1@news.spamcop.net... > > "Asterix" wrote in message > news:1jc4k2k.1yl12d9566v8uN%asterix@no_where.net... >> Ejo wrote: >> >>> I like this greylisting, it reduces the load from the pump and dump >>> spammers. Noticed that there are quite a lot within certain domains like >>> ms21.hinet.net ms29.hinet.net and *.ocn.ne.jp >> >> Pump'n'dump? Haven't see them in years, pro'lly thanks to graylists. > > See very few now, but why would P&D spammers be hit harder than pecker > spammers or mugumailers by grey listing? > I get less than a couple spam/week since applying grey listing. From DeathToSpam at crazyhat.net Mon Jan 11 12:15:17 2010 From: DeathToSpam at crazyhat.net (DevilsPGD) Date: Mon Jan 11 12:20:08 2010 Subject: [Scspamcop] Re: greylist filtering References: <1jc4k2k.1yl12d9566v8uN%asterix@no_where.net> Message-ID: In message "bar0" was claimed to have wrote: >See very few now, but why would P&D spammers be hit harder than pecker >spammers or mugumailers by grey listing? P&D is somewhat more illegal than other types of spammers (or at least the SEC puts more effort into pursuing them for their illegal behaviour vs other agencies) More importantly, it needs a bit of specific financial know-how to make it work. As a result of the above, I believe that there is only a very small number of P&D senders and they're using similar techniques to distribute their spam. Like 419 (which are often sent oneoff or in small batches by actual humans), P&D have always been just a little different to block then anything else. From nobody at nowhere.not Mon Jan 11 14:52:10 2010 From: nobody at nowhere.not (Robert Blair) Date: Mon Jan 11 14:55:08 2010 Subject: [Scspamcop] Were any spam reports sent? Message-ID: All indications in this response say there were no reports sent. From past discussions on this list it has been stated that the block list is not updated unless a spam report is sent (even to devnull). The tracker states that if reported today a report would be sent to abuse@orbitel.com.co but the quick report response does not indicate that a report was sent. Were any spam reports sent? Was the block list updated? The following is a response to a quick report. SpamCop.net Here are the results of your submission: Processing spam: From: ciliep4233@epm.net.co Subject: Visitor blairra's personal 80% OFF 0: Received: from mailwash26.pair.com (66.39.2.26) by umbar.pair.com with SMTP; 11 Jan 2010 19:06:28 -0000 Hostname verified: mailwash26.pair.com pair received mail from pair ( 66.39.2.26 ) 1: Received: from localhost (localhost [127.0.0.1]) by mailwash26.pair.com (Postfix) with SMTP id A03911B30F for ; Mon, 11 Jan 2010 14:06:28 -0500 (EST) Internal handoff at pair 2: Received: from epm.net.co (unknown [190.71.92.195]) by mailwash26.pair.com (Postfix) with ESMTP id 2FEEC2D299 for ; Mon, 11 Jan 2010 14:06:28 -0500 (EST) No unique hostname found for source: 190.71.92.195 pair received mail from sending system 190.71.92.195 Tracking message source:190.71.92.195: Cached whois for 190.71.92.195 : adminternet@une.net.co Using abuse net on adminternet@une.net.co abuse net une.net.co = abuse@orbitel.com.co Using best contacts abuse@orbitel.com.co warning:Yum, this spam is fresh! Message is 0 hours old 190.71.92.195 not listed in dnsbl.njabl.org ( 127.0.0.8 ) 190.71.92.195 not listed in dnsbl.njabl.org ( 127.0.0.9 ) 190.71.92.195 not listed in cbl.abuseat.org 190.71.92.195 listed in dnsbl.sorbs.net ( 127.0.0.7 ) May be saved for future reference: http://www.spamcop.net/sc?id=z3647672703z37a482384e5139176c14b7f037f66eecz -- Robert Blair From tmcgraw at spamcop.net Tue Jan 12 02:36:02 2010 From: tmcgraw at spamcop.net (Tim McGraw) Date: Tue Jan 12 02:40:08 2010 Subject: [Scspamcop] Re: Were any spam reports sent? In-Reply-To: References: Message-ID: Robert Blair wrote: > Were any spam reports sent? Yes. http://www.spamcop.net/sc?track=190.71.92.195 Click "Report history." > Was the block list updated? http://www.spamcop.net/fom-serve/cache/297.html "The SCBL will not list an IP address with only one report filed." From clewis at nortel.com Wed Jan 13 02:11:30 2010 From: clewis at nortel.com (Chris Lewis) Date: Wed Jan 13 02:15:08 2010 Subject: [Scspamcop] Re: Does SpamCop get the notify for this spamitem correct? References: Message-ID: According to Geoffrey Hyde : > > "Mike Easter" wrote in message > news:hhqffs$sf2$1@news.spamcop.net... > > from manorparktrading.co.uk ([81.138.226.38]) by > > nschwingx06p.mx.bigpond.com > > from User ([86.43.102.104]) by manorparktrading.co.uk > > In fact, there is a mailserver mail.manorparktrading.co.uk DNS > > 81.138.226.38 = rDNS > > So, in my analysis, 86.43.102.104 no rDNS of eircom.net relayed the item > > via the manorparktrading mailserver, so SC should find the eircom IP as > > the source and notify abuse@eircom.net and not find the mailserver the > > source. > > In a minute I'll check and see if the parse for a nonmailhosted account > > gives a more accurate result. > Thank you for your analysis, and further analysis, Mike, I wonder if I > should put in a request for SpamCop admins to do something about it - if > indeed they will do anything at all. Actually, while 86.43.102.104 is likely the source, 81.138.226.38 is the one with the problem that most immediately needs to be fixed. The "from User" generally means that one of manorparktrading.co.uk's users has had their SMTP password cracked. This is so consistent that you can put filters in for "Received: from User" and almost exclusively nail 419s. Generally, it's pointless to go past the IP in the first received line inserted by one of the recipient's (your) mail server, because (a) the rest of them are usually forged (except this one) and (b) even if it isn't forged, it's _that_ IP that has a problem to fix - open relay, cracked account, infected customer etc. > What SpamCop should be doing is trying to figure out how to notify those > servers hiding behind the noncompliant tracelines and more accurately name > the source so that the ISP's responsible can do something about it instead > of getting an innocent mailserver blocklisted. Right. But since >90% of previous Received headers are fake, you're sending complaints to the wrong place 90% of the time. We have an /8. We get a considerable number of SC reports about bogus IPs that don't exist because the SC parsing has been tricked into parsing fake received lines. Your suggestion would make the error rate higher. -- Chris Lewis, Age and Treachery will Triumph over Youth and Skill It's not just anyone who gets a Starship Cruiser class named after them. From g.hyde at bigNOSPAMpond.net.au Wed Jan 13 08:12:05 2010 From: g.hyde at bigNOSPAMpond.net.au (Geoffrey Hyde) Date: Wed Jan 13 08:15:08 2010 Subject: [Scspamcop] Re: Does SpamCop get the notify for this spamitem correct? References: Message-ID: "Chris Lewis" wrote in message news:hijrn2$d2o$1@news.spamcop.net... > According to Geoffrey Hyde : [...] >> Thank you for your analysis, and further analysis, Mike, I wonder if I >> should put in a request for SpamCop admins to do something about it - if >> indeed they will do anything at all. > > Actually, while 86.43.102.104 is likely the source, 81.138.226.38 is > the one with the problem that most immediately needs to be fixed. The > "from User" generally means that one of manorparktrading.co.uk's users > has had their SMTP password cracked. Can you prove that one way or the other? If so, go ahead and tell them it needs fixed. > This is so consistent that you can put filters in for "Received: from > User" > and almost exclusively nail 419s. > > Generally, it's pointless to go past the IP in the first received line > inserted by one of the recipient's (your) mail server, because (a) the > rest of them are usually forged (except this one) and (b) even if it > isn't forged, it's _that_ IP that has a problem to fix - open relay, > cracked account, infected customer etc. What I am saying is that this looks to me like it could be a possible abusive open relay. Why do I say this? It does not look like it was stamped as a dialup or other kind of modem connection - even if the spammer could forge that, I do know about bigpond's weird double stamping of header lines, so possibly that third traceline should be attacked by SpamCop. But that's what SpamCop isn't even trying to do. >> What SpamCop should be doing is trying to figure out how to notify those >> servers hiding behind the noncompliant tracelines and more accurately >> name >> the source so that the ISP's responsible can do something about it >> instead >> of getting an innocent mailserver blocklisted. > > Right. But since >90% of previous Received headers are fake, you're > sending complaints to the wrong place 90% of the time. > > We have an /8. We get a considerable number of SC reports about bogus IPs > that don't exist because the SC parsing has been tricked into parsing > fake received lines. Your suggestion would make the error rate higher. Are you saying that you're *from* manorparktrading and that you can poistively identify the 3rd Received: line as fake? Good. Then that would positively dismiss my theories and additionally says that SpamCop is getting the notify right. If not, there is still the problem of the second server that looks like a relaying server to me. Of particular interest is whether the manorparktrading server administrators will shut down the spammer trying to abuse their mailserver, or if they will allow the spammer to contine unabated. Cheers ... Geoffrey Hyde From MikeE at ster.invalid Wed Jan 13 09:05:53 2010 From: MikeE at ster.invalid (Mike Easter) Date: Wed Jan 13 09:10:08 2010 Subject: [Scspamcop] Re: Does SpamCop get the notify for this spamitem correct? In-Reply-To: References: Message-ID: Geoffrey Hyde wrote: > What I am saying is that this looks to me like it could be a possible > abusive open relay. I'll repeat some things I said earlier, leaving out a misstatement I made. We are talking about this abbreviated traceline situation: from manorparktrading.co.uk ([81.138.226.38]) by nschwingx06p.mx.bigpond.com from User ([86.43.102.104]) by manorparktrading.co.uk which has these resolutions: 81.138.226.38 rDNS host81-138-226-38.in-addr.btopenworld.com. manorparktrading.co.uk MX = mail.manorparktrading.co.uk mail.manorparktrading.co.uk DNS 81.138.226.38 86.43.102.104 no rDNS belongs to eircom.net All you know for sure is that you got the item from the mailserver, but 'we' thereisnowe are supposing that the eircom.net IP sourced the item by relaying it thru' the mailserver. A simple automated test with a script at abuse.net shows that the mailserver apparently isn't promiscuously misconfigured, and so one supposition is that it relayed the item because of a cracked user/pass. SpamCop isn't purposed to be a lister of open or abused relays. (And/But) There are beneficial side effects when a 'small' server is mistakenly named as source, because that may result in the server being blocklisted which would motivate the server's admin to do something and/or a spamcop notification might help the admin become aware. -- Mike Easter From not at home.today Wed Jan 13 09:42:26 2010 From: not at home.today (Ant) Date: Wed Jan 13 09:45:07 2010 Subject: [Scspamcop] Re: Does SpamCop get the notify for this spamitem correct? References: Message-ID: "Geoffrey Hyde" wrote: > "Chris Lewis" wrote: >> We have an /8. We get a considerable number of SC reports about bogus IPs >> that don't exist because the SC parsing has been tricked into parsing >> fake received lines. Your suggestion would make the error rate higher. > > Are you saying that you're *from* manorparktrading and that you can > poistively identify the 3rd Received: line as fake? Good. Only large corporations or governments own CIDR blocks the size of an /8, not small businesses. Mr Lewis works for Nortel as you can see from his headers. From g.hyde at bigNOSPAMpond.net.au Thu Jan 14 06:16:19 2010 From: g.hyde at bigNOSPAMpond.net.au (Geoffrey Hyde) Date: Thu Jan 14 06:20:08 2010 Subject: [Scspamcop] Re: Does SpamCop get the notify for this spamitem correct? References: Message-ID: "Mike Easter" wrote in message news:hikk02$rec$1@news.spamcop.net... > All you know for sure is that you got the item from the mailserver, but > 'we' thereisnowe are supposing that the eircom.net IP sourced the item by > relaying it thru' the mailserver. A simple automated test with a script > at abuse.net shows that the mailserver apparently isn't promiscuously > misconfigured, and so one supposition is that it relayed the item because > of a cracked user/pass. Suppositions are nice, got anything to back them up with? > SpamCop isn't purposed to be a lister of open or abused relays. (And/But) > There are beneficial side effects when a 'small' server is mistakenly > named as source, because that may result in the server being blocklisted > which would motivate the server's admin to do something and/or a spamcop > notification might help the admin become aware. And if this 'small' server doesn't connect to many SpamCop blocklist-operated mailservers, it may not even know it's been blocklisted. There are two problems with being a 'small' mailserver. The first is getting hacked and used as a mail relay. The second is the first, plus an ignorant operator discarding SpamCop reports because a lot of their traffic doesn't get blocklisted and so never suspects anything really is amiss. I believe SpamCop should not only name the 'small' server, it should see if it can find logic which would enable it to name the server which sent to the 'small' server as well. If the logic doesn't fit, it doesn't name it, simple as that. Cheers ... Geoffrey Hyde From MikeE at ster.invalid Thu Jan 14 10:20:30 2010 From: MikeE at ster.invalid (Mike Easter) Date: Thu Jan 14 10:25:07 2010 Subject: [Scspamcop] Re: Does SpamCop get the notify for this spamitem correct? In-Reply-To: References: Message-ID: Geoffrey Hyde wrote: > "Mike Easter" >> All you know for sure is that you got the item from the mailserver, but >> 'we' thereisnowe are supposing that the eircom.net IP sourced the item by >> relaying it thru' the mailserver. > Suppositions are nice, got anything to back them up with? There is a philosophical issue here. If you hang out in such places as nanae, people like Vernon Schryver emphasize the point that the parsing of mailheaders is very presumptive, and he strongly believes that what spamcop does in terms of logically deriving how an item was sourced by chaining the tracelines backward is inherently terribly flawed. By flawed I mean, the result is, "Maybe this is true, and maybe it isn't." To me, parsing headers is about achieving a 'result' in which the parser says, "This is what I think happened." When you say, 'got anything to back (it) up?' it sounds as if you are insisting on some kind of 'proof'. The proof is that you got the spam. The evidence of your having received the spam is damaged by your mailserver's treatment of its own tracelines. So, as far as I'm concerned, there is no solid evidence you even received the spam (from somewhere else). Now what are you going to do with my suppositions and your lack of hard evidence? -- Mike Easter From clewis at nortel.com Thu Jan 14 11:20:49 2010 From: clewis at nortel.com (Chris Lewis) Date: Thu Jan 14 11:25:09 2010 Subject: [Scspamcop] Re: Does SpamCop get the notify for this spamitem correct? References: Message-ID: According to Geoffrey Hyde : > > "Chris Lewis" wrote in message > news:hijrn2$d2o$1@news.spamcop.net... > > According to Geoffrey Hyde : > [...] > >> Thank you for your analysis, and further analysis, Mike, I wonder if I > >> should put in a request for SpamCop admins to do something about it - if > >> indeed they will do anything at all. > > Actually, while 86.43.102.104 is likely the source, 81.138.226.38 is > > the one with the problem that most immediately needs to be fixed. The > > "from User" generally means that one of manorparktrading.co.uk's users > > has had their SMTP password cracked. > Can you prove that one way or the other? No, but the odds are better than 100:1 in favour of it. "from User" is what (most) SMTPAUTH-based mail submit services will insert. Eg: any MTA offering roaming services to their customers either on port 25 or 587. These are equivalent to X-Originating-IP headers at sites that do this (securely) on webmail, and mean pretty much the same thing, to whit: proof that the spam is going out using credentials _known_ to the MTA, not some random forgery. > If so, go ahead and tell them it needs fixed. That's spamcop's job, in the case of your submissions to them. > > Generally, it's pointless to go past the IP in the first received line > > inserted by one of the recipient's (your) mail server, because (a) the > > rest of them are usually forged (except this one) and (b) even if it > > isn't forged, it's _that_ IP that has a problem to fix - open relay, > > cracked account, infected customer etc. > What I am saying is that this looks to me like it could be a possible > abusive open relay. Abusive open relays (open SMTP relays of any kind) are vanishingly rare these days. Less than 3% of spam is sent this way. How do I know this? 90%+ of all spam is sent direct-to-MX by bots (by direct measurement), and most of the rest by snowshoe/dedicated spamhausen. Doesn't leave much room for open relays. You go by the odds. And further, the IP that handed the email to your MX is by definition the one with a problem - either an abusive user, or a security hole. In some rare cases (with "from User" or "trusted" received line chains) it might make sense to notify someone else further down the chain. But, in the end, the IP that handed off to your MX must _always_ be your first priority to notify, and most of the time they're the most likely to actually _do_ something about it. If it's bot spam (which the odds are 90% or more in favour in any random spam you look at), it's NEVER appropriate to notify anything past the first received line. In a case such as this one, the IP that did the handoff (manorparktrading) _should_ be able to find the transaction in their mail server logs and directly identify which of their customers had their passwords hacked. Since this is a trading company, you'd _think_ that they'd have rather higher incentive to do so, more than a generic ISP. > could forge that, I do know about bigpond's weird double stamping of header > lines, so possibly that third traceline should be attacked by SpamCop. But > that's what SpamCop isn't even trying to do. And I don't generally think they should bother. It'd cut down the erroneous reports from spamcop about bots forging received lines with _our_ IPs in them. The ones that are worse are the manual reports that include everybody and their dog, including the US government, in their complaints about spam we supposedly (but didn't) send. -- Chris Lewis, Age and Treachery will Triumph over Youth and Skill It's not just anyone who gets a Starship Cruiser class named after them. From clewis at nortel.com Thu Jan 14 11:23:17 2010 From: clewis at nortel.com (Chris Lewis) Date: Thu Jan 14 11:25:09 2010 Subject: [Scspamcop] Re: Does SpamCop get the notify for this spamitem correct? References: Message-ID: According to Geoffrey Hyde : > "Mike Easter" wrote in message > news:hikk02$rec$1@news.spamcop.net... > > SpamCop isn't purposed to be a lister of open or abused relays. (And/But) > > There are beneficial side effects when a 'small' server is mistakenly > > named as source, because that may result in the server being blocklisted > > which would motivate the server's admin to do something and/or a spamcop > > notification might help the admin become aware. > And if this 'small' server doesn't connect to many SpamCop > blocklist-operated mailservers, it may not even know it's been blocklisted. If they get notification, they will. That report will certainly help later if they get blocklisted by, say, Spamhaus, which _everyone_ notices and usually in quite short order. -- Chris Lewis, Age and Treachery will Triumph over Youth and Skill It's not just anyone who gets a Starship Cruiser class named after them. From anfi at onet.eu Thu Jan 14 17:33:00 2010 From: anfi at onet.eu (Andrzej Adam Filip) Date: Thu Jan 14 17:35:07 2010 Subject: [Scspamcop] Listing addresses without reporting address [separate list] Message-ID: <7mqieyay5d-A1E@lonnie.brudna.chmurka.net> Do you think it would make sense to create new DNSBL listing IP addresses with unknown reporting address? -- [pl>en Andrew] Andrzej Adam Filip : anfi@onet.eu : Andrzej.Filip@gmail.com Love is the delusion that one woman differs from another. -- H. L. Mencken From jason.mangiafico at verizon.net Thu Jan 14 17:42:24 2010 From: jason.mangiafico at verizon.net (JM) Date: Thu Jan 14 17:45:07 2010 Subject: [Scspamcop] stopped on forged Ip, now account is deactivated [was: Re: [SpamCop Message] Mailhosts] Message-ID: I noticed one report was going to the forgery address, and not a real report, so I typed in the comments field what Ip should have been detected, and sent it anyways. My system is actually quite easy - it's just the top most Ip address in the header that "touched" my server. I wonder why if Spamcop's logic knows it stopped on a forged Ip, why was it using it for a report anyway? From MikeE at ster.invalid Thu Jan 14 18:50:45 2010 From: MikeE at ster.invalid (Mike Easter) Date: Thu Jan 14 18:55:08 2010 Subject: [Scspamcop] Re: Listing addresses without reporting address [separate list] In-Reply-To: <7mqieyay5d-A1E@lonnie.brudna.chmurka.net> References: <7mqieyay5d-A1E@lonnie.brudna.chmurka.net> Message-ID: Andrzej Adam Filip wrote: > Do you think it would make sense to create new DNSBL listing IP > addresses with unknown reporting address? If that 'you' is any respondent who cares to speak up, personally I wouldn't have any 'use for' such a dnsbl. Anything can have an address. What happens at something that has an address might range from devnull to immediate correction of any problems with a personal acknowledgement or it might be a useless autoack. So, something else which doesn't (even) have an address could be no less bad than something which does have a useless address. The condition of RFC ignorance already has a listing function which isn't actually any good for anything. For many years spamcop.net was rfc-ignorant listed, but it is off now. http://snipr.com/u3355 added 2003 Feb, removed 2009 Nov. -- Mike Easter From MikeE at ster.invalid Thu Jan 14 19:05:25 2010 From: MikeE at ster.invalid (Mike Easter) Date: Thu Jan 14 19:10:08 2010 Subject: [Scspamcop] Re: stopped on forged Ip, now account is deactivated [was: Re: [SpamCop Message] Mailhosts] In-Reply-To: References: Message-ID: JM wrote: Subject: stopped on forged Ip, now account is deactivated [was: Re: [SpamCop Message] > I noticed one report was going to the forgery address, and not a real > report, so I typed in the comments field what Ip should have been detected, > and sent it anyways. My system is actually quite easy - it's just the top > most Ip address in the header that "touched" my server. I wonder why if > Spamcop's logic knows it stopped on a forged Ip, why was it using it for a > report anyway? This would be easier to see with the tracker for the issue in question. When you access the report of that item, there is a link which contains a format like this: www.spamcop.net/sc?id=z1505491930z5db2559eebcde98291b8e783c95d61cez which id= contains 2 z fields, a 10 digit decimal one and a 32 digit hex one. Other formats such as report ones are only useful to the reporter, no one else. That tracker format above lets us see the original spam, current parsing, and how it would be notified if reported today. -- Mike Easter From jason.mangiafico at verizon.net Thu Jan 14 20:02:52 2010 From: jason.mangiafico at verizon.net (JM) Date: Thu Jan 14 20:05:08 2010 Subject: [Scspamcop] Re: stopped on forged Ip, now account is deactivated [was: Re: [SpamCop Message] Mailhosts] References: Message-ID: Here is the tracker. http://spamcop.net/sc?id=z3650128886z021d27cb40def38588788452422ea343z From MikeE at ster.invalid Thu Jan 14 20:34:19 2010 From: MikeE at ster.invalid (Mike Easter) Date: Thu Jan 14 20:35:08 2010 Subject: [Scspamcop] Re: stopped on forged Ip, now account is deactivated [was: Re: [SpamCop Message] Mailhosts] In-Reply-To: References: Message-ID: JM wrote: > Here is the tracker. > > http://spamcop.net/sc?id=z3650128886z021d27cb40def38588788452422ea343z Well, I can't comment on anything that you did or that SC admin may have thought you did or on anything that the parser did or didn't do. All I can comment on is how I would (go about) interpreting the source based on the headers I see. This is the way I abbreviate and comment Received tracelines: Abbreviated Received tracelines *comment from [72.76.45.124] by openbrick.kicks-ass.net *server output from ApexMailbox.apexcomputersllc.com ([169.254.1.243]) by apexserver.apexcomputersllc.com ([192.168.0.251]) *server input apexcomputersllc.com MX = mail.apexcomputersllc.com mail.apexcomputersllc.com DNS = 72.76.45.124 72.76.45.124 rDNS dns2.apexcomputersllc.com The IP addresses used by the apexcomutersllc server are what I call non-routing addresses, used for such as internal networks and link locals. If I as a human parser chain back thru' the server to the IP which the server said it got the mail from, that is a nonrouting 169.254.x.x IP. No good. Some say IANA reserved. Your tracker is for a mailhosted account. SC's parser doesn't really like to 'think' about trying to chain for mailhosted accounts, and runs 'tight'. In parsing for a mailhosted account, it stops at the top line which is the server 72.76.45.124. If I submit those same headers for a nonmailhosted account, the parser will properly chain back to the nonrouting IP and submit the report to the 'forged-ip' address -- kinda like an error report. If reported today, reports would be sent to: Re: 169.254.1.243 (Administrator of IP block - statistics only) forged-ip@don.spamcop.net So, the 'proper' chaining results in a bad report, if you see what I mean. -- Mike Easter From user at domain.invalid Thu Jan 14 21:39:12 2010 From: user at domain.invalid (Farelf) Date: Thu Jan 14 21:40:07 2010 Subject: [Scspamcop] Re: stopped on forged Ip, now account is deactivated [was: Re: [SpamCop Message] Mailhosts] In-Reply-To: References: Message-ID: Mike Easter wrote: ... > > If I submit those same headers for a nonmailhosted account, the parser > will properly chain back to the nonrouting IP and submit the report to > the 'forged-ip' address -- kinda like an error report. > > If reported today, reports would be sent to: > Re: 169.254.1.243 (Administrator of IP block - statistics only) > forged-ip@don.spamcop.net > > So, the 'proper' chaining results in a bad report, if you see what I mean. > Hey, so it does. I don't recall seeing one of those before - thanks Mike. From anfi at onet.eu Fri Jan 15 02:00:32 2010 From: anfi at onet.eu (Andrzej Adam Filip) Date: Fri Jan 15 02:05:09 2010 Subject: [Scspamcop] Re: Listing addresses without reporting address [separate list] References: <7mqieyay5d-A1E@lonnie.brudna.chmurka.net> Message-ID: <32u1kja6dl-A1F@terry.huge.strangled.net> Mike Easter wrote: > Andrzej Adam Filip wrote: >> Do you think it would make sense to create new DNSBL listing IP >> addresses with unknown reporting address? > > If that 'you' is any respondent who cares to speak up, personally I > wouldn't have any 'use for' such a dnsbl. > > Anything can have an address. What happens at something that has an > address might range from devnull to immediate correction of any > problems with a personal acknowledgement or it might be a useless > autoack. > > So, something else which doesn't (even) have an address could be no > less bad than something which does have a useless address. I would not encourage to use such list to block IP addresses in "near by countries". Anyway I think it may be useful for providing a reason to block "countries" someone would like to block without declaring it is "country" blocking. > The condition of RFC ignorance already has a listing function which > isn't actually any good for anything. > > For many years spamcop.net was rfc-ignorant listed, but it is off now. > > http://snipr.com/u3355 added 2003 Feb, removed 2009 Nov. -- [pl>en Andrew] Andrzej Adam Filip : anfi@onet.eu : Andrzej.Filip@gmail.com Almost nothing in Perl serves a single purpose. -- Larry Wall in <199712040054.QAA13811@wall.org> From nobody at spamcop.net Fri Jan 15 17:39:11 2010 From: nobody at spamcop.net (Richard W) Date: Fri Jan 15 17:40:08 2010 Subject: [Scspamcop] SpamCop reporting site emergency update Message-ID: Sorry for the short/no notice, but this just came across the wire about five minutes before it took effect. An emergency Hot Patch is being applied to the SpamCop Reporting side servers starting at 1430 -0700 hrs (PST). The SpamCop reporting site will be in maintenance mode for up to two hours while this patch is being applied. The reason for the patch is to get the parser to recognize the X-Originating-IP line for a whole bunch of new Hotmail servers. Richard From nobody at spamcop.net Mon Jan 18 00:33:23 2010 From: nobody at spamcop.net (Richard W) Date: Mon Jan 18 00:35:07 2010 Subject: [Scspamcop] Re: stopped on forged Ip, now account is deactivated [was: Re: [SpamCop Message] Mailhosts] In-Reply-To: References: Message-ID: Farelf wrote: > Hey, so it does. I don't recall seeing one of those before - thanks Mike. Between forged-IP, bad-tracking and bad-user, Don probably gets the most reports in the world ;-) Richard From nobody at nowhere.not Tue Jan 19 15:00:07 2010 From: nobody at nowhere.not (Robert Blair) Date: Tue Jan 19 15:05:08 2010 Subject: [Scspamcop] attention deputies Message-ID: The quick reports reply is not reporting the email address where the reports are sent except for devnull and nomaster. Cached whois for 88.236.199.166 : nazan.oztekin@turktelekom.com.tr zela.unsal@turktelekom.com.tr abuse@ttnet.net.tr serdar.ozgur@turktelekom.com.tr Using abuse net on abuse@ttnet.net.tr abuse net ttnet.net.tr = abuse@ttnet.net.tr Using best contacts abuse@ttnet.net.tr warning:Yum, this spam is fresh! Message is 0 hours old 88.236.199.166 not listed in dnsbl.njabl.org ( 127.0.0.8 ) 88.236.199.166 not listed in dnsbl.njabl.org ( 127.0.0.9 ) 88.236.199.166 listed in cbl.abuseat.org ( 127.0.0.2 ) 88.236.199.166 is an open proxy May be saved for future reference: http://www.spamcop.net/sc?id=z3665672939z7f00f24aecacb585209b48842bd8063dz The web page has the email address where the reports were sent. Also http code is still in the quick reports output whenever I get the "error:ISP has indicated spam will cease;" message. error:ISP has indicated spam will cease; ISP resolved this issue sometime after -- Robert Blair From nobody at spamcop.net Wed Jan 20 09:23:29 2010 From: nobody at spamcop.net (Twayne) Date: Wed Jan 20 09:25:08 2010 Subject: [Scspamcop] abuse#exacttarget.com@devnull.spamcop.net? Message-ID: I'd never use an e-mail link to access ANY bank function, but ... am wondering about this being spam or not: http://www.spamcop.net/sc?id=z3667283710zc8c9c9959455629bccfb32386509925dz Would some kind soul take a look at the above tracker and tell me whether it's spam or not? exacttarget.com caught my eye and I can't find any connection to it and BOA ... SC says reports are disabled for that address. Google seems to indicate exacttarget.com is legit but ... I can find no connection between BOA and exacttarget.com (at godaddy.com) as the e-mail intimates. Unless it's a typo, their expiration was 2018, a pretty permanent looking organization: ==== Expiration Date: 2018-02-21 Creation Date: 2000-02-21 Last Update Date: 2009-02-19 ==== IS there a connection between BOA and exacttarget? Or is SC erring? Thanks for looking, Twayne From MikeE at ster.invalid Wed Jan 20 11:24:15 2010 From: MikeE at ster.invalid (Mike Easter) Date: Wed Jan 20 11:25:08 2010 Subject: [Scspamcop] Re: abuse#exacttarget.com@devnull.spamcop.net? In-Reply-To: References: Message-ID: Twayne wrote: > I'd never use an e-mail link to access ANY bank function, but ... am > wondering about this being spam or not: www.spamcop.net/sc?id=z3667283710zc8c9c9959455629bccfb32386509925dz > > Would some kind soul take a look at the above tracker and tell me > whether it's spam or not? Not. > exacttarget.com caught my eye and I can't find any connection to it and > BOA ... mta.emcom.bankofamerica.com = 66.231.90.53 66.231.90.53 rDNS mta.emcom.bankofamerica.com Naturally bankofamerica.com belongs to BOA and/but whereas the specific IP belongs to the netblock of exacttarget. ExactTarget is a member of a coalition of email service providers http://en.wikipedia.org/wiki/Email_Sender_and_Provider_Coalition The Email Sender and Provider Coalition is an industry cooperative of e-mail service providers working to create solutions to the continued proliferation of email spam and the emerging problem of email deliverability. - The ESPC works on solutions to spam and deliverability concerns through a combination of legislative advocacy, technological development, and industry standards. > SC says reports are disabled for that address. Google seems to > indicate exacttarget.com is legit but ... I can find no connection > between BOA and exacttarget.com (at godaddy.com) as the e-mail > intimates. Unless it's a typo, their expiration was 2018, a pretty > permanent looking organization: > IS there a connection between BOA and exacttarget? Or is SC erring? The mailserver's name belongs to BOA; the IP belongs to the netblock of the ESPC member The mail is a mailing list they say you joined and you can leave. -- Mike Easter From Not_For_Mail at example.com Sun Jan 24 08:04:38 2010 From: Not_For_Mail at example.com (Giampaolo) Date: Sun Jan 24 08:05:07 2010 Subject: [Scspamcop] Reports on 68.234.134.113 are probably resolved incorrectly Message-ID: This is what SC knows: http://www.spamcop.net/sc?action=showroute;ip=68.234.134.113;typecodes=17 Instead, these are the related whois records: # whois 68.234.134.113 Distributed Management Information Systems, Inc. (DMISI) DMISI (NET-68-234-128-0-1) 68.234.128.0 - 68.234.255.255 PAVLOVMEDIA-SE PAVLOV-SE-REGIONAL (NET-68-234-132-0-1) 68.234.132.0 - 68.234.135.255 # whois NET-68-234-132-0-1 CustName: PAVLOVMEDIA-SE Address: 56 Marietta St. City: Atlanta StateProv: GA PostalCode: 30303 Country: US RegDate: 2009-07-14 Updated: 2009-07-14 NetRange: 68.234.132.0 - 68.234.135.255 CIDR: 68.234.132.0/22 OriginAS: AS46925 NetName: PAVLOV-SE-REGIONAL NetHandle: NET-68-234-132-0-1 Parent: NET-68-234-128-0-1 NetType: Reassigned Comment: RegDate: 2009-07-14 Updated: 2009-07-14 RAbuseHandle: NETWO175-ARIN RAbuseName: Network Operations Center RAbusePhone: +1-217-353-3059 RAbuseEmail: netops@fusionbroadband.com Regards, Giampaolo From MikeE at ster.invalid Sun Jan 24 12:05:28 2010 From: MikeE at ster.invalid (Mike Easter) Date: Sun Jan 24 12:10:09 2010 Subject: [Scspamcop] Re: Reports on 68.234.134.113 are probably resolved incorrectly In-Reply-To: References: Message-ID: Giampaolo wrote: > This is what SC knows: > > http://www.spamcop.net/sc?action=showroute;ip=68.234.134.113;typecodes=17 This/That (earlier) is fixed now: Reports routes for 68.234.134.113: routeid:56592157 68.234.128.0 - 68.234.255.255 to:netops@fusionbroadband.com Administrator found from whois records Statistics: 68.234.134.113 listed in bl.spamcop.net (127.0.0.2) More Information.. 68.234.134.113 not listed in dnsbl.njabl.org ( 127.0.0.8 ) 68.234.134.113 not listed in dnsbl.njabl.org ( 127.0.0.9 ) 68.234.134.113 listed in cbl.abuseat.org ( 127.0.0.2 ) Reporting addresses: netops@fusionbroadband.com postmaster@fusionbroadband.com -- Mike Easter From tmcgraw at spamcop.net Sun Jan 24 12:12:53 2010 From: tmcgraw at spamcop.net (Tim McGraw) Date: Sun Jan 24 12:20:07 2010 Subject: [Scspamcop] Re: Reports on 68.234.134.113 are probably resolved incorrectly In-Reply-To: References: Message-ID: Mike Easter wrote: > Giampaolo wrote: >> This is what SC knows: >> >> http://www.spamcop.net/sc?action=showroute;ip=68.234.134.113;typecodes=17 > > This/That (earlier) is fixed now Begging the question, should routing errors be posted in this forum since the routing group is apparently no longer read by deputies and the like? From MikeE at ster.invalid Sun Jan 24 12:37:05 2010 From: MikeE at ster.invalid (Mike Easter) Date: Sun Jan 24 12:40:07 2010 Subject: [Scspamcop] Re: Reports on 68.234.134.113 are probably resolved incorrectly In-Reply-To: References: Message-ID: Tim McGraw wrote: > Mike Easter wrote: >> This/That (earlier) is fixed now > > Begging the question, should routing errors be posted in this forum > since the routing group is apparently no longer read by deputies and the > like? I don't know the answer to your qx, but this wasn't actually a routing (manual/deputy entry) issue. The cache just needed refreshing. And/So/But; guessing from the top of my head, I would say that if I wanted to post a genuine routing related question or answer, I would do it in routing and see what happened. The world including spamcop is a dynamic and changing place; some things may get better and others may get worse -- Mike Easter