Subject: clarification on consensus call for compromise

From: Andrew Newton <[email-masked]>
Date: Thu, 9 Sep 2004 14:21:03 -0400

There seems to be some confusion on the proposal on table and on
the next steps which it implies.  To clarify that, it seems important
to step back a bit.  The co-chairs have judged that there is no 
consensus
to move forward with the documents as they entered last call.  Since
the issues with documents do not relate to the syntax of the record,
the DNS-based mechanism, or the fundamental architecture (e.g.
application of these tests by an MTA), the co-chairs have focused the
next steps on how to retain the work which has garnered consensus
and move forward.  To do that, the co-chairs suggest that the existing
documents be modified so that the group creates a standard that:
describes the DNS-based mechanism, the MTA's application
of tests, and a modified syntax which is explicitly scoped.

In order to ensure that there are scopes for which there is no known
IPR encumbrance, the co-chairs propose a new document describing
a mail_from scope.  The PRA scope would also be one of the scopes 
initially
described, as there is clearly sufficient interest in checking pra to
allow it to move forward as one among several scopes (interest being
judged both on public statements and deployed code).  An IANA registry
for additional scopes created by Standards Track RFCs would be created.

Under such a system, it would be up to the zone maintainer to determine
which scopes to provide data on.  It would be up to the MTA running
the check to determine which checks to run.  No single scope would
be mandatory to provide or check; it would simply be mandatory that
someone populating a record use a valid, registered scope.  The
existence of scopes which an MTA does not choose to check take up
packet space in the DNS response, but have no other effect.  While
the existence of at least one mandatory to implement scope would
be beneficial, the co-chairs do not see consensus emerging around
any single scope during the lifetime of this group.  In order not
to abandon this work completely, the appropriate thing to do is
to allow the fundamental mechanism move forward with the options
that have emerged.  Over time, deployment will tell us whether either
of these scopes is successful.

For a real consensus call on this proposal, new documents must
be produced which describe it in full.  Those would be based on
the existing documents and the co-chairs anticipate that they would
be closely related to the existing proposals, at least in regards to
the elements of the system for which we already have consensus.
The document authors have agreed to take on the work required to
undertake the additional work to make this new attempt to reach
overall consensus.

This is not a call for alternate suggestions, nor is it a consensus call
on the documents which have not yet been produced.  It is the
chairs' work plan for meeting this chartered goal of this working
group:

Aug 04 Submit working group document on MTA Authorization Record in DNS 
to PS

Once the documents have been produced, working group discussion of the
protocol engineering and deployment will proceed using the same subject
line headers as before, and we will move through that discussion to a 
second
last call.

-andy, co-chair of MARID

---

From: "william(at)elan.net" <[email-masked]>
Date: Thu, 9 Sep 2004 15:07:48 -0700 (PDT)

I don't know if there was any confusion, but it appears I understood 
you perfectly and answered with negative exactly based on that correct
understanding that group is going to standartize scopes without any
hope that they will be able to be used worldwide - this is not a a way
to create a "standard".

Your calls for letting market decide if any "scope" is sucessfull also
suggests that we'll not have a standard for a while (until the market
made the decision...) As such the working group documents for each scope 
should be listed as EXPERIMENTAL while only the protocol should be listed 
as STANDARD when they are submitted to RFC editor for publication. 

That means that IANA registry should be maintained not only for STANDARD 
track RFCs related to scope but for EXPERIMENTAL ones as well - and it is 
probably best that IANA registry is setup to make such distinction, i.e.

SPF Scope    Status and description
-------------------------------------------------
MAILFROM     Authorization to use RFC2821 Mail From by SMTP clients
	     as desribed by EXPERIMENTAL RFCxxxx

---

From: Max Kanat-Alexander <[email-masked]>
Date: Thu, 09 Sep 2004 14:57:57 -0700

On Thu, 2004-09-09 at 11:21, Andrew Newton wrote:
> the check to determine which checks to run.

	Does the IPR really cover the syntax of the published record? I thought
the only significant IPR was the PRA algorithm itself, on the MTA side.
Why not just leave the IPR question only in the hands of the MTA folks,
and just let people publish their records unscoped?

	Would there be specific examples in which this would cause a terrible
problem?

	I think that would make deployment much easier.

	-Max
-- 
Maxwell Kanat-Alexander
2nd Level Tech Support Engineer, USA
Kerio Technologies, Inc.
2041 Mission College Blvd. Suite 100
Santa Clara, CA 95054
Phone: (408) 496-4500
Fax: (408) 496-6902
Web: http://www.kerio.com/support.html

---

From: Ted Hardie <[email-masked]>
Date: Thu, 9 Sep 2004 15:37:52 -0700

>and just let people publish their records unscoped?

An unscoped record would be meaningless, as the MTA checking the
record would not know which identity was at issue.  This has been
covered before; please read the archives.
			regards,
				Ted Hardie

---

From: AccuSpam <[email-masked]>
Date: Fri, 10 Sep 2004 08:59:54 +0800

\
>>and just let people publish their records unscoped?

I support scoping what the published data means "these are the approved mail servers for this domain" but not scoping which experimental and incomplete algorithm the data is intended for.

>covered before; please read the archives.

Apologies if I am not aware of the specific posts you are referring to.

Nevertheless, I fail to see how publishing "the approved mail servers for sending e-mail from a domain" is an amibiguous "identity" without algorithm scope?

