On 6/23/2004 9:34 AM, Alan DeKok wrote:
What about putting the MARID data in-line in SMTP via an extension?
It can be signed, and the keys can go into DNS ala DK, which should
validate it. It does mean that the barrier for adoption is higher, as
more software has to change, but it does avoid the above problems.
There are lots of good reasons to do this. For one thing, you can define
whatever lookup-keys you want, meaning that you can ~extend into per-user
policy statements, for example. You can also take advantage of existing
AUTH mechanisms to publish ~public policies versus ~private policies. It
seems to me that if we really want infinitely extensible policy docs,
these kinds of features are going to be important, and given that DNS
*DOES NOT* support these kinds of things easily that an appropriate design
would favor some kind of service.
Note that all of the above assumes that policy will be interpreted by the
recipient system, which is not necessarily required. A sender-side policy
daemon that returns YES/NO/MAYBE could also work.
Of course, it means that caching of the data becomes more
problematic. DNS takes care of that automatically, and that won't be
possible if the data is inline. But at ~100 bytes per typical MARID
record, itwouldn't be much of a problem to just re-send it.
Cache meta-data can be embedded into the XML pretty easily (especially if
message-size is no longer an issue), so the real issue is tracking and
cleanup code, which nobody wants to write, and which comes with DNS 'for
free' [sic].
There are other problems with reusing SMTP -- the biggest one I can think
of is the excessive number of round-trip times, which imposes significant
latency considerations. Connect->HELO->POLICY-> to a laden serve behind a
slow link in ~Ukraine can be expensive.
Probably the best generalized approach to the "where's the policy" issue
(assumng such a design is taken) is to use a URI syntax, and to define
things like SMTP:host and SMTP:MX:domain as eligible candidates (those
syntaxes would be useful for other things anyway).
--
Eric A. Hall http://www.ehsco.com/
Internet Core Protocols http://www.oreilly.com/catalog/coreprot/