This discussion has been locked.
You can no longer post new replies to this discussion. If you have a question you can start a new discussion

Sandstorm scan pending SMTP spool (for over a day)

Today I saw there are 3 mails in SMTP spool. Two of them are from yesterday and 1 from the day before yesterday. All 3 have status Sandstorm scan pending.
What can be wrong that these mails are still in the spool?

They look pretty legit (sender and recipient send each other more often and files and mails look like others), so I can release those mails, but that doesn't really solve the (possible) problem. Other mails have also been scanned and are delivered shortly after.



This thread was automatically locked due to age.
Parents
  • 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

  • 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

    Sachin Gurung
    Team Lead | Sophos Technical Support
    Knowledge Base  |  @SophosSupport  |  Video tutorials
    Remember to like a post.  If a post (on a question thread) solves your question use the 'This helped me' link.

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

    Sachin Gurung
    Team Lead | Sophos Technical Support
    Knowledge Base  |  @SophosSupport  |  Video tutorials
    Remember to like a post.  If a post (on a question thread) solves your question use the 'This helped me' link.

Reply
  • 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.

    Sachin Gurung
    Team Lead | Sophos Technical Support
    Knowledge Base  |  @SophosSupport  |  Video tutorials
    Remember to like a post.  If a post (on a question thread) solves your question use the 'This helped me' link.

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

     
    Sophos UTM Community Moderator
    Sophos Certified Architect - UTM
    Sophos Certified Engineer - XG
    Gold Solution Partner since 2005
    MediaSoft, Inc. USA