6
SM 8580 upgrade?? Any issues so far?
Question asked by Brian Bjerring-Jensen - 6/2/2023 at 5:28 AM
Unanswered
Just saw the release notes.

Anyone tried it yet?

44 Replies

Reply to Thread
5
Updated my biggest server a few hour ago from 8451.
All seem ok... finger crossed!!!
Gabriele Maoret - Head of SysAdmins at SERSIS
Currently manages 3 SmarterMail installations (1 in cloud for SERSIS which provides service to a few hundreds 3rd party Mail Domains + 2 on premise to customers)
1
Mike Mulhern Replied
Anyone know if the MAPI issues are resolved?
1
MAPI has worked for us flawlessly since 8545 upgrade.
2
M.G. Wallace Replied
In a couple weeks I may update of our servers with many clients on it if all continues to go well with those who've updated their servers. Thank you for updating and reporting what happens!

Cheers.
3
Updated to 8552 on June 2nd directly from "old SM"  build 8451.

I have no new problems, for now everything is pretty good, even if I have some observations to make... I gave more details here: 
Gabriele Maoret - Head of SysAdmins at SERSIS
Currently manages 3 SmarterMail installations (1 in cloud for SERSIS which provides service to a few hundreds 3rd party Mail Domains + 2 on premise to customers)
1
Tan Replied
Just upgraded but there is tons of cpu load. Support taking a look at it but the slowness and unresponsive is driving me nuts. Hope support can find the root cause.

Previously was OOM issue and was told to upgrade now instead of OOM become CPU issue.

Update:
CPU is stable now, here is what SM responded. Strange, how come you guys not having the same issue

====
The issue was that the URIBLs were activating Spam assassin and spam assassin was doing lots of regex lookups while checking emails for spam. The developers think that this can be optimized and will be working on it. In the meantime, I have disabled your URIBLS in Settings->Antispam->URIBLS
====

0
Manuel Martins Replied
HI,
I get this error on SMTP log, does anybody know why ?

rsp: 501 Syntax error, syntax: "MAIL FROM:" "<" address ">" / "<>" [SP Mail-parameters] CRLF

1
Jay Dubb Replied
Aside from the initial RAM and CPU spikes on "first login" how is resource consumption moving forward?  

We brought on a large client (currently in the 1,700 mailbox range) in late 2021 and We/They suffered through some pretty agonizing MAPI issues during the first year of service-- enough that they notified us they were going to break contract and were already getting quotes from 2 other large ESPs.  Fortunately the biggest pain points were fixed and we were able to retain the account.  There are still MAPI problems that forced them to convert dozens of users to IMAP + CalDAV/CardDAV.  That has been enough to give some relief, and things have been fairly quiet the past couple months, thankfully.

Quiet enough that we are VERY afraid to move off 8451 (Feb 20, 2023) and jump back into a potential fire.

We've read about the MAPI issues on the new version that persisted coming out of Beta.  Some say "fixed with version __" while others say there are still some lingering problems.  We have to know MAPI is "right" before risking the upgrade.

Another huge concern is CPU, and especially RAM consumption, going way up. Our Smartermail server hosting around 1,800 mailboxes with 7.5 TB of mailbox data, is a resource HOG already.  It runs on a Dell R440 bought new in 2022.  Dual Xeon, 8 x 2 TB Enterprise SAS (not SATA) SSDs.  During the average weekday, resource consumption is:

  • 20 Xeon cores sustained at 50-60% with spikes to 95%.
  • 68-70 GB of sustained RAM consumption (80 GB total installed) with daily spikes to 76-78 GB.
If the new version requires more CPU and RAM than 8451, we'll have to lay out another 5-figures for a fatter server... something we are NOT particularly willing to do given our investment in the current server last year.

Thoughts, insights, opinions?

0
This is what we see. Very easy on ressources. Look into the spamlists and they are the worst culprits regarding ressource use.

1
Lasse B. Replied
There is apparently a problem with the Spam Checker module, where it checks intermediate mail server IP addresses if the sender's mail server IP address is whitelisted. Intermediate mail server IP addresses are rarely in SPF records (e.g. an IPv6 address) and therefore SPF validation fails. I have a case open about it, as the users in Webmail see a warning on all mails from e.g. Microsoft Outlook 365.

I would just let you know.
2
Jay Dubb Replied
@Brian Bjerring-Jensen, your graph is similar to the resource consumption on our serve too, until we added a MAPI customer with around 1,700 mailboxes.  Now, THIS is what our consumption looks like on a typical weekday afternoon.



So you can see why we're more than a little worried about what things will look like on the new version.
 
 

