wayne [wayne(_at_)midwestcs(_dot_)com] wrote (in part):
> 5. Extensibility: [sniped]
I agree that extensibility is important.
SPF allows extensibility via modifiers, I think that that
most of the other LMAP proposals either have, or could have,
similar extensibility.
--Harry Katz <hkatz(_at_)exchange(_dot_)microsoft(_dot_)com> wrote:
If I understand section 6.1 of the SPF spec correctly, an SPF receiver
must abort evaluation if any unrecognized mechanisms are encountered.
This means in practice a sending domain loses the protection of it's SPF
record whenever it adds a new mechanism unless the receiving domain
understands that new mechanism.
Both of these are correct. SPF allows unknown "modifiers" but not new
"mechanisms". This allows *some* extensibility, but not *complete*
extensibility.
For 100% real extensibility, you have to basically go back in time and
leave specific instructions in the past for coders, telling them what to do
when they get to the unknown (and presumably unusable, without a version
update) mechanism/keyword/whatever.
What I mean by that is, you would need to have some sort of
if-supported/then/else structure. Otherwise, you are left in an ambiguous
state. Did the mechanism you can't use contain something that might have
permitted the mail? Is it reasonable to reject the mail after skipping
over an unknown mechanism that might have allowed it? You would really
need something like this:
v=spf1 a mx ptr unsupported=unknown +magic:white -all
v=spf1 a mx ptr unsupported=skip -magic:red -all
Since SPF was already being characterized by some opponents as too complex,
an if/then structure would have put it a bit over the top. So, currently
the only way to introduce a new mechanism is to have two or more SPF
records (such as v=spf1 and v=spf1a, or whatever)
v=spf1 a mx ptr -all
v=spf1a a mx ptr unsupported=skip +magic:white -all
This is a significant barrier to the
adoption of any new mechanisms that might be introduced. In effect
sending domains have to wait until substantially all receiving domains
have upgraded their software to support the new mechanism -- and how
would they know this? -- until they add the new mechanism to their SPF
record.
Not quite true, there is *some* barrier there, but that's what the version
number is there for. Multiple versions can be supported in parallel.
Pragmatically speaking, this means that no new SPF mechanisms will be
successfully introduced ever. I'm curious why this approach was taken.
That seems to be either erroneous or unfair.
(Don't get me wrong, while I like SPF, I'm keeping an open mind to
alternatives. I'm trying to limit my jumping to the defense of SPF to
instances where I think it's being unfairly/inaccurately characterized. I
don't mean to add to the general atmosphere of "whose is better"... It's
unlikely that this working group will rubber-stamp *any* proposal so I'd
like to focus on taking the best parts of each, and blending those with new
solutions for things that have not already been done well.)
> [list of examples]
All of these can be done via SPF modifiers.
How does SPF deal with possible naming collisions of modifiers? The XML
approach is to use versioned namespace prefixes. This allows new
elements or attributes to be added by either a central coordinating
authority, e.g. IETF, or by individual organizations or groups
coordinating on an ad hoc basis. This is all standard XML usage.
Hang on, I don't think XML is a panacea that gives you instant
extensibility... You still have to proactively decide what to do when a new
keyword or type is encountered in the data for which the code isn't loaded
yet.
If there is a data item not supported by the current code, I doubt that the
XML schema named in the header will automatically update your MTA to the
new code on the fly. So, there needs to be something in either the data
node or the schema that says "what to do if this mechanism is not
supported". I didn't see this in reading the CallerID proposal...
Otherwise you would have the same if/then problem. Does the new data type
provide a way to authorize messages that won't otherwise be accepted? Is
there a specific IP range you would like to check against the new
mechanism, but allow through if not supported?
--
Greg Connor <gconnor(_at_)nekodojo(_dot_)org>