Subject: Work plan for Sender ID

From: Andrew Newton <[email-masked]>
Date: Mon, 13 Sep 2004 18:03:23 -0400

Due to the fact that we released statements in two separate messages, 
there seems to be some confusion on how we intend this working group to 
proceed on Sender ID.

First, the PRA document is not being dropped.  Instead, we are 
proceeding with a document set that includes a non-encumbered (as far 
as we know) scope, "mailfrom", in addition to the "pra" scope.  As we 
stated before, the objection to PRA is based on questions of deployment 
caused by incompatibilities with open source licenses.  However, there 
were also a significant number for responses from participants stating 
that they had no such deployment issues.

Second, it does not make sense to discuss alternatives to PRA if those 
alternatives may be reasonably inferred to be covered by the patent 
application (though not necessarily the license) since this working 
group does not wish to discount Microsoft's patent application.  And 
since we do not know the specific claims of the patent application, 
construction of such an alternative would need to take into account a 
few things we do know:
    1. The patent application covers at least -core and -pra in 
combination.  There is no reason to think that Microsoft's application 
is limited to the technology in these two drafts.
    2. It does not cover MAIL FROM because this question has been 
specifically asked of Microsoft.
    3. The algorithm in -pra has changed through multiple revisions of 
the draft(s).
This would seem to at least exclude any scopes that use 2822 headers to 
identify the party most recently responsible for injecting the message.

We hope to have a schedule as soon as possible.

-andy

---

From: Daniel Quinlan <[email-masked]>
Date: 13 Sep 2004 16:23:49 -0700

> that they had no such deployment issues.

Andrew, that is all true, but I think the interoperability of
deployments needs to be considered more strongly.  To use a reverse
analogy, I would not want the IETF to standardize a protocol that was
only reasonably licensed for use in GPL software (like some IBM Linux
patents are).  Deploying "pra" from when most receivers are unable to
implement it seems like a major deployment issue.
 
> group does not wish to discount Microsoft's patent application.

For example, I believe the "fetchmail" alternative is:

a. possibly not encumbered by the Microsoft patent(s) and we could find
   out from Microsoft upon publication of the specification
b. more likely to result in an invalidated patent *if* the patent
   application also covers the algorithm due to prior art

Then, would it not be a good idea to encourge the workgroup to begin
work on additional scopes in parallel with the other scopes?  At worst,
we would decide they were no less encumbered than PRA, but *both* (a)
and (b) would have to go against them for that to be the case.

> [...]

I'm really confused as to why you think that's true.  I think my
reasoning is sound, can you explain why the chairs think a parallel
effort on additional "backup" scopes (which has been suggested by more
than a few people) should be ruled out?  I don't want to delay the
initial release of a "mailfrom" scope, but I also don't think we should
wait to work on "fetchmail" (or whatever) and "helo" until after the
others are done.  By waiting, I think we might paint ourselves into a
corner where the entire specification is rejected because only
"mailfrom" is deemed interoperable by the email community as a whole and
the "pra" scope is too much of a de-facto requirement.

Daniel

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

---

From: Yakov Shafranovich <[email-masked]>
Date: Mon, 13 Sep 2004 20:09:21 -0400

> the "pra" scope is too much of a de-facto requirement.

We can always ask Microsoft as has been done with MAILFROM. We can ask 
Harry whether Wayne´s current draft falls under the IPR claims, and the 
fetchmail algorithm. If there is a definitive negative, than we are in 
the clear.

Yakov

---

From: Andrew Newton <[email-masked]>
Date: Mon, 13 Sep 2004 21:09:06 -0400

On Sep 13, 2004, at 7:23 PM, Daniel Quinlan wrote:

> I'm really confused as to why you think that's true.

The long answer:
   Because the Microsoft IPR claim calls out -pra and -core in 
combination.  And we know the algorithm has changed.  And that is why I 
wrote "This would seem to at least exclude any scopes that use 2822 
headers to identify the party most recently responsible for injecting 
the message." And I suspect it is actually broader than that.  
Therefore, using the fetchmail algorithm to do such a thing for 
anti-forgery using DNS records, which is not why the fetchmail 
algorithm is in fetchmail, seems to infringe upon the patent 
application.  No matter what, the IETF cannot decide what is and what 
is not prior art -- courts do that.