0
J Lee Replied
I'm seeing server crashes every few days, and one else seeing this?

J. Sebastian Lee Service2Client LLC 6333 E Mockingbird Ste 147 Dallas, TX 75214 - 877.251.3273

0
Manuel Martins Replied
Hi,
Our Server is working 25-40% CPU and RAM. No crashes fortunatly!! 

My major concern for now is that we see a very high increse on Disk Bandwidth Usage since upgraded to this new release, 2 weeks ago, the old version did not used to use so many Disk Bandwidth and Webmail is much slower than it was.

1
We are on 8566 now. Apart URIBLs bug (se the other thread here...), everything is working good.

Yes, we also are seeing a (fairly) big increment in CPU, RAM and disk I/O usage, but it's not a problem by now.

Sure I hope that CPU and RAM usage will be more optimized in the future...
Gabriele Maoret - Head of SysAdmins at SERSIS
Currently manages 3 SmarterMail installations (1 in cloud for SERSIS which provides service to a few hundreds 3rd party Mail Domains + 2 on premise to customers)
0
Jay Dubb Replied
@Gabriele , when did you first upgrade to the new version track?  Was that recently and maybe the system is still grinding through its "first use" conversions, or was that a while back and the increased RAM/CPU/Disk is a permanent thing now?
0
I upgraded over a month ago... The increased resource usage is really permanent, but I've seen small improvements with almost every build, so I'm hopeful they can make more improvements in the future
Gabriele Maoret - Head of SysAdmins at SERSIS
Currently manages 3 SmarterMail installations (1 in cloud for SERSIS which provides service to a few hundreds 3rd party Mail Domains + 2 on premise to customers)
0
Seeing very little use on 8566

After the inital reboot everything settles down and is running rock solid.No issues with MAPI or sync at all.

Now I am fighting SPAM since a lot of shit is coming through...
0
Jay Dubb Replied
I'm seeing a number of reports of much higher disk I/O.  Does anybody know the root cause of that, beyond the one-time first-login update that happens?  Our mail server is using an array of 8 x Enterprise SAS SSDs on a fat caching controller.  Even with that very FAT (and expensive, these SAS SSDs are $2,000 each) disk subsystem, there are times where disk IO is so heavy (build 8451) that it noticeably affects performance, particular for webmail users.

We really WANT to upgrade to the new version, but so many reports of increased CPU, RAM, and disk I/O have us extremely concerned about taking that irreversible step forward.  We were expecting improved efficiencies over the old version, but it's not looking to be the case.
 
1
Hi Jay! We are on 8566 now and efficiency is really improved over the first buils of the "new" SmarterMail.

CPU, RAM and disk I/O are still higher than the "old", but not so high, we see about 1,4-1,5x on our server

The first builds where sometimes over 3-4x... 
Gabriele Maoret - Head of SysAdmins at SERSIS
Currently manages 3 SmarterMail installations (1 in cloud for SERSIS which provides service to a few hundreds 3rd party Mail Domains + 2 on premise to customers)
0
Chris Danks Replied
We just upgraded to 15 June build and our server keeps crashing. I’ll try what @tan said above. 
3
ActorMike Replied
Trusted Senders go to Junkmail and those browser notice nag messages that cannot be permanently dismissed are a nuisance. 

Image Caption
1
J Lee Replied
2nd, the Trusted Sender does not work all the time.

J. Sebastian Lee Service2Client LLC 6333 E Mockingbird Ste 147 Dallas, TX 75214 - 877.251.3273

0
Chris Danks Replied
have you opened a ticket with smartertools so they can see the issue themselves and then fix it for everyone else in the next update?
3
ActorMike Replied
They already know about the trusted senders issue. Obviously this is a serious problem since valid email can get dumped into junkmail. Hopefully a quick fix. Regretting updating now.
0
Chris Danks Replied
Yeah I too really regret updating!
I wish smartertools would have a beta/rc/stable build process as it feels like i have upgraded to a beta build. 
0
ActorMike Replied
What happened to the view raw header function? We cannot report spam messages anymore.
0
Andrew Barker Replied
Employee Post
ActorMike,

The View Header option is available in the ... menu in the message view. If you want View Raw Content, that is accessible by right clicking on the message in the message list.

Andrew Barker
Software Developer
SmarterTools Inc.
(877) 357-6278
www.smartertools.com

2
ActorMike Replied
Andrew Barker  True but it only shows the message header now and not the raw content in the message body, so we cannot report the message to spamcop! We've been able to view the raw message forever!

Add this to the list of downgrades.

