Messages from EAS senders have date/time stamp of when received, not sent

Problem reported by Paul R - 11/2/2018 at 7:38 AM

Resolved

Head scratcher here. Person uses Outlook but DOES NOT use EAS. Closes Outlook at 5 pm and goes home for the night. Arrives the next morning and opens Outlook, which downloads all new emails.

Emails sent by non-EAS users on the same domain arrive with their date/time stamp (as displayed in Outlook) reflecting when the message was originally sent. That's good.

Here's the problem. Emails sent specifically by EAS users on the same domain arrive with their date/time stamp (as displayed in Outlook) reflecting when the message was received that morning. So a message sent at 6:00 p.m. the night before displays a date/time stamp in Outlook of 8:00 a.m. the next morning when it's retrieved. Recipient has no way of knowing when the message was actually sent. That's bad, because he's a high-level manager and needs to know when employees are actually sending the messages.

Again, this only seems to affect messages sent by EAS users.

Ideas?

22 Replies

Reply to Thread

Employee Replied

11/2/2018 at 7:42 AM

Employee Post

Paul, thank you for reporting this. I have added it to our bugs list for further investigation.

Paul Blank Replied

11/3/2018 at 5:48 AM

Which versions of SM are affected, please?

Paul R Replied

11/3/2018 at 6:30 AM

We're seeing the problem on SM Enterprise 16.3.6870.

Employee Replied

11/8/2018 at 7:59 AM

Employee Post Marked As Resolution

Hello,

The fix for this issue was included in last night's release of SmarterMail 16.3.6885:

Fixed: Messages from EAS senders have date/time stamp of when the message was received, not sent.

Please upgrade SmarterMail and let us know if the issue persists.

Paul R Replied

11/12/2018 at 7:04 AM

Hello,

We applied 16.3.6885 and it fixed the problem, but ONLY FOR senders using Microsoft Outlook. Messages sent via the mail client on MacOS still show a timestamp when the user receives it. So whatever fix you applied to EAS apparently needs to be applied to the EWS environment also.

Employee Replied

11/16/2018 at 5:19 AM

Employee Post

Paul, we have moved the changes from EAS to the EWS code base as well. If a client sends a message and is missing the Date header, it will be appended to the message.

Paul R Replied

11/16/2018 at 6:35 AM

Thanks for the quick followup on this. We've installed the update and to minimize noise, I'll only update this thread if there is still a problem.

Paul R Replied

11/17/2018 at 9:35 AM

BIG Problem. After updating from 16.3.6885 to 16.3.6893 (to get the EWS fix) late Thursday night, all 4 CPU cores are hanging at just over 50%. See screenshots below.

UPDATE #1: High CPU is from indexing. When I disable the Indexing service in the SmarterMail management interface, CPU drops to normal. Start indexing, CPU climbs back up. I'm watching the indexing progress, and it's not hanging on any specific mailboxes.

UPDATE #2: Disk consumption began increasing rapidly (multiple GB per day) at the same time the CPU issue began-- when the 16.3.6893 update was installed.

UPDATE #3: Full uninstall and reinstall did not help.

UPDATE #4: Had to disable the Indexing service tonight. It was rapidly chewing through disk space by the GB.

UPDATE #5: Uninstalled 16.3.6893 and reverted back to 16.3.6885. No more problems, other than back to the EWS problem of the email timestamp being the date/time the user receives the email (which .6893 was supposed to have fixed)

CONCLUSION: Something in 16.3.6893 broke Indexing.

Michael Replied

11/18/2018 at 12:30 PM

Hum...

We've seen this before in v 15.x where an update breaks indexing. And indexing loops forever taking up huge amounts of cpu. Interested to see how this is fixed and more importantly how it can be prevented in the future.

Ionel Aurelian Rau Replied

11/19/2018 at 2:19 AM

Same here - we updated to v16.3.6893 over the week-end and now CPU utilization is 80 - 95%, while normally it sits under 20% worst case scenario.. Some users are reporting that Outlook is not synchronizing and other complain of slow web interface.

*It's just another (Smarter)manic Monday* :)

Christian Schmit Replied

11/19/2018 at 3:07 AM

Same here with v16.3.6893.

Ionel Aurelian Rau Replied

11/19/2018 at 6:19 AM

Oh, wow, this version is indeed horrible:

