Subject: Re: [spfbis] WGLC: draft-ietf-spfbis-4408bis-14

From: Scott Kitterman <[email-masked]>
Date: Wed, 08 May 2013 13:14:01 -0400

On Tuesday, April 23, 2013 11:03:37 AM Murray S. Kucherawy wrote:
> On Mon, Apr 8, 2013 at 11:24 PM, Andrew Sullivan 
<[email-masked]>wrote:
> > Dear colleagues,
> > 
> > This message initiates a two-week working group last call on
> > draft-ietf-spfbis-4408bis-14, our only work item.
> > 
> > The draft has been through 14 revisions, and all open issues in the
> > tracker are closed.  Please review the document and indicate any
> > comments you have by sending a note to the mailing list.  If you have
> > no comments, it is valuable nevertheless to learn that you have read
> > the document and support its publication.
> > 
> > WGLC will close at 2014-04-24 00:00 UTC.
> > 
> > SM will be the shepherd for this document.
> 
> Most of this is nits; except as noted, you could ignore it all and I'd be
> happy.  Nevertheless:
> 
> Section 1:
> 
> The last paragraph makes the claim that domain reputation is likely to be
> more accurate than IP reputation.  Is it worthwhile to add a sentence or
> two explaining why this is true?

I don't think so.  First, it's speculation and I don't think enough of a case 
for it can be made without being too long/distracting.  Second, it's not part 
of the protocol, so it not something we should worry about overmuch.

> Section 1.1.2:
> 
> Suggest replacing the first sentence with "ABNF is defined in [RFC5234], as
> are the tokens ALPHA, ..."  As it is now, "ABNF" is not expanded on first
> use.

Done.

> Section 1.1.3:
> 
> Replace the last sentence with: "Note that other terms that might
> superficially look like the common terms, such as 'reverse-path', are used
> only as they are specified in their defining documents."

Done.

> Section 2.1:
> 
> I think someone else already mentioned this, but how does encouraging a
> second check decrease DNS resource use?

I did reply to this already.  It's a matter of HELO records generally being 
much 'cheaper' than mail from records.

> Also, suggest replacing the first sentence of the second paragraph with
> "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 is identity to be an IP address literal, or simply be
> malformed."   We might even reference the IP address literal ABNF in
> RFC5321 here.

Done (both changes)

> Section 2.2:
> 
> Add to the first paragraph "...or no HELO check was done." or something of
> that ilk.

Done.

> Section 2.3:
> 
> The second paragraph is loaded with negatives "no... neither... nor."
> Suggest: "ADMDs can publish SPF records that authorize no hosts to use
> their DNS domain names in HELO or MAIL FROM commands during SMTP sessions."

I added that, because it's a good point, but it doesn't replace the existing 
text which attempts to (without being too pointed about receiver policy) say 
that if you want receivers to be able to reject mail that didn't come from 
authorized hosts, you need a -all record.  Some senders care about supporting 
these negative assertions, others don't.

> Section 2.4:
> 
> Isn't the fourth paragraph implicit in any standards specification?  That
> is, do we really need it?

I see your point, but I think it should actually stay.  Consistency of 
evaluation across multiple implementations is key to the success of the 
protocol.  IIRC, you said during the debate that if you were implementing SPF, 
you'd ignore the macro requirements.  You're, of course, free to do that, just 
don't say you implemented SPF.

> Section 2.5:
> 
> I can't remember if I suggested it previously, but an appendix of RFC5451
> gives a pretty thorough treatment of the notion of doing mail
> authentication checks during the SMTP session versus later.  It might be
> helpful as an informative reference here.

Added.

> Section 2.6.7:
> 
> Does "permerror" also result when permanent DNS errors occur?

Tell me how to figure out when a DNS error is permanent and then maybe.  Given 
what's described in 4.4 Record Lookup, I think only extended SERVFAIL (if the 
receiver has implemented the temperror -> permerror promotion option) can 
currently get a permerror.

> Section 3.1:
> s/alternate/alternative/

Done.
> 
> Section 4.1:
> 
> The list of check_host() inputs have been repeated here as in Section 2.4.
> Do we need both lists?

I think not.  I made 2.4 reference 4.1 and removed the duplication.

> Section 4.4:
> 
> s/suggests on an algorithm/suggests an algorithm/

