Re: [spfbis] Document shepherd review of draft-ietf-spfbis-4408bis-14

[Scott Kitterman <[e-mail]>]

On Friday, May 17, 2013 01:35:21 AM Murray S. Kucherawy wrote:
> On Thu, May 16, 2013 at 11:37 PM, Scott Kitterman <[e-mail]>wrote:

Snipped down to only the items I think I need to reply to.

> > > > >    'Without explicit approval of the domain owner, checking other
> > > > >     identities against SPF version 1 records is NOT RECOMMENDED
> > because
> > > > >     there are cases that are known to give incorrect results.'
> > > > > 
> > > > > How should this explicit approval be sought?  This recommendation
> > > > > does not make sense.
> > > >
> > > >What I have now is "Documents that define other identities will have
> > > >to define the method for explicit approval."
> > > 
> > > "out-of-band" or "private" was suggested.  I'll use one of them (I do
> > > 
> > > not have any preference):
> > >      Without out-of-band approval of the ADMD, checking other identities
> > >      against SPF version 1 records is NOT RECOMMENDED because there are
> > >      cases that are known to give incorrect results.
> > 
> > I don't think that's correct.  One could get a new modifier added to the
> > SPF
> > modifier registry that would indicate a record can be used for other
> > purposes.
> > There are no such other purposes defined at the moment, but there's
> > absolutely
> > no need for out-of-band/private methods to accomplish this goal.
> 
> I'm confused now about what we're trying to say.   I think the RFC is
> trying to say that it's a bad idea to try to check identifiers other than
> HELO and MAIL FROM using the check_host() function, unless you really know
> what you're doing and so does the sender.  Is that correct?  If not, what's
> the intent?  Maybe with that clarified, I can suggest an alternative.

Close.  It goes a bit further.  SPF records have to be interpreted in the 
context of SPF.  As a receiver, that's ALL you can know.  It's not possible 
for receivers to accurately translate something written in an SPF context to 
another one.  Any such use has to be opt-in so that there's an explicit 
statement from the sender that their SPF record is suitable for the 
alternative use.

As an example, DMARC is very careful to stay on the (in my opinion) correct 
side of this line be taking the results of an SPF check as is as one of the 
inputs and using the additional factor of identity alignment to consider if 
the SPF input supports a DMARC pass (I know that DMARC is OT for this group, 
but it's a current example).

> > > > >    'Although invalid, malformed, or non-existent domains cause SPF
> > > > >    checks
> > > > >     to return "none" because no SPF record can be found, it has long
> > > > >     been
> > > > >     the policy of many MTAs to reject email from such domains,
> > > > >     especially
> > > > >     in the case of invalid "MAIL FROM".  Rejecting email will
> > > > >     prevent
> > > > >     one
> > > > >     method of circumventing of SPF records.'
> > > > > 
> > > > > This text is already in RFC 4408.
> > > > > 
> > > > >    "Implementations have to take care to correctly extract the
> > 
> > <domain>
> > 
> > > > >     from the data given with the SMTP MAIL FROM command as many MTAs
> > > > >     will
> > > > >     still accept such things as source routes ..."
> > > > > 
> > > > > The definition of <domain> is:
> > > > >    'the domain portion of the "MAIL FROM" or "HELO" identity.'
> > > > > 
> > > > > I am not sure whether it is even a definition.  From an
> > > > > implementation perspective the last paragraph of Section 2.4 is
> > unclear.
> > 
> > > >It seems clear to me.  Could you expand on why you think it's
> > problematic
> > > >or provide recommended text.
> > > 
> > > I mentioned in a previous comment that "<domain> definitions (not
> > > sure whether it is a definition) are mentioned in two places.  I
> > > suggest fixing that and then getting back to the above".
> > 
> > I don't understand what you think is wrong.  Repeating the comment won't
> > help.  I did read it.  I don't understand it.
> 
> I believe the issue is that the <domain> token is defined in two places in
> the bis draft, namely 2.4 and 4.1.  We should consolidate them and ensure
> the consolidated one is complete.

Here's that last paragraph of 2.4:

