Increase in legitimate messages going to the delay queue

Hi Ben,

there are a few things that could be going on.

the first thing to keep in mind.. the delay queue feature requires a 1,000,000 second collection time (approx 10.5 days)

#1 changing the delay settings is not recommended and will skew the way delay queue works.   Ensure that you reset them to defaults.

when you change the stats from On / OFF or Collect this has different.

If you change the delay queue to "off" at any time, this will destroy the database, resulting in a new collection time.. (so it will essentially not work for the next 10.5 days)  It is important to ensure that you only either select "ON or Collect" 

#2 Min and max delay times, ensure these are not changed as there is more going on there than meets the eye.  This is a time range based on several factors.. if you change it from 10 - 60 mins.. to say .. 10 - 30 mins, you will skew the entire rule set.. this may have unwanted results.

#3 delay queue is targeted towards unknown ips.. It sounds like the delay queue got turned off and treated all ips as "new"  

#4 adding the sender / ip or host name to the white list will omit those senders from all checking, including delay queue.   Generally if whitelising a sender does not work the most common reason is that the DATA sender was whitelisted not the MTA sending domain. These are totally different.  

Thanks for the response.  We've had the delay queue set to defaults since the feature came out, so nothing has been changed.  When support directed me to turn it off, it was changed to 'collect'.  But that was only after this problem started.  And that was 16 days ago that I changed it back to On.  All the other settings are set to defaults, which is how they've always been.  Yeah, I've resorted to whitelisting senders that this is a problem with.  But that's obviously not ideal.

As long as it was not turned off your DB should be fine.   

I would recommend creating a new email.. drag and drop some delayed samples as .eml attachments ..  send them to not-spam@labs.sophos.com then reply back to your case and provive them with the email addresses used to submit the samples.. and request they escalate some of them to labs for further analysis.  They should be able to verify if there is a detection or issue with rules. or possibly adjust the rules.  

Ideally if you are using a syslog server.. including the message_log and maillogs of the submitted samples would also really help as it provides a list of the triggered spam rules.

Unfortunately,  the forums is not the best venue to resolve your case.. but I would recommend sending in those samples and or working with your support case engineer to collect the logs.

So, can you tell me if this is actually a known issue?  I've been waiting three weeks for a fix based on being told that by support.  I'm suspicious that's not the case at all.

Hi Ben,

honestly I have moved out of support so I am not aware of the current development tickets.  You can definitely request the JIRA ticket number (IE) (SEA-1234) which will be updated via the release notes.  

they can be seen here

http://sea.sophos.com/rn/sea/concepts/KnownIssues.html

and

http://sea.sophos.com/rn/sea/concepts/ReleaseNotes_4.3.2.0.html

In your case if you have submitted those false positives, collected and submitted the samples and logs to labs and they have come back saying there is not an issue and you have exhausted the case with support.  I would recommend requesting an escalation to level 2 and or involving your account manager.