Would be sweet if this was pre-packaged with the Linux flavor needed like 3CX does with their VOIP platform. Eliminates a lot of user variables during setup.

I've installed it on a vanilla Ubuntu Server 22.04.4 LTS (Gnu/Linux 5.15.0-105-generic x86_64) VM, and it works perfectly. SmarterMail will install what it requires to work, like ClamAV, etc. so, as far as I know, there are no package prerequisites in order to get it running. 

I'm happy to hear you are as excited as we are :-) As Derek noted; you won't actually need any prerequisites as our installer will deploy them as necessary, but, we will install and deploy these specifically in addition to the components we include in our install: 

gss-ntlmssp

If you already maintain these on the environment you are installing into you may want to take backups of them before getting started. 

What if I don’t want NTLM?

Thanks. Where in the settings will that be?

My first feature request on the beta: An option to install or not NTLM or anything else that can be done without.

Can the current version of SM be set to not advertise NTLM? (this came up in another thread)

Wait, where did the post I was replying to go?

So, SmarterMail installs the packages it needs, by default, so all is working after an installation. If a particular package is unwanted -- like the gss-ntlmssp package -- you can uninstall it, then make any changes to SmarterMail. For example, changing settings not advertise NTLM.  Just realize that the installer would install NTLM again on the next install / upgrade. So, you'd probably want to make a script to remove it after you perform any upgrades.

In addition, SmarterMail is installed as root, by default. If you want to run SmarterMail as a user, we'll be creating a KB that will have commands to further secure your system.

  

We have prioritized bringing an enterprise Windows experience to Linux with an easy install process that gets customers up and running within minutes. If customers want to further secure their systems and customize how SmarterMail is operating, that will be possible. We'll be highlighting these types of changes and releasing KBs throughout the BETA process.   

Patrick, I asked Derek to replace my post with additional information.  

Thanks Tim. 

The first two questions and suggestion still stand. :)

The installer is intended to get customers up and running with all SmarterMail functionality. This has been our approach on Windows since our inception and is how it will be approached on Linux.

 

If you want to further customize or  secure your mail server beyond our standard install, you would do that with your own commands and scripts. For example, I would hope most customers would use our upcoming KB to switch SmarterMail from running as root to a user etc.

 

NTLM can't be disabled within SmarterMail at the moment but we are planning to make that available before release.

 

Keep in mind, NTLM is required for Exchange interoperability when using migration features within SmarterMail.  The requirement for NTLM is an Exchange restriction, not our restriction.  There are a couple other cases where you will lose functionality if you don't include NTLM. 

We are also working on enhancing our support for Kerberos and other identity providers.  None of this changes the restrictions Microsoft has in place for Exchange though.  

Hope this helps,

Thanks Tim. I have no use whatsoever for Exchange interoperability, Outlook, or any other MS crap. Though I understand there are those that do. I just want a nice functional reliable mail server.

The BETA is now LIVE:

OK, Here's a server related question:

Should the server be set to UTC or my local time zone? I think general consensus is Linux Servers should be set to UTC, and clients set to a local time. It causes my logs to be recorded and changed over in zulu time.

We switched from Arizona to UTC on ours for now, when we moved smartertools.com to linux. I've been noticing that too. It'd be nice if we could optionally translate the logs to local time, though that'd be pretty 'stressful' for the system as we'd have to basicly re-write the logs on the fly depending on who is viewing them.

Thanks Matt. I imagine I'll just get used to it.

You'll get really good at timezone calculations though Patrick! ;-)

Thanks Kyle. Good point! I'll need that for my clearance void times which are stated in zulu.

It is a handy skill to have for sure :-) In a previous life I did support for EMC/OpenText and they almost always ran in Linux environments, whereas the software I actually supported at the time (integrated into these document management systems) was a Windows based application, so timezone conversion was the bane of my existence for a while. 

Related to that, Currently 5/3/34 20:17 Eastern time. The troubleshooting logs page shows the date 5/3/24 but searching the log reveals only results from the 5/4/24 log. (SMTP log for reference.)