James R Grinter <jrg@???> probably said:
> I'm all for not having unnecessary backup MX's (a former PIPEX
> postmaster wrote a very good document on that aspect)
That would be Tim, my boss at the time. Good person to work for.
> but I consider it a bad form to expect the sender to spend more CPU
> and time than necessary in delivering mail.
This is pipex corporate (pipex dial only does dynamic IP so thus had
no customer MXen), where most of the lines were up most of the time
(since they were hard lines) with the exception of a few ISDN lines
some of which may be down much of the time.
The small extra processing goes on the ISP side, congregated in one
point (or a set of points) and slows down everyone's mail due to the
extra hop and the extra processing all the time, or on the sender's
side where it takes one extra DNS lookup and one timed out connection
if (big if in that sample set) the line is down.
Since the sample set is practically all lines that are up practically
all the time the right thing is to have mail go directly to the
customer machines and special casing for the tiny proportion of other
customers is a pain in the neck (unless they happen to run their own
DNS, which is pretty unusual although there are standard facilities
there to handle this case) and the ones who do run their own DNS
normally chose the same order anyway ...
Personally I'd rather not have all my mail delayed and dependent on
yet another machine (or even a redundent set of machines, it's still
an unneeded dependency) to get to me every time and personally both
the MXen for my domains are controlled by me.
If the sample set is static IP dialups (which beyond Demon isn't found
many places in any scale) then the argument is somewhat different (the
assumption becomes down most of the time) and I agree with Demon's
current policy for that, but if you're talking about pipex then that
is not the sample set.
P.
--
pir pir@??? pir@???
