[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: [spf-help] Re: SPF and SenderID
On Fri, 2005-06-17 at 14:27 -0400, Michael Hammer wrote:
> On 6/15/05, Douglas Otis <dotis@xxxxxxxxxxxxxx> 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
>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.
> > 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
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
> 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
> 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