I think I will be updating an on premise installation at a small client of mine (only 19 users...) within the week, and this will be my first field test...

Thanks Gabriele! Please let us know if you run into any trouble or have any questions along the way.

Big  problems with calendar with MX time and US time.  

All the events created in CST time (US) were moved one hour ahead. 

Meaning an event already created at 10 am CST, was moved to 11 am.

And now, all the events created in MX time are shown one hour earlier than when created.  It is very urgent to solve this... 

I create an event at 9 am MX time (Monterrey, Guadalajara, Monterrey) and when shown in the calendar it shows at 8 am.  If I click on the event it shows the event at 8 am.  If I manually change the time to 9 am again, it does not do anything. The event is kept at 8 am.  If I move the event (drag it with my mouse) from 8 am to 9 am in the calendar, it immediately goes back to 8 am.  

We're going to try an update this evening. Everyone is VERY excited for the new features and fixes.

11 domains / 150+ users.

Fingers and toes crossed.

Thanks Team Smarter Tools!

Having issue with webmail view being blank in Inbox view on mobile phone after upgrade? Turn the phone side ways and you can see the email list. Turn the phone normal and email list turns to blank white screen with just the menus showing.

Google Chrome / Samsung S23 Android. Preview pane disabled. Deleted cache in browser and restarted phone. Works with Preview pane turned on.

Thanks for the feedback, everyone! 

Gabriele, Michael, I'm happy to hear you'll be upgrading soon, and I look forward to hearing about your progress! 

Jaime, our developers are working on this now. We will keep you updated on the other thread and support ticket. 

Barry, I was able to get that issue replicated and will get it escalated. In the meantime, you can use your workaround of turning the phone into landscape mode, or you might try connecting to the native Samsung Mail client using EAS or IMAP. 

Thank you everyone!

Kind regards,

Thanks Andrea!

Today I upgraded our production server to 8495 RELEASE (from RC 8489)

Overall my first impresion is good and the NEW SmarterMail is a big step in the right direction of SmarterMail future.


An issue that I already noticed with BETA/RC builds but I was not being able to track down this further - but today I figured out what all such problematic mesasges have in common:Emails with just PDF/fileattachemnt - and an  "empty" messagebody: it is impossible to open the pdf-attachment, impossible to forward the email and impossible to save to file/.eml
Message not downloaded completely says eMClient v9.2.x using EWS-protocol.
Webmail ans EAS is ok, I am able to open the PDF-attachment! But we rely on eMClient/EWS  at our company.