0
Kyle Kerst Replied
Employee Post
For all admins seeing Trusted Sender issues - please open a ticket with us so we can help dig into it further. Trusted Senders are working in the vast majority of environments we've looked at, and the ones where it isn't usually ends up being a configuration change being required to account for improvements in these areas. 

@ActorMike - you can use the ...>Download EML to get the full raw content (including headers as well) for spam submissions if needed. These can be opened in a text editor if need be, but usually you can just zip up the EML and submit that to your antispam vendor.
Kyle Kerst
System/Network Administrator
SmarterTools Inc.
(877) 357-6278
www.smartertools.com
0
ActorMike Replied
I submitted a ticket for the Trusted senders issue and I guess I misunderstood and thought it was a bug. How can we get this addressed? 
0
Mark K. Replied
On Server 2019 I removed the Windows Defender Antivirus Role and it helped
0
Webio Replied
@ActorMike just like someone else suggested view raw source is available still but not under three dots button above message but above message list.

When it comes to trusted senders IMHO it might be related to return-path.

SMTP log on incoming gateway:

...
2023.06.28 11:21:24.202 [69.169.224.126][27770915] cmd: MAIL FROM:<01070189014eba02-e17d6307-9131-4e22-9386-02235475965d-000000@eu-central-1.amazonses.com>
2023.06.28 11:21:24.202 [69.169.224.126][27770915] senderEmail(1): 01070189014eba02-e17d6307-9131-4e22-9386-02235475965d-000000@eu-central-1.amazonses.com
2023.06.28 11:21:24.202 [69.169.224.126][27770915] rsp: 250 OK <01070189014eba02-e17d6307-9131-4e22-9386-02235475965d-000000@eu-central-1.amazonses.com> Sender ok
2023.06.28 11:21:24.202 [69.169.224.126][27770915] Sender accepted. Weight: 0. Block threshold: 90.
2023.06.28 11:21:24.233 [69.169.224.126][27770915] cmd: RCPT TO:<RECIPIENTEMAILWASHERE>
2023.06.28 11:21:24.342 [69.169.224.126][27770915] rsp: 250 OK <RECIPIENTEMAILWASHERE> Recipient ok
2023.06.28 11:21:24.373 [69.169.224.126][27770915] cmd: DATA
2023.06.28 11:21:24.373 [69.169.224.126][27770915] Performing PTR host name lookup for 69.169.224.126
2023.06.28 11:21:24.436 [69.169.224.126][27770915] PTR host name for 69.169.224.126 resolved as b224-126.smtp-out.eu-central-1.amazonses.com
2023.06.28 11:21:24.436 [69.169.224.126][27770915] rsp: 354 Start mail input; end with <CRLF>.<CRLF>
2023.06.28 11:21:24.482 [69.169.224.126][27770915] senderEmail(2): message@moje.zalando.pl parsed using: Zalando <message@moje.zalando.pl>
Delivery log on incoming gateway:
2023.06.28 11:21:52.453 [89968425] CMD: MAIL FROM:<01070189014eba02-e17d6307-9131-4e22-9386-02235475965d-000000@eu-central-1.amazonses.com> RET=HDRS ENVID=febcfc6e-a2af-4563-bbc3-657ac7576008 SIZE=102494
2023.06.28 11:21:52.484 [89968425] RSP: 250 OK <01070189014eba02-e17d6307-9131-4e22-9386-02235475965d-000000@eu-central-1.amazonses.com> Sender ok
Delivery log on primary server:

2023.06.28 11:21:52.362 [40553307] Delivery started for 01070189014eba02-e17d6307-9131-4e22-9386-02235475965d-000000@eu-central-1.amazonses.com at 11:21:52
2023.06.28 11:21:55.830 [40553307] Added to SpamCheckQueue (0 queued; 3/150 processing)
2023.06.28 11:21:55.830 [40553307] [SpamCheckQueue] Begin Processing.
2023.06.28 11:21:55.830 [40553307] Blocked Sender Checks started.
2023.06.28 11:21:55.830 [40553307] Blocked Sender Checks completed.
2023.06.28 11:21:55.830 [40553307] Spam Checks started.
2023.06.28 11:21:55.830 [40553307] Spam Checks skipped: Spam checks done by inbound gateway
2023.06.28 11:21:55.830 [40553307] Spam Checks completed.
2023.06.28 11:21:56.705 [40553307] Removed from SpamCheckQueue (1 queued or processing)
2023.06.28 11:21:59.674 [40553307] Added to LocalDeliveryQueue (0 queued; 2/150 processing)
2023.06.28 11:21:59.674 [40553307] [LocalDeliveryQueue] Begin Processing.
2023.06.28 11:21:59.690 [40553307] Starting local delivery to RECIPIENTEMAILWASHERE
2023.06.28 11:21:59.721 [40553307] Process delivery status notification step from local recipient success. Recipient: [RECIPIENTEMAILWASHERE], Notify: [failure], Delivered: [True], Forwarded: [False], Deleted: False
2023.06.28 11:21:59.721 [40553307] Delivery for 01070189014eba02-e17d6307-9131-4e22-9386-02235475965d-000000@eu-central-1.amazonses.com to RECIPIENTEMAILWASHERE has completed (Delivered to Junk Email) Filter: Spam (Weight: 33), Action (Global Level): MoveToFolder
2023.06.28 11:21:59.721 [40553307] End delivery to RECIPIENTEMAILWASHERE (MessageID: <01070189014eba02-e17d6307-9131-4e22-9386-02235475965d-000000@eu-central-1.amazonses.com>)
So as you can see email from return path is being used for verification (it looks that way) during checking process BUT when I go to junk mail in webmail and I'm opening this message it shows trusted sender (message@moje.zalando.pl) info.
0
Tan Replied
@Actormike since you are on the latest build, can you help me to check on this?