>    Implementations have to take care to correctly extract the <domain>
>    from the data given with the SMTP MAIL FROM command as many MTAs will
>    still accept such things as source routes (see [RFC5321], Appendix
>    C), the %-hack (see [RFC1123]), and bang paths (see [RFC1983]).
>    These archaic features have been maliciously used to bypass security
>    systems.

I think it's a cautionary tale, not a definition.  This could be moved to 4.1, 
I suppose, but I don't see what it adds to do so.

> > > > >    'Generating non-delivery notifications to forged identities that
> > have  failed the authorization check is a source of backscatter and
> > > > SHOULD  be avoided.'
> > > > > 
> > > > > This RFC 2119 SHOULD is not in RFC 4408.  The above does not have
> > > > > anything to do with Sender Policy Framework.  It was mentioned
> > > > > during
> > > > > WG discussions that "SPF can help the backscatter problem" [2]. 
> > > > > This
> > > > > text may have been introduced in response to a review [3].  Is this
> > > > > an enhancement or a clarification?
> > > >
> > > >It's a clarification.
> > > 
> > > In a previous comment I mentioned that "my reading of the above is
> > > that it is neither an enhancement or a clarification.  I suggest
> > > removing the text".
> > 
> > So you think it's not something that should be avoided?
> 
> I think it's something to be avoided, but the choice of generating an NDN
> has nothing to do with the SPF protocol itself.  It's a local policy
> matter.  I agree with strong language, but not SHOULD.

OK.  Would you please suggest strong, but not 2119 text?  It would be a help.

> > > > >    'ADMDs publishing SPF records SHOULD try to keep the number of
> > > > >     "include" mechanisms and chained "redirect" modifiers to a
> > minimum.'
> > 
> > > > > What is the minimum?  Note that this RFC 2119 SHOULD is in RFC 4408.
> > > >
> > > >It's the least an ADMD needs to properly describe the hosts
> > > >authorized to send
> > > >mail from their domain.  It's minimum in the sense of no more than
> > needed.
> > 
> > > I commented previously about this "I didn't understand that as there
> > > wasn't any explanation for the RFC 2119 SHOULD.  I suggest adding an
> > > explanation or rewriting the text so that the expression (see above)
> > > is clear".
> > 
> > I'm failing to understand how to clarify that use the minimum means use as
> > little as you can.  It's basically just explaining the dictionary to the
> > reader, so I think I don't understand what you think needs changing.
> 
> I think the issue here is that use of normative language ought to be
> associated with something more definitive than "a minimum", which is a bit
> mushy.  Since there are caps on DNS query counts established elsewhere,
> does this SHOULD accomplish anything?
> 
> On the other hand, I think we're not required to justify normative language
> that's just repeated from RFC4408, so we shouldn't burn too many cycles
> here.

I'll leave it then, I guess.  An example of something that is not the minimum 
is v=spf1 a mx ptr ?all where a and mx point to the same host and that host 
has a PTR match for the domain too.  Such records are quite common as they are 
the default output of some SPF record generation wizards.  With such a record, 
there's triple the DNS lookups for every mail that doesn't pass to no purpose.

> > > > > In Section 4.1:
> > > > >    '<domain> - the domain that provides the sought-after
> > authorization
> > > > >                information; initially, the domain portion of the
> > "MAIL
> > > > >                FROM" or "HELO" identity.'
> > > > > 
> > > > > The above text is different from the text in Section 2.4.
> > > >
> > > >Yes, but not inconsistent with it.
> > > 
> > > I suggest having the definition in one place for consistency.  What I
> > > am looking at is consistency for the reader instead of where I
> > > believe that there is inconsistency.
> > 
> > They are talking about different things relative to domains, so given the
> > organization, I don't see an easy way to do that.  I'm open to
> > suggestions.
> 
> The definition in 2.4 is less complete than that in 4.1, and also there are
> references to the one in 2.4.  I propose copying the 4.1 version on top of
> the 2.4 version, remove the 4.1 definitions and have them refer to 2.4.

I'm still not seeing 2.4 as a definition.  If there is a consolidation needed, 
I think 4.1 is the right place for it.  If someone can specify exactly what 
text in 2.4 is definitional, I'll try and consolidate it into 2.4 (and check 
the references).