The short answer:
   Because if I had written the patent application, that's probably what 
I would have done.

-andy

---

From: Ted Hardie <[email-masked]>
Date: Mon, 13 Sep 2004 18:21:55 -0700

At 4:23 PM -0700 9/13/04, Daniel Quinlan wrote:
>   Deploying "pra" from when most receivers are unable to

Note that deployment of "pra" resource records is not in
any way encumbered.  Zone maintainers may choose to
include a "pra" scope for their domains as information for
those who choose to check it.  Those MTAs who do choose
to check it will find it at some domains and not at others (just as those
who check for the existence of a MARID record will not find it at some
domains and will find it at others).

There have been a number of assertions that there must be
a mandatory scope if there are multiple scopes.  From my
perspective, there has never been a mandatory scope; it
was always up to the zone maintainer to determine whether
or not to put a record into her zone with the relevant data.
An MTA performing a MARID check against a domain with
no MARID record finds no data; an MTA performing a MARID
check against a domain with a MARID record but with a different
scope finds no relevant data.  From an engineering standpoint,
there are differences between the two (a present record with
a different scope would likely have different caching characteristics,
and would require bare minimum parsing), but many of the
key characteristics are the same.  So going in this direction
may not result in the same level of convergence as might
have occurred with a single scope, but it is an improvement
over where we are now, with engineering consequences
that are similar to the original proposal's.

It may be worth noting also that a fair number of folks said
that they would continue to check SPF records once spfv2/pra records
were available, because they reflected different things.  Having
both scopes available allows those records to transition to the new
RR, and supports those who want to check both as well as
those who wish to check one or the other.

>I'm really confused as to why you think that's true.

At least to me, the fact that the PRA algorithm has changed during
the course of the working group's deliberations but the need
for the declaration has not suggests that the original patent
claim covers the *idea* of checking the headers for the most
recent injector into the mail system against a domain-based
record maintained in the forward zone.  Even without that indication,
that is the broadest interpretation of the combination Microsoft
has identified, and many folks have indicated that they wish to
be very cautious in that regard.

That implies to me that other scopes which might later be registered have to
do something other than identify the most recent injector in order to
avoid this particular IPR filing.  Mail_from qualifies now.  If Ned Fred's
assessment is correct, the Sun algorithms would as well, since they
are meant to indicate where to send replies, rather than to identify
the most recent injector.  But they do so by not identifying the
same thing as PRA; anything that *does* the same thing as PRA
may be inferred to be covered by the declaration and license.
If Microsoft makes a different statement, of course, that would
change.  But that is my personal reading of the statements which
have been made.

Have I mentioned this was my personal opinion, said without hats?
It is so.
			regards,
				Ted Hardie

---

From: wayne <[email-masked]>
Date: Mon, 13 Sep 2004 22:39:12 -0500

> those who wish to check one or the other.

The SPFv1 records can not transition to the SPFv2 records unless the
both the MAILFROM and HELO scopes are added.

I again ask that the "v=spf1 " magic number be interpreted as
"spf2.0/mailfrom,helo" in the SenderID spec.

> may be inferred to be covered by the declaration and license.

As has been pointed out several times, the NOTE WELL requirement for
filing drafts and participating in this mailing list requires that
Microsoft employees inform us of any drafts that we are considering
that would be covered by their IPR.  I see no problem with proceeding
with I-Ds that deal with the 2822.From: identity and then, if someone
tells us that they have IPR covering those I-Ds, we can consider our
options.

However, this direction can not even be tried because the co-chairs do
not want to consider *any* alternatives to the PRA.  This will again
lead us to a Hobson's choice of either reject all 2822.From: checks,
or proceed with an encumbered standard that can not be deployed to on
a large percentage of the current MTAs.

I just don't understand this.  If I didn't know better, I would say
that this is an attempt to force acceptance of something that would
otherwise be quickly rejected.

-wayne

---

