Subject: Re: [spfbis] Addressing reviews (was: Document shepherd review of draft-ietf-spfbis-4408bis-14)

From: S Moonesamy <[email-masked]>
Date: Sun, 05 May 2013 23:33:23 -0700

Hi Scott,

The milestone for draft-ietf-spfbis-4408bis-14 is May 2013.  The 
draft has already gone through WGLC.  Can you provide an estimate 
date of when the reviews and comments received during the WGLC can be 
addressed?

Regards,
S. Moonesamy (as document shepherd)

---

From: S Moonesamy <[email-masked]>
Date: Mon, 13 May 2013 21:36:36 -0700

Hi Scott,

Can you provide an estimate date of when the reviews and comments 
received during the WGLC will be addressed?

Regards,

---

From: Scott Kitterman <[email-masked]>
Date: Tue, 14 May 2013 01:21:51 -0400

> S. Moonesamy (as document shepherd)

Probably Thursday.

Scott K

---

From: Scott Kitterman <[email-masked]>
Date: Thu, 16 May 2013 17:45:35 -0400

On Tuesday, April 23, 2013 04:08:39 PM S Moonesamy wrote:
> Hello,
> 
> Here's my review as Document Shepherd.  draft-ietf-spfbis-4408bis is
> nearly ready for publication as a Proposed Standard.  I took into
> consideration the restrictions in the SPFBIS Charter and the
> controversial working group discussions in making this assessment.
> 
> In the Abstract:
> 
>    "This document describes version 1 of the Sender Policy Framework
>     (SPF) protocol, whereby an ADMD can explicitly authorize the hosts
>     that are allowed to use its domain names, and a receiving host can
>     check such authorization."
> 
> ADMD should be expanded in the above.  This was pointed out in a
> review posted on August 26, 2012 [1].

Fixed.

> In Section 2.1:
> 
>    'It is RECOMMENDED that SPF verifiers not only check the "MAIL FROM"
>     identity, but also separately check the "HELO" identity by applying
>     the check_host() function (Section 4) to the "HELO" identity as the
>     <sender>.'
> 
> As a note this "RECOMMENDED" is also in RFC 4408.
> 
>     'Note that requirements for the domain presented in the EHLO or HELO
>      command are not always clear to the sending party, and SPF verifiers
>      MUST be prepared for the "HELO" identity to be malformed or an IP
>      address literal.'
> 
> This RFC 2119 "MUST" is not in RFC 4408.  It is a substantive change
> in my opinion.

Fixed.

>    "This SPF check can only be performed when the "HELO" string is a
>     valid fully qualified domain."
> 
> What is a valid fully qualified domain?

Would s/domain/domain name/ clear it up for you?

> In Section 2.2:
> 
>    'SPF verifiers MUST check the ""MAIL FROM" identity if a completed
>     "HELO" check has not reached a definitive policy result by applying
>     the check_host() function to the "MAIL FROM" identity as the
>     <sender>.'
> 
> As a note this RFC 2119 MUST is already in RFC 4408.
> 
> In Section 2.3:
> 
>    "An SPF-compliant domain MUST have valid SPF records as described in
>     Section 3."
> 
> As a note the RFC 4408 text is:
> 
>    "An SPF-compliant domain MUST publish a valid SPF record as described
>     in Section 3."
> 
> The RFC 2119 MUST is redundant.

Is there a reason to change it?

>    'If domain owners choose to publish SPF records and want to support
>     receivers making negative authorization determinations, then they MUST
>     publish records that end in "-all", or redirect to other records that
> do, otherwise, no definitive determination of authorization can be made.'
> 
> The document uses ADMD while there is "domain owners" in the
> above.  I suggest reviewing that.

Changed

> The RFC 2119 MUST is a substantive change.  Why is this a MUST?

Because it's the literal truth.  That's what you have to do to achieve that 
result.  You won't interoperate with receivers in that way effectively if you 
don't.

> In Section 2.4:
> 
>    'At least the "MAIL FROM" identity MUST be checked, but it
>     is RECOMMENDED that the "HELO" identity also be checked beforehand.'
> 
> There is already a RFC 2119 MUST in Section 2.2.  There is also a RFC
> 2119 RECOMMENDED in Section 2.1.  The above text restates existing
> RFC 2119 requirements or recommendations.

Modified to make them non-redundant.

>    '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."

> In Section 2.4:
> 
>    'When a mail receiver decides to perform an SPF check, it MUST use a
>     correctly-implemented check_host() function (Section 4) evaluated
>     with the correct parameters.'
> 
> This RFC 2119 requirement states the obvious.  It basically says that
> there is a requirement in draft-ietf-spfbis-4408bis-14 to use a
> correct implementation of draft-ietf-spfbis-4408bis-14.

This was changed already due to other comments.  I think it makes sense now.  
Please check when -15 is published.

>    '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.

> In Section 2.5:
> 
>    "The authorization check SHOULD be performed during the processing of
>     the SMTP transaction that sends the mail."
> 
> This RFC 2119 SHOULD is already in RFC 4408.
> 
>    'Performing the authorization other than using the return-path and
>     client address at the time of the MAIL command during the SMTP
>     transaction can cause problems, ..'
> 
> Shouldn't that be "authorization check"?

Yes.  Fixed.

>    '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 Section 2.6:
> 
>    "An SPF verifier implements something semantically identical to the
>     function defined there."
> 
> John Levine commented about this during the WGLC [4].  I am listing
> this as a reminder for myself.
> 
> In Section 2.6.1:
> 
>    'A result of "none" means either (a) no syntactically valid DNS domain
>     name was extracted from the SMTP session that could be used as the
>     one to be authorized, or (b) no TXT records were retrieved from the
>     DNS that appeared to be intended for use by SPF verifiers.'
> 
> I suggest "DNS TXT records".  What is a syntactically valid DNS
> domain name?  The definition of "none" in RFC 4408 is clear (to me).

How could one retrieve anything other than DNS TXT records from the DNS?  That 
seems redundant since it says "retrieved from the DNS".

> In Section 2.6.2:
> 
>    'The domain owner has explicitly stated that it is not asserting
>     whether the IP address is authorized.  This result MUST be treated
>     exactly like the "none" result; the distinction exists only for
>     informational purposes.'
> 
> As a note, the RFC 2119 MUST is in RFC 4408.  The Introduction
> Section mentions "ADMDs can authorize hosts to use their domain
> names".  The above uses "domain owner".

Changed to ADMD.  Made the same change in 2.6.5 as well.

> In Section 2.6.7:
> 
>    'A "permerror" result means the domain's published records could not
>     be correctly interpreted.  This signals an error condition that
>     definitely requires manual intervention to be resolved.'
> 
> What is "manual intervention" in the above?

Would operator intervention or operator action be better?
 
> In Section 3:
> 
>    'An SPF record is a DNS record that declares which hosts are, and are
>     not, authorized to use a domain name for the "HELO" and "MAIL FROM"
>     identities.'
> 
> How are hosts which are not authorized to use a domain name listed in
> a SPF record?

If a record contains something like -a:host.example.com that host is 
explicitly not authorized.

>    "The SPF record is a single string of text."
> 
> What is a single string of text?  It may be easier to state this in
> terms of record format.

I think this was addressed in a later comment and it should be improved.

>    '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.

>    'ADMDs SHOULD also try to minimize the amount of other DNS information
>     needed to evaluate a record.'
> 
> This RFC 2119 SHOULD is also in RFC 4408.  There are two RFC 2119
> SHOULDs in the last paragraph of Section 3.  This usage of RFC 2119
> key words does not help the SPF "publisher".   In my opinion the
> "SHOULD try" in this context uses the RFC 2119 key word in unorthodox ways.

I took try out of the section.  I think that should do it.

> In Section 3.1:
> 
>    'SPF records MUST be published as a DNS TXT (type 16) Resource Record
>     (RR) [RFC1035] only.'
> 
> I would ask why "MUST be published ... only".  By the way, Section 3
> has a reference to Section 4 for record format instead of Section
> 3.1.  Is that correct?

The only is to make it clear that the Type SPF records that were defined in RFC 
4408 are no longer part of the protocol.  It is correct.  The ABNF for the 
record format is in section 4.

> In Section 3.2:
> 
>    "A domain name MUST NOT have multiple records that would cause an
>     authorization check to select more than one record."
> 
> This RFC 2119 MUST NOT was in RFC 4408.  Is this to help the SPF
> "publisher" and if so, how does it help?

4408 has an implicit requirement for this.  In section 4.5, it says:

> If the resultant record set includes more than one record, check_host()
> produces the "permerror" result.

The MUST NOT here makes it clear the condition has to be avoided.   It's not a 
functional change in the protocol.

> In Section 3.3:
> 
>    "As defined in [RFC1035] sections 3.3.14 and 3.3, a single text DNS
>     record can be composed of more than one string."
> 
> See previous comment about " a single string".
> 
>    "If a published record contains multiple character-strings, then the
>     record MUST be treated as if those strings are concatenated together
>     without adding spaces."
> 
> This RFC 2119 MUST is also in RFC 4408.  I suggest removing the
> "MUST" in the example.

Why?  If you don't do it that way, the result is not interoperable.

>    "TXT records containing multiple strings are useful in constructing
>     records that would exceed the 255-byte maximum length of a character-
>     string within a single TXT record."
> 
> I suggest using "octet" instead of "byte".  I'll point the working
> group to CVE-2008-2469 in case it might wish to consider that issue.

The CVE is unrelated.

> In Section 4:
> 
>    "A compliant SPF implementation MUST do something semantically equivalent
> to this description."
> 
> It's unusual to see a "do something" RFC 2119 requirement in a
> specification.  Is the SPFBIS WG working on compliance for SPF
> implementations?

It was added as part of making check_host() not a formal API/functional 
specification.  You need an equivalent result, but needn't follow all the steps 
exactly.  Please recommend an alternative.

>    "Mail receivers that perform this check MUST correctly evaluate the
>     check_host() function as described here."
> 
> Where does "mail receivers" fit in the Sender Policy Framework?  The
> "MUST correctly evaluate" is stating the obvious.

Receiving ADMDs.  Fixed.

>    "Implementations MAY use a different algorithm than the canonical
>     algorithm defined here, so long as the results are the same in all
>     cases."
> 
> Why is this a RFC 2119 MAY?  I am aware that the text is in RFC 4408.

trying to make it clear there's flexibility for the implementer.  Do you think 
it should be changed?

> 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.

> In Section 4.3:
> 
>    "If the <domain> is malformed (e.g. label longer than 63 characters,
>     zero-length label not at the end, etc.)"
> 
>   That should be "octets".

I recall further discussion about this in a later message in the thread.  I'll 
address it there.

>    "Properly formed domains are fully qualified email domains as
>     described in [RFC5321] Section 2.3.5."
> 
> What are "properly qualified email domains"?

What it says they are in the reference.

>    "Internationalized domain names MUST be encoded as A-labels, as
>    described in Section 2.3 of [RFC5890].on 2.3 of [RFC5890]."
> 
> I'm listing the above and leave it to Area Director guidance.  Please
> note that it is a new RFC 2119 requirement.

It's a new requirement because IDN wasn't addressed in 4408.  It's necessary 
to address it now and the WG agreed this was the best way to do it.

> In Section 4.4:
> 
>    "In accordance with how the records are published (see Section 3
>     above), a DNS query needs to be made for the <domain> name, querying
>     for type TXT only."
> 
> I don't understand the sentence.

What don't you understand?

>    '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.

> In Section 4.6.2:
> 
>    "If there are no more mechanisms, the result is specified in
>     Section 4.7."
> 
> This sentence does not make sense.

If I changed it to "If there are no more mechanisms, the result is the default 
result as described in section 4.7" would it be clearer?
> 
> 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?

> I read the first paragraph of Section 4.6.4.  I am not sure how the
> absolute requirement will be interpreted by the reader.

We worked on making it clearer.  If you have suggested improvements, please 
send them.

>    '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?

>    'SPF implementations SHOULD limit "void lookups" to two.'
> 
> What are void lookups?

The term is defined in the two immediately preceding sentences.

>    "In this case, a default of two is RECOMMENDED."
> 
> Why is "two" recommended?

Because that's the limit that is currently widely deployed (in the perl 
Mail::SPF implementation) with which there has been good experience.

>    'Note that records SHOULD always use either a "redirect" modifier or
>     an "all" mechanism to explicitly terminate processing.'
> 
> Why is there a RFC 2119 key word in a note?

Took out the 2119 word.

> In Section 4.8:
> 
>    'e.g., "foo..example.com") or overlong labels (more than 63
>     characters).'
> 
> I suggest octets.
> 
> in Section 5:
> 
>    'SPF implementations on IPv6 servers need to handle both "AAAA" and "A"
>     secords, for clients on IPv4 mapped IPv6 addresses [RFC4291].'
> 
> There is a typo, "records".

Already fixed.

> I'll flag the above for review by people with IPv6 expertise.

What's in -15 is the result of the review and WG feedback.

> In Section 5.3:
> 
>    'a   = "a"      [ ":" domain-spec ] [ dual-cidr-length ]'
> 
> "dual-cidr-length" is introduced in this sub-section.  I had to
> search through the draft to find out what it means.
> 
> In Section 5.4:
> 
>    'Note regarding implicit MXs: If the <target-name> has no MX records,
>     check_host() MUST NOT pretend the target is its single MX, and MUST
>     NOT default to an A or AAAA lookup on the <target-name> directly.'
> 
> There are two RFC 2119 MUSTs in the above.  This is over-usage of RFC
> 2119 key words.  This text was in RFC 4408.  This is not a divergence
> from RFC 5321, it is a contrary to Section 5 of RFC 5321.

It's not contrary.  It's saying that aspect of 5321 is not relevant to SPF.  
In any case, changing it would be a substantiative change to the protocol that 
would require all implementations to be updated.

> In Section 5.5:
> 
>   "This mechanism SHOULD NOT be used."
> 
> I suggest providing a reason for this.

The reason is given in the note at the end of the section.

>    "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 if 
you want.

>    "It is, however, still in use and part of the SPF protocol, so compliant
>    check_host() implementations MUST support it."
> 
> What is a compliant check_host() implementation?

One that works in accordance with 4408bis.  Please suggest an alternative if 
you don't like that.

> In Section 5.6:
> 
>    "ip6-network      = <as per [RFC 4291], section 2.2>"
> 
> I suggest that the above reference be verified for correctness.
> 
> In Section 5.7:
> 
>    'v=spf1 exists:%{ir}.%{l1r+-}._spf.%{d} -all'
> 
> I'll flag this for review by DNS folks.
> 
> 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?

> 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.

>    "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.

> In Section 7.1:
> 
>    'The "toplabel" construction is subject to the LDH rule plus
>     additional top-level domain (TLD) restrictions.'
> 
> Where can I find these restrictions?  Please note that I have read
> the Informational RFC.

LDH + non-numeric as the RFC says.

> In Section 7.3:
> 
>    "-exists:%(ir).sbl.spamhaus.example.org"
> 
> I commented about vendor-neutral previously [8].  The above is a way
> to get around the objection [9].  I suggest cleaning this up.

Took spamhaus out.

>   "so trailing dots SHOULD NOT be published by domain owners"
> 
> Why is it "domain owners"?

Took out everything after published.

>    "This macro SHOULD NOT be used.  See Section 5.5 for the discussion
>     about why not."
> 
> This comes out as a flippant explanation for the RFC 2119 SHOULD.

Please recommend non-flippant text then.  It doesn't read that way to me.

