Spam Filter ISP Support - Incorrect handling of 4.x.x errors?

Incorrect handling of 4.x.x errors?

Printed From: LogSat Software
Category: Spam Filter ISP
Forum Name: Spam Filter ISP Support
Forum Description: General support for Spam Filter ISP
URL: https://www.logsat.com/spamfilter/forums/forum_posts.asp?TID=7012
Printed Date: 28 December 2024 at 5:15pm

Topic: Incorrect handling of 4.x.x errors?

Posted By: roaridse
Subject: Incorrect handling of 4.x.x errors?
Date Posted: 26 March 2012 at 3:22am

We recently had a little downtime on our exchangeserver due to upgrade from 2007 to 2010 .

The mails seems to queue fine in spamfilter, but I think the handling of 4.x.x errors are incorrect?

4.x.x errors are temporary errors afaik, but mails returned to sender when the exchange-server returned this message:

Sorry, your message to xxx@xxxx.net
could not be delivered.

The specific error is:
server error - ex03.xxxx.net:25 said: 4.3.2 The maximum number of concurrent connections has exceeded a limit, closing transmission channel

This cannot be the the correct way to handle 4.x.x messages?

Replies:

Posted By: LogSat
Date Posted: 26 March 2012 at 9:19pm

roaridse,

You are correct - 4xx errors are temporary, and by default SpamFilter should queue until the destination SMTP server accepts them. 5xx errors are instead permanent, and SpamFilter should not queue those and return an error right away.

These parameters in the SpamFilter.ini file can be used to alter this behavior:

;Determines if SpamFilter should hold in the queue emails that were rejected by the destination SMTP server with an error in the 4xy range

QueueIfDestinationError400=true

;Determines if SpamFilter should hold in the queue emails that were rejected by the destination SMTP server with an error in the 5xy range

QueueIfDestinationError500=false

;Determines if SpamFilter should remove from the queue emails that could not be delivered to the destination SMTP server due to a "Read Timeout" (an NDR is sent if the email is removed from the queue)

DoNotQueueIfReadTimeout=false

Could you please check your SpamFilter.ini file and see if the "QueueIfDestinationError400" value is set to "true" or "1"?

-------------
Roberto Franceschetti

http://www.logsat.com" rel="nofollow - LogSat Software

http://www.logsat.com/sfi-spam-filter.asp" rel="nofollow - Spam Filter ISP

Posted By: roaridse
Date Posted: 27 March 2012 at 2:39am

Hi,

Thanks - QueueIfDestinationError400 was set to "0" .. Explains it all..

Roar

Posted By: LogSat
Date Posted: 27 March 2012 at 7:47pm

Hi Roar,

We looked into this a bit further, and unfortunately have just discovered a bug related to the option above. We'll be fixing it in the next beta version of SpamFilter. The release note relative to this is:

{TODO -cFix : If the SpamFilter.ini option DoNotQueueIfReadTimeout was set to false, it was also affecting the option QueueIfDestinationError400 by overriding it and setting it to false as well}

-------------
Roberto Franceschetti

http://www.logsat.com" rel="nofollow - LogSat Software

http://www.logsat.com/sfi-spam-filter.asp" rel="nofollow - Spam Filter ISP