Subject: [spfbis] I-D Action: draft-ietf-spfbis-experiment-07.txt

From: [email-masked]
Date: Tue, 24 Apr 2012 12:04:42 -0700

A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the SPF Update Working Group of the IETF.

	Title           : Resolution of The SPF and Sender ID Experiments
	Author(s)       : Murray S. Kucherawy
	Filename        : draft-ietf-spfbis-experiment-07.txt
	Pages           : 11
	Date            : 2012-04-24

   In 2006 the IETF published a suite of protocol documents comprising
   SPF and Sender ID, two proposed email authentication protocols.
   Because of possible interoperability issues, particularly but not
   only those created by simultaneous use of the two protocols by a
   receiver, the IESG was unable to determine technical consensus and
   decided it was best to publish all of RFC4405, RFC4406, RFC4407 and
   RFC4408 as Experimental documents.  The IESG invited the community to
   observe their deployments for a period of time, and expressed hope
   for later convergence of opinion.

   After six years, sufficient experience and evidence have been
   collected that the experiments thus created can be considered
   concluded.  This document presents those findings.

A URL for this Internet-Draft is:
http://www.ietf.org/internet-drafts/draft-ietf-spfbis-experiment-07.txt

Internet-Drafts are also available by anonymous FTP at:
ftp://ftp.ietf.org/internet-drafts/

This Internet-Draft can be retrieved at:
ftp://ftp.ietf.org/internet-drafts/draft-ietf-spfbis-experiment-07.txt

The IETF datatracker page for this Internet-Draft is:
https://datatracker.ietf.org/doc/draft-ietf-spfbis-experiment/

---

From: "Murray S. Kucherawy" <[email-masked]>
Date: Tue, 24 Apr 2012 19:07:15 +0000

> -----Original Message-----
> From: [email-masked] [mailto:[email-masked]] On Behalf Of [email-masked]
> Sent: Tuesday, April 24, 2012 12:05 PM
> To: [email-masked]
> Cc: [email-masked]
> Subject: [spfbis] I-D Action: draft-ietf-spfbis-experiment-07.txt
> 
> A New Internet-Draft is available from the on-line Internet-Drafts
> directories. This draft is a work item of the SPF Update Working Group
> of the IETF.
> 
> [...]

- include Dave's suggestions, now that he's out of email jail

- add reference to RFC5507 in the appendix

- add a note that our data are admittedly a cross-section of a complete Internet survey

Co-chairs, I believe this is ready for Working Group Last Call.

-MSK

---

From: Scott Kitterman <[email-masked]>
Date: Tue, 24 Apr 2012 15:27:46 -0400

"The two protocols made use of this same policy statement and some specific 
(but different) logic to evaluate whether  the email client sending or relaying 
a message was authorized to do so." still really bothers me because I think it 
is factually incorrect.

SPF designated a policy statement record and used it.  Sender ID designated a 
policy statement record and used both it and the SPF record.  Papering this 
over is wrong.

I don't expect it to change, but, FWIW, I really disapprove.  Other than that, 
I agree it's ready for last call.

Scott K

---

From: Dave Crocker <[email-masked]>
Date: Tue, 24 Apr 2012 12:35:56 -0700

> policy statement record and used both it and the SPF record.  Papering this

It does not paper it over.  It ignores the question of precedence and, 
instead noting the fact of dual use.

It's not that precedence isn't an isn't an interesting question.  It's 
that it is irrelevant to the current topic.

Don't fight battles that distract from the current work.

One could imagine a separate Informational discussion paper that reviews 
the history of this topic, possibly suggesting things that could have 
been avoided and ways that things could have been handled better.

Such a paper might be a useful lesson for public discussion of protocol 
evolution.

d/
-- 
  Dave Crocker
  Brandenburg InternetWorking
  bbiw.net

---

From: "John Levine" <[email-masked]>
Date: 24 Apr 2012 20:49:00 -0000

>that it is irrelevant to the current topic.

It does still present a technical issue.  If you want to implement
Sender-ID, you publish some spf/2.0 records and you're done.  You
don't need to know anything about SPF.

If you want to implement SPF, you publish v=spf1 records, and now you
have to decide what to do about Sender-ID.  Here are the options I see
we could recommend:

1) Learn enough about Sender-ID to publish an spf/2.0 ?all record (or
something similar) so that any Sender-ID users will functionally
ignore what you're doing.

