David Dyer-Bennet wrote:

> Greg Owen <[EMAIL PROTECTED]> writes on 19 September 1999 at 09:18:55 -0400
> 
>  >    But before I go, in response to Racer X:
>  > 
>  > >> the more i think about this, the more i think that 
>  > >> fallback MX records aren't really necessary anymore.
>  > 
>  >    There are several reasons I think they are still useful:
>  > 
>  >    1) Redundancy.  All machines die at some time or other.  I'd rather
>  > not have the added pressure of knowing that mail will start bouncing if it
>  > isn't fixed in X amount of time while I'm trying to fix it.
>  > 
>  >    2) Maintenance.  You can take your mail server down for maintenance
>  > and not worry about where the mail sits in the meantime - I'd rather it sit
>  > and wait on my server than on someone elses!
>  > 
>  >    3) Upgrades.  You can test upgrades on a fallback MX before moving
>  > them on up.
> 
> This is amusing to me; you're both essentially saying that you trust
> your *own* servers more than you trust other people's servers, so it's
> better for the mail to do its waiting on *your* servers.  

Yes we do, but, the reason I (I cannot speak for others) prefer the mail to
be queued to my secondary is that I know it will come over to the primary a
whole lot faster.  The secondary can do retries every minute and is connected
to the primary at 100 mbps ethernet.  And that's only my top reason.  There
are also lesser reasons (including that, yes, I do trust my server more than
some arbitrary server I have no idea about).  I can also up the expiration
time on my secondary so I give myself more time to correct the primary.

And how do you know that the secondary works from the same MX list as the
sender has?  I may well have the real primary unlisted at all.  There may
be a perfectly good reason to do that.  It could be on a private LAN, for
one example.  Or it might be on a slow link where I want to serialize the
mail delivery.  The apparent primary would then be in the public MX list as
primary because it is the faster machine, and the apparent secondary being
slower, gets listed next, even though it can deliver to the real primary
without the apparent primary being functional for SMTP.

Sure, I could list the public MX machines as equals in the list.  If they
were indeed equal, that might be a good idea.  Or I could list one machine
with multiple A records for each separate real machine (some people do have
a problem with this in their talk, but it has worked for me before).  But
if the machines are unequal, I would list them unequally.

-- 
Phil Howard | [EMAIL PROTECTED] [EMAIL PROTECTED] [EMAIL PROTECTED]
  phil      | [EMAIL PROTECTED] [EMAIL PROTECTED] [EMAIL PROTECTED]
      at    | [EMAIL PROTECTED] [EMAIL PROTECTED] [EMAIL PROTECTED]
  ipal      | [EMAIL PROTECTED] [EMAIL PROTECTED] [EMAIL PROTECTED]
     dot    | [EMAIL PROTECTED] [EMAIL PROTECTED] [EMAIL PROTECTED]
  net       | [EMAIL PROTECTED] [EMAIL PROTECTED] [EMAIL PROTECTED]

Reply via email to