Seems to me that your implication that someone would need to publish different mail servers depending on whether the Return-Path or PRA header is being evaluated is not mainstream.  And I have asserted that once you publish the data in the DNS, you have no control over how receivers are going to evaluate that data any way.  Since none of the scoped algorithms give a 100% final result, it is obvious that receivers are going to experiment with many algorithm scopes.

Please enlighten me on the past discussion about "identity" as an algorithm instead of as "approved mail servers"?

Also do you think the average users can ever be educated on the nuances of their use of e-mail relative to some complex permutations of algorithm scopes and multiple DNS records?

---

From: wayne <[email-masked]>
Date: Thu, 09 Sep 2004 20:50:06 -0500

> for additional scopes created by Standards Track RFCs would be created.

Andy, I just don't understand this.  While there is clearly sufficient
interest in using the PRA by some people, there are also many who
object to such a patent encumbered RFC advancing.  I can't see how you
think you will get consensus for the PRA advancing later.  If you
intend to ignore the objections, why don't you just advance it now?

Since before this working group was founded, there was clearly
sufficient interest in using the MAIL FROM in the form of
SPF-classic.  If "sufficient interest" is an adequate reason for
pushing an RFC, why was SPF-classic put on the back burner?

> chairs' work plan for meeting this chartered goal of this working

Ok, let me understand this.  We can't put forth alternatives to the
PRA, but you can pull a incompatible version of SPF-classic out of
your hat?

The case of patent encumbered crypto has been mentioned several
times.  As has been repeatedly pointed out, RFCs that allow patent
encumbered crypto almost(?) always include options for unencumbered
crypto that can be used in the same problem space.

I vehemently object to advancing marid-pra unless there is at least
one unencumbered proposal that covers the 2822.From: identity.
(marid-pra becoming unencumbered is obviously one way of erasing my
objection.)

-wayne

---

From: Daniel Quinlan <[email-masked]>
Date: Thu, 09 Sep 2004 23:29:10 -0700

Andrew Newton <[email-masked]> writes:

> IPR encumbrance, the co-chairs propose a new document describing a
> mail_from scope.  The PRA scope would also be one of the scopes
> initially described, as there is clearly sufficient interest in
> checking pra to allow it to move forward as one among several scopes
> (interest being judged both on public statements and deployed code).

I believe there has been a lot more interest in not using the patented
approach and replacing it with an unencumbered technique.  In addition,
I believe most of the statements of support have been for Sender ID
itself, not specifically for leaving PRA in as an option.  A good number
of the statements of support for Sender ID also suggested removing PRA,
finding a way to adopt Sender ID without PRA, etc.

> chairs' work plan for meeting this chartered goal of this working

If the chairs feel it is necessary to actively advocate patented
material when we have barely explored unencumbered alternatives, barely
consider interoperability, and fix the specification in stone before it
is ready -- all in order to meet our time goals, perhaps we should
request changes to the charter.

Daniel

-- 
Daniel Quinlan
http://www.pathname.com/~quinlan/

---

From: "Scott Kitterman" <[email-masked]>
Date: Fri, 10 Sep 2004 10:24:55 -0400

> -----Original Message-----
> From: [email-masked]
> [mailto:[email-masked]]On Behalf Of Andrew Newton
> Sent: Thursday, September 09, 2004 2:21 PM
> To: IETF MARID WG
> Subject: clarification on consensus call for compromise
>
PRA isn't what I would think of when I think of the word scope.  The scope
within which PRA operates is the 2822 message header.  Within this scope
there is more than one way to determine which header field is appropriate to
use.  PRA is one way.  There are others.

If scope were defined by the type of data used to make a determination vice
the method, then I believe there is a limited, bounded set of potential
scopes that can be defined now.  Pick different names if you want, but I
think they are:

1. Envelope [2821] ~ mail_from
2. Header [2822] (I would include SUBMITTER here since it's an early look at
this scope)
3. HELO (separate from Envelope because it relates to the MTA and not the
message)

If defined in this manner, then PRA is one potential method to evaluate the
Header scope, but there are others.  This would let work on the documents
upon which there is some agreement move forward while preserving the
possibility of eventually reaching rough consensus on an approach for the
Header scope.  I put this forward in the hopes that this will meet the
objections of those that strongly object to any standard going forward that
includes PRA as currently licensed.

Done this way, I don't think there's a need for an IANA registry of scopes.
What there will be is an eventual set of RFCs that describe appropriate
methods for evaluating each scope.  There may even be more than one per
scope if they are demonstrated to be interoperable.

There is also a need to define the inter-relationship of the different
scopes, but once defined that would be static and dependable.  The variable
remaining for future drafts is how to evaluate the individual scopes in
isolation.

Scott Kitterman

---

From: Frank Ellermann <[email-masked]>
Date: Sat, 11 Sep 2004 03:30:10 +0200

AccuSpam wrote:

> Seems to me that your implication that someone would need to
> publish different mail servers depending on whether the
> Return-Path or PRA header is being evaluated is not
> mainstream.

It is.  PRA does not work with legacy MUAs and MSAs, where the
sending site doesn't insert a "Sender" matching the MAIL FROM
(to overrule a 2822-From not matching the MAIL FROM).

In other words I daily send mails with "my" 2822-From, which
would FAIL in a PRA-Test, because "my" sender policy has scope
MAIL FROM and not PRA.

> none of the scoped algorithms give a 100% final result

If "my" MAIL FROM results in a FAIL, then this is 100% final,
and if it results in a PASS then that's also 100% final.  And
"my" 2822-From results in a 100% final NONE when it happens to
be the PRA.
                            Bye, Frank