E-mail Sent time not matching server

bhaughn

I have been having an issue with version 2.0.2.0 of the SRP e-mailing utility. When we send an e-mail from our server (AST timezone) at 12:00pm noon, when we receive it; the received time is still noon, but the sent time says 8:00am. We had an older version of the utility (1.2.0.0) and the same e-mailing code does not have this issue.

Was there a change we missed between those versions where some sort of time setup is required on send to set the timezone properly?

KevinFournier

I'm not sure why this is happening. I'm getting the time from the localtime API. According to MSDN:

localtime attempts to use the time zone information specified in the Date/Time application in Control Panel. If this information cannot be obtained, PST8PDT, which signifies the Pacific Time Zone, is used by default.

Based on this, and given that PST is 4 hours earlier than AST, I get the impression that the SRPMail.dll is not able to retrieve the time zone from the server. Perhaps a permission setting is getting in the way?

bhaughn

I wonder. In both these cases I am connecting to the computer being run through citrix, which adjusts the time zone appropriately for the user logging in (to match their time zone). Could this have some effect on the api being called? I can't see it being involved.

Was the 1.2.0.0 not using that localtime API previously and that is why the older version seems to work vs the new one?

KevinFournier

1.2.0.0 send mail using the now deprecated CDO Messaging service. As of 2.0, we use SMTP directly. It's reasonable that CDO has some additional logic to handle Citrix-type scenarios.

I could add a field to SRP_Send_Mail to let you supply your own sent-date, but I don't know if OI would have the same problem. That is, I don't know what API OI is ultimately relying on for its date and time.

JaredBratu

It could be related to the 'Allow time zone redirection' setting on the server. If this is/isn't set it can impact the time returned to an application. See https://technet.microsoft.com/en-us/library/cc725887(v=ws.10).aspx

bhaughn

I know its been a few years but I thought I would follow up on this as we're still experiencing it. We double checked all our servers have the setting that Jared Bratu mentioned. It all appears to be configured properly.

We are still able to use older SRPMAIL.dll files to get the correct time to show up in an e-mail program, but we don't like the idea of removing fixes by downgrading to get the time fixed in the e-mail. We acknowledge that this problem is probably coming from our use of Citrix and adjusting the time zone to each user logging in to their local time zone.

If it helps to know, the time we get from OI when we do this appears correctly. So for now we are now including the time within the e-mails we send to say what time the e-mail was created. That way even though the time arrived may say something like 8am when it is actually 11am, the e-mail contains the 11am info.

KevinFournier

I rewrote SRPMail.dll from scratch in order to break free from the open source SMTP library I was using in favor .NET. You can download 2.2.0.0 for testing. Note: it supports TLS, but not SSL (as SSL is less secure). Also, this RDK uses RevDotNet, so if it doesn't work at first, you'll have to run OI's Client Install.

Please let me know if the date look correct with this new version. If you absolutely must have SSL, let me know. There's a deprecated API in .NET that might be useable, but I'd rather not have to use something unsupported.

bhaughn

Hi Kevin. I spent the day testing this in a test environment. It does solve the time issue, unfortunately it introduced a few new issues. Some were solvable and some were not.

we had previously used the SRPSENDMAIL command rather than SRP_SEND_MAIL which is an easy change as it appears as though SRPSENDMAIL no longer exists in the dll. It looks like they have the same parameters though in the same order. No matter what I did though, it would always ignore any files I asked to have attached, and reset any importance flag to low importance.

Everything else seemed ok though. And like I said, it solved the time issue. We send attachments in many of our e-mails (usually pdf or excel reports) so it was easy to notice this right away.

KevinFournier

I was able to confirm the issue and get it resolved. You can download the RDK here.

bhaughn

Thanks for the quick reply.
I installed this into the test system I was working with and ran into an issue where now SRP_SEND_MAIL always returns "" rather than a success of 1. It also never sends the e-mail so I suppose that makes sense. Just in case, I made a fresh test system and installed the newer patch to it rather than overwrite the previous patch.
I got the same result. All of my e-mails had pdf attachments and normal priority. The title would be just "Work order 100001" and the description I changed to just say "see attached" in testing to see if it was the description.

I can get all of the settings of config and message if that helps.

KevinFournier

If it's always returning "", that tells me that OI is unable to make the .NET call into the DLL. Did you run OI's Client Setup for this test system to make sure RevDotNet was fully enabled?

bhaughn

Hi Kevin: we had run that client setup and can use other .net calls. With the previous 2.2.0.1 file in the same system it was able to make the calls into the dll, but upgrading the same system with the 2.2.0.2 update I always get a blank returned from the call and no e-mail is sent.

The call in both cases is the same, it was just the 2.2.0.1 vs 2.2.0.2 so far as I can tell.
If versions matter, I see that we have on the server installed:
Revelation Software .Net 4.0 v9.5
Revelation Software .NET Components v9.5

as the dotnet components.

KevinFournier

The best I can offer is SRP Mail 2.2.0.3, which will try to avoid passing just "" when there is a RevDotNet error. The issue will probably still occur, but at least you'll know that RevDotNet is not working if you get "RevDotNet Error" (along with an error code) as a result.

I can also email you the source code to SRP_Send_Mail for debugging to troubleshoot further. That way you can see exactly what is failing.

bhaughn

Hi Kevin. I'll follow up with an e-mail with details rather than posting a lot of extra info here. I appreciate your help on this.

bhaughn

Kevin helped me out with this issue. I now have SRPMAIL sending e-mails with the proper times using 2.2.0.4. This should be something we can thus easily include in all of our existing system installations. Thank you so much for all your help on this!

KevinFournier

In case others read this thread, we decided to release this as 3.0 since there are some changes that could require some developers to adjust their code. 3.0 is a drop-in replacement for some developers, but not all. Read our blog post for more details.

Thanks, Brad, for your patience.