After reviewing the windows logs

"Mailman.Get Exception: System.TypeInitializationException: The type initializer for 'SmarterTools.Common.Network.DNS.DnsManager' threw an exception. ---> System.IO.FileNotFoundException: Could not load file or assembly 'DnsClient, Version=1.3.2.0, Culture=neutral, PublicKeyToken=4574bb5573c51424' or one of its dependencies. The system cannot find the file specified.
   at SmarterTools.Common.Network.DNS.DnsManager..cctor()
   --- End of inner exception stack trace ---
   at MailService.Repositories.SystemRepository.SettingsGet()
   at MailService.Core.Mailman..ctor()
   at MailService.Core.Mailman.Get()"

Looks like something didn't come over with the installer

Confirmed.

Build 7944 is non-functional here on Windows Server 2016 w/ .NET 4.8 as well.

Uninstalling Build 7944 and re-installing Build 7929 brought everything back to life.

I was tempted to log an Emergency Support Ticket in order to raise awareness of this problem with SmarterTools so that they can quickly pull the build from public view but after seeing that the $299 is non-refundable regardless of the outcome, I decided against it.

Really? Is 7944 so worse than 7929??????

Why?

This is why we need Monday releases. So when they break… ST is around to fix it…

@echoDreamz: I agree, releases right before a "office-closed Friday" or like this time even released on such a Friday probably due to the fix for the DNS-Client/TTL-issues - this was really not the best decision by ST.

Issues/Bugs can happen and no ones head will be cutoff right away - but releasing an update and then it´´s "weekend" and no-official-one of ST will have an eye at the fresh release/customer comments this is causing a bad reputation for their company.

Better release-days in my eyes are Mondays and/or Tuesdays - so no one at ST needs to work over their weekend and they probably could even use the weekend for some more (automated) QualityControl-tests and last stability-tests If their test-servers/systems will keep up running over the weekend. And if no fatal issues are found make it as a public-release.

And keep in mind: the actual released build 7944 is an official/public release - so customers would expect it to be almost stable. I already suggested two branches "stable" and "beta" for a few times - but not really an reaction/answer by ST. And they better keep in mind to always put a release at first into the beta-branch - and in case of fixes required they should not release a public/stable build right with the fix in it - better to first release it as "beta/unstable" - and move good/stable release after some time into the public/release-stable-branch.


btw: I thought about updating to build 7944 over this weekend - but I am glad that I did not give it a try yet. But we could need this update/build due to IMAP and DNS-issues - but only if it is working/running as it should. Right now it is almost better to wait until some customers were "brave enough" testing a new release and giving their feedback here at the community.

I suppose we will have a solution/fixed build on Monday/Tuesday by ST - but it would be much better ST would react/comment even during this weekend.

It looks like a missing library within the installer, i.e. when its compiled its not included a reference it should have done.

Anyway DO NOT install it :)

Note... the installer for 7944 is smaller than 7929 which could indicate something is missing.

I usually leave pushing out SM updates for 7 days after release, but I thought as it only contained a few fixes push it out.

Thread title changed

It will never be possible to install a new release of this product without being anxious that it will break something critical. It can't go on like this :(

Especially when it is advised not to downgrade because it could create other issues.

Please ST do something to improve this in the future.

As other folks and myself proposed, please create two branches. A stable and a beta and only push things to stable when they passed the "beta" testing.

We are customers, not beta testers.

Thankyou you saved me from another period of heart ache

Thanks Zach for responding on a weekend and getting this fixed up.

Great job Zach!

I'm testing it (7945) now and it seems to be OK

For us 7945 seems to be working normally.  

@Zach: Thank you very much for getting this fixed and releasing a new build.

And for the future we hope that ST will release new builds on Mondays/Tuesdays - so that you will have the weekend free / without trouble :-) And please think/discuss two branches for public builds: for example a stable and a beta-branch.

I have big issues with 7945 and DNS.

SmarterMail still keeps trying to send emails to the wrong IP addresses.

I just sent an email to Gmail and SmarterMail tried to send it to the IP 127.0.0.1

The issue started for me with 7914 after installing ASP.NET 4.8 in preparation for the new version that requires AS.NET 4.8.

I have about 12,000 mailboxes and am finding that large numbers of emails are affected. I have to keep rebooting the mail server to fix the DNS issue,. The DNS issues then start again either within minutes or sometimes a few hours.

To try and limit the impact I have my DNS server sending a TTL of 0 to SmarterMail so that it more quickly gets fresh DNS results, but it is still impacting a large number of emails with SmarterMail getting the wrong DNS and either the RBL spam filters bounce emails or worse and more common sending sent emails to the wrong IP address so they end up being sent to the wrong mail server!!

I have to agree with others on here, ST needs to do more testing, and new releases on Monday, not Friday so that support staff are on hand to help with issues.

> I just sent an email to Gmail and SmarterMail tried to
> send it to the IP 127.0.0.1
>
> [2021.10.04] 09:17:07.479 [39900643] MxRecord
> count: '1' for domain 'gamail.com'

Methinks it is not SmarterTools that is responsible for this particular error 😉

Just seen the person I replied to gave their email as @gamail.com.

I have been getting a lot of @gmail emails going to Microsoft IP's, MailChimp IP's and even 127.0.0.3 in the last week and presumed the issue is still not fixed. 

Just chiming in to echo what others are saying regarding the releases. Switching to Monday/Tuesday instead of Thursday, going with stable/beta, and/or just releasing specific patches...any of these would be a big improvement.

7945 2 days ago
No problem so far

@Bruce

Just following up here. Did the issue turn out to just be a typo? 

Looking forward to hearing from you. 

Best Regards, 

Yes, the issue was a typo the person gave their email address as @gamail.com in an online form which the MX record for the domain has the IP 127.0.0.1. The bounced email and logs were the same as during the DNS issue with emails sent to GMails.

I have been monitoring with 7945 and so far everything is working well with no DNS issues.

@JerseyConnect :SmarterTools did it again: a release right before Wekkend/right before their 'free Friday' :-( build 7950 released October 7th (Thursday).

I have not tried the latest release build 7950 yet.... I will wait until some customers are brave enough to give the new build a try - right now we are running build 7945.

I can't agree more, SmarterMail releases are often very buggy and released just before the weekend when they go off for two days.

They need to have better in-house testing, more stable releases, and release dates on Mondays so support is available in case of any bugs.

Personnally, I'll wait at least until next week to install latest build for our customers. I would like to have a calm weekend for once... :)

I will keep 2-3 weeks before install a new update...

Might need to change the 1-week rule to a 1-month rule for installing new releases. :)

Unfortunately we had a few customers reporting syncing recurring events issues with EAS on Android, the latest build seems to fix this, so we had to install the latest build. So far, no issues to report.

Hi echoDreamz!

Good to know that it works well on you...

Maybe I will give it a try...