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

From: "Frank Ellermann" <[email-masked]>
Date: Wed, 15 Jun 2005 10:41:18 +0200

Pete Chown wrote in spf-help:

> What should I do now?  Is there a way of supporting SPF
> without helping to get a patented technology established
> on the Internet?

Sure.

MS pretends to control spf2.0/pra to a certain degree, as
defined in draft-lyon-senderid-pra-01

They certainly don't control all of spf2.0, as defined in
draft-lyon-senderid-core-01

They never controlled a single bit of v=spf1 as defined
in draft-schlitt-spf-classic-01

As long as you don't want PRA this doesn't affect you,
v=spf1 is an open standard (wannabe from the IETF's POV,
there's yet no RfC for it).

MS tried to pull the stunt that v=spf1 is by default a
part of PRA.  This is a lie, the IESG knows that it's a
lie, so senderid-lyon-core-01 can never pass as an RfC.

                 Bye, Frank (Cc: mxcomp)

-------
Archives at http://archives.listbox.com/spf-help/current/
Donate! http://spf.pobox.com/donations.html
To unsubscribe, change your address, or temporarily deactivate your subscription, 
please go to http://v2.listbox.com/member/?member_id=1449865&user_secret=615bee79

-------
Archives at http://archives.listbox.com/spf-help/current/
Donate! http://spf.pobox.com/donations.html
To unsubscribe, change your address, or temporarily deactivate your subscription, 
please go to http://v2.listbox.com/member/?member_id=1449865&user_secret=615bee79

---

From: Douglas Otis <[email-masked]>
Date: Wed, 15 Jun 2005 07:29:49 -0700

> lie, so senderid-lyon-core-01 can never pass as an RfC.

This advice is based upon a false impression that Microsoft waits for an
RFC before producing product.  Recall draft-leach-cifs-v1-spec-02.txt?
Consider spf2.0/mfrom and _removing_ v=spf1 as the safe reaction to
Sender-ID.

-Doug

---

From: Michael Hammer <[email-masked]>
Date: Wed, 15 Jun 2005 11:11:42 -0400

> Consider spf2.0/mfrom and _removing_ v=spf1 as the safe reaction to

Doug,

This is exactly what Microsoft wants people to do. 

The correct action is for someone to force MS to back off (SPF
Council, FTC, IETF,EU...anyone listening) from what is essentially a
move to squash SPF. This could certainly be construed as an
anti-competitive action.

spf2.0/PRA lost in the marketplace. People simply weren't publishing
the records. People were publishing spf1 records at a significant rate
given that it wasn't even an "approved" standard. So, what better way
to cause problems for SPF AND co-opt the spf1 records that people were
publishing.

You don't resolve an issue of someone doing a wrong thing by giving in
through a work around that gives validation to the publication of
"their" (SPF2.0) record.

This also begs the question of who controls the SPF record format. Can
anyone come up with their own mechanisms willy-nilly? Does the SPF
Council control SPF? If not, who does? What about spf3.x and forward?

As usual, just my 2 cents.

Mike

---

From: wayne <[email-masked]>
Date: Wed, 15 Jun 2005 11:04:04 -0500

> Council control SPF? If not, who does? What about spf3.x and forward?

By submitting the SPF and SID drafts to the IETF, all of us have
accepted that the IETF has a great deal of control over the spec.  The
IESG has said that, in order to be fair to SID and not show favoritism
to SPF, both the SPF and SID drafts can say whatever they want about
the use of SPFv1 records and that the SPF draft will be held back
until the SID drafts are ready.  Also, in order to be fair to SID, the
IESG is discounting the 1.5 years of deployment experience with SPF so
that both SPF and SID can start collecting deployment information now.
OK, I can't start collecting data now, because the IESG refuses to
tell me what kind of data they want to see.  I'm sure this is to be
fair to SID.

Yes, the IESG is being very even handed and fair.

</heavy sarcasm>

For a slightly more realistic/accurate view of what the IESG actually
said, see: http://thread.gmane.org/gmane.mail.spam.spf.council/312

-wayne

---

From: "Hector Santos" <[email-masked]>
Date: Wed, 15 Jun 2005 12:40:03 -0400

----- Original Message -----
From: "Douglas Otis" <[email-masked]>
To: <[email-masked]>
Cc: "IMB Recipient 1" <[email-masked]>;
<[email-masked]>
Sent: Wednesday, June 15, 2005 10:29 AM
Subject: Re: [spf-help] Re: SPF and SenderID

> Consider spf2.0/mfrom and _removing_ v=spf1 as the safe reaction to

First,  thanks for not writing a thesis on the subject.

Second..................

Oh stop it Doug.

Sender-ID will go down in the annals of computer history as yet another
PAYLOAD "Get Pass the Door" security exploit that Microsoft pushes upon the
industry in the name of non-existence "virtual email security innovation."

It does not qualify as part of the "Trust Worthy Initiative" and Gates will
put another foot in his mouth if he claims it is.

Sender-ID is an unreliable PAYLOAD protocol and this is NOT want the
industry is looking for.  So you can keep down this ad-nausem path of
knocking SPF every which way but loose,  those who support Sender-ID will
suffer scalarbility consequences of getting killed with higher bandwidth
payloads.  Hackers will BLAST away higher payloads just to help create the
scale issues.  Customers who "just do it" because its part of the MS package
will then begin to blame MS as to why they didn't concentrate on a TRANSPORT
solution BEFORE THE JUNK is transferred  I predict corporate mal-practice
and negligence suits because MS was very aware of the consequences.

If our customers want it, they will have to add it via MAIL FILTER hooks. We
will not take responsibility for fuzzy 2822 mail analysis technique and we
will NOT de-emphasize the R&D required for 2821 methods.   Our system is
nearly 90-98% spam proof purely based on 2821 transactions.

Do you really understand the issue?  I really don't think you do. It is
quite simple.  A SPF FAIL is a FAIL.  PERIOD.  SENDER-ID is saying to NOT
accept this response and to ACCEPT the PAYLOAD to do more checking on
INFORMATION that MAY NOT be there and if was, the end results can just be as
POOR in trust.

--
Hector Santos, Santronics Software, Inc.
http://www.santronics.com

---

From: Frank Ellermann <[email-masked]>
Date: Wed, 15 Jun 2005 19:34:49 +0200

> Yes, the IESG is being very even handed and fair.

This case of excessive technical incomptence or outright
corruption is so far limited to _one_ member of the IESG. 

                     Bye, Frank

---

From: Arnt Gulbrandsen <[email-masked]>
Date: Wed, 15 Jun 2005 20:17:15 +0200

Frank Ellermann writes:
> This case of excessive technical incomptence or outright corruption is 
> so far limited to _one_ member of the IESG.

Just a question: Does that IESG member happen to think that SPF suffers 
from poor workmanship?

Arnt

---

From: wayne <[email-masked]>
Date: Wed, 15 Jun 2005 14:14:47 -0500

In <XrOhwSthhKOKU/[email-masked]> Arnt Gulbrandsen <[email-masked]> writes:

> Just a question: Does that IESG member happen to think that SPF
> suffers from poor workmanship?

I have heard no such direct comment on the "workmanship".  I suspect
that many people in the IESG, like many others outside, find the
subject of MTA Authorization Records In DNS (MARID) to be a
controversial subject.

I think David Kessens comments indicate that he doesn't particularly
like SPF:
https://datatracker.ietf.org/public/pidtracker.cgi?command=view_comment&id=30894

Russ Housley echos those concerns:
https://datatracker.ietf.org/public/pidtracker.cgi?command=view_comment&id=31013

Harald Alvestrand seems to think that the wordsmithing, at least, is
pretty good:
https://datatracker.ietf.org/public/pidtracker.cgi?command=view_comment&id=30972

It might be best to look at the entire datatracker for SPF:
https://datatracker.ietf.org/public/pidtracker.cgi?command=view_id&dTag=12662&rfc_flag=0

-wayne

---

From: "william(at)elan.net" <[email-masked]>
Date: Wed, 15 Jun 2005 13:47:53 -0700 (PDT)

On Wed, 15 Jun 2005, Arnt Gulbrandsen wrote:

>
> Frank Ellermann writes:
>> This case of excessive technical incomptence or outright corruption is so 
>> far limited to _one_ member of the IESG.
>
> Just a question: Does that IESG member happen to think that SPF suffers from 
> poor workmanship?

I think it was quite clear that IESG wording had nothing to do with
technical merits of the proposal(s) and was due to political pressure.
And that is what worries me that IETF/IESG could be manipulated like that.

-- 
William Leibzon
Elan Networks
[email-masked]

---

From: Dean Anderson <[email-masked]>
Date: Wed, 15 Jun 2005 19:05:25 -0400 (EDT)

> defined in draft-lyon-senderid-pra-01

I don't think you can conclude this. The patent claims haven't been 
released. All that happened is that MS identified that it has patent 
interests in the draft proposed by MS. That doesn't mean it doesn't have 
patent interests in other drafts proposed by non-MS personnel.

Until the patent issues, and the patent claims are known, you can't say 
just how broad the patent is.

-- 
Av8 Internet   Prepared to pay a premium for better service?
www.av8.net         faster, more reliable, better service
617 344 9000

---

From: Douglas Otis <[email-masked]>
Date: Wed, 15 Jun 2005 18:29:02 -0700

> through a work around that gives validation to the publication of

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.

By excluding a solution for a known problem, how can it be said the
draft for SPF based upon the bounce-address made any attempt to avoid
this situation?  At least Sender-ID accommodates use of the SPF2.0
record.  On April 13, 2004 Wayne, in response to Harry Katz talked about
the use of SPF2.  By August 13, Mark Lentczner announced adoption of the
"spf2.0/" instead of the "v=spf2" by the design team for the
draft-ietf-marid-protocol-01.  Checking the archive, around August 19,
my email warns of the problem of assuming the PRA as a scope for the
v=spf1 record.  On August 25, Meng Wong introduced the "mfrom" scope as
a solution.  This was done amid growing concerns of the licensing
required by Microsoft.

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.

-Doug

---

From: Terry Fielder <[email-masked]>
Date: Wed, 15 Jun 2005 22:34:00 -0400

> participated in the MARID WG that identified this scope related problem,
Point 1: agreed

> and as both of these drafts also credit common authorship, 
Point 2 (Meng): agreed

> it would be
Point 3: Wrong, (Point 1 and point 2 do *not* add up to point 3, but 
good wordsmithing)

> 
> By excluding a solution for a known problem, 
Wrong again, SID is not a solution for *anything*.

> how can it be said the
You are entitled to your (albeit misguided) opinion.

Terry

-- 
Terry Fielder
[email-masked]
Associate Director Software Development and Deployment
Great Gulf Homes / Ashton Woods Homes
Fax: (416) 441-9085

---

From: Frank Ellermann <[email-masked]>
Date: Thu, 16 Jun 2005 05:15:27 +0200

Arnt Gulbrandsen wrote:

> Does that IESG member happen to think that SPF suffers from
> poor workmanship?

That person changed [yes] to [discuss] after he found out that
his removal of one critical "NOT RECOMMENDED" against the PRA-
abuse doesn't fly with the SPF community.  That person did not
propose to remove the offending "SHOULD abuse v=spf1" from PRA.

                           Bye, Frank

---

From: "william(at)elan.net" <[email-masked]>
Date: Thu, 16 Jun 2005 12:47:27 -0700 (PDT)

On Thu, 16 Jun 2005, Ted Hardie wrote:

> A sponsoring AD always has a ballot position of YES when they bring
> a document to the IESG.

I don't think it is always. I will check datatracker more but I've
definitely seen no objections from everyone including sponsoring AD
for some documents (especially individual submissions for information
or experimental track).

> As was documented on the IETF list response to Wayne, there was no support 
> for at this time for publishing the spf draft as a Proposed Standard (to 
> be  clear: the IESG was asked this question at a telechat, and no AD 
> thought it was appropriate).

Could you be more specific on which day this telechat happened and if
the logs/brief summary for it are available?

> The IESG is currently considering moving forward on the basis of an IESG note
> suggested by David Kessens.  Once the IESG agrees that the document set
> is ready, the sponsoring AD position will go back to YES.
...
>> The IESG takes no position about which approach is to be preferred and
>> cautions the reader that there are serious open issues for each approach

I'd appreciate if you discussed more rational that went behind your note
and its text. I do understand that IETF does not wish to take position on
if authenticating PRA or MAILFROM identities is better choice for email.
This is not new and its one of the reason that MARID probably failed as
such decision may not have been something that we could easily find 
consensus on. But it seems to me taking not position on above is different 
then the note that you propose to add to the drafts.

Also it appears to me the IESG criteria for when evaluating documents 
(especially for experimental status) is not necessarily to see if certain 
approach is good or bad for internet future but more importantly to make 
sure that proposal would not directly create problems for something else 
being done at IETF and most important to make sure that the proposal does 
not cause people to violate existing standards. So is my understanding
about this being part of IESG evaluation wrong?

> There has been a lot of discussion of this draft, and this short summary no 
> doubt misses some points, but I hope it clarifies the current state at 
> least somewhat

It clarified some things but as often fr short summaries it raised more
questions. I'd appreciate if you could find more time to discuss the
drafts and how IESG evaluation of them went.

-- 
William Leibzon
Elan Networks
[email-masked]

---

From: johnp <[email-masked]>
Date: Thu, 16 Jun 2005 22:24:07 +0200

This is the relevant extract from the note suggested by David Kessens:

https://datatracker.ietf.org/public/pidtracker.cgi?command=print_ballot&ballot_id=1599&filename=draft-schlitt-spf-classic

" I would have much preferred a solution that would be an extension to SMTP
that simply checks back with one of the official MTA machines as listed
in the
'mx' records for the domain whether the sending machine can be accepted,
or just one simple DNS record with the name of the machine which is capable
of doing the verification. The
resulting protocol would be much simpler as all the configuration of the
MTA doesn't need standarization as this information would not need to be
published since it is not needed by any other than the 'mx' domain.

 From an operational perspective, the DNS solution also has issues since
the DNS administrator is not necessarily the same as the mail
administrator. "

------

Taking these points in turn -

Unfortunately a domain does not have to have an MX record for it to be
used for e-mail. If an A record exists, this is sufficient. Should the
IETF/IESG choose to rectify that situation, the world of e-mail would
already become an easier place to work in.

SPF does have the ability to use a simple DNS record entry which can
include the relevant detailed record from another zonefile, perhaps the
zonefile of a subdomain. This would probably be the method of choice for
large users of SPF, since it eliminates the necessity of maintaining a
lot of records in each individual domain's zonefile.

Operationally, any specialist DNS administrator will be able to
accomodate his Mail administrator counter-part by allowing access to
add, edit or remove the relevant DNS records required by SPF.

Kind regards,

John Pinkerton

Ted Hardie wrote:
> 
> At 5:15 AM +0200 6/16/05, Frank Ellermann wrote:
> 
>> Arnt Gulbrandsen wrote:
>>
> All changes to the state of document are noted in a public ID tracker.
> The URL for the tracker details for the SPF document is:
> 
> a document to the IESG.  Sponsoring ADs often put in what are called
> "placeholder DISCUSS" comments when there are issues raised outside
> of the IESG (since those would otherwise not be tracked).  Those
> should have explanatory text.  In this case,the explanatory text is:
> 
> "Further discussion on the intended status and relationship to
> MARID working group needed."
> 
> This was entered to track the fact that the IESG needed to discuss 
> Wayne's comments
> on the disconnect between his intentions as author and the original 
> draft solicited
> after MARID closed (draft-lentczner).  This discussion has continued 
> through Wayne's
> request that the spf draft be considered for Proposed Standard, rather 
> than Experimental.
> It also encompasses the problems raised by forwarding both documents; these
> were raised both within and outside the IESG, and the IESG had discussed 
> them
> at great length.
> 
> As was documented on the IETF list response to Wayne, there was no 
> support for
> at this time for publishing the spf draft as a Proposed Standard (to be 
> clear:  the
> IESG was asked this question at a telechat, and no AD thought it was 
> appropriate).
> is ready, the sponsoring AD position will go back to YES.  For those who 
> find
> navigating the tracker hard (and it can be non-intuitive), here's the text:
> 
>> The following documents  (draft-schlitt-spf-classic, 
>> draft-katz-submitter,
>> draft-lyon-senderid-core, draft-lyon-senderid-pra) are published 
>> simultaneously
>> as Experimental RFCs, although there is no general technical
>> consensus and efforts to reconcile the two approaches
>> have failed.  As such these documents have not received full IETF review
>> and are published "AS-IS" to document the different approaches as
>> they were considered in the MARID working group.
>>
>> and concerns about using them in tandem. The IESG
>> believes that documenting the different approaches does less harm
>> than not documenting them.
>>
>> The community is invited to observe the success or failure of the
>> two approaches during the two years following publication, in
>> order that a community consensus can be reached in the future.
> 
> 
> The document names would be replaced by RFC numbers by the RFC Editor.
> All other instructions to the RFC Editor (that is, all the text trying 
> to reconcile
> the two) has been removed.
> There has been a lot of discussion of this draft, and this short summary 
> no doubt
> misses some points, but I hope it clarifies the current state at least 
> somewhat.
>             regards,
>                 Ted Hardie
> 
> 
> 
>

---

From: Ted Hardie <[email-masked]>
Date: Thu, 16 Jun 2005 14:27:42 -0700

>for some documents (especially individual submissions for information

There are two types of Information and Experimental documents; those
which are sponsored by an AD and those which come from the RFC Editor
to be checked for conflict with IETF work.  In the latter case, you may
well see blank spaces, all no-objections, or similar.  In the former case,
it might happen that something does not have a Yes because of something
like a Last Call comment to be resolved simultaneously with IESG review,
but it is unusual and considered as a "yes-->placeholder" collapsed.

The IESG also asks different questions for the two tracks, because there
is a set of IESG Notes automatically added to RFC Editor-sponsored documents.
The review instructions for AD sponsored Informational and Experimentals is:
>
>Reviews should focus on these questions: "Is this document a reasonable
>contribution to the area of Internet engineering which it covers? If
>not, what changes would make it so?"

The review instructions for RFC Editor-sponsored Informational and 
Experimentals is:
>
>The IESG will use RFC 3932 responses: 1) The IESG has not
>found any conflict between this document and IETF work; 2) The
>IESG thinks that this work is related to IETF work done in WG
><X>, but this does not prevent publishing; 3) The IESG thinks
>that publication is harmful to work in WG <X> and recommends
>not publishing at this time; 4) The IESG thinks that this
>document violates the IETF procedures for <X> and should
>therefore not be published without IETF review and IESG
>approval; 5) The IESG thinks that this document extends an
>IETF protocol in a way that requires IETF review and should
>therefore not be published without IETF review and IESG approval.
>
>Other matters may be recorded in comments to be passed on
>to the RFC Editor as community review of the document.