Done.
> 
> Section 4.6.4:
> 
> I imagine you're going to say that 10 is the limit imposed by most
> implementations, but shouldn't we say that there should be a finite,
> perhaps configurable limit, and operational experience has shown that 10 is
> a reasonable default?

No.  We need consistent limits because if receivers vary the limits, then 
there will be inconsistent results and poor interoperability.

> Why 20 seconds for the overall run time?

This is carried forward from RFC 4408.  It was moved from section 10.1 to 
4.6.4 as part of issue #6, but the value is unchanged.  I'm not aware of any 
issues with what's defined in 4408.

> Section 4.8:
> 
> In the third paragraph, a couple of sentences start with "Domain" when you
> actually mean it as a literal parameter name.  I suggest using "domain"
> (including the quotes) instead.

Done.

> The "Some implementations ..." sentence seems to be malformed.  I can't
> parse it.

Better?

          Note: Historically, this document has made no provisions for how to
          handle domain-specs, or macro-expansions thereof, that are
          syntactically invalid per <xref target="RFC1035"/>, such as names
          with empty labels (e.g., "foo..example.com") or overlong labels
          (more than 63 characters).  Some implementations choose to treat 
          mechanisms associated with such expansions as no-match and
          ignore modifiers with such names, others return a "permerror" 
          exception. The outcome for an unexpected domain-spec without macros 
          might even differ from that for an unexpected &lt;target-name&gt; 
          after macro expansion.

> Section 5.2:
> 
> s/Check_host/check_host/ (it's not a word that starts sentences and thus
> needs capitalization)

Done.

> Missing end-quote at the end of bullet 3.
>
Done.

> The second-last paragraph is weirdly wrapped.  Is the XML ok there?

I think I fixed that already based on John Levine's comments.   Please double 
check the new draft.

> Section 5.4:
> 
> Should the limits stuff in here be removed, and simply reference Section
> 4.6.4 instead?

Yes.  Done.

> Section 5.5:
> 
> The SHOULD NOT in here is puzzling.  Does it interfere with
> interoperability to use it?  It was my impression that it's possible to get
> the same functionality some other way, but not that using "ptr" actually
> was a bad idea for interoperability reasons.

Yes, because it produces inconsistent results and is error prone.  Both those 
things impact interoperability.

> Again with the limits stuff, redundant to Section 4.6.4.

Done.

> Section 5.6:
> 
> For IPv4, shouldn't the CIDR be 1*2DIGIT?  For IPv6, shouldn't the CIDR be
> 1*3DIGIT?

I don't know.  It's unchanged from RFC 4408 right now, but I'd like other 
opinions on changes here (ABNF makes my head hurt).

> Section 6.2:
> 
> It just occurred to me that in the earlier sections (2 or 4, in
> particular), it's clear that check_host() returns one of the enumerated
> result, but it's never made explicit that it also outputs an explanation
> string.  We might want to mention this earlier than we do now so it's not a
> surprise later.

It's an optional and somewhat rare output of the protocol, so I think not, but 
did you have something specific in mind?
> 
> The SHOULD in the fifth paragraph is questionable: How does it describe an
> aspect of interoperability?

It avoids the risk of a common implementation error in SPF libraries (that 
process left to right) so it promotes consistent results.  It also helps for 
human readability, but I think it helps the protocol too.
> 
> Last paragraph, s/exp=/exp/ 2x.

Done.

> Section 7.1:
> 
> ABNF rules say literal strings in productions are case-insensitive.  That
> means the macro-letter set actually implicitly includes all of the capital
> letter equivalents.  If we want to constrain it to lowercase only, we need
> to use hex notation.

OK.  If someone would provide those, it would be great.  Otherwise, I'll take 
a shot at it, probably Friday.

> Section 7.3:
> 
> "This macro SHOULD NOT be used...." should be in its own paragraph.  Also
> the second sentence should be "See Section xxx for discussion."

Done.

> At the end of this section, there are three paragraphs that all start
> "Note:".  I don't think those tags add anything and suggest they be removed.

Done.

> Section 8:
> 
> Second paragraph, s/, and where/ and, where/

Done.

> Section 8.7:
> 
> Don't the last two sentences say the same thing?

Almost.  One is error due to macro expansion giving a bogus result.  the other 
is an error due to check_host being handed a bad domain as an input.

> Section 9.1:
> 
> Same point about the case-insensitivity of ABNF here.

