"This email contains no date" error - won't report

[Aunty Spam]

I'm getting a new error that I've never seen before.

SC is reporting that there's no date in the email even though it's there as far as I can see in every appropriate header. (I replaced emails w/ x123x).

Delivered-To: x123x

Received: by 10.114.25.165 with SMTP id d5csp136869ldg;

Sat, 19 Jan 2013 03:47:00 -0800 (PST)

X-Received: by 10.66.90.34 with SMTP id bt2mr28730687pab.29.1358596019905;

Sat, 19 Jan 2013 03:46:59 -0800 (PST)

Return-Path: <bounce-anon-x123x[at]craigslist.org>

Received: from mxo13f.craigslist.org (mxo13f.craigslist.org. [208.82.238.108])

by mx.google.com with ESMTP id u7si8579741paw.330.2013.01.19.03.46.59;

Sat, 19 Jan 2013 03:46:59 -0800 (PST)

Received-SPF: pass (google.com: domain of bounce-anon-x123x[at]craigslist.org designates 208.82.238.108 as permitted sender) client-ip=208.82.238.108;

Authentication-Results: mx.google.com;

spf=pass (google.com: domain of bounce-anon-x123x[at]craigslist.org designates 208.82.238.108 as permitted sender) smtp.mail=bounce-anon-x123x[at]craigslist.org

Received: from mout.gmx.net (mout.gmx.net [74.208.4.201])

by craigslist.org (Haraka/1.3.3) with ESMTP id 39838099-C6E4-42EC-8D5F-010D4F63D442.1

(envelope-from <x123x>);

Sat, 19 Jan 2013 03:46:44 -0800

Received: from mailout-us.gmx.com ([172.19.198.45]) by mrigmx.server.lan

(mrigmxus001) with ESMTP (Nemesis) id 0MbxJK-1TfXjJ25cE-00JFW9 for

<x123x>; Sat, 19 Jan 2013 12:46:43 +0100

Received: (qmail 8985 invoked by uid 0); 19 Jan 2013 11:46:43 -0000

Received: from 199.47.195.159 by rms-us003 with HTTP

Content-Type: multipart/alternative;

boundary="========GMXBoundary125941358596001133520"

Date: Sat, 19 Jan 2013 06:46:37 -0500

From: x123x

Message-ID: <20130119114641.125940[at]gmx.com>

MIME-Version: 1.0

Subject: CRAIGSLIST

X-Authenticated: #149463577

X-Flags: 0001

X-Mailer: GMX.com Web Mailer

x-registered: 0

X-GMX-UID: 9uKIcFZQ3zOl2njBg3whbJ9+IGRvbwC6

X-CL-ID: 39838099-C6E4-42EC-8D5F-010D4F63D442.1

To: undisclosed-recipients:;

Any ideas?

I suspect this header: "Received: from 199.47.195.159 by rms-us003 with HTTP"

but there's still sufficient doubt to not declare it the issue.

Cheers.

[SpamCopAdmin]

http://www.spamcop.net/sc?id=z5455864060z8...3368e6270f0221z

The spam parses OK for me.

All very strange.

- Don D'Minion - SpamCop Admin -

- Service[at]Admin.SpamCop.net -

.

[Aunty Spam]

Definitely strange because it still doesn't for me. I tried again in case it was a temporary system problem/glitch.

http://www.spamcop.net/sc?id=z5455860354ze...6bd941d11ca4cdz

[Farelf]

Ah, maybe it is is the difference between "mailhosted" and non-mailhosted parsing. I remember when mailhosting was first introduced there was a flurry of discussion (mostly in the newsgroups) about differences in the parsing of dates and Mike Easter made some detailed analyses of the discrepancy. Haven't heard a murmur about it for years until now but it seems there is still some difference. I just ran the spam through a non-mailhosted account and, same as Don's parse, there was no problem at all with the date-time recognition.

Don, I can probably locate that Mike Easter discussion if you want but if the problem is confined to just an occasional case it is probably of more academic interest than practical purpose. Though certainly the developers should be aware of it, if it is capable of re-surfacing. The line

Received: from 199.47.195.159 by rms-us003 with HTTP

without date would be the problem. In non-mailhosted parsing the parser evidently picks up its definitive date-time from another line and that was the specific detail M.E. looked at, "back then" (and offered some pointed comment and suggestions, IIRC ). I take it the mailhosting of the O/P's account is correct, and that line should actually be included in the parsing? (I don't know).

HTH

[DRSpalding]

I have the same issue this morning with a spam report:

http://www.spamcop.net/sc?id=z5457188401z8...49992125ace42bz

