You'll just need to install the .NET Core runtimes which are available direct from Microsoft and as of right now; the latest is .NET Core 7.0.21. That said, I've confirmed with development those components will be prompted during installation so there shouldn't be anything you need to do in addition to your normal upgrade routine when we get there! We should have more information as we get nearer that release though. I hope that helps!

The true promise of .NET Core is that it runs cross platform. The other versions of .NET are not cross platform. Hence you can run Core applications on Linux without any modification (which can save hosting costs while boosting performance).

That likely won't be the case for SmarterMail. If they upgrade it to use .NET Core, that won't necessarily mean they will support a webmail that runs on Apache, nor build a Linux installer. Instead, based on Kyle's comment, I suspect it means it will continue to run on Windows, but will simply use new libraries. From that perspective, there is no immediate benefit. Also, a big piece of software like SmarterMail will use many 3rd party libraries, and those libraries of code are not necessarily cross platform. There are also the other services such as Cyren and Clamd which SmarterMail spawns and would need to be ported.

I would say this is an important step in the path to SmarterMail becoming a product that supports cross platform, but this is a long road, with no immediate impact for users at this point.

Great response Ben! Exactly, this has given us a chance to standardize on newer libraries and chunks of code that aren't windows/.net framework specific and we have made sure all the new decisions we make with what we use is that it can eventually be used on Linux. Your example with ClamAV and Cyren are good too, we'll end up needing to include binaries for Linux which thankfully they do have. We're making sure some chunks of code can be turned off for Linux (like Windows Defender scanning). This has also given a chance to modernize some of our base-level code to use more modern dotnet stuff like our Socket based protocols (XMPP, POP, IMAP, SMTP). IIS isn't as strong of a dependency anymore, now it's simply a proxy to our process and we serve HTTP via Kestrel from SmarterMail directly. 

Check out our .Net Version on https://mail.smartertools.com/about/checkup :) It's coming along!

Ben, you would be correct if you were referring to 3 years ago but as we mentioned, we have been working on this for a while!

.NET Core Beta will be released within a 3 to 4 weeks.  It's not just .NET Core but a bunch of new stuff as well.

Blog Post will be available in 2 to 3 weeks with all the details.  We are finalizing what new features are ready to be released.  Lot of moving parts!

SmarterMail is already running on Linux along with the associated components like Cyren! :)   I get Ubuntu builds to play with frequently!

Ok, these are two very exciting messages to receive. I stand corrected.

Will you terminate ssl at the machine's web server (presumably Apache, nginx, IIS) and then proxy to Kestrel?

I'm looking forward to more information on this and trying the beta. I am curious to know what your preliminary testing has shown for Linux vs Windows performance. Every application is different, but an application that I migrated showed 2x the performance under Linux at the same hosting tier under a side-by-side load test.

Yup, IIS still handles all the certificate stuff exactly the same way as before. No changes should need to be made to accommodate this. IIS will handle the HTTPS and then talk to SM directly via HTTP. This allows you to have a reverse proxy that handles your HTTPS, IIS in this case. Clicking around in the web interface is definitely snappier now. No comparisons yet but we're still finding big optimizations like our Socket async changes I mentioned. Maybe during BETA we can do some comparison testing between environments.

Tim, you've got internal SM builds running on Linux? Whoa!! Does this mean Apache? Or, is this way too preliminary to talk about publicly? Interesting, for sure.

Matt

I think it would mean that on Linux any web server (apache, nginx, etc.) would handle the ssl termination (same as they describe for IIS on Windows) and then proxy to Kestrel, which is the web server built in to .NET core. That's what would allow them to run cross platform. I am very excited to see this thread, and even more impressed that they have been doing this in the background (presumably for years) while also working on the recent major release.

Really good news, even better if you support Debian. Looking forward to those builds appearing:-)

I know it is early days but will migrating from Windows to Linux be supported? I guess a lift and shift could be tricky due to case sensitivity in the Linux file system, differing paths, etc. Would be good if there was some sort of automated 'move domain' function to move a whole domain between installs if a lift and shift is not possible.

I really am eager, any news on the .core beta?

Sounds like it may be any day. I know we're waiting on a number of fixes and enhancements that are in the .NET Core update. So we're very much looking forward to it.

Looking forward to it too.

eM Client partnership this week!

Next week we go into .NET Core BETA with new fixes, changes and FEATURES!

Before end of year we will release .NET Core for real :) 

Three to four months something even bigger!

We are working hard for you and your customers, there is a lot in the pipeline!

Love that we are getting a .net core release! That is awesome, great work!! However, it is not cool that we have to wait for bug fixes to be rolled out in this beta release instead of getting updates to the current SM branch... So we are stuck with the current SM build with our bugs for another 6 or so months or we chance it, install a beta release and hope that the new build does fix the issues we've reported and does not have any new major issues or stability concerns.