Except for "Received-SPF" is there anything case insensitive there?  I'd 
greatly appreciate text for this too.

> The "SPF verifiers MUST make sure..." doesn't seem actionable to me.  Do we
> really expect Received-SPF generators to be able to identify and exclude
> malicious data?

I think you have to.  I've seen people put html pointing to malicious web 
sites in SPF records.  Thanks to someone privately pointing this class of 
attack out to me, my SPF validator now properly escapes anything that's 
retrieved from DNS.
> 
> Section 10:
> 
> s/document/protocol/ (or specification) x3

Done.

> Section 10.1.1:
> s/required/necessary/

I went with needed.

> Section 10.1.2:
> 
> Add "at the cost of a DNS query per receiver" to the end of the first
> sentence.

Done.

> Section 10.1.3:
> 
> s/to hostname/to the hostname/, s/of domain/of the domain/

Done.

> Section 10.2:
> 
> Missing close parenthesis in the first paragraph.

I don't see it.  I may have fixed it already.  Please double check.

> Section 10.3:
> 
> Errant period in the first sentence.

Fixed.

> s/Address/address/

Done.

> Section 11.1:
> 
> Aren't the first and third bullets describing the same attack?

No.  One's a DoS due to lots of mail being sent.  The other's a DoS due to the 
way malicoius SPF records are constructed.  Similar, but not the same.

> Missing parenthesis at the end of the fourth bullet.

Fixed.

> Section 11.3:
> 
> Clobbering the DNS at a receiver could also result in delivery of malicious
> mail if the receiver is configured to pass on "tempfail" and just add a
> header field.

Good point.  I added a sentence on to bullet two in 11.1.  It seemed to fit 
there.  Please let me know what you thing.

> Is that second bullet true?  It appears to claim that IP address spoofing
> is effectively impossible.

In any way that would be useful for SPF, it is AFAIK.

> Section 11.5:
> 
> This appears to be an incomplete thought.  At a minimum, it doesn't flow
> nicely into the next subsection.  Maybe add a sentence to indicate that
> SMTP itself doesn't do anything to validate those parameters?

Added.

> Section 11.5.2:
> 
> Remove commas around the section reference.

Done.

> Appendix A:
> 
> Any changes made to ABNF above need to be reflected down here.

I believe they are consistent.

> Appendix B.3:
> 
> Suggest a reference to RFC5782.

Done.

> Appendix C:
> 
> s/implmentation/implementation/

Done.

> Appendix G:
> 
> Fourth paragraph: As I mentioned above, RFC5451 has an appendix that talks
> at length about why you want to do things like SPF checks at the border
> rather than inside.

Added the reference.

> Appendix I:
> 
> The second paragraph claims we're documenting extensions since 4408.  Were
> there any?
Yes.

Use of A-R in place of Received-SPF in some cases and the "void lookups" 
limit.

Sorry for the delay in responding.

Scott K

---

From: Dave Crocker <[email-masked]>
Date: Wed, 08 May 2013 12:02:57 -0700

> of the protocol, so it not something we should worry about overmuch.

Unfounded speculation in a specification has no utility other than 
providing opportunities for pure distraction.  Good candidate for 
removal from the text.

> much 'cheaper' than mail from records.

I don't understand.

> don't say you implemented SPF.

The problem is that casting it in normative terms means that the spec is 
pretending it is asserting something distinctive in this context.  It 
might make sense to caution the implementer to validate the function, 
but it doesn't make sense to phrase this as part of the protocol 
specification, any more than it makes sense to say that the MUST use a 
compiler that works well...

> there will be inconsistent results and poor interoperability.

Yeah, that's probably right.  My own view is that a recursion limit of 
10 is phenomenally expensive (impractical) and a much smaller number 
would be much better; but I assume that discussion isn't in scope...

>            might even differ from that for an unexpected &lt;target-name&gt;

Perhaps a bit simpler still:

    Note:  Historically, this document made no provisions for the 
handling of syntactically invalid domain-specs or macro-expansion, per 
<xref target="RFC1035"/>. Examples include names with empty labels, such 
as "foo..example.com", and labels that are longer than 63 characters. 
Some implementations choose to treat such errors at no-match and 
therefore ignore such names, while others return a "permerror" exception.

{I'm lost on the last sentence because I don't know what "unexpected" 
means in technical terms. }

