Re: [spf-help] Re: SPF and SenderID

> > On 6/15/05, Douglas Otis <dotis(_at_)mail-abuse(_dot_)org> wrote:
> >
> > > For "Sender Policy Framework (SPF) for Authorizing Use of Domains in
> > > E-MAIL, version 1", the listed authors are M. Wong, and W. Schlitt.
> > > For "Sender ID: Authenticating E-Mail" the listed authors are J. Lyon,
> > > and M. Wong.  The "spf2.0/" record syntax was a product of the MARID WG
> > > specifically addressing this very issue.  As all the authors
> > > participated in the MARID WG that identified this scope related
> > > problem, and as both of these drafts also credit common authorship, it
> > > would be impossible to say which draft is now authoritative for the
> > > "v=spf1" record.
> On Fri, 2005-06-17 at 14:27 -0400, Michael Hammer wrote:
> > I would certainly agree with you that the waters have been muddied. I
> > have stated my opinion on that in other threads/locations so I won't
> > go there. The issue at hand though is whether IETF/IESG should accept
> > an ID (even experimental) which proposes to break the implementation
> > (existing) of a competing ID where the purported reason for doing so
> > comes down to "people won't publish the record we want (and
> > participate in our experiment) so we will force them to publish our
> > record, suffer bad outcomes or remove existing (SPF1) records all
> > together.
--Douglas Otis <dotis(_at_)mail-abuse(_dot_)org> wrote:
> From the day of the SPF/Sender-ID merger in the interim meeting at
> Qualcomm, it has been clear the SPF record would be utilized to evaluate
> the PRA.  Microsoft wanted to use their XML record, but the WG convinced
> them to use the existing record syntax.  This is why Meng Wong
> eventually suggested the use of the "spf2.0/mfrom ..." record once the
> licensing issue became a concern.  This is history that can not be
> changed.  Especially by a third-party like IETF/IESG.  You want the IESG
> to say who made the mistake?  There were so many in sequence.

As one who spent a fair amount of time working in the MARID working group, 
I can honestly say I'm still disappointed that there was never a proposed 
standard, only drafts and talking.
I wouldn't call any of those drafts or discussions "mistakes" but I 
wouldn't credit them as being standards either.  My belief, in the few 
conversations I did have with MS folks, was that we were working toward a 
common goal that was, in the end, never realized.  The WG failed to produce 
the output we were all expecting... we were left only with "Go ye forth and 
experiment some more."
Technically, there is no official functional definition of what a TXT 
record means other than "it contains text".  So, no draft writer can claim 
it's an exclusive domain.  However, if I'm looking for propriety in whose 
draft should or should not claim to make use of the records, I'm going to 
look for prior art.  I'm going to look for what people who actually 
published the records *intended* them to be used for.  It seems pretty 
clear to me that people who published TXT records starting with v=spf1 
intended them to be used *FOR SPF*.  Any other interpretation seems 
specious to me.  Nothing output by MARID has reached any level of adoption 
even approaching the level SPF was at even before MARID was convened.
Probably the worst "mistake" we made with MARID was allowing it to be 
subjected to denial-of-service attacks, and I'm not talking about the DNS 
variety.  I'm talking about people who continually trotted out the same FUD 
over and over, blatantly going over posting limits and outside of topics 
requested by the chair, and repeatedly questioning what had already been 
declared a rough consensus.

> > > It has been nearly a year to consider the impact of this problem.  Only
> > > those that don't care about the scope of the record should publish
> > > "v=spf1".  Those that care, should publish "spf2.0" records that
> > > declare the assured scope.
...
> This depends upon which era is considered, and which draft the publisher
> may have been reading.
...
> The SPF spec is frozen, which is why it does not offer a solution to
> your dilemma.  You would need to thaw it out before you could use the
> new and scope-safe record.
...
> You should review the histories of these two drafts.  It is clear to me
> the authors of the "frozen in time" draft have not allowed themselves to
> deal with this conflict, as the PRA did not exist back then.  This draft
> is just to document a distant point in history, nothing more.  Reading
> the white paper, you would be hard pressed to even discern there was a
> problem.

...
> I am posting to the MARID reflector in order to express my views
> concerning the two drafts published.  Your view of history is simply
> biased.  What is preventing the use of "spf2.0/mform"?  Why battle when
> there is a solution?  You are talking about a mistake made by the group
> as a whole.  We all make mistakes.  Watch for the camel's nose next
> time.


Speaking of FUD, thank you for the eloquent reminders as to why I haven't 
opened the MXCOMP mail folder for nearly a year.
MARID failed it's primary goal, but most of the people involved are moving 
ahead with other proposals.  More power to them.  I don't even think of 
them as "competing" proposals.  The best case would be if they all move 
forward in some form or another.
I don't think it's productive to point to the actions taken by MARID and 
say that those are the "official" versions of anything.
Anyway, best of luck with your... whatever it is you're doing.  The only 
real advice I have is, resist the temptation to tear down what other people 
are building, and go build something interesting of your own.  It's a lot 
harder to build than to tear down, but you have a better chance of earning 
respect in the long run.
Be well.

gregc

--
Greg Connor <gconnor(_at_)nekodojo(_dot_)org>