Jump to content

Error using two-part form


qjvgpuryy

Recommended Posts

I tried to report a spam using the two-part form (like I always do) and got this result:

spam Header

No blank line deliniating headers from body - abort

This page may be saved for future reference:

http://www.spamcop.net/sc?id=z522625164z23...8e65d65f1ca40ez

Skip to Reports

View entire message

Parsing header:

No source IP address found, cannot proceed.

Add/edit your mailhost configuration

Finding full email headers

Submitting spam via email (may work better)

Example: What spam headers should look like

No body provided, check format of submission

I viewed the entire message, and I think the important line is

X-SpamCop-note: Converted by merging mime and mail headers (eudora 4)

Can anyone tell me how to fix this?

Link to comment
Share on other sites

No, it happens every time I try to submit this e-mail.

I added a blank line at the end of the header section, then at the beginning of the body section, then both places and still got the same result.

I forgot to mention in the original post that the e-mail is from Outlook, not Eudora. I'm not sure why SpamCop thinks it's in a Eudora format.

Thanks for the suggestions anyway,

qjvgpuryy

Link to comment
Share on other sites

Outlook and some versions of Eudora had the same problematic issues, thus the "combined" description. I'm kind of stuck here, I don't know how many users are doing the two-part form, but even if we go with "at least 100 people" .. you're the only one posting with this particular issue. No traffic on this in the newsgroups, and nothing seen in the Forums. If you've already tried adding "two" blanks lines, and still getting the same error, hmmmm .. I know that there's nothing I can do at this level. Will kick a note to Deputies, ask them if they've heard this one or have any other ideas ... Sorry I can't come up with anything a bit more obvious.

Link to comment
Share on other sites

Outlook and some versions of Eudora had the same problematic issues, thus the "combined" description.  I'm kind of stuck here, I don't know how many users are doing the two-part form, but even if we go with "at least 100 people" .. you're the only one posting with this particular issue.  No traffic on this in the newsgroups, and nothing seen in the Forums.  If you've already tried adding "two" blanks lines, and still getting the same error, hmmmm .. I know that there's nothing I can do at this level.  Will kick a note to Deputies, ask them if they've heard this one or have any other ideas ... Sorry I can't come up with anything a bit more obvious.

...FWIW, I think kicking a note up the chain is the right thing to do in this case.

Link to comment
Share on other sites

