Yahoo spam no body because of a ton of references

[Schmide]

Return-path: <webweg946[at]gdfasr.com>

Envelope-to: x

Delivery-date: Tue, 09 Dec 2014 01:41:34 -0500

Received: ME

(snip)

References: <#.#.#.JavaMail.yahoo[at]jws10069.mail.ne1.yahoo.com> (repeat very long)

(^ This kills spamcop)

Subject: Your winning information is attached in this email

MIME-Version: 1.0

Content-Type: multipart/mixed;

boundary="----=_Part_###"

Content-Length: 72489

(snip)

[Farelf]

Hi Schmide,

Haven't heard of a (properly constructed) header breaking the parser before. Does that mean the parser page does not display a tracking URL (up near the head of the parse) before you dismiss it? If it does you could copy that and paste it here, even though no reports are generated and the reference is not recoverable from your report history. What errors does the parser bleat? Are you "pasting in" the spam in the submission form or e-mailing?

First thought is this could be a mangling introduced by the tools used in whichever submission method (supposing paste in given Yahoo problems with forwarding attachments).

[Schmide]

Sorry it was late at night when I found it.

Here's a tracking url for it.

https://www.spamcop.net/sc?id=z6028469378z3a0635c3ac1601ae431b595e5cccb578z

Well it doesn't break spamcop's engine, but it does make it unreportable.

[turetzsr]

Hi, Schmide,

&nbsp &nbsp&nbsp&nbsp&nbsp If no one comes by right away with a better idea, please report this to the SpamCop Deputies at e-mail address deputies[at]admin.spamcop.net. It may be helpful to them if you would include the spam as an attachment to your e-mail to them. For brevity, you could also refer them to this Forum Topic (http://forum.spamcop.net/forums/topic/14612-yahoo-spam-no-body-because-of-a-ton-of-references/).

[Lking]

If I read the tracking URL correctly and looking at the complete message I see the following:

1. The OP is correct that the References line in the header is causing the issue. Because it is so long the parser is trunking the message. The shorter message does not contain a blank line (end of the header) followed by a body. Resulting in the error message "No body text provided, check format of submission. spam must have body text."

2. The OP has the advantage of the original full message which is not what the parser sees. Following the tracking URL, and clicking on "View entire message" and scrolling waaaaay down you can see the SC parser does not see "Subject" and following parts of the message. Some place, but I can't remember where, there is a discussion on trunkation of long message. Don't remember if there is a workaround.

[turetzsr]

<snip>

Some place, but I can't remember where, there is a discussion on trunkation of long message. Don't remember if there is a workaround.

&nbsp &nbsp&nbsp&nbsp&nbsp IIRC, that applied only to the message body, not to the headers (but I could be failing to remember something about truncating the headers, too).

[Lking]

I though it was a storage issue, therefore overall size which in most cases would only affect the body. But without facts, I can adjust what I "remember" to fit my conclusion. In any case looking at what SC displays it looks like much of the message was dropped.

[turetzsr]

<snip>

it looks like much of the message was dropped.

&nbsp &nbsp&nbsp&nbsp&nbsp And, specifically, that headers were dropped. Which SC seems to assume was done by the user by mistake or by the e-mail or internet provider either by design or in ignorance and therefore will refuse to parse.

&nbsp &nbsp&nbsp&nbsp&nbsp All of which is idle speculation and would seem to require a more knowledgeable look by an SC Deputy. <g>

[Schmide]

Email sent to deputies.