Why "No source IP found"

[fredfighter]

Moderator note: This was originally posted in the Reporting forum but was move here due to specifics found later in the thread which make it a bit more appropriate to this forum. The acutal reporting issues do apply to both forums.

The only difference in reporting from WebMail is the extra option of quick reporting as a menu bar item. and access to the alternate VER interface which has additional options. [/Moderator note]

I'm trying to report a spam with the headers appended below.

SpamCO returns the error: "No source IP address found, cannot proceed."

I've tried taking out the carriage returns to make the "Received:" all

one line each. Sometiimes that helps, but not in this case. I've

replaced the sender's name and domain with x[at]example.com,

(only here, not when I submitted it) otherwise the headers are unmunged.

Can someone tell me why this won't parse?

Return-Path: <x[at]example.com>

Delivered-To: spamcop-net-fredfighter[at]spamcop.net

Received: (qmail 22191 invoked from network); 31 Aug 2005 21:13:26 -0000

Received: from unknown (192.168.1.101)

by blade6.cesmail.net with QMQP; 31 Aug 2005 21:13:26 -0000

Received: from cpe-66-24-18-35.stny.res.rr.com (HELO mjdtools.xxx) (66.24.18.35)

by mailgate.cesmail.net with SMTP; 31 Aug 2005 21:13:25 -0000

Received: by MJDTOOLS with Internet Mail Service (5.5.2653.19)

id <R9AR5XL3>; Wed, 31 Aug 2005 17:03:31 -0400

Message-ID: <C0A636275F1ED911A3930060973CEEBF87E9D0[at]MJDTOOLS>

From: "example.com" <x[at]examplem.com>

To: "'fredfighter[at]spamcop.net'" <fredfighter[at]spamcop.net>

Subject: Absentee Bidding Reminder - September 9th & 10th Antique Tool Auc

tion Weekend, Nashua, NH

Date: Wed, 31 Aug 2005 17:03:21 -0400

MIME-Version: 1.0

X-Mailer: Internet Mail Service (5.5.2653.19)

Content-Type: multipart/alternative;

boundary="----_=_NextPart_001_01C5AE6F.6B6F8240"

X-spam-Checker-Version: SpamAssassin 3.0.2 (2004-11-16) on blade6

X-spam-Level: **

X-spam-Status: hits=2.2 tests=FORGED_RCVD_HELO,HTML_FONT_BIG,HTML_MESSAGE,

HTML_TAG_EXIST_TBODY,SARE_OBFUAUCTION version=3.0.2

X-SpamCop-Checked: 192.168.1.101 66.24.18.35

This message is in MIME format. Since your mail reader does not understand

this format, some or all of this message may not be legible.

------_=_NextPart_001_01C5AE6F.6B6F8240

Content-Type: text/plain;

charset="iso-8859-1"

[StevenUnderwood]

I'm trying to report a spam with the headers appended below.

32273[/snapback]

What you do not state is HOW you are submitting this message. Pasting it, email submission, etc.

Are you getting a tracking URL? That would be better than pasting headers here because of the way this app handles whitespace. Also, anyone with mailhosts configured can not attempt to parse your message.

You need to make sure every line starts with either whitespace or a header name which would end with a colon and a space. One thing I notice is your subject line is wrapped.

[Wazoo]

http://www.spamcop.net/sc?id=z801925412zf1...1cd71874b93679z is a parse of the results of my 'fixing' your sample. I've got leave it to "you" to see how it differs from your actual spam / submittal. It seem pretty easy to suggest that the problem is coming from how you are handling the spam to be submitted.

[turetzsr]

I'm trying to report a spam with the headers appended below.

SpamCO returns the error:  "No source IP address found, cannot proceed."

I've tried taking out the carriage returns to make the "Received:" all

one line each.

<snip>

32273[/snapback]

...If you submit the resulting reports, that may constitute a violation of SpamCop reporting rules. See Material changes to spam FAQ page for more information.

[fredfighter]

What you do not state is HOW you are submitting this message. Pasting it, email submission, etc.

Are you getting a tracking URL? That would be better than pasting headers here because of the way this app handles whitespace.  Also, anyone with mailhosts configured can not attempt to parse your message.

You need to make sure every line starts with either whitespace or a header name which would end with a colon and a space.  One thing I notice is your subject line is wrapped.

32276[/snapback]

