I advise you to go back to the old 8930... The new windows/linux releases, in my humble opinion, are buggy...

I posted on another thread a few days ago about this behavior. The post linked below explains why this behavior occurs. As mentioned there, we are discussing some potential changes that we expect to minimize this kind of bounce message.

I find myself facing a serious problem. There are already dozens of complaints from clients. I need a solution now because if I don't fix the problem I will lose clients.

I understand that the SmarterMail team is trying to do their job as best as possible, but I cannot argue with a client of mine when he tells me that if he sends emails with GMail everything works correctly, but that with SmarterMail he cannot send emails.

What should I do to install the previous version?

Uninstall the current SmarterMail and install the previous one?

What problems can I have if I install a previous version?

I am terrified of installing a previous version and the mail server stopping working, which would be catastrophic for our company.

I ask that someone from the SmarterMail team tell me if it is possible (and safe) to install the previous version, which does not seem to have these problems.

Thank you very much.

Get the 8930 exe file.

Stop the service. Uninstall SM and install 8930.

Done. And dont update to the latest and greatest but wait until someone else took the plunge and reported back.

We cant be beta testers for SM in production environments.

https://www.smartertools.com/SmarterMail/downloads/8930 

We are also facing a lot of delivery issues, encoding issues, corrupt mail issues, since SM is annoucing support for SMTPUTF8.

Until it gets sorted out we should at least have a toggle to disable SMTPUTF8 support announced by SM for incoming mail and to ignore SMTPUTF8 support announced by remote servers.

Thanks

Well, actually our gateways were already supporting SMTPUTF8 since a long time before SM did and were used by other non-SM MTAs to relay mails (using SMTPUTF8) including exchange servers. 

We never had any trouble about it.

The issues started when SM started to support SMTPUTF8 (from prod build 8965) and only occurs with mails from/to SM.

As there is no toggle to disable SMTPUTF8 support in SM, we had to disable SMTPUTF8 on both incoming and outgoing gateways to mitigate the issue. It was this or downgrade SM to 8930.

To be honest, I'm not sure at this point if its' our gateways that does not handle SMTPUTF8 properly.

Still I would be interested to know what our gateways are doing wrong with SMTPUTF8 if they are the source of the issue. This could help up fix the issue at the source.

I'll make an attempt at boiling a highly complicated topic here but the issue kinda revolves around us sending to a gateway successfully via utf8 successfully, which means the message MUST be encoded utf8 forever. Your server now MUST use utf8 to send to everyone else, your server can not choose to use normal encoding anymore, because we signed it with utf8.

Now, if we were talking to a gateway that DIDNT support utf8, we would then choose to not use utf8 for the message and thus the recipients of your gateway would never have the issue down the line.


The change we're making today is that we will only use UTF8 if we have to, which means the recipients have a symbol in their username, which should reduce the frequency of this monumentally as up until our release we didn't even support symbols in usernames.