>    "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.

>    "When the result of macro expansion is used in a domain name query, if
>     the expanded domain name exceeds 253 characters (the maximum length
>     of a domain name), the left side is truncated to fit, by removing
>     successive domain labels (and their following dots) until the total
>     length does not exceed 253 characters."
> 
> Where is it specified that the maximum length of a domain name is 253
> characters?

This was covered in someone else's response.

>    "Care has to be taken by the sending ADMD so that macro expansion for
>     legitimate email does not exceed the 63-character limit on DNS labels."
> 
> Where is that 63-character limit specified?

This was covered in someone else's response.

> 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.

> 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.

> In Section 8.5:
> 
>    "The domain owner believes the host is not authorized but is not willing
>     to make a strong policy statement."
> 
> Why is it domain owner?

 Because conversion to the newer terms was incomplete.  I clean up this and 
some others as well.

> In Section 9:
> 
>    "An operator could choose to use both to serve different downstream
>     agents.  In such cases, care needs to be taken to ensure both fields
>     are conveying the same details, or unexpected results can occur."
> 
> This has been discussed on the mailing list.  I don't think that it
> encourages interoperability but the working group decided otherwise [10].
> 
> In Section 9.1:
> 
>    "The Received-SPF header field is a trace field (see [RFC5322] Section
>     3.6.7) and SHOULD be prepended to the existing header, above the
>     Received: field that is generated by the SMTP receiver."
> 
> "prepended to the existing header" does not sound right.

I believe it is.

>    "It MUST appear above all other Received-SPF fields in the message."
> 
> How does this fit into the previous RFC 2119 SHOULD?

It will generally happen as a natural result of following the previous one, 
but is there in case more than one is added by a single MTA.

> in Section 10:
> 
>    "This section is not a "how-to" manual, or a "best practices" document,
>     and it is not a comprehensive list of what such entities SHOULD do in
>     light of this document."
> 
> What is the meaning of the RFC 2119 SHOULD in the above?

Got rid of it.
> 
> 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.

> 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.pdf

> In Section 10.1.3:
> 
>    "SPF functionality is enhanced by administrators ensuring this
>    identity is set correctly and has an appropriate SPF record."
> 
> How is SPF functionality enhanced?

If there's an SPF record for HELO as well as Mail From, then a check can be 
performed on bounces.

> In Section 10.2:
> 
>    "As stated elsewhere in this document, there is no normative requirement
>     for specific handling of a message based on any SPF result."
> 
> The "as stated elsewhere" is vague.

It comes up multiple places.  Adding several specific reference won't improve 
the draft.

>    'The primary considerations are that SPF might return "pass" for mail
>     that is ultimately harmful (e.g., spammers that arrange for SPF to
>     pass using nonsense domain names'
> 
> What are "nonsense" domain names?

There was follow-on discussion about this.

> In Section 10.3:
> 
>    "The mediator can make the newly-posted message be as similar or as
>     different from the original message as they wish."
> 
> The sentence seems incomplete, i.e. similar to what.

The original message.

>    "For the operation of SPF, the essential concern is the email
>     address in the 5321.MailFrom command for the new message."
> 
> What does this mean?

It means that's the thing that's the most important.

>    'Because SPF evaluation is based on the IP Address of the "last"
>     sending SMTP server, the address of the mediator will be used, rather
>     than the address of the SMTP server that sent the message to the
>     mediator.'
> 
> I'll note that this is a mix of RFC 5321 and RFC 5598.  The result is
> clear or unclear depending on the background of the reader.

I guess I have the background for it to be clear.  Please suggest an 
improvement.

> 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.

> In Section 11.6:
> 
>    "Checking SPF records causes DNS queries to be sent to the domain
>     owner."
> 
> How are DNS queries sent to domain owners?

Fixed it.

> Section 12:
> 
> I note that Murray S. Kucherawy has contributed significantly to
> draft-ietf-spfbis-4408bis.  If I am not mistaken it is IETF practice
> to acknowledge such contributions.  I don't recall who sent text at
> the moment.  If you did, please send an (off-list) email to the
> SPFBIS WG Chairs.

There are many, many people who contributed to both 4408 and 4408bis that 
aren't listed.  If someone wants to make a list of people who made a 
significant contribution, I'll be glad to include it.

> In Section 13.1:
> 
>    "The format of this type is identical to the TXT RR [RFC1035]"
> 
> The format is not identical, i.e. it's a different RR.  I suggest
> keeping the IANA Considerations Section simple, i.e. clearly explain
> to IANA what action is requested.

Yes, it is.

> In Section 13.2:
> 
>    "Per [RFC3864], the "Received-SPF:" header field is added to the IANA
>     Permanent Message Header Field Registry."
> 
> Note to self: request removal from the provisional message  header
> field registry.
> 
> The "status:" should be "standard"

Not Standards Track?

> In Section 13.3:
> 
>    "Their status should not be changed."
> 
> I suggest "Their status is unchanged".  BTW, it should be "SPF
> Modifier Registry".

Fixed

> I suggest following RFC 6652 Section 5.1.

> An "Updates:" for RFC 6652 may be needed.

Why?  It's the registry that gets updated, not 6552.
> 
> References:
> 
> Why is RFC 1123 a normative reference?

See section 2.4.
> 
> Why is RFC 3864 a normative reference?

Because it defines how the Received-SPF registration is done.
> 
> Where can I find "Designated Mailers Protocol"?

See draft-fecyk-dsprotocol
> 
> Where can I find "Domain-Authorized SMTP Mail"?

I don't have a copy of this.

> ABNF:
> 
> Did anyone verify the ABNF?
> 
> In Appendix C:
> 
> In Section E.1:
> 
>    'This would cause a lookup on an DNS white list (DNSWL) and cause a
>     result of "fail" only for email not either coming from the
>     domain's mx host(s) (SPF pass) or white listed sources (SPF
>     neutral).'
> 
> I didn't find any discussion about this on the SPFBIS mailing
> list.  is there an explanation for this change between RFC 4408 and this
> draft?

It was pointed out that this is a white list, not a black list.

> I note that there are 48 pages in RFC 4408.  There are 78 pages in
> this draft.  A significant amount of text has been added in the
> Appendix (over 20 pages).  I doubt that the text has been carefully
> reviewed.  I may be asked for an explanation about all that once the
> draft leaves this working group.

Why wait?

> 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."
> 
> 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".

>    "This document updates and replaces RFC 4408 that was part of a group
>     of simultaneously published Experimental RFCs (RFC 4405, RFC 4406,
>     RFC 4407, and RFC 4408) in 2006.  At that time the IESG requested the
>     community observe the success or failure of the two approaches
>     documented in these RFCs during the two years following publication,
>     in order that a community consensus could be reached in the future."
> 
> Why is this needed?  The SPFBIS WG produced RFC 6686 to resolve the
> experiment.

Since this is what obsoletes 4408, not everyone will read 6686.

>    "SPF is widely deployed by large and small email providers alike.
>     There are multiple, interoperable implementations."
> 
> Someone might point out that this is marketing instead of text
> relevant to a protocol.  I'll mention that one or more significant
> issues (e.g. Issue #9) was identified during the WG
> discussions.  Issue #9 was not listed as the errata.  I suggest
> removing the section as it will be less text and there is already two
> informative references to help the reader find background information.

#9 has been known since before 4408 was published.  In 2005 it was the price 
of admission to the IETF.

> 1. http://www.ietf.org/mail-archive/web/spfbis/current/msg02371.html
> 2. http://www.ietf.org/mail-archive/web/spfbis/current/msg00928.html
> 3. http://www.ietf.org/mail-archive/web/spfbis/current/msg01810.html
> 4. http://www.ietf.org/mail-archive/web/spfbis/current/msg03378.html
> 5. http://trac.tools.ietf.org/wg/spfbis/trac/ticket/1
> 6. http://www.ietf.org/mail-archive/web/spfbis/current/msg00630.html
> 7. http://www.ietf.org/mail-archive/web/spfbis/current/msg00199.html
> 8. http://www.ietf.org/mail-archive/web/spfbis/current/msg02279.html
> 9. http://www.ietf.org/mail-archive/web/spfbis/current/msg02308.html
> 10. http://www.ietf.org/mail-archive/web/spfbis/current/msg02526.html
> 11. http://www.ietf.org/mail-archive/web/spfbis/current/msg02763.html
> 
> _______________________________________________
> spfbis mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/spfbis

---

From: Mark Andrews <[email-masked]>
Date: Fri, 17 May 2013 07:54:23 +1000

> Would s/domain/domain name/ clear it up for you?

"com" is a fully qualified domain.  Multi-label domain is the term
being looked for. 
 
Mark
-- 
Mark Andrews, ISC
1 Seymour St., Dundas Valley, NSW 2117, Australia
PHONE: +61 2 9871 4742                 INTERNET: [email-masked]

---

From: Scott Kitterman <[email-masked]>
Date: Thu, 16 May 2013 18:00:57 -0400

> "com" is a fully qualified domain.  Multi-label domain is the term

Thank you.  Incorporated.

Scott K

---

From: "Murray S. Kucherawy" <[email-masked]>
Date: Thu, 16 May 2013 17:28:14 -0700

> "com" is a fully qualified domain.  Multi-label domain is the term
Interesting.  What would be an example of something that a domain name but
isn't a fully-qualified domain name?

-MSK

---

From: S Moonesamy <[email-masked]>
Date: Thu, 16 May 2013 18:36:14 -0700

Hi Scott,

Murray Kucherawy, Alessandro Vesely, John Levine and Stuart Gathman 
commented about this review.  I'll cover these comments in my 
response.  By the way if I missed any of the comments please let me know.

I'll follow the guidance in the message at 
http://www.ietf.org/mail-archive/web/spfbis/current/msg03642.html for 
RFC 2119 key words.

>Would s/domain/domain name/ clear it up for you?

I'll suggest the following:

   This SPF check can only be performed when the "HELO" string is a
   fully-qualified domain name.

>Is there a reason to change it?

 From a previous comment:

   'In a recent conversation, Pete described this as "not really wrong, but
    it's shouting." I guess that means changing "MUST publish" to "publishes"
    or something like that.

   I am ok with the "publishes".'

I suggest using that.

>result.  You won't interoperate with receivers in that way effectively if you

I mentioned this in another message:

Andrew Sullivan, as an individual, commented about the text (
http://www.ietf.org/mail-archive/web/spfbis/current/msg02784.html
  ). I suggest going with what was suggested or else the working 
group will be discussing Issue #33 again.

>Modified to make them non-redundant.

I suggest including the proposed text for any changes so that the 
working group is aware of the text will be added to the revision of the draft.

>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.

>Please check when -15 is published.

The comment I read on the mailing list is:

   "I agree, that sentence can probably go."

The other comment was from Alessandro.  Does your comment mean that 
the sentence will be removed or does it mean that text is being proposed?

>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".

> > an enhancement or 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".

>seems redundant since it says "retrieved from the DNS".

I left this DNS angle for Andrew to comment.

>Would operator intervention or operator action be better?

I suggest "operator intervention" (there was a comment about this).

>explicitly not authorized.

Ok.

>I think this was addressed in a later comment and it should be improved.

There was a suggested text:

   "An SPF policy statement is expressed as a single string of text encoded in
    a DNS TXT record."

and:

   "The SPF record is a variable length string of octets encoded in
    a DSN TXT record."

>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 took try out of the section.  I think that should do it.

There was a comment that:

  "SHOULD minimize" conflicts with one intended use, namely

    v=spf1 redirect=_spf.example.com

   Exemplified in Section 6.1, that use does not attain the minimum.

>record format is in section 4.

There were two comments:

   "The reference is indeed incorrect."

and:

  'Should we say "is described along with its interpretation in Section
   4.5"?  How about changing the title of Section 4.5 to "Record Format"?'

>functional change in the protocol.

Ok.

>Why?  If you don't do it that way, the result is not interoperable.

I'll take some text from the Responsible Area Director:

   "MUSTs are normally instructions for protocol actions or 
implementation coding".

I suggest not using it in examples.

>exactly.  Please recommend an alternative.

I suggest fixing the "do something"

>trying to make it clear there's flexibility for the implementer.  Do 

I'll leave this as it is, i.e. no change suggested.

>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.

>I recall further discussion about this in a later message in the 

Ok.

>What it says they are in the reference.

There was the following comment:

   "Properly formed domains are described in [RFC5321] Section 2.3.5.

    The wording is not that good but I could not think of anything better."

There was another comment:

   'The term "email domain" lacks a formal definition, and is used improperly
    in Section 4.3 since HELO needs not be an email domain in some sense.
    I'd s/fully qualified email domains/fully-qualified domain names/.'

>to address it now and the WG agreed this was the best way to do it.

Ok.  I am leaving this to the Responsible Area Director.

>What don't you understand?

I commented previously about this: "I read the first paragraph of 
Section 4.4 as meaning that the DNS query is for Type TXT only. I 
suggest explaining that the record lookup is done by query for the 
SPF record described in Section 3. By the way, the text you suggested 
for Section 3 fits in nicely".

>Yes.  This is a change to address an operational issue found during SPF

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".

>result as described in section 4.7" would it be clearer?

The follow text was proposed in a comment:

   "After all mechanisms have been processed and no matches are found, the
    result is determined according to Section 4.7."

>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.

>We worked on making it clearer.  If you have suggested improvements, please

Could you please provide the proposed text?

>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 see what Points (a) or (b) has to do with interoperability. 
Trying to common factor the RFC 2119 SHOULD reduces occurrences of 
the word instead of addressing the issue. I suggest understanding the 
intent first before working on the text to be added.

Alessandro and Murray did not agree with the above.

>The term is defined in the two immediately preceding sentences.

Ok.

>Mail::SPF implementation) with which there has been good experience.

Ok.

> > Why is there a RFC 2119 key word in a note?

Ok.

> > There is a typo, "records".

Ok.

>What's in -15 is the result of the review and WG feedback.

As a note for the working group, Simon Perreault proposed text about this.

>would require all implementations to be updated.

There are changes listed in Appendix C.  Implementations will have to 
be updated anyway in my opinion.  I'll discuss this matter with the 
Responsible Area Director.

>The reason is given in the note at the end of the section.

The following text was suggested:

   "This mechanism SHOULD NOT be used it is not as reliable as other mechanisms
    in cases of DNS errors, and it places a large burden on the .arpa 
name servers."

>interoperation).  For the SHOULD, it's an optimization.  We can change it if

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".

>One that works in accordance with 4408bis.  Please suggest an alternative if

I am ok with what the working group wants.

> > This text is in RFC 4408.  I would label the RFC 2119 usage as defective.

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".

>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")'.

>I don't understand the comment.

There was a comment from Murray:  "we're talking about 
interoperability between humans here, and not between implementations".

>LDH + non-numeric as the RFC says.

I'll get back to this issue.

> > to get around the objection [9].  I suggest cleaning this up.

Ok.

>Took out everything after published.

Ok.

>Please recommend non-flippant text then.  It doesn't read that way to me.

   "This macro SHOULD NOT be used (See Section 5.5 for discussion).

> > The RFC 2119 key words are in RFC 2119.  I don't know what to say.

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.)

>This was covered in someone else's response.

Ok.

>This was covered in someone else's response.

Ok.

>They aren't really notes in that sense.  If you have a better name for the

I suggest removing all the RFC 2119 requirements in Section 7.3 if 
the working group cannot find a way to fix this.

>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.

