_INetSmtpMail Sent Time Info

[jgira]

Below is the header to the exact email I posted a screen shot of... I removed the reference to the SMTP server ({VALID SMTP SERVER}) and the email address I am sending from ({VALID EMAIL ADDRESS}).

Received: from IS-L08-067 (10.1.8.143) by {VALID SMTP SERVER} (10.4.20.101) with

Microsoft SMTP Server id 8.1.291.1; Wed, 3 Dec 2008 17:49:49 -0600

From: LANDesk - Workstation Imaged <{VALID EMAIL ADDRESS}>

To: <jgira@wje.com>

Subject: Computer ReImaged - IS-L08-067

MIME-Version: 1.0

Date: Wed, 3 Dec 2008 17:49:49 +0000

Content-Type: text/plain; charset="US-ASCII"

Message-ID: <0351e6a0-a350-444b-b103-527cd5e9b0c0@wjenbcas2.wje.com>

Return-Path: {VALID EMAIL ADDRESS}

[jgira]

Sorry to press the point, but that's only answers half the question. What about the time zone on the mail server? It only gets handled correctly if the zones are set correctly on BOTH the clients and the servers.

No problem. That was the first thing I looked at. I agree with all of the posts regarding time zones. This issue does appear to be a time zone problem but when I wrote a script to send a basic email from my PC to myself, I had the same issue. Thanks for the post though!

[trancexx]

Actually, this is. It might not be from the very email I posted earlier, but it is from a similiar email with the same problem. So, to answer your question, yes I am having a problem.

If that's true then you deserve to be banned because that what you do is to be condemned.

If that is the header of mail sent by _INetSmtpMail() then the bias would be enclosed in parentheses.

Part of the function that deals with that is:

$bias =  StringFormat(" (%+.2d%.2d)", $biasH, $biasM)

You posted this:

Date: Wed, 3 Dec 2008 17:49:49 +0000

So, you clearly changed original header before posting it here.

If you removed the parentheses it is kind of inicating what else you might have done.

Sorry, but that's not ok thing to do.

[jgira]

If that's true then you deserve to be banned because that what you do is to be condemned.

If that is the header of mail sent by _INetSmtpMail() then the bias would be enclosed in parentheses.

Part of the function that deals with that is:

$bias =  StringFormat(" (%+.2d%.2d)", $biasH, $biasM)

You posted this:

So, you clearly changed original header before posting it here.

If you removed the parentheses it is kind of inicating what else you might have done.

Sorry, but that's not ok thing to do.

Ok, let's calm down... I didn't intentionally try and do anything except look for help on the forums. All I did was what you asked of me yesterday.

Right click on message in inbox list and choose "Message Options..." or whatever. Window that pop-up will have true header. Post that.

Attached is a compressed video of what I did to get you the header. I did edit the server and email address information but I stated that in every post. You seem to want to accuse me of something I am not doing...

EmailHeader.wmv

[jgira]

And to reiterate the header, here it is again. And once again, I removed the SMTP address and from address and replaced it with {VALID X ADDRESS}.

Received: from IS-L08-067 (10.1.8.143) by {VALID SMTP SERVER ADDRESS} (10.4.20.101) with

Microsoft SMTP Server id 8.1.291.1; Wed, 3 Dec 2008 17:49:49 -0600

From: LANDesk - Workstation Imaged <{VALID FROM ADDRESS}>

To: <jgira@wje.com>

Subject: Computer ReImaged - IS-L08-067

MIME-Version: 1.0

Date: Wed, 3 Dec 2008 17:49:49 +0000

Content-Type: text/plain; charset="US-ASCII"

Message-ID: <0351e6a0-a350-444b-b103-527cd5e9b0c0@wjenbcas2.wje.com>

Return-Path: {VALID FROM ADDRESS}

[Jos]

What is the result of this piece of code?

#include <date.au3>
Local $aResult = _Date_Time_GetTimeZoneInformation()
ConsoleWrite('@@ Debug(' & @ScriptLineNumber & ') : $aResult[1] = ' & $aResult[1] & @crlf & '>Error code: ' & @error & @crlf);### Debug Console
Local $bias = -$aResult[1]/60
ConsoleWrite('@@ Debug(' & @ScriptLineNumber & ') : $bias = ' & $bias & @crlf & '>Error code: ' & @error & @crlf);### Debug Console
Local $biasH = Int($bias)
ConsoleWrite('@@ Debug(' & @ScriptLineNumber & ') : $biasH = ' & $biasH & @crlf & '>Error code: ' & @error & @crlf);### Debug Console
Local $biasM = 0
If $biasH <> $bias Then $biasM =  Abs($bias - $biasH) * 60
ConsoleWrite('@@ Debug(' & @ScriptLineNumber & ') : $biasM = ' & $biasM & @crlf & '>Error code: ' & @error & @crlf);### Debug Console
$bias =  StringFormat(" (%+.2d%.2d)", $biasH, $biasM)
ConsoleWrite('@@ Debug(' & @ScriptLineNumber & ') : $bias = ' & $bias & @crlf & '>Error code: ' & @error & @crlf);### Debug Console

