Jump to content

"This email contains no date"... parser bug?


Recommended Posts


The header timestamps look normal to me. Parser bug?

Looks to my untutored eye like the problem that has drawn criticism ever since mailhosting started - no time-datestamp on the critical "Received:" line - Received: from by rms-eu006 with HTTP which counts as a malformed line accordingly. The parser ignores the relevant date stamp on the next line (going up), because it is too simple to link the two. There used to be much discussion about similar cases (particularly in the Newsgroups) but apparently nothing has been done to fix things in all these years. I suppose that means it doesn't happen much (but yours is not the only recent query about it - notwithstanding the reduced number of reports these days).

Certainly no need for the parser to be so finicky in this case. The date stamps are all consistent:


- but evidently consistency isn't examined by the parser algorithm.

A non-mailhosted parse has no argument with those headers:


- it takes a datestamp from later in the delivery chain (which is presumably less desirable in the bigger picture).

Vexing. We need more reports, not less!!

Link to comment
Share on other sites

  • 2 weeks later...
...While I claim no great expertise in interpreting parses, doesn't the following suggest that one of your e-mail provider's servers is not inserting correct "Received" lines?
Parsing header:

0: Received: from mout.gmx.net (mout.gmx.net []) by rax1.acsmail.com (Postfix) with ESMTP id 65FF216504CA for <x>; Thu, 14 Mar 2013 14:11:55 -0400 (EDT)

Hostname verified: mout.gmx.net

acsmail received mail from 1&1 ( )

1: Received: from mailout-eu.gmx.com ([]) by mrigmx.server.lan (mrigmx002) with ESMTP (Nemesis) id 0LeP1H-1V6LI71jnp-00q75P for <x>; Thu, 14 Mar 2013 19:11:54 +0100

Internal handoff at 1&1

2: Received: from by rms-eu005 with HTTP

Hostname verified:

1&1 received mail from sending system

...Hopefully someone more knowledgeable than I will drop by and offer some more specific advice, such as that my post here adds nothing to the goal of explaining what happened here. :) <g>
Link to comment
Share on other sites

Servers "rms-eu006", now "rms-eu005" and "rms-eu002" (last in a query from the newsgroups) are using split headers with the date on a separate "Received" line. Googling shows "rms-eu001" does the same and, no doubt, everything in between. Used to be a relatively rare misconfiguration issue, looking that way no longer. Just who owns those I have no idea (sources are coming in from various networks), but reporters' own networks (all include gmx.com, I now realise) are effectively accepting mail from them. So I guess gmx.com/gmx.net/1&1 Internet AG?

Link to comment
Share on other sites

Same error with these headers

From - Sat Mar 16 19:33:05 2013
X-Account-Key: account5
X-UIDL: 0000308c498dc3fe
X-Mozilla-Status: 0001
X-Mozilla-Status2: 00000000
Return-Path: &lt;ganswindt-etikett[at]t-online.de&gt;
X-Original-To: x[at]y
Delivered-To:  x[at]y
Received: from avasout05.plus.net (avasout05.plus.net [])
	by tty.org.uk (Postfix) with ESMTP id 3CC93A4A05C
	for &lt; x[at]y&gt;; Sat, 16 Mar 2013 19:29:39 +0000 (GMT)
Received: from mail.just-the-name.co.uk ([])
	by avasout05 with smtp
	id CKVe1l0023UurnZ01KVfXB; Sat, 16 Mar 2013 19:29:39 +0000
X-CM-Score: 0.00
X-CNFS-Analysis: v=2.0 cv=dpoF/Sc4 c=1 sm=1 a=PUDuvyRKLtwbrNFgjAcZ3A==:17
 a=V-zUeSKy1cgA:10 a=BSdCXb3PsnMA:10 a=wPDyFdB5xvgA:10 a=JQDKme5JAAAA:8
 a=ddzrcIyeOpVgtScUs9oA:9 a=QEXdDO2ut3YA:10 a=ZXnRUJqJAM72iZD4:21
 a=Z_mDU5pvhsaMALCt:21 a=Rxsao-tDsPTLu8wqkekA:9 a=_W_S_7VecoQA:10
Received: from mailout07.t-online.de (mailout07.t-online.de [])
	by mail.just-the-name.co.uk (Postfix) with ESMTP id D356C1F0323
	for &lt; x[at]y&gt;; Sat, 16 Mar 2013 19:29:37 +0000 (GMT)