To be fair there will have to be a cutoff where they stop maintaining two codebases and .NET Core gets my vote every time as it is the future. Lets hope we get through the beta phase quickly :-)

I admit that is probably easy to say as although we licence MAPI we do not use it as it has never been a reliable experience (have to take that on the chin to get the EWS support we do use) and the IMAP/SMTP/EWS works for us.

One of the things that sets SmarterTools apart from other software companies is our frequent and consistent software updates and fixes. We don't wait for major releases to implement improvements or address issues. You can see our track record of updates by looking at our release history.

Sometimes, we have to delay a fix because it depends on a major change in the code base or a significant difference between versions. However, we always prioritize stability and workarounds for any critical problems. 

We also try to minimize our reliance on other software companies that update their products less often than we do (such as quarterly, biannually, or annually). That's why we prefer to develop our own solutions or use open source libraries that we can modify and release according to our schedule, which is about every three weeks on average.

We are proud of our software development processes and we rarely receive negative feedback about them. In fact, we are often approached by other companies that want to acquire us, not only for our products but often for our software development team and our processes.

Tim,

I really do not underestimate working with MAPI, having done so on an infinitely smaller scale than you I know it is far from simple, definitely an art rather than science. I can only imagine the amount of development hours to get this far!

We encountered too many performance issues in the early days that we decided to park it but will definitely revisit when the .NET core beta builds start appearing :-) Looking forward to being able to get SM/MAPI on Debian !

Nathan, I absolutely agree that .net core is a good move, 10000% on board with that. However, having no fixes in the pipeline for the RTM SmarterMail build and having to choose between waiting many months for a stable release (probably extra time to make sure it is extra stable and let the early adopters find the majority of the issues) or jumping into the deep end of a mail server in beta just to get bug fixes (and possibly introduce many more) does not sound fun :). Though, I do also understand that some fixes or features simply were not possible in fwk or were not easily achievable. There absolutely has to be a cut off date on work for the stable branch, generally when the new branch is stable, not when the beta branch releases for testing.

The majority of software vendors we use have regular releases, we've never been told if you want fixes, you will have to join our beta program and run beta software in your production environment, especially something as critical as a mail server. I am sure the .net core release has been tested, and I am sure the majority of the code probably ported over, but it is a whole new platform that needs a lot of testing.

Maybe SmarterTools can deploy a Linux .Net Core version of SM and allow us to login to webmail, IMAP, MAPI, POP, etc and test.

I don't see any big way to avoid the BETA approach.

There will be bugs, especially if they gather tens of testers vs thousands of testers.

To SmarterTools credit, it's tough to rely on a small team for testing. Thus, they advertise BETA.

For production, unfortunately, echoDreamz is correct that it is an extended waiting game.

I am very interested in the ability to run it on Linux, but as far as that goes, that is now 2 different platforms, .net core and a completely different OS with a completely different set of variables.

I totally agree they need beta testers, everyone does and they will get some for sure, we will def install beta builds on our test environment to review the API and what not, but forgetting about your stable branch in the mean time isnt cool.

Maybe SmarterMail should deploy a testing build on their end. Then create an account for us. We can test it as customer point of view from our end.

Just my thoughts

Can't wait for the beta so we can install it

Microsoft moving to .Net Core means all developers will ultimately need to move that direction. ST has to pull that bandaid off at some point.

Linux is a far more diverse environment than is Windows. I see no way to replicate all possible operating systems and configurations of software and hardware without getting a product out into beta.

.Net Core and Kestrel will mitigate that to a degree which is why this is even possible.

ST needs to continue innovating on its products to stay competitive in the market.

All of these factors are inherently at odds with one another. One has to keep up with the tools that are being provided, must keep the product stable, must innovate to retain and attract customers, must open up new markets, and must keep existing installations stable.

ST must delicately balance these elements. I think .net core represents a good way to do this in a way that reduces risk for its current clients. My guess is that a large chunk of the code did not have to be rewritten to make this move.

I had to double the size of my SM server for the memory requirements of the latest major release. I am excited that Linux is less expensive to run than is Windows and I might be able to get my server cost back under control with this move. I have been happy with the performance and stability of my other .Net Core Linux-hosted applications.

Hi,

We are eagerly awaiting the new version of the SmarterMail mail service written with the .Net Core 7 codebase. 

We would like to know if it's possible to automatically set up IIS virtual directories and SSL installations for all domains (e.g., mail.domain, webmail.domain.com, and autodiscover.domain.com). 

Additionally, when we inquired about whether services like SMTPs, IMAPs, and POPs would have SNI support, they told us that it's not possible due to some limitations in the Asp.Net 4.7 framework. However, they mentioned that when transitioning to the .NET Core 7 codebase, all these features could be developed. 

We would love to hear if there will be any development on this from your end.