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 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

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

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.