No, it has been my experience that SpamCop does not return a tracking URL for

spams it cannot parse. Sometimes (but I digress) it will not even provide a link

to see the spam it has failed to parse which is especially inconvenient when

the spam has been submitted via email queue and already deleted from the reciepient mailbox

I was cutting the spam from the "Message Source" window and pasting it

into the "Report another spam Window"

Another respondent in this thread indicates that this problem was an artifact

of that process that I didn't catch. Line-wrapping and similar problems seem

to be an artifact of how text is read into the "Report antoher spam" window

and perhaps is a bug that shouls be addressed. IMHO the window is in-

conveniently small, especially from left to right.

--

FF

[fredfighter]

http://www.spamcop.net/sc?id=z801925412zf1...1cd71874b93679z is a parse of the results of my 'fixing' your sample.  I've got leave it to "you" to see how it differs from your actual spam / submittal.  It seem pretty easy to suggest that the problem is coming from how you are handling the spam to be submitted.

32280[/snapback]

Thanks. I thought I had 'fixed' all the problesm introduced by cutting and

pasting.

--

FF

[fredfighter]

...If you submit the resulting reports, that may constitute a violation of SpamCop reporting rules.  See Material changes to spam FAQ page for more information.

32282[/snapback]

It will not becausee removing whitespace/carriage returns that were introduced

when the spam was cut and and pasted is not a material change. In fact,

the whitespace/carriage returns that are removes are a correction to restore

the spam ot its 'as received' state, although the changes in this case were

immaterial in nature.

Another common problem is that SpamCop does not generate reprots for blank

spam. Adding a blank line and a notation like (blank) where the body of the spam

normally would be is not a material change.

(Just becuase the spammer/spamware screwed up and forgot to include a payload

is no reason to not report the spam.)

Thanks.

--

FF

[Wazoo]

It will not becausee removing whitespace/carriage returns that were introduced

when the spam was cut and and pasted is not a material change.  In fact,

the whitespace/carriage returns that are removes are a correction to restore

the spam ot its 'as received' state, although the changes in this case were

immaterial in nature.

Dangerous ground being walked on there. Especially when pointing to spam that was intentionally "screwed up" by the originator. Statements like this placed before folks that aren't really up-to-speed on things can get them into trouble also.

Another common problem is that SpamCop does not generate reprots for blank spam.  Adding a blank line and a notation like (blank) where the body of the spam normally would be is not a material change.

32360[/snapback]

Actually, the jury is still out on that one. Granted, the general guidance is as you suggest, but .... the SpamCop FAQ entry on reporting rules and guidelines offer no such loophole. There is a complete lack of Deputy statements making an "ageement" that this is acceptable, more than likely based on the remarks I made above. Some folks don't know what a "blank e-mail" actually is (thus an entry in the How to Use ... forum that shows the difference in what might be displayed and what the e-mail actually contains ....)

Bottom line, spam submittals should contain the "as received" spam. If you actually have to manipulate the spam to "make" it parse, there are other issues that probably need to be worked.

[turetzsr]

I'm trying to report a spam with the headers appended below.

SpamCO returns the error:  "No source IP address found, cannot proceed."

I've tried taking out the carriage returns to make the "Received:" all

one line each.

<snip>

...If you submit the resulting reports, that may constitute a violation of SpamCop reporting rules. See Material changes to spam FAQ page for more information.

32282[/snapback]

It will not becausee removing whitespace/carriage returns that were introduced

when the spam was cut and and pasted is not a material change. In fact,

the whitespace/carriage returns that are removes are a correction to restore

the spam ot its 'as received' state, although the changes in this case were

immaterial in nature.

<snip>

32360[/snapback]

... *BLUSH* I did not read carefully enough what you had written you were editing. Now that you have explained (which should not have been necessary, as what you originally wrote was quite clear enough to anyone who is able to read properly <g>), I agree with you.

[fredfighter]

Dangerous ground being walked on there.  Especially when pointing to spam that

was intentionally "screwed up" by the originator.

If by originator you mean the spammer then that is a particularly bizarre statement

because no one ponted out that it was intentionall "screwed up" by the originator.

Evedently it was screwed up when I cut it from the "display message" window and

pasted it into the "Report another spam" window probably due to a bug in the

way the "Report another spam" window reads text that is pasted into it.