From: wayne <[email-masked]>
Date: Mon, 13 Sep 2004 22:46:07 -0500

In <[email-masked]> Andrew Newton <[email-masked]> writes:

> stated before, the objection to PRA is based on questions of
> deployment caused by incompatibilities with open source licenses.
> However, there were also a significant number for responses from
> participants stating that they had no such deployment issues.

While there were quite a few people (especially by drive-by posters)
who said that they could deploy SenderID with the PRA, many expressed
reservations about the license anyway and only a few said that they
wanted the PRA.

Since the option of advancing SenderID with out the PRA was never
given, I think it is unreasonable to assume that those that express
support for SenderID were really expressing support for the PRA.

For the people who objected to the PRA due to the patent license, I
can't recall anyone that said that they would accept the PRA if other
scopes were allowed also.

I think that the PRA should be dropped since I can see no way that
there will be a rough consensus for advancing it.  Allowing other
scopes will probably not change any of the votes against the PRA, and
may well change some of the votes for it.

I think continuing with the PRA is a very poor use of this working
group's time.

-wayne

---

From: "Michael R. Brumm" <[email-masked]>
Date: Mon, 13 Sep 2004 22:56:16 -0600

>"spf2.0/mailfrom,helo" in the SenderID spec.

I am also interested in a response to this request. It seems reasonable to
me.

Michael R. Brumm

---

From: "Anne P. Mitchell, Esq." <[email-masked]>
Date: Tue, 14 Sep 2004 01:37:34 -0700

On Sep 14, 2004, at 12:12 AM, william(at)elan.net wrote:

> Dont you think its more appropraite per IETF practice (and based on 
> opinions
> expressed by the majority of participants of this WG) to say and do the
> other way around, that should proceed on the non-encumbered scopes 
> first
> and in addition may consider "encumbered" scopes if they bring enough
> benefits to make it worth deploying and if there are no non-encumbered
> alternatives that can achieve similar results?
>
>> As we  stated before, the objection to PRA is based on questions of
> There have been significant number of objections to PRA on the 
> technical
> ground as well and most of these have not been answered. But IPR issues
> caused so much more discussions that technical problems were not being
> noticed. But to say that IPR issues with deployment is the only 
> objection
> to SenderID/PRA in its correction form is simply incorrect.
>
> I would point out that majority of those expressing support were large
> companies who are actually "end-users" that are willing to enter dns
> records for their domains. This is significantly less important then
> issues of software writers that have to implement capabilities to check
> these records.
>

It would seem that not everyone agrees with you on these points;  from 
a news.com article covering the very discussions going on here (you all 
are aware that the press is reading these archives and reporting on 
what they are reading, right?)...anyways, from a news.com article 
entitled "Standards group scuttles Microsoft e-mail proposal":

"Microsoft spokesman Sean Sundwall said the company would continue with 
its plans
to develop its own proposal, Caller ID for E-mail. In August, Microsoft 
had
feted more than 80 e-mail service providers in Redmond, Wash., as part 
of the
E-mail Service Provider Consortium. Between the company's participation 
in that
group and the Anti-Spam Technical Alliance, Microsoft has done a good 
job of
selling major Internet infrastructure companies on the benefits of its 
proposal.

Sundwall would not say whether the IETF's censure would hinder the 
company's
quest to get its Caller ID proposal accepted as a de facto Internet 
standard.
But he did note that many participants stayed out of the vote on 
Microsoft's
involvement.

"If you look at the number of contributors that (voted), it is very 
small," he
said."

Full article at http://news.com.com/2100-1032-5364075.html

Anne

---

From: "william(at)elan.net" <[email-masked]>
Date: Tue, 14 Sep 2004 00:12:28 -0700 (PDT)

On Mon, 13 Sep 2004, Andrew Newton wrote:

> as we know) scope, "mailfrom", in addition to the "pra" scope. 

Dont you think its more appropraite per IETF practice (and based on opinions
expressed by the majority of participants of this WG) to say and do the 
other way around, that should proceed on the non-encumbered scopes first 
and in addition may consider "encumbered" scopes if they bring enough 
benefits to make it worth deploying and if there are no non-encumbered 
alternatives that can achieve similar results?