> way malicoius SPF records are constructed.  Similar, but not the same.

it's worth adding text to make this clearer.

d/

-- 
Dave Crocker
Brandenburg InternetWorking
bbiw.net

---

From: "John Levine" <[email-masked]>
Date: 8 May 2013 20:42:13 -0000

>would be much better; but I assume that discussion isn't in scope...

I think you'll find that the libraries have all had a limit of 10 for
quite a while, and nothing bad has happened.

Also, there are definitely real SPF records with 9 or 10 indirections,
typically companies that include an ESP's record that has ranges all
over the place.  Were we to drop the limit below 10, there would be
interop problems.

R's,
John

---

From: Scott Kitterman <[email-masked]>
Date: Wed, 08 May 2013 16:46:40 -0400

> over the place.  Were we to drop the limit below 10, there would be

Definitely.  I'm not so far aware of a domain that couldn't express it's record 
within the processing limits if they made the effort to try, but there are 
large ADMDs with records that exceed the limits on a not infrequent basis and 
ahve to be reminded.

Lowering limits is not a realistic option.

Scott K

---

From: Scott Kitterman <[email-masked]>
Date: Wed, 08 May 2013 17:01:09 -0400

On Wednesday, May 08, 2013 12:02:57 PM Dave Crocker wrote:
> > I don't think so.  First, it's speculation and I don't think enough of a
> > case for it can be made without being too long/distracting.  Second, it's
> > not part of the protocol, so it not something we should worry about
> > overmuch.

OK.  Ditched the paragraph.

> > much 'cheaper' than mail from records.

I did give a longer answer elsewhere, but I can't find it.  Typically records 
for HELO/EHLO require zero or one additional DNS lookups.  If you can reject 
based on that, you save the cost of looking up the generally more 
complex/expensive Mail From record.  As with many things, if it's cheaper in 
DNS lookups or not is very scenario dependent, which is why it's not stated as 
a hard fact.  It'll be true sometimes and not others.

> > protocol.  IIRC, you said during the debate that if you were implementing
> > SPF, you'd ignore the macro requirements.  You're, of course, free to do
> > that, just don't say you implemented SPF.
> 

OK.  I did s/MUST/has to.

> would be much better; but I assume that discussion isn't in scope...

See John Levine's reply and mine to him.

> means in technical terms. }

I concluded it didn't add anything useful.  I went with something close to 
what you provided:

          Note:  This document and its predecessors make no provisions for 
          defining correct handling of syntactically invalid domain-specs or 
          macro-expansion, per <xref target="RFC1035"/>.  Examples include 
          names with empty labels, such as "foo..example.com", and labels that 
          are longer than 63 characters.  Some implementations choose to treat 
          such errors at no-match and therefore ignore such names, while 
          others return a "permerror" exception.  

I considered saying, "... so senders should not create SPF records that rely 
on either behavior to achieve the desired result."   I decided it probably 
wasn't needed.  Let me know if anyone disagrees.

> > No.  One's a DoS due to lots of mail being sent.  The other's a DoS due to
> > the way malicoius SPF records are constructed.  Similar, but not the
> > same.

Done.

Scott K

---

From: "Murray S. Kucherawy" <[email-masked]>
Date: Wed, 8 May 2013 14:09:24 -0700

On Wed, May 8, 2013 at 10:14 AM, Scott Kitterman <[email-masked]> wrote:

> case

I think a simple, brief addition would do it:

This is advantageous because reputation of domain names is likely to
   be more accurate than reputation of host IP addresses since domains
are more likely to be stable over the long term.

 ...or something like that.

> much 'cheaper' than mail from records.

As long as the document explains that in a sentence or two, we're good.

> these negative assertions, others don't.

My comment wasn't so much to correct the text, but to point out that the
sentence is hard to read with so many negatives.

Doesn't the sentence I proposed say the same thing?

> SPF,

I would agree with all of that except the need to say it in a Proposed
Standard.  Any other opinions?

> currently get a permerror.

RCODEs 1, 3, 4, and 5 all look permanent to me as defined in RFC1035, in
that a retry is unlikely to yield a different result absent an operator
changing some configuration or zone data.  0 is "no error" and 2 is "server
failure"; the latter is obviously permanent (but desirable), leaving 2 for
the case where a timeout or some other transient thing occurred.

