Reading Mark's post and the series of replies, I believe it would be fair
to say that his vision of SPF/MARID is a record which allows a
domain to make assertions about its own infrastructure that an MTA
might be able usefully to check when deciding whether to accept
traffic which asserts a relationship to that domain.
The extensions of "accreditation, reputation, and rate limiting" which
Margaret describe fundamentally involve a 3rd party (since rate limiting
only looks really useful if audited). If that is correct, the question
becomes: are these third party assertions something that need to be
tied to the individual MARID assertions, are they an independent
pointer within the record, or are they out of scope?
Let's assume for now that at least the pointers to them are in scope.
Imagine for a moment that MARID includes an extension that says: these
other people also wish to make assertions about me (with the implication
that the domain knows about it and is willing to point to it). Is it
possible to extend MARID to do that? Sure. Give those records a
similar syntax
to MARID and it becomes a set of assertions made by two or more different
parties about the same domain's infrastructure. Silly states then require
meta-reputation to resolve, but that may not be a big deal. Local policy
can resolve those towards permissiveness or restriction as required.
Is it also possible to do that such that it could be attached to other
assertions, as a generic mechanism for per-attribute
reputation/accreditation/certification? I think so. That would,
again, require the other domain to maintain some record that
allowed you to check that they did make such an assertion. As long
as the syntax for the per-attribute pointers is reasonably broad,
they could be records associated with multiple protocols or domains.
This way forward would also allow the original domain owner to specify
for which attributes the other domains' views were acceptable to the domain
owner (not binding on the recipient, but potentially a useful data point).
But the usefulness of either goes back to the issue raised by Roy Badami--what
does this mean in the context of the extension processing?
The WG discussions so far seem to have gone down two processing paths:
one in which MARID processing iterates through separate assertions until
one assertion explicitly allows, disallows or marks unknown the
message traffic;
the other in which all the assertions are taken together to create three sets:
allowed, disallowed, not known. In the first approach, new assertions can
easily be defined to have a null affect. If the working group takes that
approach, though, it seems fairly critical to define the generic
"external pointer"
syntax now, so that the use of external pointers modifying base assertions
does not later render null assertions which would otherwise
allow or disallow traffic. An alternate approach there is to specify that
modifiers of a certain type can be ignored such that the base processing
of the assertions can proceed if they are not understood. That would mean that
the syntax of the "external pointer" could be left vague right now, as long
as it is known to be of that type.
Since the "set construction" mechanism presumes that you will process
all the assertions to construct the sets, it is somewhat easier to have
mechanisms which allow assertions to be about other assertions. The
ability to handle nested assertions is also very handy here. The
difficulty with this approach and 3rd party assertions is that the
extension mechanism must describe what happens when they cannot
be resolved, and the choice of "pretend it wasn't there" is not so
easy in the face of nesting and assertions about assertions. A
common, practical approach at that point is to limit external assertions
to ones in which "pretend it wasn't there" processing does no
harm (viz. the GeoPriv limitation that all rules must add permissions,
so that the failure to resolve external reference cannot result
in disclosure of private information). That can both be a serious
limitation and difficult to get right when the base assertion and
the 3rd party assertion about it are not coordinated.
Without stepping on the toes of the original question asked by the
chairs, I'd be interested in hearing whether anyone believes MARID
will need the "set construction" mechanism, or whether it can
go forward with the iterative processing method. That may
tell us something about the extension mechanism choices and
what our core needs for syntax are.
regards,
Ted Hardie