> deployment caused by incompatibilities with open source licenses.  

There have been significant number of objections to PRA on the technical
ground as well and most of these have not been answered. But IPR issues
caused so much more discussions that technical problems were not being
noticed. But to say that IPR issues with deployment is the only objection
to SenderID/PRA in its correction form is simply incorrect.

Unless I'm mistaken opensource mail servers account for > 60% of deployed
email servers on the internet. You simply can not discount that majority
of them will not be implementing SenderID (because their email server
software package would not be implementing it).

> alternatives may be reasonably inferred to be covered by the patent 
I disagree. I do not believe we can reasomably infer if the aleternative
is convered by IPR unless that alternative is allowed to be presented.

There is also exist a very "interesting" way of finding out if alternative
is covered by IPR or not. One may send a draft as individual submission
and if Microsoft is aware of the draft being published, it will have to 
disclose that it has IPR claims on what is presented there if their
patent seems to apply for it. If they don't disclose it, we can assume
that the draft had no IPR claims and may then proceed working on it in WG.

> group does not wish to discount Microsoft's patent application. 
There has not been clear consensus of WG wants or does not want to
discount Microsoft patent application, but the number of people on 
this WG arguing to ignore the patent claims were actually highier
then number of people that argued against it.

> And since we do not know the specific claims of the patent application, 

Actually there are good reasons to believe that. Microsoft people have 
specifically commented that their IPR claims do not extend to any of the 
documents alone. This seems to imply that IPR issue is very specific to 
combination of those two documents and does not likely extend further.

> specifically asked of Microsoft.
Good.

>     3. The algorithm in -pra has changed through multiple revisions of 
The changes were minor to account for cases of bad or incomplete header 
data. Order of headers in PRA algorithm has not changed.

> identify the party most recently responsible for injecting the message.

I completely reject this conclusion as not being based on the facts
presented so far to this WG.

Unless you know something of specifics of their patent that we dont I dont
see any base to believe that IPR claims is so widespread to cover ANY 
2822 headers that we may come up with.

Furthermore the "party responsible for injecting the message" is not the
only alternative available to us when working on algorithm that cover
previous hop in the email transaction. And I have alredy given an 
alternative that is not based on it, but based on "party responsible
for transmission of the message on its email network".
 
---
William Leibzon, Elan Networks:
 mailto: [email-masked]
Anti-Spam Research Worksite:
 http://www.elan.net/~william/asrg/

---

From: "william(at)elan.net" <[email-masked]>
Date: Tue, 14 Sep 2004 02:58:17 -0700 (PDT)

> entitled "Standards group scuttles Microsoft e-mail proposal":

Media is reading too much into technical and other discussions going on
this group. This kind of media attention in my view is not helpfull to
the the IETF process. It also allows different sides instead of using
technical arguments inline with IETF process to pressure ietf into making 
possibly bad decisions due to presumed interest from outside based for 
example on wild speculation that they represent large groups (when these 
groups are in fact unwilling to comment directly) and by using interviews,
press-conferences and other vendor organized public events to bolster 
their own image.

It would be great if media stop interfering with our process until the WG 
actually produces standard track RFC documents. At that time, if documents
were produced according with IETF standard process and represent concensus
of WG participants on the technical solution that does not violate existing 
standards, then it becomes an issue of deployment of new standard/protocol
and media exposure becomes very helpfull in widespread adaption of the
new technology.

---

---

From: Tony Finch <[email-masked]>
Date: Tue, 14 Sep 2004 11:54:45 +0100

> For example, I believe the "fetchmail" alternative is:

I don't think the fetchmail algorithm is suitable. It's trying to guess
what the return path was in the absence of any SMTP-time information and
in the presence of crap installations that don't add a Return-Path: field
when delivering into the POP mailbox. A /fetchmail scope would be
semantically identical to a /mailfrom scope, but with some additional
heuristics intended for use with non-standard and misconfigured systems.
This is not appropriate for a technical standard.

