I use an after queue filter to filter incoming email. When the filter
queue grows because email comes in faster than it can handle the filter
returns a 450 until the filter queue is empty again. Now when email is
received in a big burst it can happen that the filter queue temporarily
grows and
Martijn Brinkers:
I use an after queue filter to filter incoming email. When the filter
queue grows because email comes in faster than it can handle the filter
returns a 450 until the filter queue is empty again. Now when email is
received in a big burst it can happen that the filter queue
Wietse Venema wrote:
Martijn Brinkers:
I use an after queue filter to filter incoming email. When the filter
queue grows because email comes in faster than it can handle the filter
returns a 450 until the filter queue is empty again. Now when email is
received in a big burst it can happen that
On Fri, Jan 30, 2009 at 11:43:07AM -0600, Noel Jones wrote:
If that's ineffective for some reason, then implement the suggestions
outlined in
http://www.postfix.org/QSHAPE_README.html#backlog
Note, for Postfix 2.5.x with x=6, there is an error in the parameter
names actually used by qmgr(8),
On Fri, 2009-01-30 at 11:43 -0600, Noel Jones wrote:
Seems to me the first action should be to reduce the number of
smtp connections to the content_filter to a number it's able
to consistently handle.
There is a big difference in filtering speed between messages. The
filter is an encryption
Martijn Brinkers wrote:
On Fri, 2009-01-30 at 11:43 -0600, Noel Jones wrote:
Seems to me the first action should be to reduce the number of
smtp connections to the content_filter to a number it's able
to consistently handle.
There is a big difference in filtering speed between messages. The
Victor Duchovni wrote:
On Fri, Jan 30, 2009 at 08:14:22PM +0100, Martijn Brinkers wrote:
If I'm not mistaken the described approach (with
fragile_destination_concurrency*) works when you have small bursts of
errors. In my case it can take some time before connections are allowed
(email is
On Fri, Jan 30, 2009 at 01:45:29PM -0600, Noel Jones wrote:
Victor Duchovni wrote:
On Fri, Jan 30, 2009 at 08:14:22PM +0100, Martijn Brinkers wrote:
If I'm not mistaken the described approach (with
fragile_destination_concurrency*) works when you have small bursts of
errors. In my case it
iminate all queues from the filter, it should be a proxy. Let Postfix
do all the queueing, it is much better at this than the filter.
The filter is based on James which is a Java based email server and
cannot be used as a proxy, at least not without a major overhaul. The
biggest reason I added
On Fri, Jan 30, 2009 at 09:00:26PM +0100, Martijn Brinkers wrote:
iminate all queues from the filter, it should be a proxy. Let Postfix
do all the queueing, it is much better at this than the filter.
The filter is based on James which is a Java based email server and
cannot be used as a
10 matches
Mail list logo
