Jump to content

.info urls not being reported


hotdlz

Recommended Posts

I have been recaiving about 4 spam messages a day from the same spammer (different mail host IPs of course), all which have similar .info URLs, but none of those URL's ISPs are being contacted. Every time I submit this spam, spamcop always says "no links found in body", but there is clearly a link in each body.

Here's one of the spam reports I just sent:

http://www.spamcop.net/sc?id=z691325306z93...608e359a1a925az

If you view the entire message, you can see the link is there. Maybe because it's a .info URL? Maybe because the URL looks fake? Personally I can resolve the URL to an IP address and track down its origin is "Sun Network" in Las Vegas. I wish spamcop would notify them about this spammer.

Link to comment
Share on other sites

Problem starts right out with the lines;

Content-Type: multipart/alternative;

      boundary="bri6TkKFEvCGx2e3rB"

And the lack of corresponding Bundary lines within the spam.

So the "answer" starts right out with;

How are you submitting the spam?

What software is in ues / on what platform?

Have you been to the FAQ?

Link to comment
Share on other sites

How are you submitting the spam?

What software is in ues / on what platform?

20085[/snapback]

I use "pine" on unix as my mail reader. Whenever I get spam, I open up all headers, save the original message as ascii text, then I copy/paste the spam onto spamcop's webpage.

These messages have attachments, and my virus protection program immediately dropped the attachments because they contained java scri_pt text with html layers, so I was left with just the original email.

Link to comment
Share on other sites

For that spam, if you were to change

Content-Type: multipart/alternative;

         boundary="bri6TkKFEvCGx2e3rB"

to
Content-Type: text/html
and note that change in your "Additional notes", you would get a parse of the URL, as seen at http://www.spamcop.net/sc?id=z691347910z76...a35c6e89dfb798z .

EDIT: That would work for asking the Parser where you should send one or more Manual Reports.

Link to comment
Share on other sites

Won't fault Jeff G's suggestion in this case ... but missing is the bit of caution ... if you don't know what you are doing exactly, are the least bit unsure of how to read headers and you do apply a bit of "touch" to a spam to "make it parse" ... just be aware that you could be putting your account into jeopardy. Ellen's posts over the last many months make it pretty clear that the Deputies and Don take the FAQ literally on this subject.

Link to comment
Share on other sites

Wazoo is right. Please use even more caution in modifying spam for submission than you would use in modifying a Windows Registry. You can always send an Additional Report or Manual Report to the ISP responsible for the URL.

Link to comment
Share on other sites

Since I simply copy/paste the original email (including headers), would it be okay if I just remove the Content-type header?  Rather than modifying any headers, I would feel more comfortable just removing that header.

20099[/snapback]

...But, again, be aware that you would be violating SpamCop rules by proceeding with the "Send Reports" after the resulting parse, so if you wish to send reports, generate your own e-mails that make no mention of SpamCop.
Link to comment
Share on other sites

Exactly which rules?

20106[/snapback]

Probably this one:

"Do not make any material changes to spam before submitting or parsing which may cause SpamCop to find a link, address or URL it normally would not, by design, find."

Found at:

http://www.spamcop.net/fom-serve/cache/283.html

DT

20107[/snapback]

...Thanks, DT! Which I believe is also to what Wazoo, above, 20094[/snapback] was referring.
Link to comment
Share on other sites

Wazoo, DT, and Steve are right. Removing or changing a "multipart/alternative" Content-Type is a "material change" within the meaning of SpamCop's Material changes to spam Rule, violation of which could of course result in account termination. In fact, given a recent edit, so is changing a "text/plain" Content-Type to "text/html", which used to be allowed. If you use the Parser to parse something that you have materially changed (other than just manually base-64 decoding for munging purposes) and you still want to send one or more reports, you MUST cancel the report and send one or more Manual Reports.

I'm sorry if my previous posts gave any impression to the contrary.

Link to comment
Share on other sites

Archived

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

×
×
  • Create New...