>>support for at this time for publishing the spf draft as a Proposed 
>>Standard (to be  clear: the IESG was asked this question at a 
>>telechat, and no AD thought it was appropriate).
>

It was the June 9th telechat; the minutes get approved at the following
telechat (a week from today), and they'll be public then.  The response
to Wayne contains all the data, though:  the IESG considered it, but did
not find support for it.

>consensus on. But it seems to me taking not position on above is 
>different then the note that you propose to add to the drafts.

Just to be clear, David Kessens proposed the note; there has been 
some wordsmithing
by others, but he was the person who brought it forward.  I believe David has
some basic concerns about the usability of either approach as well as concerns
about using them in tandem.  I don't want to speak for David, but I think
these were not limited to the question of which identity is at issue.

>Also it appears to me the IESG criteria for when evaluating 
>documents (especially for experimental status) is not necessarily to 
>see if certain approach is good or bad for internet future but more 
>importantly to make sure that proposal would not directly create 
>problems for something else being done at IETF and most important to 
>make sure that the proposal does not cause people to violate 
>existing standards. So is my understanding about this being part of 
>IESG evaluation wrong?

See above for the evaluation instructions.

		regards,
				Ted Hardie

---

From: Ted Hardie <[email-masked]>
Date: Thu, 16 Jun 2005 10:39:52 -0700