> > > > >    'Alternatively, for a server failure (RCODE 2) result,
> > check_host()
> > > > >     MAY track failures and treat multiple failures within 24 hours
> > for
> > > > >     the same domain as "permerror".'
> > > > > 
> > > > > This text is not in RFC 4408.  I found a note in Issue #1 [5] and in
> > > > > a message [6].
> > > >
> > > >Yes.  This is a change to address an operational issue found during SPF
> > > >deployment.
> > > 
> > > Stuart mentioned that: "This also solves the TIMEOUT for type 99
> > > problem. Reporting a PermError for a broken name server would be very
> > > appropriate (and switching to checking TXT first while said failure
> > > is cached would also be permissible)".
> > > 
> > > John commented that:  "Not that I'm aware of.  That looks to me like
> > > an optimization to do in the DNS cache, not in the client".
> > > 
> > > In a previous comment I mentioned that: "Are there any
> > > implementations that do this? If so, that's the justification; it's
> > > practical experience. If not, we should consider dropping it".
> > 
> > There was an issue.  We discussed possible solutions (my initial hope was
> > to
> > make all SERVFAIL responses permerror) and this was the best solution we
> > came
> > up with.  Because we want consistent results across implementations it's
> > not
> > just a local cache optimization.  I think we should leave it since I don't
> > want to redo the entire process of solving the issue again.
> 
> I understand the intent, but there's quite a bit of onus on us to show that
> this is important enough to include.  Are there implementations that do
> this, which would be evidence that it's important?

I didn't implement it yet because coming into the working group, I'd thought 
the solution to the problem in question was to convert serve fail from 
temperror to permerror in general (which proved to be wrong).  I believe 
Stuart is working on this now and if he doesn't, I will.

I can tell you that the issue we are trying to resolve is the reason I don't 
configure software I've written to defer on temperror by default.  I used to 
and it caused problems.

>From my point of view, we have a new proposed solution that the WG developed 
to a long standing issue.  It seems a bit odd to then demand that it can only 
be part of the output of the WG if someone else implemented it.

So I can show that the problem it's addressing is real.  As written, it's 
fully backward compatible, so adding it causes no harm.  Part of what we are 
supposed to be doing is addressing lessons learned from the experimental 
period and that is exactly what this is.

> > > > > In Section 4.6.4:
> > > > >    "SPF implementations MUST limit the total number of mechanisms
> > > > >    and
> > > > >     modifiers ("terms") that cause any DNS query to at most 10
> > > > >     during
> > > > >     SPF
> > > > >     evaluation."
> > > > > 
> > > > > This was discussed on the mailing list [7].
> > > > > 
> > > > >    "If this number is exceeded during a check, a permerror MUST be
> > > > > returned."
> > > > > 
> > > > > I read this as if an implementation-specific limit is reached a
> > > > > permerror is returned.  There are two RFC 2119 MUST in the
> > > > > above.  That can be reduced to one MUST.
> > > >
> > > >Is there a problem with it the way it is?
> > > 
> > > Here is my previous comment:
> > > 
> > > For context we are at Section 4.6.4.  I'll quote some text from it:
> > >   "If this number is exceeded during a check, a permerror MUST be
> > returned."
> > 
> > >   'If this limit is exceeded, the "mx" mechanism MUST produce a
> > >    "permerror" result.'
> > >   'If this limit is exceeded, all records other than the first 10
> > >    MUST be ignored.'
> > > 
> > > I prefer not to discuss about the last one (see quoted text) again.
> > > In terms of coding it is easier if I am told to return a "permerror"
> > > results when DNS limit X is exceeded. That can be specified with one
> > > RFC 2119 MUST.  I am taking in consideration the SecDir
> > > recommendation and interoperability.  Speaking of interoperability
> > > 
> > > the following text:
> > >    'SPF implementations MUST limit the total number of mechanisms and
> > >     modifiers ("terms") that cause any DNS query to at most 10 during
> > >     SPF
> > >     evaluation.'
> > > 
> > > does not encourage it because of the "at most". Section 4.6.4 does
> > > not make things easier for DNS operations as the reader cannot
> > > identify the limits easily due to the exceptions. I am ok with the
> > > exceptions. What I am suggesting is not to use two RFC 2119 MUST if
> > > it there is a way for it to be done with one RFC 2119 MUST.
> > 
> > They are different limits that you have to code differently, so I think
> > combining them would reduce clarity for implementers.
> 
> I agree that there are actually three different things being limited here:
> 
> - the mechanism count
> - the MX query count
> - the resulting A query count
> 
> The "at most" thing is interesting.  If I limit the DNS count to 2, for
> example, I'm still compliant but would likely get very different results
> than an implementation with a limit of 10.  That's the same logic that we
> applied to say you can't go over that limit either.