>  Because conversion to the newer terms was incomplete.  I clean up this and

Ok.

> > "prepended to the existing header" does not sound right.

Murray explained this in a comment about the review.

>but is there in case more than one is added by a single MTA.

Murray commented on this.

> > What is the meaning of the RFC 2119 SHOULD in the above?

Ok.

>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.

>http://www.bits.org/publications/security/BITSEmailAuthenticationFeb2013.pdf

I suggest "good practice" as mentioned by Alessandro.

>If there's an SPF record for HELO as well as Mail From, then a check can be

Ok.

>It comes up multiple places.  Adding several specific reference won't improve

I suggest adding a reference to Section 8 (subject to the AppsDir 
review being addressed).

>There was follow-on discussion about this.

"discardable" was suggested.

> > The sentence seems incomplete, i.e. similar to what.

Ok.

>It means that's the thing that's the most important.

Ok if the working group agrees.

>I guess I have the background for it to be clear.  Please suggest an

I suggest leaving it as it if there isn't any disagreement.

>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".

> > How are DNS queries sent to domain owners?

Ok.

>significant contribution, I'll be glad to include it.

My understanding is that it is the task of the document editor to 
keep track of contributions and contributors.  There is a message at 
http://www.ietf.org/mail-archive/web/spfbis/current/msg03059.html 
where it is mentioned that:

   "2.  Scott, in collaboration with Murray Kucherawy (who proposed
       the original reorganization), undertakes the reorganization and
       creates the next WG document."

> > The "status:" should be "standard"

I verified this again; it's "standard".

> > I suggest "Their status is unchanged".  BTW, it should be "SPF

Ok.

>Why?  It's the registry that gets updated, not 6552.

I'll ask the Area Director.

> > Why is RFC 1123 a normative reference?

Ok.

>Because it defines how the Received-SPF registration is done.

Ok.

>See draft-fecyk-dsprotocol

Ok.  As a note for the working group, I could not find the draft.

>I don't have a copy of this.

I suggest dropping the reference.

>It was pointed out that this is a white list, not a black list.

I suggest dropping this change as it was not discussed within the 
working group.

> > draft leaves this working group.

I am not the person doing the IESG evaluation.

>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.

>Since this is what obsoletes 4408, not everyone will read 6686.

There is an informative reference to RFC 6686.  I don't see why the 
text mentioned above is needed.

>of admission to the IETF.

My suggestion as document shepherd is to avoid that discussion.  The 
draft will face a very difficult Last Call as it is and more 
controversies won't make matters any better.

Regards,

---

From: Mark Andrews <[email-masked]>
Date: Fri, 17 May 2013 13:01:43 +1000

In message <CAL0qLwa=[email-masked]>
, "Murray S. Kucherawy" writes:
> --001a11c262e808006a04dcdf0f17
> Content-Type: text/plain; charset=ISO-8859-1
> 

	foo in foo.bar.example.net
	foo.bar in foo.bar.example.net
	foo.bar.example in foo.bar.example.net

	foo is unqualified
	foo.bar is partially qualified
	foo.bar.example is partially qualified

	Now w.r.t. SMTP HELO/EHLO you have no way of determining
	if a name is partially qualified or not.  Additionally
	there isn't any reliable way to qualify a name if you
	could.

	Mark

---

From: Scott Kitterman <[email-masked]>
Date: Fri, 17 May 2013 02:37:39 -0400

>    fully-qualified domain name.

Done.

>     it's shouting." I guess that means changing "MUST publish" to
> "publishes" or something like that.
> 

Done.

> >result.  You won't interoperate with receivers in that way effectively if
> >you don't.
> 

OK.  I still find it confusing that things that are needed for the protocol to 
function are not considered requirements, but changed.

> working group is aware of the text will be added to the revision of the

That's not always easy to do.  In this case, it would be hard to evaluate out 
of context, so I think it's best to wait for the next revision.

>      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.

> >This was changed already due to other comments.  I think it makes sense
> >now. Please check when -15 is published.
> 

It means it was changed based on other comments.  Please look at -15 and see 
if you still think it's a problem.

> >It seems clear to me.  Could you expand on why you think it's problematic
> >or provide recommended text.
> 

I don't understand what you think is wrong.  Repeating the comment won't help.  
I did read it.  I don't understand it.

> that it is neither an enhancement or a clarification.  I suggest

So you think it's not something that should be avoided?

OK.

> I suggest "operator intervention" (there was a comment about this).

OK.  Changed.

>    "An SPF policy statement is expressed as a single string of text encoded
> in a DNS TXT record."
> 
> and:
> 

I split the difference and put in:

The SPF record is expressed as a single string of text encoded in a  DNS TXT 
record.

> explanation or rewriting the text so that the expression (see above)

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.

>    Exemplified in Section 6.1, that use does not attain the minimum.

If it makes sense to use the redirect then that's the minimum.  If we truly 
wanted the absolute minimum physically possible, we'd only have ip4, ip4, and 
maybe include mechanisms.  I don't think there's a conflict.

>    4.5"?  How about changing the title of Section 4.5 to "Record Format"?'

Changing the title to Record Format would be wrong because it's not just the 
format.  I changed it to "The record format and the process for selecting  
records is described in ..."

> I suggest not using it in examples.

OK.  I changed it to "is equivalent to:"

> > > In Section 4:
> > >    "A compliant SPF implementation MUST do something semantically
> > 
> > equivalent
> > 
> > > to this description."
> > > 

OK.  I changed it to produce results.

> 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 term "email domain" lacks a formal definition, and is used
> improperly in Section 4.3 since HELO needs not be an email domain in some
> sense. I'd s/fully qualified email domains/fully-qualified domain names/.'

OK.  I took email out.

> >It's a new requirement because IDN wasn't addressed in 4408.  It's
> >necessary to address it now and the WG agreed this was the best way to do
> >it.

Sorry, still confused.   "I read the first paragraph of Section 4.4 as meaning 
that the DNS query is for Type TXT only."  That's correct, so I think you do 
understand the sentence.

> 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.

>     result is determined according to Section 4.7."

OK, but you didn't answer the question.  Would the text I proposed clarify 
things for you?  I like it better than the comment you brought up because I 
think it's clearer, so I'd prefer to use it if you think it's OK.

> 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.

> Could you please provide the proposed text?

No, I don't have any more proposed text.  I was saying the WG has already 
worked over trying to clarify this section.  I think we've done our best,  to 
clearly express something that is complicated.  I don't think "do it better" 
is going to result in further improvements, so if you have an idea how to 
improve it, please provide it.

>    (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.
> intent first before working on the text to be added.

They are about defining some consistent limits/expectations in order to avoid 
both impedance between senders and receivers and the potential security 
implications of not implementing proper limits.

OK.  It's from RFC 4408, so I don't think it should be changed:

>    MTAs or other processors MAY also 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".

> As a note for the working group, Simon Perreault proposed text about this.

There were several suggestions, some of them inconsistent with actual practice 
experienced by some WG members with real operating systems.  I chose to go 
with the text that supported getting interoperable results regardless of OS.

> Responsible Area Director.

What is there to discuss?  It's NOT a change from 4408?  Changing it from 
what's there now would be out of scope for our charter.

>    "This mechanism SHOULD NOT be used it is not as reliable as other
> mechanisms in cases of DNS errors, and it places a large burden on the
> .arpa name servers."

In -14, it already says:

>    Note: This mechanism is slow, it is not as reliable as other
>    mechanisms in cases of DNS errors, and it places a large burden on
>    the .arpa name servers.  

What should I change?

> >interoperation).  For the SHOULD, it's an optimization.  We can change it
> >if you want.
> 

Obvious to you.  Not obvious to everyone.

> >One that works in accordance with 4408bis.  Please suggest an alternative
> >if you don't like that.
> 

That is defective use of 2119 language?  I disagree that that would be 
clearer.

> >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.
> 

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.

> interoperability between humans here, and not between implementations".

We're talking about avoiding security issues caused by the humans getting 
confused.

>    "This macro SHOULD NOT be used (See Section 5.5 for discussion).

Done.

> 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.

> the working group cannot find a way to fix this.

Why?  How about if we call it "Details" instead of Notes?

> 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.

> I suggest "good practice" as mentioned by Alessandro.

What's wrong with the way it is?  I think the current text is accurate.

> >It comes up multiple places.  Adding several specific reference won't
> >improve the draft.
> 

The next sentence has a reference to Section 8.

> "discardable" was suggested.

I went with disposable, since discardable is a specific term of art in other 
email authentication related documents and I don't want to create potential 
for confusion.

> input is unverified is probably in order, with references if possible".

I think the section explains exactly that, so some text would help.

>        creates the next WG document."

I think to single out one person in this way would be unfair to other people 
that made significant contributions.  The original 4408 acknowledgements 
weren't done this way and so I think it's literally impossible to properly 
develop an acknowledgements section that would be fairly done.  This is not to 
knock down Murray's contribution, which I agree has been significant.

There was a thread about this on the IETF main list in late March.  Working 
groups vary significantly.  What's in the draft for acknowledgements has been 
there, virtually unchanged since last summer.  If you really want a reasonable 
list of contributors, we'll need to discuss a new schedule because this won't 
finish in May.

Fixed.

> 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

> 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 suggest dropping this change as it was not discussed within the

Yes.  It was.

> I am not the person doing the IESG evaluation.

OK.  I misunderstood your comment.  I think you're wrong about the lack of 
review though.

> 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?

> text mentioned above is needed.

I think the section is incomplete without it.

> >#9 has been known since before 4408 was published.  In 2005 it was the
> >price of admission to the IETF.
> 

I'm not the one claiming it was discovered by the WG.  I'm not sure what 
controversy you think I'm adding.

Scott K

---

From: Scott Kitterman <[email-masked]>
Date: Fri, 17 May 2013 02:57:12 -0400

On Monday, April 29, 2013 01:21:22 AM Murray S. Kucherawy wrote:
> > I suggest using "octet" instead of "byte".  I'll point the working group
> > to CVE-2008-2469 in case it might wish to consider that issue.
> 
> How is an octet different from a byte in this context?  This strikes me as
> a stylistic issue at best.

> Since the DNS is all in ASCII, they're synonymous.  That said, we may as
> well be consistent.