Tony.
-- 
f.a.n.finch  <[email-masked]>  http://dotat.at/
SELSEY BILL TO LYME REGIS: SOUTHWEST VEERING WEST 6 TO GALE 8, DECREASING 4 OR
5 OVERNIGHT. SHOWERS. MAINLY GOOD. ROUGH OR VERY ROUGH, BECOMING MODERATE.

---

From: Stephane Bortzmeyer <[email-masked]>
Date: Tue, 14 Sep 2004 13:11:52 +0200

On Tue, Sep 14, 2004 at 02:58:17AM -0700,
 william(at)elan.net <[email-masked]> wrote 
 a message of 30 lines which said:

> It would be great if media stop interfering with our process until
> the WG actually produces standard track RFC documents.

It is of course impossible in a free country. And it would not even be
sensible: face it, IETF working groups no longer work in a purely
technical environment. Their decisions affect the work and lives of
many people and media attention on a public process is perfectly
normal and I wish it goes on (of course, I also wish future papers in
the media to be more informed...)

---

From: "william(at)elan.net" <[email-masked]>
Date: Tue, 14 Sep 2004 02:58:17 -0700 (PDT)

---

---

From: "Anne P. Mitchell, Esq." <[email-masked]>
Date: Tue, 14 Sep 2004 01:37:34 -0700

Anne

---

From: Yakov Shafranovich <[email-masked]>
Date: Tue, 14 Sep 2004 11:06:14 -0400

> and media exposure becomes very helpfull in widespread adaption of the

The Tao of the IETF (RFC 3160) points this out as well (section 8.2):

¨Considering all this, it's not surprising that some IETFers would 
prefer to have the press stay as far away from meetings as possible. 
Having a bit of press publicity for protocols that are almost near 
completion and will become significant in the industry in the next year 
can be a good thing. However, it is the rare reporter who can resist 
over-hyping a nascent protocol as the next savior for the Internet. Such 
stories do much more harm than good, both for the readers of the article 
and for the IETF.¨

Yakov

---

From: Mark Lentczner <[email-masked]>
Date: Tue, 14 Sep 2004 08:27:37 -0700

> "spf2.0/mailfrom,helo" in the SenderID spec.

Since "v=spf1" has always been experimental, and changing over time, 
and hence there is no normative reference for it, I do not think that 
the next round of drafts should include any official endorsement of 
what to do with such records.

That said, I don't see anything wrong with implementations deciding to 
support these records as well.  However, I would caution that it seems 
the opinion of many on this list (myself included), that "v=spf1" be 
treated as valid for only the "mailfrom" scope.  I.e.: as 
"spf2.0/mailfrom".

I note that there is no "helo" scope defined (nor will I support one 
now -- I leave this question for later when we all tackle CSV.)  
Furthermore, the use of the HELO domain in the classic SPF check does 
not constitute a check on the HELO scope:  It is not ascertaining the 
authorization of the use of the domain name in HELO.  The use of the 
HELO domain to construct a MAIl FROM identity when the reverse-path is 
null ("<>") is still checking the authorized use of the domain name as 
a MAIL FROM name.  It does not constitute a blanket assertion about 
domain use in HELO.

	- Mark

Mark Lentczner
http://www.ozonehouse.com/mark/
[email-masked]

---

From: Yakov Shafranovich <[email-masked]>
Date: Tue, 14 Sep 2004 12:50:18 -0400

Mark Lentczner wrote:
> Since "v=spf1" has always been experimental, and changing over time, and 
> hence there is no normative reference for it, I do not think that the 
> next round of drafts should include any official endorsement of what to 
> do with such records.
> 

Would there be anything wrong with a separate informational draft on 
this, especially considering that something like your statement above is 
not readily apparent to implementation authors.

Yakov

---

From: "Anne P. Mitchell, Esq." <[email-masked]>
Date: Tue, 14 Sep 2004 10:22:34 -0700

> the the IETF process.

Well, yes.  But that really wasn't my point so much as that Microsoft 
is saying this about what is going on here, and their plans:

I felt that a fairly interesting data point for what it means for 
several aspects of the discussions going on here.

Anne

---

From: wayne <[email-masked]>
Date: Tue, 14 Sep 2004 13:07:43 -0500