I'm OK with dropping at most.  Any objections?
> 
> > > >    'MTAs or other processors SHOULD impose a limit on the maximum
> > amount
> > > > >     of elapsed time to evaluate check_host().  Such a limit SHOULD
> > allow
> > > > >     at least 20 seconds.  If such a limit is exceeded, the result of
> > > > >     authorization SHOULD be "temperror".'
> > > > > 
> > > > > There are three RFC 2119 SHOULDs in the above.  I suggest rewriting
> > > > > the text to reduce that.
> > > >
> > > >They are three different things.  Why would rewriting it help?
> > > 
> > > Here is my previous comment:
> > > 
> > > Throughout the document the words "MTA", "other processors", "mail
> > > receivers", "SPF implementations" and "SPF verifiers" are used. That
> > > looks inconsistent to me.
> > > 
> > > Here's an example of a rewrite:
> > >    MTA or other processors SHOULD:
> > >    
> > >    (a) impose a limit on the maximum amount of elapsed time to
> > > evaluate check_host().
> > > 
> > >    (b) allow for at least 20 seconds.
> > >    
> > >    (c) return a result of authorization of "temperror".
> > 
> > I don't find that any clearer, probably less so than what's in the draft
> > now.
> 
> It's a common-factoring of the noun and SHOULD with otherwise identical
> meaning.  Seems a stylistic choice to me more than anything else.

I understand.  I don't think it's helpful here.  There seems to be an idea 
that the fewer times 2119 words appear in the draft the better.  While we want 
to avoid over specifying, cases like this don't actually change the 
requirements.  I think clarity is more important than consolidation and I find 
the current wording clearer.  If other people think the refactored version is 
clearer then I'll change it, but I think it's a mistake to change it just to 
reduce the count of 2119 words in the draft.

> > > > >    "To prevent DoS attacks, more than 10 PTR names
> > > > >     MUST NOT be looked up during the evaluation of a "ptr" mechanism
> > > > >     (see Section 4.6.4)."
> > > > > 
> > > > > The above restates a previous RFC 2119 MUST.
> > > > > 
> > > > >    "If used, proper PTR records MUST be in place for the domain's
> > hosts
> > 
> > > > >     and the "ptr" mechanism SHOULD be one of the last mechanisms
> > > > >     checked."
> > > > > 
> > > > > Those RFC 2119 key words are not in RFC 4408.  I don't see how this
> > > > > RFC 2119 change qualifies as a clarification or explanation.
> > > >
> > > >For the MUST, it flat out won't work if you don't have those (no
> > > >interoperation).  For the SHOULD, it's an optimization.  We can change
> > > it f you want.
> > > 
> > > My previous comment was that: "It's a change. I suggest reverting it.
> > > Telling people who are using the "ptr" mechanism that they must have
> > > PTR records is stating the obvious".
> > 
> > Obvious to you.  Not obvious to everyone.
> 
> I think this is what Pete described as "shouting", i.e., using MUST where
> "needs to" is fine.  PTR isn't part of SPF itself.

OK.  Changed.

