Ned Freed <NED(_at_)INNOSOFT(_dot_)COM> writes:
There is also the added complexity involved in caching errors.
This problem exists independently of MX fallbacks.
I don't understand. Sure, the issue of how to cache errors exists without
MX fallbacks. But MX fallbacks makes it substantially more complex, since
before you simply had one basic error (host is not reachable or not
responding) and now you have a whole spectrum of errors, many of which
seem to demand somewhat different handling. A 4xx in response to a HELO,
for example, would seem to be something you want to cache, while a 4xx
in response to a trailing dot may or may not be -- a "spool is full" error
would be cached, but a "user is over quota" would not be.
MX fallbacks are completely orthogonal to error caching.
If you get a 4XX response to some command, the decision to cache the
error for use in future delivery attempts to this MX host is
independent from the decision to try the next MX host for the
destination domain. An implementation which implements error caching
but not MX fallbacks has to deal with exactly the same spectrum of
errors as one that implements both. An implementation that makes a
bad caching decision will be no less screwed by failing to roll over
to the next MX host on that particular delivery attempt.
--
_.John G. Myers Internet: jgm+(_at_)CMU(_dot_)EDU
LoseNet: ...!seismo!ihnp4!wiscvm.wisc.edu!give!up