Subject: Re: [spfbis] #60: Section 2.3 - Publishing Authorization

From: S Moonesamy <[email-masked]>
Date: Tue, 11 Sep 2012 21:53:06 -0700

At 16:16 11-09-2012, spfbis issue tracker wrote:
>#60: Section 2.3 - Publishing Authorization
>
>  Message posted by Scott Kitterman on 11 Sept 2012:
>
>  I don't understand why you want to revert the Section 2.3 changes?
>
>  Those changes were not primarily made in response to issue #33.  They were
>  made because of comments that in RFC 4408 the specification RECOMMENDS
>  something without a rationale for the recommendation.  Given the lack of
>  rationale, it's hard to know what might be an exceptional case for not
>  following the recommendation.
>
>  The change is also made because of operational experience gained since RFC
>  4408 was published.  At the time RFC 4408 was published, it was envisioned
>  that there would be a transition to a paradigm where most organizations
>  published -all SPF records.  This didn't happen.  The revised text gives
>  some guidance on the implications of not following the recommendation.
>  Since it is
>  common for large entities to ignore it, I think that is important.  That's
>  more true now than I would have envisioned when RFC 4408 was being
>  developed.
>
>  http://www.ietf.org/mail-archive/web/spfbis/current/msg02772.html

I am including the message from Andrew Sullivan below.

At 21:00 11-09-2012, Andrew Sullivan wrote:
>It seems that these two mails talk past each other.  Scott's point, as
>I read him, is that the 4408 text just says "you probably want to use
>these records", and the new proposed text says "if you want to achieve
>something, then you MUST do some other thing".

Here's a pointer to the message from Scott Kitterman 
http://www.ietf.org/mail-archive/web/spfbis/current/msg02781.html

>Now, there are two questions here, both relevant to the WG.
>
>First, is this really a clarification?  That is, does the new proposed
>text expans on or otherwise clarify what the old text said implicitly,
>as Scott argues it does?
>
>Second, is the new text both true and a correct use of the RFC 2119
>keyword?  It seems to me that in the new proposed text, it isn't a
>2119 MUST at all.  It's really just stating an entailment.  It could
>be as correctly phrased as "if senders ... 'want to support receivers
>making negative authorization determinations, it is necessary for them
>to publish records that end in -all'".  If I understand correctly,
>this is a fact about how the protocol works, and not actually a
>normative requirement for interoperation.  What have I missed?

Regards,
S. Moonesamy

---

From: Scott Kitterman <[email-masked]>
Date: Wed, 12 Sep 2012 13:12:54 -0400

> >normative requirement for interoperation.  What have I missed?

Andrew's understanding of my intent is largely correct.  Part of what was 
implicit in RFC 4408 was an assumption that SPF record publishers would have 
as a goal to allow receivers to (as I put it) make negative authorization 
determinations.  Since then (and if you look at the paucity of non-financial 
institution/high value phishing target domains with -all SPF records it's 
pretty clear this is the case) the operational use evolved differently.  Some 
senders have this goal and some don't.

So my goal wasn't 100% clarification, it was also to update the recommendation 
to match operational lessons learned since RFC 4408 was written.  I believe 
such non-protocol impacting changes are well within our scope.

I sent a separate message regarding the use of MUST, so if you want to talk 
about point, 2 above, I think it would be better to reply to that one.

Scott K

---

From: Scott Kitterman <[email-masked]>
Date: Wed, 12 Sep 2012 14:44:41 -0400

> >#60: Section 2.3 - Publishing Authorization

I don't see #60 listed:

http://trac.tools.ietf.org/wg/spfbis/trac/report/1

It clearly existed at one point, because I got email about the issue being 
created, but it seems to have vanished.

Scott K

---

From: S Moonesamy <[email-masked]>
Date: Wed, 12 Sep 2012 15:44:44 -0700

Hi Scott,
>created, but it seems to have vanished.

I don't see the ticket.  I don't know why it vanished.  I'll try and 
find out what happened.

Regards,
S. Moonesamy