> what to do with such records.

Uh, say what?

Yes, there have been some changes to the SPF spec since last November,
mostly in the area of where can be placed modifiers.  Still the
marid-protocol spec is almost completely compatible with every SPF
spec I can think of.

In all the time that we have been discussing using SPFv1 records in
this working group, I think this is the first time I've heard anyone
claim that they should not be used because they are "experimental."
We have heard for people who say that the PRA scope is not the same as
the mailfrom and helo scope that SPFv1 uses, and therefore the PRA
should have a different record, but that is a different subject.

> a MAIL FROM name.  It does not constitute a blanket assertion about

As far as I can see, this is a distinction without a difference.
SPF-classic would use apply the check_host() function on the HELO
domain in almost exactly the same way that the Unified-SPF HELO check
would.

All HELO domains would are subject to this checking under
SPF-classic, and thus this should be acknowledged.

If you want to continue to make a distinction without a difference,
call this the mailfrom-helo scope, or the null-mailfrom-helo scope or
something.

It completely boggles me that you would suggest throwing out the
deployment of maybe up to a million SPF records deployed over the last
10 months, just because they are "experimental".

-wayne

---

From: Mark Lentczner <[email-masked]>
Date: Tue, 14 Sep 2004 15:38:28 -0700

I worded my post on this topic carefully.  I never said that "v=spf1" 
records "should not be used", nor did I suggest "throwing out the 
deployment of .. SPF records".

I am against them being included as part of the standard.

We should not drag the "v=spf1" records into issues of conformance, 
interoperability, future deployment and/or deprecation, etc.  Let's not 
complicate the situation for publishers of records even more by 
throwing "v=spf1" into the mix.

I am for implementations supporting them.

Of course "v=spf1" records can be almost certainly interpreted at 
"spf2.0/mailfrom".  Surely, any implementation can do this trivially.  
They should.  But when things go wrong with "v=spf1" records, for any 
reason, better for us to be able to all say: "Use the standard"

	- Mark

Mark Lentczner

---

From: Matthew Elvey <[email-masked]>
Date: Tue, 14 Sep 2004 16:50:01 -0700

"v=spf1" MUST be valid for the "HELO" scope or the message/record is not 
compliant enough with the SPF specification to ensure a 'pass'.
Mark's statements to the contrary are incorrect. (Read the spec - the 
SPF I-D - http://spf.pobox.com/spf-draft-200406.txt , which says that 
the HELO check MAY be done on any message. 
Hey, Meng - it's way too hard to find the I-Ds on the site since the 
redesign! )

From the spec:
   "An SMTP sending host MUST also resolve a "pass" for all the
   SPF-conformant domains which appear in the "HELO" or "EHLO" command."

Mark Lentczner wrote:

> [T]he use of the HELO domain in the classic SPF check does not 
> constitute a check on the HELO scope:  

See spec.

> It is not ascertaining the authorization of the use of the domain name 
> in HELO.

See spec.

>   The use of the HELO domain to construct a MAIL FROM identity when 
> the reverse-path is null ("<>") is still checking the authorized use 
> of the domain name as a MAIL FROM name.

See spec.

> It does not constitute a blanket assertion about domain use in HELO.

 See spec.

---

From: wayne <[email-masked]>
Date: Tue, 14 Sep 2004 20:17:51 -0500

In <[email-masked]> Mark Lentczner <[email-masked]> writes:

> [....]

*UGH*

What next?  Implementations should (*wink* *wink*) support ipv4: as an
alias for ip4:?  And prt: is ok for ptr:?  And putting an IP address
on a: is something implementations should support because there are
alread a lot of records out there that have it?

> reason, better for us to be able to all say: "Use the standard"

This is circular reasoning.  Things will go wrong with both the SPFv1
records and SPFv2 records.  By excluding them from the standard you
are by definition making them non-standard.  By making them
non-standard, people will not want to support them, or if they support
them, they won't have anything to guide them.  

How fricken hard it is it put a sentence in the standard that says:

"Records that begin with v=spf1 MUST be interpreted as spf2.0/mailfrom,helo"

