james-server-user mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Stefano Bagnara <apa...@bago.org>
Subject Re: HELP!! Thousands of files stuck in spool at 'transport' state
Date Tue, 20 Jun 2006 23:37:59 GMT
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.


To unsubscribe, e-mail: server-user-unsubscribe@james.apache.org
For additional commands, e-mail: server-user-help@james.apache.org

View raw message