Subject: Re: Appeal: Publication of draft-lyon-senderid-core-01 in conflict with referenced draft-schlitt-spf-classic-02

From: Bob Braden <[email-masked]>
Date: Fri, 9 Dec 2005 13:41:38 -0800 (PST)

This thread has contained several suggestions that publication of
an RFC in the Experimental category constitutes an "IETF experiment".
I cannot find any evidence from RFC 2026 that there is any such thing
as an "IETF experiment" or "IETF-sanctioned experiment".  Section 4.2.1
of RFC 2026 explains what "Experimnental" means on an RFC.

Bob Braden

_______________________________________________
Ietf mailing list
[email-masked]
https://www1.ietf.org/mailman/listinfo/ietf

---

From: John Levine <[email-masked]>
Date: 9 Dec 2005 22:14:01 -0000

> I cannot find any evidence from RFC 2026 that there is any such
> thing as an "IETF experiment" or "IETF-sanctioned experiment".

Me neither.  Since neither the SPF nor the Sender-ID crowds appear to
have any interest in modifying their specs, that doesn't sound like an
experiment to me, IETF or otherwise.

I'd suggest the most sensible thing to do is to reclassify both of them
as Informational, to document what you might find in some TXT records,
publish them, and be done with it.

Regards,
John Levine, [email-masked], IRTF ASRG chair

---

From: Dave Crocker <[email-masked]>
Date: Fri, 09 Dec 2005 14:42:50 -0800

> publish them, and be done with it.

Yes. This seems like exactly the right choice, since it is what is 
typically done for documenting
existing practise that is outside the IETF process.

d/

---

From: Frank Ellermann <[email-masked]>
Date: Fri, 09 Dec 2005 23:58:39 +0100

Bob Braden wrote:

> I cannot find any evidence from RFC 2026 that there is any
> such thing as an "IETF experiment" or "IETF-sanctioned
> experiment".

Yes, that's tricky.  Some folks including me were surprised
that there's no "IETF last call" for experimental RFCs, unless
they are the product of an IETF WG (4.2.3).  That's one of the
reasons why the v=spf1 author and others wanted PS.  The AD of
the former MARID WG wanted to handle this as some kind of post-
MARID experiments without "IETF last call".  The IESG sticked
to this plan.

v=spf1 is not really an "experiment" anymore after two years
with about 1,000,000 published records one year ago, and it's
not really "IETF" without "last call" (not for lack of trying).

                           Bye, Frank

---

From: wayne <[email-masked]>
Date: Fri, 09 Dec 2005 18:22:10 -0600

> experiment to me, IETF or otherwise.

Well, I dunno.  I solicited comments on the SPF draft on several IETF
mailing lists a couple of times and made changes based on those
comments.

What exactly do you think needs to be changed with the SPF draft?

-wayne

---

From: wayne <[email-masked]>
Date: Fri, 09 Dec 2005 18:37:03 -0600

> an RFC in the Experimental category constitutes an "IETF experiment".

This is, in part, due to the directions of the IESG.  For example, the
IESG note that will be placed at the top of these drafts refer to
things like a two year observation period.  So, while there isn't
anything in RFC2026 that documents what the IESG has requested, I
don't think the "experiment" term is being thrown around quite as
loosely as might first seem.

Still, I think you are correct that this is not your typical
"experimental" RFC process and people should be careful not to read
too much into the term.

-wayne

---

From: John Levine <[email-masked]>
Date: 10 Dec 2005 06:04:21 -0000

>What exactly do you think needs to be changed with the SPF draft?

If you want to document what people do with SPF now, nothing other
than making it Informational.

If you actually want to do experiments, change the record format so it
won't be confused with Sender-ID or anything else and you can tell
what the results of your experiments are.

R's,
John

PS: "We want to do experiements but those Sender-ID meanies won't let
us" doesn't fly.

---

From: Brian E Carpenter <[email-masked]>
Date: Sat, 10 Dec 2005 10:04:30 +0100

I remind people that the IESG has completed its appeal
handling for these documents. People are certainly entitled
to their opinions, of course, but the IESG appeal process
has ended.

     Brian

---

From: Frank Ellermann <[email-masked]>
Date: Sat, 10 Dec 2005 12:41:59 +0100

John Levine wrote:

> change the record format so it won't be confused with
> Sender-ID

Confusing strings "v=spf1" and "spf2.0" is not impossible,
but difficult enough, no change needed.

> you can tell what the results of your experiments are

Only if you strictly use different local parts in PRA and
MAIL FROM, otherwise you can't be sure what the other side
actually tried to check.  Example with a fresh snapshot:

<http://article.gmane.org/gmane.mail.spam.spf.discuss/19908>

