Subject: [spfbis] Applications Directorate Review of draft-ietf-spfbis-4408bis-19.txt

From: Eliot Lear <[email-masked]>
Date: Sun, 25 Aug 2013 17:13:53 +0200

I have been selected as the Applications Area Directorate reviewer for
this draft (for background on appsdir, please see ​
http://trac.tools.ietf.org/area/app/trac/wiki/ApplicationsAreaDirectorate ).

Please resolve these comments along with any other Last Call comments
you may receive. Please wait for direction from your document shepherd
or AD before posting a new version of the draft.

Document: draft-ietf-spfbis-4408bis-19
Title: Sender Policy Framework (SPF) for Authorizing Use of Domains in
Email, Version 1
Reviewer: Eliot Lear
Review Date: 25 Aug 2013
IETF Last Call Date: 19 Aug 2013
IESG Telechat Date: 12 Sep 2013

Summary: This draft is not yet ready for publication as a Proposed
Standard and should be revised before publication.

Major issues:

1. Deprecation of SPF record not properly justified in text and in the
wrong place

Deprecation of the SPF record is given short shrift in Section 13.1
which is the IANA considerations section.  A persistent reader would not
understand why the record was in fact deprecated.  Here's what is 13.1
(there are a few words about 6686 in 3.1 as well, but nobody would care
if this was simply a matter of low implementation/deployment).

>    Studies have shown that RRTYPE 99 has not seen any substantial use,
>    and in fact its existence and mechanism defined in [RFC4408] has led
>    to some interoperability issues.

First, this text should be moved out of the IANA considerations sections
and forward to Section 3.1.  Second it should explain what those
interoperability issues are or have a normative (and retrievable)
reference.  At the very least, the winning argument(s) should be
elucidated, and not just for posterity: the claim is that there is an
interoperability problem.  If so, then might administrators want to know
that?

The matter of handling garbage in garbage out is not well enough
specified in Section 3.  I would go considerably further and state that
(a) records that do not begin with "v=spf1" MUST NOT be processed
further, and (b) that any record that does not conform to the stated
grammar MUST be ignored.  Also, did the working group consider a
DKIM-like solution?  They all but establish an _spf label in this
document (I'll come to that in a moment).

There is a general issue about when to deprecate an RR and the ability
to add new RRs into the DNS.  That issue has to be addressed in the
longer term, no matter what the IESG and community decide here. 
Furthermore, to be clear, please do not read into the above comments an
opinion about deprecation of the record itself, which I am withholding
until there is clear text about the interoperability issues that are
mentioned.

2.  So-called "Utility Labels"

Throughout the document _spf.example.com is used, as is the term "common
utility labels".  Maybe bind doesn't cough up blood on underscores, but
this is also not what we would call a sanctioned practice by our RFCs. 
If this is truly first use (and I could be wrong), then the utility of
utility labels need to be made clear.  As this is, IMHO, *not* the focus
of this standard, my suggestion would be to change the example.

3.  Retain a summary of changes since 4408.

A -bis document usually has a change list that can assist implementers
familiar with previous work.  Appendix J is pretty close to what I would
want, but it needs some editing.

Minor Issues:

There are areas where the document seems to go to lengths to avoid the
use of normative language.   If either the WG or the IESG cares, I can
go through a few that could stand to be MAYs, but here is but one example:

>    A mail receiver can perform a set of SPF checks for each mail message
>    it receives. 
As I say below, this text actually adds nothing to the document, but if
the author decides to leave it in, this is a prime example of where MAY
was intended to be useful.

Similarly, there is the occasional "ought to", such as that found in
Section 3.  If the WG considered normative text and rejected it, fine. 
But if they didn't, they should.  This is a complex specification, and
our normative language definitions are there to provide clarity and
consistency.

Throughout the document <target-name> is used as the macro expansion of
<domain-spec>.  I don't recommend that.  While much of SPF seems an
exercise in indirection, the actual RFC should not be.  Better to simply
say "<domain-spec> or its macro-expansion."  And no, I wouldn't care
about this in most documents, but the sheer number of forward and
backward references in this document has me (and will have other
readers) constantly flipping backward and forward.

Section 2.2, 1st para

>    Typically, such checks are done
>    by a receiving MTA, but can be performed elsewhere in the mail
>    processing chain so long as the required information is available and
>    reliable
People may infer a traipse through Received headers for HELO
information.  Is that the intent, and is that acceptable, given that
they could be forged?  My point: the above is vague.

Section 2.5: title

> 2.5.  Location of Checks
I don't think you mean location.  I think you mean "When to perform checks".

Section 4.7, 2nd para, 2nd sentence.

>    Although the latter
>    has a default (specifically "?all"), it aids debugging efforts if it
>    is explicitly provided.

How does it aid in debugging?

Section 5.6, ABNF:

You've gone to some lengths to get ipv4 correct, but you don't do the
same with CIDR prefixes.

>    ip4-cidr-length  = "/" 1*DIGIT
>    ip6-cidr-length  = "/" 1*DIGIT
Strictly speaking the value range is from 1 to 32, for v4, and 1 to 128
for v6.  This isn't quite all legal, but at least it's bounded:

    ip4-cidr-length = "/" 1*2DIGIT ; value must be > 0 and may not exceed 32
    ip6-cidr-length = "/" 1*3DIGIT ; value must be > 0 may not exceed 128

You could do the same as you did with qnum, but perhaps that is overkill.

Section 6.2, last para:

The following text is confusing:

>    Note: During recursion into an "include" mechanism, an "exp" modifier
>    from the <target-name> MUST NOT be used.  In contrast, when executing
>    a "redirect" modifier, an "exp" modifier from the original domain
>    MUST NOT be used.

When "MUST NOT be used" do you mean MUST NOT be evaluated or processed
or MUST NOT be present in the record?  e.g., does this MUST apply to
operators, implementers, or both?

Appendix A:

>    This section is normative and any discrepancies with the ABNF
>    fragments in the preceding text are to be resolved in favor of this
>    grammar.
Normally we don't normatively reference Appendices, and it represents a
bit of a cultural cognitive dissidence for some.  One possible fix:
don't make it an Appendix, but the last section.  But also, Section 7.1
is entitled "Formal Specification".  Don't have two of those.

Appendix E:

There's probably a case not covered here, but it's close.  E.1 describes
originating ADMD behavior.  Think of the case of a university or
professional organization that offers forwarding.  The advice given in
the first bullet of E.1 is probably applicable, but requires that a new
whitelist entry be created for new aliases that contain new hosts on the
RHS.  I would go just that bit further to explain.

Nits:

Please stop creating acronyms.  Spam = unsolicited bulk email.  UBE is
obfuscation in this case.  Similarly, I'd ask the authors to trying
speaking out loud "domain owning ADMDs,", expanding out the acronym. 
How about just saying "domain owners"?

In general your definitions section is unnecessarily verbose and could
go for a good "haircut".  For example, how about these:

Imported Definitions:

  * MAIL FROM: The RFC5321.MailFrom, as defined in [RFC5321]
  * HELO: The parameter specified in the HELO or EHLO commands as
    specified in [RFC5321].

Page 7, Section 1.2:

This forward reference is unnecessary, and I would remove the section.

2.1 2nd para, 2nd sentence:

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

That's grammatically incorrect.  Remove everything after "do," and you
are fine.

Same section further down, please clarify "While offline checks are
possible".  I think you mean "deferred" or "checks made after delivery"
or some such.

Section 2.2 first para, first sentence:

>    A mail receiver can perform a set of SPF checks for each mail message
>    it receives. 

What value does this sentence offer the reader?  Personally I say none,
and would remove.

Section 5.4: "mx"

> Then it performs an address lookup on each MX name returned.

To be precise:

"It then performs an address lookup on of the name found in the RDATA of
each answer."

Section 8.5, 2nd sentence:

> The ADMD believes the host is not authorized but is not willing to
> make a strong policy statement

Which ADMD?

Eliot

---

From: S Moonesamy <[email-masked]>
Date: Sun, 25 Aug 2013 08:58:15 -0700

Hello,

I'll comment about the Applications Directorate Review.

At 08:13 25-08-2013, Eliot Lear wrote:
>Summary: This draft is not yet ready for 
>publication as a Proposed Standard and should be revised before publication.
>
>Major issues:
>
>1. Deprecation of SPF record not properly 
>justified in text and in the wrong place
>Deprecation of the SPF record is given short 
>shrift in Section 13.1 which is the IANA 
>considerations section.  A persistent reader 
>would not understand why the record was in fact 
>deprecated.  Here's what is 13.1 (there are a 
>few words about 6686 in 3.1 as well, but nobody 
>would care if this was simply a matter of low implementation/deployment).
>
>First, this text should be moved out of the IANA 
>considerations sections and forward to Section 
>3.1.  Second it should explain what those 
>interoperability issues are or have a normative 
>(and retrievable) reference.  At the very least, 
>the winning argument(s) should be elucidated, 
>and not just for posterity: the claim is that 
>there is an interoperability problem.  If so, 
>then might administrators want to know that?

The above refers to the second paragraph of 
Section 13.1 of draft-ietf-spfbis-4408bis-19.  In 
my opinion the reviewer is correct in his comment 
about the text in IANA Considerations 
Section.  If anyone disagrees with that I suggest 
that the person explains why the text has to be in that section.

Section 3.1 of draft-ietf-spfbis-4408bis-19 mentions that:

   "Use of alternative DNS RR types was supported in SPF's experimental
    phase, but has been discontinued.  See Appendix A of [RFC6686] for
    further information."

The explanation in RFC 6686 is:

    "[SPF] itself included a faulty transition plan, likely because of
     the late addition of a requirement to develop one -- it said:

     An SPF-compliant domain name SHOULD have SPF records of both RR
     types.  A compliant domain name MUST have a record of at least
     one type.

     which means both can claim to be fully compliant while failing
     utterly to interoperate.  Publication occurred without proper
     IETF review, so this was not detected prior to publication."

What is the interoperability issue?

>The matter of handling garbage in garbage out is 
>not well enough specified in Section 3.  I would 
>go considerably further and state that (a) 
>records that do not begin with "v=spf1" MUST NOT 
>be processed further, and (b) that any record 
>that does not conform to the stated grammar MUST be
>  ignored.  Also, did the working group consider 
> a DKIM-like solution?  They all but establish 
> an _spf label in this document (I'll come to that in a moment).

Can the working group please comment about the above?

The working group did not discuss about a 
DKIM-like solution.  There is a thread at 
http://www.ietf.org/mail-archive/web/spfbis/current/msg03963.html

>There is a general issue about when to deprecate 
>an RR and the ability to add new RRs into the 
>DNS.  That issue has to be addressed in the 
>longer term, no matter what the IESG and 
>community decide here.  Furthermore, to be 
>clear, please do not read into the above 
>comments an opinion about deprecation of the 
>record itself, which I am withholding until 
>there is clear text about the interoperability issues that are mentioned.

I'll wait for the working group to comment.

>Throughout the document _spf.example.com is 
>used, as is the term "common utility 
>labels".  Maybe bind doesn't cough up blood on 
>underscores, but this is also not what we would 
>call a sanctioned practice by our RFCs.  If this 
>is truly first use (and I could be wrong), then 
>the utility of utility labels need to be made 
>clear.  As this is, IMHO, not the focus of this 
>standard, my suggestion would be to change the example.

I'll wait for the working group to comment.

>A -bis document usually has a change list that 
>can assist implementers familiar with previous 
>work.  Appendix J is pretty close to what I 
>would want, but it needs some editing.

Scott, can you look into this?

>Minor Issues:
>
>There are areas where the document seems to go 
>to lengths to avoid the use of normative 
>language.  If either the WG or the IESG cares, I 
>can go through a few that could stand to be MAYs, but here is but one example:
>As I say below, this text actually adds nothing 
>to the document, but if the author decides to 
>leave it in, this is a prime example of where MAY was intended to be useful.

I'll wait for the working group to comment.

>Similarly, there is the occasional "ought to", 
>such as that found in Section 3.  If the WG 
>considered normative text and rejected it, 
>fine.  But if they didn't, they should.  This is 
>a complex specification, and our normative 
>language definitions are there to provide clarity and consistency.

The answer I suggest for this one is the restrictions in the charter.

>Throughout the document <target-name> is used as 
>the macro expansion of <domain-spec>.  I don't 
>recommend that.  While much of SPF seems an 
>exercise in indirection, the actual RFC should 
>not be.  Better to simply say "<domain-spec> or 
>its macro-expansion."  And no, I wouldn't care 
>about this in most documents, but the sheer 
>number of forward and backward references in 
>this document has me (and will have other 

I'll wait for the working group to comment.

>People may infer a traipse through Received 
>headers for HELO information.  Is that the 
>intent, and is that acceptable, given that they 
>could be forged?  My point: the above is vague.

I'll wait for the working group to comment.

>>2.5.Â  Location of Checks

I'll wait for the working group to comment.

>Section 5.6, ABNF:
>
>You've gone to some lengths to get ipv4 correct, 
>but you don't do the same with CIDR prefixes.
>
>Strictly speaking the value range is from 1 to 
>32, for v4, and 1 to 128 for v6.  This isn't 
>quite all legal, but at least it's bounded:
>

I suggest considering this change.

>When "MUST NOT be used" do you mean MUST NOT be 
>evaluated or processed or MUST NOT be present in 
>the record?  e.g., does this MUST apply to operators, implementers, or both?

I'll wait for the working group to comment.

>Normally we don't normatively reference 
>Appendices, and it represents a bit of a 
>cultural cognitive dissidence for some.  One 
>possible fix: don't make it an Appendix, but the 
>last section.  But also, Section 7.1 is entitled 
>"Formal Specification".  Don't have two of those.

I suggest moving Appendix A to a section.

>Appendix E:
>
>There's probably a case not covered here, but 
>it's close.  E.1 describes originating ADMD 
>behavior.  Think of the case of a university or 
>professional organization that offers 
>forwarding.  The advice given in the first 
>bullet of E.1 is probably applicable, but 
>requires that a new whitelist entry be created 
>for new aliases that contain new hosts on the 

I'll wait for the working group to comment.

>Nits:
>Please stop creating acronyms.  Spam = 
>unsolicited bulk email.  UBE is obfuscation in 
>this case.  Similarly, I'd ask the authors to 
>trying speaking out loud "domain owning ADMDs,", 
>expanding out the acronym.  How about just saying "domain owners"?
>
>In general your definitions section is 
>unnecessarily verbose and could go for a good 
>"haircut".  For example, how about these:
>
>Imported Definitions:
>MAIL FROM: The RFC5321.MailFrom, as defined in [RFC5321]
>HELO: The parameter specified in the HELO or 
>EHLO commands as specified in [RFC5321].
>
>Page 7, Section 1.2:
>
>That's grammatically incorrect.Â  Remove 
>everything after "do," and you are fine.
>
>Same section further down, please clarify "While 
>offline checks are possible".  I think you mean 
>"deferred" or "checks made after delivery" or some such.
>
>What value does this sentence offer the 
>reader?  Personally I say none, and would remove.
>
>Section 5.4: "mx"
>
>"It then performs an address lookup on of the 
>name found in the RDATA of each answer."
>
>>The ADMD believes the host is not authorized 
>>but is not willing to make a strong policy statement
>
>Which ADMD?

Please comment about the above.

Regards,
S. Moonesamy

---

From: Andrew Sullivan <[email-masked]>
Date: Sun, 25 Aug 2013 12:16:03 -0400

No hat.

> What is the interoperability issue?

I guess the WG sort of hoped that readers would be able to do
elementary entailment for themselves.  It says that two
implementations might follow the same MUST and decide for their own
reasons that the SHOULD cannot be met.  By implication, they could
pick different results of the MUST, and they wouldn't interoperate.

Best,

A

-- 
Andrew Sullivan
[email-masked]

---

From: Andrew Sullivan <[email-masked]>
Date: Sun, 25 Aug 2013 12:23:32 -0400

No hat.

> of this standard, my suggestion would be to change the example.

I don't think I understand this critique, but I think your claim is
that underscores are somehow not scanctioned by RFC.  I think you are
mistaken about this.

Best,

A
-- 
Andrew Sullivan
[email-masked]

---

From: S Moonesamy <[email-masked]>
Date: Sun, 25 Aug 2013 09:39:15 -0700

Hi Andrew,
>No hat.

[snip]

>pick different results of the MUST, and they wouldn't interoperate.

Thanks, I understand what you wrote.  I think what the APPSDIR 
reviewer is asking for is to document the issue so that an 
administrator can understand the interoperability problem.  As an 
alternative I suggest explaining it in terms of SPF publisher and SPF verifier.

Regards,
S. Moonesamy

---

From: "John Levine" <[email-masked]>
Date: 25 Aug 2013 17:58:24 -0000

[ I'm breaking this up into separate messages so there can be separate threads ]

>>deprecated.

I don't understand the issue.  It has always been my impression that
the point of a standards track RFC is to tell readers how to implement
the spec so it'll interoperate, not to document the history of how it
got there.  Five years from now, it's hard to imagine that people
reading the RFC will want to know about the current food fight.  Or if
they do, that's why we have mailing list archives.

I agree that the discussion would better be in the appendix about
post-4408 changes, perhaps with a sentence noting that 4408 had
inconsistent instructions about publishing and checking type 99
records, which would have caused interop problems if anyone had
actually followed them.

R's,
John

---

From: "John Levine" <[email-masked]>
Date: 25 Aug 2013 18:09:36 -0000

>>ignored.

The (a) part is in there now, or if it's not, that's what the wording
is supposed to mean. (Actually, it's "v=spf1 " with a following
space.)

The (b) is more of a can of worms than you might think.  Many
implementations interpret SPF records incrementally and stop as soon
as they have a result.  If there are syntax errors farther along, or
in included records referenced farther along, they don't care and
often don't even notice.

This change would likely present an interop issue by requiring changes
in behavior by systems using existing libraries that interpret SPF
incrementally, which I think is most of them.  Standards don't usually
offer detailed advice about what to do if the other end screws up, and
I don't see any reason to do that here.  If you want to interoperate,
publish correct SPF.  If you don't, you take your chances.

R's,
John

---

From: "John Levine" <[email-masked]>
Date: 25 Aug 2013 18:31:58 -0000

>> Also, did the working group consider 

>>standard, my suggestion would be to change the example.

To the first part, Scott says they considered an _spf prefix back in
2003 and rejected it because a decade ago too much provisioning
crudware choked on underscores.  That problem is long gone, but
changing the initial lookup name now would be a huge and extremely
incompatible change both to the spec and to existing practice.  It's
true that some SPF records redirect to _spf.name, but most don't, or
include multiple names with various names and prefixes.  See the SPF
for google.com and hotmail.com for examples.

As far as underscored names not being sanctioned, I don't understand
that at all.  Underscores aren't valid in hostnames, but they are
entirely valid and widely used in non-host names.  I suppose it might
be worth mentioning that the targets of include: and redirect= need
not be hostnames, and if the target name isn't intended to be one that
sends mail, it's better if it's not.

R's,
John

PS: Re changes to the spec and to practice, deprecating type 99 is a
somewhat significant change to the spec, but an insignificant change
to existing practice because everyone publishes and checks TXT now.
Nobody checks _spf.<name> now.

---

From: S Moonesamy <[email-masked]>
Date: Sun, 25 Aug 2013 11:40:21 -0700

Hi John,
>  [ I'm breaking this up into separate messages so there can be 

Thanks, it makes the discussion easier.

>records, which would have caused interop problems if anyone had

The depreciation of SPF RR is a bit convoluted.  The SPF 
specification is no longer using SPF RR.  Section 13.1 is the 
requested IANA action to mark it as obsolete.  The working group does 
not have text in other sections of the draft to explain why the SPF 
RR is no longer needed.  What Eliot may be saying is to have some 
text in another section about that.

The interoperability problem could be separated from the depreciation 
of the SPF record.  The explanation could be in an appendix.

Regards,
S. Moonesamy

---

From: "John Levine" <[email-masked]>
Date: 25 Aug 2013 18:41:24 -0000

>> etc.

I agree that the document is not fabulously written, inheriting that
problem from 4408, but we had significant concerns about rewrites
changing the semantics.  I'd be willing to take a whack at it, but
it's hard to do and not run the risk of screwing something up.

>>could be forged?  My point: the above is vague.

A typical example would be a delivery-time filter like spamassassin
looking at the topmost Received: applied by the local MTA which is
known to be real.  I don't recall anyone else finding this section
confusing, and it reflects existing practice.

>>You could do the same as you did with qnum, but perhaps that is overkill.

That would be an incompatible change.  What's wrong with this?

  ip4:1.2.3.0/00024

R's,
John

---

From: S Moonesamy <[email-masked]>
Date: Sun, 25 Aug 2013 12:11:18 -0700

Hi John,
>sends mail, it's better if it's not.

It would be an incompatible change.  The other part of the issue is 
that the document uses "_spf.example.com" in the examples.  If too 
many provisioning systems choked on underscores it is questionable 
why it was used in examples.  There is a note that refers to a label 
with an underscore prefix as a common utility labels.  I read that as 
saying that the "utility label" was in common use.

>Nobody checks _spf.<name> now.

Ok.

Regards,
S. Moonesamy

---

From: "John R Levine" <[email-masked]>
Date: 25 Aug 2013 15:14:28 -0400

> It would be an incompatible change.  The other part of the issue is that the 
> document uses "_spf.example.com" in the examples.  If too many provisioning 
> systems choked on underscores it is questionable why it was used in examples.

It always worked in the DNS, and it always worked if you weren't stuck 
with cruddy provisioning software.  I suppose we could change the examples 
to something else, but I still don't understand what problem that would 
solve.

Again, I don't see much use in putting 2003 history in a 2013 standards 
track document.

Regards,
John Levine, [email-masked], Taughannock Networks, Trumansburg NY
"I dropped the toothpaste", said Tom, crestfallenly.

---

From: Andrew Sullivan <[email-masked]>
Date: Sun, 25 Aug 2013 15:23:39 -0400

No hat.

On Sun, Aug 25, 2013 at 03:14:28PM -0400, John R Levine wrote:

> It always worked in the DNS

This is a key point, and I do not think that the SPFBIS WG is a place
to reiterate the STD13 point that labels are supposed to be bags of
octets (modulo the issue of case handling, which is admittedly a mess).  

A

-- 
Andrew Sullivan
[email-masked]

---

From: Dave Crocker <[email-masked]>
Date: Sun, 25 Aug 2013 13:24:09 -0700

These are meant as targeted responses, rather than to the review in general:

On 8/25/2013 8:13 AM, Eliot Lear wrote:
> understand why the record was in fact deprecated.

This is confusing.  These are specifications, not historical 
explanations.  IETF specifications /permit/ far more commentary than do 
most standards groups' documents. However the degree of expectation -- 
nevermind requirement -- for extended rationale about choices that is 
being called for here does not match my sense of what is typical for 
IETF specifications.

Can you provide some pointers to recent exemplars that match what you 
are calling for?

> utility labels".

Perhaps my search function is off, but I'm only finding one occurrence 
of "common utility labels".

> Maybe bind doesn't cough up blood on underscores, but

Use of underscores is not sanctioned?  Huh?

It's been a standardized practice for more than 10 years.  See SRV.

If you mean something else, what is it?

> was intended to be useful.

Probably not.  It has nothing to do with interoperability.  It is, in 
fact, purely advisory text about possible use.  As such, it's actually 
rather important that it /not/ use normative language.

(The text does need to be clear about the line between normative and 
advisory text, of course.)

d/

-- 
Dave Crocker
Brandenburg InternetWorking
bbiw.net

---

From: Scott Kitterman <[email-masked]>
Date: Sun, 25 Aug 2013 16:27:14 -0400

>of the SPF record.  The explanation could be in an appendix.

We did discuss this point and concluded it didn't belong in 4408bis.

Scott K

---

From: Mark Andrews <[email-masked]>
Date: Mon, 26 Aug 2013 07:15:24 +1000

> pick different results of the MUST, and they wouldn't interoperate.

Actually they do interoperate with the set they DECIDE to interopate
with.

This comes done to not letting people live with the consquences of
their actions.  There is NOTHING wrong with someone deciding they
don't want to interoperate with EVERYONE.  Truly.  There are very
clear instruction in 4408 about what SHOULD happen.  Not following
a SHOULD has always has the risk of breaking something.  In this
case you don't get to stop quite as much forged email.

Everybody has the choice to decide if they want to interoperate with
everyone.

This is and always has been a NON PROBLEM.  A non problem which when
trying to "fix" causes real problems elsewhere.

Mark

> Best,
> 
> A
> 
> -- 
> Andrew Sullivan
> [email-masked]
> _______________________________________________
> spfbis mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/spfbis
-- 
Mark Andrews, ISC
1 Seymour St., Dundas Valley, NSW 2117, Australia
PHONE: +61 2 9871 4742                 INTERNET: [email-masked]

---

From: Pete Resnick <[email-masked]>
Date: Sun, 25 Aug 2013 16:44:51 -0500

> 2.  So-called "Utility Labels"

Eliot, I would like to hear some followups to the folks who have posted 
so far before more folks pile on. I'm hearing for the two above major 
issues:

On 1: Others have said that the document already points to 6686 where 
quite a bit of justification is made, and in any event the present 
document isn't the correct place for such justifications. Also, folks 
have said that the document already says that syntactically incorrect 
records will fail processing (with a "permerror" -- see section 4.6).

On 2: Folks have said that you are incorrect about underscore in labels 
being a problem as they are already widely used (e.g. SRV).

Were your comments misunderstood?

I'm not sure why major issue 3 is "major", but I think the WG can 
consider it (if it has not already) like some of the other things you've 
mentioned.

But like I said, before more people respond on the first two, I'd like 
to understand what you mean.

pr

-- 
Pete Resnick<http://www.qualcomm.com/~presnick/>
Qualcomm Technologies, Inc. - +1 (858)651-4478

---

From: Eliot Lear <[email-masked]>
Date: Sun, 25 Aug 2013 21:51:19 +0200

You're correct.  For some reason I thought they were reserved.

Eliot

---

From: S Moonesamy <[email-masked]>
Date: Sun, 25 Aug 2013 15:26:46 -0700

Hi Mark,
>trying to "fix" causes real problems elsewhere.

The problem is when the text in Section 3.1.1 is read with:

   'In accordance with how the records are published (see Section 3.1
    above), a DNS query needs to be made for the <domain> name, querying
    for either RR type TXT, SPF, or both.'

Regards,
S. Moonesamy

---

From: Mark Andrews <[email-masked]>
Date: Mon, 26 Aug 2013 08:42:03 +1000

> is supposed to mean. (Actually, it's "v=spf1 " with a following

It is a record consisting of "v=spf1" only or a record starting with
"v=spf1 ".

This is from 4408 and if it has change in the draft it is a introduced
iteroperabilty problem.  I'm offline so I can't check the draft.

   1. Records that do not begin with a version section of exactly
      "v=spf1" are discarded.  Note that the version section is
      terminated either by an SP character or the end of the record.  A
      record with a version section of "v=spf10" does not match and must
      be discarded.

It would also be useful to specify "case insensitive" to reinforce that
all of the record is case insensitive.

---

From: "John R Levine" <[email-masked]>
Date: 25 Aug 2013 19:48:31 -0400

> iteroperabilty problem.  I'm offline so I can't check the draft.

The ABNF hasn't changed, I was wrong about the space, which is only needed 
is there's something following.

> all of the record is case insensitive.

That's implicit in the ABNF.

R's,
John

---

From: S Moonesamy <[email-masked]>
Date: Sun, 25 Aug 2013 16:49:50 -0700

Hi Eliot,
>Standard and should be revised before publication.

I'll respond to part of the comments.

The SPFBIS WG has a tightly-scoped charter.  Suggested changes to RFC 
2119 keywords, for example, were carefully considered.  One of the 
problems was the way RFC 4408 was written.  draft-ietf-spfbis-4408bis 
is not a complete rewrite of RFC 4408.  The clarifications were kept 
as narrow as possible.

[snip]

>the stated grammar MUST be ignored.  Also, did the working group 
>consider a DKIM-like solution?  They all but establish an _spf label 
>in this document (I'll come to that in a moment).

There is a thread at 
http://www.ietf.org/mail-archive/web/spfbis/current/msg03964.html 
about the "_spf" prefix.  I went over some of the messages posted 
during the WG charter discussion to see whether the WG could have 
considered a DKIM-like solution.  In my opinion it would be out-of-scope.

>Throughout the document _spf.example.com is used, as is the term 
>"common utility labels".  Maybe bind doesn't cough up blood on 
>underscores, but this is also not what we would call a sanctioned 
>practice by our RFCs.  If this is truly first use (and I could be 
>wrong), then the utility of utility labels need to be made 
>clear.  As this is, IMHO, not the focus of this standard, my 
>suggestion would be to change the example.

There is a thread at 
http://www.ietf.org/mail-archive/web/spfbis/current/msg03996.html in 
response to your review.  The "Utility labels" is a note in the 
draft.  _spf.example.com was used in RFC 4408 for some examples and 
the text is similar in the draft.  My reading of the message at 
http://www.ietf.org/mail-archive/web/apps-discuss/current/msg10272.html 
is that the examples do not have to be changed (re. not sanctioned by RFC).

>A -bis document usually has a change list that can assist 
>implementers familiar with previous work.  Appendix J is pretty 
>close to what I would want, but it needs some editing.

Did you mean merging some of Appendix J into Appendix C?

>Minor Issues:
>
>There are areas where the document seems to go to lengths to avoid 
>the use of normative language.   If either the WG or the IESG cares, 
>I can go through a few that could stand to be MAYs, but here is but 
>one example:
>As I say below, this text actually adds nothing to the document, but 
>if the author decides to leave it in, this is a prime example of 
>where MAY was intended to be useful.

Please refer to my opening comment.

>Section 3.  If the WG considered normative text and rejected it, 
>fine.  But if they didn't, they should.  This is a complex 
>specification, and our normative language definitions are there to 
>provide clarity and consistency.

The SPFBIS WG considered whether having the normative text was within 
scope.  I agree with your argument about clarity and 
consistency.  The document shepherd review is at 
http://www.ietf.org/mail-archive/web/spfbis/current/msg03414.html I 
did a pass of the RFC 2119 keywords and compared them against what is 
in RFC 4408.  Adding normative language can entail a significant 
rewrite of the draft.  It can create incompatible changes.  As you 
mentioned this is a complex specification and significant changes 
would require a level of review beyond what has been done up to now 
to achieve better clarity and consistency.  This draft has been a 
significant effort.  I'll leave it to the IESG to assess whether 
asking the SPFBIS WG to go beyond that is doable.

Thanks for the careful review.

Regards,
S. Moonesamy

---

From: Mark Andrews <[email-masked]>
Date: Mon, 26 Aug 2013 10:53:01 +1000

In message <[email-masked]>, S Moonesamy writes
>     for either RR type TXT, SPF, or both.'
 
Again there is no problem.  Because if your read the entire document
it is clear that one is migrating from TXT to SPF.  Note the wording
didn't stop spf library developers adding SPF lookups.  Sure the
wording could have been stronger.

I read "In accordance with" to put a SHOULD in SPF lookup and a MAY on
TXT lookup only / both lookup.

Mark

---

From: Scott Kitterman <[email-masked]>
Date: Mon, 26 Aug 2013 00:13:31 -0400

> want, but it needs some editing.

That's what Appendix C is meant to accomplish.  Appendix J is not meant to be 
included in the final document.  As far as I've noticed, the items that aren't 
listed in Appendix C that are in Appendix J don't directly affect implementers.  
Is there something specific missing from Appendix C?

Scott K

---

From: Scott Kitterman <[email-masked]>
Date: Mon, 26 Aug 2013 00:16 -0400

> You could do the same as you did with qnum, but perhaps that is overkill.

Would someone with a fully ABNF enabled brain comment on this suggestion 
please?  Seems reasonable to me.

Scott K

---

From: Dave Crocker <[email-masked]>
Date: Sun, 25 Aug 2013 21:18:38 -0700

> please?  Seems reasonable to me.

offhand, seems reasonable to me too, although I'd probably do the 
comment more tersely:

       ip4-cidr-length = "/" 1*2DIGIT ; value range 1-32
       ip6-cidr-length = "/" 1*3DIGIT ; value range 1-128

d/

---

From: "John Levine" <[email-masked]>
Date: 26 Aug 2013 04:24:47 -0000

>please?  Seems reasonable to me.

Are these valid?

  ip4:1.2.3.0/0024 ip6:1111:2222:3333:4444::/0064

If so, the current ABNF is fine and the suggested stuff isn't, other
than perhaps adding the comments about the value ranges.

R's,
John

---

From: Scott Kitterman <[email-masked]>
Date: Mon, 26 Aug 2013 00:31:20 -0400

> than perhaps adding the comments about the value ranges.

I wouldn't have thought they were valid.  In pyspf, which is most convenient 
for me to quickly check, they both cause a permerror.  

Scott K

---

From: "John Levine" <[email-masked]>
Date: 26 Aug 2013 04:39:51 -0000

>  ip4:1.2.3.0/0024 ip6:1111:2222:3333:4444::/0064

I looked at the code in libspf2 spf_compile.c, and it looks to me like
it accepts any integer string after the slash, then checks the value
to be sure it's in the 0-32 or 0-128 range.

So the current ABNF matches the code, and the suggested change doesn't.

R's,
John

---

From: "John Levine" <[email-masked]>
Date: 26 Aug 2013 04:57:48 -0000

>for me to quickly check, they both cause a permerror.  

I looked at pyspf and the regexp it uses to match a CIDR doesn't match
the current ABNF.

The current ABNF is:

Its pattern matches approximately this:

   ip4-cidr-length  = "/" ("0" |  %x31-39 0*DIGIT)

That is, the number after the slash has to be 0, or start with a
non-zero.  It uses the same pattern for ip4 and ip6 CIDRs, and range
checks the values later.

So now we have the existing ABNF and libspf2, which match.  Then we
have pyspf and the proposed ABNF, which are both different from the
existing ABNF in different ways.

I suggest we leave it alone, other than perhaps adding the comment
about allowed values.

R's,
John

---

From: Eliot Lear <[email-masked]>
Date: Mon, 26 Aug 2013 07:44:20 +0200

On 8/25/13 11:44 PM, Pete Resnick wrote:
>
> Eliot, I would like to hear some followups to the folks who have
> posted so far before more folks pile on. I'm hearing for the two above
> major issues:
>

The reference is to Appendix A.  Unfortunately, the text there doesn't
go far enough.  All it says is:
>    4.  [SPF] itself included a faulty transition plan, likely because of
>        utterly to interoperate.

This reads as if somehow a record is a protocol.  What I would suggest
(at the very least) is the following:

"Because ADMDs have in the past published either SPF or TXT records, and
because some MTAs query for only one or the other, it is possible that
an MTA will not find a published record.  When both records are
published it is possible for them to differ."

I *think* these are the interoperability issues (I can't say because
6686 isn't clear).

Because we know people are querying SPF records (there is ample
empirical evidence), the text could even go further and say something
like this:

"While we are deprecating the SPF record, any ADMD that continues to
publish an SPF record at this point MUST also publish the semantically
equivalent TXT record."  I don't know of instances in the wild where
this was a problem, and if it wasn't then this isn't really an
interoperability issue worth considering.  That goes to a more
substantial debate about whether the record should be deprecated. 
Again, I'm not taking a position about that here.

There is matching text for MTAs: "MTAs MUST NOT query for RRTYPE 99
records."  The text ALMOST says that in Section 4.4 and again in 13.2,
but for some reason stops short.  This goes to my other issue, that
normative language is not appropriately used.

>
> On 2: Folks have said that you are incorrect about underscore in
> labels being a problem as they are already widely used (e.g. SRV).

I withdraw that issue.  See exchange between Andrew, John and me.
> consider it (if it has not already) like some of the other things
> you've mentioned.

It's in Appendix C.  I was looking at Appendix J.  Withdrawn.

Eliot

---

From: S Moonesamy <[email-masked]>
Date: Sun, 25 Aug 2013 22:52:24 -0700

Hi John,
>I suggest we leave it alone, other than perhaps adding the comment

Thanks for the effort to help address the issues.

The current ABNF is:

Based on what you wrote I'll suggest:

   ip4-cidr-length  = "/" 1*DIGIT ; value range 1-32
   ip6-cidr-length  = "/" 1*DIGIT ; value range 1-128

I am not trying to address the question mentioned in the message at 
http://www.ietf.org/mail-archive/web/spfbis/current/msg04015.html

Dave Crocker suggested:

I'll have to explain the choice to Eliot.  Could you make the choice?

Regards,
S. Moonesamy

---

From: S Moonesamy <[email-masked]>
Date: Sun, 25 Aug 2013 23:01:17 -0700

Hi Eliot,
At 22:44 25-08-2013, Eliot Lear wrote:
>The reference is to Appendix A.  Unfortunately, the text there 
>doesn't go far enough.  All it says is:
>This reads as if somehow a record is a protocol.  What I would 
>suggest (at the very least) is the following:

Yes, that text might be read in different ways.  Your review brought 
a fresh perspective to the discussion.  I'll ask the SPFBIS WG about the text.

>I withdraw that issue.  See exchange between Andrew, John and me.

I'll list Issue 2 ( 
http://www.ietf.org/mail-archive/web/apps-discuss/current/msg10270.html 
) as addressed.

>It's in Appendix C.  I was looking at Appendix J.  Withdrawn.

I'll list Issue 3 ( 
http://www.ietf.org/mail-archive/web/apps-discuss/current/msg10270.html 
) as addressed.

Regards,
S. Moonesamy (as document shepherd)

---

From: S Moonesamy <[email-masked]>
Date: Sun, 25 Aug 2013 23:15:35 -0700

At 22:44 25-08-2013, Eliot Lear wrote:

>>posted so far before more folks pile on. I'm hearing for the two 
>>above major issues:
>>
>>On 1: Others have said that the document already points to 6686 
>>where quite a bit of justification is made, and in any event the 
>>present document isn't the correct place for such justifications. 
>>Also, folks have said that the document already says that 
>>syntactically incorrect records will fail processing (with a 
>>"permerror" -- see section 4.6).
>
>"Because ADMDs have in the past published either SPF or TXT records, 
>and because some MTAs query for only one or the other, it is 
>possible that an MTA will not find a published record.  When both 
>records are published it is possible for them to differ."
>

The suggested text (Because ADMDs) looks okay to me, minus the "MTA" 
term.  Would the working group be okay with retaining that with some 
minor editing?

>empirical evidence), the text could even go further and say 
>something like this:
>
>publish an SPF record at this point MUST also publish the 
>semantically equivalent TXT record."  I don't know of instances in 
>the wild where this was a problem, and if it wasn't then this isn't 
>really an interoperability issue worth considering.  That goes to a 
>more substantial debate about whether the record should be 
>deprecated.  Again, I'm not taking a position about that here.
>
>records."  The text ALMOST says that in Section 4.4 and again in 
>13.2, but for some reason stops short.  This goes to my other issue, 
>that normative language is not appropriately used.

Can the working group suggest what to do about this part?

Regards,

---

From: Scott Kitterman <[email-masked]>
Date: Mon, 26 Aug 2013 08:51:11 -0400

> I suggest we leave it alone, other than perhaps adding the comment

Here's my suggestion:

   ip4-cidr-length  = "/" 1*DIGIT ; value range 1-32
   ip6-cidr-length  = "/" 1*DIGIT ; value range 1-128
   dual-cidr-length = [ ip4-cidr-length ] [ "/" ip6-cidr-length ]
            ; Avoid leading zeros in cidr-lengths since not all
            ; implementations recognize them as valid.

Does that work?  My intent there is to make libspf2 correct, but warn about 
more strict implementations.

Scott K

---

From: Hector Santos <[email-masked]>
Date: Mon, 26 Aug 2013 08:55:09 -0400

Hi Eliot,

I appreciate your review of SPFBIS.  I only have a few small input 
bits to provide:

> Standard and should be revised before publication.

+1

> grammar MUST be ignored.  

I think the documentation usage of the term "SPF record" can be 
confusing if the type99 is going to be removed.  It can suggest that 
this "SPF record" is unique and is not residing with other "records."

I think the term should be more specific to say the SPF TXT resultant 
record contains multiple EOL (CRLF or CR or LF terminators) strings 
and and only a string beginning with the *token* "v=spf1" is a 
considered a SPF record string.   In theory, the parser should 
tokenizing it to check for "v=" and then only process the v= value "spf1"

Perhaps a more specific term such as "SPF Line Record" or String would 
be clearer.

> Also, did the working group consider a

Yes. It was but I didn't think it was taken serious. I can see now the 
draft was leaning towards to publishing method.  My particular concern 
with this is that it also yields a TXT/TXT dual call waste and high 
redundancy if it doesn't become a learned processed (a domain is known 
to use _spf. zone).

In other words, for large ESP using this method, it will yield a very 
high overhead in at least TWO TXT lookups. Keep in mind one of the 
SPF99/TXT concerns is the wasted SPF99 call.

> until there is clear text about the interoperability issues that are

+1.

--
HLS

---

From: Scott Kitterman <[email-masked]>
Date: Mon, 26 Aug 2013 09:03:39 -0400

> term.  Would the working group be okay with retaining that with some

I think we discussed this before and, as several people have re-iterated, 
concluded that 4408bis wasn't the place to document the rationale for this 
decision.  I don't understand what problem adding the text solves?  If we need 
to go back and add rationale for all the changes we made, it's going to delay 
the document significantly for, IMO, no good purpose.  If we aren't, then I 
don't think this change deserves to be treated differently.

> Can the working group suggest what to do about this part?

We aren't deprecating type SPF.  We're removing it from the protocol.  We did 
discuss this.  IIRC, we had something very like MUST NOT publish, MUST NOT 
query ..., but removed it in favor of just removing type SPF from the protocol 
description.  I think it might be reasonable to be more verbose in Appendix C, 
which currently says:

   o  Use of DNS RR type SPF (99) has been removed from the protocol,
      see [RFC6686] for background.

Personally, I think it's accurate and succinct and I'm not sure what to change 
that would amount to the same thing in a lot more words.  To me, ... has been 
removed ... . .... MUST NOT query ... . ... MUST NOT publish ... . Is 
redundant, but I don't strongly object if people think it would be better.

Scott K

---

From: "John R Levine" <[email-masked]>
Date: 26 Aug 2013 10:27:41 -0400

This seems to match the least badly:

>  ip4-cidr-length  = "/" 1*DIGIT ; value range 0-32
>  ip6-cidr-length  = "/" 1*DIGIT ; value range 0-128

Although it doesn't explicitly say so in 4408 or the current draft, both 
pyspf and libspf2 accept /0 and treat it as equivalent to /32 or /128.

Regards,

---

From: Dave Crocker <[email-masked]>
Date: Mon, 26 Aug 2013 07:32:52 -0700

> pyspf and libspf2 accept /0 and treat it as equivalent to /32 or /128.

1. Why don't you like specifying the limit on number of digits?  I think 
it makes the rule more informative to the reader, as well as creating a 
slightly more accurate parser.

2. I had wondered about permitting zero, so that change makes sense to me.

d/

---

From: Scott Kitterman <[email-masked]>
Date: Mon, 26 Aug 2013 10:41:40 -0400

> pyspf and libspf2 accept /0 and treat it as equivalent to /32 or /128.

I just checked pyspf 2.0.7 and 2.0.8 and they both accept /0 and will match it 
to anything.  If I am reading RFC 4632 correctly, that's expected behavior.

I don't expect /0 to be particularly useful, but I think it's not technically 
wrong.

Scott K

---

From: "Murray S. Kucherawy" <[email-masked]>
Date: Mon, 26 Aug 2013 08:15:24 -0700

> 2. I had wondered about permitting zero, so that change makes sense to me.
I concur:  I like 1*2DIGIT and 1*3DIGIT, with a range that includes 0.

-MSK

---

From: "John Levine" <[email-masked]>
Date: 26 Aug 2013 15:36:10 -0000

>slightly more accurate parser.

Installed base.  But I took a look at perl Mail::SPF which I think is
more widely used than pyspf, since it's what spamassassin uses to do a
SPF check.

It also has code to prohibit leading zeros, so it looks like the best match
to the installed base is this:

   ip4-cidr-length  = "/" ("0" |  %x31-39 0*DIGIT) ; value range 0-32

   ip6-cidr-length  = "/" ("0" |  %x31-39 0*DIGIT) ; value range 0-128

Even though 0*DIGIT doesn't explicitly limit the number of digits, the
value range does it for you, and that's how pyspf and Mail::SPF do it.

R's,
John

---

From: Tony Hansen <[email-masked]>
Date: Mon, 26 Aug 2013 11:37:34 -0400

On 8/26/2013 10:27 AM, John R Levine wrote:
> Although it doesn't explicitly say so in 4408 or the current draft,
> both pyspf and libspf2 accept /0 and treat it as equivalent to /32 or
> /128.

RFC 4632 section 3.1 specifically allows 0. It's not taken as equivalent
to /32|/128, but instead as a complete wildcard for the address.

    Tony

---

From: Dave Crocker <[email-masked]>
Date: Mon, 26 Aug 2013 08:41:52 -0700

> value range does it for you, and that's how pyspf and Mail::SPF do it.

1. 0* means that there can be /no/ digits.  However in the context the 
rule is used, there must be at least one digit.  Otherwise, for example, 
you could get 1.2..3

2. I don't understand why you are resisting an iteration count that 
matches the actual number of digits appropriate for each address type.

3. Other elaborations, such as prohibiting leading zeroes, sound fine.

d/

---

From: S Moonesamy <[email-masked]>
Date: Mon, 26 Aug 2013 11:35:26 -0700

Hi Scott,

I am adding back the Cc so that someone who has not provided input 
might be able to comment.

>don't think this change deserves to be treated differently.

If I understood the review, the argument is about an explanation for 
the administrator.    The reviewer is not asking for a rationale for 
all the changes which was made.  This is about Issue 1 only.  I only 
need to address the review.  I can go with "4408bis is not the place 
to document the rationale".

>redundant, but I don't strongly object if people think it would be better.

Yes.  I'll wait a day before closing this one.

Regards,

---

From: Ángel <[email-masked]>
Date: Mon, 26 Aug 2013 23:17:03 +0200

> Perhaps a more specific term such as "SPF Line Record" or String would 

However, there could be one TXT record with embedded line breaks. I
don't think a spf parser should try to extract that.

---

From: Ángel <[email-masked]>
Date: Mon, 26 Aug 2013 23:31:09 +0200

> more strict implementations.

I think the right way would be to use this grammar:

   ip4-cidr-length  = "/" 1*2DIGIT / obs-cidr-length ; value range 0-32
   ip6-cidr-length  = "/" 1*3DIGIT / obs-cidr-length ; value range 0-128
   obs-cidr-length  = "/" 1*DIGIT

and declare in the text that the cidr length MUST not be written with
leading digits, obsoleting the 4408 syntax which allowed them.

The use of obs- prefix for obsoleted tokens is common on other RFC (eg.
rfc5322 section 3.1).

---

From: S Moonesamy <[email-masked]>
Date: Mon, 26 Aug 2013 14:37:09 -0700

Hi Angel,
>The use of obs- prefix for obsoleted tokens is common on other RFC (eg.

Thanks for suggesting a fix for the ABNF.

On what grounds would obsoleting the 4408 syntax be allowed?

I am asking the question as an explanation is needed for such a change.

Regards,

---

From: Scott Kitterman <[email-masked]>
Date: Mon, 26 Aug 2013 18:13:23 -0400

> I am asking the question as an explanation is needed for such a change.

Multiple implementations use the more strict construction, so it would, I 
think, make sense to specify it more tightly so that record publishers don't 
publish records that we know won't be fully interoperable.  I don't think I 
like this one any better than what we were already discussing.

Scott K

---

From: "John Levine" <[email-masked]>
Date: 26 Aug 2013 23:12:00 -0000

>> >leading digits, obsoleting the 4408 syntax which allowed them.

This seems unduly messy.

Now that I've lookeed at Mail::SPF and pyspf, I see that leading zeros
have never worked.  The obs- stuff means that new code has to support
leading zeros for backward compatibility, which just seems wrong.

This describes what actually works now, and what I think people want the
spec to be:

   ip4-cidr-length  = "/" ("0" |  %x31-39 0*1DIGIT) ; value range 0-32
   ip6-cidr-length  = "/" ("0" |  %x31-39 0*2DIGIT) ; value range 0-128

or equivalently:

R's,
John

---

From: S Moonesamy <[email-masked]>
Date: Mon, 26 Aug 2013 15:57:29 -0700

Hi Scott,
>like this one any better than what we were already discussing.

The ABNF would have to be changed in Section 5.6 and Appendix A.

Are you okay with:

It is specified more tightly without affecting the two 
implementations which John Levine verified.

Regards,

---

From: Scott Kitterman <[email-masked]>
Date: Mon, 26 Aug 2013 19:41:33 -0400

>implementations which John Levine verified.

I'm ok with either this or the one that John just suggested. I'm not an ABNF expert though. Since we have several in the group,  I'd rather they arm wrestle to decide the right answer. 

Scott K

---

From: "John R. Levine" <[email-masked]>
Date: 26 Aug 2013 19:55:18 -0400

>  ip6-cidr-length  = "/" 1*DIGIT ; value range 0-128

No, this is the current ABNF which turns out to be wrong.  It would permit 
1.2.3.0/00024 which pyspf and Mail::SPF don't accept.

I've sent in the correct ABNF three times now.  If someone has specific 
objections to it, I'd appreciate knowing specifically what they are.

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: Dave Crocker <[email-masked]>
Date: Mon, 26 Aug 2013 18:19:56 -0700

>     ip6-cidr-length  = "/" ("0" |  %x31-39 0*2DIGIT) ; value range 0-128

I prefer this form.  I think it provides the most parsing precision and 
the most reader information.  I think all the alternatives (that aren't 
just plain wrong) offer less.

d/

---

From: Scott Kitterman <[email-masked]>
Date: Mon, 26 Aug 2013 21:21:12 -0400

> just plain wrong) offer less.

I sense a tide starting to flow.  Unless people start objecting, I'll go with 
this.

Scott K

---

From: S Moonesamy <[email-masked]>
Date: Mon, 26 Aug 2013 18:21:26 -0700

Hi John,
At 16:55 26-08-2013, John R. Levine wrote:
>I've sent in the correct ABNF three times now.  If someone has 
>specific objections to it, I'd appreciate knowing specifically what they are.

Sorry about that.

I see two alternatives in the message at 
http://www.ietf.org/mail-archive/web/spfbis/current/msg04039.html 
Which one should I use in my response to Eliot's review?

Thanks,

---

From: "John Levine" <[email-masked]>
Date: 27 Aug 2013 01:26:00 -0000

R's,
John

---

From: Tony Hansen <[email-masked]>
Date: Mon, 26 Aug 2013 22:30:10 -0400

+1

    Tony Hansen

---

From: Hector Santos <[email-masked]>
Date: Tue, 27 Aug 2013 12:22:49 -0400

>>   ip6-cidr-length  = "/" ("0" |  %x31-39 0*2DIGIT) ; value range 0-128

To simplify the above and to further codify existing parsers in the 
wild, may I suggest the ABNF be:

   ip4-cidr-length  = "/" [ ip4-cidr-value ]
   ip6-cidr-length  = "/" [ ip6-cidr-value ]
   ip4-cidr-value   = 2*DIGIT  ; value range 0-32
   ip6-cidr-value   = 3*2DIGIT ; value range 0-128

This allows for the possible omission of the alphanumeric after the 
slash. Both RFC4408 & 4408BIS says:

    If ip4-cidr-length is omitted, it is taken to be "/32".  If
    ip6-cidr-length is omitted, it is taken to be "/128".  It is not
    permitted to omit parts of the IP address instead of using CIDR
    notations.  That is, use 192.0.2.0/24 instead of 192.0.2.

What it doesn't say is when the cidr-length is just "/".  My 
suggestion will also codify existing spf processing code where it 
handles SPF mechanism examples such as:

    v=spf1 ip4:192.0.2.2/ -all

The following simple C code will treat this condition with a cidr=0:

    int cidr = 32;  // default per rfc4408 for ip4
    char *slash = strchr(mechanism,'/');

    if (slash) cidr = atoi(slash+1);

and continues with the ip/cidr masking calculation against the 
connecting ip address.

Another could see this as an error:

    if (slash && !strlen(slash+1)) return SPF_IP4_PERMERROR;

or it could probably try to fit the Levine's proposed ABNF a little 
better which checks for a non-blank string:

    if (slash && strlen(slash+1)) cidr = atoi(slash+1);

which would use a cidr=32 as a default perhaps.

So we have three possible parsing possibilities:

    cidr = 0
    cidr = 32 or 128
    return a permanent error

The ABNF should allow for the partial omission of the cidr-length or 
it should be specific to say what should be the default consideration. 
  Levine's proposed ABNF, while technically valid, could enforce an 
error condition for a parser where it is not today.

Overall, these are well tested case scenarios for long time SPF 
parsers. As long as there is no security loophole (and I don't see 
it), I think my proposed change better fits the market place of 
implementations across the board.

Thanks

-- 
HLS

---

From: Hector Santos <[email-masked]>
Date: Tue, 27 Aug 2013 13:05:05 -0400

Small correction with my proposed ABNF:

>    ip6-cidr-value   = 3*2DIGIT ; value range 0-128

should be:

      ip6-cidr-value   = 3*DIGIT ; value range 0-128

-- 
HLS

---

From: Tony Hansen <[email-masked]>
Date: Tue, 27 Aug 2013 13:30:40 -0400

> handles SPF mechanism examples such as:

A cidr-length of just "/" is not permitted by the 4408 ABNF. Any parsers
that follow the 4408 ABNF will reject the bare "/".

Are you saying that there are parsers in the wild that accept already
accept a bare "/", or that there are sites that are using a bare "/" ?

    Tony Hansen

---

From: Scott Kitterman <[email-masked]>
Date: Tue, 27 Aug 2013 13:52:00 -0400

>accept a bare "/", or that there are sites that are using a bare "/" ?

There are not that I'm aware of.

Scott K

---

From: Hector Santos <[email-masked]>
Date: Tue, 27 Aug 2013 15:53:50 -0400

On 8/27/2013 1:30 PM, Tony Hansen wrote:

>> Hector Santos

 From what I can see, our commercial WCSMTP/SPF c/c++ library and 
implementation, it treats it as a cidr=0 rather than return an error 
because of the code shown:

Long ago it was tested again libspf2.  It produces the same masking 
result that was compared with libspf2 output to cover this use case 
scenarios when it was "/0" or "/" from a masking standpoint.  Libspf2 
even has a:

      if (cidr == 0) cidr=32;

check in its IP4 masking function.

I think it should cover all market bases; "/" and "/0" are treat the 
same.

-- 
HLS

---

From: "Murray S. Kucherawy" <[email-masked]>
Date: Tue, 27 Aug 2013 14:00:19 -0700

> accept a bare "/", or that there are sites that are using a bare "/" ?
An IP address followed by a slash and nothing else is a syntax error, both
in the SPF context and the context of CIDR expressions in general.  Even if
there are implementations that tolerate this by effectively applying a
default, I disagree that the ABNF should be changed to allow it.

-MSK

---

From: Scott Kitterman <[email-masked]>
Date: Tue, 27 Aug 2013 17:04:10 -0400

+1.

Scott K

---

From: S Moonesamy <[email-masked]>
Date: Tue, 27 Aug 2013 14:36:29 -0700

>>implementations across the board.

The ABNF suggested by John Levine is technically correct.  The SPFBIS 
working group is supposed to correct errors in the specification.  It 
is going to be extremely difficult to convince Eliot Lear or the 
Routing Area Directors that "192.0.2.2/" is in accordance with CIDR 
notation.  I'll use the technically correct ABNF in my response to Eliot Lear.

Regards,

---

From: Hector Santos <[email-masked]>
Date: Tue, 27 Aug 2013 17:58:58 -0400

On 8/27/2013 5:00 PM, Murray S. Kucherawy wrote:
> in the SPF context and the context of CIDR expressions in general.

A reference would help please for the latter assertion.

> Even if there are implementations that tolerate this by effectively
> applying a default, I disagree that the ABNF should be changed to
> allow it.

It was just changed to satisfy an implementation. Why can't we codify 
it to satisfy existing implementations which do not error and may 
tolerate it?

I mean if we want to look at libspf2, from what I can see, it doesn't 
even like a ABNF valid "/0" and treats it a mask_len = 0  string to 
integer conversion as an SPF_E_INVALID_CIDR error.

SPF_c_parse_cidr_ip4(SPF_response_t *spf_response,
				unsigned char *maskp,
				const char *src)
{
	int		 mask;

	/*
	if (spf_server->debug > 2)
		SPF_debugf("Parsing ip4 CIDR starting at %s", src);
	*/

	mask = strtoul(src + 1, NULL, 10);

	if ( mask > 32 ) {
		return SPF_response_add_error_ptr(spf_response, SPF_E_INVALID_CIDR,
						NULL, src,
						"Invalid IPv4 CIDR netmask (>32)");
	}
	else if ( mask == 0 ) {
		return SPF_response_add_error_ptr(spf_response, SPF_E_INVALID_CIDR,
						NULL, src,
						"Invalid IPv4 CIDR netmask (=0)");
	}
	else if ( mask == 32 ) {
		mask = 0;
	}

	*maskp = mask;

	return SPF_E_SUCCESS;
}

-- 
HLS

---

From: Hector Santos <[email-masked]>
Date: Tue, 27 Aug 2013 18:15:09 -0400

On 8/27/2013 5:36 PM, S Moonesamy wrote:
> notation.

Can we reference a CIDR notation guide/RFC?

> I'll use the technically correct ABNF in my response to
> Eliot Lear.

 From what I see, its not technically correct and currently reflective 
of all the parsers.  Not all parsers will treat it as an error and 
LibSPF2 will in fact, treat the ABNF correct "/0" as an error as well. 
  According to the libSPF2 web site, the following packages use 
LIBSPF2: Sendmail, Postfix, Exim, Zmailer and MS Exchange.   Are they 
now not compliant packages?

At the very least, it should be tolerated  "/" == "/0"  or describe 
this exception just like the short circuits exception is currently 
described (not allowed):

       It is not permitted to omit parts of the IP address
       instead of using CIDR notations.  That is, use
       192.0.2.0/24 instead of 192.0.2.

-- 
HLS

---

From: Mark Andrews <[email-masked]>
Date: Wed, 28 Aug 2013 08:38:52 +1000

> it to satisfy existing implementations which do not error and may 

Because it looks likes and is a error.

If SPF_c_parse_cidr_ip4 is supposed to be checking src is a valid
prefix length well it doesn't as the coding is sloppy.

% cat lllll.c 
#include <stdio.h>
#include <stdlib.h>

int main() {
        long mask;
        char src[] ="/xxxx";

        mask = strtoul(src + 1, NULL, 10);
        printf("mask=%lu\n", mask);
}
% cc lllll.c
% ./a.out
mask=0
%

---

From: S Moonesamy <[email-masked]>
Date: Tue, 27 Aug 2013 15:47:35 -0700

Hi Hector,
>Can we reference a CIDR notation guide/RFC?

There is already a reference to RFC 4632.

> From what I see, its not technically correct and currently 
> reflective of all the parsers.  Not all parsers will treat it as an 
> error and LibSPF2 will in fact, treat the ABNF correct "/0" as an 
> error as well.  According to the libSPF2 web site, the following 
> packages use LIBSPF2: Sendmail, Postfix, Exim, Zmailer and MS 
> Exchange.   Are they now not compliant packages?

I don't have an opinion about compliance.  I'll have to read the code 
again to determine whether there may be an interoperability issue.

>       192.0.2.0/24 instead of 192.0.2.

The IESG will comment about the issue if what I mentioned is not 
technically correct as its members will be reviewing the specification.

In my personal opinion it's not worthwhile to get into that level of 
detail (see text from the draft).  It's the working group opinion 
that matters as it will be up to it to discuss the text with the IESG 
if there is a DISCUSS.

Regards,

---

From: Scott Kitterman <[email-masked]>
Date: Tue, 27 Aug 2013 19:02:01 -0400

>now not compliant packages?

At least with Sendmail and Postfix, it's not common to use it.  There are alternatives. 
At worst, it may fail to detect a few record errors.  If that's"non-compliant", then I guess so, but it's a minor bug.  We shouldn't write standards around implementation errors. 

Scott K

---

From: "Murray S. Kucherawy" <[email-masked]>
Date: Tue, 27 Aug 2013 17:30:39 -0700

On Tue, Aug 27, 2013 at 4:02 PM, Scott Kitterman <[email-masked]> wrote:

>  We shouldn't write standards around implementation errors.
>
>
+1.  There's a bug in the code, not a bug in the specification.  Let's fix
the right thing, please.

"/0" is not wrong according to RFC4632.  "/" is.  So yes, if libspf2 (or
anything) accepts "/" with no digits after it, then it needs to be fixed.

Of 180,000+ records found during the RFC6686 surveys, not one contained any
portion of a "v=spf1" record (TXT or 99) that included "/" followed by
something other than a digit, or "/" at the end of the record. The
likelihood that someone out there is relying on the existence of this bug
in implementations seems to be, at best, vanishingly small.  Thus, the fact
that this bug has been in some implementations all along is not a good
argument for augmenting the standard.

Finally, I take the libspf2 page to mean the add-on modules that use it are
affected by this bug, but not that the MTAs themselves are impacted,
because they don't use it directly.

-MSK

---

From: "Murray S. Kucherawy" <[email-masked]>
Date: Tue, 27 Aug 2013 17:35:34 -0700

>>       192.0.2.0/24 instead of 192.0.2.
Interestingly enough, the BSD inet_aton() function would accept the latter
version, treating it as 192.0.0.2.  This is a documented property of that
function and has been there for as long as I can remember.  Any software
that uses that function without also checking for three dots in the input
string is probably forgiving that syntax shortcut.

That said, I don't think that's ever been declared as a standard
alternative way to express an IP address, so I'm not suggesting anything be
changed here.  This just stirred a possibly relevant memory.

-MSK

---

From: Mark Andrews <[email-masked]>
Date: Wed, 28 Aug 2013 10:48:21 +1000

In message <CAL0qLwa1SeCYJfJqd-zx-psw4S4zuczKJP8WHrB6s2kj7W=[email-masked]>
> changed here.  This just stirred a possibly relevant memory.

Actually it is standard but for class B addresses.

	e.g. 130.155.1   

For class A you have a single period.

	e.g. 127.1 

If you want to check dotted decimal quad you need to use inet_pton.
Unless you OS vendor has hacked it (broken it) inet_pton only accepts
dotted decimal quad without leading zeros.

Mark

---

From: "Murray S. Kucherawy" <[email-masked]>
Date: Tue, 27 Aug 2013 18:14:40 -0700

> dotted decimal quad without leading zeros.

Which standard allows that expression?  I know what inet_aton() accepts,
but I never found an RFC or similar document that codified it.  The closest
thing I found was the inet_aton() man page, which is pretty specific to one
family of operating systems.

-MSK

---

From: Mark Andrews <[email-masked]>
Date: Wed, 28 Aug 2013 11:45:33 +1000

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

Last I heard POSIX was a standards body.

http://pubs.opengroup.org/onlinepubs/009695399/functions/inet_ntoa.html

---

From: Dave Crocker <[email-masked]>
Date: Tue, 27 Aug 2013 19:40:18 -0700

> Last I heard POSIX was a standards body.

You are trying to offer a standard for a parameter to a specific Unix 
function call as a format that should affect the work in the IETF?

d/

---

From: Mark Andrews <[email-masked]>
Date: Wed, 28 Aug 2013 12:53:27 +1000

> function call as a format that should affect the work in the IETF?

I think it should be dotted decimal quad with no leading zeros.
There exists standard functions that only accept that as input.

Having had to deal with the problems causes by people not being
aware of what inet_addr() accepts as input I want this to be a
straight forward definition.

There was a claim that "127.1" was not a standardised format for
a IP address and that claim was wrong.

Mark

---

From: Scott Kitterman <[email-masked]>
Date: Tue, 27 Aug 2013 23:05:06 -0400

> function call as a format that should affect the work in the IETF?

It was pretty clear to me that the conversation was about inet_aton(), which 
is specific to a family of operating systems (Linux is the same), so it was 
just about how some systems function, not any kind of a call for change.

Scott K

---

From: Dave Crocker <[email-masked]>
Date: Tue, 27 Aug 2013 20:15:58 -0700

> There exists standard functions that only accept that as input.

I think you are confusing a programming convention with a protocol 
convention.

Just to be clear, the current discussion is about the latter.

d/

---

From: Dave Crocker <[email-masked]>
Date: Tue, 27 Aug 2013 20:16:58 -0700

On 8/27/2013 8:05 PM, Scott Kitterman wrote:
> so it was

whereas it sounded to me like an attempt to get the SPF spec changed.

d/

---

From: "John Levine" <[email-masked]>
Date: 28 Aug 2013 03:20:01 -0000

>For class A you have a single period.

Yes, that was a fairly common syntax for classful network numbers
before CIDR was invented.

Since the syntax for SPF address ranges has always been CIDR and
nothing by CIDR, the history of other ways to write other stuff
doesn't seem the least bit useful or relevant.

R's,
John

---

From: Mark Andrews <[email-masked]>
Date: Wed, 28 Aug 2013 13:28:16 +1000

> Just to be clear, the current discussion is about the latter.

I thought I was being clear.  I wanting a extremely tight definition
as then it doesn't matter what parsing code is used for valid records
as you won't get unintended results.  Leading zero's lead to
unexpected results some of the time.

Additionally if you are trying to reject invalid records there already
exists code that can do it.

Mark

---

From: Ángel <[email-masked]>
Date: Wed, 28 Aug 2013 12:37:10 +0200

John Levine wrote:
> >> At 14:31 26-08-2013, ngel wrote:

The rfc could state that the parsers may accept the obs- tokens but are
not required to. And as it would state that new records MUST NOT use
it...

Murray, can you check the SPF records surveyed for cidr-lengths with
leading zeroes? I suspect we may be discussing how not to break use of
a feature that nobody is using (in addition of not working on all spf
implementations).

---

From: Hector Santos <[email-masked]>
Date: Wed, 28 Aug 2013 10:24:31 -0400

> accept a bare "/", or that there are sites that are using a bare "/" ?

The parsing I am sure came from the sites that were found to have it 
in the field and done long ago. Perhaps reported by customers and 
relaxed for future updates to help minimize and preempt such customer 
interop reports. There is 10 years of wide deployment history here and 
RFC6686 with its helpful 180,000+ records is not the definitive all 
encompassing sample of complete learned SPF history here. Too much 
leaning on the larger systems when the majority are the small to mid 
systems that may not fully represented in the group.  Not every site 
gets the same type of domains connecting to them. That is not 
suggesting all systems are not considered or not represented widely, 
but we have some additional exceptions to consider just as the leading 
zero ("/0x") behavior with one package was corrected with the ABNF.

Tony, just like with SMTP, we had the similar ABNF versus deployment 
issue with accepting the "MAIL FROM: <path>" syntax (space after the 
colon is invalid).  Hopefully you recall this specific 2821BIS 
discussion. We added the implementation notes and a reminder that the 
space is invalid.  However, the note indirectly gives insight to all 
SMTP developers that a SPACE is possible in the field and every system 
is very likely to come across it. Its better for developers to know 
this upfront rather than learn the hard way. By far, the major 
majority of SMTP receivers, if not all, tolerant the space. I suppose 
local policy offer STRICT5321 options like ours which is off by 
default (no surprise principle).  This is the text added for RFC5321:

    New text from 2821BIS discussions added to RFC5321:

    Since it has been a common source of errors, it is worth noting that
    spaces are not permitted on either side of the colon following FROM
    in the MAIL command or TO in the RCPT command.  The syntax is exactly
    as given above.

All SMTP developers remember this issue with the Outlook client.  It 
doesn't pay to be strict and reject this "MAIL FROM: <xxx>" command 
for syntax reasons.

What I am suggesting that we relax the ABNF (with an obs- token) and 
add the similar semantics and language to 4408BIS regarding "/" and 
also "/0" which is ABNF/CIDR valid but the popular LIBSPF2 will reject 
it (due to cidr=0).

Angel had a good idea to use obs- tokens. Perhaps 4408BIS can document 
the token "/" as obsolete and state parsers MAY accept the obs- token 
but are not required to with a cidr value of zero. It will also state 
the publisher MUST be compliant with standardized CIDR notations.

I suggest the following:

   obs-ip4-cidr-length  = "/" [ip4-cidr-value]
   obs-ip6-cidr-length  = "/" [ip6-cidr-value]
   ip4-cidr-length  = "/" ip4-cidr-value
   ip6-cidr-length  = "/" ip6-cidr-value
   ip4-cidr-value   = "/" ("0" |  %x31-39 0*1DIGIT) ; value range 0-32
   ip6-cidr-value   = "/" ("0" |  %x31-39 0*2DIGIT) ; value range 0-128

and with some draft text added:

   It is noted some implementations issue an perm error when cidr-length
   is "/0" and some implementations tolerant cidr-length "/" with a
   cidr-value of "0". It is not permitted to have a "/" for the
   cidr-length. The syntax is exactly as given above.

Thanks

-- 
HLS

---

From: Scott Kitterman <[email-masked]>
Date: Wed, 28 Aug 2013 10:35:56 -0400

>    cidr-length. The syntax is exactly as given above.

No.  Once you add the obs-* elements they are mandatory to support.  We 
shouldn't do that.  If some verifiers are slightly less tight than the ABNF, 
it's not an issue.  Imposing non-standard CIDR syntax is an issue.  I'm 
currently using the standard python ipaddress module for all this processing 
and I'm certainly not go to replace standard library code for a custom 
implementation to accommodate something like "/".

Scott K

---

From: Hector Santos <[email-masked]>
Date: Wed, 28 Aug 2013 10:48:49 -0400

> anything) accepts "/" with no digits after it, then it needs to be fixed.

Murray, we are talking about humans vs software.  While RFC6686 may 
not have recorded the use case scenario, there is a rich 10 year 
history among many implementations. So we very keen this report did an 
good job, but must be open to the idea it didn't cover everything.  It 
only takes one case, one customer complaint, report, etc and its 
determined it is better to be relaxed than to be strict.

I'm suggesting 4408BIS document this field implementation note. See my 
last post tony with some ideas where I am proposing similar action 
done to RFC5321 in regards to the invalid syntax of using an space 
after the "MAIL FROM:" or "RCPT TO:" commands.

> in implementations seems to be, at best, vanishingly small.

The sample didn't cover every SPF scenario.  I agree, it would be rare 
but thats the whole idea of long time engineering refinements - it 
covers and/or considers those rare situations. Sometimes it only takes 
one report case to take action in business. The automated parser needs 
to be robust, yet tolerant. Generally, in general, a 100% strict 
parser will not be very strict for long.

> Thus, the fact that this bug has been in some implementations all
> along is not a good argument for augmenting the standard.

Augmentation for this case is not the suggestion.  Codifying, adding 
implementation notes and a reminder what is the expected syntax for 
both the publisher and parser is what I am suggesting.

> because they don't use it directly.

Sure. Good point.

Lets keep in mind libspf2 was one of the original open source C SPF 
packages and also very likely used to get a proof of concept, 
exploration into SPF and to also port the logic to another package, 
other languages and scripting tools, etc.  So chances are good, while 
many don't directly use it, translated SPF knowledge and logic was 
carried over.

-- 
HLS

---

From: Scott Kitterman <[email-masked]>
Date: Wed, 28 Aug 2013 11:19:54 -0400

> many don't directly use it, translated SPF knowledge and logic was 

Just as a historical note:

The original reference implementation was in Perl, Mail::SPF::Query.  In C, 
libspf (a completely different code base than libspf2) was first.  Neither of 
these are in wide use anymore.  They were replaced by Mail::SPF and libspf2 
respectively.  

The area where libspf2 was important for protocol development was processing 
limits.  The current concept of a DNS lookup based set of limits was first 
implemented in libspf2 and then standardized in RFC 4408.  These limits 
replaced an earlier concept of recursion depth limits that was not very 
effective.

>From a lineage perspective, the Python library, pyspf, derived it's design 
from Mail::SPF::Query, but was then updated for RFC 4408 support in a way that 
wasn't feasible in the Mail::SPF::Query code base (which is why Mail::SPF 
exists).

Scott k

---

From: Hector Santos <[email-masked]>
Date: Wed, 28 Aug 2013 11:58:56 -0400

On 8/28/2013 10:35 AM, Scott Kitterman wrote:

> it's not an issue.

BIS specs are better when they tell the future reader about learned 
experiences and the potential market place interfacing issues.  A 
similar consideration was done for RFC5321 in regards to the space 
after "MAIL FROM:".    The ABNF was not refined to support it, but it 
functionally described the protocol design issue. It made you aware of 
the potential.

>Imposing non-standard CIDR syntax is an issue.

4408BIS still enforces a strict spec, but it has to also make note of 
the possible implementations which do exist.

> I'm

But speaking in general, with improved functional specifications, one 
may decide to add a SPFSTRICT_INVALID_CIDR_SLASH option to offer 
strict versus relaxed operations.

Of course, not every implementator uses 3rd party software.  Not every 
site is a *nix operation.  There are proprietary, in-house, commercial 
systems out there that don't use any of these 3rd party open source 
tools you mention and for many cases, just for legal reasons.

Thanks

-- 
HLS

---

From: Scott Kitterman <[email-masked]>
Date: Wed, 28 Aug 2013 12:02:29 -0400

On Wednesday, August 28, 2013 11:58:56 Hector Santos wrote:
> > shouldn't do that.  If some verifiers are slightly less tight than the
> > ABNF, it's not an issue.
> 
> > currently using the standard python ipaddress module for all this
> > processing and I'm certainly not go to replace standard library code for
> > a custom implementation to accommodate something like "/".
> 

I'm not objecting to the note, or something like it.  I don't think it's 
necessary, but I don't find it problematic.  I do object to adding anything to 
the ABNF that requires accepting non-standard CIDR, which this proposal does.

Scott K

---

From: "Murray S. Kucherawy" <[email-masked]>
Date: Wed, 28 Aug 2013 09:44:43 -0700

> the ABNF that requires accepting non-standard CIDR, which this proposal
I object even to the note.  I don't see the benefit in documenting a
(potentially large) list of ways various pre-bis implementations did things
incorrectly in the first place unless it's clear that their use became
common.  There's no evidence to support that.

The argument that this is just like the MAIL FROM debate in RFC2821 doesn't
work for me, because that form was contained completely within SMTP.  CIDR
format pre-dates SPF and has numerous other applications.  If instead it's
the case that lots of CIDR parsers got this wrong, then that's possibly
interesting, but RFC4408bis is the wrong place to say so.

-MSK

---

From: Hector Santos <[email-masked]>
Date: Wed, 28 Aug 2013 13:16:42 -0400

> the ABNF that requires accepting non-standard CIDR, which this proposal does.

Overall I agree, but for the record...

Where is that its documented that leading zero padding support is 
accepted standard CIDR notation for a SOFTWARE PARSER?  In other 
words, parsers MUST support this syntax.

As I see it, it was changed here to better support a package that 
bugged out on the leading zero.  Using your position, why bother? One 
may consider it common sense and only that is needed is the simpler 
notation:

         ip4-cidr-length: "/" 1*2DIGIT; range 0-32
         ip6-cidr-length: "/" 1*3DIGIT; range 0-128

By changing it, you are telling PARSERS not to barf out on a leading 
zero token which I agree with. So an immediate fix to the broken 
parser is done with new ABNF. But where is the empirical SPF record 
history that shows publishers are using leading zeros?  I don't recall 
any more self. I agree with it in principle, but a description would 
resolved it.

IMO, we need to be more consistent.

Thanks

-- 
HLS

---

From: Hector Santos <[email-masked]>
Date: Wed, 28 Aug 2013 14:48:20 -0400

On 8/28/2013 12:44 PM, Murray S. Kucherawy wrote:

> work for me, because that form was contained completely within SMTP.

Don't follow you, its exactly the same protocol/parser strict/relaxed 
design issue and consideration.  Relaxed wins in practice even though 
RFC5321 did not want to relax it via the ABNF.  That particular 
statement was added in RFC5321 for a reason.

-- 
HLS

---

From: S Moonesamy <[email-masked]>
Date: Wed, 28 Aug 2013 13:46:05 -0700

Hello,

I intend to use the inline reponses to address 
this review.  Please comment if there is anything 
you disagree with.  There are some points on 
which the author would like the working group to comment about.

At 08:13 25-08-2013, Eliot Lear wrote:
>considerations section.Â  A persistent reader 
>deprecated.Â  Here's what is 13.1 (there are a 
>that does not conform to the stated grammar MUST 
>be ignored.  Also, did the working group 
>consider a DKIM-like solution?  They all but 
>establish an _spf label in this document (I'll come to that in a moment).
>

The SPFBIS WG is not deprecating type 
SPF.  RRTYPE 99 has been removed from the (draft) 
protocol.  The working group discussion was 
something very like MUST NOT publish, MUST NOT 
query ...  The author thinks it might be 
reasonable to be more verbose in Appendix C,
which currently says:

Personally, he thinks it's accurate and succinct 
and he is not sure what to change that would 
amount to the same thing in a lot more words.  In 
his opinion, ... has been removed ... . .... MUST 
NOT query ... . ... MUST NOT publish ... . Is 
redundant, but I don't strongly object if people think it would be better.

There has been some discussion of the _spf label 
on the SPFBIS mailing list.  If I recall 
correctly I commented about that in one of my responses to the APPSDIR review.

>headers for HELO information.Â  Is that the 
>could be forged?Â  My point: the above is vague.

It's, most importantly, the actual connect IP 
from outside the receiving ADMD.  Finding the 
trust boundary reliably while groveling through 
the message header is hard, but people do 
it.  Since post-SMTP checks are quite common, it 
wouldn't be appropriate to try and disallow 
them.  The author thinks the current language is 
a reasonable compromise and, IIRC, subject to 
some intense WG debate that he prefers not to revisit.

>I don't think you mean location.  I think you mean "When to perform checks".

Location in the sequence of events.  Where would 
work as well.  The author thinks
Location/When/Where are all equivalent.  He 
prefers not to change it unless the WG supports a change.

>How does it aid in debugging?

It makes it clearer to the human eye what's 
intended.  People handle explicit better than implicit.

>You could do the same as you did with qnum, but perhaps that is overkill.

There has been some discussion of the ABNF on the 
SPFBIS mailing list ( 
http://www.ietf.org/mail-archive/web/spfbis/current/msg04047.html 
).  This is the suggested ABNF (credits to John Levine):

>>    from the <target-name> MUST NOT be used.Â  In contrast, when executing

Recursion into an include or execution of a 
redirect is part of the evaluation that a 
verifier does.  Must not be processed/evaluated 
by a verifier.  Since record publishers won't 
always know if others will use point to their 
records using include/redirect, there's no way a 
publisher could satisfy this requirement.  Given 
it can only work one way, the author don't understand the confusion.

The author is open to improved text, but he does not see the problem.

>"Formal Specification".  Don't have two of those.

The ABNF collection will be moved to a section.

>RHS.  I would go just that bit further to explain.

Forwarders are mediators in the terms used here and E.2 is applicable, not E.1.

>expanding out the acronym.  How about just saying "domain owners"?

That's unchanged from RFC 4408.  The author does not think we should change it.

RFC 5598 is the mail architecture document the 
working group used got.  The author agrees it's 
trained, but we tried to stick with terminology 
from 5598.  Ripping out the 5598 terminology 
would be a bunch of work that he does not think would be worth it.

>EHLO commands as specified in [RFC5321].
Possibly.  The longer definition is largely from RFC 4408.

Can the working group comment on this if it is going to change it?

>This forward reference is unnecessary, and I would remove the section.

The author agrees but the working group does.

>That's grammatically incorrect.  Remove 

The author is ok with the suggestion.

>"deferred" or "checks made after delivery" or some such.

The author thinks post-delivery would be 
better.  Obviously literal offline checks aren't
possible.

>reader?  Personally I say none, and would remove.

That's there in response to people complaining 
4408 was somehow making SPF checks 
mandatory.  The author does not care if it is 
removed it as long as someone else deals with the 
crazies convinced it's removal means something sinister.

>name found in the RDATA of each answer."

The author is ok with changing this.

>>but is not willing to make a strong policy statement

The sending one.  It's their record.

Regards,
S. Moonesamy (as document shpeherd)

---

From: Dave Crocker <[email-masked]>
Date: Wed, 28 Aug 2013 14:01:29 -0700

On 8/28/2013 9:44 AM, Murray S. Kucherawy wrote:
> On Wed, Aug 28, 2013 at 9:02 AM, Scott Kitterman <[email-masked]
> <mailto:[email-masked]>> wrote:
>
> (potentially large) list of ways various pre-bis implementations did
> things incorrectly in the first place unless it's clear that their use
> became common.  There's no evidence to support that.

+10.

d/

---

From: S Moonesamy <[email-masked]>
Date: Thu, 29 Aug 2013 01:03:54 -0700

Hi Eliot,

The following is to address the rest of the 
review.  There was one major issue which I did 
not comment about in my previous message.

At 08:13 25-08-2013, Eliot Lear wrote:
>deprecated. Here's what is 13.1 (there are a few 
>words about 6686 in 3.1 as well, but nobody 

redundant, but he don't strongly object if people think it would be better.

Location in the sequence of events.  Where would 
work as well.  The author thinks
Location/When/Where are all equivalent.  He 
prefers not to change it.  The SPFBIS did not support a change.

The SPFBIS WG did not suggest any change to this.

>This forward reference is unnecessary, and I would remove the section.

The author agrees but the working group doesn't.

Regards,