Steve Brewin wrote:
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?
This is not an SMTP option, but a DNS feature. Multihomed IPs are not
specified in a specific order, and DNS servers return IPs in random
order. So there is no need to prioritize them in a given order. MX have
weight for this.
Btw I really don't care about this specific issue: if anyone will
develope the code to add an optional feature to remember the already
tested IP for each MX I will not use it but I won't be against its
inclusion (-0).
Instead, about the use of multihomed ips I don't want to rediscuss a
thing that the RFC say has been controversial and does not specify the
correct way.
The sentence from the rfc is: "The question of whether a sender should
attempt retries using the different addresses of a multihomed host
has been controversial. The main argument for using the multiple
addresses is that it maximizes the probability of timely delivery,
and indeed sometimes the probability of any delivery; the counter-
argument is that it may result in unnecessary resource use"
I just want to know if anyone will put a veto on the the patch attached
to this issue: http://issues.apache.org/jira/browse/JAMES-358
I'll probably start a real vote soon if I don't understand the response
to this.
What I really know is that without that patch one of my production
server was not able to deliver my 200K mails per day (200K mails in a
single hour, but only once a day), having a lot of non working host.
This means that my outgoing was growing to much and to increase the
probability of delivery to non working servers I decreased the
probability to deliver most of my mail.
Stefano
---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