> > > > > In Section 6:
> > > > >    'The modifiers defined in this document ("redirect" and "exp")
> > > > >    MAY
> > > > >     appear anywhere in the record, but SHOULD appear at the end,
> > after
> > > > >     all mechanisms.'
> > > > > 
> > > > > This text is in RFC 4408.  I would label the RFC 2119 usage as
> > > > > defective.
> > > >
> > > >Why?
> > > 
> > > My previous comment was: "The text tells me that it is ok if the
> > > modifiers appear anywhere but they should appear at the end after all
> > > mechanisms. It would be clearer to say that it should appear after
> > > all mechanisms".
> > 
> > That is defective use of 2119 language?  I disagree that that would be
> > clearer.
> 
> "MAY" is essentially meaningless except perhaps to emphasize that the
> implementer has a choice with no protocol consequence.  You could make it
> "can" and have the same effect.

There's an inverse requirement on implementers that SPF verifiers can't assume 
modifiers are in any particular place in the record.  So the fact that this MAY 
happen has an effect on verifier implementation requirements (and it would affect 
interoperability if they don't consider it).

> > > > > In Section 6.2:
> > > > >    "Since the explanation string is intended for an SMTP response
> > > > >    and
> > > > >     [RFC5321] Section 2.4 says that responses are in [US-ASCII], the
> > > > >     explanation string MUST be limited to US-ASCII.'
> > > > > 
> > > > > It would be easier to defer to RFC 5321 instead of setting a RFC
> > > > > 2119
> > > > > requirement in this draft.  I note that this requirement was not in
> > RFC
> > > > > 4408.
> > > >
> > > >It's not a new requirement.  If you couldn't find it in 4408, then that
> > > >means we've succeeded in making the actual requirement more clear.
> > > 
> > > None of the WG participants have pointed out where the actual
> > > requirement (RFC "MUST") is in RFC 4408.  If the text was in RFC 4408
> > > it would be possible for a WG participant to point me to it.   There
> > > was a comment about 'this could be expressed non-normatively (e.g.
> > > "needs to be")'.
> > 
> > If it's not ASCII, it won't interoperate (at all).  Isn't that exactly
> > where
> > 2119 language is supposed to be used?  Regardless of how it's worded in
> > 4408,
> > putting non-ASCII characters in explanation strings does not and has never
> > worked.  At most it's making something explicit that was implicit before,
> > which is a good clarification I'd think.
> 
> I support this change of adding MUST.  An SPF implementer does not
> necessarily know how the mechanism by which SMTP will be accessed to relay
> the result, and we don't specify anything about encoding special characters
> to 7-bit.  We could MUST this, or we could MUST an RFC2047-style encoding
> or escaping of some kind.  Guess which one I prefer.
> 
> The other alternative I can think of is to drop the MUST here but make it
> clear that if the explanation string isn't 7-bit clean, someone's going to
> have to make it SMTP-compliant somehow before it's returned in the SMTP
> reply.

I don't think that's an alternative because it's inconsistent with current 
practice.  I don't think we have a choice other than ASCII, however we choose 
to word it.

> > > > >    "Software SHOULD make it clear that the explanation string
> > > > >     comes from a third party."
> > > > > 
> > > > > I could not understand what that means in RFC 2119 terms.  The draft
> > > > > uses RFC 2119 key words by example instead of providing an
> > explanation.
> > 
> > > >I don't understand the comment.
> > > 
> > > There was a comment from Murray:  "we're talking about
> > > interoperability between humans here, and not between implementations".
> > 
> > We're talking about avoiding security issues caused by the humans getting
> > confused.
> 
> If this document defines a protocol that operates between senders and
> receivers, then wrapping explanation text (which is for humans) in more
> explanation text is out of scope, at least in a normative sense.
> 
> That said, this was in RFC4408 and is unchanged here.  I don't think it's
> worth our energy at this stage.

OK.