I've gone through and searched for both byte and character (there were both) 
and made them octets (when character was relevant to this, it's used in other 
ways too, so we're consistent.

Scott K

---

From: Scott Kitterman <[email-masked]>
Date: Fri, 17 May 2013 03:00:20 -0400

On Monday, April 29, 2013 01:21:22 AM Murray S. Kucherawy wrote:
> > There are two RFC 2119 MUSTs in the above.  This is over-usage of RFC 2119
> > key words.  This text was in RFC 4408.  This is not a divergence from RFC
> > 5321, it is a contrary to Section 5 of RFC 5321.
> 
> I believe the advice should remain, but it could be simplified:
> 
> "Note regarding implicit MXes: If the <target-name> has no MX records,
> check_host() MUST NOT apply the implicit MX rules of RFC5321 by querying
> for an A record for the same name."

Thanks.  Done.

Scott K

---

From: Scott Kitterman <[email-masked]>
Date: Fri, 17 May 2013 03:10:10 -0400

On Monday, April 29, 2013 07:36:26 AM Dave Crocker wrote:
>     Internet Users' Glossary", FYI 18, RFC 1983
>     http://tools.ietf.org/html/rfc1983
> 
>     Fully Qualified Domain Name (FQDN)
>        The FQDN is the full name of a system, rather than just its
>        hostname.  For example, "venera" is a hostname and
>        "venera.isi.edu" is an FQDN.  See also: hostname, Domain Name
>        System.
> 
> I suggest merely citing this RFC.

Done.

> >        "Implementations have to take care to correctly extract the
> ><domain> from the data given with the SMTP MAIL FROM command as many MTAs
> >will
> >     implementation perspective the last paragraph of Section 2.4 is
> >unclear.>
> > I don't agree.  I imagine by now you're aware of what this is for; can
> > you suggest some other text that accomplishes the intent?
> 
> On reflection, it might avoid some reader confusion to define have the 
> label be something like <spf-domain>, so that <domain> isn't overloaded 
> with a specialized definition for this document.

I don't think it's that specialized.  I think such a change would cause people 
to wonder how it was different and cause more confusion than it resolved.

Scott K

---

From: Scott Kitterman <[email-masked]>
Date: Fri, 17 May 2013 03:19:12 -0400

On Monday, April 29, 2013 05:32:16 PM Alessandro Vesely wrote:
> On Mon 29/Apr/2013 10:21:22 +0200 Murray S. Kucherawy wrote:
> > Scott and I talked a bit about some of these points, and I thought it
> > might
> > help if I went through the whole thing and commented on it.  I hope this
> > is
> > helpful.  I've chopped out stuff where I have no specific response or
> > opinion about the points made, so this is only a nearly-complete reply.
> 
> I add a few lines, in case consensus needs to be gauged.
> 
> > On Tue, Apr 23, 2013 at 4:08 PM, S Moonesamy <[email-masked]> wrote:
> >> In the Abstract:
> >> ADMD should be expanded in the above.  This was pointed out in a review
> >> posted on August 26, 2012 [1].
> > 
> > Agree.
> 
> +1, good style.
> 
> >> In Section 2.1:
> > You made these notes throughout your review.  I take it there's no action
> > for the WG here; you are just auditing "out loud" what normative things in
> > 4408bis were also present as-is in 4408, and which have changed.
> > 
> >> This RFC 2119 "MUST" is not in RFC 4408.  It is a substantive change in
> >> my
> >> opinion.
> > 
> > This was probably at my suggestion.  The issue here is that RFC2119
> > doesn't
> > say "must" has any different meaning than "MUST" does, so we should either
> > be consistant and uppercase-ize it, or use some other word.
> 
> +1 for some other word.
> 
> > In any event, I don't agree that this is actually a substantive change.
> 
> +1, sanitizing input is part of any protocol.
> 
> > I believe it means "a name comprising a sequence of DNS labels, separated
> > by dot characters, which when queried resolve to an A or MX record".  It
> > may have a proper definition in some other RFC too.  Should we add one in
> > the Introduction or Definitions?
> 
> "What is a Fully Qualified Domain Name?" is the title of Section 5.2
> of RFC 1594.
> 
> >> In Section 2.3:
> > In a recent conversation, Pete described this as "not really wrong, but
> +1, that would be the definition of an SPF-compliant domain.
> 
> >>    do,
> >>    otherwise, no definitive determination of authorization can be made.'
> >> 
> >> The document uses ADMD while there is "domain owners" in the above.  I
> >> suggest reviewing that.
> > 
> > I think they're synonymous.  Going with ADMD is probably a good idea.
> 
> Just mentioning that they they are synonyms, e.g. in the 1st paragraph
> of the introduction, might be handier to readers who are not familiar
> with the term.
> 
> > It is the only way within the protocol to cause negative authorization
> > determinations to occur.  It is an interoperability requirement.  I
> > believe
> > this is correct.
> 
> +1, an equivalent wording could be:
> 
>    An SPF-compliant domain needing to support receivers making
>    negative authorization determinations MUST...
> 
> >> In Section 2.4:
> >> 2119
> >> RECOMMENDED in Section 2.1.  The above text restates existing RFC 2119
> >> requirements or recommendations.
> > 
> > I agree; the redundancy should be resolved.  The cited sentence in 2.4 can
> > probably go.
> 
> -1, Section 2.4 is the proper place to say that.  Sections 2.1 and 2.2
> should be just definitions.  They are garbled and it's they who
> deserve corrections.
> 
> >> How should this explicit approval be sought?  This recommendation does
> >> not
> >> make sense.
> > 
> > Adding "out-of-band" or "private" after "explicit" would probably clear
> > this one up.
> 
> How about defining the concept of (private or standard) "extension"?
> 
> >> In Section 2.4:
> >> there is a requirement in draft-ietf-spfbis-4408bis-14 to use a correct
> >> implementation of draft-ietf-spfbis-4408bis-14.
> > 
> > I agree, that sentence can probably go.
> 
> +1
> 
> >> I am not sure whether it is even a definition.  From an implementation
> >> perspective the last paragraph of Section 2.4 is unclear.
> > 
> > I don't agree.  I imagine by now you're aware of what this is for; can you
> > suggest some other text that accomplishes the intent?
> 
> I don't think we need to specify how to treat archaic input.  To
> mention it is right and proper, though.
> 
> > Yes.
> +1
> >> 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?
> > 
> > I think it documents operational experience acquired since RFC4408 was
> > published.  As for whether RFC2119 language is appropriate, I agree that
> > it
> > isn't; it has nothing to do with SPF itself, though it is a side effect of
> > its use.  I suggest changing SHOULD to "needs to".
> 
> +1, note that both RFC 5321 (silent dropping of messages should be
> considered) and RFC 3464 (should take appropriate precautions) have
> lowercase "should".
> 
> >> In Section 2.6:
> >> John Levine commented about this during the WGLC [4].  I am listing this
> >> as a reminder for myself.
> > 
> > I agree with John.
> 
> +1 for "semantically equivalent".
> 
> >> In Section 2.6.1:
> >> I suggest "DNS TXT records".  What is a syntactically valid DNS domain
> >> name?  The definition of "none" in RFC 4408 is clear (to me).
> > 
> > "DNS TXT records" is fine but probably not necessary at this point in the
> > document.
> 
> +1
> 
> > We discussed the "syntactically valid" thing above.
> > 
> > This definition of "none" is more precise than it was in RFC4408.  The
> > 4408
> > 
> > definition was:
> >    A result of "None" means that no records were published by the domain
> >    or that no checkable sender domain could be determined from the given
> >    identity.  The checking software cannot ascertain whether or not the
> >    client host is authorized.
> > 
> > This text did not account for the notion that TXT records were returned
> > that didn't start "v=spf1".  It also wasn't clear about what "checkable"
> > meant.  I believe the bis definition is better.
> 
> +1
> 
> >> In Section 2.6.2:
> >> As a note, the RFC 2119 MUST is in RFC 4408.  The Introduction Section
> >> mentions "ADMDs can authorize hosts to use their domain names".  The
> >> above
> >> uses "domain owner".
> > 
> > Covered earlier.
> > 
> >> In Section 2.6.7:
> > "Operator intervention" might be more consistent with common IETF usage.
> 
> Either wording tends to imply that it is clear who should do what in
> order to resolve the permerror.  That's not always the case (e.g.
> multiple void lookups).
> 
> >> In Section 3:
> >> How are hosts which are not authorized to use a domain name listed in a
> >> SPF record?
> > 
> > It's implicit in that the set that is not authorized is the complement to
> > the set that is authorized.  If we want to make it clear, we could say
> > "which hosts are, and thus also which are not," or something like that.
> 
> Well, not authorized is "-", authorized is "+", but we cannot make it
> clear without mentioning the other qualifiers too.  I suggest leaving
> that as is.
> 
> >> What is a single string of text?  It may be easier to state this in terms
> >> of record format.
> > 
> > I don't think that statement is unclear, but I agree with the improvement
> > suggestion.  Maybe:
> > 
> > in
> Leave off "single string" (Section 3.3 title is "Multiple Strings in a
> Single DNS record").  We could reuse "string of octects" from RFC
> 1035, e.g.:
> 
>    The SPF record is a variable length string of octets encoded in
>    a DSN TXT record.
> 
> > There isn't a specific minimum.  The expression means "don't use this
> > technique unless you absolutely need it".
> 
> Yes, that sense is conveyed with "SHOULD try" --must consider some
> alternative ways that result in a smaller number of include/redirect.
> 
> >> This RFC 2119 SHOULD is also in RFC 4408.  There are two RFC 2119 SHOULDs
> >> in the last paragraph of Section 3.  This usage of RFC 2119 key words
> >> does
> >> not help the SPF "publisher".   In my opinion the "SHOULD try" in this
> >> context uses the RFC 2119 key word in unorthodox ways.
> > 
> > I agree with "SHOULD try", as that's arguably not actionable.  "SHOULD
> > minimize" is probably fine, however.
> 
> >> I would ask why "MUST be published ... only".  By the way, Section 3 has
> >> a
> >> reference to Section 4 for record format instead of Section 3.1.  Is that
> >> correct?
> > 
> > The text is not incorrect, but it's also not necessary.  Dropping "only"
> > is
> > probably sufficient.
> 
> +1, we don't need to stress that the other type was discontinued.
> 
> > The reference is indeed incorrect.
> 
> Should we say "is described along with its interpretation in Section
> 4.5"?  How about changing the title of Section 4.5 to "Record Format"?
> 
> >> In Section 3.2:
> > I believe it is an advisory to publishers of the consequences of having
> > more than one "v=spf1" record published.
> 
> Yup
> 
> >> In Section 3.3:
> > This use is correct, as it describes the fact that there are many ways to
> > encode a single high-level string into multiple low-level
> > "character-strings" as defined in RFC1035.
> 
> +1, but I wouldn't mention the level of strings in the I-D...
> 
> >> This RFC 2119 MUST is also in RFC 4408.  I suggest removing the "MUST" in
> >> the example.
> > 
> > I disagree.  It's required for interoperability.
> 
> +1, are there DNS libraries that do otherwise?
> 
> +1 for s/byte/octet/, even if it's stylistic:
> 
>    The size of the byte has historically been hardware dependent and
>    no definitive standards existed that mandated the size.
>                                    http://en.wikipedia.org/wiki/Byte
> 
> >> In Section 4:
> >>    equivalent to this description."
> >> 
> > RFC6376 is an example of a standards track document that uses RFC2119 MUST
> > in this way.  I'm sure I've seen others but I can't think of them at this
> > hour.  I think it's fine.
> 
> Would it be better to s/do something/behave in a way/?
> 
> >> "MUST
> >> correctly evaluate" is stating the obvious.
> > 
> > I'm not understanding how the answer to the first question isn't obvious.
> > 
> > I agree with the second point.
> 
> I propose to remove that sentence.
> 
> > This seems to me to be another stylistic question, since MAY in RFC2119
> > terms doesn't mean much.
> 
> It helps understanding the previous MUST, they are two poles that
> implementations have to stay in between.
> 
> >> In Section 4.1:
> > I think I agree; I would prefer to have it defined in one place, and have
> > other points in the document reference it.
> 
> +1, Section 2.4 can refer to Section 4.1.  However, Section 2.4 needs
> to mention how the <sender> parameter should be set in each of the checks.
> 
> >> In Section 4.3:
> Yeah, but ASCII is 7-bit...
> 
> > Is the reference defining that term not appropriate?
> 
> IMHO the reference is fine.  The term "email domain" lacks a formal
> definition, and is used improperly in Section 4.3 since HELO needs not
> be an email domain in some sense.  I'd s/fully qualified email
> domains/fully-qualified domain names/.
> 
> > I'm pretty sure RFC4408 pre-dates most of the IDN work, so this is a
> > modernization step.  I think it's important to include, and it also does
> > the same thing DKIM did, which is now Draft Standard.  If we don't,
> > there's
> > no guidance for use of SPF in the IDN context.  The alternative is to spin
> > up another document (which we're not chartered to do) that discusses use
> > of
> > SPF in the IDN context.
> 
> Fully agree with Murray.  However, it is not layer-wise clear whether
> any A-label conversion is to be carried out as initial processing
> within check_host().
> 
> >> In Section 4.4:
> > Query the HELO domain or the MAIL FROM domain, as described in Section 3.
> 
> In this case, I'd keep the trailing "only" as is.
> 
> >> This text is not in RFC 4408.  I found a note in Issue #1 [5] and in a
> >> message [6].
> > 
> > Are there any implementations that do this?  If so, that's the
> > justification; it's practical experience.  If not, we should consider
> > dropping it.
> 
> +1 for dropping it.  This would be needed for type 99, where bad
> firewall rules could produce effects similar to network errors except
> that they'd never get resolved.  For "normal" SERVFAIL cases, the
> meaning of temperror as derived from RFC 2308 is just fine.
> 
> >> In Section 4.6.2:
> > How about: "After all mechanisms have been processed and no matches are
> > found, the result is determined according to Section 4.7."
> 
> +1, better style.
> 
> >> 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.
> > 
> > I'm not sure I agree.  SecDir has pushed the fixed query limit on other
> > topics in the past, which is the first MUST, and the second MUST
> > prescribes
> > a specific result that has to occur when the limit is reached which is
> > important for interoperability.
> 
> +1, while it is possible to say "MUST return permerror if more than
> 10", the resulting text would be less readable.
> 
> >> There are three RFC 2119 SHOULDs in the above.  I suggest rewriting the
> >> text to reduce that.
> > 
> > All three of them seem to be important interoperability points.  We could
> > common factor the SHOULD and then present three bullets in a list, but the
> > meaning is the same.
> 
> +1, for the same readability reason.
> 
> > Last paragraph of Section 4.6.
> > 
> > Interoperability; if one is two while another is 10, different SPF results
> > can be returned.
> 
> This is a protocol change, marked as such in Appendix C, 2nd bullet.
> 
> > Since the explanation I've been given is that it's better for human
> > debugging, I think I agree since the advice is not specific to the
> > protocol
> > itself.
> 
> Scott removed the "Note that".
> 
> >> In Section 4.8:
> > Again, synonymous.
> +1 for SM, again.
> > This was covered in a different thread.  I believe a proposed text fix was
> > made that people seemed to like.
> > 
> >> In Section 5.3:
> >> "dual-cidr-length" is introduced in this sub-section.  I had to search
> >> through the draft to find out what it means.
> > 
> > That happens sometimes.  :-)
> > 
> >> In Section 5.4:
> >> 2119
> +1, s/A/A or AAAA/
> > The very next sentence is "See below for discussion."
> > 
> > Agreed.
> +1, since we collected those limits.  I propose to replace the second
> sentence in that bullet with something like:
> 
>    This is where to apply the rule of Section 4.6.4 to ignore records
>    other than the first 10.
> 
> >> 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.
> > 
> > It was "must" vs. MUST in RFC4408.  It's otherwise unchanged.
> > 
> > One that complies with this specification.
> > 
> >> In Section 5.6:
> > Looks right to me.  The CIDR expression is in the optional token next to
> > it, so this has to be just a plain IPv6 address, so that's the right
> > reference.
> 
> I'd rather import IPv6address and IPv4address from
> http://tools.ietf.org/html/rfc3986#section-3.2.2
> 
> >> In Section 5.7:
> >>   'v=spf1 exists:%{ir}.%{l1r+-}._spf.%{**d} -all'
> >> 
> > What's the specific question being asked of DNSDIR here?
> > 
> >> In Section 6:
> > I agree that this could be expressed non-normatively (e.g. "needs to be").
> 
> -1, it means the value of "exp" must be ASCII.
> 
> >> 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 agree; we're talking about interoperability between humans here, and not
> > between implementations.
> 
> +1, something like "implementers are advised to make it clear..."
> 
> >> In Section 7.1:
> >> Where can I find these restrictions?  Please note that I have read the
> >> Informational RFC.
> > 
> > I'm pretty sure it's referring to common TLD conventions.
> 
> The "LDH rule" is explained in the Informational RFC.  It is the
> Letter-Digit-Hyphen convention defined in RFC 952 and later modified
> by RFC 1123 [http://www.icann.org/en/node/1145376]
> 
> >> in Section 10:
> > Agreed, it's inappropriate here.
> 
> I think Scott removed it already.
> 
> >> In Section 10.1.2:
> >> t=6097A7EA-53F7-4028-BA76-**6869CB284C54"
> >> 
> >> ;; QUESTION SECTION:
> >> ;com.com.                       IN      TXT
> >> 
> >> ;; ANSWER SECTION:
> >> com.com.                293     IN      TXT "google-site-verification:**
> >> esSnoZdChIkkfCfS9MMgqNhE0yaXfn**nZWdZPuBf7e8k"
> > 
> > What are you saying here?  This is an existence proof of non-mailing
> > domains that don't publish SPF records, but it doesn't contradict the
> > statement made in the draft.
> 
> It doesn't mean there's a BCP.  s/best/good/?
> 
> >> In Section 13.1:
> >> The format is not identical, i.e. it's a different RR.  I suggest keeping
> >> the IANA Considerations Section simple, i.e. clearly explain to IANA what
> >> action is requested.
> > 
> > The format is indeed identical, right down to the octet.
> 
> The format of RDATA, that is.  I'd leave the definition of the
> obsolete type with the obsolete RFC 4408.
> 
> >> In Section E.1:
> >> I didn't find any discussion about this on the SPFBIS mailing list.  is
> >> there an explanation for this change between RFC 4408 and this draft?
> > 
> > It was in 9.3 in the previous document and has been reworded a little.
> > It's otherwise unchanged.
> 
> See http://www.ietf.org/mail-archive/web/spfbis/current/msg02276.html
> 
> >> In Appendix I:
> >> 
> >> Proposed Standard. From an IETF perspective that is what it will be.
> >> 
> >>  Describing it as something different can be misleading.
> >>  
> > There are two typos in there (techincal, deplyment).
> > 
> >> Extensions to the SPF protocol are clearly mentioned in the charter as
> >> being out of scope.  The "document widely deployed extensions" is
> >> problematic.
> > 
> > Agreed.
> 
> Yes, in some sense.  I'd s/extensions/changes/.

I've been through this, and I think that either through sm referring to some 
of your comments or other discussions, we've been through these issues 
already.  If I missed something, please let me know.

Scott K

---

From: "Murray S. Kucherawy" <[email-masked]>
Date: Fri, 17 May 2013 01:35:21 -0700

> function are not considered requirements, but changed.

Andrew's message drew the distinction between saying "necessary" and
"MUST".  There must be a nuance in there that I'm missing, because they're
essentially synonymous to me; in fact, "-all" is the only way to achieve
the stated goal for either party to the communication, so "MUST" seems
proper to me, though either solution is also fine.  Andrew, would you care
to elaborate?

> 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.

> <domain>
> unclear.

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.

> 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.

> 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.

> 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.

> that the DNS query is for Type TXT only."  That's correct, so I think you

Given the choice to drop type 99 entirely, the word "only" can probably
go.  Other than that I don't see what part of the quoted sentence is
ambiguous.  How else might it be interpreted?

> 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?

> think it's clearer, so I'd prefer to use it if you think it's OK.

I think they're synonymous.

> 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 don't find that any clearer, probably less so than what's in the draft

It's a common-factoring of the noun and SHOULD with otherwise identical
meaning.  Seems a stylistic choice to me more than anything else.

> 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.

> That is defective use of 2119 language?  I disagree that that would be

"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.

> 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.

> We're talking about avoiding security issues caused by the humans getting

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.

> interoperability issue.  Having consistency helps interoperability.  I'd

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.

> 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.

> > I'll leave this issue open as it was mentioned in the AppsDir review.

I'll help with this if needed.

> 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.

> 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.

> 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.

> 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.

> appropriate to leave it as it shows part of the trace back to the origin of

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.  I misunderstood your comment.  I think you're wrong about the lack of

I concur; there have been several reviews, including by AppsDir.  A
non-trivial amount of the bulk is the reorganization, which added a lot of
blank space around a lot of new section headings.

I can't identify any gigantic but gratuitous changes.

> > > >     deployed extensions to SPF that have been developed since

My browser identifies two typos in there ("techincal", "deplyment").

> It was also not widely deployed.  Should I take authentication-results out

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.

-MSK

---

From: Scott Kitterman <[email-masked]>
Date: Fri, 17 May 2013 09:58:55 -0400

> On Thu, May 16, 2013 at 11:37 PM, Scott Kitterman <[email-masked]>wrote:

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

> > > >What I have now is "Documents that define other identities will have
> > > >to define the method for explicit approval."
> > > 

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).

> > > > >     in the case of invalid "MAIL FROM".  Rejecting email will
> > > > >     prevent
> > > > >     one
> > I don't understand what you think is wrong.  Repeating the comment won't
> > help.  I did read it.  I don't understand it.
> 

Here's that last paragraph of 2.4:

>    Implementations have to take care to correctly extract the <domain>
>    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.'
> > > > > 

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

> that's just repeated from RFC4408, so we shouldn't burn too many cycles

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.

> 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).