[metris]

Hi Jos,

I've the same problem.

Here's my result:

>"C:\Programme\AutoIt3\SciTE\AutoIt3Wrapper\AutoIt3Wrapper.exe" /run /prod /ErrorStdOut /in "D:\mysc.au3" /autoit3dir "C:\Programme\AutoIt3" /UserParams

+>15:40:01 Starting AutoIt3Wrapper v.1.10.1.8 Environment(Language:0407 Keyboard:00000407 OS:WIN_2000/Service Pack 4 CPU:X86)

>Running AU3Check (1.54.14.0) from:C:\Programme\AutoIt3

+>15:40:01 AU3Check ended.rc:0

>Running:(3.3.0.0):C:\Programme\AutoIt3\autoit3.exe "D:\mysc.au3"

@@ Debug(3) : $aResult[1] = -60

>Error code: 0

@@ Debug(5) : $bias = 1

>Error code: 0

@@ Debug(7) : $biasH = 1

>Error code: 0

@@ Debug(10) : $biasM = 0

>Error code: 0

@@ Debug(12) : $bias = (+0100)

>Error code: 0

+>15:40:02 AutoIT3.exe ended.rc:0

>Exit code: 0 Time: 1.864

[Jos]

Hi Jos,

I've the same problem.

Here's my result:

>"C:\Programme\AutoIt3\SciTE\AutoIt3Wrapper\AutoIt3Wrapper.exe" /run /prod /ErrorStdOut /in "D:\mysc.au3" /autoit3dir "C:\Programme\AutoIt3" /UserParams

+>15:40:01 Starting AutoIt3Wrapper v.1.10.1.8 Environment(Language:0407 Keyboard:00000407 OS:WIN_2000/Service Pack 4 CPU:X86)

>Running AU3Check (1.54.14.0) from:C:\Programme\AutoIt3

+>15:40:01 AU3Check ended.rc:0

>Running:(3.3.0.0):C:\Programme\AutoIt3\autoit3.exe "D:\mysc.au3"

@@ Debug(3) : $aResult[1] = -60

>Error code: 0

@@ Debug(5) : $bias = 1

>Error code: 0

@@ Debug(7) : $biasH = 1

>Error code: 0

@@ Debug(10) : $biasM = 0

>Error code: 0

@@ Debug(12) : $bias = (+0100)

>Error code: 0

+>15:40:02 AutoIT3.exe ended.rc:0

>Exit code: 0 Time: 1.864

Define same problem in more details to be sure we understand what you are seeing?

What is your real timezone?

[metris]

Emails that we send via AutoIt over exchange 2003 has a sent time 2 hours in the future (before summertime 1 hour).

Example: I run the script at 0:15pm. The email I receive has a received time of 0:15pm but a sent time of 2:15pm (s. attachment).

The PC - running the script - AND Exchange has the same time zone (GMT+1)

[MightyGuru]

I have been struggling with this issue also. There are some issues with the way _InetSmtpMail formats the Date/Time header information that does not conform to the RFC822 date/time specification. Specifically the time zone. The time zone data is not supposed to contain parentheses, Ex. (-0500). The code for $bias adds this unnecessary detail:

$bias = StringFormat(" (%+.2d%.2d)", $biasH, $biasM)

Contrary to trancexx's accusation, the header information jgira provided IS the exact header provided from Outlook. YES, _InetSmtpMail is set to format the time zone with parentheses when the message is sent, BUT since this is a voilation of RFC822 Microsoft's SMTP server, and most other modern SMTP servers, removes these in an attempt to properly format the header. Unfortunatly this screws up the time zone data and it is set to UTC +0000.

The other issue, which is not as bad, is the MONTH data. Based on the code: _DateToMonth(@MON, 1) the month is abbreviated. This is correct, as RFC822 dictates the month should be a three character abbreviation of the actual month's name. This works great for every month except June, July, and September. The code for these months abbreviates them to four characters (June, July, Sept); again a violation of RFC822. This is not as fatal because most SMTP servers correct this properly.

Local $aMonthNumberAbbrev[13] = ["", "Jan", "Feb", "Mar", "Apr", "May", "June", "July", "Aug", "Sept", "Oct", "Nov", "Dec"]

All this may sound a bit anal but I can tell you from experience, deviating from the 'standard' will cause problems.

RFC822 5.1

5 DATE AND TIME SPECIFICATION

5.1 SYNTAX

