Instead of MX magic, would it be possible to use a local cache to keep
track of QMTP-capable hosts?
QMTP is most useful for hosts that we talk to often and [with
multi-recipient protocols] with smarthosts, etc. Thus, it should be
possible to use SMTP by default, recognize from the banner that the
recipient talks QMTP, and commit that info to a cache (e.g. a
non-synced file which could asynchronously be compiled into a cdb once
in a while).
When sending, one would look up host names in the cdb, and if
QMTP-capable start a QMTP dialog. If it fails, the db can be updated
with that info (it doesn't matter if it takes a while to make it to the
cdb since this should be rare). When the db is updated a subsequent
redelivery will use SMTP.
When building up multi-recipient QMTP blocks, one could parse the
recipients of the message first and look up the hosts (useful only for
messages with many recipients, say > 50). Alternatively, one could do
this only for "smtproutes" entries or even have "qmtproutes" since the
gain is for smart hosts or MLM hosts that use exploders via QMTP (the
exploder does VERP).
The advantage would be that QMTP could be automatically implemented by
a qmail host and would soon be employed between qmail hosts without the
need for any special setup. The disadvantage is the need to maintain
another lookup db, but it would be relatively static and fast as it is
local. If the db is lost, it would cause a slowdown, but it wouldn't be
fatal. If the updates from the last few hours are lost, it is quite
insignificant, so there is no need for frequent sync()/rebuilds. If the
info is incorrect, SMTP will be used and the error noted and corrected,
or QMTP will be attempted, fail, and the info corrected.
-Sincerely, Fred
(Frederik Lindberg, Infectious Diseases, WashU, St. Louis, MO, USA)