2) Decide that nobody uses Sender-ID, so don't worry about it.

3) Decide that the IESG's concerns about record reuse were
unwarranted, Sender-ID usually produces the same result as SPF, so
don't worry about it.

4) Decide that the IESG's concerns about record reuse were warranted,
so if we're going to advance SPF, we should deprecate Sender-ID.

What am I missing here?

R's,
John

---

From: Scott Kitterman <[email-masked]>
Date: Tue, 24 Apr 2012 19:03:07 -0400

On Tuesday, April 24, 2012 08:49:00 PM John Levine wrote:
...
> ignore what you're doing.
...

That has been the assumption, but we don't actually know that.  Receivers are 
supposed to treat Neutral the same as None, but they don't.  As a practical 
matter there's no way to publish an SPF record and safely opt-out of Sender 
ID.

Scott K

---

From: Andrew Sullivan <[email-masked]>
Date: Tue, 24 Apr 2012 19:26:52 -0400

No hat.

On Tue, Apr 24, 2012 at 07:03:07PM -0400, Scott Kitterman wrote:
> supposed to treat Neutral the same as None, but they don't.

Do I read that correctly as "nobody actually implements the protocol
as specified"?

Best,

A

-- 
Andrew Sullivan
[email-masked]

---

From: Scott Kitterman <[email-masked]>
Date: Tue, 24 Apr 2012 19:31:21 -0400

On Tuesday, April 24, 2012 07:26:52 PM Andrew Sullivan wrote:
> > That has been the assumption, but we don't actually know that.  Receivers
> > are supposed to treat Neutral the same as None, but they don't.
> 

No it's intended as, "The protocol specification says some things about what 
receivers must do.  They don't always do that."

We've had repeated debates about the lack of utility in specifying receiver 
policy.  Receivers will do what they think best deals with the mail stream 
they are facing even if that's not what's in the RFC.

Scott K

---

From: Andrew Sullivan <[email-masked]>
Date: Wed, 25 Apr 2012 10:16:48 -0400

> receivers must do.  They don't always do that."

Ok, so it means _some_ people don't implement the protocol correctly.
Got it.  

So the worry is that SPF users can't opt out of Sender ID "safely"
because some purported Sender ID users actually aren't Sender ID users
(i.e. they're not doing what the protocol document says to do) and
don't do the right thing with the mail.  Correct?  (I'm not trying to
be a pain; I'm trying to get clear on what the problem is supposed to
be.)

Best,

A

-- 
Andrew Sullivan
[email-masked]

---

From: Scott Kitterman <[email-masked]>
Date: Wed, 25 Apr 2012 10:26:31 -0400

On Wednesday, April 25, 2012 10:16:48 AM Andrew Sullivan wrote:
> > No it's intended as, "The protocol specification says some things about
> > what receivers must do.  They don't always do that."
> 

>From a strict standards perspective, I think that's correct.  The real world 
isn't so black and white.

I do think that at some point if SPF is a standards track protocol and Sender 
ID isn't, someone needs to say that the Sender ID experiment is over (where 
over means "don't do that anymore."  I'm not sure when, who, or how, but I 
think "Using a standards track protocol entangles you in an experiment you 
can't escape" is not a sustainable position.

Scott K

---

From: Hector Santos <[email-masked]>
Date: Wed, 25 Apr 2012 11:13:35 -0400

> be a pain; I'm trying to get clear on what the problem is supposed to

I always believed this was a "Maximum Coverage" issue more than 
incorrect publishing possibilities.

Legend:

SMTP-SPF1  MSA/MDA with 4408 support only
SMTP-SPF2  MSA/MDA with 4405-4408 support
DNS-SPF1   Domain/MTA publishing for 4408 support
DNS-SPF2   Domain/MTA publishing for 4405-4408 support

+====================================+
|            SPF1 vs SPF2            |
|   Receiver vs Publishing Support   |
|                                    |
|          +-------------------------|
|          | SMTP-SPF1  |  SMTP-SPF2 |
|----------+------------+------------|
|DNS-SPF1  |    OK      |    OK      |
|----------+------------+------------|
|DNS-SPF2  |  conflict  |    OK      |
+------------------------------------+

For the market base focusing on SIDF, it may come with the presumption 
that all receivers will cover SPF1 and SPF2.  Not possible with a pure 
4408 deployment site unless dual SPF1 records were added as well by 
the SIDF.