- space utilization has increased by ~ 3GB in the last 2-3 hours since Paul R`s reply made me watch this closely. So about 1GB per hour!

- CPU utilization fluctuates for a while, but then shoots up at ~ 90 - 97% and stays there. WebMail gets slower and slower until after ~ 3-4 hours it just stops responding for users

- Restarting the SmarterMail service does not solve anything - a full reboot of the VM is needed to bring back the WebMail interface

- People are reporting emails stuck in Outlook`s Outbox folder or missing synchronization altogether.

I have now disabled Indexing so people can work with the WebMail interface, but have no idea what this does in the long run.

Can anyone at STools acknowledge the issue and provide a fix? Is Indexing the sole culprit? If yes, ca you tune indexing to have a much lower priority and to not consume more than X amount of CPU time?

Ionel Aurelian Rau Replied

11/19/2018 at 8:52 AM

Now a user complains that all of his folders disappeared and indeed this seems to be the case. He now only has the Inbox, Sent and Deleted folders, all of his other ones are gone.

Anyone else see this in the new version?

Paul Blank Replied

11/19/2018 at 9:40 AM

I am hoping that these issues do not affect v15. Will [still] be staying with v15 for the foreseeable future, and hope that ST continues support for this (very) stable version.

Ionel Aurelian Rau Replied

11/19/2018 at 12:05 PM

Dear Diary, today was a horrible day..

I just reverted back to v16.3.6885 - hopefully things will at least get back to last week`s normal.

Looking forward to tomorrow.

Paul R Replied

11/19/2018 at 12:27 PM

We've been fine since reverting back to 16.3.6885 yesterday. Except for the aforementioned timestamp problem in my original post.

The moral of the story is, always keep the last known-good installer on-hand. This is the 2nd time in the past few months we've had to revert to a previous build because of a defect in an update.

To ST Developers-- please pay more attention to Quality Assurance before releasing new builds. You're ruining the reputation of a very good product by releasing sloppy patches that break stuff.

Employee Replied

11/19/2018 at 5:56 PM

Employee Post

There is a new release that addresses the indexing and high CPU issue.

Paul R Replied

11/19/2018 at 8:46 PM

Anyone want to have a whack at it? After having to revert 2 of the past 5 build updates we've installed, I'm not inclined to install this one without lots of feedback in the community.

Ionel Aurelian Rau Replied

11/20/2018 at 1:53 AM

Yes, this is the problem, now I cannot update to the last build as I do not trust it. I`ll just have to live with v16.3.6885 until I think another (not the latest) build is safe after constantly reading the community threads here.

I just finished rebuilding a user`s mailbox that got corrupted yesterday (all folders disappeared except for Inbox and Deleted [yes, including the Sent Items folder, but that was recreated automatically when the use sent an email]) and apart from that there is another one whose Outlook still does not sync emails today. Apart from that, being on v16.3.6885 is smooth sailing even with the timestamp issue compared with yesterday on v16.3.6893.

I`ll just have to camp here, hit refresh until I feel safe of jumping to another version (which I know is no guarantee.. oh the horror ;) ).

Paul R Replied

11/20/2018 at 5:34 AM

We're anxious to update because the timestamp bug is affecting many users, including a very important client that does a lot of other (non-email) business with us. They were the ones who first discovered it and contacted us. The EAS bug was fixed, but some of their executives and staff are on Macs, which use EWS, and that's the part I'm most anxious to resolve for them.

But we're obviously gun-shy.

Ionel Aurelian Rau Replied

11/21/2018 at 5:28 AM

OK, so I had to bite the bullet again and update to the very latest version (16.3.6897) since there was a bug that we did not previously observe in v16.3.6885 and wanted to know if it`s fixed in .6897 (it`s not, I`ll report it shortly). So far the CPU usage sits between 15 - 30%, so that`s good. People are not complaining of slow WebMail experiences, nor are reporting other major issues. Fingers crosses - maybe v16.3.6897 is worth staying onto for now.

Paul R Replied

11/22/2018 at 2:38 PM

We also bit the bullet and installed 16.3.6897, and all seems to be well. No CPU or disk consumption issues. I would have preferred waiting, but the timestamp bug needed to be resolved ASAP, particularly for one of our "white glove" clients whose executive team uses Macs.

Back to Community Threads

Please leave this box unchecked

22 Replies

Reply to Thread

Tags

Related Knowledge Base Articles