Back to Community Threads

1

SmarterMail Build 8762: Internal Mails won't be delivered

Problem reported by Stefan Mössner - 12/30/2023 at 3:10 AM

Resolved

Hello all,

yesterday, I updated SmarterMail to build 8762. And since then internal mails won't be delivered.

Today, I restarted the mailserver service and the delivery worked. But just for a short time. After about 2 hours the delivery of internal mails doesn't work any more. In the delivery log I found the following entries:

09:16:13.838 Relay server stopped at 30.12.2023 09:16:13
09:17:06.341 Delivery server started at 30.12.2023 09:17:06
09:20:29.161 Relay server stopped at 30.12.2023 09:20:29
09:20:46.085 Delivery server started at 30.12.2023 09:20:46

In the SMTP log I these entries with the same timestamps:

Binding(2) Exception: System.Net.Sockets.SocketException (10048): Normalerweise darf jede Socketadresse (Protokoll, Netzwerkadresse oder Anschluss) nur jeweils einmal verwendet werden.

This is strange. I don't have other programs running using the port 25 for SMTP. And I don't understand why this happens about two hours after restarting SmarterMail.

I use SmarterMail Free Edition on a Windows 10 Professional 22H2 system.

I wish you all a happy new year.

Kind Regards.

21 Replies

Reply to Thread

0

Stefan Mössner Replied

12/30/2023 at 3:20 AM

I've gone back to build 8755 which worked without issues before updating to build 8762. I will see if this is still the case now.

0

Stefan Mössner Replied

12/30/2023 at 7:43 AM

Reverting back to build 8755 solved the issue with getting internal mails.

0

Andrea Free Replied

1/2/2024 at 12:24 PM

Employee Post

Hi Stefan,

I started a support ticket with you so we can evaluate this issue directly.

Kind regards,

Andrea Free SmarterTools Inc. 877-357-6278 www.smartertools.com

0

Stefan Mössner Replied

1/2/2024 at 12:45 PM

With internal mails I mean mails sended by SMTP from internal systems within the same domain. Sending and receiving mails to or from external domains was working.

0

Stefan Mössner Replied

1/5/2024 at 12:10 AM

This is a known issue and is under investigation of SmarterTools. We should wait for a new build until this is described in the release notes. In the build 8768 (Jan 3, 2024) there's no description regarding a solution of this issue.

0

Stefan Mössner Replied

1/11/2024 at 12:36 AM

When will this issue be resolved? With the next build release today?

0

Stefan Mössner Replied

1/12/2024 at 12:34 AM

It doesn't look like build 8776 is solving the issue, right?

1

Sébastien Riccio Replied

1/14/2024 at 3:07 AM

Hello. I upgraded from 8664 straight to 8776. I haven't noticed any issue with sending internal mails through SMTP. But maybe I should do some tests to be sure it's working as it should...

EDIT: The only log entries I see about delivery relay servers are these:

[2024.01.12] 00:29:07.368 Relay server stopped at 12.01.2024 00:29:07

[2024.01.12] 00:36:37.346 Delivery server started at 12.01.2024 00:36:37

The time/date correspond to the moment I did the upgrade. There was no other occurrence since the upgrade.

Sébastien Riccio System & Network Admin https://swisscenter.com

0

Stefan Mössner Replied

1/14/2024 at 6:00 AM

How long do you have the update running? In my case the issue started 2 hours after restarting SmarterMail.

EDIT: I see that you updated on 12.01.2024. This is great. So I will try the update today and will Report.

0

Sébastien Riccio Replied

1/14/2024 at 6:21 AM

Hello, yes I updated the night 11->12 january. It's seems to be running without problems since the restart after the upgrade.

Sébastien Riccio System & Network Admin https://swisscenter.com

0

Stefan Mössner Replied

1/14/2024 at 7:30 AM

I updated now to build 8776 but this time I get the error regarding the SMTP port immediately in the SMTP log file:

15:22:38.471 smtp started at 14.01.2024 15:22:38
15:22:38.481 [x.x.x.x:25] Binding(2) Exception: System.Net.Sockets.SocketException (10048): Normalerweise darf jede Socketadresse (Protokoll, Netzwerkadresse oder Anschluss) nur jeweils einmal verwendet werden.
   at System.Net.Sockets.Socket.UpdateStatusAfterSocketErrorAndThrowException(SocketError error, Boolean disconnectOnFailure, String callerName)
   at System.Net.Sockets.Socket.DoBind(EndPoint endPointSnapshot, SocketAddress socketAddress)
   at System.Net.Sockets.Socket.Bind(EndPoint localEP)
   at SmarterMail.Protocols.Common.PooledTcpServer.StartListening(IPEndPoint ipEndPoint, db_system_binding_port bindingPort)

