Russell Nelson wrote:
> David Dyer-Bennet writes:
> > What is the appropriate MTA behavior in this case? It seems clear
> > to me that what everybody would want in this situation is for an
> > MTA to fail over to the secondary MX.
>
> If their MX records are incorrectly configured, their email isn't
> going to go through. Why should other hosts go through heroic hoops
> just to get the mail to them?
Just because the primary MX-pointed host happens to be down does not
make the MX records incorrectly configured. There are scenarios where
MX records should indeed be changed. But there are also scenarios where
the MX records are correct as they stand and the difference cannot be
distinguished from the point of view of the MTA trying to send mail.
> > Should we be giving any consideration to the question of whether, on
> > the average, secondary MXs are less reliable than primary? I don't
> > think we should; I don't think we should warp the implementation to
> > accommodate incorrectly configured systems.
>
> Aren't you doing just that? Right now, qmail works fine for machines
> which are correctly configured but sometimes inaccessible. Various
I would disagree. At least you said "fine" as opposed to "conformant",
opening it to disagreement of opinion, since "fine" is subjective. The
reason I disagree is because of the scenario where it may take three
days or more to correct the problems in the 1st host while the 2nd host
is able to deliver the mail just fine.
> people (not you) are talking about warping the implementation to
> accommodate incorrectly configured systems. There's a ton of
And some are talking about warping it to accomodate situations of
failure that don't repressent a misconfiguration.
> different ways you can configure your system so that email bounces.
> Why should a remote system bother to work around any of them? I mean,
> there's the chance that the SMTP server might be configured with the
> wrong hostname, so the client should strip off the hostname for the
> RCPT TO: lines, right??
I'm not suggesting we bend over backwards, or even bend at all, to
accomodate incorrect configurations. However, I don't want to miss
an opportunity to work around a problem in a correctly configured
setup just because someone else may be able to produce identical
symptoms by means of incorrect configuration. If it happens that
a change intended to work around problems also happens to work around
misconfiguration, who of us will feel bad about that (raise hands)?
--
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]
