This problem seems to be exacerbated by the fact that if a target server is down, there is a default 10 minute timeout value. Personal feeling is that if the target mail server doesn't respond in a minute or so, time to move on and try again later. I doubt there are many mail servers that will finally respond after eight or nine minutes of waiting.
Is that 10 minute timeout value configurable? I can't seem to find it. (Probably just overlooked yet another obvious parameter...) Thanks. -----Original Message----- From: Steve Brewin [mailto:[EMAIL PROTECTED] Sent: Tuesday, June 20, 2006 3:00 PM To: 'James Users List' Subject: RE: HELP!! Thousands of files stuck in spool at 'transport' state Stefano Bagnara wrote: > > DNS servers already return multihomed host IPs randomly. > So I don't think that a similar algorythm would be so useful. RFC 2821, section 5 (http://james.apache.org/rfclist/smtp/rfc2821.txt) contradicts this... "The destination host (perhaps taken from the preferred MX record) may be multihomed, in which case the domain name resolver will return a list of alternative IP addresses. It is the responsibility of the domain name resolver interface to have ordered this list by decreasing preference if necessary, and SMTP MUST try them in the order presented". > > Multihoming is not used for clustering, but for loadbalancing. > > In real use cases you won't get any real advantage by remembering the > failing multihomed ip in a following retry (being done > minutes or hours > later). This is often true for intermittent failures in as much as the fault may be rectified prior to the retry. But there is no guarantee that it will be and no disadvantage in trying the next IP. Given that the target DNS configuration is dynamic, we cannot assume that it will be the same at the time of the retry. A "most often works" strategy would be to save the last used IP and compute the next IP on the retry. The last used IP might have been configured out by then, in which case we would restart from the top. This seems to be within the bounds of the spec. > > Furthermore, by specification multihomed IPs MUST NOT be tried in a > "deterministic way" but "randomly". My reading of RFC 2821, section 5 (see above) suggests a decidedly deterministic, order based, algorithm for retries. Equal preference MX records are the only exception; these should be chosen randomly. Perhaps we should move this discussion to server-dev to clarify our understanding and evaluate our options? <snipped/> Cheers, -- Steve --------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] --------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