> issues with what's defined in 4408.

I don't have an issue with 20 specifically.  I'm just anticipating the "Why
20?" question from someone else.

>           might even differ from that for an unexpected &lt;target-name&gt;

Now that I see what it's trying to say, this is fine.  Dave's suggestion is
fine as well, I think.

> I think I fixed that already based on John Levine's comments.   Please

Will do when it comes out.

> opinions on changes here (ABNF makes my head hurt).

It's probably not harmful to leave it, really.  It's just an observation
that 1*DIGIT allows 000000024 (which is probably fine) but also allows
1048576 (which probably isn't).  1*2DIGIT would limit it to 00-99 at least.

You could also cover this in prose by saying 1*DIGIT and then in either an
ABNF comment ("; blahblah") or in text nearby say that it has to evaluate
to an integer from 0 to 32 for v4 and 0 to 128 for v6.

> did you have something specific in mind?

I'm thinking about what we did with DKIM, where we made it very clear that
DKIM's primary output is a pass/fail/etc. and the "d=".  Anything that
outputs something beyond that is an extension outside the scope of the
specification.  Then again, the premise for doing that was protracted
debate about "i=" vs. "d=" (Dave still has the buttons), but that's a
different issue.

Maybe we don't need to go down this path with SPF if it's not needed, but
during my review that memory came up, and I thought it might be useful to
consider it.

> a shot at it, probably Friday.

The "ascii" man page on your favourite UNIX distribution has them.  You're
looking for something like:

   macro-letter     =  %x73 / %x6c / ...

> greatly appreciate text for this too.

I don't think "From" needs to start with a capital "F" for it to be the one
RFC5322 talks about.  More generally, I don't think header field names are
case-sensitive.  Thus, "Received-SPF" is fine as-is.

The rest of it is probably also fine, unless for some reason it has to be
"pass" and must never be "PASS" or "pAsS", etc.

> attack out to me, my SPF validator now properly escapes anything that's

It's the "malicious data" part that concerns me because what constitutes an
effective data attack is very context-sensitive.

> I don't see it.  I may have fixed it already.  Please double check.

Will do, when it's out.

> there.  Please let me know what you thing.

Will do, when it's out.

-MSK

---

From: Alessandro Vesely <[email-masked]>
Date: Thu, 09 May 2013 17:31:18 +0200

On Wed 08/May/2013 23:09:24 +0200 Murray S. Kucherawy wrote:
>>> ABNF rules say literal strings in productions are
>>> case-insensitive.  That means the macro-letter set actually
>>> implicitly includes all of the capital letter equivalents.  If
>>> we want to constrain it to lowercase only, we need to use hex
>>> notation.
>>
>> OK.  If someone would provide those, it would be great.  Otherwise, I'll
>> take a shot at it, probably Friday.
>

No, wait.  Do we really want that?

The syntax of URL escaped expansions is the same as that of lowercase
macros.  We don't need two parallel sets of production rules, do we?

IMHO, adding a comment, e.g. as follows, such suffice.

  macro-letter     = "s" / "l" / "o" / "d" / "i" / "p" / "h" /
                      "c" / "r" / "t" / "v"
                     ; uppercase or lowercase, see URL escaping below

---

From: "Murray S. Kucherawy" <[email-masked]>
Date: Thu, 9 May 2013 10:55:26 -0700

> No, wait.  Do we really want that?

We do if current implementations generally do only lowercase macro
support.  If they're case-insensitive, then what's there is fine.  It's my
impression that %{S} isn't valid to most implementations.  If I'm wrong
about that, then I withdraw the suggestion.

>                      ; uppercase or lowercase, see URL escaping below

 "uppercase or lowercase" is implicit in ABNF.  That's the point of my
suggestion.

-MSK

---

From: Alessandro Vesely <[email-masked]>
Date: Fri, 10 May 2013 11:54:04 +0200

> about that, then I withdraw the suggestion.

I agree the case (in)sensitivity can easily get overlooked.  Yet, the
syntax is the same.  Currently, the paragraph that specifies URL
escaping makes no reference to any grammar rule, but we could rewrite
it as:

   MACRO-EXPAND macros with an uppercase MACRO-LETTER expand
   exactly as their lowercased equivalents, and are then URL
   escaped.  URL escaping MUST be performed for characters not
   in the "unreserved" set, which is defined in [RFC3986].

I don't think that would make it any clearer.  Anyway, if we still
wanted to rewrite it that way, we could do so without having to define
MACRO-LETTER and MACRO-EXPAND, since rule names are case insensitive
as well [1].

> "uppercase or lowercase" is implicit in ABNF.  That's the point of my

Yup, the comment turns implicit into explicit.  IOW, the grammar is
correct but readers overlook it.  Hence it's the accompanying text,
not the grammar, that we need to amend.  I think the reason why that
paragraph is overlooked is because it is too far down in the section,
not because it misses grammar references.  The second part of the
comment is an attempt to draw the reader's attention there.

-- 
[1] For example, the <mechanism> rule has uppercase A / MX / PTR / IP4
/ IP6, while those terms' definitions are lowercase in the subsections
of Section 5 where they are introduced  --a change committed on August
16, 2012 (-04), a period we were lowercasing various stuff.

---

From: "Murray S. Kucherawy" <[email-masked]>
Date: Fri, 10 May 2013 09:37:09 -0700

On Fri, May 10, 2013 at 2:54 AM, Alessandro Vesely <[email-masked]> wrote:

> [...]

Whoops, I completely missed the thing about uppercase macros are URL
escaped.  I withdraw the suggestion.

-MSK

---

From: Scott Kitterman <[email-masked]>
Date: Fri, 10 May 2013 12:54:18 -0400

On Friday, May 10, 2013 09:37:09 AM Murray S. Kucherawy wrote:
> > > On Thu, May 9, 2013 at 8:31 AM, Alessandro Vesely <[email-masked]>
> > 
> > wrote:
> > > support.  If they're case-insensitive, then what's there is fine.  It's
> > 
> > my
> > 

Excellent.  Sometimes procrastination pays ...

Scott K

---

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

>  ...or something like that.

I think that would have been fine.  I already took it out.  Do you think I 
should put it back?

> As long as the document explains that in a sentence or two, we're good.

Here's what I added:

... (if a conclusive determination about the message can be made based on a 
check of "HELO", then the use of DNS resources to process the typically more 
complex "MAIL FROM" can be avoided).

> > > their DNS domain names in HELO or MAIL FROM commands during SMTP
> > 
> > sessions."
> > 

Almost.  It loses the nuance that this is only appropriate for hosts that send 
no mail.  You'd think that'd be obvious, but it's not.

> Standard.  Any other opinions?

I didn't here much in the way of opinions on this.  Since it's carried forward 
from 4408, I'll leave it for now.

> the case where a timeout or some other transient thing occurred.

This is a good point.

3 is permanent, but it's not an error.  It's no data.  Currently the draft 
says anything other than 0 or 3 is a temperror.

5 could be temporary, I'd think (query refused due to overload maybe?)

Looking at http://www.iana.org/assignments/dns-parameters/dns-parameters.xml#dns-parameters-6, I agree that many of these DNS errors could 
be permanent, but the spec calls for temperror in these cases.

The only temporary errors that turned out to really be permanent that I've 
seen in the wild are some SERVFAIL (2).

If we were starting from scratch, I'd probably classify many of the other 
rcodes as permanent errors, but we aren't.  Absent some evidence of this 
causing real world problems, I think we need to leave it the way it is.

> 20?" question from someone else.

Because it's been that way for a long time and seems to work.  IIRC, at the 
time, it was the shortest time we could get some agreement around.  If it were 
just me, I'd pick a number closer to 2 than 20.

> >           Note: Historically, this document has made no provisions for how
> > 
> > to
> > 
> >           exception. The outcome for an unexpected domain-spec without
> > 
> > macros
> > 

Thanks.

> > > For IPv4, shouldn't the CIDR be 1*2DIGIT?  For IPv6, shouldn't the CIDR
> > 
> > be
> > 
> > > 1*3DIGIT?
> > 

Maybe import the definitions in http://www.ietf.org/rfc/rfc3986.txt instead?

> > > string.  We might want to mention this earlier than we do now so it's
> > 
> > not a
> > 
> > > surprise later.
> > 
> > It's an optional and somewhat rare output of the protocol, so I think not,
> > but did you have something specific in mind?
> 

I think it's enough of a corner case we should leave it.

> > > means the macro-letter set actually implicitly includes all of the
> > 
> > capital
> > 
> > > letter equivalents.  If we want to constrain it to lowercase only, we
> > 
> > need
> > 
> > > to use hex notation.
> > 

We resolved this already, right?

> effective data attack is very context-sensitive.

Do you still think it needs a change?

Scott K

---

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

On Fri, May 17, 2013 at 10:04 AM, Scott Kitterman <[email-masked]>wrote:

> > > > The last paragraph makes the claim that domain reputation is likely
> to
> > > > be
> > > for it can be made without being too long/distracting.  Second, it's
> not
> > > part

I do.

> complex "MAIL FROM" can be avoided).