Statements like this placed before folks that aren't really up-to-speed on things can > get them into trouble also.

Statements like what? You've lost me again. Once the headers have been

"screwed up" by the uct and paste process leaving them screwed up would

mean submitted a spam after making a material change to the headers,

albeit na unintentional one. Surely you do not sugggest that putting the

headers back the way they were before the cut and paste process

"screwed them up" is making a material change to the spam.

Actually, the jury is still out on that one.  Granted, the general guidance is as you suggest, but .... the SpamCop FAQ entry on reporting rules and guidelines offer no such loophole.  There is a complete lack of Deputy statements making an "ageement" that this is acceptable, more than likely based on the remarks I made above.

Your comments above do not seem to be germaine to the matter at hand.

Some folks don't know what a "blank e-mail" actually is (thus an entry in

the How to Use ... forum that shows the difference in what might be displayed and what the e-mail actually contains ....)

I've pretty much given up on trying to find a "How to Use" FAQ for Spamcop.

Bottom line, spam submittals should contain the "as received" spam.

If you actually have to manipulate the spam to "make" it parse, there

are other issues that probably need to be worked.

Yes. In the instant case the other issue was fixing the changes that resulted

from cutting and pasting the spam into the window for reporting it. Hopefully

we are clear on this now.

Digressing to the issue of blank spams, is there any good reason why

SpamCop should not parse headers only? spam is unsolicited bulk

email, by definition, independent of payload.

--

FF

EDIT: Wazoo fixed Quoting issues in this post

[turetzsr]

> Dangerous ground being walked on there.  Especially when pointing to spam that

> was intentionally "screwed up" by the originator.

<snip>

Statements like what? You've lost me again. Once the headers have been

"screwed up" by the uct and paste process leaving them screwed up would

mean submitted a spam after making a material change to the headers,

albeit na unintentional one. Surely you do not sugggest that putting the

headers back the way they were before the cut and paste process

"screwed them up" is making a material change to the spam.

32388[/snapback]

...If you intervene, including intervening to put "the headers back the way they were before the cut and paste process 'screwed them up.'" then you run the risk of making a material change to the spam.

> Actually, the jury is still out on that one.  Granted, the general guidance is as you

> suggest, but .... the SpamCop FAQ entry on reporting rules and guidelines offer no >such loophole.  There is a complete lack of Deputy statements making an >"ageement" that this is acceptable, more than likely based on the remarks I made >above. Your comments above do not seem to be germaine to the matter at hand.

32388[/snapback]

...IIUC, Wazoo is saying that it has been suggested by other SpamCop users (that is, general guidance) that "[a]dding a blank line and a notation like (blank) where the body of the spam" is something one might do, but that there is been no "official" corroboration, either in the "official" FAQ or by means of a comment from a SpamCop Deputy or employee.

> Some folks don't know what a "blank e-mail" actually is (thus an entry in

>the How to Use ... forum that shows the difference in what >might be displayed and what the e-mail actually contains ....)

I've pretty much given up on trying to find a "How to Use" FAQ for Spamcop.

...Try "How to Use" forum.

<snip>

Digressing to the issue of blank spams, is there any good reason why

SpamCop should not parse headers only?  spam is unsolicited bulk

email, by definition, independent of payload.

32388[/snapback]

...We users don't know for sure (AFAIK). It has been suggested that because the SpamCop parser can not distinguish between a spam without a body and a botched submission by one of us users, it takes the conservative approach and does not generate reports (an example of the oft-repeated maxim that, for SpamCop reporting, quality is more important than quantity).

[Wazoo]

If by originator you mean the spammer then that is a particularly bizarre statement because no one ponted out that it was intentionall "screwed up" by the originator.

and no one has said that. Had I said this, it would have been worded "your spam"

Evedently it was screwed up when I cut it from the "display message" window and pasted it into the "Report another spam" window probably due to a bug in the way the "Report another spam" window reads text that is pasted into it.

There is no known "bug" on that section of code. What is pasted is what gets processed, thus the errors when what is pasted is hosed. It has already been suggested that if you have to "correct" what you cut/paste, there is an issue there that needs to be dealt with.

Statements like what?  You've lost me again.  Once the headers have been "screwed up" by the uct and paste process leaving them screwed up would

mean submitted a spam after making a material change to the headers,

albeit na unintentional one.  Surely you do not sugggest that putting the

