This email contains no date

cwg · November 3, 2013

Envelope-to: [at].com
Delivery-date: Sun, 03 Nov 2013 08:02:15 +0000
Cc: [at].com
Content-Type: text/plain; charset="utf-8"
Date: Sun, 03 Nov 2013 09:02:10 +0100
From: "eHarmony-Dates" &lt;[at]gmx.us&gt;
Message-ID: &lt;[at]gmx.com&gt;
MIME-Version: 1.0
Subject: eHarmony - has sent you an invitation! It expires in 24 hours.
To: [at]carolina.rr.com
Content-Transfer-Encoding: 8bit

body not included

Spamcop parsing engine:

Tracking message source: 91.229.248.108:
Routing details for 91.229.248.108
[refresh/show] Cached whois for 91.229.248.108 : abuse[at]epiohost.net
Using abuse net on abuse[at]epiohost.net
No abuse net record for epiohost.net
Using best contacts abuse[at]epiohost.net
This email contains no date

Not funny.

Farelf · November 4, 2013

...Not funny.

Not funny at all. But interesting.

gmx internal server mailout-eu.gmx.com ([10.1.101.216]) is apparently not correctly configured - or maybe it's the receiving server mrigmx.server.lan (mrigmx001) at fault - anyway continuation lines in that "Received:" header line are, by whichever server, not correctly wrapped (assuming they are exactly "as received") - but, ideally, that shouldn't matter since the parser would decide to ignore an internal hand-off anyway, if that header line was intact.

The "no date" error presumably comes from the "split" "Received:" lines

Received: (qmail 371 invoked by uid 0); 3 Nov 2013 08:02:12 -0000

Received: from 91.229.248.108 by rms-eu007 with HTTP

- with the date and sending server identification in separate headers. That has apparently caused the "no date" error in other cases discussed in these forums recently.

The parsing system (in its totality), apparently running numerous individual parses concurrently on numerous processing servers, can be observed handling more than 40 parses a second at peak. Commentators (well, Mike Easter in the newsgroups, "back in the day") have noted that an individual parse seems to be running several independent analysis streams "simultaneously" (presumably threaded on the same server) and those don't talk to each other but that each can drop out an error message as/sometime after errors occur. Perhaps this strategy and architecture is required to handle the activity bursts encountered but it can lead to some confusing processing messages (not to mention "dumb" or incongruous and out of sequence) from the human point of view.

It seems not a lot has changed over the years in that regard. One might expect the "error: couldn't parse head" stemming from the misconfigured gmx server. That is, after all, a header processed first (working back down the delivery chain) which might at least allow the reporting of the message source - and it is a "Received:" line within or at the boundary of your mailhosting which is integral to integrity of the parse of the verifiable delivery chain. But no (I think), the actual header parsing part of the processing is apparently not bothered by that, that message is, confusingly, always presented AFTER the head has been parsed, when the parser tries to determine where the body begins - the threaded processing thing (perhaps) - though why on earth that could not be made more apparent after all these years of confusing reporters, I have no idea. Perhaps it is an IQ test, predicated on the belief that reporters might be smarter than spammers

Yes, it is frustrating that the parser is so "fragile", obliged to run with "rules" of message construction more strict than any current major/consumer-level e-mail client and that it accordingly discards many/most that don't comply. And we're not allowed to interfere with the evidence (the headers) to "help" the parser in even the most obvious cases. Even when the parser has obviously already identified the source (or relay).

There are reasons for all of that insistence on "form" - but it is tempting to think this particular case perhaps reveals a minor and maybe correctable bug with this "no date" thing maybe only in qmail/webmail transactions with the relay. But I wouldn't be holding my breath. Possibly there's much more to it than that - also misconfigured servers seem to be pretty-much a minority case (especially since mailhosting-driven analysis removes the ability of spammer forgeries to "spoil" a parse) and the owners of such servers generally fix the things sooner or later.

Here are non-mailhosted parses of that data:

original:

http://www.spamcop.net/sc?id=z5621745781z2...507d5456781563z

gmx line wrap "fixed"

http://www.spamcop.net/sc?id=z5621745333za...e1c6b06fbee2f2z

gmx line wrap and qmail split lines "fixed"

http://www.spamcop.net/sc?id=z5621758654ze...044a2589575c3ez

Makes no difference in these - epiohost.net is the responsible abuse handler in each case, as source. As also seen elsewhere, the "no date" error is not encountered in the non-mailhosted parses (but, for good reason, those parses can't be used for "quick" and VER reporting).

goofy173 · November 29, 2013

I had one of these before I posted about on here. spamcop says it has no date, although I find dates in the message.

http://www.spamcop.net/sc?id=z5631075952z6...0b443041aa611bz

Farelf · November 30, 2013

Merged with one of the several existing topics on this subject, doesn't seem much point in proliferating further when, similarly, the problem seems to lie in the "split" 'Received' lines

Received: (qmail 2821 invoked by uid 0); 29 Nov 2013 09:41:58 -0000

Received: from 173.234.57.155 by rms-us006 with HTTP

- when it seems the parser might be "expecting" something like

Received: from 173.234.57.155 by rms-us006 with HTTP (qmail 2821 invoked by uid 0); 29 Nov 2013 09:41:58 -0000

GMX.com Web Mailer again implicated (though could be forged, I'm not smart enough to tell).

goofy173 · December 4, 2013

And another with no date.

http://www.spamcop.net/sc?id=z5632495372z3...29d1dfba656df5z

Is this just Yahoo mail doing this? Usually I can report just fine. This is only the 2nd or 3rd that has ever said no date.

turetzsr · December 4, 2013

...This one seems to have the same problem as your last one 86700[/snapback] -- what should be "Received" information on a single line seems to have been split into two. As this information appears to be from the internet header information that the sending server is providing to gmx (Yahoo?), it seems to be something gmx is doing for reasons of its own.

C2H5OH · December 11, 2013

...This one seems to have the same problem as your last one 86700[/snapback] -- what should be "Received" information on a single line seems to have been split into two. As this information appears to be from the internet header information that the sending server is providing to gmx (Yahoo?), it seems to be something gmx is doing for reasons of its own.

This is the second I've received today with the same problem;

http://www.spamcop.net/sc?id=z5636078712za...be0bf2a67405efz

For both the common element was gmx.

Sign In

This email contains no date

Recommended Posts

cwg

Farelf

goofy173

Farelf

goofy173

turetzsr

C2H5OH

Archived

Browse

Activity