> 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.

> > > > >     modifiers ("terms") that cause any DNS query to at most 10
> > > > >     during
> > > > >     SPF
> > > > >     evaluation."
> > > > > 

I'm OK with dropping at most.  Any objections?
> 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.

> > > >interoperation).  For the SHOULD, it's an optimization.  We can change
> > > it f you want.
> > > 

OK.  Changed.

> "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).

> have to make it SMTP-compliant somehow before it's returned in the SMTP

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.

OK.

> "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).

> Dumping the RFC2119 language in there is a bad idea.  It's all

Thanks. Changed.

> I'll help with this if needed.

Thanks.

> table match the prose, I think it's fine to leave it in.

I checked.  It does.

> > http://www.bits.org/publications/security/BITSEmailAuthenticationFeb2013.p
> > d
> > 
> > > >f
> > > 

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)?

> authority of the receiver, and thus are not guaranteed to be accurate or

Added.  Thanks.

OK.

> My browser identifies two typos in there ("techincal", "deplyment").

Fixed.  Thanks.

> thing we usually include in shepherd writeups and not in the RFCs

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

Scott K

---

From: "Murray S. Kucherawy" <[email-masked]>
Date: Fri, 17 May 2013 11:18:31 -0700

> statement from the sender that their SPF record is suitable for the

What's an example of unacceptable use?  I'm possibly not understanding
exactly what "SPF context" means.

> I suppose, but I don't see what it adds to do so.

That's not the part of 2.4 I mean.  2.4 contains:

  <domain> - the domain portion of the "MAIL FROM" or "HELO" identity.

Meanwhile 4.1 contains:

   <domain> - the domain that provides the sought-after authorization
              information; initially, the domain portion of the "MAIL
              FROM" or "HELO" identity.

They're not exactly the same.  It's cleaner to define <domain> in one
place, completely, and then replace the other one with a reference to that
definition.

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

Sure:

Generating non-delivery notifications to forged identities that have failed
the authorization check often constitutes backscatter, i.e., inactionable,
nuisance rejection notices.  Operators are [strongly] advised to avoid such
practices.

> text in 2.4 is definitional, I'll try and consolidate it into 2.4 (and

I think I provided that above.  Hope that clarifies things.

> be part of the output of the WG if someone else implemented it.

I'm not making that demand, but I do think it bolsters our position if it's
seen real world action.  I don't have any objection to including it.  We
just need to be prepared to push on it if the WG agrees that it's what we
want to say and it's met with resistance.

> interoperability if they don't consider it).

Yeah.  Ultimately I don't feel strongly about it.  I'm fine with it as it
is, but it might be another instance of "shouting".

> hostname -f and not hostname).

