Jump to content

This email contains no date


cwg
 Share

Recommended Posts

Return-path: <[at]gmx.us>
Envelope-to: [at].com
Delivery-date: Sun, 03 Nov 2013 08:02:15 +0000
Received: from mout-xforward.gmx.net ([82.165.159.13]:64519)
	by rs3.abstractdns.com with esmtps (TLSv1:DHE-RSA-AES128-SHA:128)
	(Exim 4.80.1)
	(envelope-from <[at]gmx.us>)
	id 1VcsdT-002AH4-0k
	for [at].com; Sun, 03 Nov 2013 08:02:15 +0000
Received:  from mailout-eu.gmx.com ([10.1.101.216]) by mrigmx.server.lan
 (mrigmx001) with ESMTP (Nemesis) id 0M6yIl-1VpTwP3xnZ-00wlgR for
 <[at].com>; Sun, 03 Nov 2013 09:02:12 +0100
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
Cc: [at].com
Content-Type: text/plain; charset="utf-8"
Date: Sun, 03 Nov 2013 09:02:10 +0100
From: "eHarmony-Dates" <[at]gmx.us>
Message-ID: <[at]gmx.com>
MIME-Version: 1.0
Subject: eHarmony - has sent you an invitation! It expires in 24 hours.
To: [at]carolina.rr.com
X-Flags: 0001
X-Mailer: GMX.com Web Mailer
x-registered: 0
Content-Transfer-Encoding: 8bit
X-GMX-UID: VGYEckYseSEqJ1kn/X4hD5F+IGRvb0B0
X-Antivirus: avast! (VPS 130829-1, 08/29/2013), Inbound message
X-Antivirus-Status: Clean


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.

Link to comment
Share on other sites

...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 :D

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).

Link to comment
Share on other sites

  • 4 weeks later...

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).

Link to comment
Share on other sites

...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.

Link to comment
Share on other sites

...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.

Link to comment
Share on other sites

Join the conversation

You can post now and register later. If you have an account, sign in now to post with your account.

Guest
Reply to this topic...

×   Pasted as rich text.   Paste as plain text instead

  Only 75 emoji are allowed.

×   Your link has been automatically embedded.   Display as a link instead

×   Your previous content has been restored.   Clear editor

×   You cannot paste images directly. Upload or insert images from URL.

 Share

×
×
  • Create New...