http://www.spamcop.net/mcgi?action=gettrac...rtid=3584621484

Domain Reported: best4www.info
Domain Parsed: www.info.

The parser incorrectly identified the above domain because it contained www in the domain name.

From: "deepak" <deepak[at]best4www.info>
To: <x>
Subject: Re:Web Promotion
Date: Thu, 16 Oct 2008 19:23:05 +0530
MIME-Version: 1.0
Content-Type: multipart/alternative;
boundary="----=_NextPart_000_0B00_01C92FC5.E2F99500"
X-Mailer: Microsoft Office Outlook, Build 11.0.5510
Thread-Index: Ackvllu2dD8v9QrhSeuqG2sPF5IZhA==
X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.3350

Thanks, an unusual one - noting:

Non-authoritative answer:
Name: best4www.info
Address: 66.36.231.147

WHOIS Source: ARIN
IP Address: 66.36.231.147
Country: USA - Washington
Network Name: HOPONE-DCA2-1
Owner Name: HopOne Internet Corporation
From IP: 66.36.224.0
To IP: 66.36.255.255
Allocated: Yes
Contact Name: HopOne Internet Corporation
Address: 3311 South 120th Place, Tukwila
Email: hjass[at]hopone.net
Abuse Email: abuse[at]hopone.net
Phone: 206-438-5909

You can pass such finding on to the deputies - deputies[at]admin.spamcop.net - I will send an email with the detail this time.

No-one but you, or SpamCop staff, can follow your link by the way. What we see is Authorization failure, no username provided by server; action = gettrack The way to turn a report number into a generally accessable link is shown in Tracking URL

Okay, Ellen (deputy) has looked at it, says there appears to be no website involving that domain, but there is an email address. That's unexpected. Can you please supply the 'tracker' as indicated in my previous? The part that's particularly relevant is the link from the tracking url Wiki entry I gave, that is http://forum.spamcop.net/forums/index.php?showtopic=4498

Using my own account and your report number all I (or any other member) can see is the report history, not the (munged) message, not the parse. Sure enough, reports went out concerning www.info and certainly that is the wrong target. Doubly wrong because email addresses/their domains aren't supposed to be reported, not even when they're the right one. We surely want to get on top of this.

Hello,

I am a mail admin for the company that owns the www.info domain. I got a ticket from my ISP regarding this issue today.

I can't see anything in the spam email at all that relates to us in anyway. Not sure how http://www.info ended up in the "Resolving link obfuscation" section of the report.

So, is this issue resolved for us? I'd like to simply select the "URL used without our permission" in the dropdown box on the "Abuse report response center" page. If there is anything else required of us, please let me know.

Regards,

As you have probably read above, the reports to your address are not correct. The parser coding is seeing the www and assuming it is the start of the url.

I believe there is a link to contact someone at spamcop about it (maybe dispute the report????). You should really try talking to an official SpamCop employee. This is a user to user support forum. The email address would be deputies[at]admin.spamcop.net but a direct link inside the report is probably the best/quickest way to get in contact.

Please accept our applogy for this mistake. The deputies will straighten it out and likely remove any black marks against your domain.

This far, "we" are not able to do much research into what happened due to the lack of feedback with additional details from the Topic starter. You could help by following the "How SpamCop tracked this to you" link and then providing the Tracking URL from that web-page. One of Farelf's previous posts references an e-mail from Ellen (a paid employee of SpamCop.net) but the posted information doesn't really seem to answer anything directly, especially just how "your" address was invoked.