I suspect that's better as its own sentence rather than something
parenthetical, but the text is right.

> > > text which attempts to (without being too pointed about receiver
> policy)
> > > say

So:

ADMDs that wish to declare that no hosts are authorized to use their DNS
domain names in the HELO or MAIL FROM commands during SMTP sessions can
publish SPF records that say so.

> > > you'd ignore the macro requirements.  You're, of course, free to do
> that,
> > > just

Rats.  Since we're looking for text to slash in response to the bloat
complaint, this is a prime candidate.

> > > what's described in 4.4 Record Lookup, I think only extended SERVFAIL
> (if
> > > the

True, NODATA isn't an error, but it is final.

> 5 could be temporary, I'd think (query refused due to overload maybe?)

 Overload is supposed to be SERVFAIL, I think.  Andrew?

I think 5 is used for policy things like "You're not allowed to know that."

> Looking at
> http://www.iana.org/assignments/dns-parameters/dns-parameters.xml#dns-parameters-6,
> I agree that many of these DNS errors could

As in a server that constantly returns SERVFAIL?  I imagine that just like
in any context, a temporary error that's constantly returned is eventually
de facto treated as permanent insofar as the client gives up and goes away.

> causing real world problems, I think we need to leave it the way it is.

I think this is an error that warrants correction.  It might be interesting
to know what some implementations have done here, e.g., if implementers
decided to implement based on RFC1035 rather than RFC4408.

> > > 4.6.4 as part of issue #6, but the value is unchanged.  I'm not aware
> of
> > > any

I suggest a sentence saying this was chosen arbitrarily, or based on the
fact that SMTP sessions that take longer than this are quite unusual, or
something.

> Maybe import the definitions in http://www.ietf.org/rfc/rfc3986.txtinstead?
>

I looked through the collected grammar in there and didn't see anything
that covered CIDR expressions.  Now that my eyes have un-crossed, did you
have specific one(s) there in mind?

> We resolved this already, right?

Yes, disregard.

> > > The "SPF verifiers MUST make sure..." doesn't seem actionable to me.
>  Do
> > > we
> > >

Yes, but it's not a hill on which I plan to die.  I'd love to hear what
others think though.

-MSK

---

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

On Friday, May 17, 2013 10:54:52 AM Murray S. Kucherawy wrote:
> > > On Wed, May 8, 2013 at 10:14 AM, Scott Kitterman <[email-masked]>
> > 
> > wrote:
> > to be
> > not part

OK.  Done.

> > ... (if a conclusive determination about the message can be made based on
> > a check of "HELO", then the use of DNS resources to process the typically
> > more complex "MAIL FROM" can be avoided).
> 

OK.  Changed.

> > > > > Suggest: "ADMDs can publish SPF records that authorize no hosts to
> > 
> > use
> > 
> > > > that if you want receivers to be able to reject mail that didn't come
> > 
> > from
> > 

Based on this, I changed it to:

          ADMDs that wish to declare that no hosts are authorized to use their 
          DNS domain names in the HELO or MAIL FROM commands during SMTP 
          sessions can publish SPF records that say so for domain names that 
          are neither used in the domain part of email addresses nor expected 
          to originate mail.

> > > > protocol.  IIRC, you said during the debate that if you were
> > 
> > implementing
> > 
> > > > SPF,
> > > > Tell me how to figure out when a DNS error is permanent and then
> > > > maybe.
> > > > 
> > > >  Given
> > > > 
> > > > receiver has implemented the temperror -> permerror promotion option)
> > 
> > can
> > 
> > > changing some configuration or zone data.  0 is "no error" and 2 is
> > 
> > "server
> > 
> > > failure"; the latter is obviously permanent (but desirable), leaving 2
> > 
> > for
> > 
> > http://www.iana.org/assignments/dns-parameters/dns-parameters.xml#dns-para
> > meters-6, I agree that many of these DNS errors could

