Here is a brief discussion of what the include: and redirect= currently do.
This probably has more to do with error handling than with extensibility.
The reason I am talking about error handling in this thread is, if unknown
keywords are always considered "errors" then maybe some intelligent error
handling could give me what I want anyway. If extensibility is allowed
some other way, error handling could still be more flexible, but it's not
as important.
I think I was getting confused by the Mechanisms page, which has a terse
and maybe misleading description of include: -- for one thing, I didn't
realize it would be possible to write ?include: and have their Pass result
be transformed into an unknown result for me.
The description in the spec itself is more accurate, and includes this
table.
included include
query mechanism SPF
result result processing
-------- -- -------------- -------------------------------------
pass => match, return the prefix value for "include"
fail => no match, continue processing
softfail => no match, continue processing
neutral => no match, continue processing
error => throw error, abort processing, return error
unknown => throw unknown, abort processing, return unknown
none => throw unknown, abort processing, return unknown
It goes on to say:
If the parent domain includes another domain, and that domain one day
loses its SPF record, it is better for the query to abort with
"unknown" than to continue on to a potential "-all".
I think I would like to have a better way to handle this case than to
always abort with unknown. That has more to do with error handling than
extensibility. IF there is a general way to trap results, that could be
used as a kind of crude nesting.
redirect= doesn't seem to be suitable for either extensibility or
controlled error handling/nesting either, given that it is always executed
last, and only one redirect may appear per record.
--
Greg Connor <gconnor(_at_)nekodojo(_dot_)org>