Re: [Exim] Delivery optimization tips for large lists ?

Página superior
Eliminar este mensaje
Responder a este mensaje
Autor: Exim Users Mailing List
Fecha:  
A: exim-users
Asunto: Re: [Exim] Delivery optimization tips for large lists ?
[ On Monday, October 11, 1999 at 21:54:24 (-0700), Pete Naylor wrote: ]
> Subject: Re: [Exim] Delivery optimization tips for large lists ?
>
> That's right - I hope nobody is silly enough to configure their DNS in the
> manner that you've just described. Really bad practice.


Come on now!!!! That's one of the better ways to configure multiple
fail-over mail servers! Indeed using multiple MX records is adequate in
some circumstances too, but using multiple A RRs is most definitely 100%
*NOT* "bad practice"!

In fact if you are a very large entity and you require more than ten or
so mail servers then using multiple MX RRs, each with multiple A RRs on
the target host, is the *ONLY* way to achieve the desired result. Check
out compuserve.com, aol.com, uu.net, and any other really big e-mail
provider who's technical folks do know mostly what they are doing. Even
some of the ones who don't have everything esle figured out yet, such as
mail.com, have figured this bit figured out.

The SunOS-5.x (Solaris-2.x) nscd *IS* misconfigured for default
operation on the Internet. I believe Sun even admit this themselves now
(and for certain many of their more astute technical people realise this
and will openly say it to be so). The *only* proper way to run a
SunOS-5 box with DNS as the primary information source for host
information is to either kill nscd, or to tell it not to cache host
information, and that's done trivially by uncommenting the example line
in /etc/nscd.conf given for exactly this purpose. Any SunOS-5 box
running on the Internet as a mail server is most definitely not
optimally configured until this change is made.

Leaving nscd enabled for caching host information while at the same time
using BIND for host information causes exactly the kinds of problems
that any duelling cache protocol implementations will bring. Don't do it!

-- 
                            Greg A. Woods


+1 416 218-0098      VE3TCP      <gwoods@???>      <robohack!woods>
Planix, Inc. <woods@???>; Secrets of the Weird <woods@???>