This was entered to track the fact that the IESG needed to discuss 
Wayne's comments
on the disconnect between his intentions as author and the original 
draft solicited
after MARID closed (draft-lentczner).  This discussion has continued 
through Wayne's
request that the spf draft be considered for Proposed Standard, 
rather than Experimental.
It also encompasses the problems raised by forwarding both documents; these
were raised both within and outside the IESG, and the IESG had discussed them
at great length.

As was documented on the IETF list response to Wayne, there was no support for
at this time for publishing the spf draft as a Proposed Standard (to 
be clear:  the
IESG was asked this question at a telechat, and no AD thought it was 
appropriate). 

The IESG is currently considering moving forward on the basis of an IESG note
suggested by David Kessens.  Once the IESG agrees that the document set
is ready, the sponsoring AD position will go back to YES.  For those who find
navigating the tracker hard (and it can be non-intuitive), here's the text:

>The following documents  (draft-schlitt-spf-classic, draft-katz-submitter,

The document names would be replaced by RFC numbers by the RFC Editor.
All other instructions to the RFC Editor (that is, all the text 
trying to reconcile
the two) has been removed. 

There has been a lot of discussion of this draft, and this short 
summary no doubt
misses some points, but I hope it clarifies the current state at 
least somewhat.
			regards,
				Ted Hardie

---

From: "william(at)elan.net" <[email-masked]>
Date: Thu, 16 Jun 2005 18:02:38 -0700 (PDT)

> but it is unusual and considered as a "yes-->placeholder" collapsed.

Thank you for your explanation.

>> not, what changes would make it so?"

If I understand based on IESG notes, it appears you're unable to answer
the above question clearly. In particular that you say:
  "As such these documents have not received full IETF review and
   are published "AS-IS" to document the different approaches"
and:
  "The IESG takes no position about which approach is to be preferred and
   cautions the reader that there are serious open issues for each approach
   and concerns about using them in tandem"

>> therefore not be published without IETF review and IESG approval.

So with RFC-Editor drafts, IESG is asked to evaluate the draft for 
conflict with other standards and IETF work, but not necessarily
say that it agrees with it. That is good explanation, thank you.

Nevertheless it is unclear to me why the above points would in the
same way not apply to AD-sponsored drafts. If anything it would
indicate that as initial criteria for being "sponsored" the draft
would already have to have passed all above evaluation items and is
now being considered by IETF not just as individual contribution for
documentation of existing work but as something IETF is expected to 
provide some kind of approval on (even if its just for experiment).

And overall (especially after reading your new note) the situation
seems to be that SPF & SID drafts can not find approval of IESG
so while they started as sponsored work, perhaps the situation right
now (with IESG note saying that you just want it documented) is
closer to the kind of documentation one would expect with draft being
submitted through RFC-Editor. So I think it maybe more appropriately
for IESG to directly reexamine evaluation criteria for the drafts and
work with them in the say way you would work as if it were drafts
coming from RFC-Editor.

> Just to be clear, David Kessens proposed the note; there has been some 
> wordsmithing by others, but he was the person who brought it forward.
> I believe David has some basic concerns about the usability of either 
> approach as well as concerns about using them in tandem.

The problem is not just using them "in tandem", using in tandem would mean
somebody doing both SPF and SID check on his/her system. The problem we 
have is different in that both drafts attempt to rely on the same record 
but use it differently, this is collision of namespaces for different 
experiments and it does seem like its something that IESG should be 
seriously concerned with.

> I don't want to speak for David, but I think

Is it possible to ask David to come to this list and explain more about
his concerns?

-- 
William Leibzon
Elan Networks
[email-masked]

---

From: Douglas Otis <[email-masked]>
Date: Fri, 17 Jun 2005 12:56:33 -0700

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.

>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.

> 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

---

From: Terry Fielder <[email-masked]>
Date: Sun, 19 Jun 2005 08:12:57 -0400

Douglas Otis wrote:
> 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

---

From: Douglas Otis <[email-masked]>
Date: Mon, 20 Jun 2005 04:33:12 -0700

> have to use an XML format"

Part of the pitch for the SPF syntax, during the transition from the
bounce-address to the PRA, included using the _exact_ syntax to avoid
causing a change to the existing record.  It has become obvious, this
was a mistake from the point of view of the bounce-address-only
proponents.  It is also clear from the onset of the requests to publish
SPF records, little consideration has been given to the potential
outcome when reputation is applied.

Although I repeatedly warned SPF does NOT prevent spoofing and that this
assumption is dangerous for those that share outbound MTA servers, this
caution was never heeded.  The typical response from various proponents
has been, "It is the publisher's fault for not considering these
potential problems."  It is also the proponent's fault for failing to
provide _any_ warning regarding these concerns.

It is rather outrageous to see statements like "Everyone and their dog
should publish SPF records."  This advice should include, "provided you
and your dog control exclusive access to the authorized outbound MTA."
If the MTA is being shared, then you and your dog should be indemnified
by your outbound service provider against their not maintaining your
exclusive use of both the bounce-address and the PRA.   

It is not surprising that SPF promoters don't care what problems they
may cause the average mailbox-domain owner.  Often these promoters are
bulk email service providers or network service providers looking to
escape accountability when one of their customers abuses email.  An
understandable goal and one safely achieved using email signatures,
rather than SPF.

With signatures, the providers would not alter signed messages nor
attempt to evaluate SPF.  With SPF, providers would need to evaluate
user/mailbox-domain permissions for the bounce-address and the PRA, or
place their customers in serious peril.  Signatures expect nothing from
the providers.  Whereas, SPF expects much more from providers, without
providing any ramification when they fail these added duties.

Sender-ID wants to change Sender-Header handling in conflict with the
much safer signature scheme.  SPF wants to change the bounce-address
handling and place providers at risk with its poor level of security.
The risk and incompatibility created by either SPF or Sender-ID is
without merit, when there is a much better and safer alternative
possible.

Remember, SPF is simply an historical document that attempts to capture
SPF as it was before Sender-ID had been adopted, according to Meng.
Sender-ID is the only active document relevant to the application of the
SPF record, in his view.  Sender-ID now permits evaluation of both the
bounce-address and the PRA.  It seems that the SPF classic group are
confused about the current relevance of their document.  The problem of
requiring assurances for the PRA or publishing a record destined to be
refused seems of little concern. 

To get a better understanding why SPF is historical, and that only
Sender-ID defines use of the SPF record read:
http://spf.pobox.com/whitepaper.pdf

-Doug

---

From: Douglas Otis <[email-masked]>
Date: Mon, 20 Jun 2005 04:35:04 -0700

-Doug