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

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

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