and I believe it is that same type of (probable qmail insertion?) header line:

Received: from 117.5.180.206 by rms-eu007 with HTTP

I would just delete it and report it to the abuse host (they are the same for both the actual SMTP sender and this "originating IP" address anyway) and place the removed header line in by hand in the report. Is that kosher or should I just not bother?

PS/Edit: I should also note that mine is from the same mail host of mout.gmx.net but a different IP address. Here are all the IP addrs for mout.gmx.net:

Name: mout.gmx.net

Address: 212.227.17.21

Address: 212.227.17.20

Address: 212.227.15.18

Address: 212.227.17.16

Address: 74.208.4.200

Address: 212.227.17.17

Address: 212.227.15.19

Address: 74.208.4.201

Address: 212.227.15.16

Address: 212.227.15.17

[Farelf]

That one also parses okay through a non-mailhosted account:

http://www.spamcop.net/sc?id=z5457193659z9...419ca501bd605az

You shouldn't alter the headers (big no-no) but maybe contact Don to look at your mailhosting, if there could be an issue with that. It is probably just the network with that qmail insertion though I think, as you suggest (somebody needs to lead them to the light). Anyway, his address is in his signature, a couple of posts previous.

[DRSpalding]

I do not have gmx.net as a mailhost--I have hotmail.com. It shouldn't even bother past that point, but if it knows that qmail puts in a certain format and this is not parsing from that, it could be fixed I guess.

As an aside, I added in a reasonable and proper date in the header to that particular line and it parsed wonderfully, although SpamCop seems to treat gmx.net just like hotmail/yahoo/gmail from a web interface and parses right on through it to the originating IP address:

http://www.spamcop.net/sc?id=z5457196003zc...528d4dbf75c8d5z

I won't be reporting this one either since I changed the header in a material way and I'm not sure that the whole received chain is legit to report that IP addr as the sender.

[Dale H. Cook]

I believe it is that same type of (probable qmail insertion?) header line:

Received: from 117.5.180.206 by rms-eu007 with HTTP

That does indeed seem to be the cause. I have seen this three times in recent days, coming through at least two of the several ISPs where I have email addresses. The one recieved today contained the line:

Received: from 113.161.87.235 by rms-us007 with HTTP

and adding a reasonable datestamp to that line allowed it to be reported.

I did not retain the earlier examples, but will retain this one and further examples to look for reference.

Dale H. Cook, IT Director, Centennial Broadcasting, Roanoke/Lynchburg, VA

http://plymouthcolony.net/starcityeng/index.html

[Farelf]

...The one recieved today contained the line:

Received: from 113.161.87.235 by rms-us007 with HTTP

and adding a reasonable datestamp to that line allowed it to be reported. ...

Um ... altering headers to "help" the parser is not allowed for reporting. Check with the deputies/SC admin if in doubt, before making any such submission. But cancelling a report with the suspect lines altered and subsequently posting the tracking URLs of both the failed original parse and the successful parse of the amended header might be helpful to the SC staff. Especially if such lines are now being received from overseas sources, like in that example.

[danorton]

What's the procedure for reporting this bug? I have a failing example, too.

By demanding that all but my own host's headers pass provides an easy method for spammers to prevent SpamCop from validating email. (I don't know if the IPv6 header validation still must pass, but that was for a long time an easy way to prevent spam from being reported through SpamCop.)

[turetzsr]

What's the procedure for reporting this bug?

<snip>

...This is it! You may also send an e-mail to the SpamCop Deputies: deputies[at]admin.spamcop.net.

[danorton]

...This is it! You may also send an e-mail to the SpamCop Deputies: deputies[at]admin.spamcop.net.

Okay, here's another that arrived an hour ago. The only timestamp it should consider is "06 Feb 2013 13:10:15 +0000":

Return-Path: <evapapemyp[at]gmx.com>

Received: from mout-xforward.gmx.net ([82.165.159.131])

by cust1.hostdillo.com with esmtp (Exim 4.71)

(envelope-from <evapapemyp[at]gmx.com>)

id 1U34lO-0003xV-NH

for daniel[at]danielnorton.com; Wed, 06 Feb 2013 13:10:15 +0000

Received: from mailout-us.gmx.com ([172.19.198.45]) by mrigmx.server.lan

(mrigmxus001) with ESMTP (Nemesis) id 0LkOel-1UeLO04C1z-00cNsq for

<daniel[at]danielnorton.com>; Wed, 06 Feb 2013 14:10:08 +0100

Received: (qmail 12614 invoked by uid 0); 6 Feb 2013 13:10:07 -0000

Received: from 117.242.209.130 by rms-us020 with HTTP