So I reverted back to build 8755 again and everything is fine.

0

Brian Bjerring-Jensen Replied

1/14/2024 at 9:10 AM

did you reboot or restarted the smartermail server/service?

0

Sébastien Riccio Replied

1/14/2024 at 10:16 AM

It looks like something (another process) is already listening on port 25 of x.x.x.x IP address, but that would be strange.

Or maybe you have for some reason two port bindings configured in SmarterMail that uses the same IP:Port but that would also be strange.

Sébastien Riccio System & Network Admin https://swisscenter.com

1

Stefan Mössner Replied

1/14/2024 at 11:32 AM

The mail service is stopping and starting when you install SmarteMail. So there's no need to restart the server or the service.

No, there's no other process already listening on port 25. With build 8755 and earlier there's no such issue. And Andrea wrote me some time ago that this issue is happening to other customers, too. So this is under investigation by SmarterMail. And we should wait until it's written in the release notes.

I thought, that Sébastien had the the same issue when he wrote that he doesn't have the issue after updating to build 8776. So I tried it once again.

With build 8755 everything is running fine again.

1

Stefan Mössner Replied

1/16/2024 at 5:36 AM

This morning I updated again to 8776 with the following procedure that Andrea from SmarterTools sent to me:

Stop the SmarterMail IIS site and application pool. This allows connected web clients to gracefully disconnect from the server and thereby the SmarterMail service in turn.
Stop the SmarterMail system service, then uninstall SmarterMail.
Install the new build of SmarterMail using the same directory used previously.
While the installer is copying new files; go ahead and start your SmarterMail application pool and IIS site.

I know this described upgrade process from older releases but at one day this wasn't needed anymore. So I always started the installer without stopping IIS site, application pool and the mail service before updating.

For the moment it looks like eyerything is working fine.

0

Stefan Mössner Replied

2/15/2024 at 11:34 AM

This issue still resists. I found out that stopping the MailService service sometimes won't terminate the MailService.exe process. This is why I get errors like this when only restarting the MailService service:

15:22:38.471 smtp started at 14.01.2024 15:22:38
15:22:38.481 [x.x.x.x:25] Binding(2) Exception: System.Net.Sockets.SocketException (10048): Normalerweise darf jede Socketadresse (Protokoll, Netzwerkadresse oder Anschluss) nur jeweils einmal verwendet werden.
   at System.Net.Sockets.Socket.UpdateStatusAfterSocketErrorAndThrowException(SocketError error, Boolean disconnectOnFailure, String callerName)
   at System.Net.Sockets.Socket.DoBind(EndPoint endPointSnapshot, SocketAddress socketAddress)
   at System.Net.Sockets.Socket.Bind(EndPoint localEP)
   at SmarterMail.Protocols.Common.PooledTcpServer.StartListening(IPEndPoint ipEndPoint, db_system_binding_port bindingPort)

So, after stopping the MailService service you have to check the processes in the taskmanager and maybe terminate the MailService.exe process first before starting the MailService service again. This prevents you from this error.

0

Stefan Mössner Replied

3/1/2024 at 4:57 AM

This issue still resists. Stopping the MailService service won't stop the MailService.exe process! I have SmarterMail build 8825 running.

2

Sébastien Riccio Replied

3/1/2024 at 5:05 AM

We noticed here that when the service is considered stopped in the service manager, it still needs 2-3 minutes for the process to really exit and disappear from running processes.

During that time you can see the process memory usage to fall more or less slowly, and then the process to switch to "suspended" for a few seconds and then come back running and finally disappear...

I guess that in that condition doing a restart might be problematic as it would start a secondary process while the original one is still running... and therefore probably triggering the port binding issues as the port is still hold by the previous process.

For a restart or during upgrades, we now always stop it and wait there is no more trace of it before starting it again or starting the upgrade.

Sébastien Riccio System & Network Admin https://swisscenter.com

0

Stefan Mössner Replied

3/1/2024 at 9:37 AM

Thank you for this interesting fact. I will have a look the next time I have to restart the service if I can see the same behavior. For me this a new behavior. I never seen this before with older builds of SmarterMail.

1

Stefan Mössner Replied

3/7/2024 at 10:27 PM

I can confirm the behavior of stopping the MailService service. After stopping the service the process MailService.exe is still running for some more minutes before the it's stopped.

0

Stefan Mössner Replied

3/29/2024 at 7:30 AM

Could this behavior be stopped? It's strange when I stop the service and Windows says the service is stopped but the process is still running for some more minutes? I don't know any other software that shows this behavior! And this didn't happen with earlier versions of SmarterMail.

Back to Community Threads

Please leave this box unchecked

Reply to Thread

Related Knowledge Base Articles