0
M.G. Wallace Replied
Has anyone updated to the newest build (8587) as of July 6, 2023?
If so, how has this improved the CPU and RAM issues?
Also, how about the Trusted Senders going to junk mail?
Again, thank you to everyone who are assisting with these newest issues builds.
Cheers.
0
J Lee Replied

J. Sebastian Lee Service2Client LLC 6333 E Mockingbird Ste 147 Dallas, TX 75214 - 877.251.3273

0
ActorMike Replied
M.G., there is no note of the trusted senders going to junkmail being fixed, unfortunately.

Build 8587 (Jul 6, 2023)

  • Fixed: An issue were a single appointment in a user's account caused sync issues and exceptions in SmarterMail.
  • Fixed: An occasional blank compose/reply window when SmarterMail is running in a virtual directory in IIS.
  • Fixed: Better handling of string comparisons in MAPI related to Turkish Windows servers.
  • Fixed: Category sync issues in IMAP.
  • Fixed: Email migrated from Exchange 2010 has the wrong time in the sent folder.
  • Fixed: Folders created through any EWS client create those folders in the wrong location on the server.
  • Fixed: For some emails, the attachment icon doesn't appear in webmail, and the attachment doesn't appear in MAPI, EAS, and EWS clients.
  • Fixed: In News Feeds, the RSS title, "Last Updated" timestamp, and RSS summary are missing on all feeds.
  • Fixed: Meeting Invitations from MAPI to MAPI that include attachments lack Accept/Decline buttons and duplicate the attachments.
  • Fixed: Messages that are forwarded by automated forwarding or content filters have a mismatch between Return Path and From address.
  • Fixed: Setting a report start date to 01/01/1800 leads to MailService.exe consuming ~5GB of memory until restart.
  • Fixed: URIBL's sometimes use excess CPU and take too long to do their checks.


1
Ben Rowland Replied
I installed 8580 yesterday. I had been having multiple outages per day and extremely slow performance on the previous build. I have found performance greatly improved with 8580 so far and no outages. Webmail had been unusably slow and is now working again.

I see 8587 now released but somehow the version downloaded and installed yesterday was 8580 instead of 8587. So I must have installed it after they posted the release notes but before posting the new installer.

Regardless, the performance is better, at least for me.
1
M.G. Wallace Replied
@ActorMike: That is why I asked about the junk mail issue as well, as they didn't include it... thinking the URIBL's fix of taking to long and using up CPU would somehow be a fix to this issue as well.

Hopefully this new build will be doing what it is intended to do soon!

@Ben Rowland: Thank you for your update too! Very encouraging!
4
Martin Schaible Replied
Updated to 8587 today directly from old build 8451.

Everything went good, no issues so far. The logs are looking good.

I had to update the IDS rules to my needs only.
3
Brian Bjerring-Jensen Replied
On 8587 and no issues reported so far.
1
Alessandro Pereira Replied
We have a serious problem with excessive CPU usage in Build 8587 (July 6), we didn't have this problem in previous versions.
We disabled the URIBLS and also several RBL to be able to work again.
1
Thats because they are stuck in the spooler and the blacklist is very slow to load.
0
Tan Replied
@Alessandro Pereira, do you want to log ticket with SM because this issue technically should be fixed.
1
ActorMike Replied
Does the new build address the problem with Trusted senders going to junkmail that fail DMARC? A trusted sender should NEVER go to junkmail for any reason.

Reply to Thread