2018-06-04



Outlook 2016 shows the date of the Date  header  (22:15)  in  the
message  view,  but  it shows the date of receival (22:32) in the
messages list view.

     Received: from foo (unknown [x.x.x.x])
             by mx.foo (Postfix) with ESMTP id D95F046CD1
             for <bob@blub>; Thu, 31 May 2018 22:32:16 +0200 (CEST)
     Received: from mx.foo (mx.foo [y.y.y.y])
             by mx.quux with ESMTPS id w4VKWG6D019589
             (version=TLSv1.2 cipher=ECDHE-RSA-AES256-GCM-SHA384 bits=256 verify=NOT)
             for <bob@blub>; Thu, 31 May 2018 22:32:17 +0200 (MEST)
             env-from (alice@foo)
     Received: by foo (Postfix, from userid 1000)
             id 7975061F317E; Thu, 31 May 2018 22:32:16 +0200 (CEST)
     Received: by foo (Postfix)
             id A215F61F317F; Thu, 31 May 2018 22:32:16 +0200 (CEST)
     Received: from mx.quux ([z.z.z.z] verified)
       by mbox.quux (CommuniGate Pro SMTP 6.1.19)
       with ESMTP id 73229531 for bob@blub; Thu, 31 May 2018 22:32:19 +0200
     From: "\(Cron Daemon\)" <alice@foo>
     To: <alice@foo>
     Subject: Cron <alice@foo> /home/alice/bin/update-all
     Date: Thu, 31 May 2018 22:15:03 +0200
     Message-ID: <20180531203216.7975061F317E@foo>
     MIME-Version: 1.0
     Content-Type: text/plain;
             charset="UTF-8"
     Content-Transfer-Encoding: quoted-printable
     X-Mailer: Microsoft Outlook 16.0
     Thread-Index: AQDRU/bZL+ntpYY1WYBS4xswrZ/NFw==


Besides this, some of the MTAs  didn't  preprend  their  Received
headers, as required by RFC 2821 and its successor RFC 5321:

     SMTP servers MUST prepend Received lines  to  messages;
     they MUST NOT change the order of existing lines or in-
     sert Received lines in any other location.  [0] [1]

Already RFC 821, dated 1982 (!), had it this way, although not as
explicitely:

     When the receiver-SMTP accepts a message either for re-
     laying  or  for final delivery it inserts at the begin-
     ning of the mail data a time stamp line.  [2]

It's no fun, reading  transport  information  when  the  Received
headers  are  shuffled.  But who reads transport information any-
ways?!


[0]  https://tools.ietf.org/html/rfc2821#section-4.4
[1]  https://tools.ietf.org/html/rfc5321#section-4.4
[2]  https://tools.ietf.org/html/rfc821


http://marmaro.de/lue/        markus schnalke <meillo@marmaro.de>