headers back the way they were before the cut and paste process

"screwed them up" is making a material change to the spam.

All I've said is that there should be no reason to "fix" the cur/pasted data. There is something else going on that needs to be 'fixed' ... apparently whatever you are using that you are cutting the data from.

Your comments above do not seem to be germaine to the matter at hand.

OK, fine ... whatever ...

I've pretty much given up on trying to find a "How to Use" FAQ for Spamcop.

I'm kind of tired of writing things up that no one seems to look at, comment on, add to, or ever re-write .... I'd suspect that there are some other contributors that are in the same boat.

Yes.  In the instant case the other issue was fixing the changes that resulted from cutting and pasting the spam into the window for reporting it.  Hopefully we are clear on this now.

Trying to figure out where you think "anyone" has been confused.

Digressing to the issue of blank spams, is there any good reason why

SpamCop should not parse headers only?  spam is unsolicited bulk

email, by definition, independent of payload.

One has to start with the original premise that only an RFC compliant e-mail makes it to the parsing point. Yes, there are hacks in place for Outlook/Eudora, but ...

[Jeff G.]

I'm kind of tired of writing things up that no one seems to look at, comment on, add to, or ever re-write .... I'd suspect that there are some other contributors that are in the same boat.

32447[/snapback]

Your writings are almost always on the mark, but I'd given up on criticizing your typos - want me to restart?

[Wazoo]

Your writings are almost always on the mark, but I'd given up on criticizing your typos - want me to restart? 

32452[/snapback]

Heh! Replacing a few keyboards was on the horizon actually. However, my son decided to make a visit with wife and those grandkids I haven't seen in a number of years. New keyboards will have to wait a bit, sorry ...

[Lking]

IMHO this thread has wandered so far from the original post that any real answer to fredfighter's question(s) may never be found.

A day or two ago when I was a newbie I also had trouble figuring out how to submit spam with out errors.

"Knowing" that no one reads the FAQ (sorry Wazoo <g>) about how to cut/past or attach spam, maybe it would be useful to ask what apps are being used, and how they're being used, to cause the errors that need to be corrected. Maybe the 'outlook/eudora workaround form' should be used?

So in that vain, fredfighter what are you using to look at your email/spam and how are you cutting and pasting the spam, with header into the spamcop form?

Just a thought.

[Wazoo]

IMHO this thread has wandered so far from the original post that any real answer to fredfighter's question(s) may never be found.

Agreed, but after so many "hints" ....????

"Knowing" that no one reads the FAQ (sorry Wazoo <g>) about how to cut/past or attach spam, maybe it would be useful to ask what apps are being used, and how they're being used, to cause the errors that need to be corrected. Maybe the 'outlook/eudora workaround form' should be used?

As seen in the SpamCop FAQ "here" ... an entry titled How To Ask Questions The Smart Way (language issue, but there really is only one defintion for RTFM) was one shot at educating folks to how to frame a 'good' query. Knowing that this was probably not going to be read, I went in and added an entry in the How to Use ... SpamCop Forum section that offered a suggestion on things to include in a query within this Forum. Even went the extra and Pinned it as Forum Use, General Intro And this data mentioned after all the previous references to the How to Use... Forum section for Reporting issues.

So in that vain, fredfighter what are you using to look at your email/spam and how are you cutting and pasting the spam, with header into the spamcop form?

Just a thought.

32455[/snapback]

If I recall correctly, the last Tracking URL offered suggested that a web browser was involved, looking at a web-mail view of e-mail in a SpamCop e-mail account. But that didn't explain the cut/paste scenario, so then figured that this e-mail was POP'd by some other tool and this was the one causing the issue with word/line wrapping. I'll admit that I didn't ask the question straight out, but again, that the 'problem' is out of the ordinary has certainly been pointed out a few times. So guess I'll say thanks for getting to the point

[Lking]

It's true, put up signs pointing the way, read them the signs, take them by the hand and lead them to 'water', stick their face in it, and yet ... It does get old, but thus is the life of those that choose to serve.

During a local election I watched a pole worker smile again and again every time a voter told the same lame joke about the paper ballets. I ask her how she did it, 'Think God this is a small town!' she said with the same practiced smile.

[fredfighter]

...

So in that vain, fredfighter what are you using to look at your email/spam and how are you cutting and pasting the spam, with header into the spamcop form?

Just a thought.