My point is that there are some hosts for which "hostname -f" and
"hostname" produce the same single-label output.  Lots of Windows hosts are
called "localhost", for example, and have no idea what their domain name is
(and don't need to).

> > > > >Because of the structure of the document that the WG came up with.
>  I
> > > don't

If you email me the current XML (when you're ready to take a break from it)
I'll take a run at that.

> have caught correct uses of it (or do I misremember how you got your domain

I'm missing something.  I thought the point was to find instances where
there's been a declaration via SPF that "this domain sends no mail".  Isn't
"v=spf1 -all" the way to do that?

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

Appendix I. Protocol Status.

-MSK

---

From: Scott Kitterman <[email-masked]>
Date: Fri, 17 May 2013 14:41:43 -0400

On Friday, May 17, 2013 11:18:31 AM Murray S. Kucherawy wrote:
> > > 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 classic one is Sender ID.  As I mentioned, I think DMARC very carefully 
drove right up to the line and stayed on the right side of it.  If instead of 
evaluating SPF against mail from and then taking that as an input to (as part 
of DMARC) consider that an 'authenticated' identifier to be evaluated for 
identifier alignment, DMARC had just done an SPF like test using 5322.From, I 
think that would have been wrong.  I've seen people try to match SPF results 
against domains extracted from Received header fields.  

There have been other ideas over the years.  I don't remember them all.

> place, completely, and then replace the other one with a reference to that

OK, sorry for being dense.  Now I get it.  I actually did this already and 
lost track.  It's just in 4.1 now.

> > > > > > >    'Generating non-delivery notifications to forged identities
> > 
> > that
> > 
> > > > > > > text may have been introduced in response to a review [3].  Is
> > 
> > this
> > 

Thank you.  Here's what I have now:

          Generating non-delivery notifications to forged identities that have 
          failed the authorization check often constitutes backscatter, i.e., 
          inactionable, nuisance rejection notices.  Operators are strongly 
          advised to avoid such practices. Section 2 of <xref
          target="RFC3834"/> describes backscatter and the problems it causes.

> > > > > > > In Section 4.1:
> > > > > > >    '<domain> - the domain that provides the sought-after
> > > > 
> > > > authorization
> > > > 
> > > > > > >                information; initially, the domain portion of the
> > > > 
> > > > "MAIL
> > > > 
> > > > They are talking about different things relative to domains, so given
> > 
> > the
> > 
> > > 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
> > 

Yes.  Sorted now.

> want to say and it's met with resistance.

I think it's far better than leaving eventually permanent temperrors in the 
sending mail queue for the queue life.  If someone has a better way to deal 
with it, then please suggest it.  I don't particularly like the solution, I 
just think it's better than anything else we've got.

> > > > > > > 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.'
> > > > > > > 
OK.  I'll see if others share your concern.

> > > > > > >    "This SHOULD be a fully qualified domain name, but if one
> > > > > > >    does
> > > > > > >    not
> > > > > > >    
> > > > > > > The RFC 2119 key words are in RFC 2119.  I don't know what to
> > 
> > say.
> > 
> > > > > >OK.
> > > > > 
> > > > 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
> > 

Right.  Those are the ones you call "unknown".

> > > > > > > In Section 8.2:
> > > > > > >    'A "neutral" result MUST be treated exactly like the "none"
> > > > 
> > > > result;
> > > > 

Will do.

> "v=spf1 -all" the way to do that?

Yes, but if you're selecting from domains that have sent mail, there's a 
sampling bias.

> Appendix I. Protocol Status.

OK.  I'd figured that would stay in because I think it's useful to see how we 
got where we are.  If others agree it's better to come out, I don't object 
strongly.

Scott K

---

From: "Murray S. Kucherawy" <[email-masked]>
Date: Fri, 17 May 2013 11:52:13 -0700

> There have been other ideas over the years.  I don't remember them all.

Right, so "Don't use SPF to evaluate things other than MAIL FROM and HELO
unless both the sender and receiver have agreed out-of-band that doing so
is appropriate for that mail stream."  That's the intended sentiment?

>           target="RFC3834"/> describes backscatter and the problems it

Nice.

> > > to a long standing issue.  It seems a bit odd to then demand that it
> can
> > > only

+1.  It has to have consensus though, so what do others think?

> Right.  Those are the ones you call "unknown".

I get that part, but that has nothing to do with the first SHOULD, only the
second.

> Yes, but if you're selecting from domains that have sent mail, there's a

They're domains present in mail my reporting sites received.  Some of them
were obviously forgeries because they violated the published SPF rule.

-MSK

---

From: Scott Kitterman <[email-masked]>
Date: Fri, 17 May 2013 15:59:39 -0400

> is appropriate for that mail stream."  That's the intended sentiment?

Except for the out of band part.  It could be a new in-band modifier that gets 
defined in the future.

> >           Generating non-delivery notifications to forged identities that
> > 
> > have
> > 
> >           failed the authorization check often constitutes backscatter,
> > 
> > i.e.,
> > 
> >           target="RFC3834"/> describes backscatter and the problems it
> > 
> > causes.
> 
> Nice.
> 
> > > From my point of view, we have a new proposed solution that the WG
> > > 
> > > > developed
> > > I'm not making that demand, but I do think it bolsters our position if
> > 
> > it's
> > 

It seemed like people were OK with it when I put it in.

> I get that part, but that has nothing to do with the first SHOULD, only the

OK.  I see your point now.  SHOULD could be replaced with 'is normally'.  If 
you agree, please go ahead and change it.

OK.

Thanks,

Scott K

---

From: S Moonesamy <[email-masked]>
Date: Fri, 17 May 2013 11:52:07 -0700

HI Scott,

Thanks.

>of context, so I think it's best to wait for the next revision.

I understand that it is not always easy to do.  When revising a draft 
it is better that the editors keep a list showing how each comment 
was addressed and what the revised text is so that an Area Director 
raising an issue can see how the issue was addressed.  That list can 
be forwarded to the reviewer (e.g. directorate, Area Director, anyone 
doing a detailed review).  When it is done on the working group 
mailing list there is a record of the issues being addressed as they 
do not have to be revisited.

There was a comment about issues in a draft (see 
http://www.ietf.org/mail-archive/web/ietf/current/msg79096.html 
).  The external view is:

   "I have not followed this discussion, but my cursory read of the tracker
    ticket shows the WG blew off the issue by claiming that historical
    unsophisticated attacks can be easily thwarted, while completely ignoring
    the case where the target domains exist."

Irrespective of whether that is correct or not it may end up as more 
work for you and for the working group.

>no need for out-of-band/private methods to accomplish this goal.

The issue was how can explicit approval be sought.  Murray suggested 
'Adding "out-of-band" or "private" after "explicit" would probably 
clear this one up'.  I didn't see any comments from John or 
Stuart.  Alessandro commented as follows:  'How about defining the 
concept of (private or standard) "extension"?'.  Extensions are 
out-of-scope for SPFBIS.

I'll suggest the following for the second paragraph of Section 2.4:

   Checking other identities against SPF version 1 records is NOT
   RECOMMENDED because there are cases that are known to give
   incorrect results.  For example, almost all mailing lists
   rewrite the "MAIL FROM" identity (see Section 10.3), but some
   do not change any other identities in the message.  A document
   that defines other identity will have to specify how the identity
   is used.

I tried to capture what is mentioned in your explanation.  It's 
basically "no need for out-of-band/private methods".

>if you still think it's a problem.

I went through the mailing list archive and I only found two comments 
about this issue.   I'll suggest the following text for the fourth 
paragraph of Section 2.4:

   A SPF verifier performs an SPF check using the check_host() function
   (Section 4).  The SPF check it has to be  performed as specified so
   that the correct semantics are preserved between publisher and receiver.

I would rewrite the next sentence as:

   To make the SPF check, the SPF verifier MUST evaluate the check_host()
   function with the arguments set as follows:

That sentence could be moved to the previous paragraph.  You then get 
the arguments (for the function) together with the check_host() function.

>I did read it.  I don't understand it.

The following is from Section 2.4:

   '<domain> - the domain portion of the "MAIL FROM" or "HELO" identity.'

and this is from Section 4.1:

I suggest choosing one of the above text for "<domain>" and using it 
in both sections.

>So you think it's not something that should be avoided?

It's not that I don't think that the problem should not be 
avoided.  I read the SPFBIS charter and I didn't find any text about 
addressing every mail-related problem.  That is why I suggested 
removing the last paragraph of Section 2.5:

   "Generating non-delivery notifications to forged identities that have
    failed the authorization check is a source of backscatter and SHOULD
    be avoided.  Section 2 of [RFC3834] describes backscatter and the
    problems it causes."

>The SPF record is expressed as a single string of text encoded in a  DNS TXT

Ok (subject to Andrew's comments).

>reader, so I think I don't understand what you think needs changing.

Fro context this is about the first paragraph of Section 3:

   'ADMDs publishing SPF records SHOULD try to keep the number of
    "include" mechanisms and chained "redirect" modifiers to a minimum.
    ADMDs SHOULD also try to minimize the amount of other DNS information
    needed to evaluate a record.  Section 4.6.4 and Section 10.1.1
    provide some suggestions on how to achieve this.'

I'll give the rewrite a try:

   ADMDs publishing SPF records ought to keep the amount of DNS
   information needed to evaluate a record to a minimum.
   Section 4.6.4 provides some suggestions about "include"
   mechanisms and chained "redirect" modifiers.

>maybe include mechanisms.  I don't think there's a conflict.

I tried to address this above (see suggested text).

>records is described in ..."

The issue was that the reference was incorrect.  Here is the text 
from Section 3:

   'The SPF record is a single string of text.  The record format is
    described below in Section 4.'

The title of Section 4 is "The check_host() Function".

Thanks.

>OK.  I changed it to produce results.

Ok (subject to reading the sentence)

>organization, I don't see an easy way to do that.  I'm open to suggestions.

I commented on the <domain> in Section 4.1.  I'll repeat what I 
mentioned for Section 2.4:

The following is from Section 2.4:

   '<domain> - the domain portion of the "MAIL FROM" or "HELO" identity.'

and this is from Section 4.1:

I suggest choosing one of the above text for "<domain>" and using it 
in both sections.

>OK.  I took email out.

Ok (subject to reading the sentence).

>that the DNS query is for Type TXT only."  That's correct, so I think you do

I'll defer to Andrew on this.

>want to redo the entire process of solving the issue again.

I asked whether there were any implementations that do the following:

Stuart Gathman is listed as the author of pySPF.   He 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)"'.

As an individual I prefer not to do the entire process again.  Given 
that this is tied to another controversial discussion I have to list 
the issue as unresolved.

>think it's clearer, so I'd prefer to use it if you think it's OK.

I am ok if you prefer to use the text you proposed.

>combining them would reduce clarity for implementers.

I suggest that the working group reviews that text.  In my opinion 
the "at most" can interpreted as setting a number less than 10 and 
that can cause an interoperability issue.

>improve it, please provide it.

I'll list Section 4.6.4 as an unresolved issue.

Ok.

>implications of not implementing proper limits.

I'll discuss Section 4.6.4 in a separate message

Ok.

>what's there now would be out of scope for our charter.

Here is the text from the last paragraph of Section 5.4 of RFC 4408:

   'Note regarding implicit MXs: If the <target-name> has no MX records,
    check_host() MUST NOT pretend the target is its single MX, and MUST
    NOT default to an A lookup on the <target-name> directly.  This
    behavior breaks with the legacy "implicit MX" rule.  See [RFC2821],
    Section 5.  If such behavior is desired, the publisher should specify
    an "a" directive.'

And the text from the draft:

   'Note regarding implicit MXs: If the <target-name> has no MX records,
    check_host() MUST NOT pretend the target is its single MX, and MUST
    NOT default to an A or AAAA lookup on the <target-name> directly.
    This behavior diverges from the legacy "implicit MX" rule, (See
    [RFC5321], Section 5.  If such behavior is desired, the publisher
    will have to specify an "a" directive).'

I compared two sentences:

  1. This behavior breaks with the legacy "implicit MX" rule.

  2. This behavior diverges from the legacy "implicit MX" rule

I consider this as a change.  I would like to discuss the matter with 
the Responsible Area Director.

> >    mechanisms in cases of DNS errors, and it places a large burden on

I mentioned the suggested text previously.  In the first paragraph of 
Section 5.5:

Existing text:

   This mechanism SHOULD NOT be used.  See below for discussion.

Suggested text:

    This mechanism SHOULD NOT be used it is not as reliable as other
    mechanisms in cases of DNS errors, and it places a large burden on the
   .arpa name servers.

>Obvious to you.  Not obvious to everyone.

I suggest reverting the change.

>That is defective use of 2119 language?  I disagree that that would be

I'll list this as an unresolved issue.

>which is a good clarification I'd think.

The Responsible Area Director has commented about RFC 2119 
language.  I suggest referring to his message for any question about 
RFC 2119 language.  I also suggest removing the RFC 2119 language.

>We're talking about avoiding security issues caused by the humans getting

I'll list this as an unresolved issue.

>interoperability issue.  Having consistency helps interoperability.  I'd

I'll list this as an unresolved issue (the text is: 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.)
).

>Why?  How about if we call it "Details" instead of Notes?

There was a suggestion (from you if I recall correctly in another 
message).  I suggest using that if the working group agrees.

>that was in 4408.  It does not create any new requirements.

I don't see agreement for that table.

>What's wrong with the way it is?  I think the current text is accurate.

I don't see anything in the charter about working on a best practice 
document.  I suggest choosing "good practice" if the working group 
really wants that text.

>email authentication related documents and I don't want to create potential

ok.

>I think the section explains exactly that, so some text would help.

I'll list issue as unresolved.

>list of contributors, we'll need to discuss a new schedule because this won't

I'll wait for input from Andrew and the Responsible Area Director.

Thanks.

>appropriate to leave it as it shows part of the trace back to the origin of

I suggest adding text about that if it is important.  I suggest 
removing the reference as nobody has been able to provide the 
document being referenced.

> > I suggest dropping this change as it was not discussed within the

As I didn't find that discussion I can only conclude that it has not 
been discussed within the working group.  I suggest dropping the change.

>It was also not widely deployed.  Should I take authentication-results out of

I did not mention "authentication-results" in my comment.  My comment 
was about Appendix I.  In my opinion "extension" is out-of-scope.

>I think the section is incomplete without it.

The reference mentions "Resolution of the Sender Policy Framework 
(SPF) and Sender ID Experiments".  I suggest removing the text.

Regards,

---

From: "John Levine" <[email-masked]>
Date: 17 May 2013 20:47:57 -0000

>Except for the out of band part.  It could be a new in-band modifier that gets 

Anything defined in the future would update the spec, so we don't have
to worry about it.  If (as I understand it) the only current way to agree
to use SPF on other stuff is out of band, just say so.

>> > with it, then please suggest it.  I don't particularly like the solution,
>>> > I just think it's better than anything else we've got.
>> 

Oops, I missed this.  My position is that the queue lifetime is the
length it is for a reason, and it's a mistake to shortcircuit that.

Stuff will stay in the outbound queue for the full lifetime if there
are DNS temperror problems with the MX lookup, or the A records the MX
points to.  Why should SPF temperrors be different?

R's,
John

---

From: Scott Kitterman <[email-masked]>
Date: Fri, 17 May 2013 16:51:25 -0400

On Friday, May 17, 2013 11:52:07 AM S Moonesamy wrote:
> >That's not always easy to do.  In this case, it would be hard to evaluate
> >out of context, so I think it's best to wait for the next revision.
> 
>     unsophisticated attacks can be easily thwarted, while completely
> ignoring the case where the target domains exist."
> 
> >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.

Based on the follow-up with msk, the draft now reads:

   Without explicit approval of the publishing ADMD, checking other
   identities against SPF version 1 records is NOT RECOMMENDED because
   there are cases that are known to give incorrect results.  For
   example, almost all mailing lists rewrite the "MAIL FROM" identity
   (see Section 10.3), but some do not change any other identities in
   the message.  Documents that define other identities will have to
   define the method for explicit approval.

This is very close to what you suggest.  Do you think this is OK?

> >It means it was changed based on other comments.  Please look at -15 and
> >see if you still think it's a problem.
> 

That currently point to 4.1 to remove the duplication that was complained 
about in other comments.  I don't think we should put it back.

   To make the test, the mail receiver MUST evaluate the check_host()
   function with the arguments described in Section 4.1.

> I suggest choosing one of the above text for "<domain>" and using it

I got this clarified in the dialog with msk and it's all in 4.1 now.

>     be avoided.  Section 2 of [RFC3834] describes backscatter and the

This is very close to what msk and I worked out.  Please see the text I posted 
in the subthread with him and see if it works for you.

> >The SPF record is expressed as a single string of text encoded in a  DNS
> >TXT record.
> 

OK.  How about this:

          ADMDs publishing SPF records ought to keep the amount of DNS
          information needed to evaluate a record to a minimum.  <xref
          target="eval-limits"/> and <xref target="sending-resources"/> 
          provide some suggestions about "include" mechanisms and chained 
          "redirect" modifiers.

> >wanted the absolute minimum physically possible, we'd only have ip4, ip4,
> >and maybe include mechanisms.  I don't think there's a conflict.
> 
> > > > >    'SPF records MUST be published as a DNS TXT (type 16)
> > 
> > Resource Record
> > 
> > > > >     (RR) [RFC1035] only.'
> > > > > 
> >Changing the title to Record Format would be wrong because it's not just
> >the format.  I changed it to "The record format and the process for
> >selecting records is described in ..."
> 

It's not incorrect.  That is, in fact, where it's described.

> I suggest choosing one of the above text for "<domain>" and using it

This is fixed.

> >that the DNS query is for Type TXT only."  That's correct, so I think you
> >do understand the sentence.
> 
> >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.
> 

How so?  It's only unresolved because you decided to second guess what we 
already agreed on.  I don't think WGLC is a free shot at revisiting all the 
work we've done.  There's a real problem.  This is the best solution anyone 
came up with and so absent some alternative approach, there's nothing to 
resolve.

> I am ok if you prefer to use the text you proposed.

OK.  Done.

> that can cause an interoperability issue.

I agree that at most should be removed.  Done.

> > > >We worked on making it clearer.  If you have suggested
> > 
> > improvements, please
> > 
> > > >send them.
> > > 
> >worked over trying to clarify this section.  I think we've done our best, 
> >to clearly express something that is complicated.  I don't think "do it
> >better" is going to result in further improvements, so if you have an idea
> >how to improve it, please provide it.
> 

Please specify what's unresolved.

> >They are about defining some consistent limits/expectations in order to
> >avoid both impedance between senders and receivers and the potential
> >security implications of not implementing proper limits.
> 

OK.

> > > > >    'Note regarding implicit MXs: If the <target-name> has no
> > 
> > MX records,
> > 
> > > >It's not contrary.  It's saying that aspect of 5321 is not
> > 
> > relevant to SPF.
> > 

It's a change from what?  SPF has worked this way since 2003.  It doesn't 
"break" anything.  It was a deliberate design decision.

>     mechanisms in cases of DNS errors, and it places a large burden on the

It already says that.

> I suggest reverting the change.

Why?  It's not a rare error for people not to understand this.  Most people 
for small domains that try to deal with SPF are not DNS experts.

> I'll list this as an unresolved issue.

What's unresolved?  You've yet to explain what's defective.  I don't think 
it's particularly effective to list issues you've not explained as unresolved.  
By definition that's true, but it's also rather unresolvable.

> >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 read it.  I think it needs to stay.

> >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.
> 

msk is taking a stab at text for this, I think.

> I don't see agreement for that table.

I can take it out.  So far one person objected.  If the standard is nothing 
that anyone objects to goes in, we'll be here for a long time.

> document.  I suggest choosing "good practice" if the working group

I am at a loss for words.  Best practice is correct.

> >I went with disposable, since discardable is a specific term of art in
> >other email authentication related documents and I don't want to create
> >potential for confusion.
> 
> ok.
> 
> > > > > 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 made a change today based on a suggestion from msk.  I think it's resolved.

> >I think to single out one person in this way would be unfair to other
> >people that made significant contributions.  The original 4408
> >acknowledgements weren't done this way and so I think it's literally
> >impossible to properly develop an acknowledgements section that would be
> >fairly done.  This is not to
> >groups vary significantly.  What's in the draft for acknowledgements has
> >been there, virtually unchanged since last summer.  If you really want a
> >reasonable
> >list of contributors, we'll need to discuss a new schedule because this
> >won't finish in May.
> 
> > > > > list.  is there an explanation for this change between RFC
> > 
> > 4408 and this
> > 
> > > > > draft?
> > > >

As msk pointed out, it was mostly affected by the reorganization.

> >It was also not widely deployed.  Should I take authentication-results out
> >of the draft then?
> 

If extensions are out of scope, then we need to remove the discussion about a-
r.  I understand you didn't mention it, but if I follow your suggestion, 
that's a logical conclusion.

> > > > >    "This document updates and replaces RFC 4408 that was part
> > 
> > of a group
> > 
> > > > >     RFC 4407, and RFC 4408) in 2006.  At that time the IESG
> > > > >     requested
> > > > >     the
> > > > >     documented in these RFCs during the two years following
> > 
> > publication,
> > 
> > > > >     in order that a community consensus could be reached in
> > 
> > the future."
> > 

I think it should stay as is, but I guess I'm the only one.

Scott K

P.S. I sent the XML file to msk for some edits.  Once I get it back, I'll merge 
the changes I mentioned here with that.

---

From: Scott Kitterman <[email-masked]>
Date: Fri, 17 May 2013 16:54:48 -0400

On Friday, May 17, 2013 08:47:57 PM John Levine wrote:
> >Except for the out of band part.  It could be a new in-band modifier that
> >gets defined in the future.
> 

The spec already accommodates handling unknown modifiers, so it doesn't need to 
updated.  There's a registry.

> points to.  Why should SPF temperrors be different?

Because they aren't temporary.

---

From: "John Levine" <[email-masked]>
Date: 17 May 2013 22:58:05 -0000

>updated.  There's a registry.

But the registry is specification required.  If there's a new spec, it
will specify what to do with the new modifier.  I don't think this is
worth a huge argument, but I don't see the point in documenting things
that don't exist when we know that they will be documented somewhere
else if and when they do.

>Because they aren't temporary.

Huh?  I went through -14 and all the temperrors are either DNS
failures or timeouts.  How is that different from failures or timeouts
looking up an MX?  I realize it happens on the server rather than the
client, but so what?

R's,
John

---

From: Scott Kitterman <[email-masked]>
Date: Fri, 17 May 2013 19:05:49 -0400

On Friday, May 17, 2013 10:58:05 PM John Levine wrote:
> >The spec already accommodates handling unknown modifiers, so it doesn't
> >need to updated.  There's a registry.
> 

True, but I think the statement that such understanding requires an out of 
band/private agreement is not correct.

> looking up an MX?  I realize it happens on the server rather than the

SERVFAIL is supposed to be something temporary, but in my experience it often 
is not.  That was the root of the original discussion.  I wanted to call 
SERVFAIL a permanent error, but got shown that was not correct.  SERVFAIL is 
often a "permanent" "temporary" error.

Scott K

---

From: S Moonesamy <[email-masked]>
Date: Fri, 17 May 2013 16:24:15 -0700

Hi Scott,
>This is very close to what you suggest.  Do you think this is OK?

The issue was the "explicit approval".  I'll leave it to the working 
group to see whether it is ok with the text.

>    function with the arguments described in Section 4.1.

If the working group is ok with this I am ok with it.

>in the subthread with him and see if it works for you.

I'll leave it to the working group to review and see whether it works 
for WG participants.

>           provide some suggestions about "include" mechanisms and chained

That's ok if the working group is ok with it.

>It's not incorrect.  That is, in fact, where it's described.

I'll leave it to the working group.

>came up with and so absent some alternative approach, there's nothing to

I went through the mailing list archives.  The issue that was raised 
was "multiple DNS errors over a 24 hour period now can be called a 
permerror".  I saw a discussion of "SERVFAIL" in the mailing list 
archives.  If the working group does not raise this as an issue it's 
not an issue for me.

>Please specify what's unresolved.

I'll take this in a separate message.

>"break" anything.  It was a deliberate design decision.

I'll say ok if the working group does not raise this as an issue.

Ok.

>for small domains that try to deal with SPF are not DNS experts.

That's not what I see as agreement based on I read from the mailing 
list archives.

> > I'll list this as an unresolved issue.

I didn't see agreement for this after reading the mailing list archives.

Ok.

>that anyone objects to goes in, we'll be here for a long time.

I suggest taking it out.   My reading of the mailing list archives is 
that there wasn't agreement.

>I am at a loss for words.  Best practice is correct.

I mentioned that it is outside the scope of the charter.

Ok.

> > > > > > In Appendix C:
> > > > > >
> > > > > > In Section E.1:
> > > > > >    'This would cause a lookup on an DNS white list 
> (DNSWL) and cause
> > > > > >    a
> > > > > >

I didn't see agreement for this change.

>that's a logical conclusion.

Please see my previous comment about what is out of scope.

Ok.

As a note to the working group, the "Updates" I mentioned previously 
is not needed.  I am also ok with the IDN text as it was reviewed by 
the working group.

Regards,
S. Moonesamy

---

From: Scott Kitterman <[email-masked]>
Date: Fri, 17 May 2013 19:41:39 -0400

> archives.  If the working group does not raise this as an issue it's

Sigh.  I'll remove it as you aren't the only one who doesn't like this now.  

> That's not what I see as agreement based on I read from the mailing

I don't recall anyone saying that was incorrect.

> > > > > > > I could not understand what that means in RFC 2119
> > 
> > terms.  The draft
> > 

I don't see a strong push for a change either and it's in 4408.

> that there wasn't agreement.

It's out.

> I mentioned that it is outside the scope of the charter.

The document is full of this kind of advice.  When we went through the 
reorganization discussion, we also we through want was in and what was out.  
If you want to revisit the scope of the document, it's probably an August 
deliverable at the earliest.

> >If extensions are out of scope, then we need to remove the discussion about
> >a- r.  I understand you didn't mention it, but if I follow your
> >suggestion, that's a logical conclusion.
> 

Yes.  I read it.  I think you are wrong, but if you are right, there's a lot 
of stuff that needs to come out and we'll need a new schedule.

Scott K

---

From: "John Levine" <[email-masked]>
Date: 17 May 2013 23:58:55 -0000

>band/private agreement is not correct.

We could have another round, but the language you and Murray came up
with looks fine to me.

>often a "permanent" "temporary" error.

Well, sure, and it can be equally permanent if you get it when doing
an MX or A/AAAA lookup on the client side, leading to repeated
requeues until the message times out (RFC 5321 sec 5.1.)  I still
don't see what merits different treatment.

---

From: S Moonesamy <[email-masked]>
Date: Fri, 17 May 2013 16:49:06 -0700

Hello,

I am listing some text from Section 4.6.4 of the draft only.  I'll 
borrow a few works from Andrew:

   'IMO, the purpose of a 2119 SHOULD is not "eat your broccoli; it's good
    for you."  A good rule of thumb is, if you have a SHOULD, you ought to
    be able to say why it's not MUST (i.e. under what conditions it would
    be ok not to do the thing you SHOULD do).  Since the IETF is about
    interoperability, this harm should be an interoperability issue.'