Today I got another e-mail with the same problem (tracking URL is http://www.spamcop.net/sc?id=z526171269z00...8a7f58d6154f24z).

I'd like to know if anything is being done. Am I likely to hear back from a Deputy?

Well, it's like this. I've gone back and forth with Ellen on this. Bottom line, no one esle is complaining of this issue. The posted "samples" have the problem already described - lack of a blank line between the header and body. As "we" know that there are ton load of folks submitting with Outlook without running into this problem this would appear to suggest that it's not a SpamCop problem. But what is needed is an actual copy of the actual spam . preferably prior to Outlook screwing it up. The previously suggested "add some blanks lines" that was "agreed to" and then described as "also didn't work" has caused much confusion, as this can't be duplicated for anyone else.

At this point, no answer, Ellen can't parse your stuff due to the MailHost issue, and without seeing the actual spam and/or watching over your shoulder as you walk through the manipulations involved in submitting your spam, "we" are at a loss as to how to "fix" your issue.

How many spams do you get the parse OK? Can you compare the source data yourself and see what the difference is between one that works and one that doesn't? Apparently, the specific part would be at the tail end of the header ...????

Link to comment
Share on other sites

How many spams do you get the parse OK?

It's been over a month since I signed up, but I haven't been keeping a count. My estimate is hundreds.

Can you compare the source data yourself and see what the difference is between one that works and one that doesn't? Apparently, the specific part would be at the tail end of the header

Yes. The difference seems to be that most spam headers end with a line like

----05100402183120804512--

where these spams end with lines after that type of line, for example

----8992094567421009687

Content-Type: text/html;

Content-Transfer-Encoding: 7Bit

(note that it ends with blank lines, which were then (I guess) stripped off)

Bottom line, no one esle is complaining of this issue.

Maybe this is the start of a new attempt to keep SpamCop from working.

But what is needed is an actual copy of the actual spam . preferably prior to Outlook screwing it up.

I wish I could do that. The best I can do now is provide the headers and the body separately.

Link to comment
Share on other sites

Yes. The difference seems to be that most spam headers end with a line like

 

----05100402183120804512--

Ouch ... sever issue here. This is "NOT" a "Header line" ..... Actually, what you just offered looks more like an "ending boundary line" which would normally be seen towards the bottom of the spam "body" ....

where these spams end with lines after that type of line, for example

 

----8992094567421009687

Content-Type: text/html;

Content-Transfer-Encoding: 7Bit

(note that it ends with blank lines, which were then (I guess) stripped off)

And again, the "blank lines" in question should exist "above" these lines .. these lines are "body" content ....

At this point, it's all too easy to suggest that you are cutting/pasting some bad data into the parsing form. Again, as there isn't a large body of complaints backing your findings, and that "we" can't seem to duplicate the problem, are you sure that you're selecting the data to copy into the two-part form correctly?

Link to comment
Share on other sites

I called them headers only because that was the term used on the FAQ page SpamCop FAQ: Outlook 98 and 2000. They look a lot like the lines on the FAQ page SpamCop FAQ: What do you mean by "full headers"? except for the matching (added by Outlook?) lines consisting of hyphens and random(?) characters, like these ...

----6100291900096822
Content-Type: text/html;
	charset="iso-8859-1"
Content-Transfer-Encoding: base64


----6100291900096822--

At this point, it's all too easy to suggest that you are cutting/pasting some bad data into the parsing form.

It's possible ...

are you sure that you're selecting the data to copy into the two-part form correctly?

I've been using the same procedure since I started reporting, and it has worked every time except twice, so I hope it is correct. :-/

Link to comment
Share on other sites

except for the matching (added by Outlook?) lines consisting of hyphens and random(?) characters

That is the problem...Those hyphens and random characters are supposed to be the start and end of one part of the body. It allows the mail message to have multiple bodies, usually in various levels of "prettyness". There will usually be one line in the headers telling you what to look for to determine the boundries of the various sections.

headers

html body

text body

Link to comment
Share on other sites

I called them headers only because that was the term used on the FAQ page SpamCop FAQ: Outlook 98 and 2000. They look a lot like the lines on the FAQ page SpamCop FAQ: What do you mean by "full headers"? except for the matching (added by Outlook?) lines consisting of hyphens and random(?) characters

Sorry, I can't agree with your picture ... the first reference "talks" about headers, offers up a way to try to grab those headers, then suggests some other thrid-party tools to attempt the same. The second link offers a smmple of a "plain/text" header, which doesn't relate to your Outlook/Eudora issue at all.

In your case, the header line that concerns you would look like;

X-Content-Type: multipart/alternative;

boundary="--924693998908718"

and then in the BODY you would see things like (if you weren't using Outlook / Eudora;

----924693998908718

Content-Type: text/html;

charset="iso-8859-1"

Content-Transfer-Encoding: base64

and at the 'bottom of the samp, the 'ending boundary line;

----924693998908718--

Let's try this .. Header lines should start with 'some word' followed by a colon (ignoring those lines too long to fit on one line) ... see the differences above. So the point is, if you are copying stuff into the "header" part of the teo-part form that doesn't start with "some word" followed by a colon (again, ignoring the "line too long" aspect) then you are copying too much or the wrong things .... this may be where and why the "blank lines" are getting eaten????

Link to comment
Share on other sites

Yes. The difference seems to be that most spam headers end with a line like

 

----05100402183120804512--

Ouch ... sever issue here. This is "NOT" a "Header line" ..... Actually, what you just offered looks more like an "ending boundary line" which would normally be seen towards the bottom of the spam "body" ....

<snip>

...FYI, Outlook includes the MIME (?) boundary lines in its "Internet Headers."

Link to comment
Share on other sites

Are you stating that my Jun 30 2004, 08:31 PM is wrong?  And that the "end Boundary line" as offered for sample is somehow the "defined" boundary line in the header?

...Me, say you are wrong? No way! :) <g> I'm just trying to explain why qjvgpuryy is referring to the separator lines header lines -- because Outlook calls them that, even though in Internet e-mail (SMTP?) terms they are not.

Link to comment
Share on other sites

So there are three definitions of body and header in this discussion - e-mail specification, Outlook, and what the two-part form is expecting. No wonder we're not getting anywhere.

That is the problem...Those hyphens and random characters are supposed to be the start and end of one part of the body.

After unsuccessfully attempting to reproduce the parse problem by removing the last boundary line, I looked at the body and noticed that the matching line was actually at the end of it.

(end of Outlook header)

----924693998908718
Content-Type: text/html;
Content-Transfer-Encoding: 7Bit


(end of Outlook body)

&lt;P align=center&gt;&lt;FONT face=Tahoma size=3&gt;  Xan&lt;FONT 
style="FONT-SIZE: 1px"&gt;z&lt;/FONT&gt;ax - Cia&lt;FONT style="FONT-SIZE: 1px"&gt;w&lt;/FONT&gt;lis 
- Via&lt;FONT style="FONT-SIZE: 1px"&gt;h&lt;/FONT&gt;gra - Vali&lt;FONT 
style="FONT-SIZE: 1px"&gt;e&lt;/FONT&gt;um&lt;BR&gt;&lt;BR&gt;&lt;B&gt;&lt;A 
href="(address removed because of personal information in it)" 
target=_new&gt;Pl&lt;FONT style="FONT-SIZE: 1px"&gt;a&lt;/FONT&gt;ace Your Or&lt;FONT 
style="FONT-SIZE: 1px"&gt;d&lt;/FONT&gt;der Here Tod&lt;FONT 
style="FONT-SIZE: 1px"&gt;z&lt;/FONT&gt;ay&lt;/A&gt;&lt;/B&gt;&lt;/FONT&gt; &lt;/FONT&gt;----924693998908718--- 
&lt;/P&gt;&lt;/BODY&gt;&lt;/HTML&gt;

I then attempted a new parse with a previously successfully submitted e-mail with that line moved to the end of the body and reproduced the error.

The e-mails are too old to submit now, even if they could be submitted with the line moved from the end of the Outlook body to the end of the Outlook header (a definite Material change to spam which isn't allowed). I could send the Outlook body and header to a deputy, who in turn could compare them to e-mails forwarded to SpamCop to see if they were already reported and/or processed correctly.

Thanks everyone for all the work you've put into this.

Link to comment
Share on other sites

The "boundary line" in your sample "at the end of the body" is wrong in several ways. First of all, based on the snippet your provided, it should be found below the line "</P></BODY></HTML>" ... How it got to put into the middle of some HTML code I can't come up with. Secondly, there should only be two dashes after that string, whereas your sample shows three. Another one I can't guess at how it happened.

Link to comment
Share on other sites

Are you stating that my Jun 30 2004, 08:31 PM is wrong?  And that the "end Boundary line" as offered for sample is somehow the "defined" boundary line in the header?

...Me, say you are wrong? No way! :) <g> I'm just trying to explain why qjvgpuryy is referring to the separator lines header lines -- because Outlook calls them that, even though in Internet e-mail (SMTP?) terms they are not.

Hey, if I'm wrong, nail me <g> ... I need to know before I go spouting off wrong stuff elsewhere <g> .... The inclusion of the data and description of MIME and Boundary lines in the header I can agree with, but I do hve to note that the sample I was quoting had the characteristics of being the "end Boundary line" ... the two dashes at the end of the string denotes that there aren't any more to follow ... see my Jun 30 2004, 08:31 PM where I tried to show the difference between these "strings of data bits" ...

Link to comment
Share on other sites

What can I say - that's what Outlook gave me, so that's what I posted.

...Which suggests that something Outllook (or maybe Exchange) is doing to your incoming spam is causing the SpamCop parser to (propery) puke. I guess you'll just have to make the "material" change to such spam, cancel the report and manually LART. :( <frown>

...Maybe Microsoft will get its act together one day. But I ain't holding my breath! :) <g>

Link to comment
Share on other sites

Archived

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

×
×
  • Create New...