> -----Original Message----- > From: Scott Taylor > Sent: Wednesday, May 05, 2004 3:15 PM
> On Wed, 2004-05-05 at 15:22, Sander Holthaus wrote: > > > Both machine's have the same MX-prefernce. > > Thats your problem. Smallest number for the final destination. Period. Scott, you're wrong. > If you want to setup a separate dns zone that makes them look > the same *to the outside world* in order to get the load > distributed evenly, thats an option, but the dns that your > servers see need to have one server being the preferred one > which will keep the servers themselves from getting confused. Nope. RFC2821 is explicit (section 5): if there are multiple destinations with the same preference values and there is no clear reason to favor one (e.g., by recognition of an easily-reached address), then the sender-SMTP MUST randomize them to spead the load across multiple mail exchangers for a specific organization. (That's verbatim). So I don't where you're getting this "that's your problem" nonsense. The behavior is explicitly required by RFC2821. Moreover, Courier's behavior when it identifies a broken MX record appears incorrect per the RFC. I quote (also from secton 5): "To provide reliable mail transmission, the SMTP client MUST be able to try (and retry) each of the relevant addresses in this list in order, until a delivery attempt succeeds. However, there MAY also be a configurable limit on the number of alternate addresses that can be tried. In any case, the SMTP client SHOULD try at least two addresses." It seems to me that Courier doesn't conform, since: 1. It is not able to try (or retry) each of the relevant addresses in the case where one of the relevant addresses fails to resolve due to it being malformed. 2. The limit (of 1 attempt, in that case) is not configurable. 3. The limit (of 1 attempt) is not at least two addresses. I don't see any way of arguing that around the fact that, in order to try to enforce some RFC's, Courier is violate another RFC... > -- > Scott Taylor - <[EMAIL PROTECTED]> Malc. ------------------------------------------------------- This SF.Net email is sponsored by Sleepycat Software Learn developer strategies Cisco, Motorola, Ericsson & Lucent use to deliver higher performing products faster, at low TCO. http://www.sleepycat.com/telcomwpreg.php?From=osdnemail3 _______________________________________________ courier-users mailing list [EMAIL PROTECTED] Unsubscribe: https://lists.sourceforge.net/lists/listinfo/courier-users