I openening a support-ticket for this issue- could be SmarterMail or eMClient issue.
Because it only affects "empty" emials (just file-attachment/without any further mail/messagecontent) I at first think it could be an SmarterMail EWS-protocol-issue (perhaps having issues with messages without messagetext? But this could even be an eMClient issues - but in the past this was working as expeceted with eMClient/EWS. Just occured/started after upgrading to one of the BETA/RC candidates... and still occures with the Release build 8495 :-(

A second issue:
saving signatures to SmarterMail-server/eMClient-EWS-sync: table-formatting/table heights is not being kept as what i posted into eMClient and saved as signature. Even for this I will open a support-ticket, but I not today - will try to create sample/comparison screenshots tomorrow or the day after tormorrow.
I would love to maintain/store all our signatures on SmarterMail-server/user-account for EWS-syncing, would make it much easier to maintain/makikng updates to all employees signatures.

Regards,
Thomas

As a quick update... 

We plan to release a new build tomorrow with the time zone fix and other changes for various small issues that have been reported. 

Michael, Gabriele: Although we're very eager for you to experience the new build, you may want to wait until tomorrow night for your upgrade - so you can have the latest updates. 

Thomas: We're looking into the issues you've reported and will follow up accordingly. 

Hi Thomas I did some testing on the two issues you reported with eM Client EWS but was not able to reproduce here. Blank emails, emails with only a subject line, emails from external and internal senders without body content, etc all load their attached PDF files as expected. Could you send in an example PDF (on the ticket) you see that with so we can test with the problematic file itself?

I also tested a variety of height/width tables in my signatures and had no issues seeing these reflected in webmail. Can you provide more information about what the signature looks like pre/post save and details on whether there is any other content saved in there as well? Lastly, are you editing the default signature that is synced via EWS or modifying your own? Thanks Thomas!

hi andrea free - > you have written: 

-------------

I just wanted to follow up. We were able to determine a way to reproduce the issue with emails containing only a single attachment. A fix for that will be available in the coming build.

@Andrew: good that you determine a way to reproduce the issue with emails only containing a single attachment and no other content/text at all. And even better that the fix will be included into today´s upcoming build.

So today I do not have to continue struggling arouind with our nasty/annoying emial/attachment issue and I can create sample screenshots for the EWS/signature-sync/saving issue with wrong/different table-content-displaying.


@Kyle: I will create a separate support-ticket forr the signature/table issue
will send you sample screenshots where you can see the difference and Export/.xml of the eMClient-signature that I transferred by copy+paste into a "blank" EWS-synced signature.



one more issue I noticed / not yet reported by support-ticket:

we are using events for our extermal email-archive solution: MailStore
SmarterMail copies all incoing and all outgoing-emials to jourmal@xxxxxxxxxx.de
(General/Events: Incoming and Outgoing: Add Recipient: journal@xxxxxxxxxx.de )

Delivery logs contains many lines like this:
[2023.04.06] 00:11:01.399 Forwarding to 'journal@xxxxxxxxxx.de' is not allowed. User 'xxxx.xxxxxx@xxxxxxxxxx.de' allow_mail_forwarding is False.
[2023.04.06] 00:43:31.095 Forwarding to 'journal@xxxxxxxxxx.de is not allowed. User 'xxxx.xxxxxx@xxxxxxxxxx.de' allow_mail_forwarding is False.
[2023.04.06] 01:14:45.747 Forwarding to 'journal@xxxxxxxxxx.de' is not allowed. User 'xxxx.xxxxxx@xxxxxxxxxx.de' allow_mail_forwarding is False.
[2023.04.06] 01:38:46.244 Forwarding to 'journal@xxxxxxxxxx.de' is not allowed. User 'xxxx.xxxxxx@xxxxxxxxxx.de' allow_mail_forwarding is False.
[2023.04.06] 01:55:47.683 Forwarding to 'journal@xxxxxxxxxx.de' is not allowed. User 'xxxx.xxxxxx@xxxxxxxxxx.de' allow_mail_forwarding is False.

and sometimes the user gets a system message about forwarding to journal@...... not being allowed.
But not for each emial that is incoming or that is outgoing - just rarely our users see such an error/failure message.

Regards,
Thomas

Thomas,

I just finished testing signature synchronization between SmarterMail and eM Client over EWS, and I did find a couple things worth mentioning.

The first thing I noticed is the table widths. It appears that eM Client defaults to using percentages for table and column widths. As a result, when viewed in the signature edit modal in SmarterMail, tables defined in eM Client will tend to appear to be narrower. To work around this, when editing a signature in eM Client, right click on any tables and select the Table > Properties menu option. In the Table Properties section, make sure Pixels is selected instead of Percent.

The other thing I noticed has to do with adjusting the border width. This is do to a difference in how borders are defined in SmarterMail and eM Client; eM Client uses the border attribute while SmarterMail uses CSS based border styles. Due to current HTML standards, the CSS based border styles override the border attribute used by eM Client. We are looking into possible changes that may make this behavior a little easier to work with.

I also tested syncing signatures from SmarterMail to EWS, but I didn't notice any issues with creating a signature in SmarterMail and syncing it to eM Client. In that case, all styles appeared to sync correctly in my tests.

@Andrew: many thanks for this update concerning some "differences" between eMClient and SmarterMail signatures.Due to the fact that you working with eMClient together in kind of a partnership I am sure you will find a way to make this better or perfect!


I created a separate support-ticket for this eMClient/EWS-synced-signatures issues
I uploaded my .html saved eMClient signature - so you can play around with it.

We did the way eMClient marking, copy and paste into the EWS-synced-signature, because we created our signatures with eMClient - and we like the simple/intuitive what-you-see-is-what-you-get editing. There are some differences, spaces/distances between textlines - and the table with our company/remote-branches address looks kind of different - even if added to new emails as EWS-synced-signature.

It would be nice to have a way to "import" and "export" signatures in SmarterMail, so that we can import it and modify it a little bit to users/employee needs - nut all can be done with the user-variables/user-values.

We did not want to redesign each signature from scratch for each user in SmarterMail. :-)
We tried in the past signature creation in SmarterMail - but it looks way better if designed/created with eMClient - and it has Save(Export) and Import of the signature-.html-file :-)

Regards,
Thomas

Hey Thomas good afternoon! I just wanted to confirm QC has finished up on fixes for the signature issues and this is now resolved. We'll have updates on other issues soon!

Hi Thomas, 

For the issue you reported about Forwarding is not allowed... 

In this new build, we fixed some issues related to automated forwarding. In older builds, even if an admin had disabled automated forwarding for domains or users, users could use the events or content filters to work around that limitation. In the new release, if automated forwarded is disabled for the user or domain, Content Filter > Forward message and Event Action > Add Recipient will not function (since these are essentially automated forwards). Users should be prevented from adding these new forwards, and existing forwards that already exist will be bounced. 

If you want to give your users this ability, you'll just need to go to Domain Settings > Accounts and edit the user. Then, on the Forwarding card, enable "Allow automated forwarding". At the domain level, this option can be found on the domain's Features card > Automated Forwarding. 

I hope this helps! 

Build 8496 has been released! I believe this contains fixes for all of the issues that had been reported on Build 8495 thus far. 

New thread available here

Thank you everyone for your feedback.

@Kyle and @Andrew: emails containing just one single file/PDF-attachment issue is fixed in build 8496
Thank you, concerning signature syncing/displaying differently thank you for your coments/analyzing - I will test and play around and try updateing/redesign my signature and see what happens.


@Andrea: automatic forwarding (for external journaling/archiving purpose):
Thank you for your explanations concerning the new/fixed way how to achieve this.
For our external MailStore archive now I had to enable the "automatic forwarding" for all users - but I am not really happy with this new situation becaurse of the side-effect is that users could modify/add forwarding settings on their own! :-(  I would expect that the "Global" and "Domain-Events" setup at SmarterMail should work independently of the "allowing automatic forwarding" setting.

Events with Automated forwarding setup by admin/domian-admin should always work.
Our users should not have settings for configuration/changing the forwarding settings or adding email-recipients at all. For example we had users that entered/added their private email-adress to receive all of their emials even at there private address. This is not allowed at all - but we still need to copy all emails send in copy to our jornal-user-account for the external Mailarchive "MailStore". Right now we are forced to open the user-settings/configuration just for getting our Mailarchive "back to work" as it did before :-(

Regards,

Thomas