All of the ones I know of make anything not 0 or 3 a temperror.  I agree it's 
wrong, but is it an error that, in operation, causes any problems?  If not, I 
don't think we should fix it.

> > > > This is carried forward from RFC 4408.  It was moved from section 10.1
> > 
> > to
> > 
> > > I don't have an issue with 20 specifically.  I'm just anticipating the
> > 
> > "Why
> > 

The number was extracted from the usual location.

OK, not that.

Is it common to justify design decisions like this in the draft of the text?  
Might this be better for sm's write up than the actual draft?

> > > > > For IPv4, shouldn't the CIDR be 1*2DIGIT?  For IPv6, shouldn't the
> > 
> > CIDR
> > 
> > > > be
> > > > 
> > > > > 1*3DIGIT?
> > > > 
> > > > I don't know.  It's unchanged from RFC 4408 right now, but I'd like
> > 
> > other
> > 
> > > 1048576 (which probably isn't).  1*2DIGIT would limit it to 00-99 at
> > 
> > least.
> > 
> > > You could also cover this in prose by saying 1*DIGIT and then in either
> > 
> > an
> > 
> > Maybe import the definitions in
> > http://www.ietf.org/rfc/rfc3986.txtinstead?
> 

I was looking at 3.2.2, which (you are correct) defines IPv4/IPv6, but not CIDR 
(I lost track of which one we were discussing), sorry.

Unfortunately RFC 4632 doesn't have an ABNF.

> > > > > really expect Received-SPF generators to be able to identify and
> > 
> > exclude
> > 
> > > > > malicious data?
> > > > 
> > > > I think you have to.  I've seen people put html pointing to malicious
> > 
> > web
> > 
> > > > sites in SPF records.  Thanks to someone privately pointing this class
> > 
> > of
> > 
> > > It's the "malicious data" part that concerns me because what constitutes
> > 
> > an
> > 

OK.  I'll keep waiting.

Scott K

---

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

>           are neither used in the domain part of email addresses nor

Better.  Could be better still if it weren't one sentence spanning five
lines, but I can live with it.

> don't think we should fix it.

I guess.  I'd rather it be correct, and the operations ADs or DNSDIR review
might pick on this, but maybe not.

> Is it common to justify design decisions like this in the draft of the

In my experience, it's essential, even if it's from the usual location.
"We picked this number as a guess and it seemed to work well" is fine, but
how do we know 15 or 25 wouldn't have been better choices?  We might be
challenged on that if we don't say something.

> Might this be better for sm's write up than the actual draft?

No.  The shepherd writeup would be where he says something like "Consensus
agreed with 20, but there were several people who felt it should be {lower,
higher, random, purple}." It's information for the IESG, but it's not
something your average reader will go and find.

> Unfortunately RFC 4632 doesn't have an ABNF.

So back to my suggestion: What about 1*2DIGIT and 1*3DIGIT?

-MSK

---

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

On Friday, May 17, 2013 11:45:40 AM Murray S. Kucherawy wrote:
> >           ADMDs that wish to declare that no hosts are authorized to use
> > 
> > their
> > 
> >           sessions can publish SPF records that say so for domain names
> > 
> > that
> > 
> >           are neither used in the domain part of email addresses nor
> > 
> > expected
> > 
> >           to originate mail.
> 
> > > > The only temporary errors that turned out to really be permanent that
> > 
> > I've
> > 
> > > As in a server that constantly returns SERVFAIL?  I imagine that just
> > 
> > like
> > 
> > > in any context, a temporary error that's constantly returned is
> > 
> > eventually
> > 
> > > de facto treated as permanent insofar as the client gives up and goes
> > 
> > away.
> > 
> > > > If we were starting from scratch, I'd probably classify many of the
> > 
> > other
> > 
> > > > rcodes as permanent errors, but we aren't.  Absent some evidence of
> > 
> > this
> > 
> > > I think this is an error that warrants correction.  It might be
> > 
> > interesting
> > 

OK.  I'm a bit tired of staring at 4408bis XML at the moment, so when I send 
you the XML, please take a shot at it.

> So back to my suggestion: What about 1*2DIGIT and 1*3DIGIT?

OK.  Please do that too.

Scott K