I agree, sounds all like some major issues that should be addressed/solved asap.
Glad that I did not upgrade to build 7565 yet - we are still running build 7544 at our production server.
I expected some issues because of build 7565 being the first release including/introducing the server-side language-support. In addition it looks like some other main-areas/tasks of a mailserver are affected.

The process of "quality control" for main functions needs to become much better.
Probably SmarterTools should have two download-branches for SmarterMail (and perhaps their other products): a stable branch - and a beta branch.
Important is: First release your new versions inside the beta branch - and if the version is in developer´s eyes stable and good then move exactly this version into the stable branch. This could make live much easier for us as system-administrators and paying customers. So beta-branch could be updated weekly or each second week - and stable branch probably only one time each month or just every two month, just in case a build is "really good and kind of stable" for the production usuage.

I am quite sure that just working with a small and closed group of external beta-testers does not work at i´s best - as we can see what is going wrong with your public-releaseversions. I know it is very difficult and complicated to make your product stable and release-ready, for example concerning language-support and encoding-issues. You should stick with internal/closed external beta-testers - but just ad another step in between on the way to new public-release versions with kind of a puiblic-beta-branch to download.

and in case of any "confirmed issues" in public-releases:
Please place kind of a note/hint at the download-page so that your customers are informed what probably is not working yet as expeceted.

Same here, we do not install production builds until I see no complaints etc. in the community :). We didnt do this latest build simply because I saw the notes about the language changes and knew that was going to cause issues.

I do agree though on multiple branches... Like a nightly, beta and stable branch for us to all play with and report on. What I really wish ST had was a public (for customers only) tracker so that we can see known issues in the product that others have reported, with categories like "New/Unconfirmed" and "Known/Confirmed" etc. so we know what issues are known, which ones customers are reporting that the developers are looking into. We have several products that we use that do this and it makes life easier.

This way, I can login, see oh, devs have already confirmed a bug that I was going to report, no need to submit a ticket then.

Can someone from you which are on 7565 build on main SM instance with outgoing gateways also running on SM with this build version check if bounces are working correctly?

I still like SmarterMail as a Mailserver, I really prefer it - SmarterMail could be better than Exchange and I would love to continue using it at our company - but these often unstable public-release-builds are really a big pain. It is not easy at all for me to stick to SmarterTools... It could be that we are forced to switch to Microsoft 365 subscriptions, most because we need more and more addional Microsoft Office licenses and probably Microsoft Teams would be nice to use and even "ExchangeOnline" will already be included without additional/extra fees. So then it will be very, very diffucult for me to argue why keeping SmarterMail as our local mailserver that needs additonal payment (Support&Maintenance, MAPI/EWS and EAS.). Microsoft Outlook in addition with the 'original Exchange-Server' has probably not to deal with so many nasty/fatal issues at all - it is just working - and that is what business users want and expect.

The SmarterTools quality management really needs to be much, much better - you will never discover all bugs before a new public release. I know that issues/bugs in software will always exist - that is the real live. But with your official/public releases/downloads with often nasty issues in it is not the best reputation for your company and software products. Please work at this and find a good solution for the near future.

I'd also add that I wish ST didnt close tickets after referring them to development. We get a response like...

ST is the only software developer we work with that does this. Other companies, the ticket is put into a status like "Hold Development" etc. and then we get a response letting us know that the issue has been resolved in x.x.x.x build with a download link.

This is always going to be a challenge. SmarterTools is much smaller than Microsoft and Google, which have excellent competing products. I've used SmarterMail for a long time and have occasionally had problems with it, but I find it to mostly be good quality, and I appreciate their responsive support and honesty. There will always be bugs.

SmarterTools must strike a difficult balance between adding new functionality and ensuring quality. If they don't change anything and just keep fixing bugs, the quality will be phenomenal, but there will be no new functionality, and they will fall behind. If they add too much functionality too quickly, it will make for exciting product marketing, but the lack of quality will quickly alienate their customers. I'm not saying they have struck the right balance - just saying that it's an inherent challenge that any product faces.

