Re: Drive Towards Consensus [was Re: On Extensibility in MARID Re cords]

I'd like to respond to the three postings about why SPF syntax is not 
sufficient that appeared in this thread during the last few days.
First, I'd like to state my view that while there are many approaches 
and parts of the problem of unwanted mail, the original SPF was 
designed to implement a small, but important, slice of them.  When it 
was seen that several other approaches were converging on similar 
ground, there was a push to consolidate them and one result of that 
push was this working group.
In light of that, I see that each of the three postings argue that the 
SPF syntax can't handle something that it wasn't designed to handle.  
They are issues and approaches that are beyond the original scope of 
SPF and the similar projects that are trying to be merged here.  In 
particular:
1) Margaret Olson's examples
Alas, these examples didn't actually state what aspect SPF couldn't 
handle.  I don't know if the desire is to have mail rate information in 
SPF, or reputation information or what.  As a part of the system, SPF 
seems to me to work in all the examples given.
2) Jim Lyon's examples
These examples focused on assignment of reputation, and how that might 
depend on the route the mail takes, or even perhaps on different 
mailbox names within a domain.  I contend that these are issues for the 
reputation systems.  All SPF does is authenticate that the domain 
believes that it's mail could have traveled via a particular MTA.  If 
that check passes, normally, one just feeds the domain name into a 
reputation system (such as white or black lists.)  If there is need for 
finer grained reputation, then it is up to some reputation service to 
offer better assessments based on more information.  Nothing in any of 
the proposals tells clients how they should assess reputation.  If it 
is argued that domain name based reputation will be the only de facto 
available option, then I submit it isn't too hard for large entities to 
use multiple mail sub-domains:
    jane_doe(_at_)example(_dot_)com - mail from real people
    news(_at_)support(_dot_)example(_dot_)com - mail from opt-in newsletters
    coolOffer(_at_)ads(_dot_)example(_dot_)com - unsolicited advertisement

3) Phillip Hallam-Baker's examples
These examples are a clear extension into other approaches.  None of 
these examples has anything to do with domain authentication of an IP.  
To quote Phillip about such extensions: "...the number of degree of 
freedom are huge".  To this end, these examples beg for something much 
larger than the part of the problem the current projects ever set out 
to handle.
I understand the desire to design a more comprehensive mail policy 
format.  And I understand the desire that such a format be extensible 
for future approaches that are now only contemplated.  However, the 
proposed XML syntax doesn't achieve this either:  While it is true that 
XML provides a much richer syntactic framework in which to extend an 
original document format, it says nothing about the semantic meaning of 
such extensions.
In the six months that the XML format has been in public discussion, I 
haven't seen one proposal that actually includes the rules for semantic 
interpretation of future extensions.  This is no surprise: It is a hard 
problem.  The myriad of possible extensions that have been expressed, 
and their subtle effects of the semantics of the original format make 
it clear that defining how clients are to interpret future extensions 
would be difficult.
I maintain that, in the problem space these projects were designed for, 
namely authentication of the origin of mail based on the domain name, 
the SPF classic syntax does just fine.  There is a little room for 
extension (defined both syntactically and semantically), just enough to 
handle a few future ideas within this problem space.  I think Dave 
Crocker's posting from earlier today 
(http://www.imc.org/ietf-mxcomp/mail-archive/msg02139.html) speaks for 
this approach eloquently.  When a larger framework for mail policy 
emerges, SPF can easily add a modifier for pointing to it.  Or perhaps 
SPF will have run its course, and the newer framework will simple take 
over.  Either way is fine.
Solving the original small, but important slice that all of the 
original projects targeted should be our first priority.  If we can do 
that, then we show the world, and ourselves, that we are capable of 
tackling more.
        - Mark Lentczner

Mark Lentczner
http://www.ozonehouse.com/mark/
markl(_at_)glyphic(_dot_)com