The text being discussed was:

Please comment if you are not ok with the above.

Regards,
S. Moonesamy

---

From: S Moonesamy <[email-masked]>
Date: Fri, 17 May 2013 17:20:23 -0700

Hi Scott,
>I don't recall anyone saying that was incorrect.

I could not find any discussion of the current text being proposed 
and discussed in the mailing list archives.

>I don't see a strong push for a change either and it's in 4408.

I don't see a strong push either.

>deliverable at the earliest.

I am looking at what text has been discussed on the mailing list and 
what gained agreement.

Regards,
S. Moonesamy

---

From: Scott Kitterman <[email-masked]>
Date: Fri, 17 May 2013 20:24:04 -0400

>don't see what merits different treatment.

It's pretty clear I'm in the rough on this, so I've removed it.

Scott K

---

From: Scott Kitterman <[email-masked]>
Date: Fri, 17 May 2013 20:26:13 -0400

>I am looking at what text has been discussed on the mailing list and 

If it's out of scope, why does that matter? 

Scott K

---

From: S Moonesamy <[email-masked]>
Date: Fri, 17 May 2013 17:43:37 -0700

Hi Scott,
>If it's out of scope, why does that matter?

My comment was:

   "I am looking at what text has been discussed on the mailing list and
    what gained agreement."

A working group participant can raise any objection if a text change 
was made and that text change is outside the scope of the SPFBIS 
charter .  I read the messages posted to the SPFBIS mailing list 
before or during the WGLC and I did not find any objection which has 
not been addressed by the SPFBIS WG Chairs.

Regards,
S. Moonesamy

---

From: Scott Kitterman <[email-masked]>
Date: Fri, 17 May 2013 21:22:16 -0400

>not been addressed by the SPFBIS WG Chairs.

FYI, I went back and looked.  It was added in rev 05.

 My point is that if this is out of scope, then a substantial fraction of the document is out of scope.   We've had many discussions about what is in and what is out.  Coming at this point in the process, I find a shift in your view about scope very troubling. 

If describing a established operational practices is out of scope, then it has to be generally out of scope and we have to re-write the document. You can't bend the charter in one direction to get rid of some of it and in the other to keep the rest.  The group my decide it's prudent not to put this in or to reword it, but you can't selectively adjust the scope of the charter.

I don't recommend this path.

Scott K

---

From: S Moonesamy <[email-masked]>
Date: Sat, 18 May 2013 01:46:46 -0700

Hello,

I read the SPFBIS mailing list archive again to see whether the 
question of scope was not addressed correctly.

There was a discussion about "what unused means".  John Levine, Scott 
Kitterman, Dave Crocker, Alessandro Vesely, and Hector Santos 
commented about that.  A message about the scope of the charter was 
posted to the SPFBIS mailing list by the WG Chairs after that.

Douglas Otis posted comments about "Leaving DNS look-up handling 
undefined or suggesting A-labels should be retained in the in the 
return path is not acceptable".  There were comments from John 
Levine, Scott Kitterman, Dave Crocker, Murray S. Kucherawy, 
Alessandro Vesely, Commerco WebMaster and John Leslie about that.

There was a comment from Scott Kitterman about "localpart macros are 
rare enough that no one need any sleep over them not supporting the 
full range of UTF-8, but they are in use so it's out of scope to 
ditch them".  Murray S. Kucherawy, Dave Crocker, John Leslie, 
Alessandro Vesely, Kurt Andersen and Scott Kitterman participated in 
the discussion about the issue.

There was a message from Douglas Otis about "support for retaining 
Received-SPF Header Field".  There was also a message from Murray S. 
Kucherawy about adding support for "Authentication-Results: 
header".  There was a message from Hector Santos about "remove A-R 
from 4408bis".  Scott Kitterman, Hector Santos, John Levine, Arthur 
Thisell and Wayne Doust participated in the discussion.

There was a message from Hector Santos about "Genesis of 30 days 
delays" as the text appeared in draft-ietf-spfbis-4408bis-10.  Scott 
Kitterman, Murray S. Kucherawy and John Levine participated in the 
discussion.  I mentioned that there was an short discussion between 
Scott Kitterman and Murray S. Kucherawy about the "30 days" period previously.

In my opinion these changes or non-changes were proposed on the 
SPFBIS mailing list and they were discussed on the SPFBIS mailing 
list.  What I have to show during the evaluation of the document is 
where the decision for a change or non-change was made and the 
discussions leading to the decision.  If there is an issue about 
scope, for example "extensions to SPF" I can point out that the 
matter was brought to the attention of the working group last year:

   "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."

and it was pointed out that extensions to SPF does not seem in line 
with what is in the SPFBIS charter.  If I am asked about Section 9 of 
the draft during the evaluation I can point to the messages 
discussing about scope and the decision about the change.

Regards,
S. Moonesamy

---

From: Andrew Sullivan <[email-masked]>
Date: Sat, 18 May 2013 05:25:29 -0400

> proper to me, though either solution is also fine.  Andrew, would you care

In RFC 2119 we have this: "MUST This word, or the terms "REQUIRED" or
"SHALL", mean that the definition is an absolute requirement of the
specification."  But the passage in question is not saying "you have
to do this".  It's saying instead that, because of the way the
protocol works, the only way to achieve some end is to use a
particular facility.  In other words, this is really informational
guidance on how to use the protocol, given the way it works.

The original reason I was making the distinction, please remember, was
that the draft at the time was making a change from RECOMMENDED to
MUST, but it was doing so conditionally, thereby using the RFC 2119
keywords more correctly (the 4408 use of RECOMMENDED in this case was
really more "we think this is a good idea").  In the context of the
new text, it seemed to me we didn't need a 2119 keyword at all,
because what was being described is a consequence of the way the
protocol operates, and not a requirement on conforming
implementations.

I don't feel super strongly about this.  I acknowledge SM's point,
however, that this change appears to be a substantive change in the
use of a 2119 keyword from 4408 to the new document, and there's a
potential question as to whether that is appropriate under our
charter.  I think this argument could go either way, which is why I
suggested the formulation without the keyword.  I'm not married to
this approach, however, and I think it will be possible to argue that
the change in this case is ok under our charter.  It's just a
potential snag when we go to IETF LC.  (Of course, compared to the war
we'll have over the TXT record, I suppose this'll be in the noise.)

I hope that clears things up.

A

-- 
Andrew Sullivan
[email-masked]

---

From: Andrew Sullivan <[email-masked]>
Date: Sat, 18 May 2013 05:55:11 -0400

> > I left this DNS angle for Andrew to comment.

I don't think it matters.  

> The SPF record is expressed as a single string of text encoded in a  DNS TXT 

Here, however, I think there might be a problem.

First, I think the sentence probably should say "The SPF record is
expressed as a single string of text encoded in the RDATA of a DNS TXT
record."  That's strictly speaking where you find it.

But on reflection, there remains the question of whether you're
allowed to split across TXT records.  This came up on another list,
and it's a good point.  If we have consensus that you _can't_, then we
should say so: "The SPF record is expressed as a single string of text
found in the RDATA of a single DNS TXT resource record."  Or something
like that.  If it _is_ possible to split the policy statement across
multiple TXT records, we need to explain how.  (I think it's
impossible to do reliably, FWIW.)

Best,

A

-- 
Andrew Sullivan
[email-masked]

---

From: Scott Kitterman <[email-masked]>
Date: Sat, 18 May 2013 10:55:36 -0400

Thanks.

The practice to date has been that it can be multiple strings in a single 
record.  I've to copy/pasted your second suggestion.  

Scott K

---

From: "Murray S. Kucherawy" <[email-masked]>
Date: Sat, 18 May 2013 10:22:07 -0700

> > impossible to do reliably, FWIW.)
The predecessor to Sender ID was Caller ID, and it stored the policy in XML
which most of the time didn't fit in a single TXT RR, so they came up with
a labeling scheme to indicate the order in which multiple TXT RRs were to
be reassembled.  It seemed to be reliable.  Totally unnecessary here though.

-MSK

---

From: S Moonesamy <[email-masked]>
Date: Sat, 18 May 2013 10:35:03 -0700

Hi Scott,

The Gen-ART review of draft-ietf-spfbis-4408bis-14 was posted on 
April 29 ( 
http://www.ietf.org/mail-archive/web/spfbis/current/msg03647.html 
).  There weren't any comments about that review.