I usually wait a couple of weeks before installing a new release and lurk on this forum to see if there are any problems reported before I upgrade. Last release was one of the rare occasions that I did not follow that policy, because there was a bug fix that I needed. Now I've been listed as a spammer and my customers are complaining. I've spent the past week fighting to get delisted.

For me, their recent adoption of Exchange "clone" functionality was too late, and I'm not promoting email hosting services any more, though I hope that this functionality opens up new avenues for others. It's too competitive and too much of a commodity. All of my email hosting customers have long since moved to Google or Microsoft 365 for email. Today, I primarily keep the email server because I am a developer of web-based software and email is integral to its operations, so having this level of control of the server is very desirable, and having a good reputation means I have fewer delivery problems. I'm a very heavy user of plus addressing so I can create infinite email addresses for testing my software.

Now, there is room for innovation in this space. Look at Basecamp's new Hey email service as an example of a new email product.

Yes I agree about the ticket closing thing. I was surprised when they started to do this.
It's a bit a problem because then you can't easily identify which one of the closed tickets are really closed/fixed.

We probably have some closed tickets that were supposed to be adressed by developpement but never did and are now forgotten in page 3 or 4 of our tickets list.

We are still on 7516 too scared to update at the moment, we're awaiting a release that we can move to without it further reducing our customer base.

Hello Ronald,

Part of the issues, the retries after 5xx errors, yes, seems good.

But there are still issues introduced by the server-side special folders translation, with outlook.

Added my test results there:

So for us, we still have to stick to 7544 (before the translations) or it will start to mess our outlook/imap users mailboxes 

Well, it probably already did create some duplicate folders the time we were running the "pre-latest" build and we'll have to check every user mailboxes (20k) for duplicate folders.

Kind regards

Ill take iron-clad quality over new features...  I am sure many here most likely feel the same. I do understand though, the dilemma of stability vs. shinny things.

This new folder translation build I knew was going to be problematic, so we will hold off on updating for a while. Nice to see the random Outlook MAPI restart issue fixed though!