Anyway, you get the idea.

-- 
Hector Santos, CTO
http://www.santronics.com
http://hector.wildcatblog.com

---

From: Andrew Sullivan <[email-masked]>
Date: Wed, 25 Apr 2012 11:23:32 -0400

No hat.

> isn't so black and white.

Got it, thanks.  Unfortunately, we're writing protocols, and not a
guide to the real world, so we have to interpret things protocol-y,
i.e. in a way I wouldn't actually run my life.

> can't escape" is not a sustainable position.

"Don't use the Internet?"  The fact is that once something is
deployed, it is _impossible_ to get it back, and the IETF doesn't
have an enforcement arm.  It seems likely to me that the real
mechanism for making Sender ID wither is the gradual disappearance of
support for it, as something else shows up on the standards track.
(The DNS is littered with this stuff, for instance.  A6 records and
queries haven't disappeared yet.  EDNS0 support isn't universal more
than 10 years after its specification.  We _still_ see people
convinced that DNS only uses UDP.  And so on.)

But there will no doubt be future occasions somewhere, sometime, for
someone to write "Sender ID Considered Harmful".  That is not today
and not in this WG, I think (again, no hat).

A

-- 
Andrew Sullivan
[email-masked]

---

From: "John Levine" <[email-masked]>
Date: 25 Apr 2012 16:16:12 -0000

>don't do the right thing with the mail.  Correct?

More or less.  The protocol documents are clear enough about how to
compute an answer of yes, no, or a few flavors of maybe.  But it only
offers vague hints about what to do with that answer, partly because
there are so many ways to do spam filtering, partly becuase we don't
know what they are, since there are so many ways that spam filters
make their special secret sauce.

DKIM happens to say quite specifically that a broken signature is
equivalent to no signature, but you won't find anything like that
in S-ID or SPF saying that some result is equivalent to no result.

R's,
John

---

From: Douglas Otis <[email-masked]>
Date: Wed, 25 Apr 2012 12:39:55 -0700

Dear spfbis wg,

A DMARC training class raised a few issues that warrant some review.

Recommended use of "~all" (softfail) for SPF records referenced by Mail 
parameters ensures DKIM has an opportunity to deal with false positives 
caused by forwarded email.  That advice seems okay, but what was missed 
is that "-all" should still be used for any SPF record referenced by the 
EHLO/HELO parameter.

DMARC also recommends walking up one domain level when searching for SPF 
records, which is perhaps the cause of the confusion.  This is not as 
bad as the exposure created by use of SPF PTR mechanisms matching any 
sub-domain.  The SPF records for EHLO/EHLO should be published at the 
EHLO/HELO host domains, and not depend upon one-step domain walking or 
use of PTR records.  The PTR mechanism should not be recommended as this 
also represents a poor domain wide security practice and where resolving 
the mechanism also invites DNS DDoS issues.

When there is an opportunity to obtain EHLO/HELO parameter 
"Authentication" rather than just a Mail parameter "Authorization", 
checking EHLO/HELO is a better practice that is able to retain SPF 
hardfails with the benefit of safe early rejection.

Regards,
Douglas Otis

---

From: Scott Kitterman <[email-masked]>
Date: Wed, 25 Apr 2012 16:35:30 -0400

On Wednesday, April 25, 2012 12:39:55 PM Douglas Otis wrote:
...
> records, which is perhaps the cause of the confusion.  
...

There were pre-RFC 4408 drafts that also suggested things like this.  It 
turned out to be a bad idea.  I strongly doubt it's improved with age.  DMARC 
should not suggest such things.

Scott K

---

From: "Murray S. Kucherawy" <[email-masked]>
Date: Wed, 25 Apr 2012 20:43:51 +0000

> From: [email-masked] [mailto:[email-masked]] On Behalf Of Scott Kitterman
> Sent: Wednesday, April 25, 2012 1:36 PM
> To: [email-masked]
> Subject: Re: [spfbis] Points raised in DMARC training.
> 
> > DMARC also recommends walking up one domain level when searching for
> > SPF records, which is perhaps the cause of the confusion.
> ...
> 
> There were pre-RFC 4408 drafts that also suggested things like this.
> It turned out to be a bad idea.  I strongly doubt it's improved with
> age.  DMARC should not suggest such things.

DMARC doesn't.  And I daresay this is off-topic for spfbis.

-MSK