-wayne

---

From: [email-masked]
Date: Tue, 14 Sep 2004 21:40:54 -0400

> -----Original Message-----
> From: [email-masked]
> [mailto:[email-masked]]On Behalf Of wayne
> Sent: Tuesday, September 14, 2004 9:18 PM
> To: IETF MARID WG
> Subject: Re: Interpreting "v=spf1"
> 
> 
> 
<snip>

> I am for implementations supporting them.

I see no other choice but then to agree with Wayne v=spf1  ===  spf2.0/mailfrom,helo

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

---

From: Meng Weng Wong <[email-masked]>
Date: Tue, 14 Sep 2004 21:59:34 -0400

On Tue, Sep 14, 2004 at 08:17:51PM -0500, wayne wrote:
| 
| "Records that begin with v=spf1 MUST be interpreted as spf2.0/mailfrom,helo"
| 

I agree with the sentiment behind this suggestion.  It might
even be more useful if v=spf1 records were defined to mean

  spf2.0/pra,mailfrom,helo,pra

or perhaps

  spf2.0/pra,mailfrom,helo,pra,ptr

and if a sender is uncomfortable with those semantics then
they should publish proper spf2.0 records that override the
v1 entries.

---

From: "Anne P. Mitchell, Esq." <[email-masked]>
Date: Tue, 14 Sep 2004 22:26:19 -0700

> Full article at http://news.com.com/2100-1032-5364075.html

Additionally, InfoWorld today has an article with quotes from an email 
statement from Microsoft made on the issues -  a search for the quotes 
turned up nothing, so I surmise that it was an email likely sent 
directly to the reporter, or forwarded to the reporter from an original 
recipient.  I assume these are of interest to the group at this point 
because the information contained herein may have bearing on in what 
direction people want to go from here - please let me know if that is 
not the case:

"In an e-mail statement, Microsoft said that MARID's decision "does not 
mean Sender ID has been rejected," but that changes proposed by MARID 
will make the standard more flexible. Microsoft is "excited to continue 
our collaboration with industry stakeholders to help move this 
important authentication protocol forward" and sees a future in which 
"complementary technologies" will be used with Sender ID to fight spam.
...

In its statement, Microsoft said that the Sender ID framework has 
essentially been accepted, and that MARID's decision only means there 
will be "an alternative spoof checking mechanism to the proposed PRA 
check."

"While we would have preferred a single technical mechanism as the 
standard, we believe this proposal to allow multiple scopes in the 
protocol is a reasonable approach to provide additional choice and 
flexibility," Microsoft said in the statement."

---

Particularly taken with the quote from News.com, I read this as an 
indication that they plan to move forward on their own with Sender I.D. 
regardless of what recommendations or other standards may come from 
this group.  What their end goal is, and how this fits with the current 
recommendations here, I wouldn't hazard to say, and leave as an 
exercise to the reader.

Full article at:

http://www.infoworld.com/article/04/09/14/HNietfmsblow_1.html

---

From: Mark <[email-masked]>
Date: Wed, 15 Sep 2004 05:50:07 GMT

>> "Records that begin with v=spf1 MUST be interpreted as

I am in favor of this.

>  spf2.0/pra,mailfrom,helo,pra

Could you clarify this, please? I mean, currently, pra is not part of 
v=spf1, right? I could see v=spf1 to mean this, though:

spf2.0/mailfrom,submitter,helo

I am not really sure, though, whether "helo" should be mentioned as a 
separate entity. It feels to me that "helo" is an implicit part of the 
mailfrom check (namely in the case of MAIL FROM: <>).

> they should publish proper spf2.0 records that override the

As soon as this workgroup decides on its syntax, I will publish such new 
records. :)

Well, having said that, in reality I will probably wind up publishing both 
types of records, so as not to break downward compatibility.

- Mark

---

From: Matthew Elvey <[email-masked]>
Date: Tue, 14 Sep 2004 23:26:32 -0700

