emailemail-clientrfc822

Why do RECEIVED email headers seem to be out of order chronologically?


When reviewing the headers, it appears that the 2nd server to receive the message didn't relay it until AFTER the reported delivery date in the final header.

At c9mailgw11.amadis.com, the reported time was 22:47:49 -0800 (PST). However, the final server, BY2PR0401MB0966.namprd04.prod.outlook.com, reports the time as 06:46:08 +0000.

Is the discrepancy due to something simple, like a bad clock on the amadis relay?

I've written a script that detects email delays, and when I hit an oddity like that I get a negative value from that hop to the next and I want to understand why they are ordered this way to see if I have way to lookahead.

Can anyone offer insight?

**Received: from BY2PR0401MB0966.namprd04.prod.outlook.com (10.160.64.15) by
 CY1PR0401MB0971.namprd04.prod.outlook.com (10.160.160.17) with Microsoft SMTP
 Server (TLS) id 15.1.403.16 via Mailbox Transport; Wed, 17 Feb 2016 06:46:08**
 +0000
Received: from BN3PR0401CA0023.namprd04.prod.outlook.com (10.162.159.161) by
 BY2PR0401MB0966.namprd04.prod.outlook.com (10.160.64.15) with Microsoft SMTP
 Server (TLS) id 15.1.409.15; Wed, 17 Feb 2016 06:46:07 +0000
Received: from BN3NAM01FT022.eop-nam01.prod.protection.outlook.com
 (2a01:111:f400:7e41::207) by BN3PR0401CA0023.outlook.office365.com
 (2a01:111:e400:51d1::33) with Microsoft SMTP Server (TLS) id 15.1.409.15 via
 Frontend Transport; Wed, 17 Feb 2016 06:46:07 +0000
Received: from BAY004-MC1F22.hotmail.com (10.152.66.51) by
 BN3NAM01FT022.mail.protection.outlook.com (10.152.67.153) with Microsoft SMTP
 Server (TLS) id 15.1.409.7 via Frontend Transport; Wed, 17 Feb 2016 06:46:06
 +0000
Received: from mail2world.com ([209.67.128.125]) by BAY004-MC1F22.hotmail.com with Microsoft SMTPSVC(7.5.7601.23143);
     Tue, 16 Feb 2016 22:46:06 -0800
Received: from mail pickup service by mail2world.com with Microsoft SMTPSVC;
     Tue, 16 Feb 2016 22:46:04 -0800
ResentFrom: xxx@xxx.com
Return-Path: xxx@xxx.com
Received: from 216.163.188.203 unverified ([216.163.188.203]) by mwpop05oc.mail2world.com with Mail2World SMTP Server; 
    Tue, 16 Feb 2016 22:46:01 -0800
**Received: from sender153-mail.zoho.com (unknown [74.201.84.153])
    by c9mailgw11.amadis.com (Postfix) with ESMTP id A432C5B996A81
    for <xxx@xxx.com>; Tue, 16 Feb 2016 22:47:49 -0800 (PST)**
DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; 
  s=zapps768; d=zoho.com; 
  h=content-type:mime-version:subject:to:from:date; 
  b=b6BP/HJmeP+ORBz043y8K0tUFE3u3c8tUZvDSHjfuH0zD84gax1wUlRdYGps/SBd7SnFHYT1Plps
    wRQOJoRp6hEMPerW6MSOL9psGWfNel4lnZwdtr7ujnuh54CTTEwV  
Received: from [192.168.10.1] (xxx.xxx.net [xx.xx.xx.xx]) by mx.zohomail.com
    with SMTPS id 1455691501828999.0688176107503; Tue, 16 Feb 2016 22:45:01 -0800 (PST)

Solution

  • The answer to this question is documented in rfc5321, section 4.4 as follows:

    When an SMTP server receives a message for delivery or further
    processing, it MUST insert trace ("time stamp" or "Received")
    information at the beginning of the message content
    , as discussed in
    Section 4.1.1.4.

    This line MUST be structured as follows:

    o The FROM clause, which MUST be supplied in an SMTP environment, SHOULD contain both (1) the name of the source host as presented in the EHLO command and (2) an address literal containing the IP address of the source, determined from the TCP connection.

    o The ID clause MAY contain an "@" as suggested in RFC 822, but this is not required.

    o If the FOR clause appears, it MUST contain exactly one entry, even when multiple RCPT commands have been given. Multiple s raise some security issues and have been deprecated, see Section 7.2.

    An Internet mail program MUST NOT change or delete a Received: line that was previously added to the message header section. SMTP
    servers MUST prepend Received lines to messages; they MUST NOT change the order of existing lines or insert Received lines in any other
    location.