* 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 both possible targets > have the same 30-second timeframe to attempt delivery. Yeah, fine with me :) > If these machines are all on a high-speed LAN, why not lower all > timeouts to the practical minimum? But WHAT IS the practical minimum in a non hostile environment? > You'd need to test this with load anyway, so put a test load on the > solution and start testing at 1 second timeouts. > Increment selectively for each failure you find until failures disappear. Good idea. > >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... > > Since it is a per-destination setting at best, it depends on how many > concurrent destinations you expect to handle. > > In fact, if this setting is applicable to fallback_relay, you would > want to keep that one open indefinitely. > > You could either lower this value, or increase the limit on smtp > processes, or both. > > > > -- > J. > -- Ralf Hildebrandt Geschäftsbereich IT | Abteilung Netzwerk Charité - Universitätsmedizin Berlin Campus Benjamin Franklin Hindenburgdamm 30 | D-12203 Berlin Tel. +49 30 450 570 155 | Fax: +49 30 450 570 962 ralf.hildebra...@charite.de | http://www.charite.de
