I've restarted the SM service, rebooted the server, re-installed the software.

Something is stopping the spool from working.

Hello! I'm sorry to hear you're having these issues. First, the IIS errors you're seeing look to be unrelated to the spool, and are pretty common to see on a public mail server as hackers/spammers are attempting to scan your environment. That said, the spool not working can have a variety of root causes as well!

If you head over to Security>Antispam do you see any RBL or URIBL lists showing high response times? If so, head over to Settings>General and try setting these DNS servers:

Once implemented test again to see if the spooling process completes as expected. Next, within Security>Antispam>Options you'll find a Proc folder setting which should be disabled unless you're using Declude; what do you see here? 

Lastly, within Manage>Troubleshooting>View Logs what do you see in the Delivery, SMTP, and Error logs?

RBL's & URIBL lists show - under average times.

Changed IP's - still nothing happening with the spool

Proc folder is disabled

Delivery log:

[2021.11.11] 03:28:35.794 [41221778] Error adding message to spool stat tracker: Could not find file 'd:\SmarterMail\Spool\x541221778.eml'.
[2021.11.11]    at System.IO.__Error.WinIOError(Int32 errorCode, String maybeFullPath)
[2021.11.11]    at System.IO.FileStream.Init(String path, FileMode mode, FileAccess access, Int32 rights, Boolean useRights, FileShare share, Int32 bufferSize, FileOptions options, SECURITY_ATTRIBUTES secAttrs, String msgPath, Boolean bFromProxy, Boolean useLongPath, Boolean checkHost)
[2021.11.11]    at System.IO.FileStream..ctor(String path, FileMode mode, FileAccess access, FileShare share, Int32 bufferSize)
[2021.11.11]    at SmarterTools.SmarterMail.Mime.MimeReader.LoadHeader()
[2021.11.11]    at MailService.RelayServer.DeliveryManager.AddToSpoolStatTracker(SpoolMessage spoolMessage)
[2021.11.11] 03:28:35.794 [41221778] Exception: System.IO.FileNotFoundException: Could not find file 'd:\SmarterMail\Spool\x541221778.eml'.
[2021.11.11] File name: 'd:\SmarterMail\Spool\x541221778.eml'
[2021.11.11]    at System.IO.__Error.WinIOError(Int32 errorCode, String maybeFullPath)
[2021.11.11]    at System.IO.FileInfo.get_Length()
[2021.11.11]    at MailService.RelayServer.SpoolMessage.get_Message()
[2021.11.11]    at MailService.RelayServer.DeliveryManager.ViolatesSizeLimit(SpoolMessage spoolMessage)
[2021.11.11]    at MailService.RelayServer.DeliveryManager.ProcessMessage(SpoolMessage spoolMessage, Dictionary`2& timings)
[2021.11.11]    at MailService.RelayServer.DeliveryManager.DeliverMessages()
[2021.11.11] 04:17:10.558 [41216861] ClamD Checks error: No connection could be made because the target machine actively refused it 127.0.0.1:3310 | error
[2021.11.11] 09:41:29.466 [41216861] ClamD Checks error: No connection could be made because the target machine actively refused it 127.0.0.1:3310 | error
[2021.11.11] 09:53:36.122 [41216861] ClamD Checks error: No connection could be made because the target machine actively refused it 127.0.0.1:3310 | error
[2021.11.11] 13:21:53.308 [88657216] Delivery started for System Administrator (via bypass - System event action) at 1:21:53 PM
[2021.11.11] 13:22:41.405 [88657216] Delivery finished for System Administrator at 1:22:41 PM    [id:4688657216]

SMTP log has quite a bit in it.

Quite a few of these entries:

[2021.11.11] 00:09:59.635 [IP Unknown][5792173] Authentication failed because the remote party has closed the transport stream.
[2021.11.11] 00:11:14.653 [IP Unknown][25812570] Unable to read data from the transport connection: An existing connection was forcibly closed by the remote host.
[2021.11.11] 00:12:29.691 [IP Unknown][59599465] Unable to read data from the transport connection: An existing connection was forcibly closed by the remote host.

[2021.11.11] 04:13:12.925 [IP Unknown][30620508] A call to SSPI failed, due to someone connecting with an unsupported TLS version.
[2021.11.11] 04:16:39.765 System.Net.Sockets.SocketException (0x80004005): The requested address is not valid in its context
[2021.11.11]    at System.Net.Sockets.Socket.DoBind(EndPoint endPointSnapshot, SocketAddress socketAddress)
[2021.11.11]    at System.Net.Sockets.Socket.Bind(EndPoint localEP)
[2021.11.11]    at MailService.TcpServerLib.Common.PooledTcpServer.StartListening(IPEndPoint ipEndPoint)
[2021.11.11] 04:22:00.688 [IP Unknown][57858130] Authentication failed because the remote party has closed the transport stream.

[2021.11.11] 12:36:42.566 [87.246.7.245][36906358] connected at 11/11/2021 12:36:42 PM
[2021.11.11] 12:36:42.566 [87.246.7.245][36906358] "421 Server is busy, try again later." response returned.
[2021.11.11] 12:36:42.566 [87.246.7.245][36906358] IP blocked by brute force abuse detection rule
[2021.11.11] 12:36:42.566 [87.246.7.245][36906358] disconnected at 11/11/2021 12:36:42 PM

I have opened a ticket as I need to get this sorted asap.

Many thanks

Looking in the proc folder on the server there are loads of emails in there?

From today, would that suggest that declude is doing something (or not doing something) that it should?

Yes, emails are going into the proc folder even though its disabled in the admin control panel.

Thanks for your follow-up on this. These Declude issues result from this mailconfig.xml file being renamed by our service. We are implementing changes in this area for the future that will maintain and update this file automatically, so there should be no further issues, and the overall operation of Declude will be in better shape! Please see the Declude community post for more information on that. Have a good one!

Thanks Kyle, I did go through the other conversations about declude, but I'm not sure if my issue was the same as I tried the rename and set to read only, etc.

I think my issue was that declude wasn't running as a service (it wouldn't start), so all emails went into the proc folder and never got released to anyone, so effectively there was nothing going into the spool.

Anyway, I'll wait til the next update and try again.

You're very welcome. Happy to help. 

Yes this is what we were seeing as well. We found SmarterMail is renaming/deleting the mailconfig.xml as part of a cleanup, and this prevents Declude from initializing properly, resulting in those messages stalling in the Proc folder since Declude didn't pick them up for processing. In a future update though we will not only not rename/delete the file, but will ensure it is present an updated with the correct details. These fixes will also introduce handling of the domainlist.xml so this is available and updates for Declude as well. If you see this again in the future simply copy the mailconfig.old.xml back into place and start the Declude service back up. Have a good one!