> "We want to do experiements but those Sender-ID meanies
> won't let us" doesn't fly.

I'm not interested to experiment with PRA for my mail, let
alone with mails of others.  It's no rocket science to tell
precisely where, when, and why this cannot work.

If you're looking for the next guy saying "whatever you do,
give it to ITU or to anybody, but not to the IETF", then
you've found him.  I despise "opt out" schemes.

                              Bye, Frank

---

From: wayne <[email-masked]>
Date: Sat, 10 Dec 2005 11:47:37 -0600

> existing practise that is outside the IETF process.

This really doesn't have anything directly to do with the SPF I-D, but
more about IETF process.

The idea that individual submissions would be Information RFCs was
something I believe for quite a while.  However, a year ago, I
checked, and found quite a few standard track RFCs that were
from individual submissions.

I just checked again, and in the last several months, I found over a
dozen individual submissions and *none* of them were approved as
Informational.  Most were Proposed Standard.  While some of them were
the result of working groups that had dissolved and such, many (most?)
were only reviewed by one or more working groups.

Is this a change/evolution in IETF procedures from days-gone-by?

The ones I found were:

'Internet Message Access Protocol (IMAP) -  UIDPLUS extension' to Proposed Standard
'Media Type Specifications and Registration  Procedures' to BCP
'MIME Type Registration for MPEG-4' to  Proposed Standard
'MIME Type Registrations for 3GPP2  Multimedia files' to Proposed Standard
'Domain Name System Uniform Resource  Identifiers' to Proposed Standard
'Domain Name System (DNS) Security  Extensions Mapping for the Extensible Provisioning Protocol (EPP)' to  Proposed Standard
'Identifiers and Test Vectors for  HMAC-SHA-224, HMAC-SHA-256, HMAC-SHA-384, and HMAC-SHA-512' to  Proposed Standard
Protocol Action: 'Deprecation of "ip6.int"' to BCP
'Improved Arcfour Modes for the Secure Shell  (SSH) Transport Layer Protocol' to Proposed Standard
'The AES-XCBC-PRF-128 Algorithm for the  Internet Key Exchange Protocol (IKE)' to Proposed Standard
'Lightweight Directory Access Protocol  (LDAP) schema definitions for X.509 Certificates' to Proposed Standard
'The LDAP entryUUID operational attribute'  to Proposed Standard
'LDAP Proxied Authorization Control' to  Proposed Standard
'Guidelines and Registration Procedures for  new URI Schemes' to BCP

-wayne

---

From: Sam Hartman <[email-masked]>
Date: Sat, 10 Dec 2005 13:03:24 -0500

>>>>> "Frank" == Frank Ellermann <[email-masked]> writes:

    >> thing as an "IETF experiment" or "IETF-sanctioned experiment".

    Frank> Yes, that's tricky.  Some folks including me were surprised
    Frank> that there's no "IETF last call" for experimental RFCs,
    Frank> unless they are the product of an IETF WG (4.2.3).  

That's actually not true.  The responsible AD can issue a last call
for an experimental draft.

The AD in question chose not to do so.

---

From: John C Klensin <[email-masked]>
Date: Sat, 10 Dec 2005 16:08:54 -0500

--On Saturday, 10 December, 2005 11:47 -0600 wayne
<[email-masked]> wrote:

>>> I'd suggest the most sensible thing to do is to reclassify
>>> both of them as Informational, to document what you might
>>> find in some TXT records, publish them, and be done with it.
>> 
>> Yes. This seems like exactly the right choice, since it is
>> what is  typically done for documenting
> This really doesn't have anything directly to do with the SPF
> I-D, but more about IETF process.
> 
> The idea that individual submissions would be Information RFCs
> was something I believe for quite a while.  However, a year
> ago, I checked, and found quite a few standard track RFCs that
> were from individual submissions.

Sure.  The process has always permitted non-WG documents to be
approved as standard track documents if there is sufficient
evidence of quality, appropriateness, and community consensus
behind them.

> I just checked again, and in the last several months, I found
> over a dozen individual submissions and *none* of them were
> approved as Informational.  Most were Proposed Standard.
> While some of them were the result of working groups that had
> dissolved and such, many (most?) were only reviewed by one or
> more working groups.

