Mail "received" hour not correct
Hi there,
I have recently configured an IP camera to send notification mails to my mail account which I read Under Thunderbird. Issue is that the displayed received date is serveral hours behind the normal date. For example I generate a mail now at 8:27, and the displayed date of the received mail Thunderbird indicates 2:27.
On the mail server, the date is correctly displayed with 8:27
My mail boxes (Thunderbird as well as 2 android devices) are configured in IMAP, and I had read this could be the issue (?) but I only have this issue with this camera and not with any other mail I am receiving.
Any idea what that could be or how to investigate the issue ? Many Thanks !
الحل المُختار
So bottom line the issue is that the camera, if I understand correctly, is not applying the correct timezone and even though the timezone is set to GMT +5:00, the camera is sending the mail with a GMT +8:00 ...
I did a test again from : a NAS set to GMT +5:00 and clock set to 21:30:32 the camera set to GMT +5:00 and clock set to 21:30:32
... so both defined with the same timezone and clock, and send a mail test using Skynet SMTP.
The NAS mail source code shows :
Return-Path: <Synology-DS211@skynet.be>
Received: from mailrelay103.isp.belgacom.be ([195.xxx.20.xxx])
by mailfep012.skynet.be (InterMail vM.8.04.03.21.1 201-2389-100-165-100-20151028) with ESMTP id <20161009163019.RXWO7155.mailfep012.skynet.be@mailrelay103.isp.belgacom.be> for <xxx@skynet.be>; Sun, 9 Oct 2016 18:30:19 +0200
[...] Received: from 111.141-179-91.adsl-dyn.isp.belgacom.be (HELO DiskStation) ([91.xxx.141.xxx])
by relay.skynet.be with SMTP; 09 Oct 2016 18:30:19 +0200
Date: Sun, 09 Oct 2016 21:30:19 +0500 From: "Synology-DS211@skynet.be" <Synology-DS211@skynet.be> To: <xxx@skynet.be> Subject: =?UTF-8?B?TkFTIC0gIFRlc3QgTWVzc2FnZSBmcm9tIERpc2tTdGF0aW9u?= [...]
The Camera mail source code shows :
Return-Path: <Dahua@ced.be>
Received: from mailsec104.isp.belgacom.be ([195.xxx.20.xxx])
by mailfep012.skynet.be (InterMail vM.8.04.03.21.1 201-2389-100-165-100-20151028) with ESMTP id <20161009163017.RXDN7155.mailfep012.skynet.be@mailsec104.isp.belgacom.be> for <xxx@skynet.be>; Sun, 9 Oct 2016 18:30:17 +0200
[...] Received: from 111.141-179-91.adsl-dyn.isp.belgacom.be (HELO localhost_GNT) ([91.xxx.141.xxx])
by relay.proximus.be with ESMTP/TLS/DHE-RSA-AES256-GCM-SHA384; 09 Oct 2016 18:30:17 +0200
Date: Sun, 09 Oct 16 21:30:17 +0800 From: <Dahua@ced.be> To: <xxx@skynet.be> Subject: =?UTF-8?B?TWFpbF9UZXN0?= [...]
So I understand correctly the issue is that the camera, although set to a GMT+5:00 timezone, use a GMT+8:00 ...
... Thunderbird displays a received time of 18:30 for the mail sent my the NAS and 15:30 for the mail sent by the camera.
Therefore the Camera is not using the defined GMT for the mails she is sending. I will report this as a bug to Dahua.
Read this answer in context 👍 0All Replies (16)
Here is the source of the mail I have just received, please notice the correct date and Time like "Thu, 6 Oct 2016 13:32:57 +0200" .... but Thunderbird is displaying in my inbox "7:33" today ... so a difference of 6 hours ?!?
Return-Path: <xxx> Received: from xxx
by xxx (InterMail vM.8.04.03.21.1 201-2389-100-165-100-20151028) with ESMTP id <xxx> for <xxx>; Thu, 6 Oct 2016 13:32:57 +0200
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
d=xxx; i=@xxx; q=dns/txt; s=securemail; t=xxx; x=xxx; h=date:from:to:subject:mime-version:message-id; bh=vCO7TU+ri7neUoGhKcpgYUoKTivdt4OTwYh5rS0gcNY=; b=V3R9BaAS+DoyrmB66nUjXGO4ewgw+MGmLDLeYgu2n/WUiMIp/orfUZ7r unLyRJyvae3W9IVrpdDYX/utQyAYhw==;
Message-Id: <xxx> X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: =?us-ascii?q?A2DJRwDwNPZX/2+Ns1tdHAEBFgEBBQEBB?=
=?us-ascii?q?jqCNR8cAQEBAQEeSWsQpxIBjRGESIILhhoEAh0BgWA7EgECAQEBAQEBAV4nQRK?= =?us-ascii?q?EOBoZO0UCBDcTEYhloWmPbIUXl3k1gjgPgkwFjjp3ik6RUwGOG0mMLoN/JQgnh?= =?us-ascii?q?TIxggeGbQECAw?=
Received: from xxx
by xxx; 06 Oct 2016 13:32:56 +0200
Date: Thu, 06 Oct 16 13:33:02 +0800 From: <xxx> To: <xxx> Subject: =?UTF-8?B?TWFpbF9UZXN0?= MIME-Version: 1.0 Content-type: multipart/mixed;boundary="======DAHUA_TECH======"
This is a multi-part message in MIME format.
--======DAHUA_TECH====== Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: base64
xxx
--======DAHUA_TECH======--
by xxx; 06 Oct 2016 13:32:56 +0200
Date: Thu, 06 Oct 16 13:33:02 +0800
Two different timezones, exactly 6 hours apart.
Your mission is to decide which is wrong and what to do about it.
My camera is defined with GMT +2, hour synced with my computer. Computer is on UTC+1 (Bruxelles)
... so according me the timezone is not different ?!? Why is the time correctly displayed by my Webmail and not by Thunderbird ??
I have no interest in what your web mail does or does not display.
Your camera is defined with GMT (I don't think so) +6. UTC has been used for years now, but effectively GMT and UTC are the same thing,
You camera attached the date header as +6 hours. That would be correct if it was in China. You say your computer is on +1 Which would be correct if you are in Europe.
So according to the Folk on this forum. The timezone is different.
Fully agree, I just want to point out the difference between the web mail and Thunderbird in order to understand how thunderbirds works.
What is Thunderbird taking to display the received date / hour ? He is doing any translation ?
I mean I worked with another SMTP provider (GMAIL) and here the received hour is correctly displayed (NO 6 hours difference).
As soon as I change the SMPT provider to proximus (my official internet provider), then the displayed hour is 6 hours ahead ...
can the SMTP parameters / configuration of one provider or another provider define the behavior of the received mail hour display ?
Thunderbird is showing you the time and date put into the message header by the sender; in this case this is your IP camera. The other times we see in the header are put there by servers and are probably somewhat more trustworthy.
Other email clients may insert the time it arrived, as judged by the host's clock, or may take the last time inserted by a server. I think you can add a "recieved" column to Thunderbird's message list view which would show you the time it arrived.
IP cameras in my experience have rather buggy software that doesn't always manage to achieve what the specifications claim it can do.
As you can see in the screenshot on the second post I have put the "Date" as well as the "received" columns but bith show the 6 hours difference so th is definitely not the time the mail arrived on thunderbird. I still suspect the camera is sending the message with GMT +8:00 ...
Can you identify from the mail source code what timestamp is set by the camera ?
See here :
Mail sent by the camera using proximus SMTP, the camera bring set to GMT +2:00 Mails always arrive with 6 hours difference as reception date / Time
Return-Path: <Dahua@skynet.be> Received: from mailsec116.isp.belgacom.be ([xxx.238.20.112])
by mailfep004.skynet.be (InterMail vM.8.04.03.21.1 201-2389-xxx-165-100-20151028) with ESMTP id <20161008123411.SXBI6749.mailfep004.skynet.be@mailsec116.isp.belgacom.be> for <xxx@skynet.be>; Sat, 8 Oct 2016 14:34:11 +0200
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
d=skynet.be; i=@skynet.be; q=dns/txt; s=securemail; t=1475930051; x=1507466051; h=date:from:to:subject:mime-version:message-id; bh=3Hi3mZcSaKSsIiOidFjmlI+dkf0F7iHHrQjrIiPrXAc=; b=t5qmrC9yP5d/utOVkxDTIjGFyKVKu6UwZXz4A2QTLNUPUTxNfWKDC6ae aoc9orc/v8Sy+bEKIhaI4dZp2Gxh0g==;
Message-Id: <f88ce9$36g8l1@relay.proximus.be> X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: =?us-ascii?q?A2DHOQCi5vhX/2+Ns1taHQEXAQYBQII1H?=
=?us-ascii?q?xsBAQEBAR1JaxCnGAGNFIRIgguGGgQCGwGBXzsSAQIBAQEBAQEBXidBAQQNhDg?= =?us-ascii?q?aGTtFAgQ3ExGIZ6J7j2ydFTWCOA+CTAWOOneKTpFVAY4bSYwug38lAS6FMjGBd?= =?us-ascii?q?jaGBAECAw?=
Received: from 111.xxx-179-91.adsl-dyn.isp.belgacom.be (HELO localhost_GNT) ([91.xxx.141.xxx])
by relay.proximus.be with ESMTP/TLS/DHE-RSA-AES256-GCM-SHA384; 08 Oct 2016 14:34:11 +0200
Date: Sat, 08 Oct 16 14:34:11 +0800 From: <Dahua@skynet.be> To: <xxx@skynet.be> Subject: =?UTF-8?B?TWFpbF9UZXN0?= MIME-Version: 1.0 Content-type: multipart/mixed;boundary="======DAHUA_TECH======"
This is a multi-part message in MIME format.
--======DAHUA_TECH====== Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: base64
QWxhcm0gRXZlbnQ6IE1haWxfVGVzdA0KQWxhcm0gSW5wdXQgQ2hhbm5lbDogMQ0KQWxhcm0gU3Rh cnQgVGltZShEL00vWSBIOk06Uyk6IDA4LzEwLzIwMTYgMTQ6MzQ6MTANCkFsYXJtIERldmljZSBO YW1lOiBJUEMtRUJXODEyMDANCkFsYXJtIE5hbWU6IA0KSVAgQWRkcmVzczogMTkyLjE2OC4xLjUN Cg==
--======DAHUA_TECH======--
Mail sent by the NAS using proximus SMTP, the NAS being defined on GMT+5:00
Mails always arrive with correct timestamp.
Return-Path: <Synology-DS211@skynet.be> Received: from mailrelay116.isp.belgacom.be ([xx.238.xx.143])
by mailfep003.skynet.be (InterMail vM.8.04.03.21.1 201-2389-100-165-100-20151028) with ESMTP id <20161008123115.WEFD8090.mailfep003.skynet.be@mailrelay116.isp.belgacom.be> for <xx@skynet.be>; Sat, 8 Oct 2016 14:31:15 +0200
Message-Id: <f88ce9$36g8ct@relay.skynet.be> X-Belgacom-Dynamic: yes X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: =?us-ascii?q?A2BGEACi5vhX/2+Ns1taHAEBBAEBCgEBg?=
=?us-ascii?q?zwBAQEBAR1JDl0QD40zmU4IAYMugWeDXnQMIQOCfYEsNYJnggsihEpVWQSBfTk?= =?us-ascii?q?UAQIBAQEBAQEBXidBEIQ6DwEZCh0eFgcCJgInFBMRiF4JonuPbIVRiFuEOnyIb?= =?us-ascii?q?hEBBmKCOA+CTAWBIQGOD4pECAEBAYYmhQiDb4I3ARVOhBmJHQKJC4drHjaCZAE?= =?us-ascii?q?BAQcBAQEBAQE9gXs3NYFhg3qCIAECAw?=
Received: from 111.141-179-91.adsl-dyn.isp.belgacom.be (HELO DiskStation) ([91.xx.141.xx])
by relay.skynet.be with SMTP; 08 Oct 2016 14:31:15 +0200
Date: Sat, 08 Oct 2016 17:31:15 +0500 From: "Synology-DS211@skynet.be" <Synology-DS211@skynet.be> To: <xx@skynet.be> Subject: =?UTF-8?B?TkFTIC0gIFRlc3QgTWVzc2FnZSBmcm9tIERpc2tTdGF0aW9u?= Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: 8bit
Dear User,
Congratulations! You have successfully set up the email notification on DiskStation. For further system configurations, please visit http://192.168.1.2:5000/, http://xx.be:5000/. (If you cannot connect to the server, please contact the administrator.)
Sincerely, Synology DiskStation
... Looking at those 2 mails code, why is the first one displayed with 6 hours difference as reception date / time, and the second one, although coming from a NAS set to GMT +5:00 (different timezone), displayed with correct reception date / time ? I do not understabd Thunderbird's behavior.
Pretty simple.
If the camera has the correct time set, but the wrong timezone than it is setting garbage as the date/Time of the email.
We see exactly the same thing when people do not change the default timezone on their windows computer when they set it up. It defaults to US pacific timezone (Microsoft is a 1 Microsoft Way Redmond WA) even if you set it up on Australia.
So the user then sets the time correctly because it is just not right what displayed on the screen. When email or any other product that uses UTC time sets time stamps garbage results as an incorrect timezone converts to garbage when the correct local time is also used. They come to this forum complaining Thunderbird gets all their mail XXX hours off and how do they correct it.
Matt, for me it is still not clear where the problem is coming from ... The camera shows it is set with the correct time and timezone.
1. If I send a mail from the camera using the GMAIL SMTP, Thunderbird is showing the correct reception time 2. If If I send a mail from the camera using the PROXIMUS SMTP, Thunderbird is showing the INcorrect reception time. (but all other mails I receive are with the correct reception time 3. If I send a mail from a NAS being set on GMT+5:00, for example, the mai in Thunderbird is received with the correct reception time (the time Thunderbird received the mail).
The question is, to start ... if a system located on GMT+10:00 is sending mail to me located on GMR+2:00, at 15:31 ... what should Thunderbird show as reception time ? 15:31 or 7:31 (8 hours difference) ?
It will show you the time as the date header field set by the sender. IT is one of those Quirks Thunderbird has,
Thank you matt ... let us proceed by step then.
1. This header is set by the sender I suppose (the camera) or more logically by the SMTP configuration correct (The one from GMAIl could be different from the one from Proximus) correct ?
2. In the 2 logs I have posted 4 posts above, can you please indicate to me what is the "date header field" please, so that I can identify it in the whole bunch of data ? is it
Date: Sat, 08 Oct 16 14:34:11 +0800 and Date: Sat, 08 Oct 2016 17:31:15 +0500
?
Yes and yes.
Note that the Synology message shows a different time of day, and when the timezone offset is taken into account, it agrees with the time put in by the skynet server (and, as it happens, with all the other servers that have their own timestamps).
Your camera gives the same time of day as the skynet server, but with an incorrect timezone offset. Do the arithmetic and of course the time when corrected for your location will be wrong. Your camera, as pointed out earlier, is behaving as if it was located in China. Your camera may be syncing its clock to your pc's clock but it is falling to acquire the local timezone.
Is the camera capable of accessing an ntp server by itself rather than this botch it makes via your pc? Do you need to explicitly tell the camera where it is located, or which timezone it should be using?
Modified
Note...
Synology: 08 Oct 2016 14:31:15 +0200 Date: Sat, 08 Oct 2016 17:31:15 +0500
14:31 - 2 = 12:31 17:31 - 5 = 12:31. Good. These two timestamps convert to the same UTC value.
Camera: 08 Oct 2016 14:34:11 +0200 Date: Sat, 08 Oct 16 14:34:11 +0800
14:34 - 2 = 12:34 14:34 - 8 = 06:34. Bad. These two timestamps mean two different UTC values.
Your camera needs to say
14:34 ... +0200, or 17:34 ... +0500, or 20:34 ... +0800
or some permutation thereof.
Modified
BTW, i suspect that the calculation behind Thunderbird's "recieved" column is busted, or does something counterintuitive. ISTR I tried it and found that sorting doesn't work.
الحل المُختار
So bottom line the issue is that the camera, if I understand correctly, is not applying the correct timezone and even though the timezone is set to GMT +5:00, the camera is sending the mail with a GMT +8:00 ...
I did a test again from : a NAS set to GMT +5:00 and clock set to 21:30:32 the camera set to GMT +5:00 and clock set to 21:30:32
... so both defined with the same timezone and clock, and send a mail test using Skynet SMTP.
The NAS mail source code shows :
Return-Path: <Synology-DS211@skynet.be>
Received: from mailrelay103.isp.belgacom.be ([195.xxx.20.xxx])
by mailfep012.skynet.be (InterMail vM.8.04.03.21.1 201-2389-100-165-100-20151028) with ESMTP id <20161009163019.RXWO7155.mailfep012.skynet.be@mailrelay103.isp.belgacom.be> for <xxx@skynet.be>; Sun, 9 Oct 2016 18:30:19 +0200
[...] Received: from 111.141-179-91.adsl-dyn.isp.belgacom.be (HELO DiskStation) ([91.xxx.141.xxx])
by relay.skynet.be with SMTP; 09 Oct 2016 18:30:19 +0200
Date: Sun, 09 Oct 2016 21:30:19 +0500 From: "Synology-DS211@skynet.be" <Synology-DS211@skynet.be> To: <xxx@skynet.be> Subject: =?UTF-8?B?TkFTIC0gIFRlc3QgTWVzc2FnZSBmcm9tIERpc2tTdGF0aW9u?= [...]
The Camera mail source code shows :
Return-Path: <Dahua@ced.be>
Received: from mailsec104.isp.belgacom.be ([195.xxx.20.xxx])
by mailfep012.skynet.be (InterMail vM.8.04.03.21.1 201-2389-100-165-100-20151028) with ESMTP id <20161009163017.RXDN7155.mailfep012.skynet.be@mailsec104.isp.belgacom.be> for <xxx@skynet.be>; Sun, 9 Oct 2016 18:30:17 +0200
[...] Received: from 111.141-179-91.adsl-dyn.isp.belgacom.be (HELO localhost_GNT) ([91.xxx.141.xxx])
by relay.proximus.be with ESMTP/TLS/DHE-RSA-AES256-GCM-SHA384; 09 Oct 2016 18:30:17 +0200
Date: Sun, 09 Oct 16 21:30:17 +0800 From: <Dahua@ced.be> To: <xxx@skynet.be> Subject: =?UTF-8?B?TWFpbF9UZXN0?= [...]
So I understand correctly the issue is that the camera, although set to a GMT+5:00 timezone, use a GMT+8:00 ...
... Thunderbird displays a received time of 18:30 for the mail sent my the NAS and 15:30 for the mail sent by the camera.
Therefore the Camera is not using the defined GMT for the mails she is sending. I will report this as a bug to Dahua.
Modified