[Another technical explanation by Andrew as well here, https://portal.smartertools.com/community/a96396/sent-email-error.aspx#146054]

Hello Matt,

Thank you for the feedback.

If I understand correctly, if the outgoing gateway supports SMTPUTF8, the mail content or at least some of the headers will be converted to UTF8 and then signed before being relayed to the gateway ?

Now, when the gateway will deliver it to the final destination and that destination doesn't support SMTPUTF8, it can not "re-encode" the headers as it would break the signing, and then it must send the mail with these headers untouched.

So that means a SMTPUTF8 and signed mail send through a gateway that supports SMTPUTF8 but not the final recipient == big troubles ?

What is the solution, disable SMTPUTF8 completly ? Signing the mails on the gateway and not on SM ?

Kind regards.

Yea you're correct about the scenario, before today's update we were using utf8 for any header that had symbols or special characters. Now we'll go back to using encoded headers (QP & B64) and (now) puny-coded domain names which work without utf8.

We'll have to figure out the scenario still where the message must be utf8 which hasn't even been possible until recently (usernames with special characters). Maybe a global shutoff but this has implications of preventing international users from being created which we just started allowing and preventing the ability to even try to send to others that use special characters which is kind of a bummer. 

Atleast right now, with today's update, the utf8 should be rarely used now so the global shutoff may not be necessary. Not shutting it completely off does still allow the users to atleast attempt deliveries to others with special characters as long as every gateway in the chain supports utf8. Maybe we could use the bounce message as a chance to educate the user why it failed better, but unfortunately in these cases we aren't the ones generating the bounce but maybe we could add some logic that can add a warning if we detect the message requiring utf8 / international support.

SmarterMail support tells me not to downgrade or I may have more problems than I currently have.

I can understand that, but in that case it is mandatory to put a switch to disable SMTPUTF8 until the email sending problems are solved as soon as possible.

I honestly cannot be receiving complaints from customers and tell them to send their emails that are returned through other providers: GMail, Yahoo, ...

If there is already an update, where can I download it?

Miguel,

Here is the latest installer: 

Best regards,

I have read comments that commented that the technical service mentioned performing a downgrade, but in the open ticket that I have for problems with the attachments, they indicate to me that I may have problems if I do it.

I have installed the latest version 8979. I updated last night at 02:30 AM local time so as not to cause problems to my clients. There are very few shipments during the hours elapsed until now, but in the SMTP log I am seeing errors when analyzing the sender's emails:

[2024.08.03] 08:51:11.691 [40.107.103.111][12745984] rsp: 220 secure.monmariola.com

[2024.08.03] 08:51:11.691 [40.107.103.111][12745984] connected at 8/3/2024 8:51:11 AM

[2024.08.03] 08:51:11.691 [40.107.103.111][12745984] Country code: AT

[2024.08.03] 08:51:11.738 [40.107.103.111][12745984] cmd: EHLO EUR03-VI1-obe.outbound.protection.outlook.com

[2024.08.03] 08:51:11.739 [40.107.103.111][12745984] rsp: 250-secure.monmariola.com Hello [40.107.103.111]250-SIZE 139810133250-AUTH LOGIN CRAM-MD5250-STARTTLS250-8BITMIME250-SMTPUTF8250-DSN250 OK

[2024.08.03] 08:51:11.786 [40.107.103.111][12745984] cmd: STARTTLS

[2024.08.03] 08:51:11.786 [40.107.103.111][12745984] rsp: 220 Start TLS negotiation

[2024.08.03] 08:51:11.942 [40.107.103.111][12745984] cmd: EHLO EUR03-VI1-obe.outbound.protection.outlook.com

[2024.08.03] 08:51:11.942 [40.107.103.111][12745984] rsp: 250-secure.monmariola.com Hello [40.107.103.111]250-SIZE 139810133250-AUTH LOGIN CRAM-MD5250-8BITMIME250-SMTPUTF8250-DSN250 OK

[2024.08.03] 08:51:12.012 [40.107.103.111][12745984] cmd: MAIL FROM:<SENDER@DOMAIN.COM> SIZE=855600

[2024.08.03] 08:51:12.012 [40.107.103.111][12745984] senderEmail(1): SENDER@DOMAIN.COM

[2024.08.03] 08:51:12.012 [40.107.103.111][12745984] rsp: 250 OK <SENDER@DOMAIN.COM> Sender ok

[2024.08.03] 08:51:12.012 [40.107.103.111][12745984] Sender accepted. Weight: 0. 

[2024.08.03] 08:51:12.081 [40.107.103.111][12745984] cmd: RCPT TO:<RECIPIENT@DOMAIN.COM>

[2024.08.03] 08:51:12.082 [40.107.103.111][12745984] rsp: 250 OK <RECIPIENT@DOMAIN.COM> Recipient ok

[2024.08.03] 08:51:12.164 [40.107.103.111][12745984] cmd: DATA

[2024.08.03] 08:51:12.164 [40.107.103.111][12745984] Performing PTR host name lookup for 40.107.103.111

[2024.08.03] 08:51:12.175 [40.107.103.111][12745984] PTR host name for 40.107.103.111 resolved as mail-vi1eur03on2111.outbound.protection.outlook.com

[2024.08.03] 08:51:12.176 [40.107.103.111][12745984] rsp: 354 Start mail input; end with <CRLF>.<CRLF>

[2024.08.03] 08:51:12.245 [40.107.103.111][12745984] senderEmail(2): SENDER@DOMAIN.COM parsed using: NAME <SENDER@DOMAIN.COM>

[2024.08.03] 08:51:13.522 [40.107.103.111][12745984] Exception: One or more errors occurred. (Index was out of range. Must be non-negative and less than the size of the collection. (Parameter 'index'))

[2024.08.03]    at System.Threading.Tasks.Task.ThrowIfExceptional(Boolean includeTaskCanceledExceptions)   at System.Threading.Tasks.Task`1.GetResultCore(Boolean waitCompletionNotification)   at SmarterMail.Protocols.SMTP.SMTPSession.DATAAsyncComplete(Boolean success, String errorText)08:51:13.522 [40.107.103.111][12745984] DMARC Results: Errored, Reason: Unknown, Reject? False

[2024.08.03] 08:51:13.522 [40.107.103.111][12745984] rsp: 250 OK

[2024.08.03] 08:51:13.525 [40.107.103.111][12745984] Received message size: 825626 bytes

[2024.08.03] 08:51:13.525 [40.107.103.111][12745984] Successfully wrote to the HDR file. (D:/SmarterMail/Spool/proc/534780172604.hdr)

[2024.08.03] 08:51:13.525 [40.107.103.111][12745984] Data transfer succeeded, writing mail to 534780172604.eml (MessageID: <DBAPR08MB58487B4E38C3FE27A2132233D6BC2@DBAPR08MB5848.eurprd08.prod.outlook.com>)

[2024.08.03] 08:51:13.611 [40.107.103.111][12745984] disconnected at 8/3/2024 8:51:13 AM

The email seems to be sent correctly. I have reviewed the logs saved with version 8972 and there are already similar errors. On the other hand, with the old version that I had installed last week there are no errors.

I know that the Smartermail team solves the problems that occur as soon as possible, but I think that something is not being done well when so many complaints occur.

I hope I don't have any problems this week because today I start my vacation.

Same issues over here. Hopefully this will be resolved soon.A bit pensive about performing latest update to 8979 (currently using 8972) until this has truly been addressed and confirmed as fixed.

Customers are displeased to say the least.

Is this fixed? Can we safely update to version 8993 from 8930 now?

Dont. Wait for the new release. There are still issues with 8993. Outlook is crashing all the time.

Thanks for advice Brian - seems this is been an issue for a while now...

The "MS Outlook Crashing" issue seems to be fixed in the custom build 9000.

I think it (or a little bit newer one...) will be released later today as stable release.