Received: from fwd04.aul.t-online.de (fwd04.aul.t-online.de )
	by mailout07.t-online.de with smtp 
	id 1UGwkR-00064j-Rh; Sat, 16 Mar 2013 20:26:32 +0100
Received: from localhost (TD7ROgZGZhf3KpnEHMHevuYjzwNfSYMobGvXAnG18ItW77psoC66O7MtI+W1SlOwjq[at][]) by fwd04.aul.t-online.de
	with esmtp id 1UGwkN-24ioRE0; Sat, 16 Mar 2013 20:26:27 +0100
MIME-Version: 1.0
Received: from by cmpweb57.aul.t-online.de with HTTP/1.1
 (NGCS V4-0-14-3 on API V3-11-23-0)
Date: Sat, 16 Mar 2013 20:26:27 +0100
Reply-To: yynthvgrhyt5b[at]thnmhtbrgbth.com
To: novodogs[at]fastmail.fm
X-Priority: 3
X-UMS: email
X-Mailer: DTAG NGCS V4-0-14-3
Subject: Hello,
From: "kujhgfdsdfghjykuluyhgf" &lt;Ganswindt-Etikett[at]t-online.de&gt;
Content-Type: multipart/alternative;
Message-ID: &lt;1UGwkN-24ioRE0[at]fwd04.aul.t-online.de&gt;
X-ID: TD7ROgZGZhf3KpnEHMHevuYjzwNfSYMobGvXAnG18ItW77psoC66O7MtI+W1SlOwjq[at]t-dialin.net
X-TOI-MSGID: 6d0247c9-30e7-4d1a-a5cd-c7ead9f104e2

Content-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: 7bit

Link to comment
Share on other sites

Yes, Don's "non-mailhosted" parse picks up the date elsewhere, as we have been discussing. In fact it picks it up from the final (top-most) delivery - the top "Received:" line. That is demonstrated by running it again (also non-mailhosted) with that date-stamp thoroughly "doctored" - by 4 days - to make it unambiguous:


The datestamp problems complained of in this one involve t-online.de which may or may not actually be part of SteveAtty's mailhosted network. The header line responsible: -

Received: from by cmpweb57.aul.t-online.de with HTTP/1.1 (NGCS V4-0-14-3 on API V3-11-23-0)

- but there is no datestamp on that (first = bottom) "Received:" line (contrary to RFCs) when the parser demands that one should be there, wanting to treat it as the first, unforgeable, datestamp within the trusted network.

The other cases discussed here and elsewhere involve gmx.com with rms-eu006 (and other servers) treated as part of the reporters' hosting but, again, there is no datestamp on those (first = bottom) "Received:" lines and the reporter disavows gmx.com as part of his hosting in at least one of those (could be all of them, haven't re-read it all).

Link to comment
Share on other sites

  • 2 weeks later...

Yes, Don's "non-mailhosted" parse picks up the date elsewhere, as we have been discussing.

On a related note:


This one looks like it has been sitting in the outgoing mail queue at [] for 11 years (!) until yesterday but is in fact part of a recent spam run (identical subject, link, and "zoo movies 2012" in the body).

Link to comment
Share on other sites

  • 2 weeks later...
  • 2 weeks later...
Non-mailhosted version doesn't trip up on those non-RFC split "Received:" lines which should contain
3.6.7. Trace fields ...

received = "Received:" name-val-list ";" date-time CRLF ...

but are instead (well, I changed all dates 29->30 Apr to get a current parse):

Received: (qmail 9580 invoked by uid 0); 30 Apr 2013 13:58:14 -0000

Received: from by rms-eu002 with HTTP

- because it looks elsewhere for the definitive date.

- http://www.spamcop.net/sc?id=z5498360226z2...c261a8b469f77fz

Misconfigured server. SC can't do anything about it. Annoying, but I suppose it's a "minority" case and likely to be fixed by the owner sometime. I imagine that asking the owner to fix it is best done by a peer affected by it, of which there are none, or (next) by users of the networks who are affected - which are you guys which is galling because it's not really YOUR problem. Or there are network ops forums where an appropriate comment or two could be dropped to spread its way through the general IT community.

Also the spammer community.

Link to comment
Share on other sites

  • 5 months later...
  • 2 weeks later...


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

  • Create New...