date-time = [ day "," ] date time ; dd mm yy ; hh:mm:ss zzz

day = "Mon" / "Tue" / "Wed" / "Thu" / "Fri" / "Sat" / "Sun"

date = 1*2DIGIT month 2DIGIT ; day month year ; e.g. 20 Jun 82

month = "Jan" / "Feb" / "Mar" / "Apr" / "May" / "Jun" / "Jul" / "Aug" / "Sep" / "Oct" / "Nov" / "Dec"

time = hour zone ; ANSI and Military

hour = 2DIGIT ":" 2DIGIT [":" 2DIGIT] ; 00:00:00 - 23:59:59

zone = "UT" / "GMT" ; Universal Time ; North American : UT

/ "EST" / "EDT" ; Eastern: - 5/ - 4

/ "CST" / "CDT" ; Central: - 6/ - 5

/ "MST" / "MDT" ; Mountain: - 7/ - 6

/ "PST" / "PDT" ; Pacific: - 8/ - 7

/ 1ALPHA ; Military: Z = UT; A:-1; (J not used); M:-12; N:+1; Y:+12

/ ( ("+" / "-") 4DIGIT ) ; Local differential ; hours+min. (HHMM)

[PsaltyDS]

I have been struggling with this issue also. There are some issues with the way _InetSmtpMail formats the Date/Time header information that does not conform to the RFC822 date/time specification. Specifically the time zone. The time zone data is not supposed to contain parentheses, Ex. (-0500). The code for $bias adds this unnecessary detail:

$bias = StringFormat(" (%+.2d%.2d)", $biasH, $biasM)

Contrary to trancexx's accusation, the header information jgira provided IS the exact header provided from Outlook. YES, _InetSmtpMail is set to format the time zone with parentheses when the message is sent, BUT since this is a voilation of RFC822 Microsoft's SMTP server, and most other modern SMTP servers, removes these in an attempt to properly format the header. Unfortunatly this screws up the time zone data and it is set to UTC +0000.

The other issue, which is not as bad, is the MONTH data. Based on the code: _DateToMonth(@MON, 1) the month is abbreviated. This is correct, as RFC822 dictates the month should be a three character abbreviation of the actual month's name. This works great for every month except June, July, and September. The code for these months abbreviates them to four characters (June, July, Sept); again a violation of RFC822. This is not as fatal because most SMTP servers correct this properly.

Local $aMonthNumberAbbrev[13] = ["", "Jan", "Feb", "Mar", "Apr", "May", "June", "July", "Aug", "Sept", "Oct", "Nov", "Dec"]

All this may sound a bit anal but I can tell you from experience, deviating from the 'standard' will cause problems.

If you edit your copy of _InetSMTPMail() with these:

1. Your change to the StringFormat() for $bias without the parens

2. Get the month with StringLeft(_DateToMonth(@MON, 1), 3); or just edit the contents of the array

Does that completely fix the issue?

Edited June 26, 2009 by PsaltyDS

[trancexx]

I can confirm the redundancy of parentheses. Though I didn't encuonter stated behaviour with servers.

Great debugging MightyGuru.

If the server part is correct then I obviously owe an apology to jgira.

[MikeA]

If you edit your copy of _InetSMTPMail() with these:

1. Your change to the StringFormat() for $bias without the parens

2. Get the month with StringLeft(_DateToMonth(@MON, 1), 3); or just edit the contents of the array

Does that completely fix the issue?

>_<

With the above changes, the time for me was still off an hour, due to eastern daylight savings time. It appears that the 7th array item returned by _Date_Time_GetTimeZoneInformation() needs to be included as well in the calculation for $bias, as follows:

Local $bias = (-$aResult[1]-$aResult[7])/60

[7] - The bias value to be used during local time translations that occur during daylight saving time. This value is added to the value of the Bias member to form the bias used during daylight saving time. In most time zones this value is –60.

For me, this last code modification in Inet.au3 completely fixed the time issue.

[newcoder]

With the above changes, the time for me was still off an hour, due to eastern daylight savings time. It appears that the 7th array item returned by _Date_Time_GetTimeZoneInformation() needs to be included as well in the calculation for $bias, as follows:

Local $bias = (-$aResult[1]-$aResult[7])/60

[7] - The bias value to be used during local time translations that occur during daylight saving time. This value is added to the value of the Bias member to form the bias used during daylight saving time. In most time zones this value is –60.

For me, this last code modification in Inet.au3 completely fixed the time issue.

Maybe I'm not understanding your problem, but from my view of the headers the client and server have the same time, but not the same timezone offset.

The time for each is;

Wed, 3 Dec 2008 17:49:49 -0600

Wed, 3 Dec 2008 17:49:49 -0000

which would result in a difference of 6 hours between the client header and the servers. If the server was really '-0600' different then the hours would be also be different by 6 hours.