> > > > >    "This SHOULD be a fully qualified domain name, but if one does
> > > > >    not
> > > > >     exist (as when the checking is done by a MUA) or if policy
> > > > >     restrictions
> > > > >     dictate otherwise, the word "unknown" SHOULD be substituted."
> > > > > 
> > > > > The RFC 2119 key words are in RFC 2119.  I don't know what to say.
> > > >
> > > >OK.
> > > 
> > > Murray comemnted: "I think that looks fine as-is, though we could
> > > change the first SHOULD to "ought to" because it's a transformation
> > > of other input and not an implementation choice.  (And I assume you
> > > mean they were in RFC4408.)
> > 
> > Since the values end up in log files and Received-SPF/authentication
> > results
> > header fields that are provided to be processed on other systems, it is an
> > interoperability issue.  Having consistency helps interoperability.  I'd
> > prefer to leave it.
> 
> My point here is that the first SHOULD is essentially saying "the hostname
> of the machine SHOULD be an FQDN", but this is ineffective because the
> person configuring this host might not know a thing about SPF or this
> requirement and call the machine "banana".  What does the SPF module do
> with this SHOULD now?
> 
> "ought to", "is typically", "is ideally", etc.

What the first SHOULD is trying to say is about how you expand the macro (use 
hostname -f and not hostname).

> > > > > It is odd to have RFC 2119 requirements under a "Notes" heading.
> > > >
> > > >They aren't really notes in that sense.  If you have a better name for
> > the
> > > >section, please suggest.
> > > 
> > > I suggest removing all the RFC 2119 requirements in Section 7.3 if
> > > the working group cannot find a way to fix this.
> > 
> > Why?  How about if we call it "Details" instead of Notes?
> 
> Macro Processing Details
> 
> Dumping the RFC2119 language in there is a bad idea.  It's all
> interoperability stuff.

Thanks. Changed.

> > > > > In Section 8.2:
> > > > >    'A "neutral" result MUST be treated exactly like the "none"
> > result;
> > 
> > > > >     the distinction exists only for informational purposes.'
> > > > > Why is an existing RFC 2119 restated?
> > > >
> > > >Because of the structure of the document that the WG came up with.  I
> > don't
> > > >find a good way to avoid it and not make it less readable.
> > > 
> > > I'll leave this issue open as it was mentioned in the AppsDir review.
> 
> I'll help with this if needed.

Thanks.

> > > > > In Section 10.1.1:
> > > > > 
> > > > > There was a comment from Authur Thisell about the table [11] in this
> > > > > sub-section.
> > > >
> > > >There didn't seem to be support for changing it though.
> > > 
> > > I read RFC 4408 and I did not find any table similar to the one in
> > > Section 10.1.1 of draft-ietf-spfbis-4408bis-14.  My understanding of
> > > "support for changing text" is that the text is proposed on the
> > > working group mailing list and it is added if there is agreement.  I
> > > didn't find any messages about that in the mailing list
> > > archives.  What I found was a message disagreeing with a change which
> > > was made in the draft which was posted together with an explanation
> > > about why there was disagreement.  In my opinion there wasn't any
> > > support for making that change in the draft.
> > 
> > The text came from Alessandro and was discussed on the list.  Arthur's
> > comment
> > came later.  The table is new, but is only a new expression of information
> > that was in 4408.  It does not create any new requirements.
> 
> When we developed RFC6686, there were several people who responded well to
> the introduction of tables to show our survey results.  I seem to recall
> people liking this table in here as well, though I admit not having looked
> at the archives tonight.  If it can be confirmed that the details in the
> table match the prose, I think it's fine to leave it in.

I checked.  It does.

> > > > > In Section 10.1.2:
> > > > >    "Publishing SPF records for domains that send no mail is
> > > > >    
> > > > >     a well established best practice."
> > > > > 
> > > > > I am not aware of that best practice.  I did a few DNS queries:
> > > > > 
> > > > > ;; QUESTION SECTION:
> > > > > ;bing.com.                      IN      TXT
> > > > > 
> > > > > ;; ANSWER SECTION:
> > > > > bing.com.               3600    IN      TXT     "v=msv1
> > > > > t=6097A7EA-53F7-4028-BA76-6869CB284C54"
> > > > > 
> > > > > ;; QUESTION SECTION:
> > > > > ;com.com.                       IN      TXT
> > > > > 
> > > > > ;; ANSWER SECTION:
> > > > > com.com.                293     IN      TXT
> > 
> > "google-site-verification:esSnoZdChIkkfCfS9MMgqNhE0yaXfnnZWdZPuBf7e8k"
> > 
> > > >OK.  See
> > 
> > http://www.bits.org/publications/security/BITSEmailAuthenticationFeb2013.p
> > d
> > 
> > > >f
> > > 
> > > I suggest "good practice" as mentioned by Alessandro.
> > 
> > What's wrong with the way it is?  I think the current text is accurate.
> 
> The OpenDKIM SPF data recorded 1157 domains with "v=spf1 -all" records.

