domainkeys-feedbackbase01(_at_)yahoo(_dot_)com writes:
-- Michael Thomas <mike(_at_)mtcc(_dot_)com> wrote:
If this were true, there would be no DNS caching either.
Caching happens when it's in the cachors interest to do so.
You're not comparing the same thing. A DNS cache is not optional given the
way
that resolver libraries are written and the way that the DNS is deployed. A
KRS
cache is entirely optional.
There's nothing optional about the KRS cache in the IIM
code. I'm not sure what sort of argument somebody could
offer up to change my mind on making it optional. I'm not
sure why another implementation would come to a different
conclusion given the manifest performance improvement for
almost no effort (the caching logic is less than a page of
code.)
If you want to ensure deployment of caches, you'll need to make the interface
such that no other option is viable.
Keeping mail in MTA memory for significantly longer periods
of time for no good reason is a self-healing problem: those
that do it will be Darwin-awarded.
A better analogy is to compare the deployment of web caches - which is spotty
at best and primarily done by a subset of ISPs to save money.
Web caches help in the same way that upstream resolver
caches help. However the analogy is imperfect because the
likely deployment model is to verify at edge MTA's that
handle large amount of email, vs. individual web
browsers which only see their very narrow view of the
world. A cache on a large scale MTA is very much more
akin to an edge caching resolver than an individual
web browser's cache.
Mike