On Sat, 19 Jun 2004, Eric A. Hall wrote:
On 6/19/2004 3:18 PM, John R Levine wrote:
If experiments show that recipients can use big rich XML data to deal
with spam significantly better, great. At that point, it should be
easy to send MARID 1.1 with XML along the track. But you have to do
the work and show us the horse before you can get this cart moving.
I pretty much agree with John but on a slightly different tack.
I think we (for some value of 'we') are trying to sneak email policy into
an authentication scope, which is cart-horse inversion, as John says. If
we really want to detail an email policy architecture, let's work on that
as a discrete problem -- heck, we might even end up with receiver-side XML
architecture of some kind. Instead it seems like we're trying to come up
with excuses to sneak XML into DNS and declare that we've got ourselves an
email policy framework. Backwards.
I STRONGLY agree with above statements. XML would likely be great for
creating wide-scale policy document and I agree with Jim that is what
SPF will likely need to become in the future. But this kind of document is
almost certain to be larger then what can be put into DNS and we need new
protocol for it. At this time I believe we should leave SPF syntax as is
with maybe some additions for better extensibility (possibly new scoping
operator) and add ability to refer to different external policy service
from SPF record. This serves as quick patch that reuses current architecture
and can be deployed quickly (which is what this was all about).
The new policy service can then be developed in normal IETF process
and can reuse current work done by Microsoft in regards to SPF/XML
and <ep> document and define how to best get to users but would not have
constrains of having to be fit into records that using DNS database
service forces on us, nor would it have constraints of single-key data
lookups which allows for user wildcards and other features.
--
William Leibzon
Elan Networks
william(_at_)elan(_dot_)net