The source of your domain list was from domains seen in email, right?  So 
that's 1157 cases where they got it wrong.  I don't think your survey would 
have caught correct uses of it (or do I misremember how you got your domain 
list)?

> > > > > In Section 11.5:
> > > > >    "An SPF compliant receiver gathers information from the SMTP
> > commands
> > > > >     it receives and from the published DNS records of the sending
> > domain
> > > > >     holder"
> > > > > 
> > > > > I suggest explaining the untrusted part.
> > > >
> > > >That's what the section does.
> > > 
> > > There was a comment:  "A second sentence indicating most of that
> > > input is unverified is probably in order, with references if possible".
> > 
> > I think the section explains exactly that, so some text would help.
> 
> I think it falls short, because it's not clear to a neophyte reader that
> those data are essentially untrustable.
> 
> So append:
> 
> All of these pieces of information are generated by actors outside of the
> authority of the receiver, and thus are not guaranteed to be accurate or
> legitimate.

Added.  Thanks.

> > > > Where can I find "Designated Mailers Protocol"?
> > > >
> > > >See draft-fecyk-dsprotocol
> > > 
> > > Ok.  As a note for the working group, I could not find the draft.
> > 
> > First Google hit for draft-fecyk-dsprotocol is:
> > 
> > http://tools.ietf.org/html/draft-fecyk-dsprotocol-04
> 
> RFC5451 cites a dnsop I-D that expired a long time ago, so there's
> precedent for referring to that even though it's long dead.
> 
> > > > > Where can I find "Domain-Authorized SMTP Mail"?
> > > >
> > > >I don't have a copy of this.
> > > 
> > > I suggest dropping the reference.
> > 
> > SPF did not spring from nothing.  It gathered a number of concepts, added
> > a
> > few things, and managed to be successful.  I think it would be more
> > appropriate to leave it as it shows part of the trace back to the origin
> > of
> > the protocol.
> 
> I would suggest the co-chairs consult the AD or the RFC Editor about what
> can be done in a situation where it's appropriate to cite known prior work
> where an actual reference is no longer available.

OK.

> > > > > In Appendix I:
> > > > > 
> > > > > Appendix I is about "Protocol Status".  This draft is intended as a
> > > > > Proposed Standard. From an IETF perspective that is what it will
> > > > > be.  Describing it as something different can be misleading.
> > > > > 
> > > > >    "[RFC4408] was designed to clearly document the protocol defined
> > by
> > > > >     earlier draft specifications of SPF as used in existing
> > > > >     implementations.  This updated specification is intended to
> > clarify
> > > > >     identified ambiguities in [RFC4408], resolve techincal issues
> > > > >     identified in post-RFC 4408 deplyment experience, and document
> > > > >     widely
> > > > >     deployed extensions to SPF that have been developed since
> > [RFC4408]
> > > > >     was published."
> 
> My browser identifies two typos in there ("techincal", "deplyment").

Fixed.  Thanks.

> > > > > Extensions to the SPF protocol are clearly mentioned in the charter
> > > > > as being out of scope.  The "document widely deployed extensions" is
> > > > > problematic.
> > > >
> > > >The charter specifically allows for "addition of any enhancements
> > > >that have already gained widespread support".
> > > 
> > > I read the discussion about the charter again.  It is my
> > > understanding that extensions to the SPF protocol is
> > > out-of-scope.  The working group did not add a work item during the
> > > chartering discussion as it was considered as an extension to the
> > protocol.
> > It was also not widely deployed.  Should I take authentication-results out
> > of
> > the draft then?
> 
> Personally, I think this whole appendix can be tagged with "[For IESG
> information only]" and removed prior to publication.  It's the kind of
> thing we usually include in shepherd writeups and not in the RFCs
> themselves.

Which one are we on?  Appendix J is intended to be removed before publication.

Scott K