Douglas Otis wrote:
On Fri, 2005-06-17 at 14:27 -0400, Michael Hammer wrote:
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.
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.
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.
Inaccurate at best, the working group convinced MS not to put bloated
inefficient unnecessary XML records in DNS. It had nothing to do with
"convincing MS to use their syntax", it had to do with "don't make SPF
have to use an XML format"
Terry
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.
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.
I'm not sure how you can logically assert this Doug. People who
published v-=spf1 records didn't need to specify a scope because it
only applied to Mail From (and of course in the case of <> to HELO).
This depends upon which era is considered, and which draft the publisher
may have been reading.
Meng's white-paper on the spf.pobox.com website:
,----
| Sender ID was recently resubmitted to the IETF. It now specifies that
| both the return-path and the PRA may be used. Software that implements
| only SPF Classic can therefore be called Sender ID compliant. In
| practice, most people associate Sender ID with the PRA, and SPF
| Classic with the mail from, or return-path.
|
| The author recommends that MUA software implement Sender ID with PRA
| checking. The author recommends that MTA software implement Sender ID
| with mail from checking, aka SPF Classic.
'----
,----
| One half of Sender ID is SPF Classic. The original SPF Classic
| specification was frozen in early January 2004. It has evolved in only
| minor details since then. It was submitted to the IETF in October 2004
| and is expected to be published as an experimental RFC. When it is
| published, MTA vendors are encouraged to update their implementations
| to match it. Vendors who implement SPF Classic can indicate that they
| are Sender ID compliant.
|
| The other half of Sender ID is the PRA check. MTA vendors may also
| wish to implement that half. Specifications describing the PRA and how
| it fits into Sender ID were submitted to the IETF in October 2004 as
| well.
'----
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. According to Meng, both the bounce-address
and the PRA SHOULD be used. Obviously, there is little concern
regarding a reputation assessment described in a diagram on Page 11 of
this paper.
To make a leap from there to "don't care" is quite a stretch. To Ex
Post Facto apply new logic and claim that to know the "new" intent of
the publisher of the record (published prior to the claim that the new
logic should be applied) can have no basis in fact or logic.
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.
It is certainly ironic that you are posting from @mail-abuse.org.
Could the action being discussed be called anything than mail (related
record) abuse?
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.
-Doug
--
Terry Fielder
terry(_at_)greatgulfhomes(_dot_)com
Associate Director Software Development and Deployment
Great Gulf Homes / Ashton Woods Homes
Fax: (416) 441-9085