The Applications Area directorate review was posted on April 29 ( 
http://www.ietf.org/mail-archive/web/spfbis/current/msg03633.html 
).  There was a comment from  Hector Santos ( 
http://www.ietf.org/mail-archive/web/spfbis/current/msg03653.html ).

The Security Directorate review of draft-ietf-spfbis-4408bis-14 was 
posted on April 30 ( 
http://www.ietf.org/mail-archive/web/spfbis/current/msg03679.html 
).  There was a comment from you ( 
http://www.ietf.org/mail-archive/web/spfbis/current/msg03723.html ) 
and from John Levine ( 
http://www.ietf.org/mail-archive/web/spfbis/current/msg03726.html ).

Can you provide an estimate date of when the reviews mentioned above 
will be addressed?

Regards,
S. Moonesamy

---

From: Scott Kitterman <[email-masked]>
Date: Sat, 18 May 2013 14:07:26 -0400

> I hope that clears things up.

Here's what I have now:

          SPF results can be used to make both positive (source is authorized)
          and negative (source is not authorized) determinations.  If ADMDs
          choose to publish SPF records and want to support receivers making
          negative authorization determinations, it is necessary for them to
          publish records that end in "-all", or redirect to other records
          that do, otherwise, no definitive determination of authorization can
          be made.  Potential issues and mitigations associated with negative
          determinations are discussed in <xref target="implications"/>.

I think that addresses the question.  It makes the point without and 2119 
mustard, so if everyone is happy with it, I'm OK with it too.

Scott K

---

From: Scott Kitterman <[email-masked]>
Date: Sat, 18 May 2013 14:18:56 -0400

> ).  There weren't any comments about that review.

I inadvertently marked that one read, so I missed it.

> http://www.ietf.org/mail-archive/web/spfbis/current/msg03633.html

Same with that one.

> http://www.ietf.org/mail-archive/web/spfbis/current/msg03653.html ).

This message repeats discussions that we've already had and the chairs 
declared closed.  I don't think a response is needed or appropriate.

> http://www.ietf.org/mail-archive/web/spfbis/current/msg03726.html ).

Based on that, I think that no changes in the document are needed.

> Can you provide an estimate date of when the reviews mentioned above

I'm currently waiting for msk to send me some XML edits based on other 
comments.  Since the two outstanding reviews will probably lead to a number of 
small changes throughout the draft, I'm planning on waiting until I get msk's 
XML back and can merge in his changes.

Possibly today.  As long as I get the XML update back from msk this weekend, I 
should be able to finish up the other two reviews on Monday.

Scott K

---

From: Hector Santos <[email-masked]>
Date: Sat, 18 May 2013 15:06:26 -0400

I prefer the original MUST, there is a "legal" aspect to it, including 
"malpractice" for not doing something expected of you, or in legal terms
"what the (SPF) expert in practice is expected do."

If you (publisher) don't want harsh treatment, then it is just as equal 
to say "MUST NOT" use -ALL in the same way that you MUST use -ALL as it 
is the only way that would allow for a "legal" means to reject your mail.

We keep weakening the concept of -ALL and I hope we can stop doing 
things that will get criticism. I'm sure the key cogs can "talk" they 
way out of it, but SPF is the only protocol that allows for strong 
indemnification with a -ALL policy.   The rest is all junk in my book. 
  Its the same idea Mr. Levine had regarding SSP when he broke it up 
into ADSP and basically just offer one policy - discard.   The 
difference is that SPF caught on with a tremendous amount of high value 
domains (those that want and operate in strong exclusive network 
environments).  They are not your ESPs, public service bureaus.  The 
Mailing List, and even then the IETF.ORG has a -ALL policy. They are by 
far private corporate domains.  Please respect the desire to use -ALL 
with strong expectations for SPF compliant receivers to either reject or 
separate SPF failed mail. Either way, its not their mail and they don't 
want you (prefer) to push it to users.  It is now the Receiver 
responsibility if he ignores the -ALL policy.

Thank you

--
HLS

---

From: Commerco WebMaster <[email-masked]>
Date: Sat, 18 May 2013 15:06:43 -0600

+1

As I recall, the original spirit and intent of SPF was its being 
introduced as a simple vehicle to allow domain holders (now ADMDs) or 
publishers an easy way to announce to the known universe that email was 
being sent out from MTAs which were not under their control and were not 
authorized to send email using their domain names, as it damaged the 
reputation of their brands.  It attempted to do this without breaking 
most existing SMTP implementations and environments, which were all SPF 
unaware at that time.

Much of the impetus for SPF came from a growing practice in the late 
1990s, originally tagged a "Joe Job" because one of an early well 
publicized example which happened to the individual who held Joes.com at 
the time.  In essence, spammers were using the domain names of innocent 
domain holders, which would effectively ruin their domain's reputation. 
  SPF was a pretty darn good solution to address that problem.  SPF was 
and is not perfect, but it worked then and still works for many out there.

The sacrosanct nature of the -All syntax in the minds of publishers is 
vitally important where it is published as "v=spf1 -all", as that 
specific syntax example offers a very clear announcement by the domain 
holder, that under no circumstances should their domain ever send out email.

Ultimately, I believe that domain holders publishing this syntax would 
expect that unless the receiving MTA is SPF unaware (and after going on 
10 years of SPF published domains, it would be interesting to know how 
large that number actually is), the email MUST never arrive at the 
addressed user's mail box... ever (not as junk, not as flagged).  As SPF 
publishers, we can certainly not restrict local usage of data from the 
transaction, which can and will be used to the receivers' heart's 
desires for their analytic purposes, but if a receiver really does 
implement SPF, that message MUST never be delivered to the end user or 
it defeats the entire original goal of SPF preserving a domain name's 
reputation.

An equally binary decision should be to never deliver messages to the 
end user when the sending MTA IP does not match an explicit set of 
machines that the publisher represents as being the only IPs from which 
the domain should be sending email.

In these specific cases (and there are arguably quite a few more), 
anything less is just not a valid SPF implementation in the mind of this 
publisher... and I suspect the wide majority of those who chose to 
publish their SPF records to begin with.

For those environments needing a better answer that SPF1 supplies, it 
probably won't come from this SPFbis, but rather some future SPF V3 
where folks could have the luxury to define what they need after years 
of SPF1 experience, for example, a new ALL syntax (e.g., +ALL) which 
might meet the needs of some larger or unusual email environments.  It 
would have to be a future version because that kind of addition would be 
beyond the scope and definition of the charter.

And, rather remarkably, thanks to this SPFbis, there is even a fairly 
unused DNS RR called SPF in place which can even be immediately adopted 
and tasked for SPF V3!  The future is very exciting! ;-)

Alan M.

---

From: S Moonesamy <[email-masked]>
Date: Sat, 18 May 2013 15:25:50 -0700

Hi Scott,
>should be able to finish up the other two reviews on Monday.

Thanks.  I'll forward the responses to the directorate/review team 
reviews once they are ready.

Regards,
S. Moonesamy

---

From: Andrew Sullivan <[email-masked]>
Date: Sat, 18 May 2013 21:19:09 -0400

> Here's what I have now:

[elided]

I'm completely comfortable with that.

A

-- 
Andrew Sullivan
[email-masked]

---

From: Andrew Sullivan <[email-masked]>
Date: Sat, 18 May 2013 21:27:00 -0400

No hat, not even a straw one (it's Victoria Day weekend here).

On Sat, May 18, 2013 at 03:06:26PM -0400, Hector Santos wrote:
> I prefer the original MUST, there is a "legal" aspect to it,

No, there just isn't such an aspect, scare quotes or no.  We are not
legislators of the Internet.  We are people who recommend things that
people can do in order to maximise interoperability.  The passage in
question is talking about what happens under various conditions, _and
not_ what you have to do in order that the protocol works.  There's a
subtle but very important difference between, "If you don't do this,
the protocol doesn't work," and, "If you want to achieve $X, then you
need to do $Y."  

MUST in the 2119 sense means the former of those two, and that's why I
think in this case it's ok to change the text as Scott has suggested.
In particular,

> If you (publisher) don't want harsh treatment, then it is just as
> equal to say "MUST NOT"

_this_ is simply not a 2119 meaning of MUST, in my opinion.

> things that will get criticism. I'm sure the key cogs can "talk"
> they way out of it, but SPF is the only protocol that allows for
> strong indemnification with a -ALL policy.

There is no weakening here.  The text is plain.  It's just not
prescriptive, as is appropriate in a protocol document.  If you wish
to write a best practices document for operators, that would be a more
appropriate place to put your concerns here.

Best,

A

-- 
Andrew Sullivan
[email-masked]

---

From: "Murray S. Kucherawy" <[email-masked]>
Date: Sat, 18 May 2013 18:38:12 -0700

> I'm completely comfortable with that.

+1.

-MSK

---

From: "Murray S. Kucherawy" <[email-masked]>
Date: Sat, 18 May 2013 18:49:47 -0700

On Sat, May 18, 2013 at 2:06 PM, Commerco WebMaster
<[email-masked]>wrote:

> [...]
> publisher... and I suspect the wide majority of those who chose to publish
> their SPF records to begin with.
>
>
Hi Alan,

I'm not clear on how the language change under discussion here takes any of
that away.  It is still the case that, under the stated conditions, SPF
returns a "fail" and the receiver is then free to act on that as it sees
fit.

"MUST" has special meaning to us in the IETF.  As I understand it, "MUST
use '-all'" essentially means the protocol will break if you don't do
that.  In reality, the protocol works just fine if you don't do that; you
just aren't going to get the result you want.  The new text correctly
reflects this subtle difference.

There is no watering down of anything here; it's just a correction in the
way we use a few special words when writing RFCs.

Personally, I think the claim that any part of this or any other protocol
has "legal" implications is specious unless it's backed up by legislation
or legal precedent, which isn't the case here.

-MSK

---

From: "Murray S. Kucherawy" <[email-masked]>
Date: Sat, 18 May 2013 18:50:50 -0700

> should be able to finish up the other two reviews on Monday.
I do have it, and I plan to attack it this evening.

-MSK

---

From: "John Levine" <[email-masked]>
Date: 19 May 2013 04:44:13 -0000

>and it's a good point.

This part of RFC 4408 seems pretty clear to me, and the language is
unchanged in 4408bis other than the section number: 

3.1.2.  Multiple DNS Records

   A domain name MUST NOT have multiple records that would cause an
   authorization check to select more than one record.  See Section 4.5
   for the selection rules.

Since RRSETs are unordered, there'd be no way to tell in what order
the RRs of a split record were supposed to be assembled, or even which
RRs were supposed to be part of the SPF record and which weren't.
Since there is no length limit on a TXT record short of the 64K limit
on an RRSET, and multiple single-string records take up more space
than one multi-string record, there's no operational reason to split.
For anyone with a reasonable understanding of SPF and the DNS, I'd
think it would be obvious that splitting across multiple TXT records
wouldn't work.

When I read the message I think you're referring to, the person seemed
not to understand the difference between a TXT record with multiple
strings and multiple TXT records.  Given his background that was kind
of surprising, but that's sure what it looked like.

Scott knows better than I do, but I am not aware of anyone who's
actually tried to implement SPF being confused about this.

---

From: Commerco WebMaster <[email-masked]>
Date: Sat, 18 May 2013 23:25:25 -0600

Hi Murray,

I'm not trying to be disagreeable.  I'm simply trying to memorialize 
some of the thinking that took place in the earlier days of SPF as 
regards what publishers were told and why SPF really took off early as a 
domain name reputation tool for publishers in response to Hector's comment.

On 5/18/2013 7:49 PM, Murray S. Kucherawy wrote:
> <[email-masked] <mailto:[email-masked]>> wrote:
>
>     [...]
>
>     anything less is just not a valid SPF implementation in the mind of
>     this publisher... and I suspect the wide majority of those who chose
>     to publish their SPF records to begin with.
>
>
> Hi Alan,
>
> I'm not clear on how the language change under discussion here takes any
> of that away.  It is still the case that, under the stated conditions,
> SPF returns a "fail" and the receiver is then free to act on that as it
> sees fit.

Perhaps, as a publisher, I was being oversensitive to Hector's remarks, 
which did ring a cord.

> that.  In reality, the protocol works just fine if you don't do that;
> you just aren't going to get the result you want.  The new text
> correctly reflects this subtle difference.

I think that MUST has a special meaning to anyone defining or 
implementing a specification, as in you MUST do this or things go badly 
(as in break).

SPF was originally tasked and designed not to break SMTP, which would 
have been a show stopper for any publisher looking at implementing it. 
Thus, pretty much anything done with SPF must be flexible enough that it 
would not disturb the operation of a pure SMTP MTA.  I don't think many 
would argue that the way in which options for "all" was created in SPF1 
has proven too limited in cases for some larger mail services and other 
limited cases I won't rehash here.

I get that too.  My ultimate point is the best fix for those issues may 
well be better served in a future SPF version, because the better fix 
for this "-all" bone of contention may be to add additional "all" syntax 
to SPF1 addressing some of its current limitations and shortcomings, 
which I understand is beyond the scope of the SPFbis.

>
> There is no watering down of anything here; it's just a correction in
> the way we use a few special words when writing RFCs.
>

Very well then.

> Personally, I think the claim that any part of this or any other
> protocol has "legal" implications is specious unless it's backed up by
> legislation or legal precedent, which isn't the case here.
>
> -MSK
>

I also agree that there is certainly no actual "legal" implication in 
using the word MUST in a specification.  I'm not sure Hector was 
thinking legal as in pertaining to the legal system, thus his quotation 
marks around "legal".  I suspect that it was more like something in 
programming where words of art like "illegal bounds violation" or "legal 
operation" are used to describe bad or good events which happen in our 
world of computing and networking.  At least that is the way I took his 
statements.

"legal" arguably was an unfortunate choice by Hector, but I think the 
spirit of what I inferred as his intent may reflect concerns of some of 
the publishers about the process and the end result.

All that said, as long as publishers' domain reputations are protected 
and publishers don't end up getting inappropriate accusative phone calls 
from angry users about how a publisher spammed them (when the domain 
being accused of such events has a long term policy claim via an SPF TXT 
record not to send email at all), because the user's MTA should not have 
delivered the email to the user in the first place, then all is well. 
And again, I understand that could happen easily with an MTA that is SPF 
unaware, but with an SPF aware implementation, that really should never 
be allowed to occur.

Alan M.

---

From: "John Levine" <[email-masked]>
Date: 19 May 2013 05:57:00 -0000

>be reassembled.  It seemed to be reliable.  Totally unnecessary here though.

Well, kind of.  They put a 2K limit on the length of each TXT record,
allegedly because longer records broke BIND.  (This was in 2004, maybe
they did.)  The records were under a distinguished name _ep.whatever
and if there was more than one, each started with a two-octet sequence
number.  I think we can fairly characterize it as a crock.

Disregarding for a moment the fundamental ill-advisedness of storing
big blobs of XML in the DNS, if you actually wanted to do that, the
DNS standards have always been quite clear that you can have very long
TXT records, and that a server and client fall back to TCP to exchange
them if they're too big for a UDP packet.

But anyway, SPF has always been one record.
-- 
Regards,
John Levine, [email-masked], Primary Perpetrator of "The Internet for Dummies",
Please consider the environment before reading this e-mail. http://jl.ly

---

From: Hector Santos <[email-masked]>
Date: Sun, 19 May 2013 07:27:10 -0400

Andrew, its really not hard.

The term is used in reference to what any considerate and competent 
product manager would or better said, expected to consider -  product 
liability issues, and this certainly will fall under it.  Run it by your 
chief council. Its called neglect if you don't want to follow want is 
considered technically the expected of what will be "Internet Standard" 
practice.   Of course, nothing really matters if there is no harm, but 
push come to shove, it is certainly useful legal material if such a 
quote, harm, unquote, case ever comes up.

A protocol change (and that is what it is) of MUST to necessary, is not 
the same thing.  It weakens the protocol requirement to use -ALL as it 
was intended to be use if a publisher wishes a strong treatment to 
reject/separate by the receiver.  The BIS document went into (over) 
verbose length to stipulate this design requirement especially as a 
security concern - albeit weakly stated.

Thank you

--
HLS

---

From: Hector Santos <[email-masked]>
Date: Sun, 19 May 2013 09:20:51 -0400

On 5/18/2013 9:49 PM, Murray S. Kucherawy wrote:
> that.

Yes, that is exactly what it means.  From both ends, if a publisher 
wants immediate treatment by the receiver for highly detectable spoofed 
transactions, then he MUST use -ALL, otherwise, historically, mailer 
designers (of all networks), will not use immediate transport level 
reject, block, quarantine, or do whatever to the message that does not, 
"out of the box" requires the operator intervention, i.e. a heuristic or 
rule or trust concept.  The trust is *with* the protocol.

In other words, the SMTP package takes control.  Only -ALL can do this. 
  Consider it the "Built-in" special handling, that does not require any 
other protocol.

Keep in mind that mail receivers (MDAs, not users) also have a big stake 
in this. It lowers the processing abuse taken on by the receiver for all 
the spoofing going on.  The entire network feels it, had felt it in 2003 
which highlighted the urgency, i.e. MARID.  So receivers are also 
telling publishers you MUST use -ALL if you want the receivers to 
immediately classified the message for negative, rejectable, no need to 
report, built-in SPF support operations.

I would also like to politely suggest, that you (Murray) is 100% 
perfectly correct in having the design philosophy and synergism to 
couple concepts such as DMARC as the means to expose "handling" ideas. 
Its the same idea proposed in 2006 with the DSAP (DKIM Signature 
Authorization Protocol) [1] where it included handling and reporting 
features as well.

So on the one hand, we can refer to additional handling protocols or we 
can keep that ended for all the SPF policies except for, as long term 
SPF advocates stated, the one special case -ALL policy which gives 
publishers and receivers that power to filter at the SMTP transaction 
level.

Of course, we can make it optional, and that could be the *new* thing in 
all honesty, for implementers. A common translation we would program for 
operators:

    [X] Reject SPF -ALL failed message
        [X] Move to User's SPAM box

Of course, I understand where there may be operation, like an ESP, where 
it is done only with a separation by default and with no option to 
reject.  So one side rejects with no option to separate, and another 
aside separates with no option to reject except to allow the user to 
trash his spam box.

Finally, consider that not every mail system needs or even offers a SPAM 
BOX separation, especially true with the early mail systems.  So called 
"Spam/Junk" folders came much later in the game.

I understand your POV, like many of my sysop customers have, that SPAM 
BOXES and online views of such concepts is a good feature to have in 
mail products.   But from a protocol standpoint, this "folder view" 
design can not be enforced.

> way we use a few special words when writing RFCs.

It adds confusion for the -ALL SPF "built-in" special handling case.

> or legal precedent, which isn't the case here.

Its a product design methodology, that does include social engineering 
concepts (not of the Facebook "social" kind), but infrastructure per se.

Thank you

--
HLS

[1] DKIM Signature Authorization Protocol (DSAP)
     http://tools.ietf.org/html/draft-santos-dkim-dsap-00#page-16

---

From: Scott Kitterman <[email-masked]>
Date: Tue, 21 May 2013 00:48:43 -0400

> ).  There weren't any comments about that review.

Commented (should hit the list before this does).

> http://www.ietf.org/mail-archive/web/spfbis/current/msg03633.html 

It's almost 1AM here and I'm out of steam for the night.  I'll try to get to 
this one tomorrow.

Scott K

---

From: Alessandro Vesely <[email-masked]>
Date: Thu, 23 May 2013 13:27:17 +0200

On Fri 17/May/2013 20:52:13 +0200 Murray S. Kucherawy wrote:
>>>> 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.
>>>
>>> I'm not making that demand, but I do think it bolsters our
>>> position if it's seen real world action.  I don't have any
>>> objection to including it.  We just need to be prepared to push
>>> on it if the WG agrees that it's what we want to say and it's
>>> met with resistance.
>>
>> I think it's far better than leaving eventually permanent
>> temperrors in the sending mail queue for the queue life.  If
>> someone has a better way to deal with it, then please suggest it.
>> I don't particularly like the solution, I just think it's better
>> than anything else we've got.
> 

I agree on the principle:  Admins who wish to protect their domain
names with SPF must be so clever as to serve their records timely.

On Sat 18/May/2013 01:58:55 +0200 John Levine wrote:
>
> Well, sure, and it can be equally permanent if you get it when
> doing an MX or A/AAAA lookup on the client side, leading to
> repeated requeues until the message times out (RFC 5321 sec 5.1.) I
> still don't see what merits different treatment.

The difference is that the client side has a queue timeout, which the
server misses in this case.  The client may have a different strategy
for these malfunctions, but there's no way to inform it.  So, the
server had better not reply 4xx for 5 days if it can determine the
failure is not going to go away.

If we agree it is a server policy issue, can it be addressed in a
section on *Policy For SPF Temperror*, then?

---

From: S Moonesamy <[email-masked]>
Date: Thu, 23 May 2013 08:24:28 -0700

Hi Scott,
>Commented (should hit the list before this does).

Thanks, the Gen-ART review has been addressed ( 
http://www.ietf.org/mail-archive/web/spfbis/current/msg03801.html ).

>It's almost 1AM here and I'm out of steam for the night.  I'll try to get to

Could you please provide an estimate date of when the Applications 
Area directorate and Security Directorate reviews will be addressed?

Thanks,

---

From: Scott Kitterman <[email-masked]>
Date: Thu, 23 May 2013 12:30:06 -0400

On Thursday, May 23, 2013 08:24:28 AM S Moonesamy wrote:
> >It's almost 1AM here and I'm out of steam for the night.  I'll try to get
> >to this one tomorrow.
> 

As we discussed previously, I think the discussion we've already had is 
sufficient response to the security review.  I'm working on the applications 
area review today.

Scott K

---

From: Scott Kitterman <[email-masked]>
Date: Thu, 23 May 2013 16:23:52 -0400

> Can you provide an estimate date of when the reviews mentioned above

I believe these are all addressed now.  I don't have any other reviews 
pending, so I'll publish -15 later today if no one else speaks up.

Scott K