>I think continuing with the PRA is a very poor use of this working
I agree with the majority.  If a small minority (the Chairs) wish to 
continue to claim that is not what the WG is doing, I won't try to stop 
them. But the WG is not interested in PRA, for reasons well expressed 
by, e.g. William Leibzon in this thread.  And that's what DOES matter, 
because this is the IETF, and that's how things work here.  It would be 
nice if the several clear requests of the Chairs to eliminate 
IPR-encumbered solutions from the running not be given short shrift, but 
then elimination of the encumberances would be nice too.  Instead, 
document authors need to produce new drafts intended to meet the 
chartered work items, and a consensus call on them is needed*.  
Marid-mpr is such an item.   They will find rough consensus if they are 
well written and well defended, because, again, this is the IETF.   If 
you try to ram junk through, you induce posts like this.

*Contrast this sentence with the fait-accompli tone of "The document 
authors have agreed to producing new drafts intended to meet the 
chartered work item, and a consensus call on them or the appropriate 
diffs will be forthcoming."  I had written "*new* document authors ..." 
but Meng just posted again about HELO, so there's hope...

=-=-=-=-=

More media coverage of MARID - FYI:
http://www.theregister.co.uk/2004/09/13/ietf_bounces_sender_id/

BTW, if anyone is following nanae or nanabl and has noticed interesting 
threads discussing our work here, I'd be interested in links.  Some of 
the battle-hardened know rather well what tricks spammers [might] use.
Kinda answered my own question - found some months old posts:
I found support from Bill Cole: (who posts here too, seems to be letting 
folks there know of milestones reached - thanks.)
http://groups.google.com/groups?hl=en&lr=&ie=UTF-8&safe=off&threadm=bill-55E121.16123407082004%40fireproof.scconsult.com&rnum=3&prev=/groups%3Fnum%3D20%26hl%3Den%26lr%3D%26ie%3DUTF-8%26safe%3Doff%26scoring%3Dd%26q%3Dmarid%2Babuse%26btnG%3DSearch
Anton Squeegee: <sic>
http://groups.google.com/groups?hl=en&lr=&ie=UTF-8&safe=off&threadm=bill-55E121.16123407082004%40fireproof.scconsult.com&rnum=3&prev=/groups%3Fnum%3D20%26hl%3Den%26lr%3D%26ie%3DUTF-8%26safe%3Doff%26scoring%3Dd%26q%3Dmarid%2Babuse%26btnG%3DSearch
Vernon Schryver: tough criticism, but answerable with something that's 
easy enough to implement that it can become mandatory in a reasonable 
time period:
http://groups.google.com/groups?hl=en&lr=&ie=UTF-8&safe=off&threadm=bill-6C26C6.21474829072004%40fireproof.scconsult.com&rnum=4&prev=/groups%3Fnum%3D20%26hl%3Den%26lr%3D%26ie%3DUTF-8%26safe%3Doff%26scoring%3Dd%26q%3Dmarid%2Babuse%26btnG%3DSearch

---

From: Margaret Olson <[email-masked]>
Date: Wed, 15 Sep 2004 11:00:33 -0400

> they should publish proper spf2.0 records that override the

No. If the standard supports spf1 then spf1 must mean *exactly* what it 
means today. Otherwise you are just introducing chaos.

Margaret.

---

From: Frank Ellermann <[email-masked]>
Date: Thu, 16 Sep 2004 02:50:41 +0200

Margaret Olson wrote:

> No. If the standard supports spf1 then spf1 must mean
> *exactly* what it means today. Otherwise you are just
> introducing chaos.

Seconded.  There is no "PRA" in all existing "v=spf1"
policies.  There is a "HELO" in draft-mengwong-spf-01.txt

Partially optional on the side of the receiver, if I read
this correctly.  But no nonsense on the side of the sender
(or rather the domain owner = author of the v=spf1 policy).

One of our co-chairs proposed that we shouldn't discuss CSV
and HELO before we are ready with spf2.0/mailfrom.  In that
stage an old v=spf1 policy can be handled as spf2.0/mailfrom.

If a HELO scope is added later, and if it's still essentially
the same as in v=spf1, then a v=spf1 policy could be handled
as spf2.0/mailfrom,helo.  But not as PRA.

                          Bye, Frank