Content-Type: multipart/alternative;

boundary="========GMXBoundary8703136015620523741"

Date: Wed, 06 Feb 2013 08:10:02 -0500

From: "Eva Pape" <EvaPapemyp[at]gmx.com>

Message-ID: <20130206131005.87030[at]gmx.com>

MIME-Version: 1.0

To: info[at]drculottanorton.com,daniel[at]danielnorton.com,jguevara[at]dianeturton.com,swayman[at]dianeturton.com,rmclaughlin[at]dianeturton.com

X-Authenticated: #149303419

X-Flags: 0001

X-Mailer: GMX.com Web Mailer

x-registered: 0

X-GMX-UID: ejNgcZtA3zOl2BpTjXwhiq5+IGRvbwCd

Subject: offer tablets comparison

--========GMXBoundary8703136015620523741

Content-Type: text/plain; charset="utf-8"

Content-Transfer-Encoding: 8bit

et a hr kfl dfkd

jMake

uahappynhwzyourvkwoman-neekwbuyomkviagra/wuvicialisagr-go to boutique http://bit.ly/WPKVht mtp ccfjne mflmmhm cyegoi pghkhil

ppskxcb cyhd hlpsuagn mxm ed

dphwuc pxbcmhf jhbgj u wbds

--========GMXBoundary8703136015620523741

Content-Type: text/html; charset="utf-8"

Content-Transfer-Encoding: quoted-printable

<FONT color=3D#ffecf5 size=3D1 face=3DArial>et a hr kfl dfkd</FONT>

<DIV align=3Dleft><FONT color=3D#ffecf5=20

size=3D1>j</FONT>Make<BR><FONT color=3D#ffecf5=20

size=3D1>ua</FONT>happy<FONT color=3D#ffecf5=20

size=3D1>nhwz</FONT>your<FONT color=3D#ffecf5=20

size=3D1>vk</FONT>woman-<FONT color=3D#ffecf5=20

size=3D1>neekw</FONT>buy<FONT color=3D#ffecf5=20

size=3D1>omk</FONT>viagra/<FONT color=3D#ffecf5=20

size=3D1>wuvi</FONT>cialis<FONT color=3D#ffecf5=20

size=3D1>agr</FONT><A=20

href=3D"http://bit.ly/WPKVht">-go to boutique</A><FONT color=3D#ffecf5=20

size=3D1>m</FONT>

<FONT color=3D#ffecf5 size=3D1 face=3DArial>tp ccfjne mflmmhm cyegoi pghkhi=

l</FONT></DIV>

<DIV align=3Dleft><FONT color=3D#ffecf5 size=3D1 face=3DArial>ppskxcb cyhd =

hlpsuagn mxm ed</FONT></DIV>

<DIV align=3Dleft><FONT color=3D#ffecf5 size=3D1 face=3DArial>dphwuc pxbcmh=

f jhbgj u wbds</FONT></DIV>

--========GMXBoundary8703136015620523741--

[Edited to kill live spam link. Note: you CAN obtain a tracking link, even for an aborted parse (just have to remember to grab it while the parse screen is displayed - or re-do the parse via web form paste-in to access it again).]

[danorton]

[Edited to kill live spam link. Note: you CAN obtain a tracking link, even for an aborted parse (just have to remember to grab it while the parse screen is displayed - or re-do the parse via web form paste-in to access it again).]

What good is the tracking link?

Oh! It's not rejecting the report, it's just posting a useless message?

[turetzsr]

What good is the tracking link?

<snip>

...Please see SpamCop.Net Glossary (a link to which appears in the drop-down list under "FAQ & Words" near the top of each SpamCop Forum page) item labeled "Tracking URL."

[Farelf]

What good is the tracking link?

Oh! It's not rejecting the report, it's just posting a useless message?

Reporting is aborted right enough but the tracking URL** provides all the completed parsing and messages, preserves the original formatting of the headers and messages, keeps things like spam payloads one step removed from public exposure and comprehensively munges innocent e-mail addresses. Not to mention that it takes up far less space on these pages (and avoids having unwrapped lines blowing out the post width), avoids posting spam content smack in the face of people who already see too much of the stuff and it is (for all those reasons) - the requested format for the discussion of spam in these forums and the SC newsgroups (mostly moribund) as thoughtfully provided by SpamCop for such purposes many, many years ago, which request is moderately hard to miss .

I could go on and on, but to cut it short, trust me on this (or read the introductory materials liberally provided) .

**Like (from the head of any parse page):

Here is your TRACKING URL - it may be saved for future reference:

http://www.spamcop.net/sc?id=z5457551753z4...fbf57be98d92e4z