[geeks] ADMINISTRIVIA: Changes to mail delivery policies

[Greg A. Woods]

[ On Wednesday, March 13, 2002 at 17:01:59 (-0600), Jonathan C. Patschke wrote: ]
> Subject: Re: [geeks] ADMINISTRIVIA: Changes to mail delivery policies
>
> You're confusing the optimal solution with a workable solution.  My MX is
> staying right here, in my house, for the most practical of reasons.  I
> -like- having my mail queued remotely and then streaming in.  It means
> that the queues mail comes in a single flood, rather than in trickles from
> hundreds of places at once.

Well whatever.  You're confused and misinformed I think, but it's your
domain and your connection....  Just don't touch mine!

> > Your configuration takes that control out of her hands, and maybe even
> > out of your own hands, causing her mail to have to sit in some remote
> > mailer's queue for an even more undefined period of time, often with
> > no indication of where it is or why it hasn't been delivered yet.
> 
> If the secondary MX is properly configured, this is a non-issue.  Mail
> will come flooding in within an hour.

Huh?  You've completely missed the point of what I said.  You've
addressed an entirely unrelated issue.

Normally your waiting mail comes "flooding in within an hour" no matter
whether it's in a secondary's queue, or in the original sender's queue.
However in the latter case it's still closer to where the one person who
knows something about the stuck message.

> Or secondary nameservers, or redundant anythings, I'm sure.  It's all just
> a big capitalist scam.

Now you're really off in left field and blowing nonsense.  There's no
such thing as a "secondary" nameserver.  All NS records are returned in
equal round-robin fasion.  DNS has no queuing algorithm -- you either
get a proper answer nearly imediately, or you get no answer at all.  You
_need_ multiple nameservers -- you do not _need_ multiple MX servers
(unless one alone cannot handle the peak loads).

A "secondary" MX is only a useful for redundancy when you go beyond the
RFC-mandated 4-5 day maximal_queue_lifetime.

-- 
								Greg A. Woods

+1 416 218-0098;  <gwoods at acm.org>;  <g.a.woods at ieee.org>;  <woods at robohack.ca>
Planix, Inc. <woods at planix.com>; VE3TCP; Secrets of the Weird <woods at weird.com>