Sandstorm scan pending SMTP spool (for over a day)

Same problem here. I disabled the feature because there were dozen of messages pending without a reason...

I checked with our other UTMs - same problem everywhere! I guess this is everywhere and nobody did really recognize it till now.

I escalated this to Sophos directly. I have a private session scheduled for Friday morning. 

If anybody has found a workaround - please write it here. 

Just FYI - this is what I did in the meantime: 

checked /var/log/sandboxd.log

checked sandbox.sophos.com:443

checked ps aux | grep sandboxd

checked fallback.log

eveythings looking good. My best guess: Sandstorm at AWS is somehow dead for SMTP. Samples are submitted but never getting back and at the same time there seems to be no timeout in the UTM so the mail will be in spool forever if you don´t free em manually. Bad stuff!

Thanks,

Joerg

Update: I got confirmation from Sophos: Sandstorm is broken with UTM. SMTP and HTTP. Sophos is working to fix it with Prio=1. 

We did a lot of research - some alone and some together with Sophos.

a) Sandstorm was broken on Sophos side - it was fixed yesterday night

b) Some utm systems still are affected and cannot recover - the spool remains full of sandbox pending mails - restarting smtpd, sandboxd or whole utm does NOT help.

c) Latest research: Not all systems are affected. Some are affected. On these affected we tried various things - what finally helped was to reinstall from ISO and then apply the latest backup. Now the spool gets cleared again.

d) To find the real causer (completely reinstall is a bit hard imho) it would be very helpful if one of the affected people could flush the postgresql db and check out if the problem goes away. Ofcourse export all your logs first.

Update from Sophos: Causer is identified, fix is already in development.

There are news about the bug ?

Hi Joerg,

Please DM me the case# with Support, I need to monitor the case and monitor the resolution to help our other memebers.

Thanks

Hi,

manual workaround should be applied ONLY by sophos and thus was removed from forum. Please all encountering the problem please let sophos do this.

Thanks

Joerg

Hi,

manual workaround should be applied ONLY by sophos and thus was removed from forum. Please all encountering the problem please let sophos do this.

Thanks

Joerg

Should now be fixed in 9.409 firmware.

The bug is not fixed in 9.409-9

We have about 2 mails a day, they are pending in smtp because of Sandstorm.

Only a manuel release help!

regards peter

I put in a new case on this, got back it is a known issue and there is no fix at this point.  They linked my case to the bug ticket.  Guessing I will eventually get notified when it is fixed.  This has been an issue for us since Sandstorm came out and happens randomly on eMail and web scanning.

Best Regards,

                     Jim

We also had this issue at a few customer. Is there a way Monitoring the SMTP Queue with SNMP ? I made some Research but didnt found a Solution :(

Hi All,

Anyone that faces a similar issue should report it to Sophos Support. The linked JIRA on this issue is NUTM-6651. 

This is identified by this message in the logs: 

[daemon:warning] sandbox_reportd.plx[7347]: [SANDBOX-REPORTD] (DB sync) job id does not exist in postgres, can not update retrieve information for yyyy-yyyyy

There is no fix or workaround to this at present. I will update a workaround as soon as I recieve any further information. 

Thanks for your patience.

Still no fix? Can confirm this at a customer site.

regards

Yes. Problem is there again since more than a week now. You have to check every day for "...sandstorm scan pending..." Mails. Sophos Support confirmed. Have to wait for a new patch. Support told me this patch will be available for 9.4 and 9.5 systems. 

Hi, what did the trick for us: Clear all sandbox scan pending from smtp spool. login via console. restart services sandboxd and sandbox_reportd. after that, restart sandboxd and sandbox_reoprtd again. Don´t ask why, I really don´t know, but thats how it worked for me. I see successful sandbox activity again. Maybe you only need this trick when using a cluster because at our site rolling restart of the cluster did not help. Maybe something was transferred in the switching process which caused the sandboxd and reoprtd not to fully re-initialize. So what you normally may expect from a rolling restart may not apply and that is why the manual restart of these services MAY indeed be the cure. 

Hi,

I just came across the problem today when I had an accidential look at SMTP Spool on our SG330 Active/Passive cluster running 9.413-4. We have 24 mails in there with "Sandstorm scan pending" dating back up to a week. How is the progress with solving the problem?

Thanks
Daniel

Daniel, did you try Joerg's solution above?  If that didn't resolve it, it's definitely time to get Sophos Support involved.  I'm not seeing this.

Cheers - Bob