Ellen's conjecture was the parser mistakenly fastened on the "www" text of the domain part of an email address in the body of the message. Presumably this is a quirk of the parser but without seeing the message and parse it is impossible for others to be sure. Ellen is able to see from just the report number so I'm not sure if she needs/wants further input from "us", if we could get to the message (I volunteered it anyway, since she didn't make "we'll get it fixed" noises - and she hasn't said "no").

Ordinarily, anything involving parsing the body would not receive much priority from the programmers if there was anything needing fixing. (Spamvertized sites, which are the only legitimate target there, are not the main mission, besides quick/VER reporting ignores the body and is an increasing proportion of total reporting - at a guess). But if something unintended in the parser is causing doubly-bogus reports that might be a different thing. It is clearly a rare occurrence, parser changes take 'forever' so some accommodation needs to be worked out in the meantime, making some assumptions about cause and likely recurrence.

In any event, the user knowledge base needs to be informed for several reasons, including the possibility that future reporters might recognize the problem, if properly forewarned, and de-select the appropriate pending reports. So, yes, please , nightwalker or logaan, a tracking url is needed.

We are fortunate that nightwalker recognized that there was a problem right from the start and thought to raise the alarm.

Here is your TRACKING URL:
http://www.spamcop.net/sc?id=z2337464165za...918cffed4adfe0z


I flagged http://www.info/ as being an innocent bystander so that SpamCop will no longer send reports about it.

- Don D'Minion - SpamCop Admin -
.

Hi, just logging in now.

Yep, that's the Tracking URL. I'll considered this case closed then.

Thanks for your help!

Logaan

Thanks Don.

Well, that all seems clear enough - the parser must have done exactly what Ellen thought it had done. The deobfuscator evidently takes things a step too far in at least some cases where a non-url text string contains "www." (tri-dub dot). And Don has fixed the problem of the erroneous reporting caused by that in this instance by flagging www.info as 'innocent bystander' (and nslookup www.info.multi.surbl.org comes up NXD so that's clear as well). So, provided their ISP is cool the immediate problem is gone. Long term? It doesn't exactly seem a frequent problem but 'unexpected results' = unpredictability.

More oddities noted:

Not only do I not see how the best4www.info managed to get converted to www.info, but the only places I see that best4www.info showing is within a mailto: address .... so there's a question about the extraction of the Domain part of an e-mail address involved in the parse somehow. I must be missing something, but these old eyes aren't seeing it thus far.

After having now seen Farelf's last .... I don't quite follow the parser 'stripping' action as has been suggested. if the "best4" had been followed by a period, making it a sub-domain, I could follow the logic. However, there is no period, so shouldn't be considered a sub-domain. I suggest that this is a bug and needs to have some programming analysis and 'repair' performed.

Exactly, the email address occurs 12 times in the message body (and twice in the headers), www.info appears nowhere except in the string best4www.info of the domain part of the email address. The stripping of the www.info part is reported in this section of the parseSo, definitely a bug, unexpected and unwelcome results. I was 'agonizing', no point in that , a bug is a bug and I will respond to Ellen's email by requesting it be ticketed which she has probably already done, once she got over her amazement/disbelief, but hasn't said so. Confess that I was thinking before seeing the data that 'someone or something' had mangled the message to cause this but that isn't evident. That message certainly is 'complex' in the body part which may have some bearing but mime boundary is properly declared, expressed and terminated, further conjecture seems pointless ...

[on edit] Of couse the other factor is that, by deliberate decision, SC does not report on email addresses - so it might seem nothing with a contiguous '@' in the string should be worked on at all. But, in 'stand-alone' mode, the parser retains the ability to find the ISP for a pasted-in email address (an old capability which is similar to the stand-alone lookup/parse of a website). This is occasionally useful in research - it gives some additional information - and is probably why a simple exit based on the contiguous @ isn't in place. I guess we might/could lose this if/when the bug is ever fixed.

The parser might be "Resolving link obfuscation" with any domain inside an <a ... tag in HTML, but (normally) just dropping it when it is not a URL/URI. I haven't noticed before but I did notice this one:
http://www.spamcop.net/sc?id=z2366507399z3...b34fcfadca4ca7z
In case the parse changes with processor, with "05look $Revision: #1 $ produced by sc-app9" the email address inside a tag certainly triggers deobfuscation action
No word from Ellen/deputies on request to lodge a bug report - it may be considered that recurrence is too unlikely to bother about (but that's not wholly the point). Or my message may have been lost. Or ... who knows?

Very strange. Admitting that you got me to read your spam, and therefore once again amazed at the lunacy of some spammers. Broken HTML, bad text, the lame attempt at a bad phish, on and on. But, back on point ....

Same server involved in my look-see, same results. Simply having to note that (also ignoring that the various e-mail addresses don't match) the text version is ignored .... as is the screwed HTML mailto: link. Only the incorrectly included 'href' link is snagged by the parser. Yeah, I'll pretend/assume that the Resolving link obfuscation quit becaus it was recognized as an e-mail address, but ....?????

I do know that Don read this Topic back when it was 'new' .... after the "think it's a bug" dialog. Was hoping that there'd be some kind of feedback.

And he apparently read my update, above. I am confident now we'll be told anything that's worth sharing - and I imagine the point that *any* unexpected progam behavior should be looked at by the programming staff is well recognized.