Thread Info
  • State Not Answered
  • Locked Locked
  • Replies 5 replies
  • Subscribers 2 subscribers
  • Views 8440 views
  • Users 0 members are here
Options
Suggested
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

Increase in legitimate messages going to the delay queue

Ben_1234

In the last couple weeks we have had a noticeable increase in the number of legitimate messages going to the delay queue.  They will get rescanned and delivered, but it's causing issues with time sensitive emails.  For now I'm having to whitelist senders as necessary.  We tried disabling the delay queue, but of course had a huge uptick in SPAM.  I've had a case open for two weeks and all I've heard is that it's a known problem and will be fixed in an upcoming release, but no one can give me an ETA on  that.  When I opened the case I was told it would be a week or so, but that never happened.  Anyone else seeing this problem or have any other information?



This thread was automatically locked due to age.
Parents
  • 0

    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.  

Reply
  • 0

    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.  

Children
  • 0 in reply to Red_Warrior

    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.

  • 0 in reply to Ben_1234

    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.

  • 0 in reply to Red_Warrior

    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.

  • 0 in reply to Ben_1234

    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.

Unfiltered HTML