32455[/snapback]

I'm running the SpamCop webmail client using FireFox. I cut and paste

using the default cut and paste buffer (clipboard?).

--

FF

[fredfighter]

There is no known "bug" on that section of code.  What is pasted is what gets processed, thus the errors when what is pasted is hosed. It has already been suggested that if you have to "correct" what you cut/paste, there is an issue there that needs to be dealt with.

All I've said is that there should be no reason to "fix" the cur/pasted data.  There is something else going on that needs to be 'fixed' ... apparently whatever you are using that you are cutting the data from.

It sure looks to me that when I cut and paste spam into that window,

carriage returns are introduced that were not there in the original headers.

Those carriage returns break up the headers making them unparsable.

This isn't a sometimes thing, it appears to happen pretty much every time.

I'd call that a bug. Maybe its a bug in FireFox, Netscape, and MSIE, but

it still looks buggy to me.

--

FF

EDIT: wazoo fixed the quote tags

[Wazoo]

It sure looks to me that when I cut and paste spam into that window,

carriage returns are introduced that were not there in the original headers.

Those carriage returns break up the headers making them unparsable. 

This isn't a sometimes thing, it appears to happen pretty much every time.

I'd call that a bug.  Maybe its a bug in FireFox, Netscape, and MSIE, but

it still looks buggy to me.

33252[/snapback]

There may yet be more to the picture. For example, all your posts thus far are showing with "short" lines, as compared to everyone else's posts. This application doesn't do that. What are the odds that you're one of the folks I was asking for input from at http://forum.spamcop.net/forums/index.php?showtopic=4894 ...

Your suggested issue hasn't come up before .. so I'll also ask for help from someone else ... is the web-browser window sizeable? and if so, does narrowing down that window then cause "hard" returns to be inserted into the resulting 'scrunched' display of the e-mail? And of course, the possibility that this is also a web browser issue ... as IE6 is the general standard version these days, the version of FireFox needs to be identified (possibly extensions in use), Opera version numbers are all over the place, so that would need to be identified ...Lynx anyone?

[Jeff G.]

FF, are you pasting in the entire contents of the "Message Source" Page from Webmail? Thanks!

[fredfighter]

OK, same problem.

Here's the tracking URL:

http://www.spamcop.net/sc?id=z809689387z1e...fc8c89b11af6c1z

Why can't SpamCop parse this?

How do I report it, other than by looking up the sender's ISP using

SamSpade for Windows, GeekTools or some such?

--

FF

[fredfighter]

There may yet be more to the picture.  For example, all your posts thus far are showing with "short" lines, as compared to everyone else's posts.  This application doesn't do that.  What are the odds that you're one of the folks I was asking for input from at http://forum.spamcop.net/forums/index.php?showtopic=4894 ...

Your suggested issue hasn't come up before .. so I'll also ask for help from someone else ... is the web-browser window sizeable?  and if so, does narrowing down that window then cause "hard" returns to be inserted into the resulting 'scrunched' display of the e-mail?  And of course, the possibility that this is also a web browser issue ... as IE6 is the general standard version these days, the version of FireFox needs to be identified (possibly extensions in use), Opera version numbers are all over the place, so that would need to be identified ...Lynx anyone?

33254[/snapback]

OK, I checked out that thread and posted my settings.

When composing in this bulletin board or whatever it is I have been

putting my own carriage returns in otherwise the lines are way too

long for my taste.

It may be that the header problem was NOT just a whitespace/linewrap

issue. The person who 'fixed' my headers to make them parse didn't

actually say what was done. It just looked to me that he put each

header on its own line. There is no doubt that cutting an pasting into

the "report spam" window introduces a number of chnges in the

way the headers are wrapped.

I'm having the same problem again with another spam from the same

source and have posted a tracking URL in another article.

I'm using FireFox 1.0.4.

--

FF

[fredfighter]

FF, are you pasting in the entire contents of the "Message Source" Page from Webmail?  Thanks!

33265[/snapback]

Yes.

I copy from the Webmail "Message Source" and paste into the

"Report spam" window.

--

FF

[fredfighter]

else ... is the web-browser window sizeable?

The SpamCop "Report spam" window is not resizeable, when you

paste spam into it that is longer than the window scroll bars appear.

Changing the size of the FireFox browser window does not change

the size of the SpamCop "Report spam" window.

--

FF