* Victor Duchovni victor.ducho...@morganstanley.com:
On Thu, Feb 10, 2011 at 10:50:20PM +0100, Jeroen Geilman wrote:
and I'm not sure how
smtp_connection_reuse_time_limit = 300s
could be lowered in such a way that busy destination MXes are not
keeping a lot of mail in the active
Ralf Hildebrandt:
* Victor Duchovni victor.ducho...@morganstanley.com:
On Thu, Feb 10, 2011 at 10:50:20PM +0100, Jeroen Geilman wrote:
and I'm not sure how
smtp_connection_reuse_time_limit = 300s
could be lowered in such a way that busy destination MXes are not
keeping a lot
* Ralf Hildebrandt ralf.hildebra...@charite.de:
Goal:
=
Make mails go to a target server within 60s.
Target server is defined as either:
* the MX host of the destination domain
* my smtp_fallback_relay which keeps trying delivery
It's really fast and can take a lot of load...
So
Ralf Hildebrandt:
* Ralf Hildebrandt ralf.hildebra...@charite.de:
Goal:
=
Make mails go to a target server within 60s.
Target server is defined as either:
* the MX host of the destination domain
* my smtp_fallback_relay which keeps trying delivery
It's really fast and
On 02/10/2011 07:13 PM, Ralf Hildebrandt wrote:
Goal:
=
Make mails go to a target server within 60s.
Target server is defined as either:
* the MX host of the destination domain
* my smtp_fallback_relay which keeps trying delivery
It's really fast and can take a lot of load...
...
* Jeroen Geilman jer...@adaptr.nl:
... but can it absolutely, guaranteed, accept ALL mail immediately,
and process it within your left-over timeframe ?
Yes. It's asskicking fast.
That seems like a measurable quantity, but you could start with
one-half of the 60 seconds for simplicity, so
On Thu, Feb 10, 2011 at 10:50:20PM +0100, Jeroen Geilman wrote:
and I'm not sure how
smtp_connection_reuse_time_limit = 300s
could be lowered in such a way that busy destination MXes are not
keeping a lot of mail in the active queue...
The re-use time should equal or exceed the duration of