If I misunderstood, then I apologize and will be quiet.

[amurin]

I had the same problem with the displayed times being wrong. I followed the above suggestion to subtract $aResult[7] which worked fine until we switched back to Standard Time, then the times were off by an hour again. So after some testing, I made the following changes:

Under Func _INetSmtpMail comment out "Local $bias = -$aResult[1]/60" and replace with:

If $aResult[0] = 1 Then

Local $bias = -$aResult[1]/60

Else

Local $bias = (-$aResult[1]-$aResult[7])/60

EndIf

Pretty simple, and it SHOULD adjust for DST and Standard time automatically. It's working so far anyway.

- Al

[Tankbuster]

@amurin

Yes, that was somehow pointing to the right direction for me.

But still one hour was missing in my mail ...so first I thought it must be a general issue, but currently it looks like this line from the RFC is is the problem of the whole thing:

RFC 5322 (as MightyGuru explained already) the important line for me is

The date and time-of-day SHOULD express local time.

Should? Does this mean it depends on ...... what....the moon, personal feelings, the weather ? Maybe my English is not that perfect but it looks like "they" do not state:

"has to be local time" or "has to be UTC"

I found also that even if I write a correct date our email server changes the date line .

No joke (must be a RFC I guess), I write as an example the local string (all examples I used with local time 16:18:36 (UTC 14:18:36, Germany, DST):

Funny.

If I use original INetSmtpMail autoit will write the line

--> String from _INetSmptMail

Date : Web, 8 jun 2011 16:18:36 +0100

resulting mail headerfrom our server:

--> My TB Client will display 18:18

Date : Web, 8 jun 2011 17:18:36 +0100

with amurin mod I get:

--> String from _INetSmptMail (amurin Version)

Date : Web, 8 jun 2011 16:18:36 +0200

resulting mail headerfrom our server:

--> My TB Client will display 18:18

Date : Web, 8 jun 2011 17:18:36 +0100

I help myself (I'm not in control of the server) I changed the lines in INEt.au3 to:

Local $aResult = _Date_Time_GetTimeZoneInformation()
    If $aResult[0] = 1 Then
Local $bias = -$aResult[1]/60
Else
Local $bias = (-$aResult[1]-$aResult[7])/60
EndIf
    Local $biasH = Int($bias)
    Local $biasM = 0
    If $biasH <> $bias Then $biasM =  Abs($bias - $biasH) * 60
    $bias =  StringFormat(" (%+.2d%.2d)", $biasH, $biasM)


    local $tCur = _Date_Time_GetSystemTime()
        local $tCur_Time = StringMid(_Date_Time_SystemTimeToDateTimeStr($tCur),12)

    $s_Send[4] =    "From:" & $s_FromName & "<" & $s_FromAddress & ">" & @CRLF & _
            "To:" & "<" & $s_ToAddress & ">" & @CRLF & _
            "Subject:" & $s_Subject & @CRLF & _
            "Mime-Version: 1.0" & @CRLF & _
            "Date: " & _DateDayOfWeek(@WDAY, 1) & ", " & @MDAY & " " & _DateToMonth(@MON, 1) & " " & @YEAR & " " & $tCur_Time  & $bias  & @CRLF & _
            "Content-Type: text/plain; charset=US-ASCII" & @CRLF & _
            @CRLF
    $s_ReplyCode[4] = ""

With this code I get the line written:

--> String from _INetSmptMail (my Version)

Date : Web, 8 jun 2011 14:18:36 +0200

and my server converts this to

--> Tb displays 16:18 (hurray)

Date : Web, 8 jun 2011 15:18:36 +0100

IF someone faces a problem with such a crazy smtp server, this may help him to solve his issue.

Just to make things clear:

From my point of vie it is not a problem of Client or Autoit or the UDF, our mail server makes funny things to the mail header (date) when he receives the mail.

I guess I'm not too confused now or in two hours ahead...?

[FreeBeing]

I had the same problem with the displayed times being wrong. I followed the above suggestion to subtract $aResult[7] which worked fine until we switched back to Standard Time, then the times were off by an hour again. So after some testing, I made the following changes:

Under Func _INetSmtpMail comment out "Local $bias = -$aResult[1]/60" and replace with:

If $aResult[0] = 1 Then

Local $bias = -$aResult[1]/60

Else

Local $bias = (-$aResult[1]-$aResult[7])/60

EndIf

Pretty simple, and it SHOULD adjust for DST and Standard time automatically. It's working so far anyway.

- Al

Thank you, it solve the problem !

Maybe that bug will be fixed into future AutoIt version ?

[FreeBeing]

Finally, I use _INetSmtpMailCom, it's really better and work with many SMTP servers.

Edited September 20, 2011 by FreeBeing