This is because many (I don't have statistics, but they could be
pulled out if needed) individual (or "independent" -- there is a
subtle difference that I can't keep straight) go directly to the
RFC Editor for publication.   Those are _all_ Informational or
Experimental, since standards-track docs cannot be published
without IESG signoff (presumably based on IETF consensus).  More
or less since RFC 3932 was published a bit over a year ago, you
can distinguish Informational docs approved by the IESG (with
the implications of that consensus) from those submitted
directly to the RFC Editor by observing that the latter now bear
a rather pointed "you can't believe everything you read and
should probably not believe this" disclaimer.

> Is this a change/evolution in IETF procedures from

The only change was that in the years starting somewhat over a
decade ago and presumably ending with 3932, the IESG took a more
aggressive review and intervention role on documents submitted
to the RFC Editor than it supposedly does today.  The other
change is that, as the RFC Editor has gotten backed up,
increasing priority has been given to getting IESG-approved
documents out relative to submissions to the RFC Editor.  That
has occasionally resulted in the processing queue for
independent submissions direct to the RFC Editor grinding to a
near-halt.   But there have been no substantive changes on the
standards-track, or WG Informational, processing side of the
equation.

   john

---

From: Harald Tveit Alvestrand <[email-masked]>
Date: Sun, 11 Dec 2005 00:23:55 +0100

> Is this a change/evolution in IETF procedures from days-gone-by?

Actually it's an interpretation of RFC 2026, the basic rulebook for 
standards-track documents - so while practice may have varied a bit, the 
procedures are (in theory) the same as always.

There's an exposition of the various kinds of processing in RFC 3710, "An 
IESG Charter", which describes what the IESG thought the process for non-WG 
documents was like in spring 2003.

See section 5, especially section 5.2.1 and 5.2.2.

                    Harald

---

From: wayne <[email-masked]>
Date: Sat, 10 Dec 2005 21:34:06 -0600

In <[email-masked]> Harald Tveit Alvestrand <[email-masked]> writes:

>> Is this [non-WG I-Ds going to PS] a change/evolution in IETF
>> procedures from days-gone-by? 
>
> [...]
> There's an exposition of the various kinds of processing in RFC 3710,

Thanks.  While I have read RFC2026 quite a few times, I had not seen
RFC3710.  It does clear up some of the questions I had.

-wayne

---

From: Sam Hartman <[email-masked]>
Date: Sun, 11 Dec 2005 15:34:57 -0500

>>>>> "wayne" == wayne  <[email-masked]> writes:

    wayne> In <[email-masked]> Bob Braden
    wayne> <[email-masked]> writes:
    >> This thread has contained several suggestions that publication
    >> of an RFC in the Experimental category constitutes an "IETF
    >> experiment".

    wayne> This is, in part, due to the directions of the IESG.  For
    wayne> example, the IESG note that will be placed at the top of
    wayne> these drafts refer to things like a two year observation
    wayne> period.  So, while there isn't anything in RFC2026 that
    wayne> documents what the IESG has requested, I don't think the
    wayne> "experiment" term is being thrown around quite as loosely
    wayne> as might first seem.

I have to agree.  While typically the term experimental RFC does not
imply an IETF experiment, I think this is a bit more organized.  

I'm not sure there actually is an IETF experiment.  However the IESG
has more or less said that anyone wanting to move one of these
technologies onto the standards track needs to come back in some
period of time and demonstrate an IETF experiment took place and
present some conclusions.

Put slightly differently, we cannot force there to be an IETf
experiment.  We can encourage people to conduct such an experiment.
We can make an experiment of that type a pre-condition for being on
the standards track.  People then need to decide whether having an
Internet standard in this space is worth the effort of conducting such
an experiment and eventually changing their protocol to resolve the
conflicts.  If people don't think that's worth the effort, that's
fine; then instead of being an experiment these RFCs will turn into a
documentation of some practice people are deploying on the internet.

so, yes the IESG is sort oof putting an optimistic spin on things by
calling it an experiment.  We're hoping people will want to come back
some day, fix the problems and make a standard.

It's clear to me that neither SPF nor Sender ID could achieve the
necessary rough consensus to be a standard-track protocol.

That sometimes happens.  The IETF is good at solving problems where
rough consensus is the appropriate decision making mechansim.  Some
problems work well that way.  Some do not.  If your problem does not
achieve rough consensus the perhaps the IETF is not the right place to
bring it [1].  In my mind the major tragidy of marid seems to be that
we were very inefficient at realizing we could not get consensus.  It
would have been a lot more efficient, professional and desirable if
people had worked to understand each other and then stated what their
constraints were and on what issues they could not budge.  If there
was no way to satisfy all the stakeholders pack up early and go home,
but do so with respect and understanding.

Perhaps I'm wrong.  Here's a challenge to anyone who believes they can
get a consensus on this issue.  Go get a proposal together and get
agreement from the major stakeholders involved in marid that they will
support your proposal.  Ask to publish as an individual submission on
the standards track.  If you succeed, the IESG will end up looking
rather foolish.  Personally I'd rather play the part of a fool and end
up fixing a big problem than forever fail to reach some important
understanding.

If you do decide to take me up on this challenge I can try to answer
process questions in personal mail.  I cannot guarantee that I'll have
a lot of time particularly as questions become more complicated.

--Sam

---

From: Frank Ellermann <[email-masked]>
Date: Sun, 11 Dec 2005 23:59:57 +0100

Sam Hartman wrote:

>> Some folks including me were surprised that there's no
>> "IETF last call" for experimental RFCs, unless they are
>> the product of an IETF WG (4.2.3).

> That's actually not true.  The responsible AD can issue
> a last call for an experimental draft.

Where do I miss that provision in 2026, is it something
covered by chapter 9 (variance procedure) ?

Checking the 2026 updates I skipped 3667/3668/3978/3979.

Do 3.4 / 3.5 in 3912 address this "for the case where an
IETF protocol is proposed to be changed or extended in an
unanticipated way that may be harmful to the normal usage
of the protocol, but where the protocol documents do not
explicitly say that this type of extension requires IETF
review" ?  

OTOH 3.4 / 3.5 don't say "MAY start a last call", they're
about attempts to bypass a required "last call", or for
the quoted case.

---

From: Frank Ellermann <[email-masked]>
Date: Mon, 12 Dec 2005 00:32:18 +0100

> 3912
s/3912/3932/ (end of <http://tools.ietf.org/html/3932#page-3> )

                      Sorry, Frank

---

From: John C Klensin <[email-masked]>
Date: Sun, 11 Dec 2005 19:56:26 -0500

> about attempts to bypass a required "last call", or for

Frank,

2026 basically discusses the cases where Last Calls are
required, as one would expect.   But, by long-standing precedent
and good sense, the IESG is permitted to Last Call anything they
like on which they might need to make a decision in order to get
a better sense of the consensus or preferences of the community.
Certainly one would not want to argue against that.  

I think that, if an extensive enough search were done, one would
find occasional Last Calls for Experimental documents,
Informational ones, procedural changes or decisions that don't
lead to RFCs such as creation or deletion of areas, and possibly
even things like meeting scheduling.
 
The absence of a requirement for a Last Call on Experimental (or
Informational) does suggest that one would have a lot of trouble
appealing a decision on the grounds that the relevant AD didn't
ask for a Last Call first.  But that doesn't seem to be at issue
here.

    john

---

From: wayne <[email-masked]>
Date: Mon, 12 Dec 2005 13:51:50 -0600

In <[email-masked]> Sam Hartman <[email-masked]> writes:

>     wayne> This is, in part, due to the directions of the IESG.  [...]
>

I have, in the past, argued to the IESG that I did not think the SPF
I-D should be marked Experimental because I did not see it being an
experiment.  It has been out for 2 years now and it is far too widely
deployed to make significant changes.  Instead, I thought it should be
standard track.  I have also said that I could see it being
informational.

I have also, in the past, requested from the IESG some sort of outline
of what the "lessons learned" document should contain.  So far, I have
not received and answer.  The current SPF I-D already has had a lot of
work put into it based off of things that we learned about the actual
deployment of SPF.  I'm not sure what more we should be studying.

So, I'm somewhat perplexed about these "IETF experiments" for SPF and
SenderID.

We don't know what we are supposed to be studying.  They are being set
up in a conflicting way, thus making any results questionable.
SenderID is reusing the Resent-* headers in an incompatible way.
SenderID is self-contradictory in that even if everyone involved
implements it to its fullest, the PRA part of SenderID can't not
distinguish between an email that gets sent to a mailing list and the
forwarded (adding Sender: first, and then Resent-* second), and an
email that gets resent to a mailing list (adding Resent-* first, and
Sender: second).

I confess that the reason why I have worked hard on the current SPF
spec is so that we would have a solid spec for people to work with.  I
have asked for reviews from IETF sources because I think that is
valuable, and it certain was.  (Thanks everyone!)  I am much less
concerned about whether the SPF spec even ends up as an RFC, and if it
does, what kind of label is put on it.

> some day, fix the problems and make a standard.

Well, I can see coming back some day and trying to create an update to
the SPF protocol.  I can't see trying to change SPF version 1.

> necessary rough consensus to be a standard-track protocol.

Well, I guess that all depends on how you count "rough consensus", and
that is something I really don't understand how the IETF defines it.

There are a huge number of people who use DNSBLs and have for many
years.  There are many people who don't like them, to put it mildly.
However, DNSBLs are just a way for one part to publish information and
another to listen to it.  No one is forced to create a DNSBL, no one
is forced to listen, and no one is forced to act on the DNSBL info in
any particular way.

Personally, I think that DNSBLs are well enough understood to put on
the standard track, as long as you ignore complaints from people who
doesn't like the fact that they exist.

Similarly, I think SPF and DKIM could/should be put on the standard
track.  They both cause problems with the way people use email today,
but only for those that want to participate.

-wayne

---

From: Frank Ellermann <[email-masked]>
Date: Tue, 13 Dec 2005 06:32:30 +0100

John C Klensin wrote:

> required, as one would expect.   But, by long-standing
> precedent and good sense, the IESG is permitted to Last
> Call anything they like on which they might need to make
> a decision in order to get a better sense of the consensus
> or preferences of the community.

Makes sense...

> Certainly one would not want to argue against that.

...based on the "old" informational RFC 3710 rules I could:

In chapter 5.2.2 it says "processed in the same fashion as
an Informational or Experimental document from a working
group", in other words an IETF Last Call (RFC 2026 4.2.3).

But as it happens I've already dismissed RFC 3710 as broken
beyond repair after an overdose of its chapter 4.3 in MARID.

> one would have a lot of trouble appealing a decision on the
> grounds that the relevant AD didn't ask for a Last Call
> first.  But that doesn't seem to be at issue here.

Yes, RFC 3710 is only informational, they are not forced to
follow their own published internal rules.

                           Bye, Frank

---

From: Douglas Otis <[email-masked]>
Date: Tue, 13 Dec 2005 08:06:29 -0800

> the SPF protocol.  I can't see trying to change SPF version 1.

The problem with SPF draft is there is no spf2.0/mfrom.  This has little
to do the IETF, but rather a proponent/author with the idea that SPF was
just a snap-shot, offering a new draft that embraced the same DNS record
for much of the same reasons, which suited a particular prolific vendor
that now claims IPR.  Fixing this mistake requires adding scope.  The
short cut of using a TXT record allowed getting the cart before the
horse.

-Doug

---

From: Frank Ellermann <[email-masked]>
Date: Tue, 13 Dec 2005 19:09:16 +0100

Douglas Otis wrote:

> The problem with SPF draft is there is no spf2.0/mfrom.

One week from draft-ietf-marid-mailfrom-00 to the termination
of MARID was a bit short.  And after that the next draft was
again v=spf1 draft-lentczner-spf-00 (same author).  Actually
an emergency draft, because the last real v=spf1 expired at
this time - expecting that MARID creates something better as
far as I was concerned.

The next real thing was draft-schlitt-spf-classic-00 putting
anything that was lost back in, minus some syntax issues found
in MARID, and addressing the processing limit issues.

Whatever you think, but your complaints about the theoretical
upper limit of DNS queries in an attack scenario resulted in
some of the most interesting post-MARID changes (Wayne's I-Ds).

Can't beat CSV of course, but in practice a no-nonsense HELO
policy is now okay, 1 or 2 queries.

                           Bye, Frank

---

From: wayne <[email-masked]>
Date: Tue, 13 Dec 2005 13:07:59 -0600

> some of the most interesting post-MARID changes (Wayne's I-Ds).

This is bunk.

The DoS limits that are in draft-schlitt-spf-classic are almost
exactly the same as those found in the libspf2 implementation I
created.  The analysis of the packet sizes and the expansion factors,
and the writing of libspf2 happened well before MARID was even
started.  I know of one other SPF implemenation, and I think there was
another, that implemented roughly the same limits as I created in
libspf2.  The justification for adding those limits into the SPF spec
was, in large part, because they reflected existing practices.

Doug Otis did complain a lot about the DoS potential, and his
complaints did go unheeded by the draft authors and the working group
chairs.  However, his complaints could not have possibly had any
impact on the current limits in the SPF spec.

-wayne

---

From: Keith Moore <[email-masked]>
Date: Tue, 13 Dec 2005 15:03:18 -0500

> standard track. 

SPF does not meet the requirements for standards track.  It is based on
dubious premises and has too many known technical omissions, and it
also lacks rough consensus.  The fact that it is widely deployed is
irrelevant because IETF does not exist to recognize wide deployment.

---

From: Douglas Otis <[email-masked]>
Date: Tue, 13 Dec 2005 13:16:12 -0800

On Dec 13, 2005, at 11:07 AM, wayne wrote:

> However, his complaints could not have possibly had any impact on  
> the current limits in the SPF spec.

The reduction to 111 DNS lookups is not a resounding impact with  
respect to this concern.  Defending this sequential lookup  
requirement will likely never be tested, as it must become an  
impediment for abusers first.  Abusers remain a substantial portion  
of the initial adopters.  SPF will not likely become a replacement  
for black-hole lists, but instead may be used to implement unfair  
reputations based upon email-address domain owners authorizations.   
This problem is a good reasons for ensuring scope is defined.

SPF is not about validating the purported author of a message.  SPF  
deals with forged return-paths.  For this protection, SPF depends  
upon wide adoption by others before a benefit is obtained, hence the  
reluctance to correct the lack of scope.  BATV, on the other hand,  
provides immediate benefits when forged return-paths are used in DSNs  
(the only place where a return-path is intended to be used).  This  
forged return-path technique is often used to evade black-hole  
lists.  Even with BATV, there are about 6 packets exchanged without  
any data phase for the message, which pales against the benefits  
obtained from a black-hole list which often limits the exchange to no  
more than four when an error message is returned.

Without BATV, another 8 to 30 exchanges often occurs with a forged  
return-path DSN where content is commonly returned.  The DSNs must be  
filtered as the forged return-path has become a common exploit.  The  
heavy filtering of DSNs is troubling as this will reduce the  
integrity of a store and forward SMTP system.  One of the greatest  
benefits of store and forward scheme is efficiency.  Holding open a  
session with the upstream server to check acceptance or for AV and  
Spam filtering completion, is not optimal.  BATV does not require any  
additional DNS lookups or published DNS records.  The BATV tag is  
transparent and can be handled by all existing MTAs.  BATV offers the  
same challenges as any authentication scheme, where the admin must  
know where all their outbound MSAs are located for the domain that  
wishes to filter BATV tags at the MDA.  If the admin misses an MSA,  
or a sender uses the wrong MSA, only the DSN would be at risk.

The forged DSN is a serious problem.  Castigating those willing  
accept email on good faith and then issue DSNs is counter to  
establishing either integrity or efficiency.  Making the forged  
return-path exploit not offer any value for the sender is what _must_  
be done.  There are black-hole list protections at the front-door,  
but no protections at the back-door.  At this point, ensuring common  
acceptance criteria upstream is the only sensible stop-gap measure.   
Something like BATV can return integrity and efficiency to SMTP.  SPF  
does not offer an efficient model going forward, and is in jeopardy  
of establishing a wholly unfair reputation scheme based upon  
authorization and not the actual sending of messages.

-Doug

---

From: "william(at)elan.net" <[email-masked]>
Date: Wed, 14 Dec 2005 07:06:22 -0800 (PST)

On Tue, 13 Dec 2005, Douglas Otis wrote:

> respect to this concern.

You can do setup that involves multiple CNAME and NS redirections
with DNS and it all could come to those 100 lookups. In practice
these setups do not exist though and neither have I seen any serious 
reports of SPF records that cause 100 lookups (your tests that setup
these records on purpose is not good indicator of how administrators 
enter spf records).

> (the only place where a return-path is intended to be used).

Funny how you forget to mention that what is called BATV was invented
by people working on SPF - at first as advanced version of SRS, which
was thereafter released as SES [1] and anybody with technical knowledge
will quickly see that BATV basically implements subset of SES (although
I agree that is the more useful subset of that proposal).

[1] http://ses.codeshare.ca/files/Working_SES_Format_Definition_16.pdf

However it also happens to be that the same subset can be used quite
well with SPF (in a way BATV would never support) - in particular SES 
allows sender to run not only private validating service that checks
incoming email bounces, but also public validating server (using dns 
protocol for confirming verification) which based on given RFC2821 
mailfrom address can say if it is properly signed SES address. This 
allows for for bad bounces to be stopped closer to the source and
knowing new validation system is not required as it can be done with
SPF record (using exists mechanism to redirect to validating server).

The benefit of such combined SPF/SES setup is that if the email
comes directly from the ip block listed in spf record, then extra 
cryptographic validation (and contacting external service) is not
required (and these account for majority of real-life cases) where
as in other cases using SES service can provide results that would
make SPF work with forwarding and for roaming users.

So in practice SES/BATV cryptographic MAILFROM should not be looked
at an alternative to RMX/SPF method. In fact they both are stronger
when combined together, however unfortunately the different proponents 
fail to point this fact to the wider audience (plus BATV proponents 
obviously ignore the history of this concept both when advocating it
and in the written text).

-- 
William Leibzon
Elan Networks
[email-masked]

---

From: Douglas Otis <[email-masked]>
Date: Wed, 14 Dec 2005 08:36:54 -0800

On Wed, 2005-12-14 at 07:06 -0800, william(at)elan.net wrote:
> with DNS and it all could come to those 100 lookups.

Few would expect this to work, nor would that be a _required_ depth. 

> In practice setups do not exist though and neither have I seen any
> serious of SPF records that cause 100 lookups (your tests that setup

Actually there was case that came close to this limit by an access
provider, but was rewritten into CIDR notation to reduce the number of
records, increasing their chances for error.  At the email
authentication summit in NY, there was a large company that complained
they could still not fit into this large limit.  DNS is well designed to
resolve host names and sub-sets of hosts for a domain.  SPF wants this
to always be a complete set, even for multiple domains.

> I agree that is the more useful subset of that proposal).

The idea of tagging the Return-path was not invented by the SPF group.
Something like VERP could be an example.  It would be incorrect to
describe the simplicity of BATV as having a genesis from the SPF group.
RFC2304 could be called the genesis for the idea.  : )

BATV would be the correct choice in my view.  SES attempts the same
everything and the kitchen-sink complexity that could be seen as the
hallmark of SPF, which also makes SPF with its problems an integral
component.

-Doug

---

From: "william(at)elan.net" <[email-masked]>
Date: Wed, 14 Dec 2005 09:42:38 -0800 (PST)

> to always be a complete set, even for multiple domains.

Nobody said it wants to be complete set and that all possible ip
addresses must be entered in one spf record of 512 bytes as ip ranges
(although clearly this can be achieved with majority of domains). And
there are in fact people at SPF that believe that it should be more
properly layered and it is desirable to list mx and host names and then 
those are resolved to ip address by A lookup (i.e. like CSV) even though 
that causes 2 lookups instead of just one.

> RFC2304 could be called the genesis for the idea.  : )

I did not say "tagged" return path - certainly VERP is predecessor to
SRS in that idea. I did say encrypted address, i.e. using private (or 
public) encryption scheme to create custom "tag" for use in return-path - 
this is what SES is about and what BATV afterward used as well.

> hallmark of SPF, which also makes SPF with its problems an integral

The difference is purely semantic in different formats for return-path
tag. Thereafter you have a choice of which schemes to use which BATV
does not describe in the draft at all and SES describes in quite a bit
of detail but in practice if you don't want to use particular scheme,
you dont have to (as far as I know most people who use SES are doing 
similar with HMAC private scheme as what one person using BATV does).

And BTW as I mentioned similar also applies for its use, SES can be
used independent of SPF implemented on the sender site only processing
incoming bounces, 100% same as BATV. But it can also [optionally] be
implemented as external service [again optionally] integrated with SPF. 
These are all extra functionality one does not have to use if he/she 
does not want to.

What is clear to me is that SES people did not publish their spec right 
and should have separated it into several documents - one describing 
MAILFROM tag semantics [doc 100% equivalent to BATV] and then couple
documents describing signature schemes and then document describing 
public dns validation service and another one for special alternative
udp validation. I told them as much and as you know at some point tried 
to advocate that BATV and SES work together because I thought BATV has
done a good job on writing semantics draft already (which could be made
compatible with everything else with just few changes), where as SES
have done fairly good job describing other details for cryptographic 
signature generation, etc. Unfortunately neither group had any serious
interest in working together.

And as far as my opinion using BATV/SES together with SPF makes more
sense - both in reducing computation cryptographic computation when
it does not have to be used and also because by itself BATV/SES are
easily suspectable to a replay attack.

-- 
William Leibzon
Elan Networks
[email-masked]

---

From: Frank Ellermann <[email-masked]>
Date: Wed, 14 Dec 2005 18:38:10 +0100

william(at)elan.net wrote:

> in practice SES/BATV cryptographic MAILFROM should not be
> looked at an alternative to RMX/SPF method. In fact they
> both are stronger when combined together, however
> unfortunately the different proponents fail to point this
> fact to the wider audience (plus BATV proponents obviously
> ignore the history of this concept both when advocating it

Unfortunate that might be, but you really can't expect me to
talk about something that doesn't exist as an I-D (like SES),
or where I came to the conclusion that it doesn't work from
my POV as end-user (like BATV).

Anybody experimenting with combinations will be "delighted" to
learn that (s)he's now expected to "opt out" from PRA first.

Personally I'm more interested in the RMX side of pure SPF, is
RMX "based on dubious premises" as Keith said here recently ?
<http://permalink.gmane.org/gmane.mail.spam.spf.discuss/19922>

If that would boil down to "I don't like it" his conclusion
"no rough consensus" would fail:  There are tons of RfCs like
3865 where personal tastes don't enter the picture.

If that boils down to "1123 5.3.6(a) is no bug" I'd disagree
vehemently.  Besides SPF doesn't force anybody to participate,
there are even ways to participate on the PASS side and still
stay away from the FAIL-side.

Maybe a PASS is already good enough to implement say RfC 3834.
I doubt that he could find a serious bug in SPF.  The trouble
is that he (and some other experts) had no reason to try hard
so far without "last call".

That "last call" business is quite fascinating, everywhere:

It will also affect DKIM SSP, will they get away below PRA, or
could they as well copy your appeal and give up ?  What about
a 2476ter (8.1 in 2476bis doesn't mention Resent-*) ?  What's
the idea of the MUST in 2822 and your appeal, is this a bug ?

Or almost completely unrelated, hell freezes before CRAM-MD5
and ESMTPA die only because Sam doesn't like it, he's forced
to prove his point(s) in a "last call" for "2195bis historic".

                            Bye, Frank

---

From: Douglas Otis <[email-masked]>
Date: Wed, 14 Dec 2005 12:18:24 -0800

On Dec 14, 2005, at 9:42 AM, william(at)elan.net wrote:

> easily susceptible to a replay attack.

An anonymous replay attack would require harvesting.  Obfuscating  
signatures within a return-path tag could become a normal practice  
without affecting the value of any archive.  The signature also  
allows harvesting to be traced.  As this information is temporal, it  
would require an ongoing criminal activity, which works in favor of  
tracing bad actors. : )

Private key one-way hash computational overhead is much less than  
making even a single DNS lookup. The prominent syntax difference  
between SES and BATV reflects a desire to nest the entire  
encapsulation resembling Russian matryoshka nesting dolls, whereas  
this free-form nesting was avoided in the BATV format.  Tony Finch  
made a security argument against the SES encapsulation, as it would  
also make visual exploits easier.  The difference does not result in  
any specific limitation of one syntax over the other except, for  
ensuring the mode tag is defined and can extend beyond the use of a  
single character. : )

SES:
=<mode><glob>=<local-part>@<domain>
=<mode'><glob'>=<local-part'>=<mode><glob>=<local-part>@<domain>

BATV:
<prvs>=<local-part>/<glob>@<domain>
<nest>=<local-part>/<glob>/<mode'>/<local-part'>/<glob'>@<domain>

If desired, a nested version of BATV could encapsulate a prior local- 
part based upon a "defined" mode.

-Doug

---

From: Sam Hartman <[email-masked]>
Date: Wed, 14 Dec 2005 16:20:53 -0500

Frank> Sam Hartman wrote:
    >>> Some folks including me were surprised that there's no "IETF
    >>> last call" for experimental RFCs, unless they are the product
    >>> of an IETF WG (4.2.3).

    >> That's actually not true.  The responsible AD can issue a last
    >> call for an experimental draft.

    Frank> Where do I miss that provision in 2026, is it something
    Frank> covered by chapter 9 (variance procedure) ?

It's certainly current IESG procedure that we can last call
informationals and experimentals.  I don't know that 2026 does or
needs to say anything about it.  Unless it is forbidden it seems like
a reasonable decision making tool for the IESG to apply in some cases.

---

From: Douglas Otis <[email-masked]>
Date: Wed, 14 Dec 2005 13:58:26 -0800

> learn that (s)he's now expected to "opt out" from PRA first.

The "opt-out" of PRA is actually "opt-in" using the "spf2.0/pra ?all"  
record.

This PRA record would likely still fall within the unabashed  
definition of "authorized-authenticated".  : (

These concerns were expressed here:
http://www.imc.org/ietf-mxcomp/mail-archive/msg05502.html

-Doug

---

From: Frank Ellermann <[email-masked]>
Date: Wed, 14 Dec 2005 22:46:18 +0100

Sam Hartman wrote:

> seems like a reasonable decision making tool for the IESG
> to apply in some cases.

Yes, thinking about ways to enforce a "last call" I ended up
with some evil DoS attack scenarios.  If authors insist on it
they could still try to add something where "IETF consensus"
is required.
                        Bye, Frank

---

From: Frank Ellermann <[email-masked]>
Date: Thu, 15 Dec 2005 03:06:45 +0100

Douglas Otis wrote:

> The "opt-out" of PRA is actually "opt-in" using the
> "spf2.0/pra ?all" record.

No, the PRA spec. claims that you "SHOULD" get PRA for a pure
v=spf1 policy, and if you don't want PRA for whatever reasons
you have to "opt-out" from PRA with a dummy spf2.0/pra policy.

That's "opt-out" like the opt-out-doubleclick cookie, "don't-
call-me" lists, and similar schemes.  Of course the SPF spec.
says that checking other mail identities (not limited to PRA)
against v=spf1 without the prior and explicit consent of the
v=spf1 publisher is NOT RECOMMENDED.

> http://www.imc.org/ietf-mxcomp/mail-archive/msg05502.html

It's almost a year older and also known as "Olson objection".

 From my POV it was always obvious, I used a cute 2476 MSA with
"enforced submission rights" (6.1) and a Sympa mailing list in
2004, and both would result in PRA FAIL for legit mail from me
if checked against my v=spf1 policy (IIRC set up in May 2004).

                             Bye, Frank