@echoDreamz Yes, that is a very unique way of working with tickets and we`ve found it problematic as well. Tickets should never be closed until there is a definite acceptable solution or decision (e.g. bug cannot/will not be fixed).

We would be happy that SmarterMail has two branches. One considered stable, with only bug fixes and small non possibly breaking changes.

And a beta one with also the bug fixes but where bigger changes are also applied like for example recently the server-side folder translations, the changes in the language detection  (pop up thing), and the other features that can be problematic to introduce in production without taking the time to test them througly first.

There are often bug fixes in new builds that we want to apply as soon as possible but they come often with other changes that makes us hesitate to apply before intensive testing.

This has been recently demonstrating with latest changes...

Also as our tickets are getting closed before the issues are fixed or features added, I also like the idea to have an issue tracker where we can report/ask features and follow the progress. As someone sait It also can serve as a source for known/confirmed issues so they are not reported multiple times.

What ST thinks about it ?

Hello,

Please we really need a build today that contains these fixes:

But where folder translation for IMAP can be disabled (because of the remaining issues)

We had installed the latest build to apply these fixes and communicated with our users about it, but then we had to rollback to 7544 because of the IMAP folder issues.

Now our customers are complaining that the issues we announced as fixed are back and ask us if we are joking with them...

We do not know what to answer.

Thank you!

Hi all,

We made exactly the same steps as Sébastien. We upgraded to the last version to patch important bugs and we where forced to roll back to 7544 because we are (and our customers) are French Canadian, and the new language feature added in the two last versions broke IMAP folders and sync stop... Result:  the support dept is overloaded of calls and support tickets of irritated customers who have problems with their emails AGAIN.

@Smartertools team : Please help us to keep the last customers wishing to sticks with us and help us to get us back on track by QUICKLY bringing us a patched version.

I'm glad I'm we are not alone in this situation (not that I wish that you have trouble heh) but I feel like I'm always complaining about issues and ranting in this forum and I don't like the felling to be the one always complaining...

EDIT: Here we go, today we lost 3 big customers because of what happened recently with the imap folders issue and the bug fixes we applied and then re-introduced because we had to revert to 7544.

They requested their domain name transfer code to migrate to another service provider because we're not serious enough with our mail service. They migrated everything related to their domain, not only the mail service.

We can't work like this anymore.

This is absolutely crazy seeing all the issues reported with Smartermail in a production environment. We are still having many issues with Outlook iMap and EAS. Why is Smartertools repeatedly releasing BETA builds of software for production and causing huge headaches for everyone involved. I have many issues right now and would like to update but I'm too afraid to do so after the last update and users not being able to get emails from a certain date on. I had to roll back to version 7496 which I knew was somewhat stable (Against SmarterTools advise, but it was better than the garbage released). 

I see a few on here stating they are using version 7544, can you guys advise if this version runs a little bit stable and is ok to run in production? I'm asking users btw, not SmarterTools staff as I have lost all confidence in this software group. 

I'm on a last straw here before being forced by upper Management to switch to Microsoft Exchange for reliability.

We are on 7544 and running without any major issues, only a few minorly annoying ones, like disk space usage on domains not updating automatically and Outlook randomly restarting with MAPI (this has been fixed, but we will not be upgrading until we see all other major issues with IMAP etc. being reported are solved).

I'd consider 7544 solid enough.

Yes we went back to 7544 after attempting to use latest builds as it's the less problematic version at the moment.

But it's not satisfying as we first updated to latest to have these fix:

So now we announced to our customers these were fixed but then rolled back because of the IMAP carnage.

So you can immagine we now have customers asking us why we unfixed the fixed issues and if we are joking with them... :'(

Also I don't understand why ST is not announcing these known issues with IMAP in the download page or at least the changelog. 

It's better to let the customers download builds that are messing with IMAP folders (and create folder duplicates when using outlook and other languages than english) and leave the system admins having to discover the issue and clean the mess it generated on their multiple thousands of affected customers accounts.

Until it's fixed anyhow, a serious company would at least annonunce this important known issue to avoid create more issues and support for the people updating to latest builds.

I really don't understand this...

You're not wrong, 2020 has it amount of surprise, and it's not finished yet.

If it is a slight positive, we lost a customer to 365 and they have gone down twice recently, they are reported to being a little miffed

Ron,

We've had Robert and Matt both spend countless hours on our system, weekends, even late nights working on issues. So they def put in the work :).

I am not sure what is up with all the bugs though lately.

I'm sure ST team works hard to resolve the issues.

Still, I sometimes don't understand how the team handle these serious issues.

I mean it's not like a correctly working IMAP and trustworthy web calendar are critical for a mail server sold like an exchange alternative.

Some acknowledgement about the issue, information about the progress with some kind of ETA and avoiding customer to continue to download and install broken builds on their business servers would be welcome.

I mean it's not like we're asking a typo fix in a menu. We're talking about failure in the most used parts of the product here.

I mean they even did not officially suggested affected customers here to roll back to a previous stable version before it does more mess in the user folders. Or did they?

SmarterTools has at least a few really, really good employees in development and support, that really work hard and together with customers to solve issues. But the reputation of SmarterTools and their products is getting more and more worse... looks like public releases are more like beta or even alpha software.

Concerning internal language/translation-support SmarterTools stated some month ago, that this feature cannot be implemented before the public MAPI-release, because it requires some fundamental changes. But then after now several month they release a public build with this feature inplemented - but probably not very well tested by customers.

Since yesterday we are running custom build 7577, there it looks are mail-delivery issues solved - but concerning folder translation there are probably still issues... we are glad that we do not have many IMAP-protocol users/accounts... we prefer ussing EWS (eMClient) and EAS (smartphones/Outlook) and a small/limited Outlook/MAPI-"test"group. And until IMAP issues should be solved we wiil try to avoid switching too many user-accounts to German language.

What is really important: public release should be almost stable and reliable.
So most changes and especially implementation of new features should always be made available as beta/custom-builds first.... and only if such a build is stable (= proven by customers) then release this to the puiblic-release downloads.

Probably SmarterTools should work/release alpha builds (=only for SmarterTools own/internal testing), limited/closed beta builds (=closed circle of beta-testers, chosen by SmarterTools), beta-builds (for customers), and public-relase-builds (and at least these should be almoist stable).

If I remember right SmarterTools stated that is is now easier to add additional features, without breaking other functions... and even supply/implement hotfixes - and that was one more reason why they do not use version-numbers anymore (v15, v16) and only using incementing build-numbers (since v17 only build xxxx).

I know that release notes include many issues mentioned as fixed/changed/added, so we can see that they are really workikng on their product - but otherwise it shows that their products have again and again issues... for example different variations of calendar/appointmens-issues like not syncing over all protocols, or issues with shifting/changing times/dates during syncing. It looks liks some issues are never finally, completely solved... some issues are coming back / occure again in some new variations a few builds later.

Please work on a stable public release build branch, and add at least a second beta-branch.
It should be kind of a warning to SmarterTools that some users are stating here, that they do not trust your public releases anymore - and that they will often avoid updating and better wait what brave customers are reporting, what works and what is broken in the public build.

I am still fighting at our company and I am the one still pro SmarterTools products at our company, but this is getting more and more difficult to explain, why we should stick with SmarterTools products.

It looks like SmarterTools removed/pulled build 7573, it is not available anymore for public download,

latest public release download is now build 7544 - that is the build before introducing the folder-language-translation-feature, that currently still has some issues.

Hi everyone, 

Just wanted to reply here and tell everyone that we did remove the last 2 Builds from our Downloads page. We generally remove Builds that are problematic for a large number of users, or that have issues that may affect a large number of users, rather than put out a release and mention any new issues that are found. In addition, we're holding back this week's release until these new issues are resolved, and will be reaching out to the few customers who have tickets with us once a fix is available. If you don't have a ticket in yet, you may want to submit one so that, once we have a fixed version available, we can work together to ensure the issue is, in fact, resolved.

As for the other comments, we appreciate the support and the desire to help us improve. Some good suggestions, to be sure.

@Andrea: right decision to remove the last 2 builds from your downloads page.

I updated our production server to custom build 7577 and I did not try out switching a user/account language away from English yet (to probably German) . Will try your serverside-folder-translation-feature first with a test-useraccount during/around this weekend - and then probably create a support-ticket so that I will receive your upcoming updated/fixed custom builds.

We have a fix for the IMAP and translation issues, including folders with ampersands (&) and foreign characters.  If you would like the custom build link, please create a ticket with support, and they will provide the link.  Note: Some IMAP customer may require a remove and re-add of their accounts based on the clients in order to fix existing folders.

Hello Robert,

That's good news.

We are willingly testing the custom builds on our test environnement and report back the results. We already have a ticket open about the issue but did not receive the download link for the custom build.

Kind regards

Sébastien, see the private message I sent to you

Hi Francis, copy that. Thank you!

Hello everybody!

Is it mandatory to open a ticket to get this new Build or is it possible to have the link here?

I'm asking because I'm already using build 7577, and I'd like to upgrade, but I haven't opened any tickets. Build 7577 was given to us directly from this post:

https://portal.smartertools.com/community/a93590/latest-smartermail-build-7565-doesnt-onor-the-number-of-retries.aspx

@Gabriele: I suppose SmarterTools normally does not like to post custom-build-download-links here at all - so they are asking us for opening a support-ticket
If download-link is publicly available many people will download and install it just to always be one of the first users being "up2date" ;) and just installing and probably not giving feedback at all back to SmarterTools, or they will just blaim @SmarterTools in public and community forum, because a custom build does not work as expected.

btw: I know you would report back to ST :-)
But I can respect it as their management dicision normally not to post custom-builds inside their open community forum.

3 hours of SM 7579, no complaints yet...

I have my finger crossed...

@Gabriele and Sébastien : Is the 7579 still without Glitches? Tested MAPI WITH Outlook 365 too?

I'm using Outlook 2016, can't try Outlook 365...

If, if most of SmarterMail deployments are in English speaking countries without need for translation, maybe the software can be temporarily forked so that there is an English only version being moved forward and updated for admins who don't need translation. If introducing multilingual translation adds issues, English oriented deployments should not be made to suffer unnecessarily.

Perhaps v15 ? 

Seriously though, the broken releases are far from funny and MAPI support is still in beta as far as my testing is concerned as functions do not work whilst others trigger high CPU evening against new mailboxes with little data. e.g. It only works in offline cache mode and if you set it to say 3 months you cannot request older items using Outlook or if I search within Outlook and choose the 'search on server' (or whatever it is called) option, CPU goes through the roof on the server until I kill Outlook plus other issues. For this reason, although we are licensed we cannot allow any customers to use MAPI for fear of either killing the server or them hitting too many annoying issues.

I did right several more paragraphs but pulled them for fear of being perceived as too negative. Please just deliver what we all license the product to do, no more, no less.

So, I tested 7579 again with outlook and a user set to french in the webmail

It still creates duplicate folders and use them instead of the correct ones.

I have already reported this previously.

the only change is that on the filesystem the duplicated folders are created with encoded names, previously it was using the spécial chars (accents).

But the problem remains the same. Any user that has his webmail set to french and connects with outlook will see his folders duplicated. I've stopped the test at this point as it's already a serious enough issue that still exists.

Again, please rollback these IMAP translated folders and keep them for a beta branch. We need a stable release with the other bugfixes requested long time ago.

This is so unprofesionnal :(

The custom build should also be shipped with a changelog against the latest release, so we know what to test/expect from it.

EDIT: A really simple way would be, like proposed already, a toggle that disable the translations for IMAP, to have IMAP act like if the user had it set to english. There is no issue with IMAP when the webmail is set to english.

But we do not want to force the users to have their webmail in english so ... 

A simple bool toggle that if enabled tell the IMAP code to use english instead of the webmail language for IMAP.

We could at least use the recent builds that carries other needed bugfixes.

Hi all

Unfortunately I now have the first customer who complained about this. I can't wait until SM is in the office. Could someone send me a PM with the link to SM 7579?

Thanks!

Sandro, 7579 is buggy as previously explained by Sébastien. I have same problems there.

If you have customers who use IMAP in other languages than english, DO NOT move to this version, you will have more customers complains than you have actually!

Thank you, Francis. 

Maybe I have to say that I'm already on 7573 (not 7544). I switched back languages to "English" but the problem reported to me was caused due to an ampersand (&) in a folder name. Robert wrote above that this issue should be fixed with the newer version. 

I even deleted the folder (in webmail; folder is gone in the files too) but the IMAP user (Mac Mail App) doesn't seem to get the folder list delivered correctly. Folder is still there for him in Mac Mail.

Therefore I would have liked to try it. You think it's not worth it?

Hi,

I don't know about the ampersand symbol fix, but if you can live with having your users set to english to avoid the other imap issues, maybe trying 7579 can fix it. It should at least not be worse than 7573.

Kind regards

We fallback with 7544 build and found the calendar not saving, few customers raise the issue. SM Testing team should have a rotation policy because the same tester may be tired retesting code or lose critical bug.  The fresh testing team may have sound understanding & learning capability than the old team.  Building a business very difficult once reaches a bad reputation. I know COVID 19 very stressful years 

SM Team looks policy-level change. rotation of responsibility that will help the fresh mind 

@Binesh, you have a calendar not saving issue since you went back to 7544 ?

Sébastien Riccio  

Calendar not saving issue persists with build 7544 as well.  Noticed several issue latest two release and fall back to build 7544 

Binesh, please start a new thread or open a support ticket for the calendaring issue you are experiencing.

All,

We've sent the information below to a few people, but I figured it would work as a reply here has well. It's regarding internationalization, syncing to clients, changing languages, etc. 

With internationalization support, our goal is to match Exchange's functionality as they are the industry standard for this functionality, and we need Microsoft clients to work the same with SmarterMail. You'll find that if an Exchange user changes their language in Exchange, Outlook IMAP behaves in the same way as it does with SmarterMail: folders are duplicated on the server.

Below is link to a video you can watch that demonstrates this behavior in Exchange and this is because it is a client issue not a server issue.  The client is making calls to make these folders. 

In both Exchange and SmarterMail, if a user changes their webmail language, Outlook IMAP duplicates the folder structure on the server. The only difference you'll find between SmarterMail and Exchange is that, with Exchange, the Outlook client doesn't show the duplicated folders in the folder list, since they are not automatically subscribed. However, once you close outlook and restart the application, you'll see the duplicate folders appear in the Exchange interface and Outlook will begin using those folders instead of the default root folders.

Ultimately, we need the companies who make the clients to address these types of issues because they are the ones making the calls to create the folders, and they shouldn't be. The recommendation at this time is that users should remove their IMAP accounts before changing their webmail language, then add them back. The other option is to change the client to something that works properly.

Finally, we perform these types of tests across all clients and protocols: comparing functionality between Exchange and SmarterMail. Soon, we'll have some tables in our help docs that explain and compare how Exchange and SmarterMail behave across a variety of protocols/clients for both internationalization support and calendar functionality. In the meantime, we have the following Help document that explains the client behavior when a SmarterMail user's webmail language is changed. I'd encourage you to review this for more information: http://help.smartertools.com/SmarterMail/current/Topics/User/LanguageSelection.aspx.

THX Derek for the explanation!

That doesn’t surprise me. I can’t stand outlook! Microsoft, well we won’t even go there. Good to know it’sa client issue. Now please ensure we get a great stable server version of Smartermail :)

Hello Derek

First, thank you for clarifying things around this.

Please, no...On 25k customer accounts, we maybe 100 of them are really using the exchange functionalities through activesync or ews. The other accounts are for a few using POP3, that's maybe also 100 of them, so the remaining 24800 accounts are using standard IMAP on different clients including Outlook in IMAP mode.

If I understand correctly... by willing to copycat exchange behavior including how it (badly?) handle IMAP and special folder translations (that no other server software seems to handle this way) we will have to ask the users of these 24800 mailbox to remove and re-add their account because the language change of the special folder can be badly handled by their mail client and create issues.

Correct me if I'm wrong, but going from 7544 to the latest build, for our IMAP users is like they had changed their language in the webmail (as in 7544 every IMAP folder is in english not depending on their webmail language) and now they will match the webmail language without any action from them and there for can be affected by this forced change.

We can't do this, it will be a support nightmare and we should be able to disable this.

For our ISP usage of the product, IMAP is the main component that should have the less issues/complications, the exchange-like features are concerning a very low user base.

Why not just add a setting to allow the IMAP language to be set/changed independent of the webmail language?  For new mailboxes, you’d set it to the local language but for existing mailboxes, you’d leave it English because of the client issues changing it causes. 

After discussion and further testing, we have decided to completely remove the translation logic from the IMAP protocol. EWS, EAS, and MAPI all have accommodations for folder name translations, while POP and IMAP do not. We had tried to make IMAP work with the translations, but it was causing more problems than it was worth.

Removing the translation logic from IMAP will effectively be reverting the protocol to the same behavior it had before the server-side translation setting was added. Specifically, any folder translations which occur for a POP or IMAP connection will be handled by the client and not by SmarterMail.

Hello Andrew,

Thank you for this information.

I was able to test the custom build 7591 on our testing rig and can confirm IMAP is now acting again like it was before the folder translation changes.

We updated our production server with that build and will report back with the results after 1 day of "real life" usage.

Kind regards

Hello,

I can confirm that build 7591 seems good about the IMAP. No complaints from our customers after 24h, this is a good sign.

After the fixes for the multiple calendar issues we reported, the product should be back in a solid production state.

Thanks a lot for your efforts.